1.UMP监控

• 通过UMP实现3个黄金监控指标（可用率、调用量、TP99）。

需要注意的是，在进行报警配置时，需要结合具体的业务场景和系统特点来进行调整和优化。不同的系统可能存在不同的风险点和瓶颈，因此需要根据实际情况来制定相应的报警策略，以保证系统的稳定性和可靠性。

critical告警方式：咚咚、邮件、即时消息(京ME)、语音可用率：（分钟级）可用率 < 99.9% 连续 3 次超过阈值则报警，且在 3 分钟内报一次警。性能：（分钟级）TP99 >= 200.0ms 连续 3 次超过阈值则报警，且在 3 分钟内只报一次警。调用次数：当方法调用次数在 1 分钟的总和，连续 3 次大于 5000000 则报警，且在 3分钟内只报一次警
warning告警方式：咚咚、邮件、即时消息可用率：（分钟级）可用率 < 99.95% 连续 3 次超过阈值则报警，且在 30 分钟内报一次警。性能：（分钟级）TP99 >= 100.ms 连续 3 次超过阈值则报警，且在 30 分钟内只报一次警。调用次数：当方法调用次数在 1 分钟的总和，连续 3 次大于 2000000 则报警，且在 3 分钟内只报一次警

• 如果UMP是定时任务，最重要的一点就是确定好监控时段。只有正确地配置了监控时段，才能确保UMP在预计时间段内正常执行，这样一旦UMP未能在预计时间段内执行，就会自动触发报警机制，及时发现并解决问题。

2.报警要 快、准、少

3.细节决定成败

1.如果报警信息的响应时间较长，需要检查一下团队的值班响应机制是否正常。需要确保告警信息是否能够有效地传达给正确的人，以便及时解决问题。

2.关于报警信息的日清日结，应该建立相应的处理机制，确保每条报警信息都能得到妥善处理。如果无法做到日清日结，则需要深入分析原因，并采取相应的措施加以改进。

3.在处理报警信息时，需要深入分析其根本原因。只有找到问题的根源，才能从根本上解决问题。

4.如果报警频繁但一直未被处理，便需要认真思考这个报警是否有必要的存在。有时候，一些报警可能是由于误报或者无关紧要的问题引起的，这时候需要对这些报警进行筛选和排除。

5.如果出现问题后发现对应的UMP或其他环节的报警信息未添加，就需要仔细检查是否还有其他核心环节也漏添加了。如果有漏添加的情况，可以采用工具扫描来发现。

6.对于之前出现的报警信息，不能凭经验认为是某原因导致的。历史经验并不一定准确可靠，只有通过调查和分析相关日志才能得出真正的结论。

为了提高问题处理效率，需要从以下三个方面入手：

1.完善指挥体系和角色分工：一个完善的指挥体系和明确的角色分工可以有效地提高故障处理的效率。在处理问题时，各个角色需要明确自己的职责和任务，并协同配合，共同解决问题。

2.完备的技术层面故障隔离手段：在技术层面上，需要采取一些故障隔离手段，比如通过DUCC开关等方式来避免过度回滚代码。这样可以更加快速止血（DUCC开关秒级，如机器多回滚需要5-10分钟）

1.执行故障应急响应机制

1.建立完备的训练和演习流程：建立和维护一套完备的训练和演习流程是非常重要的。这需要一批对业务熟悉、专注投入的人来负责制定和执行相关计划。同时，还需要根据实际情况定期进行演习和模拟测试，以确保应急预案的有效性和可操作性。

2.先把问题上报组内、发挥团队的力量：在处理紧急事件时，应该先把问题上报组内，并充分发挥团队的力量。通过集思广益的方式，可以更加快速地找到问题的根源，并采取相应的措施进行解决。

关键角色分工

1.故障指挥官。这个角色是整个指挥体系的核心，他最重要的职责是组织和协调，而不是执行，比如负责人、小组长、架构师。

2.沟通引导。负责对内和对外的信息收集及通报，但是要求沟通表达能力要比较好，比如产品经理。

