2.1.随叫随到的工程师是防止计划外工作的第一道防线，无论是生产环境问题还是临时支持请求。
2.2.将深度工作与操作分开，使团队的大多数成员能够专注于开发任务。
2.3.随叫随到的工程师只需专注于不可预测的运营挑战和支持任务。
3.1.On-Call 的开发人员根据时间表轮换。
3.1.1.每个合格的开发人员都参与轮换。
3.2.大多数待命人员将时间花在处理临时支持请求上。
3.2.1.错误报告，关于他们团队的软件如何工作以及如何使用的问题。
3.3.可能每个待命人员最终都会遇到运维事件（生产软件的一个关键问题）。
3.3.1.事件是由自动监控系统发出的警报或由支持工程师观察到并报告给值班人员的问题。
3.3.2.待命的开发人员必须对事件进行分类、缓解症状并最终解决事件。
3.4.所有随叫随到的轮换工作都应以交接开始和结束。
4.1.随时回复。
4.1.1.大公司有一个“跟随太阳”的随叫随到的轮换机制，开发人员随着时间的推移轮换到不同的时区。
4.1.2.“随时回复”并不意味着立即放弃您为解决最新问题所做的工作。
4.1.3.对于许多请求，首先确认您已收到询问并回答何时应该能够查看该问题是完全可以的。
4.2.集中。
4.3.确定工作的优先级。
4.3.1.首先处理优先级最高的任务。
4.3.2.当任务完成或被阻止时，您可以从最高优先级到最低优先级工作。
4.3.3.如果您无法判断请求的紧急程度，请询问请求的影响。
4.3.4.P1：严重影响 - 服务在生产中不可用。
4.3.5.P2：高影响 – 服务的使用受到严重影响。
4.3.6.P3：中等影响 - 服务使用部分受损。
4.3.7.P4：低影响 - 服务完全可用。
4.3.8.服务级别指标 （SLI）（如错误率、请求延迟和每秒请求数）是了解应用程序是否正常运行的最简单方法之一。
4.3.9.服务级别目标 （SLO） 定义 SLI 的正常应用程序行为目标。
4.3.10.如果错误率是应用程序的 SLI，则 SLO 可能是小于 0 的请求错误率001%。
4.3.11.服务级别协议 （SLA） 是关于超过 SLO 时会发生什么情况的协议。
4.3.12.了解应用程序的 SLI、SLO 和 SLA，这将为你指出最重要的指标以及 SLO 和 SLA，从而帮助你确定事件的优先级。
4.4.清晰的沟通。
4.4.1.用简洁的句子交流。
4.4.2.快速响应请求。
4.4.2.1.响应并不一定代表解决方案。
4.4.3.状态更新会定期发布。
4.4.3.1.每次更新时，都会提供新的时间估计。
4.5.跟踪您的工作。
4.5.1.记录你在工作中所做的事情。
4.5.2.聊天是一种很好的沟通方式，但聊天记录以后可能很难阅读，因此请确保在任务票证或文档中总结所有内容。
4.5.3.关闭已解决的问题，以便待处理的任务票证不会在待命的看板上留下痕迹，也不会扭曲待命支持系统指标。
4.5.3.1.如果请求者没有响应，假设您将在 24 小时内因缺乏响应而关闭任务票证，然后真正这样做。
4.5.4.始终在笔记中包含时间戳。
5.1.事故处理是值班人员最重要的职责。
5.1.1.第一个目标是减轻问题的影响并恢复服务。
5.1.2.第二个目标是捕获信息，以便以后可以分析问题发生的方式和原因。
5.1.3.第三个目标是确定事故原因，证明是罪魁祸首，并解决根本问题。
5.2.提供支持。
5.2.1.大多数请求是错误报告、有关业务逻辑的问题或有关如何使用软件的技术问题。
5.2.2.支持请求遵循相当标准的流程。
5.3.5个阶段。
5.3.1.分流
5.3.1.1.工程师必须找到问题，确定其严重性，并确定谁可以修复它。
5.3.1.2.识别问题并了解其影响，以便适当地确定其优先级。
5.3.1.3.分流不是证明自己可以解决问题的时候，最有价值的是争取时间。
5.3.1.4.调车也不是排除故障的时候。
5.3.1.4.1.将故障排除留给提出意外事件和解决方案的阶段。5.3.2.协调
5.3.2.1.必须将此问题通知团队（和潜在用户）。
5.3.2.2.大型事件有专门的“作战室”来帮助沟通，这是用于协调事件响应的虚拟或物理空间。
5.3.2.3.所有相关方都加入作战室，以协调的方式做出反应。
5.3.2.4.即使你一个人工作，也要就你的工作进行沟通。
5.3.2.4.1.稍后可能会有人跳进来，发现你的日志是有益的，详细的记录将有助于事后重建时间线。5.3.3.缓解
5.3.3.1.工程师必须尽快解决问题。
5.3.3.2.缓解不是长期的解决方案，你只是想“止血”。
5.3.3.3.应急计划的分阶段目标是减少问题的影响。
5.3.3.3.1.应急计划不是完全解决问题，而是降低其严重性。5.3.3.4.解决问题可能需要花费大量时间，而解决方法计划通常可以快速完成。
5.3.3.5.事件的解决方法通常是将软件版本回滚到“上次已知良好”版本，或将流量从问题中转移出去。
5.3.3.6.快速写下您发现的任何缺陷可以使您更轻松地进行故障排除，并创建新的任务票证以在后续阶段解决这些问题。
5.3.4.分辨率
5.3.4.1.问题缓解后，工程师有一些时间喘口气，深入思考，并解决问题。
5.3.4.2.一旦应急计划到位，事故就不再是紧急情况。
5.3.4.3.使用科学的方法解决技术问题。
5.3.4.4.该测试不是**。
5.3.5.后续行动
5.3.5.1.调查事故的根本原因：为什么会发生。
5.3.5.2.目的是从事故中吸取习的教训，防止事故再次发生。
5.3.5.3.编写一份事后分析文档并对其进行审查，然后开始一项新任务以防止它再次发生。
5.3.5.3.1.描述事件的原因和影响、故障、影响、检测、响应、恢复、时间线、根本原因、经验教训以及所需的纠正措施。
5.3.5.3.2.任何回顾性摘要文档的一个关键部分是根本原因分析 （RCA）。5.3.5.4.使用5个“为什么”进行根本原因分析。
5.3.5.4.1.“5W”只是口口相传的体验，大多数问题需要重复5次才能找到根本原因。
5.3.5.4.2.根本原因分析是一个流行但具有误导性的术语。
5.3.5.4.2.1.事故很少是由单一问题引起的。
5.3.5.4.2.2.在实践中，这 5 个“为什么”可能导致许多不同的原因。
5.3.5.4.2.3.只需记录一切。5.3.5.5.一个好的事后总结也会将“解决问题”与审查会议分开。
5.3.5.6.在事后总结会结束时，必须完成后续任务。
5.3.5.7.旧的回顾性总结文件是很好的习学习材料。
6.1.跳入“救火”模式成为一种条件反射。
6.2.依靠“消防员”是不健康的。
6.3.长期和高风险会导致倦怠。 “消防”工程师也可能在编程或设计工作中“步履蹒跚”，因为他们经常被打断。
6.4.“消防员”的英雄主义也可能导致解决严重潜在问题的工作降级，因为“消防员”总是在一旁修补。