每个人或多或少都经历着两种力量的斗争，对独处的渴望和走出去的冲动。
乐观的人在每个危机里看到机会，悲观的人在每个机会里看见危机。
前言
- 本次去听了携程的技术峰会，下面简单的记录下一些我的听会概要。
混沌工程
混沌工程：Chaos Engineering
定义
- 正式的定义：世界是非线性的，线性只是其近似描述，混沌的发现表明：某些确定性非线性系统具有内在的随机 行为。事实上，以往20年，无所不在的混沌现象几乎在每个学科都有所报道，如数学、物理学、化学，甚至社会科学。但理论研究学者的主要兴趣在于探究混沌的本质。与此同时，混沌的实际利用在许多工程领域受到重视，如信息工程、系统工程、医药工程、农业工程、电气工程、生物工程、机械工程、土木工程等。混沌工程学是一门新的研究混沌实际利用及其基本理论的非线性工程科学。 ——《混沌工程学》
- 混沌工程的核心思想：通过不断地失败来避免失败。
- 通过主动的制造故障来验证系统的稳定性。
- 混沌工程（Chaos Engineering）：是在分布式系统上进行实验的学科，目的是建立对系统抵御生产环境中失控条件的能力以及信心。最早由Netflix及相关团队提出。
混沌工程的发展故事线
- 2010年，Netflix Eng Tools团队开发出了Chaos Monkey。当时Netflix从物理基础设施迁移到AWS上，为了保证AWS实例的故障不会给Netflix的用户体验造成影响，他们开发了这个工具，用来测试系统。
- 2011年，Simian Army诞生，在Chaos Monkey的基础上增加了故障注入模式，可以测试更多的故障场景。Netflix 认为，云的特点是冗余和容错，但没有哪个组件能够保证100%的可用性，所以他们必须设计出一种云架构，在这种架构里，个体组件的故障不会影响到整个系统。
- 2012年，Netflix在 GitHub上开源了Chaos Monkey，并声称他们“已经找到了应对主要非预期故障的解决方案。通过经常性地制造故障，我们的服务因此变得更有弹性。”
- 2014年，Netflix团队创建了一种新的角色，叫作混沌工程师。Bruce Wong 发明了这个角色，并由 Dan Woods 在 Twitter上向广大的工程社区推广。
- 2014年，Chaos Monkey的升级版本FIT诞生，实现微服务级别的故障注入。
2016年，混沌工程(Chaos Engineering)的概念通过《Principles Of Chaos》这本书被提出。面向失败设计也逐渐成为构建一个高可用架构产品的基本要求，混沌工程也在更多公司进行实践。 - 2017年，Chaos Monkey的3.0版本ChAP（Chaos Automation Platform）诞生，可以配合环境、监控实现部分场景的自动化演练。
概念：强弱依赖系统（EOS），主要为通过程序自动化的帮助应用依赖梳理、系统降级提供基础数据，减少人肉成本，定位是线下环境的测试工具。 - 2017年，Chaos Engineering被收录到ThoughtWorks Technology Radar。
- 2018年，混沌工程（Chaos Engineering）成为CNCF的一个新的技术领域。
假设性思维
前置假设：由于业务繁忙，对于非功能性需求的关注不够，存在侥幸心理。
- 常见的非功能性需求有：
- 网络是稳定的
- 单分片的故障不会影响全局
- 我的代码是完美的
- 非关键应用的故障不会影响全局
- 服务满足高并发高可用
- 监控报警已经全覆盖
- 服务降级措施是有效的
- 应用重启后能自动投产
- 增加重试就能解决问题
- 故障发生时的沟通协调是顺畅的
为何要落实混沌工程
在系统正式投入生产环境中提前暴露一些非必现但可能带来较大影响的故障。
- 以毒攻毒：使风险在可控的范围内及早暴露。
- 不破不立：持续验证系统的容灾能力。
- 常练常新：增强团队抵御风险的能力和信心。
混沌工程的原则
混沌工程的关注要点：结构化的风险，诸如支付的成功率、订单的交易量。
- 假设稳定的状态：混沌工程的演练需要一个把预期会发生的事情和实际会发生的事情进行比较的指标来衡量系统在稳定时候的状态。
- 在生产环境进行演练：混沌工程实验的环境越真实，混沌工程的实验越有价值。
- 持续地、自动地运行演练：自动和常态化，降低实验成本。
- 最小化爆炸半径：控制风险，可放可收。
- 多样化的故障场景：故障事件的分析、故障场景的抽象、故障注入与恢复的实现。
假设稳定的状态
混沌工程的演练：把预期会发生的事情和实际会发生的事情进行比较。因此，需要一个指标来衡量系统在稳定时候的状态。
- 了解核心指标在稳定时的状态
- 关注可以测量的结果
- 兼顾业务指标与系统指标
在生产环境进行演练
混沌工程的实验原则：混沌工程实验的环境越真实，混沌工程的实验越有价值。
- 系统反应会因流量模式、数据规模而不同
- 由于测试环境的流量模式、数据的规模、基础设施的架构、第三方服务的注册等等都和线上环境不一致，因此在测试环境测试通过在线上环境可能还会出现问题。
- 保持真实性和有效性，推荐使用生成环境
持续地、自动地运行实验
混沌工程的实验原则：自动和常态化。
- 像持续集成一样持续实验
- 如果一件事情很复杂，那么这件事情必然坚持不了长久。
- 降低实验成本
最小化爆炸半径
混沌工程的实验原则：控制风险，可放可收。很谨慎的、可衡量的人为故障；建议采用点、线、面、体循序渐进的方式来实验；混沌实验在生产环境中制造的故障必须可随时终止。
- 实验目标始终是控制局面，减少业务影响
- 提高异常检测、故障自愈能力
- 可随时制造故障、可随时撤销故障
多样化的故障场景
- 故障事件的分析
- 故障场景的抽象
- 故障注入与恢复的实现
以下是一些携程根据遇到的故障划分出来的分类表：
| 层次 | 故障类型 |
|---|---|
| Route | SLB拉出、SOA拉出、流量突增、限流 |
| Application | 依赖超时、依赖异常、OOM、线程池满 |
| Data | Redis宕机、Redis失效、Redis切换、Redis延迟、Redis IO高、DB连接打满、DB宕机、DB切换、DB阻塞、DB IO高 |
| OS | 服务器宕机、High CPU、High Memory、High IO |
| Network | 网络丢包、网络超时、网络中断、网卡打爆 |
混动工程的实践
混动工程的推动和落地是一个循序渐进的过程。
| 级别 | 接受度 | 复杂度 |
|---|---|---|
| 1 | 验证历史故障的修复 | 工具覆盖常见故障场景 |
| 2 | 主动设计故障场景并发起挑战 | 生产、测试环境少量演练 |
| 3 | 形成Design for failure和混沌工程的文化 | 生产关键应用的定期演练 |
| 4 | 生产设定场景的随机演练 | |
| 5 | 生产全自动化演练和验证 |
混沌工程的心得
- 坚持原则，迎难而上
- 混沌工程的核心不在于如何制造故障
- 推动监控告警、架构感知、故障定位的完善
- 大胆假设，小心求证，常态化演练
关于混动工程实验过程中的定责问题
携程混沌工程实践的实验过程中定责的流程。
- 实验中发现的问题不会走定责流程，因为混沌工程将存在的问题提前暴露出来
- 试验后发现的问题一直没有修复，将会走定责流程
附录
如果要了解更多更细致的内容，推荐阅读以下内容
