运维全球最大游戏网站过程中积累的SRE经验

《运维全球最大游戏网站过程中积累的SRE经验》要点：
本文介绍了运维全球最大游戏网站过程中积累的SRE经验，希望对您有用。如果有疑问，可以联系我们。

作者 |：Ian Miell

翻译：大愚若智

作者 Ian Miell 通过本文探讨了自己在全球最大在线游戏网站的站点可靠性运维工作中积累的经验.本文最初发布于 Ian Miell 的博客,经原作者授权由 InfoQ 中文站翻译并分享.

概述

多年来,我负责管理着很多全球最大在线游戏网站的站点可靠性运维工作,通过一家不怎么知名的公司构建并运行着很多公司的后端在线软件,这些公司的业务在峰值期间可以轻松产生每小时数千万英镑的收入.几年前我从这家公司离职了,现在可以谈谈我在这段工作中积累的经验.

从很多方面来看,我们的工作类似于一种 SRE 职能(就把我们也称作 SRE 吧,不过当时并没有这样的称呼).我们需要随时待命,需要对各种事件做出响应,需要对重构提供建议,需要为开发者和客户团队提供详细的反馈,需要管理升级上报的事件和紧急情况,需要运行监视系统,等等等等.

我所在团队有大约 5 名工程师(都曾任开发者和技术领导者角色),但在我离开时,已经增长为一个 50 人左右的跨地域团队,大家在不同领域有着丰富的经验.

本文将重点介绍我们的流程和文档,因为我觉得人们对这些内容的效用谈的还不够深入.

如果你还想进一步了解这个概念,建议阅读 Google 的 SRE 手册.

流程

流程对 SRE 运维的顺利进行和升级上报至关重要,这是我们所有成果的核心.在我加入那个团队时,当时大家的习惯很糟糕：虽然有一个工单系统,但对于解决方法的“一句话记录”情况极为常见(“网站宕机,修复,结单”).

SRE 运维基本上类似于一种处理信息,并酌情执行操作的工厂.工厂的正常运转需要通过一定的流程实现货物的运转,同理,知识密集型的 SRE 运维也需要妥善处理知识的流转.

在流程方面,我听到最多的一个异议是这种做法会“抑制创新”.实际上,有效的流程可以帮助我们通过更清晰的思路实现创新(但未能妥善实现的糟糕流程会搞砸一切!).

关于这个主题有一本很不错的书：清单革命,我们工作中的很多改进都受到这本书的启发,团队成员都曾认真拜读.本书引用了航空业实现这一流程的方法作为范例,航空业曾通过智能的自动化例行操作在巨大的压力下实现了非凡创新.书中讨论过的一个事件甚至被拍成了电影,飞行员称这主要归功于 检查清单机制和例行操作 帮助自己通过快速思考实现了创新,并在面临巨大压力的情况下重新获得了控制能力.实际上,我们自己也使用了一种类似的流程：紧急情况下,由有经验的工程师负责深入研究查找解决方案,与此同时,资历浅的工程师则按照检查清单进行逐项排查.

关于流程,还有另外一种看法认为,流程会抑制工作和协作的效用.如果将流程视作一种因其本身的存在,而非其他实际效果就认为合理的实体,这种看法当然是没错的.唯一能够防范这种错误认识的恰恰是企业文化.下文还将详细探讨.

过程 – 工具的选择

先需要准备一个合适的工单系统.与监视解决方案类似,很多人往往纠结于到底哪个工单系统才是最好的.这种想法本身就是错误的.在选择工单系统时,最终的选择将更加侧重于熟悉与否.如果所选工单系统会产生或促进不好的流程,那么这样的系统无疑是最糟糕的.但糟糕的流程到底什么样,这取决于业务本身.

更重要的是选择一个功能稳定,并且能比其他选项更好地为流程提供支持的工单系统.

这方面有个例子.在我任职期间,我们从 RT 更换为 JIRA.相比 RT,JIRA 提供了更多优势,通常我都会建议选择 JIRA 作为协作工具.然而我们更换后遇到的最大问题在于,JIRA 缺少我们在 RT 中构建的某些功能,而这些功能是我们必须的.RT 可以让我们实时更新工单,这意味着我们可以在聊天和分配工单的过程中直接针对具体事件进行协作.相关记录对事后审查工作非常重要.RT 还使得我们可以将某些内容对客户隐藏起来,这样的功能也是我们很难舍弃的.虽然克服了这些问题,但这些功能依然非常重要,因为它们已经融入到我们的流程和文化中.

在选择或更换工单系统时,必须考虑对运维来说什么才是真正重要的,而不要考虑那种在功能清单上看起来很漂亮的具体功能.对你而言,到底什么最重要,这取决于各种因素,从看起来是否漂亮(说真的,如果你的品牌更有设计感,客户也会更重视你)到报表功能是否足够强大,各种原因不一而同.

