第一章 架构域

反模式

case 1 单点故障

单点是指系统中一旦失效，就会让整个系统无法运行的部件。一般解决方案是通过冗余方式增加能够提供相同服务能力的节点来解决单点故障。这里可以引出的一个架构设计原则叫作 N+1 设计，简单来说就是在设计系统的时候要确保在系统发生故障时，至少有一个冗余的节点或者实例。

另外识别系统中的单点需要具备系统化思考的能力。

经典案例

1、2009 年淘宝交易平台 100% 下跌
2、2018 年盒马收银台停顿 1 小时。

最佳实践

1、遵循高可用架构设计，做好软硬件冗余架构，在故障出现时能够及时切换。
2、定期对单点进行巡检、迭代优化。
3、通过故障注入来发现系统中潜在的单点故障。

case 2 负载不均

负载均衡是一种计算机技术，用来在多个计算机、网络连接、CPU、磁盘驱动器或其他资源中分配负载，以达到最优化资源使用、最大化吞吐率，最小化响应时间，同时避免负载的目的。

负载不均的情况下，当业务增长到零界点或者突发流量出现时，则集群服务可能会出现雪崩导致整体不可用。另外，存储服务中的热点也属于负载不均的一种表现。

经典案例

推广活动导致热点库存争抢，导致数据库网卡被打满，整体分库无法提供服务。

最佳实践

1、设计流量分配方案时，一定要注意集群负载是否均衡。当部分集群服务压力过大时应该具备水平扩展的能力。
2、如果业务会出现热点，可以采用分桶或者热点缓存的方案来规避，尽量把热点请求分散到多台服务器上。
3、要注意负载均衡器自身是否会成为瓶颈，包括容量和高可用的部署。

case 3 有状态

最佳实践

1、在分布式系统的设计中，需要考虑系统的可扩展性需求，尽量避免有状态设计。
2、不要将 IP、磁盘路径（OS 不同分隔符及路径读取权限不同）写死在代码中或者配置里面。
3、本地磁盘只写日志，不存储业务相关数据。

case 4 事后监控

最佳实践

1、在系统设计之初就设计好监控，而不是事后再补。
2、

第七章 监控报警域

监控是我们的眼睛，我们依赖监控来了解系统、业务运行的状态；监控也是我们保障系统稳定性的前哨决策中枢，我们依赖监控来发现系统和业务运行中的隐患、风险和故障。

从本质上看，监控是对现实世界实体或对象的测量和检测，测量的结果通过监控数据的方式（可视化地）传递和展示出来，而检测的结果则会以报警（或消息）的形式通告监控的关注者。测量的目的除了让我们了解系统、系统运行的状态，便在于帮助我们及时发现异常，这也就是检测的意义。为了进行有效的检测，我们往往需要将我们认为异常（“异于平常”）的标准，以规则的形式告诉监控系统，让系统能够以这些规则来判定异常状态是否出现。一旦异常状态出现，系统会将异常以报警（消息）的形式传递出来。这些被传递出来的消息，或者触发系统的自动化预案，或者让运维/研发人员实时了解系统的异常进而做出下一步的快速恢复或故障定位的动作。

监控工作是运维工作的重要组成部分。任何运维工作的价值都可以通过“质量、成本、效率”三个维度来体现，监控工作也不例外。一个好的监控解决方案，需要同时关注质量、成本、效率，以期在实践起到符合预期的效果。

监控的质量

监控数据的质量是监控质量的基础。借用数据仓库领域的概念，监控数据又分为监控的事实数据和监控的维度（元）数据。监控的事实数据，不论是表示指标连续变化的时间序列，还是表示实体状态变化的可枚举的状态，都是我们对于监控对象某个层面的属性的观测。

监控策略的质量是监控质量的关键。一般来说，我们可以通过报警的误报率和漏报率来衡量监控策略（规则）的质量。实际生产环境中的监控测量总是会在漏报率和误报率之间作出折衷。

为了全面地反应诸多被监控对象的状态和发现异常，监控的覆盖率也是监控效果好坏的关键因素。如果说监控数据的质量和监控策略的质量是针对局部对象的监控，监控覆盖则是站在全局视角来保证监控的最终效果。我们可以从两个视角来做好监控覆盖：监控覆盖率和监控齐全度。例如 Google 提出了 4 类“黄金指标”（延迟、错误状态/码、流量、饱和度），就是站在终端业务体验的视角衡量业务状态的最佳实践。分布式系统业务主要是速率、错误、耗时。

监控系统本身的稳定性是监控质量的基石。

监控的成本

