背景
由很多微服务组成的分布式系统中,永远难以全面掌握什么事件会导致系统局部不可用,甚至全面崩溃。主要因素:
1)系统架构演进:服务集群→分布式→微服务→容器化(K8S&docker)→上云;
2)版本迭代增速:CICD、敏捷、devops、ABtest;
3)用户需求变更:复杂化、多样化、快速化、小众化;
对系统的要求:扩展性、稳定性、弹性能力、容错灾备能力;
软件系统现状:系统复杂性提高、问题定位成本高;
要解决的问题:生产环境下的分布式系统在面对失控条件时依然具备较强的“可观测性”和故障恢复能力;
主要验证方式:故障注入;
开展“混沌工程”的意义
开发者的能力和认知水平有边界,不可能所有的细节都可以预估到,系统很脆弱,各种潜在不可预期的突发事件在所难免。
我们需要在异常触发之前,尽可能地去筛选出会导致出现有异常问题的、容易造成故障的、系统中明显裂痕的环节,这也是混沌工程所肩负的意义。
能让复杂系统中根深蒂固的混乱和不稳定性浮出水面,让我们更全面了解系统中固有的现象,然后进行及时修复、加固和防患于未然,才能打造更具弹性的软件工程系统。
思考
1、设计良好的系统,需要考虑哪些因素?
可靠性、安全性、可扩展性、可定制化、可伸缩性、可维护性、用户体验等。
2、混沌工程解决什么问题?
生产环境下,分布式系统在面对失控条件时是否具备较强的“可观测性”和故障恢复能力。
3、开展混沌工程要考虑的维度有哪些?
1)建立稳定状态的假设(清晰可衡量的指标)
2)用多样的生产事件做验证(多样性降低误差)
3)在生产环境做验证(真实场景)
4)自动化开展实验(持续运行)
5)控制最小化爆炸半径(影响范围)
4、Netflix开展混沌工程总结的三点经验
1)建立面向失败设计和拥抱失败的技术文化(技术文化)
思想上,引入混沌工程的核心是通过引入一些风险去暴露已有的不易发现的问题,而不是创造问题。这样有助于问题的发现和处理,降低潜在故障带来的影响。
2)定义一个清晰可度量的目标(定义目标)
前期:对历史故障的复现率以及解决率,确保故障改进的有效性;
中期:监控发现率,验证故障发现能力的全面性和监控的完备程度;
后期:故障的“发现-定位-恢复”市场这种综合性指标;
3)在控制风险的前提下不断提升混沌工程效率(技术推广)
先从简单的场景开始尝试,逐渐增加组织对系统的信心(要明白准备工作比落地执行更重要)。
混沌工程是一种实践思想,方法论,本身不绑定任何工具或者技术。不过在进行推广和实施时,考虑到真实性、容错性、开发成本、运维效率等因素,建议复用成熟的开源组件或者商业化工具。
网友评论