目录
背景：架构变化带来的问题
随着架构越来越复杂、应用越来越多样，特别是微服务场景下，服务之间的调用层级越来越多，这给业务系统的稳定性、运维工具的有效性提出了挑战。比如：
- 某一模块的大规模变更过程导致稳定性故障频发。
- 架构的复杂化导致传统的保障方式无法满足稳定性需求。
- 监控警报、运维工具等基础设施在故障出现时是否能有效工作。
针对架构变化带来的稳定性问题，特别是用户和流量规模越大，影响将越致命。除了确保业务上线时必要的测试外，还需要针对性的做重点保障，比如一个游戏业务新上线时特别安排了为期一两个月的重保行动。
另外，当前针对系统的保障方式，也只能做到出现问题后的补救行为，我们能否在运维工具上，快速的发现问题并且预警，提前进行主动运维？这就需要我们在监控、可观测领域，研发、采购产品力更强的运维工具（比如当前云原生的可观测运维产品），实时的采集系统运行的指标，根据指标的异常情况，提前做故障预测，通过智能分析算法，给出根因分析，提出修复建议，以快速的发现和解决问题。
这就需要通过故障演练的方式，提前发现问题、解决问题，发现运维工具存在的指标不够、告警不力、根因分析不足等问题，也要组织演练。
什么是故障演练
对于很多大型企业来说，经过多年的技术演进，系统工具和架构已经高度垂直化，服务器规模也达到了比较大的体量。当服务规模大于一定量（如10000台）时，小概率的硬件故障每天都会发生。这时如果需要人的干预，系统就无法可靠的伸缩。
为此每一层的系统都会面向失败做设计，对下游组件零信任，确保在故障发生时可以快速的发现和处理。但这些措施在故障发生时的有效性、故障恢复工具的真实容灾能力、处理问题人员的熟练度，沟通机制、容灾措施对上层的影响等问题，平时并没有太多的机会验证，往往都是在真实故障中暴露。
故障演练就是这个背景下诞生的，沉淀通用的故障场景，以可控成本在线上故障重放，以持续性的演练和回归方式的运营来暴露问题，不断验证和推动系统、工具、流程、人员能力的提升，从而提前发现并修复可避免的重大问题，或通过验证故障发现手段、故障修复能力来达到缩短故障修复时长的作用。
故障演练验证，是指基于混沌工程的故障演练实现对业务系统的验证。演练可以分为有损演练和无损演练，一般通过低频的有损演练发现业务架构问题、验证业务容灾能力，通过高频的无损演练实现对业务的监控发现/报警响应、组织应急等能力进行验证。
为什么需要故障演练
云原生技术的发展，微服务架构、容器化技术广泛使用，软件架构的复杂度在不断提升，由服务之间的依赖所带来的不确定性也呈指数级增长，任何一环出现非预期或者异常的变化，都可能对其他服务造成非常大的影响。因此，有必要构建一个故障演练平台和机制，来提升系统架构的容错能力和韧性，验证整个故障定位能力和恢复体系。
下图是针对不同的演练阶段，在不同的演练环境下进行的演练任务，目的也是通过故障注入案例，在测试环境、灰度环境、生产环境上验证系统稳定性、运维告警平台的有效性而开展的一系列活动。
另外，根据故障处理的一般流程，故障演练也可以归纳为三个阶段：
-
事前：及时发现风险，做好架构、预案、演练。
-
事中：及时发现故障，及时定位，及时止损。
-
事后：排查根因，落实复盘改进项。
故障演练，主要是模拟线上环境可能遇到的各种问题进行提前摸底测试，既可以对业务系统的稳定性进行检验，也可以对运维工具的综合能力进行检验。
在生产环境上进行的故障演练是最高级别的演练，非常考验案例注入的丰富性及系统的控制编排能力（混沌工程）、可观测平台告警和根因分析能力、数据的隔离能力。
故障演练场景有哪些
故障演练场景有很多，从单个系统应用的维度、集群组件视角维度去构造案例，以检验我们业务系统的稳定性，更重要的是提前发现问题的能力，这对运维工具提出越来越高的要求，挑战也越来越大。从垂直技术架构层次，设计演练场景：（下面2个图思路类似）
从集群和组件维度，设计演练场景：
针对不同的业务场景、部署场景进行演练，我们可以对运维工具进行全方位的评估，比如通过混沌工程制造一个网络丢包案例，运维工具能否在毫秒时间内进行告警报错，能否从应用监控维度发现造成的建联失败、超时等问题，同时报告出错的点是在 OS 内核位置，还是云场景中的云网络丢包还是物理网络丢包。
如果是构造了一个访问空指针造成系统宕机的场景，集群维度的运维工具是否能快速检测到单节点出的故障，抓取 vmcore 信息并分析造成宕机的根因，然后报告节点健康度状态，根据影响做出迁移动作，非常考验运维工具的综合能力。
不同演练类型和目标
根据演练过程对线上业务的影响，演练可分为有损演练和无损演练。由于对业务的影响不同，两种演练可以进行的演练频次、可实现的业务验证目标都有不同。
有损演练是指直接在线上真实业务环境注入异常进行演练，演练模拟的真实有效性高，为了平衡业务影响一般会选择最核心场景、在业务最低峰期做演练，而且演练频次相对较小，例如为了验证多活容灾能力的机房断网演练，一般是一个月一次的演练频次；无损演练是指在一套无线上真实业务流量的隔离环境做演练，配合压测模拟流量注入异常进行演练，由于业务无损，可以支持较高频次的演练，比如为了类比/形变复现线上类似故障、验收故障复盘的改进action、演练监控感知能力/报警响应能力等，可以组织对不同业务团队轮流参与的每周1次的高频演练。
| 演练类型 | 演练方案优缺点 | 演练环境 | 演练频次 | 主要演练目标 |
| 有损演练 |
| 线上真实业务环境 | 1-2月一次 |
|
| 无损演练 |
| 全链路灰度环境/新建业务环境 | 每周1-2次 |
|
如何对工具进行评估
从上文故障演练的介绍可知，在问题预警、问题发现、根因排查方面，运维工具的作用非常大，对快速发现业务系统的稳定性、及时告警、根因分析上起到关键作用。运维工具的丰富度、告警是否及时、指标是否有效等能力，稳定轻量、易于使用、功能全面、社区支持等，也是参考的重要指标。因此，结合故障演练环节对运维工具进行评估，是一个非常有效的手段。
在成熟的业务系统上，部署一套运维工具，特别是常态化开启的监控工具，如可观测场景下经常会通过 profiling 进行系统性能剖析，往往会对业务系统带来一定的性能开销，也就是我们的运维工具上去之后，必须保障对原系统影响较小，即挑选一个功能丰富、性能开销较小、存储费用较少、能进行故障预测和告警、提供根因分析和修复建议（即具备智能化分析能力）的运维产品，将是重要目标。
总结起来对运维工具的评估，会考虑以下方向：
-
资源占用少。运维工具本身占用 CPU、内存等资源要小，不能占用比我业务系统还大的资源，本末倒置！
-
对原业务系统无影响。上工具前，先问一句工具是否可靠，不能把我的系统搞挂。否则，我业务都没了，还要你的工具做什么。
-
响应及时性，告警有效性。有问题先告警，别乱报啊！
-
分析准确性，功能一致性。监控和 profiling 功能要稳，根因分析要准确，一致！
-
数据成本低。日志、指标、追踪数据要精简，能定位问题，但指标不宜过多。多了我可买不起，不瞎折腾！
-
易用性好，易部署、易升级。操作简便，别整高大上的花里胡哨但解决不了问题的东西！
-
架构可移植性好，不同平台、不同版本兼容。考虑 X86、Arm 及 eBPF 在不同内核版本的兼容性等。
下面，分别从功能、告警、观测指标评估项上进行细化讨论。
功能评测项
1. 基础功能完备性：
-
系统监控：对 CPU、内存、磁盘、网络流量等基础资源的实时监控能力。
-
应用层监控：API 接口调用监测、数据库性能监控、容器/微服务状态监控等。
-
自定义指标支持：是否允许用户自定义监控指标和阈值。
2. 告警配置灵活性：
-
多条件组合告警规则设置：支持多维度数据聚合与逻辑运算进行告警触发判断。
-
告警策略管理：如重复告警抑制、告警升级机制、告警合并等功能。
3. 故障定位精准度：
-
根因分析：提供故障根因分析工具或功能，能快速定位问题源头。
-
故障排查路径追踪：记录并展示故障发生时的事件链路，辅助排查过程。
告警评测项
1. 告警延迟检测：
-
实时告警触发时间与实际故障发生时间之间的差距。
-
平均告警延迟时间统计。
2. 告警通道覆盖范围：
-
支持的告警通知方式（短信、电话、邮件、企业微信、钉钉等）。
-
第三方集成：与其他告警渠道和服务集成的能力。
3. 告警触发阈值敏感度：
-
对异常情况的敏感程度以及告警阈值设定的合理性。
4. 告警通知频率控制：
-
在持续异常期间告警频率的调整策略，避免过多重复告警。
观测指标评测项
1. 可观测数据源丰富度：
-
日志观测：日志收集、解析、搜索及关联分析能力。
-
时序数据观测：对各种时序数据（如系统性能指标、业务关键指标）的可视化展示。
-
分布式追踪：对分布式系统调用链路的跟踪能力。
2. 数据可视化效果：
-
可视化仪表盘定制能力：包括图表类型、自定义布局、颜色编码等。
-
数据实时更新速度：界面刷新率和数据同步延迟。
3. 洞察力与分析深度：
-
异常检测算法的有效性：能否准确识别出潜在问题。
-
智能诊断建议：提供基于 AI/ML 的故障预测与解决方案推荐。
4. 可扩展性和兼容性：
-
对不同架构（如云原生、混合云环境）的支持。
-
与第三方系统的兼容对接（如 Prometheus、OpenTelemetry 等标准协议）。
通过以上评测项的量化评估，可以全面了解运维产品的功能准确性、告警及时性和观测有效性的表现。同时，评测过程中需结合具体场景和用户需求，确保评测结果具有针对性和实用性。
总结
稍具规模的故障演练，往往需要各个团队角色协作完成，会面临一个ROI的问题，实施时需要从上到下推动，做好充足的准备。
251
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