监控数据生成和策略维护的成本过大往往会导致监控质量的降低。

监控的效率

除了监控的准确率和召回率，监控的时效性也是影响监控效果的重要因素。

除了监控本身的时效性，监控系统的数据信息和报警信息被人有效接受和利用的效率，也是我们优化监控效率的重要方面。

综上，我们尝试从监控的质量、成本、效率三个层面探讨了当前监控报警领域的挑战、可能的解决方案和系统设计思路。

case 1 监控误报成本浪费

监控项的误报往往有三个原因：
1、监控指标不准确：即监控指标不能代表监控对象的健康状态
2、监控指标抖动过大：即监控指标作为被监控的数据由于测试、演练、爬虫等流量引起指标数据非正常抖动，进而触发报警规则所代表的异常区间，导致误报。
3、监控策略不合理：即监控策略没有很好的在业务监控指标波动范围和主动发现异常上达到很好的契合，导致误报率很高。

经典案例

影子链路调试导致成功率降低，GOC 发布 P2 故障通告。实际是误报。

最佳实践

1、针对监控指标不准确的问题，我们需要根据业务的调用链去重新梳理业务风险点，根据调用链的依赖情况，找到最根本的监控指标去代表业务的健康度；在具体实现的过程中，如果条件允许的情况下，我们希望是全链路的监控，而如果实现成本较大的情况，我们可以通过对用户行为表达对服务链路最前端进行监控（因为整条链路的访问结果都在这里有所体现）。

2、监控指标抖动过大往往是因为数据源不稳定导致，这里我们需要用到原因值分类（将不同的流量和错误进行分类区分，分层处理）的办法进行解决：
2.1 将流量分为 2 类：通过流量标签识别进行分区：a 正常线上流量，正常用户访问的流量，出现问题会影响用户体验。b 测试流量：压测、灰度验证等测试流量，出现问题不会影响用户体验。c 爬虫、非法访问流量：非正常用户访问导致业务指标波动的流量。
2.2 将用户错误分为 3 类：a 系统异常；b 业务规则； c 用户操作

3、往往监控策略根据不同的业务容忍度不一样，配置之间会很大的差异，但是从更快发现问题的角度来看，只要保障足够的准确性，敏感度高一些不是主要矛盾，针对这个问题的解决办法主要有 3 类：
3.1 组合指标策略：a、将单指标的报警策略通过多策略组合，减少单指标受业务正常波动的影响；例如环比和上周同步的组合。b、将单类指标的报警策略通过多类指标组合，较少单类指标受业务波动的影响；例如失败量（绝对值）和成功率（相对值）的组合。
3.2 摊平业务指标的曲线波动：当实时环比受业务波动比较大时，通过设置时间窗口 t 和统计方式（求和、求平均、求差值）进行流量摊平，使瞬时流量平滑减少抖动，进而减少误报。
3.3 机器学习算法：通过对历史数据的拟合和趋势判断，实现当业务指标出现偏离时的异常检测。

以上方法，可以帮助减少监控误报导致的应急成本浪费，并避免过多的误报影响大家处理报警的及时率和应急意识。

case 2 指标采集不标准

在实际生产环境中，很多人因为监控误报而烦恼，提升监控的准确率需要很多方面的共同努力。其中，采集指标标准化是一个重要的因素。

经典案例

指标波动

最佳实践

1、减少误报，提示告警准确性一方面需要配置足够准确的告警策略，另一方面，提示监控数据的质量也非常重要。对于一般的业务指标而言，目前的最佳实践是 SPM 类型指标，即在日志中包含：响应时间，结果是否成功两个要素，根据一定时间窗口的埋点日志，我们可以统计出该业务点的：总量/成功量/成功率/失败率/平均响应时间等指标，我们称之为 SPM 指标。
2、根据 SPM 指标，我们能更清晰的判断该业务点是否有问题。

case 3 基础设施产品未关注业务可用性

提供给客户的服务要有从客户业务场景梳理出监控手段，并进行有效的监控，第一时间响应客户服务监控异常，并协助客户一起排查处理，即使非责任问题也要有意识协助客户排查问题，建设更多手段快速定位问题，从而最终提供更优质的产品服务给客户。基础设施类产品是各类互联网技术架构的最底层基座，基础设施类产品的问题往往会影响多个 BU 的业务系统和应用程序。

经典案例

ALB-VIP 下跌

最佳实践

1、对用户的服务可用性做好监控
2、及时协助用户排查问题，虽不是产品侧触发导致，但是及时协助客户排查处理，可以有效预防用户业务受影响。