文档

除了流程,文档也是很重要的东西,这两者是密切相关的.

关于文档也足够写本书了,因为许多人关注了错误的方向.有一个重点需要明确：和其他内容一样,文档本身也是一种资产.与任何业务资产类似,文档：

• 若能加以擅用,将提供多倍的投资回报
• 需要不断的投入以进行维护(和设施或工厂一样)
• 过时的文档如果继续使用将产生更高成本(就像过时的库存清单)
• 如果质量或易用性不佳,将成为一种负担而非资产

这些特点不存在任何争议,很少有人会觉得足够好的文档不能提供巨大的帮助.重点在于：文档工作该如何进行?

文档 – 我们原本处于怎样的情况中

我们原本处于这样的一种情况：我们所获得的文档没什么用(例如开发人员提供的文档说：“网络分区并未覆盖这里,因为这基本不可能实现”.你猜后来怎样!而就算这样的文档他们也写得不情不愿……),或者我们只能依赖以前记录下来的调查结果(这次我们终于详细记录了一切信息),借此确定下次遇到类似的问题之后该如何解决.

这种情况让所有人感觉沮丧,在决定自行撰写相关文档前,我们还花了大量时间抱怨为啥没有田螺姑娘来帮助我们.

文档 – 我们做了什么

我们做了这些事.

• 我花了两年时间对事件划分优先级(例如所触发的事件,或本应触发的事件,或下班时间的工作电话)并进行了仔细研究.各种事件的总数超过 1700 条.
• 随后按照问题类型进行分类.
• 接下来仔细查看每类问题,并总结了解决不同问题,或对问题进行升级上报之前所需执行的步骤.

上述活动花了我七个月的全职工作时间.我是资深员工,由我坐在那里写这些东西,耗费了公司不小的成本.由于得到了老板的支持,他从未质疑过这样做是否值得.他很信任我(依然是文化的作用!).另外我得说,完成这一切四个月后,我的努力才获得了回报.现在想起来,那四个月时间真是不堪回首,我原本需要用于运维的精力都被花在别人认为无意义的事情上,无谓地浪费了雇主发给我的工资,还遭遇了尴尬的失败.

为什么不交给初级员工来做?有几个原因.这件事太重要了,以前从未做过,因此我需要自行确认具体做法是妥善无误的.我完全清楚自己需要什么,因此亲自做这事至少可以确保能得到对我来说最为有用的结果.我本人也是一个有经验的作者(艺术学院毕业,曾担任记者),因此我觉得由自己来写是一种更妥善的做法.

我们按照 ITIL 将其称之为“事件模块”,但其实也可以叫做“运行手册”、“小抄”之类的.名字不重要,重要的是：

• 它们非常易于查找／搜索
• 可以很容易判断它们与自己遇到的情况是否匹配
• 其中不包含重复的内容
• 所有内容都是可信的

我们将这些文档以纯文本形式保存在工单系统一个单独的 JIRA 项目内.

文档团队了解到我们的所作所为,希望通过施压让我们转为使用一个内部维基.他们的决定很快被我们拒绝,原因也很合理：文档与工单系统的共存意味着文档的搜索和更新不会遇到相互矛盾不匹配的情况.纯文本格式的内容可以用非常快速简单的方式更新,并且可以保持一切内容井然有序.他们所要求的流程会让我们当时希望打造的工具夭折,我们自然是拒绝的.

文档和整理工作的关键性

最开始我们为这些事件模块设计了一种架构,那是一种很美观的架构,涵盖了可能出现的所有场景和情况.

但最后发现这完全是浪费时间.最终我们使用的是一种非常愚蠢的结构,其中包含：

• 对问题的描述
• 所需执行的 1-n 步操作
• 进一步／更深入的讨论,以及相关条款

就是这样.希望彻底改进结构的企图完全失败了,也许因为新的结构会让新人感到困惑,会给管理人员造成太多负担,或覆盖面还不够广.一些条款会随着时间的流逝形成与具体任务更匹配的专有架构,新的分类(例如“跳转”条款可以告诉你需要参阅哪些条款)也会随着时间流逝逐渐完善.我们并未提前设计好这些东西,因为我们不知道到底什么是可行的,什么又是不可行的.

如果愿意,可以将其称之为“敏捷文档”,敏捷是目前的热门(以前最热的是 ITIL).当然,重点在于 简化和实用性 胜过其他一切.

会写文档的田螺姑娘并不存在

在文档方面花费那么多时间和精力后,自然而然就得出了这样的结论.

