原文：
Things I Learned Managing Site Reliability for Some of the World’s Busiest Gambling Sites
https://zwischenzugs.wordpres...
多年来我为许多世界最繁忙的赌博网站管理三线站点的可靠性运维，为一个小有名气的公司构建和运行许多业务的核心后端在线软件，每个业务的峰值都有千万英镑每小时。几年前我就离职了，所以现在是一个回顾我在其中学到了什么的好时机。
在许多方面，我们做的跟现在叫SRE的很详细）（我会叫我们SRE人，但在那时没有这个叫法）。我们接电话，需要处理故障，对重构提出意见，为开发者和客户团队提供高可用建议，处理扩容和紧急情况，运行监控系统等等。
我加入时的团队有5个工程师（都是前开发者和技术lead），后来我离开时发展到约50人，在许多地点都有人。
我会重点关注流程与文档，尽管我不认为他们说的足够有用但我当时确实读了他们。
如果你想更详细的了解Google SRE （https://landing.google.com/sr...） 书籍有很不错的内容。
流程
流程是操作和扩展SRE操作的核心。它是我们归档的核心内容。当我加入团队时，习惯不咋样 - 有一个工单系统，但日志处理方式很不常见（‘站点挂了。修复，关闭’）。
一个SRE操作基本跟工厂流水线一样，并需要依照标准执行。你不会有一个计划外的工厂流程来处理货物的移动，同理在一个知识敏感的SRE操作上你不可能没有一个流程来处理知识的流动。
我听过对流程一个最常见的反对意见是‘它扼杀了创造力’。实际上，有效的流程（烂流程和差的实现能把这一切搞糟！）能清理你的脑子并让创造性思维出现。
这个领域有本很不错的书‘The Checklist Manifesto’ (http://atulgawande.com/book/t... ),鼓励我们做的很多变动，并在我们组里被广泛阅读。 它列举了航空工业的流程处理方式， 通过日常操作的心理自动化，激发了在高压情况下不可思议的创造性。甚至有一部电影（萨利机长）讲述了事故中飞行员(http://www.airspacemag.com/as... )在如此高压的情况下进行创造性的快速思考和控制。事实上，我们自己使用了一套类似的流程：在紧急状况下，一个有经验的工程师努力找解决方案，一个相对初级的工程师则跟进checklist清单。
另一个对流程的非议是它会影响有效的工作和协作。如果把它当作一个自身存在的实体而不是一个生物实体，那倒有可能。我唯一可以捍卫它的就是文化。稍后再说。
流程 - 工具
第一个把事情作对的方式就是工单系统。与监控方案一样，人们痴迷于哪个工单系统是最好的。那就错了。对于工单系统人们会最终会因为简单而选择熟悉的。工单系统只有在驱动或鼓励使用坏流程是才是不好的。什么是坏流程取决于你的业务上的限制。
还有一个重要的点是你需要一个可靠的工单系统来支持你的流程而不是被其他方式绕过。
举个例子。在我任职期间我们从RT迁移到JIRA。 JIRA提供了很多RT没有的有点，我通常会推荐JIRA作为协作工具。我们在迁移时遇到的最大问题在于一些RT功能的缺失，这个功能对我们很重要。RT可以让我们获得工单的实时更新，这意味着在事故的协作上我们近乎在聊天和工单之间。这个记录在事后回顾过程中很重要。在RT中我们可以隐藏来自客户的条目，这个功能一样不能失去。我们已经解决了这个问题，但这些事情很重要，因为它们已经烙印在我们的流程和文化上。
在选择和切换工单系统是，仔细想想哪些操作是真正重要的，而不是看到在特性列表上的内容。真正对你重要的不是它看起来多好（认真的说，你的客户会更加重视你的品牌，而你的品牌可能是一个好的设计），而是有多么强大的报表工具。
文档
在流程之后，文档是最重要的东西，这两者密切相关。
有一本关于文档的书，但是又一次，人们关注了错的东西。要理解文档是跟其他任何资产一样的东西。像任何商业资产一样，文档：
如果被好好维护，会在后面的许多时间得到投资回报
需要投入精力维护（像工厂的基础结构）
如果过期了，也需要花钱（跟过时库存一样）
如果质量很差，或者不好用，就变成了债务，而不是资产
但这没什么争议 - 基本没有人不同意文档是有用的主意。问题是：你应该怎么做？
文档 - 目前的情况
我们现在处于一个文档对我们无用的情况中（例如开发者说：‘这里不太可能，所以一个网络分区情况没有被处理’。然后，想想发生了什么！这就是他们将要在文档上写的东西 ），或者我们简单的依赖一个以前的文档（这次我们写了一些东西）去研究下一次遇到同样的事情我们该怎么做。
这让我们很诅丧，在我们负责文档前我们花了大量时间抱怨为什么文档没来找我们。
文档 - 我做了什么
这是我做的。
我花了两年时间梳理了优先级高的事故（如已经被触发过的 - 或将要被处罚的 - 超时的电话），并把它们列出来。有大约1700例。
然后我把它们按类型整理。
然后我过一遍每种类型的问题，整理解决需要步骤，或需要升级需要的步骤
这花费了我七个月的全职时间。我是一个高级雇员，我花着公司的钱坐在那写字。我有个好老板，我从来没有被质疑这个时间用的值不值。我被充分信任（又一次，文化！）我得说再前四个月看不到任何这个工作的成效。我记得这四个月让人困惑，我没有在做日常运维工作，这到底是不是在浪费我的时间和工资并导致一个尴尬的失败。
为什么没有放弃呢？有几个原因。这很重要，我们以前从来没这样做过，所以我需要知道这样做是对的。我明确知道需要什么，所以我知道我可以把它写出来，并在最后会对我很有用。我是一个有相关经验的作者（艺术毕业，前记者），所以我想那对我写出好东西也有帮助。
根据ITIL我们叫这些为‘故障模型’但我们也叫它‘run books’‘crib sheets’，不管怎么样，这都没关系。重要的东西是：
他们很容易查找/搜索
很容易确定你得到了匹配的东西
他们没有副本
他们值得信赖
我们用文本编写这些文档并将其放在工单系统中，一个独立的JIRA项目。
文档团队发现了这件事并尝试让我们使用一个内部wiki来做这件事。我们拒绝了，这很重要，文档系统与工单系统的整合意味着搜索和更新文档不会阻抗不匹配。并且由于是简单文本，它很快，方便更新，并很整齐。我们拒绝了损害我们正在做的事情的流程。