case 4 大面积 coredump 监控

coredump 是一种常见的线上故障，内存访问越界、线程访问不安全、堆栈溢出、非法指针等问题都可能引发程序的 coredump。根据程序不同，coredump 的耗时可能由几秒到几分钟不等，coredump 期间程序无法正常对外提供服务，会导致服务拒绝；同时，core 文件中包含程序运行时的内存、寄存器状态、堆栈指针、内存管理信息等，是故障定位到一个重要信息来源。

经典案例

C++ 由于特殊 case 中有特殊 query 导致 coredump

最佳实践

「集中式 coredump 管理」是一种有效的大面积 coredump 故障预发手段，通过修改「/proc/sys/kernel/core_pattern」参数将本机的 coredump 行为通过管道的方式引导到「集中管理中心」。

case 5 监控失效

监控有效性是指监控项能够持续的、正常的观测监控对象的监控情况的能力，一般我们通过单位 BU（business unit）监控项的有效率（有效监控项的占比）来进行观测。

经典案例

某业务由于监控波动较大导致监控项报警规则失效，故障未能通过监控主动发现，导致故障未被及时处理，造成较大影响。

最佳实践

监控的核心还是为了检测线上的异动（服务故障异常、业务故障异常、业务决策数据波动），那么怎么样才能去保障监控能够持续的发现服务和业务故障呢？监控有效性的持续治理的重要性就体现出来了。
1、监控对象盘点：持续保障监控的持续有效性，需要我们常态化的去盘点监控资产（每一个监控项都是一份监控资产）。
2、监控策略盘点：除了监控对象因为业务和服务迭代失效之外，同时监控策略业务也会失效。
3、监控干系人盘点：对于监控要产出效果来说，光保障监控对象且能准确报警，而没有将报警触达能够使问题和业务影响消弭的处理人手上也是不行的。所以监控资产盘点的第三个部分就是干系人的盘点，干系人的盘点主要针对该监控项所监测的指标出现问题时，需要及时响应并逐步消弭问题影响的人员，以及该监控项后续持续维护人员的准确性。

综上所述，监控有效性的持续保障的主要手段是监控资产盘点，而监控资产盘点主要分为监控对象的盘点、监控策略的盘点、监控干系人的盘点。

case 6 监控配置不合理

合理的监控报警配置能够帮助我们快速发现问题。监控信息中通常包含很多干扰信息，比如非系统异常、压测、爬虫干涉等，配置监控时应避免使用不同级别的监控配置信息配置到一起，同时应将报警域值配置在合理范围，避免过于宽松。

经典案例

盒马 buy2 发布导致支付异常，无报警感知。
未报警原因：由于端监控未区分系统异常未支付和用户行为未支付的错误码，导致客户端用户支付成功率抖动严重，报警域值配置过于宽松，变更导致故障时无报警出来。

最佳实践

指标采集：采集指标覆盖所有核心业务功能&尽可能保证采集指标过滤掉非系统异常、压测、爬虫等干扰，为报警规则配置提供好的基础。

报警规则：秉持流量最上层入口监控以「成功率、失败量绝对值域值为主，成功量总量环比同比波动为辅」，低层应用采集监控以「成功量总量环比波动为主，成功率、失败量绝对值域值为辅」原则，并根据实际业务量级大小情况、业务量高低峰值时间段，合理分量级、分时间段配置合适的报警规则。

case 7 关键报警无人处理

报警的重要性不再赘述，如果长期收到一些不关注、不处理的报警，很可能会对报警麻木。一旦线上有异常、报警有效，也很可能会忽略报警，极端情况下导致故障没有及时处理。

经典案例

淘鲜达由于没有处理报警导致问题持续 140 min。

最佳实践

1、所有报警都要处理，否则优化报警。我们的目标是每一条报警都是需要人及时介入处理的，如果不需要我介入那就不用报给我；如果只是知晓型的报警，那就用低优先级的邮件、钉钉等渠道。
2、针对失败量监控，其实更应该关注在失败率，流量（总量）增长情况下失败率保持稳定，失败率保持稳定，失败量会随之增长，而这时我们并不需要介入处理。
3、针对耗时的监控，如果服务的成功率稳定，流量（成功率）稳定，那耗时增长并没有影响业务。
4、如果失败率下跌同时耗时增长，一般都是服务有问题，需要马上排查的。

case 8 缺乏分维度大盘

我们通常用整体业务的数据作为我们发现问题的重要数据，同时，我们也需要维度的数据帮我们做一些快速的分析和判断，在发现问题后进行快速定位。

