作者

IanMiell

翻译

大愚若智

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

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

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

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

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

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

流程

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

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

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

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

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

过程–工具的选择

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

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

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

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

文档

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

关于文档也足够写本书了，因为许多人

转载请注明:http://www.aideyishus.com/lkzp/495.html