[关闭]
@liuhui0803 2016-08-12T01:21:52.000000Z 字数 7120 阅读 2367

谷歌如何通过全球级工程打造全球级基础架构

Google DevOps


此处输入图片的描述

谷歌如何确保自己的服务连续运行,并且看起来似乎永远不会出错?如果你也纳闷过这个问题,谷歌存储SRE总监Melissa BindeGCP NEXT 2016活动中通过一场名为谷歌如何通过全球级工程打造全球级基础架构的演讲向我们揭示了其中的诀窍。

Melissa的演讲虽然简短但却充满智慧和干货,让人觉得如果自己的服务停机了肯定会想要向Melissa寻求帮助。

哦,那么SRE是什么?SRE代表Site Reliability Engineering(站点可靠性工程),不过具体的定义似乎有些难以理解,这种问题的答案有些类似于当你询问“道教”的定义时获得的那种答案。SRE更像是一种过程而非一种具体的实体,谷歌副总裁Ben Sloss对SRE的定义是:

当软件工程师需要承担所谓的“运维”这项任务后所发生的事。

先好好想想这句话吧。

抛开别的不谈,有一件事是很明确的:SRE是生产任务的守护者,SRE是客户体验的守护者,无论对谷歌或GCP均是如此。

我对此次演讲的一些重点摘录如下:

这次演讲还涉及其他一些有趣的话题,例如:SRE的组织结构是如何安排的?如何招聘专注于生产任务、确保生产系统流畅运行的开发者?如何让谷歌内部重视这个团队的价值?如何帮助团队更好地通过沟通和数据来解决分歧,而不是通过各种主张或是权利的攫取?

一起来看看吧。谷歌是这样通过全球级工程打造全球级基础架构的......

维持平衡:持续运行时间与功能,动机的对立造成破坏性后果

站点连续运行时间可让系统管理员获益。站点连续运行时可以获得源源不断的访客,并能通过他们赚钱。

新功能可以让开发者获益。发布新功能可以吸引访客,并能通过他们赚钱。

生产冻结(Production freeze)其实是指新功能的冻结,通常可对应至连续运行时间的延长。

开发者和系统管理员之间存在与生俱来的紧张关系。开发者可从新功能的发布中获益,系统管理员可从连续运行时间中获益。

因此系统管理员阻止新功能发布可获得回报,而开发者如果突破系统管理员的阻止将能获得回报。

开发者会通过一种叫做Beta(测试)的方式让新功能尽早发布。

系统管理员会通过一种叫做发布审核(Launch review)的方式减缓新功能发布速度。

团队成员每天全部时间都用于这种相互“斗争”,因此你会面临激增的故障、风险、混乱,以及无序。

你需要的是在这一过程中为大家指引明确的方向,为这种情况制定规则,让团队成员在统一的目标下相互合作。

通过DevOps这种方式可以让开发者和运维人员顺利合作。问题在于不同目标下DevOps的含义也不同。对比来看,SRE(Site Reliability Engineering)的定义就很明确了。

SRE:当软件工程师需要承担所谓的“运维”这项任务后所发生的事 -- Ben Sloss,谷歌副总裁

假设谷歌在网络、计算、存储等基础架构方面有1000名SRE,其中有多少负责云服务?

技能:SRE是不同领域的多面手

这一节的标题是我自己总结的。具备娴熟技能的SRE都是精英。他们全心全意从事着一种近乎神秘的工作:生产。

就算从事相同岗位,SRE也要具备比开发者更全面的技能:

SRE必须具备与开发者相同的软件技能,这一点与应用领域不同。

当面向开发和面向生产的观点结合在一起之后,将获得更为强大的设计。

SRE所提供的价值可以通过“接手”(OnBoarding)过程的例子了解,当团队的项目交给SRE负责时需要进行这样的接手过程。在对团队的软件进行评估时发现:

组织:告诉开发者运维工作不是堆积出来的

运维工作不是堆积出来的,系统应该围绕此目标予以设计,只有让开发者也涉足运维工作,他们才能对此更关心。

为SRE提供开发预算。如果某个系统的运营开销远超过开发开销,就无法推进更多功能发布。

SRE使用了一套截然不同的指挥链。他们有自己独立于开发副总的副总裁,这样就可以得到权力和能力。当生产任务需要他们拒绝时,他们就有了说不的权力。很多整天因为寻呼疲于奔命的人并没有这种权力。

当开发者希望加入SRE运维某个指定项目时,SRE并不一定要接受。SRE可以说某个服务还不够重要,继续由你自己搞定吧。

SRE是稀缺资源。谷歌也不是每个团队都有SRE。云团队有,但其他团队未必有,并且就算云团队也不是每个小服务都有,只有一些重要服务有SRE。

环境:怎样让生产团队中的开发者感到开心?

至少要有50%的工作属于项目工作。不是指待命、处理工单,或开会,而是实实在在的项目工作。

如果项目工作实在太多,或者由开发者向SRE提供帮助,或者让开发团队参与到额外的工作流中。

项目工作到底是什么?

SRE是志愿军,他们行事不需要征募。

团队是流动的。不断有人加入或退出团队,分享着自己的经验和观点。

预算:想怎么花就怎么花的误差预算

如果你的可用性有三个9,而目标并不需要你实现四个9,你就获得了0.1%的误差预算,好好利用吧。