经典案例

监控发现视频播放的错误码上升触发了报警，但是线上并未发现播放问题。最终定位为视频播放器没有问题，播放离线广告的时候出现 问题，导致广告业务出现影响，最终影响到了资损。

最佳实践

配置分维度监控，包括客户端类型、网络类型、供应商，对错误码来源也区分到版本、省份、CDN 等。这样有时需要 30 分钟 - 1 小时定位的播放类问题，可以在 2 分钟内快速定位，CDN 异常节点的数据也可以快速提供到 CDN 团队，帮助他们快速定位甚至自动执行相关预案，帮助业务快速恢复。

case 9 变更不关注业务监控

业务上经常会出现需要割接，切流，重构等相关的运维动作，而在这个过程中出现线上故障的概率要比一般的变更操作高出很多，所以这个时候对于业务的稳定性的监控就显得更为重要，确保在业务切流过程中第一时间发现问题及时回滚。

通常在切流过程中，业务流量的趋势是会明显的变化的，所以在监控上我们更倾向于用成功率这个指标去做配置相应的报警，当然也可以用老系统的流量加上新系统的流量综合作为监控对象，但是这个方式成本相对会高一点。

经典案例

脚本执行导致交易下跌。

最佳实践

1、引入实时监控大盘，在业务或者应用重大调整阶段，需要在割接或者切流前提前部署好业务监控这双眼睛，确保切流过程有条不紊。
2、合理配置监控大盘，比如基于 HTTP 的返回码配置对应的成功率。以 2xx 和 3xx 作为成功的判断，4xx 和 5xx 作为失败的判定，这样可以快速产生一个所有新环境下各域名成功率的监控。

通过监控报警快速发现问题、快速回切，对线上的故障和问题做到快速止血。

第八章 故障处理域

随着系统越发复杂、业务链路更长、线上线下协同要求不断提高，故障发生时，快速发现问题、确切的知道影响面，快速发起应急协同、让链路上的每个角色案故障应急的流程行动起来，快速定位到问题排查方向、启动恢复预案，一切分秒必争。

当有一个基本的框架和流程来保障你应急有序的时候，技术同学就要直面系统发生的各种问题了，重启、切单元、限流、降级这些大招之外，还有各种场景下的实践或反思，本章也会带你一起领略前人的经验教训形成的经典案例，让你手中有招、心中不慌。

case 1 应急原则

应急的第一原则是，先恢复、再找原因。要使用一切可能的手段让系统恢复到合理的服务水平上来。常用的手段包括重启、切流、降级、变更回滚等等，有些需要快速决策。

经典案例

新版 HSF 路由规则升级导致交易核心应用出现 Full GC，操作回滚、重新推送配置、交易核心应用重启后恢复。

最佳实践

在重大故障发生时，有时问题不能第一时间定位或找到原因，尽快使用一些常用的恢复手段可能比定位后再解决更快速有效，例如对就近时间点完成的变更进行回滚、重启受影响的机器、某个单元或者机房受影响时刻切流、应用降级预案等。

case 2 应急启动

故障不仅仅只是一次系统 bug 修复，迫切需要工程师们把应急启动 SLA 缩短到秒级。

经典案例

盒马将交易 6 个场景进行全自动化通告灰度，为故障整体恢复时长缩短 10 分钟。

经典实践

1、提升每一个参与应急人员的意识：通过稳定性法制、机制、文化建设，组织稳定性安全生产月，安全生产认证考试等反复灌输宣传，唤起每一个可能参与到故障应急到同学的稳定性意识，真正为客户的业务保驾护航争分夺秒。
2、确保问题被及时发现：目前问题发现来源一部分来自监控系统告警，一部分来自人工上报。对于人工上报故障，通过同问题提交人员制定问题上报 SLA、问题反馈模版以及自动化工具赋能提高故障的时效和用户体验，确保问题提交人员准确反馈舆情信息，系统问题全面而有效收口，避免漏报；对于监控来源的故障，通过基于「智能基线」的业务指标智能监控，抵御各种噪声，且兼备历史趋势和局部业务变化，大大提升监控发现准确率和召回率，确保问题及时有效的发现。
3、秒级故障通告，启动应急：通过将文本形式的故障应急场景结构化为多业务指标结合的应急场景，并配置关联监控项接入，实现全量故障的自动化通告。同时通告持续驱动自动化收敛引擎的优化，提升自动化通告的准确率，避免误报过多。

case 3 应急组织

case 4 跨域协同

case 5 应急指挥

case 6 故障需及时、准确复盘

case 7 快速恢复