我们离Google SRE还有多远？

经过几年的挣扎和讨论（确切说应该是3年），老板在钉钉群以通告的方式正式告别伴随我们多年的职业Title --- PE，改名为SRE。（后续以A SRE区别Google SRE）

BigDataSRE

暂且不提名称变化背后的含义，对于新的称谓的意义很明显，SRE源于Google“网站可靠性工程师”的缩写，这个职位在Google内部有着“崇高”的地位，他们参与产品的设计（高扩展性、高可靠性），他们决定产品是否可以上线，他们研发面向海量任务、服务器、其他人员的管理系统、基础服务、规划系统等等。一时之间，SRE就是“高逼格”职业的代名词，更让人惊喜的是，这些工作都是运维的范畴。多年来成为苦逼代名词的运维岗喜极而泣！原本压抑在内心的信条 --- “运维是最牛逼的职业” 终于得到正名。

谁都不是傻子，很快SRE带来全新的、革命性的运维方式表面上让运维这个行业变得光明起来，可背后涌动的“暗流”却是我内心反复锤问 --- “运维工程师可以转型成SRE吗？”，不要忘了，SRE的出生是研发工程师。

“我们常说要转型，要做DevOps，要做SRE。可几年来，你才发现，这只不过是一个骗局，真正需要转型的是Dev，他们把Ops的活干了，而Ops只能另谋出路，DevOps对Ops来说就是一个笑话。”

虽然我不完全同意我同事的这番言论，但至少他把我们心里不愿承认的，不愿回答的问题给出了他的答案。

作为一个运维老兵，也希望可以找到自己问题的答案，好在<Google SRE>一书的上市，全面且细致的介绍了SRE工作，让我可以近距离的了解和思考未来。

                            一、土壤：基础设施

1.1 硬件故障

2010年，记得刚加入A云的我，每周耗费一个工作日例行到机房处理各种硬件故障，那时候我们还只有一个数据中心，运行的服务器不过寥寥几千台，那时的我心里有一个疑问：“以后怎么办？”，为此后续的一年，我从事两项相关的工作：

1. 把维修自动化，主要是磁盘和内存的维修自动化，当厂商把损坏的硬件替换到服务器上之后，后面的维修动作就是一键触发，自动修复并上线。
2. 故障预判，其实说预判有些牵强，大部分的故障我们无法做到预判，多数情况是在小时级别后发现硬件故障。

这能在非线性的物理服务器增长中，让同事从繁琐的维修工作中解脱出来，但事实上，2部分的工作带来很多的质疑：

“为什么机器/硬盘Hang住了，你的检测程序却无动于衷？”

质疑多了不同的团队自己就要抡开膀子自己干，造成了一些不必要的PK，这些PK渐渐的让这些相关团队认识到硬件是不可靠的，而不是天真的认为“一切硬件故障可以被甄别，并可以快速隔离”。重复造了轮子，明白了一个道理。

可我并没有在<SRE>一书中找到SRE是否经历这样的阶段，因为一书中提到和硬件相关内容甚少，不过在相关资料<The DataCenter As a Computer>中，能找到类似的经历。

文章的作者之一，Jimmy Clidaras，他从04年开始从事Google Datacenter Engineering的工作，是第一个Senior Director of Google’s Platforms Infrastructure Engineering Team。

文章提到了非常有趣观点 --- 为了提到维修的效率，以下两项工作非常关键：

1. "每天打扫一次"数据中心里需要维修的硬件。（而非时刻都在）
2. 需要一份精确的硬件损坏和分析报告，报告来自 Google System Health

最后，他同样提到应对的观点：(N+?理论，该论点也反复在SRE一书中提到)

TOLERATING FAULTS, NOT HIDING THEM.

Google System Health

我可以得出这样的结论，Google的基础设施团队，他们做了大量的工作（包括科研性的工作），这一切SRE团队并非参与者，而是“维护者”，甚至是“享用者”。（理想情况下，他们不需要再关心硬件故障或者之类，但我相信现实情况下，他们对硬件故障也耳熟能详了。）

幸运的是（还是不幸？：）），硬件故障等问题经验至今仍然是A云SRE值得“分享”的一大类目。

** A SRE 1:0 G SRE **

1.2 硬件选型

Google的信条是：

并不会用专门的物理服务器运行专门的软件服务器

