目录
背景:架构变化带来的问题
什么是故障演练
为什么需要故障演练
故障演练场景有哪些
不同演练类型和目标
如何对工具进行评估
功能评测项
告警评测项
观测指标评测项
总结
背景:架构变化带来的问题
随着架构越来越复杂、应用越来越多样,特别是微服务场景下,服务之间的调用层级越来越多,这给业务系统的稳定性、运维工具的有效性提出了挑战。比如:
- 某一模块的大规模变更过程导致稳定性故障频发。
- 架构的复杂化导致传统的保障方式无法满足稳定性需求。
- 监控警报、运维工具等基础设施在故障出现时是否能有效工作。
针对架构变化带来的稳定性问题,特别是用户和流量规模越大,影响将越致命。除了确保业务上线时必要的测试外,还需要针对性的做重点保障,比如一个游戏业务新上线时特别安排了为期一两个月的重保行动。
另外,当前针对系统的保障方式,也只能做到出现问题后的补救行为,我们能否在运维工具上,快速的发现问题并且预警,提前进行主动运维?这就需要我们在监控、可观测领域,研发、采购产品力更强的运维工具(比如当前云原生的可观测运维产品),实时的采集系统运行的指标,根据指标的异常情况,提前做故障预测,通过智能分析算法,给出根因分析,提出修复建议,以快速的发现和解决问题。
这就需要通过故障演练的方式,提前发现问题、解决问题,发现运维工具存在的指标不够、告警不力、根因分析不足等问题,也要组织演练。
什么是故障演练
对于很多大型企业来说,经过多年的技术演进,系统工具和架构已经高度垂直化,服务器规模也达到了比较大的体量。当服务规模大于一定量(如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的问题,实施时需要从上到下推动,做好充足的准备。