我们离Google SRE还有多远？ - HelloWorld开发者社区

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

我们离Google SRE还有多远？

BigDataSRE

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

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

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

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

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

我们离Google SRE还有多远？

 一、土壤：基础设施

1.1 硬件故障

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

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

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

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

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

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

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

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

"每天打扫一次"数据中心里需要维修的硬件。（而非时刻都在）

需要一份精确的硬件损坏和分析报告，报告来自 Google System Health

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

TOLERATING FAULTS, NOT HIDING THEM.

我们离Google SRE还有多远？

Google System Health

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

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

** A SRE 1:0 G SRE **

1.2 硬件选型

Google的信条是：

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

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

: "混合存储是什么机型？啊？为什么是X块SSD硬盘呢？我的业务场景需要Y块！"
:"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 **