运营一个成功的网站需要运营(ops)和开发人员(devs)的合作,因此需要“ devops ”一词。当发生冲突,对抗或不和谐时,该网站将遭受损失。仅仅告诉人们“相处”是无效的。真正的合作是提供支持和鼓励合作的结构的结果。

这样的冲突与不和谐领域通常涉及紧急呼叫升级。监视系统会向操作人员发出警告,指出存在问题或问题不断加剧,可能会导致中断。无论白天或黑夜的时间,操作中“待命”的人都必须处理该问题或将该问题上报给开发人员。

存在潜在的冲突。太多的升级使开发人员不堪重负。不和谐之处始于诸如“我只是简单地解决了一些简单的问题!这些人为什么不能做他们的工作?”

行动变得防御。“我应该怎么知道?” 或者,“我刚刚问了一个问题,现在他们对此很讨厌!”

不和谐也可以在操作中开始。“太棒了!开发人员的另一个惊喜!”

您不能强迫人们进行合作,但是可以设置结构和滑行路径来创建合作环境。

动态运行手册反馈循环就是这种范例之一。

动态Runbook反馈循环

Runbook是用于在诸如从监视系统接收警报之类的情况下如何响应的一组过程。反馈循环的目的是创建一种机制,由主题专家创建运行手册,但开发人员和操作人员均有权以减少升级次数和改善合作的方式对其进行改进。

此过程的目标是在编写文档时建立工作量与价值之间的适当平衡。有人为一个简单的问题写100页的论文是浪费时间的。但是过于简短的Runbook并没有用。这种范式导致正确的平衡。一本手册的大小以原始作者认为合适的大小为前提,但要随着练习的进行而发展到合适的大小。很少或永远不需要的运行手册将花费较少的精力,并且经常更新,优化了常用的运行手册,并可能将其转换为自动响应。

与此形成鲜明对比的是,组织在没有直接参与人员的投入的情况下以“较高”的价格创建运行手册。通常,这些更改不能更改,或者更改需要繁重的过程,无法进行任何改进。

写下来

分发团队知识的最简单方法是拥有良好的文档,让任何遇到不熟悉的问题的人都可以按照经过测试的流程来解决。这就是Runbook应该是的。 

我们的首选格式是项目符号列表,操作人员可以使用它们来解决警报。当警报到达时,ops将遵循操作手册中的指示。如果我们到达项目符号列表的末尾,但问题仍未解决,那么操作会升级到开发人员。 

显然,组织的开发人员需要编写文档。但是,通常情况下,文档被分配为低优先级,并被推后推,以便发布新产品,功能升级以及其他被认为是关键任务的工作。他们从来没有绕过它。管理部门需要将运行手册的创建作为项目的一部分。

开发人员并不总是对编写感到满意。凝视空白页可能会令人生畏。要克服空白页综合症,请给他们一个模板。甚至没有您要他们写文件的感觉。您只希望他们填写此表格。如果您使模板具有一系列项目符号,每个项目都是处理特定警报的过程,则完成文档几乎变得很简单。这里的基本文档是如何处理每个警报。

为了激励开发人员,请提醒他们,花更多的时间编写Runbook,问题升级到他们的可能性就越小。每家公司都希望减少升级,特别是必须在下班时间提出这些升级的开发人员,而达到目标的途径是通过文档。 

此过程的另一端-警报-应通过在警报文本中包含运行手册URL来强化任何警报在运行手册中都有相应过程的想法。这增加了遵守程序的可能性。

将反馈引导到更好的运行手册中

这是反馈循环开始的地方。 

在某个时候,操作人员将收到警报,该警报没有足够的文档记录,需要上报给开发人员。一旦您完成了运行手册的每一个步骤并用尽了所有想法,就该与编写代码的人进行交流了。 

这是反馈的第一点:运维工程师读取运行手册并尝试实施其中记录的过程。开发人员可能已记录了所有警报,但这就是橡胶撞到路面的地方。如果一本运行手册说不能解决问题,则操作人员应立即更正它或至少找出问题。当操作人员升格为开发人员时,这就是反馈循环的开始。 

如果问题确实升级了,那应该触发对文档的更新。无论是运维工程师添加他们不确定的内容,触发升级的用例,还是开发人员增加项目符号列表,最终结果都使操作更加自给自足并减少了未来的升级。也许您聪明的操作工程师编写了一个Shell脚本,将十个项目符号捆绑到一个命令中。编辑运行手册并包含它。 

但是,有时您会遇到未知或无法预测的问题。在以前的公司中,我得到的一本Runbook只是其中一个项目符号:“这绝不应该发生。如果可以,请致电开发人员。” 我与开发人员进行了交谈,并且没有指责他们懒惰,而是问这是否是他们可以做的最好的Runbook条目?原来是!他们正在监视一个永远不应该发生的断言,但是,如果确实发生了,他们想知道。在这种情况下,只能在第一次发生修复程序后才能确定修复程序。 