如果你想更快速推出新功能借此让GCP变得更好,在误差预算花光之前大胆放手干吧。

如果你就是不喜欢进行全面的测试,就是喜欢自己的软件频繁出错并不断回滚,你也可以选择这样做,但你的误差预算可能很快就会花光,到时候就没法继续发布新的软件了。

误差预算以季度为周期。

同时还有一个安全阀:三颗银子弹。

每个服务都有自己的误差预算。因此如果有多个开发团队负责同一个服务,他们需要共享这些预算。

脱手。如果开发者和SRE尽一切努力也没能达成共识,SRE可以终止与该开发团队的合作。

SRE是生产任务的守护者,SRE是客户体验的守护者,无论对谷歌或GCP均是如此。

SRE的支持是全方位的

交流和磋商。与开发者交流,开展各种白板讨论。

共同设计。与开发者一起完成设计工作。

全面拥有。完全拥有服务的方方面面:容量、供应、寻呼机。

寻呼机是保障大家努力工作的一种方法,但这并不是SRE的主要目的。

什么让这一切顺利实现?文化和流程

谷歌平时也会进行培训和并要随时待命。

谷歌还有一个名为厄运转轮(Wheel of Misfortune)的流程,这是一种角色扮演游戏。

事件管理

场景:你需要为Gmail服务随时待命,并接到一个工单称用户可以看到其他用户的邮件。你打算怎么办?关闭Gmail?

待命人员可以用一切手段保护用户、信息,以及谷歌自身。如果为了保护谷歌而有必要关闭Gmail甚至关闭谷歌的整个系统,SRE完全可以这样做并得到副总裁以及资深副总裁的支持。

目标在于立刻还原服务,排错工作可以稍后再做。

到底该责怪谁?

当“新手开发者”发布代码并导致整个谷歌的服务彻底停摆三小时,这时候该责怪谁?a) 新手开发者,b) 代码审核者,c) 测试者不全面(甚至完全被忽略)的测试工作,d) 代码缺乏妥善的金丝雀过程,e) 缺乏快速回滚工具。

无可指责的事后反思

关键在于避免养成相互指责的“文化”。

研究显示大部分事件都是人为错误造成的。

解决事件之前最好能彻底了解实际情况。两眼一抹黑是最佳解决方式吗?仔细调查每个事件,尽量找出责任人吧。

人们都善于隐藏,会尽量不留下痕迹,并会尽量确保别人无法了解到底发生了什么。试图找出责任人的做法只能让你了解实情的过程变得更困难。

谷歌内部“惹乱子”的人必须写事后报告。这些报告不需要指责或埋怨任何人,而是为了避免以后再犯类似的错误。任何对故障有责任的人都会尽可能诚实地写出自己到底是如何掉链子的。

造成网站故障的人还可以得到奖金,因为他们很爽快地承认了自己的错误。他们会通过IRC联系并进行回滚,并因为勇敢承担和快速处理而获得奖励。

无可指责并不意味着不需要知道问题到底是谁造成的,以及具体细节如何。只是说我们不会将人本身看作造成故障的原因。任何人都不会因为这种问题被解雇。

纵深防御

不要厌倦寻呼的哲学

团队成员最喜欢看到怎样的寻呼信息?新奇的,有趣的。

寻呼会让你知道问题的解决过程有多无聊。你应该开发专门解决各种问题的机器人。

谷歌开发了各种机器人,他们不喜欢无聊的工作。

如果你能把修复问题的全部过程都写出来,那么你应该就能写出可以自动修复问题的自动化程序。

凡是机器人可以帮你搞定的事,就不要自己动手。

通过创建各种可以自动修复的机器人,以后就只会因为出现的新问题收到寻呼,你也就不会感觉无聊了。就算有经验的工程师也有可能每次接到寻呼信息都会看到一些新奇的问题。

这是人生哲学方面的一次根本性改变。如果你每次遇到的都是新出现的问题,很少有什么问题会重复出现,这意味着在调试系统时就不能总躺在以往的经验上“吃老本”。

有关更强大调试工具的需求

如果你遇到的所有问题都是全新的,这意味着你可能需要更强大的调试工具才能找出问题所在。

文本日志算不得调试工具。如果你不确定到底要找什么,在日志文件中查找所存在的模式,这种标准化的调试方法将无法满足你对规模化的要求。以GCP这种规模的平台来说,你觉得需要查看多少日志才能找到造成问题的根源?

为了尽可能快速地还原服务,谷歌会大量运用各种可视化工具对不熟悉的问题进行排错。

图形化工具:Graphite、InfluxDB + Grafana、OpenTSDB。

通过创建框架让开发者可以更轻松地将自己的代码纳入监控框架。

为监控数据的存储提供了极大容量的存储空间。

事件图表 – 非常适用于相互关联的事件。

可视化进程追踪 – 有时候你需要深入到进程层面才能找出造成性能问题的原因。

网络的流动和容量

日志文件 – 如果其他手段都于事无补的话

堆栈驱动的错误报告

如果你想看看此类工具的示例,SRE提供了Google Stackdriver Error Reporting

整个计划的目标远不止如此。谷歌内部为云客户提供了一系列工具。

相关文章

作者Todd Hoff阅读英文原文How Does Google Do Planet-Scale Engineering For A Planet-Scale Infrastructure?

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注