所以，G SRE不会碰到硬件选型的烦恼。所以他们不会碰到如以下的对话：

<A TL>: "混合存储是什么机型？啊？为什么是X块SSD硬盘呢？我的业务场景需要Y块！"
<A SRE>:"B、C等其他业务都统一了，为了节省采购成本，请做应用的优化来适配这一款混合存储机型。"

A SRE他们有足够的话语权。这并不是说他们可以自主研发某一款机型，他们的背后还有基础系统研发团队，通常基础研发团队会拿出多款搭配的试验机型供SRE来决策。一方面A SRE在这些机型之上“折中”出四不象来，看起来让每个业务都不饿，但也都喂不饱。另一方面，A SRE开始游说业务研发的Leader们开始做应用改造和适配，否则就会面临到货周期、财务等一系列的挑战。

因为没有一个统一的资源调度系统（说起来很轻松），业务还是天然的区分了几种不同类型的物理服务器：

| 机型 | 业务场景
|--------|
| A | CPU、MEM密集型、少量存储
| B | CPU密集型、大量存储
| C | CPU密集型、磁盘响应延迟低

每年A SRE（包括基础系统、网络团队）因此需要做物理服务器在数据中心之间繁重的搬迁工作。

同时，针对机型的定制化改造也变得臃肿不堪，为了对机型做某些妥协的业务通过RAID，软RAID的方式来最小化他们应用的改造成本，而这些行为都被记录在A SRE提供的“应用模板”之中，它是系统装机之后必须经过的步骤，以确保机型被正确的配置了。

机型规划、有效缩减是A SRE必备的课题，由于缺乏长期看得见的举措，A SRE用短期“自动化”的手段补位，相信这也是A SRE值得分享的心路历程。

** A SRE 2:0 G SRE **

1.3 基础软件系统

1.3.1 Borg

Borg并不是SRE团队研发的产品，无论是资料还是John Wilkes 15年的分享（其实我早知道:)）。可为什么每次提起Brog，就会让人联想到G SRE? 就像每次提及双11，就会让人联想到阿里巴巴技术保障部。我觉得这种错觉是相似的 --- 当你既是这款产品的使用者，又是这款产品的维护者，那你最适合做这款产品的代言人。

Borg让G SRE进化，G SRE让Borg进化。看看书中G SRE进化的例子吧

最初的自动化包括简单的Python脚本，执行如下的操作。

• 服务管理：保障服务运行（例如，在段错误后重新启动） --- borg
• 跟踪 那些服务应该运行在那些机器上。 --- Borg
• 日志消息解析：SSH进入每一台机器，用正则表达式过滤日志。 --- gRPC。

我做了标注部分，书中是这样解释的。

“最初的自动化努力给我们争取了足够的时间，把集群管理转化为自治系统，而不是自动化系统。”
“机器的损坏和生命周期的管理已经不需要任何操作了。成千上万的机器加入系统，或者出现问题，被修复，这一切都不需要SRE的任何操作。”

很有意思，G SRE并没有觉得自己曾经的工作被替代（更别提被“别人”拯救）我想唯一的可能是G SRE有极大的参与感和主导权。

A SRE在地球的另一端，仍用着“最初的自动化脚本”执行着去完成那些操作。宣称不久将“替代”A SRE这些脚本的DevOps团队，从1.0演进到2.0再到现在3.0，多年来风风雨雨，你来我往，既没有兑现当年的承诺，也没有留下“战友”般的友谊。干活累的时候，相互喷一嘴解解乏。

** A SRE 2:1 G SRE **

1.3.2 BorgMon

** A SRE 2:2 G SRE **

1.3.3 Jupiter&BwE

Google Jupiter和BwE(带宽控制器)，实现了一个巨大的可供管理的虚拟网络，在一个数据中心里，几百台自研的交换机以Clos方式连接为一体，拥有几W个虚拟端口，提供1.3Pb/s交叉带宽。

网络也并不由A SRE直接维护，但A SRE在数据中心网络问题的排查中往往会起到决定性的作用，而相比较G SRE的BwE，A SRE更有办法能够找那个“坏小子”应用，人肉充当带宽控制器的角色，当然前提是时间允许的情况下。

** A SRE 2:3 G SRE **

1.3.4 存储系统

D Service

