运维全球最大游戏网站过程中积累的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 条.
• 随后按照问题类型进行分类.
• 接下来仔细查看每类问题,并总结了解决不同问题,或对问题进行升级上报之前所需执行的步骤.

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!