×

谷歌SRE运维解密序言

标签: 暂无标签
软件工程有的时候和养孩子类似∶虽然生育的过程是痛苦和困难的,但是养育孩子成人的过程才是真正需要花费绝大部分精力的地方。但是,传统软件工程专业花费了很多精力讨论软件的开发过程,而不是其后的维护过程。有统计显示,一个软件系统的40%~90% 的花销其实是花在开发建设完成之后不断维护过程中的。行业内流行的一个说法是∶一个系统如果已经开发完成,部署在生产环境上,那么它就是"稳定的",就不需要那么多工程师花费精力去优化、维护。我们认为这个说法是错误的。从这个视角出发,我们认为如果软件工程职业主要专注于设计和构建软件系统,那么应该有另外一种职业专注于整个软件系统的生命周期管理。从其设计一直到部署,历经不断改进,最后顺利退役。这样一种职业必须具备非常广泛的技能,但是和其他职业的专注点都不同。Google 将这个职位称为站点可靠性工程师(SRE,Site Reliability Engineering)。

那么,站点可靠性工程师究竟代表着什么呢?的确,这个词语并不能够特别清晰地描述这个职位的意义。基本上每个 Google SRE 都会被经常问到这个职位到底代表什么意思,以及他们的日常工作究竟是什么。

将这个词语展开来说∶首先,也是最重要的一点,SRE 是工程师(engineer)。SRE 使用计算机科学和软件工程手段来设计和研发大型、分布式计算机软件系统。有的时候,SRE 和产品研发团队共同工作,其他时候我们需要开发这些系统的额外组件∶例如备份系统和负载均衡系统等。理想情况下,同时推进这些组件在多个项目中复用。还有的时候,我们的任务是想出各种各样的办法用现有组件解决新的问题。

其次,SRE的关注焦点在于可靠性。Ben Treynor Sloss,Google负责7×24运维的副总裁,SRE 名称的发明者,宣称可靠性应该是任何产品设计中最基本的概念∶任何一个系统如果没有人能够稳定地使用,就没有存在的意义。因为可靠性是如此重要,因此 SRE专注于对其负责的软件系统架构设计、运维流程的不断优化,让这些大型软件系统运行得更可靠,扩展性更好,能更有效地利用资源。但是,SRE并不是无止境地追求完美∶当一个系统已经"足够可靠"的时候,SRE 通常将精力转而投入到研发新的功能和创造新的产品中。

最后,SRE 的主要工作是运维在分布式集群管理系统上运行的具体业务服务(service)。不论是遍布全球的存储服务,还是亿万用户赖以工作的 E-mail 服务,还是 Google 最初的 Web搜索服务。SRE 中的"S"最开始指代的就是  的运维服务,因为 SRE 的第一个工作就是维持网站的正常运转。随着时间的推移,SRE 逐渐接管了Google 内部绝大部分产品系统,包括 Google Cloud Platform 这类开发者平台,也包括内部的一些非网站类的基础设施系统,例如 Bigtable。

虽然我们在这里将 SRE 的职位定义得比较宽泛,但是在这样一个互联网业务高速发展的时代,这个职位的出现毫不奇怪。同样,虽然在应用系统运营维护的过程中有数不清的重要环节需要关注,我们最关注的是"可靠性"这一点也不奇怪。在 Web 服务领域里,对服务器端软件的优化和修改是相对可控的,变更管理与生产安全又结合得非常紧密,一种类似于 SRE 的职业早晚会在这个环境下诞生。

虽然 SRE 这个行业是在 Google 内部,从Web 社区中诞生的,但我们认为这个职业对其他团队和组织也有很多值得借鉴的地方。本书是对阐述SRE 发展过程的一次尝试∶我们既希望将这些宝贵经验共享给其他相关行业,也希望能从其他行业中汲取知识,从而更好地定义各种角色和术语。为了这个目的,本书将通用的理论、设计理念和思想,与实际的应用工具介绍等分开。在某些需要结合 Google内部信息讨论主题的时候,我们相信读者可以进行类比,将书中的理念与自己的实际环境相结合,以便得出更为有效的结论。

本书中也包含了一些对 Google 内部生产环境的介绍,将 Google 内部环境与外部常见的开源类软件相对应。这样可以让本书的一些设计理念与实践的结合度更强,应用起来更容易。