A云的存储系统和G司类似，除了D服务。A云并没有D服务，底层磁盘是直接由分布式文件系统盘古直接管理，在盘古之上也衍生出很多数据库服务，如MaxCompute、OTS、OSS等。

或许没有D服务，盘古仅能按照集群来管理不同类型的磁盘，还无法做到数据中心级别。

** A SRE 2.5:4 G SRE **

1.3.5 分布式锁服务

和存储类似，相比较可以提供多个数据中心服务的Chubby，A云的分布式锁服务仅能按照集群级别管理。

** A SRE 3:5 G SRE **

1.3.6 GSLB

** A SRE 3:6 G SRE **

1.3.7 结束

我相信G SRE的成功之一源于G基础软件服务成功，正如蒸汽火车和磁悬浮列车最高时速的差距并不在于“司机”的操作技巧。

                             二、能力：SRE研发的产品

本节只能依据书中明确提到由SRE团队研发产品来横向的比较。书中提到大部分Google内部幕后的软件工程实践都是来自SRE部门，而此类现象在A云并不多见，相反，在A云多数源于SRE部门的idea，而往往实践落到了研发部门，我们称之为“收编”。

2.1 Auxon

容量规划是两个SRE都要直面的问题，而且两者都意识到了传统容量规划的方法带来的巨大开销和不确定性。

G SRE和技术项目经理研发了Auxon，一款基于“意图”的容量规划工具。A SRE虽然表现上已经告别了表格的方式，但容量规划的系统是财务主导，由研发团队支撑，和SRE并没有太大的关系。而A SRE更多的专注在研发如何“高效”的提供让人信服的业务数据和趋势分析的平台。

从书上可以了解到，G司拥有不止一套容量规划的模型和工具，用于满足数据样本和规划模型之间的差异化，G SRE也意识到Auxon也无法满足所有项目。但书中没有提到的是大型分布式系统的容量规划，这背后不是简单一个或几个技术指标的分析与运算，容量规划背后那些KPI的目标，不同部门相互交织，视角和理解数据的方式完全不同，A SRE要面临的挑战或许要大的多。

** A SRE 0:1 G SRE **

2.2 Layer-3 Load Balancer

对于这款产品，书中提及的篇幅不多，我翻阅了一下参考资料<Maglev: A Fast and Reliable Software Network Load Balancer>，文章的作者大多数来是Google的资深软件研发工程师。

G SRE源自对网站的可靠性维护，自然的对负载均衡器有非常深的理解，从19、20章的描述可以感受到LB是那种根植于SRE技能条里必备技能。根据我个人的以往工作经历，曾经几乎一整年的工作就是和商业负载均衡器打交道，反而到了A云接触的少了。

** A SRE 0:2 G SRE **

2.3 Sisyphus

Tesla

通用的自动化发布框架,和G SRE类似的，A SRE团队已经实现了支持自动化发布的复杂部署、升级流程，这个平台叫Tesla。同时，它也具备负责记录每个步骤执行过程和异常通知，提供Python扩展包，唯一让我觉得遗憾的是，Sisyphus和构建工具打通，做到代码构建到上线快速发布。我相信任何的线上发布除了系统之间互通之外，也需要研发团队、发布团队和SRE团队之间的互通。而Tesla目前虽然还未和构建平台有任何的交互，但在团队直接的协同通知上，已经研发出了一套面向工程师的“发布申请流程”。

Tesla平台已经在内部运行了几年，是由A SRE主导研发的智能运维平台，除了自动化发布框架，它还整合了其他很多SRE主导研发的产品。

** A SRE 1:3 G SRE **

2.4 其他

Google Cron&Google WorkFlow，书中有专门的章节提及，但并未直言这两个产品是由SRE团队研发，我想列出来的原因是本是大型分布式系统应该依赖的基础软件，G SRE可以明白的阐述其软件设计思路和实现，而A云，早在几年前也有类似的产品服务整个数据中心，但由于组织架构的调整，这些服务慢慢的变成“无人区”，更别提有业务应用敢使用，作为A SRE的一员，未免令人唏嘘不已。

** A SRE 1:4 G SRE **

                               三、思想：方法论

3.1 培训新人

很不幸，我不得不承认A SRE团队目前就是这种“浴火重生”的学习方式，幸运的话，有能力的工程师最后能够从这种大坑里爬出来（所以我们招人异常困难），但更常见的是，多数有能力的工程师都无法在这种环境里成长。我们意识的问题的现状，却仍然没有腾出手来改变。