流程机制

1.故障发现后，On-Call同事或者小组长，有权召集相应的业务开发或其它必要资源，快速组织会议。

反馈机制

2.快速止血应急预案

1.面对问题时，你的第一反应可能是立即开始故障排查过程，试图尽快找到问题根源，这是错误的！不要这样做。正确的做法是：缓解系统问题是第一要务，尽最大可能让系统恢复服务。

2.快速止血而不是根源排查。首先只需要粗定位问题大概即可，然后通过一些应急预案措施（DUCC开关降级、限流、回滚等）来恢复现场。

3.线上问题首先思考，是不是上线、业务修改配置等变更导致，拉齐信息。

4.发布期间开始报错，且发布前一切正常？什么都不用管，先回滚再说，恢复正常后再慢慢排查。

5.应用已经稳定运行很长一段时间，突然开始出现进程退出现象？很可能是内存泄露，默默上重启大法。

6.如何确认是不是上线引入的问题呢？同比下上线前（比如昨天、上周）是否也存在一样问题。如果也存在说明跟上线没关系。看看昨天的日志，日志是最靠谱的。可用率会欺骗大家（因为你可能今天治理了可用率，之前可用率是100%，但不一定是真的100%）。

7.业务、产品、研发多路并行。

3.充分利用现有工具，智能分析定位问题

3.1 针对TP99高，定位难：

调用关系复杂，难以快速定位性能瓶颈。可通过工具事先梳理清楚服务间复杂的依赖关系，聚焦瓶颈服务的核心问题，而不是出现问题才去整理链路。

•如泰山 故障转移等：智能告知这个告警与哪个因素最相关，功能试用中。

•全域看板，集成UMP采集点，可快速定位是哪一个环节TP99高

•长链路应用，配置泰山雷达图。

3.2针对调用量突然高

3.3线程分析、JVM、火焰图CPU采样等

3.4业务问题

根据logbook查找，这个没什么好讲的。

通过标准化程序来指导训练技术人员，可以减少解决问题所需的时间。在相同的故障情况下，拥有适当的文档和应急预案SOP可以让您快速检查可能导致故障的所有因果因素。

下面不是严格的顺序，需要根据实际情况调整可多路并行，比如清楚问题大概环节，先止血。如不清楚，报备分工，初步定位大概环节再快速止血。

图3.

留现场，时反馈

1、在处理紧急事件（线上问题或者疑似问题）时，先把问题上报组内。

2、充分发挥团队的力量，通过集思广益的方式，可以更加快速地找到问题的根源，并采取相应的措施进行解决。

✅正例：假设一个团队中一名成员遇到了一个业务或者其他团队研发反馈的线上问题。他首先将问题上报给了组内TL/架构（电话、语音优先、咚咚），然后通过在线会议或即时通讯工具与团队成员分享问题的细节。团队成员们迅速展开讨论，集思广益，共同分析问题的原因和可能的解决方案。经过大家的共同努力，最终找到了问题的根源，并成功解决了问题。这个过程中，团队成员们充分发挥了团队协作的力量，提高了解决问题的效率。

❌反例：假设一个团队中一名成员遇到了一个业务或者其他团队研发反馈的线上问题。他没有将问题上报给组内，而是试图自己解决。结果，这个问题没有得到及时的解决，反而加重影响了线上损失。