首先,我们不再寄希望于接受其他团队提供的文档.如果他们给代码加了注释,这挺好；如果我们能在维基中找到对自己有帮助的信息,这也挺好.但在接手不同项目时,我们已经不再“要求对方提供文档”,相反我们会安排与负责设计项目,并且有经验的 SRE 约个时间一起讨论.

一般来说(假设没有运维经验的话),开发者往往更关注自己开发的东西及其工作原理,这些东西通常会经历彻底的测试,出错的可能性是最低的.

与之相对的,SRE 最关注弱点,以及可能出错的东西.“如果为网络划分分区会怎样?如果数据库磁盘空间不足会怎样?能否通过日志判断用户为什么没有收到钱?”

随后我们会自行编写自己的文档,并让相关工程师进行签发,这是一种与传统工作流截然不同的方法!他们通常会给出非常有用的意见,并针对整个流程为我们提供更深入的见解.

我们注意到的第二件事是,我们的工程师依然不愿意更新文档,除非是他们自己会用到的文档.然而文档依然需要交给他们处理.领导层只能不断地强调这也是工程师自己的文档,不是世代相传的石碑,如果不进行持续不断的维护,文档很快将变的毫无用处.

这其实是一种文化方面的问题,需要花费很长时间才能解决.解决这个问题还需要能通过流程强制对文档进行修订.

最后我发现,我们的日常工作中约有固定 10% 的工作时间被用来维护和编写文档.在最开始 7 个月的突击之后,这 10% 的时间主要被用于维护文档,而不是继续创建新的内容.

文档 – 收益

文档工作全部完成后,我们所获的的收益远远超过了那 10% 的工作时间.例如：

新员工更易于上手

在实施这样的流程之前,我们不愿意雇佣没经验的人员.但实施之后人员的上手过程更加顺畅了.此外事件发生之后进行的培训也逐渐培养了更多有经验的人员.新员工首先需要帮我们维护文档,这一过程也有助于他们对自己的知识和技能进行查漏补缺.

更好的培训

文档为我们提供了丰富的资源,可以帮助我们确定培训需求.进而我们可以为任何工程师提供完成工作所需掌握的工具和技术.

简化的升级上报流程有助于减少压力

这个收益非常重要.在使用循序渐进的事件模型前,何时进行升级上报是一个压力重重的决策.一些工程师因为过早升级上报而著称,大家都无法自信地确定在非工作时间联系负责的技术主管前是否“漏掉了某些显而易见的状况”.SRE 也经常因为升级上报不够及时而头疼!

事件模型解决了这个问题.很快,负责处理升级上报后问题的技术人员开始首先询问：“你是否已经按照事件模型进行过处理?”如果是,并且存在某些明显的疏忽,那么问题就变的非常明确,可以快速解决.很快,非 SRE 人员在处理过升级上报的问题之后会开始忙着更新和维护文档,进而形成了一种良性循环.

更好的纪律

对于团队来说,文档最明确的价值在于可以帮助团队改进其他方面的纪律.有趣的是,以前 SRE 被誉为“最吵杂”的团队,他们经常会进行各种“争论”,并且整个团队的社交属性十分强.这其实也挺合理,因为我们毕竟需要相互支持着才能搞定各种大型的技术领域,满足通常不具备技术背景的客户预期,而知识和文化的分享很重要.

随着流程的推广,这个团队变的越来越安静,部分是因为有了专门的交流环节,逐渐开始推行远程工作,以及团队逐渐变的国际化,但同时也是因为大部分工作都变成了一种例行任务：遵循事件模型的指导,任务完成后或者有什么不理解的地方时,可以升级上报给更资深的人员.

自动化

通过这种方式对调查过程实现自动化,意味着还可以借助软件对其实现更高程度的自动化.

通过制定指标将不同工单连接到不同的事件模型,这也意味着我们知道需要将自己的精力专注在何处.我们编写了在后台对日志文件进行梳理的脚本,借此更快速简单地找出与代码有关的问题,同时通过自动化方式响应客户的需求(“此问题是应用管理员用户 XXX 所做的某项变更导致的”),此外还采取了一系列其他措施.

在这些自动化机制的支持下,我们基于 Pexpect 为自己构建了一个自动化工具：http://ianmiell.github.io/shutit/,不过这就是另一个故事了.基本上在适应这些后我们养成了持续改进的良性循环.

回归流程本身

准备好所有这些资产后,如何预防这些资源随着时间流逝而贬值?此时流程本身非常重要.

为确保一切可以继续平滑运转,我们制定了两个重要流程：验伤(Triage),以及事后审查.

流程 – 验伤

 

我们有 5%-10% 的时间花在验伤流程中.另外,为了确定最准确的流程,之前已经付出了大量时间,不过这些付出获得了巨大的回报：

将需要采取的操作数量精简为必须的最少步骤