最后,我们当然希望社区内出现更多、更可靠的软件系统。我们知道,创业企业甚至中型企业经常对如何应用这些理念和技术感到困惑。可靠性就像安全性,越早关注越好。这就意味着一些小型创业公司,在应付日常面临的种种挑战时,也应该抽出一部分精力来面对可靠性这个话题。这与盖房子有些类似,如果一开始将整个地基打好并保持继续修缮,要比盖好房子之后再重新修改设计要容易得多。本书第4部分着重介绍了 SRE 团队如何进行内部培训、如何加强内部沟通等最佳实践,很多都可以直接拿来应用。

对中型企业来说,企业内部可能已经有这样的一组人在做着与SRE非常类似的工作。这些人可能并不叫 SRE 这个名字,甚至可能没有受到管理层的重视。在这样的企业中,提高可靠性最好的办法往往就是去认可这些人的工作,并配备足够的激励机制。在牛顿被世界正式认可为物理学家之前,他经常被称作是最后的炼金术师。而这些专注于可靠性的工程师们,正如当年的牛顿一样,是一个新时代的开拓者。

如果一定要为 SRE 寻找一个起源的话,谁才能够被称为世界上第一个 SRE呢?

我们选择了Margaret Hamilton,MIT 教授,参与了阿波罗登月计划的软件开发工作。她的工作具有现代 SRE的一切特性。用她自己的话来讲∶"团队文化就是从一切经历中不断学习,包括来自那些我们最意想不到的地方的经历。"

在Apollo7飞船研发期间的某一天,Margaret 带着她的小女儿 Lauren 一起来到公司。在 Margaret 忙着和组员们在大型计算机上运行飞行模拟测试的时候,她的小女儿偷偷地按下了控制台上的 DSKY 键。整个模拟程序出乎意料地崩溃了,导致整个火箭发射程序意外终止。Margaret和组员调试后发现,原来Lauren 意外触发了PO1 这段子程序的执行,导致了整个模拟过程的失败。(该子程序是起飞前调试程序,执行时会删除现存的导航信息,如果在火箭飞行过程中执行这段程序,计算机将无法继续维持火箭航线,后果将是灾难性的。)

凭借着 SRE 的直觉,Margaret 为项目组提交了一个软件改动,申请在飞行程序中增加一项特殊状态检查,以避免飞行员在飞行过程中意外触发 PO1 程序的执行。但不幸的是,NASA管理层认为,这项错误发生的可能性太小,根本不值得为此添加这项修改。于是Margaret 没有能够成功提交这项软件修改。她只能在火箭飞行手册中添加了一段文字,写道∶"在飞行过程中,请勿触发 P01程序。"(当时增加这段文字时,很多 NASA 工程师都认为这很好笑,认为 Margaret 是小题大做,几乎所有人都认为宇航员经过如此长时间的专业训练,是绝对不会犯如此低级的错误的。)

几天后,在 Apollo 8飞船执行下一项飞行任务时。宇航员 Jim Lovell、William Anders 和Frank Borman 三人执行一个长达四天的飞行计划途中,Jim Lovell 意外地触发了P01 程序的执行。更巧的是,当天正好是美国圣诞节,大部分工程师都休假去了。可想而知,当时NASA的一片混乱状态。这次不是演习,而是人命关天的危急时刻,如果不能及时解决,三名宇航员将永远无法安全返回了。所幸,当时 Margaret 的飞行手册更新中恰恰提到了这种情形,并且提供了重新上传数据以及恢复执行的有效办法,在有限的时间内解决了问题,使任务可以继续进行。

Margaret 曾经说过∶"无论对一个软件系统运行原理掌握得多么彻底,也不能阻止人犯意外错误。"在这次危机过后,Margaret 之前提交的修改申请很快就被批准了。

虽然 Apollo 8的事故发生在几十年前,但是工程师们一定不会对此感到陌生,类似的场景总是在不断重演。希望读者以史为鉴,只有靠着对细节的不懈关注,做好充足的灾难预案和准备工作,时刻警惕着,不放过一切机会去避免灾难发生。这就是 SRE 最重要的理念! 欢迎加入 SRE 的大家庭!




上一篇:谷歌SRE运维解密前言
下一篇:谷歌SRE运维解密系统管理员模式
FYIRH

写了 198 篇文章,拥有财富 1122,被 1 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies

成为第一个吐槽的人

手机版|小黑屋|最新100贴|论坛版块|ITIL先锋论坛 |粤ICP备11099876号|网站地图
Powered by Discuz! X3.4 Licensed  © 2001-2017 Comsenz Inc.
返回顶部