也许是时候停止编写详细的操作手册了-Toy模板网

这篇具有很好参考价值的文章主要介绍了也许是时候停止编写详细的操作手册了。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

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

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

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

确保每一像问题都有清晰的操作手册
确保每个人都接受过如何根据手册操作的培训

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

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

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

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

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

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

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

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

手册不是了解系统的一种方式，而是行动的号召。如果你在手册的某个页面上没有采取行动，那就把它删掉。
通过降低阈值、引入产品限制、修复bug、自动处理问题，通过这些方式避免对已知问题的支持。
如果需要覆盖缺乏轮值支持的团队，可以修改非工作时间的支持容量，同时团队在工作时也应该做出更快的反应，可以将这一点编入规范。
PM应该知道支持团队容量并进行优先级排序。
管理者应该参与轮换支持工作。

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

- END -

本文由 mdnice 多平台发布文章来源地址https://www.toymoban.com/news/detail-822244.html

到了这里，关于也许是时候停止编写详细的操作手册了的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！