Google SRE 参会总结
近期有幸参加了一个小型的运维会议，同《SRE：Google 运维解密》的译者进行面对面的沟通，收益匪浅。会议上大家的讨论非常热烈，话题主要集中在以下几个方面：
什么是SRE，职责是什么？
SRE全称Site Reliability Engineering，是Google内部的一个运维职位，主要职责是保障服务的可靠性和性能，同时负责数据中心资源分配，为重要服务预留资源，该职位不负责某个具体业务的上线和部署。
SRE分为产品SRE和平台SRE。产品SRE负责某个具体产品相关的所有组件的运维，而平台SRE则负责诸如主机计算能力，数据库资源等PaaS资源。按照我个人的简单理解，前者是以业务为单位的纵深管理，后者是以平台为基础的横向管理。不论何种SRE，在我看来，这个职位都对个人能力有较高的要求，非传说中的全栈工程师莫属。
SRE和开发如何分工协作
首先，SRE和开发仅仅只是两个不同的职位，并非某种能力的划分，两者之间可能会存在转换。比如某个产品上线之前没有设置专门的SRE，上线之后为了满足业务需要，从之前的开发人员中选择合适的人担任SRE；
其次，SRE和开发在产品的各个生命周期都可能存在合作。比如产品的设计阶段，需要SRE介入协助进行高可用架构设计；产品交付阶段，又可能需要开发人员配合SRE进行一些故障的分析和诊断。
开发和运维相互之间的职责如何界定
在国内，开发和运维相互扯皮是一个永恒的话题，那么Google是怎么应对的呢？
在Google内部有一个非常好的规则——对事不对人。出了问题，首先想到的不是谁来承担责任，而是大家坐在一起想办法解决问题。他们会尽可能找出问题的root cause，尝试从规则上、流程上杜绝类似问题的再次发生。而Google也不会由于一个具体的case开除员工，当然，如果屡教不改总是犯低级错误，或者工作态度有问题的不在此范围内。
个人觉得这是非常好的一个制度，能够消除面对某个具体问题时，由于可能承担的责任问题，把彼此放在了对立面。毕竟问题已经出了，快速的组织善后工作，从根本上解决问题避免再次发生，才是正确的方向。
当然，一团和气是干不好革命工作的，必要的工作界面划分还是有必要的。不论是开发还是SRE，提供的都是有限责任，就是说我的服务是有边界的，不是任何问题都需要负责。比如我是一个数据库平台的SRE，某个产品使用了该平台上的数据库，开发人员写了个非常消耗资源的SQL语句，导致整个系统夯死。那么这个问题的责任如何界定呢？其实早在业务部门选择这个数据库平台的时候，就已经被告知能够提供哪些服务，比如我的平台能够提供多少计算能力、多少IO能力，超出能力之外的要求概不负责。所以我们举的这个例子，实际上在Google通常不会发生。因为代码中会有相应的检测机制，超出服务能力的请求会被无条件干掉。不像我们在运维的时候，找出问题SQL后可怜巴巴的到处问是谁的SQL，能不能杀掉。可能在犹豫的这段时间，会因为这条SQL消耗过多的资源导致更大的问题出现。因此，Google的解决方案是牺牲个体，保护全局。而这套规则SRE早就告诉了业务平台，出现了问题，只能是业务部分自己想办法处理。这是界面划分杜绝扯皮的又一法门，所谓的阳谋，大概就是如此。
为什么这套规则，在国内比较难以落地
这段会上并没有深入讨论，纯属个人意淫。为什么国内没有形成这样的制度，开发运维各自为政呢？个人觉得有两点原因：
国内不论是底层基础架构还是上层应用软件，基本都是成熟的商业软件，比如Oracle Database、IBM Middleware，开发和运维分别因为某一个项目连接在一起，缺少前期沟通和磨合时间。类似于古时候的包办婚姻，双方缺少感情基础；
开发主要专注于业务逻辑的实现，缺少稳定性和性能方面的考虑，导致系统上线后出现各种奇葩问题。但由于对基础架构不了解，只能依赖于运维方面解决问题，长此以往，形成了运维“无限责任制”。
从这两个层面看，也能理解为什么DevOps近来才火热起来，而且是从互联网公司开始火的，因为互联网公司是自己开发做产品，开发和运维的联系天然比较紧密。传统公司随着业务定制化的增多，运维“无限责任制”又导致各种矛盾不断激化，DevOps需求也就越来越迫切。
以上只是通过会议上大家的讨论，加上个人理解而成，纰漏在所难免，如有不对的地方，还望指正。