1、故障指挥官(问题发现人或者小组长/架构），有权召集相应的业务、产品、开发或其它必要资源，快速组织会议。

2、故障指挥官明确各角色职责，分工明确，这样可以有效地提高故障处理的效率。

✅正例：故障指挥官（问题发现人或者TL/架构）有权召集相关的业务、产品、开发等团队成员，快速组织一个会议。在会议上，明确各成员的角色职责，如产品人员、开发人员、测试人员等，并分工明确。这样，每个人都能清楚地知道自己需要完成的任务，从而有效地提高故障处理的效率。通过集思广益，团队成员们能够迅速找到问题的根源，并采取相应的措施进行解决。

❌反例：故障指挥官（问题发现人或者TL/架构）没有及时召集相关的业务、产品、开发等团队成员开会。他试图自己解决问题，但由于缺乏专业的业务知识和经验，问题没有得到及时的解决。同时，其他团队成员也因为不知道问题的严重性而没有给予足够的关注。这种情况下，故障指挥官需要花费更多的时间和精力去协调各方资源，最终可能导致问题得不到有效解决，影响整个项目的进度。

1、让问题发现者描述发现的现象（时间、影响范围、影响程度），而不是判断的结论（因为判断的结论可能是错误的，这样会误导大家排查方向）

2、请大家避免在描述问题现象时，过多地表达自己的判断和看法，因为这可能会影响到大家的排查方向。需要保持客观和理性的态度，以便更好地分析问题。

3、同时，也请大家注意自己的思维方式，避免让自己的大脑成为别人思想的跑马场。在讨论问题时，可以提出自己的观点和建议，但请确保这些观点是基于事实和证据的，而不是个人的主观臆断。

✅正例：假设在一个软件开发团队中，当遇到一个性能问题时，问题发现者描述了如下现象：       时间：2023年8月18日上午9点至10点之间，用户在使用过程中发现了明显的性能下降。       影响范围：影响到用户登录、数据查询等主要功能模块。       影响程度：由于性能下降，用户的请求响应时间明显增加，部分用户无法正常完成操作。在这个例子中，问题发现者提供了具体的现象信息，使得团队成员能够迅速定位问题所在，并采取相应的措施进行优化和修复。

❌反例：假设在一个软件开发团队中，当遇到一个性能问题时，问题发现者仅给出了自己的判断结论：       时间：2023年8月18日上午9点至10点之间。       影响范围：可能是数据库连接池的问题。       影响程度：很严重，导致大部分用户都无法正常使用系统。在这个例子中，问题发现者没有提供具体的现象信息，而是仅仅给出了自己的判断结论。这可能会导致团队成员在排查问题时产生困惑，无法准确地找到问题的根源。同时，由于判断结论可能是错误的，这也可能误导团队成员，导致他们在排查问题上浪费时间和精力。

1、在故障处理过程中采取的所有手段和行动，一切以恢复业务为最高优先级，恢复现场止血方案高于寻找故障原因。

2、快速止血：可以采用开关技术、回滚技术等手段，迅速恢复系统功能，避免服务中断。 

3、日常应急预案：请大家提前制定好应急预案，包括关键业务的容灾策略、故障切换流程等，以便在发生故障时能够迅速启动预案，降低故障对业务的影响。 

4、请大家在故障处理过程中，不要过于关注故障原因的寻找。虽然找到故障原因是解决问题的关键，但在紧急情况下，需要优先考虑如何快速止血，恢复业务。只有在确保业务稳定运行的前提下，才能有更多的时间和精力去深入分析故障原因，从根本上解决问题。

✅正例：案例1：假设在一个软件开发团队中，当遇到一个系统故障时，问题发现者迅速采取了快速止血措施，恢复了系统功能。同时，团队成员在日常工作中制定了详细的应急预案，使得在类似的故障发生时能够迅速启动预案，降低故障对业务的影响。在这个例子中，问题发现者和团队成员将恢复业务作为最高优先级，迅速采取了快速止血措施，确保了系统的稳定性和可用性。同时，他们也注重日常应急预案的制定，为将来可能出现的故障做好了充分的准备。
案例2：在上线发布期间，如果开始报错，并且发布前一切正常？那什么也别管，先回滚再说，等恢复正常后再排查问题。案例3：应用已经稳定运行很长一段时间，突然开始出现进程退出的现象？则很可能是内存泄露，可采用重启大法，重启部分机器后观察看看是否止血了。

❌反例：假设在一个软件开发团队中，当遇到一个系统故障时，问题发现者花费了大量的时间去寻找故障原因，而忽略了快速止血和恢复业务的重要性。同时，团队成员在日常工作中没有制定详细的应急预案，导致在类似的故障发生时，处理过程混乱，无法迅速恢复系统功能。在这个例子中，问题发现者和团队成员过于关注故障原因的寻找，而忽视了快速止血和恢复业务的重要性。这导致了在故障发生时，处理过程效率低下，无法及时恢复系统功能，给业务带来了较大的影响。

✅正例：假设在一个生产环境中，系统突然出现性能下降的问题。作为oncall人员，在接到问题报告后，首先通过各种监控工具收集系统运行状态和性能指标等信息。然后，根据收集到的信息分析问题可能的原因，并与相关团队进行沟通和协作。最后，制定解决方案并进行实施，成功解决了系统性能下降的问题，恢复了正常的生产环境。

❌反例：假设在一个生产环境中，系统突然出现故障，导致业务无法正常运行。作为oncall员，在接到问题报告后，没有先定位大体方向，也没有通过监控工具收集相关信息进行分析。而是直接尝试修复问题，但由于缺乏准确的信息和分析，很难找到问题的根本原因，导致问题得不到有效解决，影响了业务的正常运行。

✅正例：假设在一个生产环境中，系统突然出现性能下降的问题。作为oncall人员，通过各种监控工具收集了UMP和日志数据，并发现在昨天和上周也存在类似的问题。同时，监测到UMP流量与之前相比没有明显变化。基于这些信息，运维人员可以初步判断问题与今天的上线无关，可能是由于其他原因导致的。他们按照优先级进行试验和验证，最终发现问题是由于某个配置参数设置不正确导致的。通过调整配置并重新试验，问题得到了解决，系统性能恢复正常。

❌反例：假设在一个生产环境中，系统突然出现故障，导致业务无法正常运行。作为oncall人员，没有经过详细的监控和分析，直接尝试修复问题。然而，由于缺乏准确的信息和分析，问题得不到有效解决，甚至可能因为错误的操作而导致更严重的错误。这种情况下，oncall人员需要及时调整方案并重新进行试验，以确保问题得到正确处理。

✅正例：假设在一个生产环境中，系统突然出现性能下降的问题。作为运维人员，通过技术回滚某台机器或者引流比对，发现输入参数与预期不符，导致接口无法正确处理请求。通过仔细排查，发现是由于一个配置参数错误导致的。修复该问题后，系统性能恢复正常，业务正常运行。

❌反例：假设在一个生产环境中，系统突然出现故障，导致业务无法正常运行。作为运维人员，没有进行任何比对和排查，直接尝试修复问题。然而，由于缺乏准确的信息和分析，问题得不到有效解决，甚至可能因为错误的操作而导致更严重的错误。这种情况下，运维人员需要及时调整方案并重新进行试验，以确保问题得到正确处理。

✅正例：假设在一个生产环境中，系统突然出现性能下降的问题，值班运维人员保留了1台机器并且摘除了流量，其他机器分批重启了，快速止血恢复了现场，同时安排其他人员去分析未重启的机器，Dump应用快照（常用的快照类型一般就是线程堆栈和堆内存映射）分析原因。

❌反例：假设在一个生产环境中，系统突然出现性能下降的问题，值班运维人员直接把机器都重启了，这样快速止血恢复了现场，但由于没有保留现场，导致现场关键信息丢失，可能无法继续排查根因

具体来说，可以从以下几个方面入手：

1.分析问题出现的原因：首先需要对问题进行深入的分析，找出问题的根本原因。只有找到问题的根源，才能够采取有针对性的措施来解决问题，从而缩短MTTR。

2.总结经验教训：在分析问题的过程中，需要总结经验教训，并提出改进建议。这些建议可以包括优化流程、提高效率、加强培训等方面的内容，但不需要列一堆Action，根据2/8法则抓重点即可。

参考：

SRE Google运维解密

持续交付2.0

推荐阅读

千万级数据深分页查询SQL性能优化实践

搜狗输入法双击输入框崩溃问题

LangChain：打造自己的LLM应用

移动端APP组件化架构实践

求分享

求点赞

求在看