嘉宾介绍
王璞，数人科技创始人。2002年获得北京航空航天大学力学学士学位，2007年获得北京大学计算机硕士学位，2011年获得美国George Mason University计算机博士学位，研究方向机器学习，发表十余篇机器学习以及数据挖掘相关论文。毕业后在硅谷先后供职StumbleUpon、Groupon和Google三家公司，负责海量数据处理、分布式计算以及大规模机器学习相关工作。2014年回国创办数人科技，基于Mesos和Docker构建分布式计算平台，为企业客户提供高性能分布式PaaS解决方案。
引言
SRE是Site Reliability Engineer的简称，从名字可以看出Google的SRE不只是做Operation方面的工作，更多是保障整个Google服务的稳定性。SRE不接触底层硬件如服务器，这也是高逼格的由来：
Google 数据中心的硬件层面的维护工作是交给technician来做的，technician一般不需要有大学学历。
SWE是SoftWare Egineer的简称，即软件工程师（负责软件服务的开发、测试、发布）。
SWE更新的程序代码（下文称为server），只有在SRE同意后才能上线发布。因此，SRE在Google工程师团队中地位非常高！我们下面将分别介绍。
备注：我本人是SWE，本文是从SWE的角度看SRE，我的老朋友@孙宇聪同学是原Google SRE，他会从另一个角度来阐述此主题，敬请期待哦！
1. SRE 职责
SRE在Google不负责某个服务的上线、部署，SRE主要是保障服务的可靠性和性能，同时负责数据中心资源分配，为重要服务预留资源。
如上文所受，和SRE想对应的是SWE（软件开发工程师），负责具体的开发工作。
举个例子，我之前在Google的互联网广告部门，我们team负责的server是收集用户数据用于广告精准投放，这个server的开发、测试、上线部署等工作，都是由SWE来完成。
SRE不负责server的具体实现，SRE主要负责在server出现宕机等紧急事故时，做出快速响应，尽快恢复server，减少服务掉线带来的损失。
备注：这里的server是指服务器端程序，而不是物理服务器。在Google，SWE和SRE都无权接触物理服务器。
2. SRE 要求
因为SRE的职责是保障服务的稳定和性能，所以在SRE接手某个server之前，对server的性能和稳定性都有一定的要求，比如server出现报警的次数不能超过一定的频率，server对CPU、内存的消耗不能超过预设的指标。
只有server完全满足SRE的要求以后，SRE才会接手这个server：
当server出现问题时，SRE会先紧急修复，恢复服务，然后SRE会和SWE沟通，最终SWE来彻底修复server的bug。
同时，对server的重大更新，SWE都要提前通知SRE，做好各种准备工作，才能发布新版server：
为了能让SRE能接手server，SWE要根据SRE的要求，对server做大量的调优。首先SRE会给出各种性能指标，比如，服务响应延迟、资源使用量等等，再者SRE会要求SWE给出一些server评测结果，诸如压力测试结果、端到端测试结果等等，同时，SRE也会帮助SWE做一些性能问题排查。
所以SRE在Google地位很高，SWE为了让server成功上线，都想法跟SRE保持好关系。
我举个具体的例子来说明，在Google，SWE是如何跟SRE配合工作来上线server的。
我们team对所负责的server进行了代码重构，重构之后，要经过SRE同意，才能够上线重构后的server。
为此，我们team的SWE要向SRE证明，重构后的server对资源的开销没有增加，即CPU、内存、硬盘、带宽消耗没有增加，重构后的server性能没有降低，即端到端服务响应延迟、QPS、对压力测试的响应等这些性能指标没有降低：
当时对server代码重构之后，server有个性能指标一直达不到SRE的要求。这个指标是contention，也就是多线程情况下，对竞争资源的等待延迟。重构server之后，contention这项指标变得很高，说明多线程情况下，对竞争资源的等待变长。
我们排查很久找不到具体原因，因为SWE没有在代码中显式使用很多mutex，然后请SRE出面帮忙。
SRE使用Google内部的图形化profiling工具，cpprof，帮我们查找原因。
找到两个方面的原因：
-
tc_malloc在多线程情况下频繁请求内存，造成contention变高；
-
大量使用hash_map，hash_map没有预先分配足够内存空间，造成对底层tc_malloc调用过多。
3. SRE 工作内容
简而言之，Google的SRE不是做底层硬件维护，而是负责Google各种服务的性能和稳定性。换句话说，Google的SRE保证软件层面的性能和稳定性，包括软件基础构架和应用服务。
SRE需要对Google内部各种软件基础构架(Infrastructure)非常了解，而且SRE一般具有很强的排查问题、debug、快速恢复server的能力。
我列举一些常见的Google软件基础构架的例子：
-
Borg：分布式任务管理系统；
-
Borgmon：强大的监控报警系统；
-
BigTable：分布式Key/Value存储系统；
-
Google File System：分布式文件系统；
-
PubSub：分布式消息队列系统；
-
MapReduce：分布式大数据批处理系统；
-
F1：分布式数据库；
-
ECatcher：日志收集检索系统；
-
Stubby：Google的RPC实现；
-
Proto Buffer：数据序列化存储协议以及RPC协议；
-
Chubby：提供类似Zookeeper的服务。
Google还有更多的软件基础构架系统：Megastore、Spanner、Mustang等等，我没有用过，所以不熟悉。
4. 运维未来发展方向
我个人觉得，在云计算时代，运维工程师会慢慢向Google的SRE这种角色发展，远离底层硬件，更多靠近软件基础架构层面，帮助企业客户打造强大的软件基础构架。
企业客户有了强大的软件基础构架以后，能够更好应对业务的复杂多变的需求，帮助企业客户快速发展业务。
另外我个人观点，为什么Google的产品给人感觉技术含量高？
并不见得是Google的SWE比其他Microsoft、LinkedIn、Facebook的工程师能力强多少，主要是因为Google的软件基础构架(详见上文）非常强大，有了很强大的基础构架，再做出强大的产品就很方便了。
Google内部各种软件基础构架，基本上满足了各种常见分布式功能需求，极大地方便了SWE做业务开发。
换句话说，在Google做开发，SWE基本上是专注业务逻辑，应用服务系统(server)的性能主要由底层软件基础构架来保证。
————我是分割线————
下面就是本次分享的互动环节整理（真的非常精彩哦：）。
问题1：SRE参与软件基础项目的开发吗？
SRE一般不做开发。比如Google的BigTable有专门的开发团队，也有专门的SRE团队保障BigTable server的性能和稳定性。
问题2：一般运维工具，或者监控，告警工具，哪个团队开发？
SRE用的大型管理工具应该是专门的团队开发，比如Borgmon是Google的监控报警工具，很复杂，应该是专门的团队开发，SRE会大量使用Borgmon。
问题3：基础软件架构有可以参考的开源产品吗？
Google内部常见的软件基础构架都有开源对应的版本，比如Zookeeper对应Chubby，HDFS对应Google File System，HBase对应BigTable，Hadoop对应MapReduce，等等。
问题4：还有SRE会约束一些项目的性能指标，比如CPU和内存的使用阈值，这些值是从哪里得来的？或者说根据哪些规则来定制的？
SRE负责Google的数据中心资源分配，所以一些重要server的资源是SRE预留分配好的。对CPU、内存等资源的分配，SRE按照历史经验以及server的业务增长预期来制定。
此外Google数据中心里运行的任务有优先级，高优先级的任务会抢占低优先级任务的资源，重要的server一般优先级很高，离线任务优先级比较低，个人开发测试任务优先级最低。
如何一起愉快地发展
高效运维系列微信群是国内高端运维圈子、运维行业垂直社交的典范。现有会员800余名，其中运维总监及以上级别会员300多名。
“高效运维”公众号值得您的关注，作为高效运维系列微信群的唯一官方公众号，每周发表多篇干货满满的原创好文：来自于系列群的讨论精华、运维讲坛线上/线下活动精彩分享及部分群友原创。“高效运维”也是互联网专栏《高效运维最佳实践》及运维2.0官方公众号。
提示：目前高效运维两个微信主群仅有少量珍贵席位，如您愿意，可添加萧田国个人微信号 xiaotianguo 为好友，进行申请；或申请加入我们技术交流群（技术讨论为主，没有主群那么多规矩，更热闹）。
重要提示：除非事先获得授权，请在本公众号发布2天后，才能转载本文。尊重知识，请必须全文转载，并包括本行及如下二维码。