将尽可能多的任务包含在验伤流程中,这种做法对我们有很大的吸引力,但更重要的是确保流程本身的价值而非完整性.任何不常执行的操作通常会被跳过,并从验伤流程中忽略掉.

专注于通过流程节约成本

通过查找重复的内容,找到相关事件模型,更快速回复客户的咨询,并且尽可能早得进行升级上报,这些举措大幅降低了每个工单的成本.这样做还可以避免其他工程师在思考其他问题时被打扰而产生不良后果.这些举措的实际收益很难衡量,但我们可以用更少的人手,更容易地处理更多事件.这些都被高管和客户看在眼里.

将所有工作的详情记录起来也可以帮我们节约时间,(例如)当工程师接到验伤工单后,可以看到在历史事件中搜索的验伤结果,进而找出有待改进的地方.这也意味着可以由更有经验的人员随时审阅验伤流程的质量.

验伤流程的审阅

有经验的人员需要定期审阅验伤流程,以确保流程得以有效地运用.

当我转岗到另一个运维团队(是一个我不太了解的领域)后,通过恰当应用这些技术,我用了大约三天时间就将事件队列中积压的事件减少了一半.验伤流程是现成的,但大家在执行时并未仔细思考或进行有效监管,并且将这些责任交给了一个不能胜任的初级员工.大错特错.验伤流程的执行或监管,必须由具备娴熟经验的人负责,虽然看上去这是一种例行的乏味工作,但其实包含了大量重要决策,必须由经验提供支撑.

没错,我就是新的负责人,我决定将第一周的工作时间用于这种“没技术含量”的验伤任务.毕竟我觉得这个工作还是很重要的.

轮值任务

没人希望长时间负责验伤工作,因此我们采取了每周轮值的做法.借此可以实现一定程度的连续性和一致性,但也可以有效避免工程师反复在相同任务上花费大量时间而抓狂.

流程 – 事后审查

验伤流程相对的是“事后审查”.每个工单都会由有经验的团队成员进行审查,这个过程大约需要占用 5% 的工作时间,但同样是值得的.

为此需要填写一个标准化的表单,如果有任何意见建议,可添加到后续“改进”任务列表中,并划分出优先级.这为我们造成了大量等待解决的技术／流程债务.

文化

上文曾多次提到文化,只要打算进行任何类型的变更,都不得不考虑文化问题,毕竟文化已经根植于一系列概念框架中,而我们的所有行动都需要遵循这些框架的规定.

另外我还提到过,人们通常会纠结于“错误的事情”.我曾多次听说有人专注于工具和技术,而非专注于文化.没错,工具和技术很重要,但如果不能有效运用,所造成的后果甚至会比完全没使用时更糟糕.你也许可以加入全球最棒的高尔夫俱乐部,但你连挥杆都不会,只会打棒球,那么这个俱乐部对你而言有何意义?

文化所需的投入远远超过技术本身(别忘了,单单为了写文档我就花了大半年时间).如果具备合适的文化,人们将能在需要时找到合适的工具和技术.

在决定将时间和金钱花在哪里时,一定要以文化为第一选择.虽然需要耗费大量预算,但可以强有力地剔除“无用”的团队成员,这是我在接管其他团队后做的最棒的事.那人离开后,其他团队成员表现好了很多,不再受到他那过激行为的影响,很多以前做不到的事情都顺利完成了.

我们还用很小的预算构建了一个高效能团队,预算小到什么程度呢,负责招募的人甚至在电话里冲我嚷嚷说我的目标是“不可能”的.但只要专注于恰当的行为,针对找到的人员不吝付出时间,准备好妥善的流程,我们实现了效能的大幅提升,并且形成了一个高忠诚度的团队,开始在公司内部和外部(其实主要还是内部!)实现了更大规模,也更出色的壮举.

办公室政治

简单说说办公室政治.你可能要随时投入“战斗”.很可能你得不到所需的资源,所以搞不定的工作需要适时放弃.

没错,你需要监视解决方案,需要更好的文档,需要训练有素的出色人员,需要更多测试……除非有印钞机,否则不可能得到自己想要的所有东西,因此还是确定最重要的事情,试着优先解决它们吧.如果试图同时在所有方面进行改进,最终很可能会失败.

除了流程和文档,我还曾试着破解“可再现环境”的谜题.最终决定选择 Docker,这是我职业生涯的一次重大转变.我曾在 这里 和 这里 简单探讨了这些问题.

作者：Ian Miell,英文原文：Things I Learned Managing Site Reliability for Some of the World’s Busiest Gambling Siteshttps://zwischenzugs.wordpress.com/2017/04/04/things-i-learned-managing-site-reliability-for-some-of-the-worlds-busiest-gambling-sites/#comment-746

文章来自微信公众号：高效开发运维

转载请注明本页网址：
http://www.vephp.com/jiaocheng/4132.html