混沌工程落地的六个阶段（上）
资深技术专家焦振清
讲述：初明明大小：4.76M时长：05:12
混沌工程是一门新兴的技术学科，它的初衷是通过实验性的方法，让人们建立对于复杂分布式系统在生产中抵御突发事件能力的信心。近日，京东资深技术专家焦振清从自己所在团队的实践出发，将混沌工程总结为六个阶段，分别是单机、单机房、依赖治理、故障注入、集成 CI/CD、产品化，并对各个阶段的落地过程加以总结，希望能够对你落地混沌工程有所帮助。
单机破坏
单机破坏能够在测试环境中发现绝大多数问题，并能扫清后续阶段的阻塞点，因此排在首位可谓是当之无愧。
重要性说明
以集群选主机制为例说明单机破坏的优先级和重要性，如果单机在某些场景异常后，集群无法选主，进而导致系统整体不可用。该问题如果在单机房破坏场景时才发现，那系统整体就不可用了。
破坏手段
在测试环境下，先从重启服务器开始，然后会出现关机、资源异常（如 CPU 打满）等场景。需要注意的是，在单机破坏场景下，一定不要把自己”拒之门外”。举个例子，把机器的 CPU 打满，但是没有设置打满的时长，结果自己也无法登录机器了，只能重启。
落地建议
初期仅在测试环境中进行，仅进行重启场景的验证就足以发现很多问题；
给出单机破坏的全部场景和验收方法，由各个团队自行落地；
不恋战，只要问题不阻塞单机房破坏环节，不影响黄金流程即可进入下阶段。
单机房破坏
这是高频故障场景，故障后影响较为严重，业界有较多的最佳实践可供参考，模拟单机房破坏的难度和风险均较低，因此排名紧随单机破坏其后。
重要性说明
单机房故障是造成服务整体崩溃的主要原因之一，全球互联网巨头大多发生过单机房故障导致服务崩溃的情形。诸如外网出口异常、内网跨机房专线异常、机房核心交换机异常、各种网络抖动和拥塞、IDC 供电设备异常等等，其重要性可见一斑。
破坏手段
将跨机房的专线端口关闭即可，恢复则是将端口重新运行，整个耗时可以控制在秒级。演练前，业务方需要提前将流量迁移到其他机房，观察跨机房的残余流量符合预期后再进行操作，否则就对残余流量进行排查，从而避免发生较为严重的故障。
落地建议
如果近期公司内部发生类似的单机房故障，那是单机房破坏发起的最佳时机；
通过数据分析来揭示风险，如跨机房交互的模块数量及比例、跨机房的流量带宽的增长趋势、使用率和成分分析、各个业务方对较大网络操作的接受度等；
借助网络调整的机会，来间接实现第一次单机房破坏；
如果仅仅破坏部分机房，如所有在线机房，是不足以发现所有的问题和隐患的，需要对所有机房逐一进行一次演练，才能发现一些潜藏的依赖和问题；
单机房破坏的时间点尽量参照网络调整的时间点，大多数在凌晨 1 点左右进行。
依赖治理
基础设施可谓是牵一发动全身，故障频率低，故障影响大，因此依赖治理放在了单机和单机房之后。
重要性说明
依赖主要是第三方依赖和基础设施，包括但不限于 MySQL、Redis、Kubernetes 、DNS、LB、ELK、Hadoop 等，上述任何服务的故障，对业务影响都极为严重。
破坏手段
基础服务和一般的业务场景无区别，主要也是通过单机破坏和单机房破坏等通用手段来进行快速的问题识别。
落地建议
对于依赖的破坏，为了减少对业务方的影响，初期可以通过业务方的测试 / 预发环境 + 依赖的正式环境组合来进行破坏，也可以在离线机房对基础设施进行破坏；
基础设施很大占比是开源软件，进行 Trace 的改造成本较高，因此要了解第三方依赖内部的关键点，并针对性的进行破坏演练；
攘外必先安内，各类依赖大部分都是其他部门提供的服务，沟通成本和配合度上会有区别，因此需要先搞定自身的问题，然后再进行第三方的依赖治理，不然很容易被人怼回去，毕竟很多依赖属于基础设施，牵一发动全身，别人配合的成本也是极大的；
对于循环依赖需要在架构层面明确原则，然后再进行整体的改造。
以上是混沌工程落地的前三个阶段，受篇幅所限，后三个阶段的落地建议将在下文展开说明，欢迎持续关注。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论