也许是时候停止编写详细的操作手册了

详细的操作手册意味着系统缺乏自动化的支持，应该尽量把编写详细手册的精力放在优化系统自动化能力上。原文: Stop Writing Great Runbooks

别再编写细致的手册了，相反，解决生产问题。

当出现生产问题，就会有人需要在线提供帮助。在生产环境中处理问题的常见方法如下:

• 确保每一像问题都有清晰的操作手册

• 确保每个人都接受过如何根据手册操作的培训

操作手册是一组手动任务，支持团队通常遵循"任何告警都应该有手册"之类的东西，操作手册被奉为圣经。

问题是操作手册意味着失败: 无法正确修复问题、无法提供自动化解决方案、无法提供优先级划分。此外，操作手册经常因其清晰和易于使用而受到称赞。实际上，操作手册越清晰、越容易操作，就越不能原谅没有自动化解决方案的问题。

操作手册的第 22 条军规是: 任何容易执行的操作手册都不应该存在。

如果操作手册上说按某个按钮，那就在出问题时自动完成。如果操作手册上说要读取某个图表，然后按下一个按钮，那么当出问题时，就让某些程序自动执行该操作。在支持团队的工作中，应该几乎没有什么是既容易执行又不能自动化的。

那有什么地方需要操作手册吗？

操作手册应该是一种培训，而不应该将手册视为反应性的剧本，好的手册是一种训练，能给你信心和知识，从而在不可预见的生产问题发生时快速有效的解决问题。

这是有道理的。其他需要随时待命的工作，比如医生、消防员、侦探等，在时间紧迫时不会拿出一摞剧本。

最后，有五个关于健康的值班轮转的想法:

• 手册不是了解系统的一种方式，而是行动的号召。如果你在手册的某个页面上没有采取行动，那就把它删掉。

• 通过降低阈值、引入产品限制、修复 bug、自动处理问题，通过这些方式避免对已知问题的支持。

• 如果需要覆盖缺乏轮值支持的团队，可以修改非工作时间的支持容量，同时团队在工作时也应该做出更快的反应，可以将这一点编入规范。

• PM 应该知道支持团队容量并进行优先级排序。

• 管理者应该参与轮换支持工作。

你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。为了方便大家以后能第一时间看到文章，请朋友们关注公众号"DeepNoMind"，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的支持和动力，激励我持续写下去，和大家共同成长进步！