虽然说，我们的初衷和G SRE相同，培养工程师个人的能力，与其让他们传授知识，不如自己动手（感觉我有点厚颜无耻），可与G SRE 提供明确的系统性培训目标以及不同领域的SRE专家和研发联系人不同是，A SRE知识体系仍然在口口相传。

相比较G SRE在生产系统做故障演练和破坏性学习，大多数A SRE会从测试环境成长起来，测试环境的配置问题和软件标准化远远比生产环境糟糕的多，虽然A SRE可以在测试环境做一些破坏性的试验加深对系统的理解，但相比较生产系统，这可以说是完全不同的世界。

缺少有效的事后总结和文档能力，A SRE每周的不定期的知识技能分享也面临无法维继的风险。

** A SRE 0:1 G SRE **

3.2 接手一项服务/产品

在A云只有部分服务是一开始就是SRE负责运维的。但和G SRE不同的是，A SRE开始刚接手服务/产品往往都是一个“烂摊子”。

为了提高该服务的可靠性，A SRE往往会参与产品的设计和下个迭代版本的构建：

• 系统的结构体系，从下自上的高可用优化方案。
• 监控，提供更加丰富和标准的监控接口。（很多产品接手时，没有任何监控，研发团队甚至不清楚有什么监控平台。）
• 选择指标，度量服务可用性的关键指标。
• 紧急事件的处理机制和升级路线。
• 服务日志分析。
• 通过Tesla的平台扩展产品自我快速迭代的能力。

并且往往在A SRE还未完全验收好相关改进和方案，产品就要开门“接客”了。

• 文档，A SRE决定了一个产品运维文档的撰写能力
• 咨询，“飞机”已经起飞，始料未及的“Bug”需要研发团队和A SRE在线找到办法修复/临时绕过，等待下一个迭代版本。（在这里，原本应该提供的运维改进版本又Delay了。）

A SRE周围充满了人情和感性，业务产品那个不是从水深火热之中爬出来，而我们又如何能够袖手旁观呢？

G SRE PRR模型是非常值得借鉴的一种接管服务的方式，G SRE的这套方法论更坚定了A SRE的未来改进的方向。

** A SRE 1:2 G SRE **

3.2 团队构成

G SRE	A SRE
/	传统Ops
Tech Lead	Tech Lead
SRM	Tech Lead
PM/TPM	/
/	PD
/	数据分析/运营

SRE团队构成多样化，有些成员喜欢责任职责被明确的定义（仅作研发效率相关的工作），据此可以迅速安全的做出范围内的决策，另一些成员在一个更为动态的环境中工作，随时切换责任。

A SRE相比G SRE是一个更为动态的团队，团队内部比较来说，只有数据分析/运营的职责（技能）的SRE技能切换不太频繁。

A SRE技术负责人承担了不仅负责团队技术方向，还有绩效管理和横向团队协作等（其他一切其他人不能处理的事情），所剩的工作时间很少能够review团队成员的代码，更多方通过在团队中推进共识的建立来引领团队。

** A SRE 2:3 G SRE **

                                  四、结束语

通读<SRE>全书，不禁赞叹！

No	A SRE	G SRE
SRE的土壤	3	6
SRE的能力	1	4
SRE的思想	2	3

一千个人眼中有一千个哈姆雷特，在意识到差距的同时更不必妄自菲薄，更重要的是思考这些差距的所欠缺是努力还是思想，是再次驱动我翻开这本书细细再品的动力。

更让我收获的是，书中那些活生生的案例。

1. 一项不稳定的服务，Bigtable稳定性造成报警过多，降低SLO减少报警，重点提升Bigtable的软件性能。

2. Gmail的手工干预哲学：是短期麻木于SRE的提供的工具减少影响还是长期找到根因，并解决。
3. 迁移Mysql到Brog，Brog不是万能，至少离开SRE在业务上做的优化，这项工作无法得以完成。

这些案例书中有的给出的答案，有的没有，给我最大的几点共鸣

1. “世界上没有捷径”，我们经历着的也是G SRE经历过的。
2. 没有一种答案可以解决所有问题，试图回答文章之初的问题变得可笑，SRE是一个积累的命题，寻找总开关想一劳永逸注定是徒劳无益。
3. 只有非比寻常的努力，才配的上不寻常的Idea。