消除减速带对修复和更新运行手册很重要。管理层应营造一种文化,期望每个人都受到鼓励,并鼓励每个人实时,而不是在项目结束时进行频繁的编辑。我建议操作工程师再走一步。阅读运行手册时,请在编辑模式下进行。它消除了拖延更新的诱惑。您可能会想,“我正在解决生产中的问题,我稍后会再编辑。” 不,你永远不会回来。以后再也没有了。如果您处于编辑模式,则可以修复该逗号,将其粘贴到更新的命令中,或者至少记下一些需要改进的地方。 

如果某个步骤不起作用或您不确定该怎么做,请仍然进行编辑。这些都是活动文档,因此并非每次编辑都必须是完美的。在给自己或开发人员的注释中:“最后的陈述令人困惑”或“第三个项目符号不起作用”。至少看到这个的下一个人在到达第3个项目符号时会知道要小心。找出问题总比保持沉默好。

反馈循环使开发人员可以控制他们升级的频率。如果开发人员觉得自己被提升了太多,那么医生可以自愈。开发人员可以通过改进文档来减少将来的升级。要么添加那些使操作无法打扰您的晚餐的程序,要么添加故意的升级电话。 

反馈循环使操作充满信心地升级,而不会觉得自己正在na或放弃得太早。由于担心会造成“哭狼来了”的情况,或者担心不知道如何处理情况,他们会显得愚蠢,因此,行动可能会犹豫不决地升级问题。取而代之的是,运营可以“展示其功课”以证明其升级。当操作人员打给您的电话可以清楚地表明他们遵循书面程序和每个步骤的结果时,很难打扰您的晚餐被打断。

这种反馈循环的好处在于,它可以为您提供与过程所需一样多或少的文档,并根据需要提供尽可能多或少的升级。它使开发人员能够解决越来越多的升级问题。

分享,不要成群

每个人都应该建立一个共享信息的组织,这种共享是值得奖励的。

我曾经在一家庆祝一个人的公司工作,因为他们最擅长处理各种紧急情况。事后看来,这是一个危险信号。为什么一个人比其他人好得多?在其他人待命的几周内,我们可以提供糟糕的服务吗?我从那次经验中学到了东西。  

我现在更喜欢庆祝分享知识的人们,以便每个人都擅长值班。我们应该向拥有更多经验的人致敬,但要以能够使每个人都变得更好的方式来庆祝分享知识的人们。这包括从一对一的教学,回答有关Stack Overflow的问题到编写运行手册的所有内容。做到这一点的人,无论轮到谁来携带寻呼机,都可以实现卓越的表现。

我们可以根据功率动态来重新构造它。维持公司权力和影响力的老派方式是成群结队地提供信息。我记得在以前的公司里欣赏过一个人,因为他们掌握了什么信息。需要完成[插入技术任务]吗?他们是唯一知道如何做的人。拜访他们的办公室。表示敬意。向他们更高的心意俯伏。如果他们认为您是值得的,他们将为您完成任务。如果您想要一家平稳运营的公司,请将这种有害的态度抛入历史的垃圾箱。

新方法则相反。力量来自于您的付出。我们敬佩分享知识的人:教人如何做事而不是为他们做事的人;持续记录文档,而不是在项目结束时;他们在做每件事时都非常慷慨。它们之所以强大,是因为每个人都指向他们并说:“那是使我成功的人!”

易于转移的知识

在Stack Overflow的Teams实例中,我们有一个集合,其中包含我们所有的运行手册和相关过程。我们敦促所有开发人员在文档中使用此反馈过程。这种格式(任何人都可以评论或编辑的文章和问题)使反馈变得容易。最常用的运行手册经过大量编辑和完善。较新编辑的Runbook易于识别和更新。努力程度反映了需求。

然后便是连锁反应,即易于获得经过现场测试的知识所带来的额外效率。运行手册中提到的技术和技能会在为新的运营人员撰写招聘广告时通知我们。一旦被雇用,运行手册就可以用作培训工具。新雇用的操作人员可以浏览每本工作手册,也可以将这些工作手册用作自学助手。一旦他们检查了所有运行手册,便可以随时待命。 

所有这些反馈循环的关键在于,开发人员,SRE和新员工每个人都可以轻松提出问题,提出问题并提供更好的解决方案建议。有时,被视为知识不足的焦虑会阻止人们进入并发表评论。您可以通过在每个运行手册中显式地提供问题空间来缓解这种情况。更好的是,您可以使用像Stack Overflow for Teams这样的平台,该平台旨在从问题和答案中收集关键业务信息。 

良好的反馈循环并不能解决通话过程中的所有问题。但是,从调试在生产中一直出现的问题到雇用,培训和入职,这将使其变得更加顺畅。如果做得好,这是通过小的,根深蒂固的流程来改善组织的非常有效的方法。