这些年，随着，微服务架构，的，普及，系统，变得，越来越，复杂。系统的，可靠性，也，变得，越来越，重要。

为了，提升，系统的，弹性，和，可靠性，我们团队，从，两年前，开始，实践，混沌工程。

混沌工程，简单来说，就是，通过，主动，注入，故障，来，测试，系统的，弹性，和，可靠性。通过，主动，制造，故障，来，发现，系统中，潜在的，问题，然后，修复，它们，从而，提升，系统的，可靠性。

这些年，我们，在，混沌工程，方面，做了，不少，实践，也，踩了，不少，坑。今天，想，分享一下，我们，在，混沌工程，实战中，踩过的，那些，坑，以及，从中，总结的，经验教训。

希望，这些，经验，能，帮，大家，少走弯路，更好地，落地，混沌工程。

一、坑一：上来就，在生产环境，搞大动作

我们，刚开始，做，混沌工程，的时候，犯了，一个，很大的，错误：上来就，在，生产环境，搞大动作。

那时候，我们，刚，了解，混沌工程，觉得，这个，方法，很，酷，很，有效。Netflix，不是，一直在，生产环境，搞，混沌工程吗？他们，还，搞了，一个，Chaos Monkey，随机，杀，实例。我们，觉得，我们，也，可以，这么干。

于是，我们，在，没有，充分，准备的，情况下，就在，生产环境，开始，注入，故障了。

我们，选了，一个，非核心的，服务，随机，杀掉了，一个，实例。本来，以为，这个，服务，有，多个，实例，杀，一个，应该，没什么，问题。

结果，没想到，这个，服务，虽然，有，多个，实例，但是，负载均衡，的，配置，有，问题。杀掉，一个，实例，之后，流量，没有，正确地，切换，到，其他，实例。导致，这个，服务，出现了，大量的，503错误，影响了，上游的，几个，服务。

虽然，不是，核心服务，但是，也，造成了，一定的，影响。我们，赶紧，恢复了，实例，才，解决了，问题。

这次，事件，给，我们，敲了，警钟。混沌工程，不是，随便，搞的。在，生产环境，搞，混沌工程，一定要，非常，谨慎。

经验教训：

  1. 从，测试环境，开始：刚开始，做，混沌工程，应该，先，在，测试环境，或者，预发布环境，进行。等，积累了，足够的，经验，对，系统，有了，充分的，了解，之后，再，逐步，推广到，生产环境。
  2. 从小范围，开始：即使，在，生产环境，做，混沌工程，也要，从，最小的，范围，开始。先，注入，最小的，故障，比如，延迟，几毫秒，或者，杀掉，一个，非核心的，实例。观察，系统的，反应，确认，没问题，之后，再，逐步，扩大，范围。
  3. 充分，准备：在，注入，故障，之前，一定要，充分，准备。了解，系统的，架构，依赖，容量，容错，机制。制定，详细的，实验计划，和，回滚方案。确保，有，足够的，监控，和，告警，能，及时，发现，问题。
  4. 有，完善的，回滚机制：混沌工程，实验，一定要，有，完善的，回滚机制。一旦，发现，问题，能，快速，恢复，系统，把，影响，降到，最低。

二、坑二：没有，定义，稳态假设

混沌工程，的，核心，是，稳态假设。也就是，你，认为，系统，在，正常情况下，应该，表现出，什么样的，行为。

在，注入，故障，之后，你，要，观察，系统，是否，偏离了，稳态假设，从而，判断，系统的，弹性，如何。

但是，我们，刚开始，做，混沌工程，的时候，没有，定义，稳态假设。

我们，只是，注入，故障，然后，看看，系统，有没有，出问题。但是，什么，叫，"出问题"？我们，没有，明确的，标准。

有时候，注入，故障，之后，系统的，错误率，上升了，一点，但是，我们，不知道，这，算不算，问题。是，正常的，降级，还是，异常的，表现？

有时候，注入，故障，之后，系统，看起来，没什么，问题，但是，实际上，有，一些，隐性的，影响，我们，没有，发现。

因为，没有，稳态假设，我们的，混沌工程，实验，变得，很，盲目。不知道，要，观察，什么，不知道，怎么，判断，实验，的，结果。

经验教训：

  1. 明确定义，稳态假设：在，做，混沌工程，实验，之前，一定要，明确定义，稳态假设。稳态假设，应该，是，可量化的，可观测的。比如，"系统的P99延迟，应该，小于，200毫秒"，"系统的错误率，应该，低于，0.1%"，"系统的可用性，应该，达到，99.9%"。
  2. 选择，合适的，指标：稳态假设，要，基于，合适的，指标。不要，只，看，基础设施的，指标，比如，CPU，内存，磁盘。更，重要的，是，看，业务的，指标，比如，请求量，延迟，错误率，转化率，等等。业务指标，更能，反映，系统的，真实，健康状况。
  3. 有，基线数据：在，注入，故障，之前，要，收集，系统，在，正常情况下的，基线数据。这样，在，注入，故障，之后，才能，对比，发现，偏离。
  4. 实验后，分析，结果：实验，结束，之后，要，认真，分析，结果。看看，系统，是否，偏离了，稳态假设。如果，偏离了，原因，是什么？如何，修复？如果，没有，偏离，说明，系统，在，这个，故障，下，是，有弹性的。

三、坑三：爆炸半径，控制，不好

爆炸半径，是，混沌工程，中，一个，非常，重要的，概念。它，指的是，故障，可能，影响的，范围。

我们，在，混沌工程，实践中，踩过的，另一个，大坑，就是，爆炸半径，控制，不好。

有一次，我们，想，测试，数据库，的，容错能力。我们，计划，把，主库，的，网络，断开，看看，系统，能不能，自动，切换，到，从库。

我们，本来，以为，这个，故障，只会，影响，一个，服务。因为，只有，这个，服务，用了，这个，数据库。

结果，没想到，这个，数据库，其实，被，好几个，服务，共用。我们，之前，梳理，依赖，的时候，漏掉了，几个，服务。

断开，主库，网络，之后，好几个，服务，都，受了，影响。其中，还有，一个，比较，核心的，服务。导致，核心功能，出现了，一段时间的，不可用。

这次，事故，影响，比较大，我们，花了，不少，时间，才，恢复。

这次，事件，让我们，深刻地，认识到，爆炸半径，的，重要性。

经验教训：

  1. 充分，梳理，依赖关系：在，注入，故障，之前，一定要，充分，梳理，系统的，依赖关系。搞清楚，这个，故障，可能，会，影响，哪些，服务，哪些，功能。不要，想当然，以为，只会，影响，某个，服务。
  2. 从小范围，开始，逐步扩大：即使，你，觉得，已经，充分，了解了，依赖关系，也要，从，最小的，范围，开始，注入，故障。先，在，测试环境，试，然后，在，生产环境，的，一小部分，实例，试，然后，再，逐步，扩大。
  3. 使用，流量，隔离：可以，使用，流量，染色，或者，蓝绿部署，等，方式，把，混沌工程，实验的，流量，和，正常流量，隔离开。这样，即使，实验，出了，问题，也，只会，影响，一小部分，用户。
  4. 设置，明确的，终止条件：在，实验，之前，要，设置，明确的，终止条件。比如，错误率，超过，1%，就，立即，停止，实验。延迟，超过，500毫秒，就，立即，停止，实验。这样，一旦，实验，出了，问题，能，及时，停止，把，影响，降到，最低。
  5. 有，专人，盯盘：在，实验，过程中，一定要，有，专人，盯盘，监控，系统的，各项，指标。一旦，发现，异常，立即，停止，实验，恢复，系统。

四、坑四：只，搞，一次性的，实验

我们，刚开始，做，混沌工程，的时候，把，它，当成了，一个，一次性的，活动。

比如，我们，会，在，某个，时间，集中，做，一批，混沌工程，实验。然后，就，很久，不做了。

但是，后来，我们，发现，这样，效果，很，有限。

因为，系统，是，在，不断，变化的。今天，系统，在，某个，故障，下，是，有弹性的。不代表，明天，系统，改了，之后，还是，有弹性的。

而且，很多，问题，不是，一次，实验，就能，发现的。有些，问题，需要，多次，实验，才能，复现，和，发现。

我们，有一次，做，一个，故障，注入，实验，第一次，做，系统，表现，正常，没发现，问题。但是，过了，一个月，再，做，同样的，实验，却，发现了，一个，严重的，问题。因为，这，一个月，系统，改了，不少，代码，引入了，一个，bug。

如果，我们，只，做，一次，实验，就，发现不了，这个，问题。

经验教训：

  1. 混沌工程，要，常态化：混沌工程，不是，一次性的，活动，而是，一个，持续的，过程。要，把，混沌工程，融入到，日常的，开发，和，运维，流程中。定期，做，混沌工程，实验。
  2. 自动化，混沌工程：为了，让，混沌工程，常态化，要，尽量，自动化，混沌工程，实验。可以，用，一些，混沌工程，平台，或者，工具，自动，注入，故障，自动，监控，自动，分析，结果。这样，就，不需要，人工，手动，做，实验，了，能，大大，降低，成本。
  3. 回归，测试：每次，系统，有，大的，变更，之后，都，应该，做，混沌工程，的，回归，测试。确保，变更，没有，破坏，系统的，弹性。
  4. 持续，改进：混沌工程，实验，发现的，问题，要，及时，修复。然后，再，做，实验，验证，修复，的，效果。这样，持续，改进，系统的，可靠性。

五、坑五：只，关注，技术，忽略，文化

混沌工程，不仅仅，是，一个，技术，问题，更是，一个，文化，问题。

我们，刚开始，做，混沌工程，的时候，只，关注，技术，层面，的，东西。比如，用，什么，工具，注入，故障，怎么，监控，怎么，分析。

但是，我们，忽略了，文化，建设。

结果，发现，推进，混沌工程，阻力，很大。

很多，开发，同学，对，混沌工程，有，抵触情绪。他们，觉得，混沌工程，就是，在，搞破坏，在，给，他们，找麻烦。他们，担心，混沌工程，实验，会，搞挂，系统，影响，他们的，工作。

很多，运维，同学，也，不支持。他们，觉得，系统，运行得，好好的，为什么，要，主动，搞，故障？万一，搞出，问题，谁，负责？

因为，没有，文化，的，支持，我们的，混沌工程，实践，推进得，很，艰难。很多，实验，都，没法，做。

后来，我们，意识到了，文化，的，重要性，开始，重视，文化，建设。

我们，组织了，多次，分享，和，培训，让，大家，了解，混沌工程，的，理念，和，价值。我们，让，大家，明白，混沌工程，不是，为了，搞破坏，而是，为了，发现，问题，提升，系统的，可靠性。

我们，还，从，小的，实验，开始，让，大家，看到，混沌工程，的，效果。比如，我们，在，测试环境，做了，一个，实验，发现了，一个，潜在的，问题。然后，我们，修复了，这个，问题。后来，这个，问题，真的，在，生产环境，差点，触发。如果，不是，混沌工程，提前，发现了，可能，就，会，造成，线上，事故。

通过，这样的，例子，大家，逐渐，认识到了，混沌工程，的，价值。抵触情绪，也，慢慢，减少了。

经验教训：

  1. 文化，先行：在，推进，混沌工程，之前，一定要，先，做，文化，建设。让，团队，理解，混沌工程，的，理念，和，价值。只有，大家，都，认可了，混沌工程，才能，顺利，推进。
  2. 高层，支持：混沌工程，的，推进，离不开，高层的，支持。要，争取，高层的，理解，和，支持，让，高层，为，混沌工程，背书。这样，推进，起来，会，顺利，很多。
  3. 从，小处，着手：不要，一开始，就，搞，大动作。从，小的，实验，开始，让，大家，看到，混沌工程，的，效果，和，价值。用，事实，说话，比，空口，说白话，有效，得多。
  4. 建立，容错，的，文化：混沌工程，实验，可能，会，出问题。要，建立，容错，的，文化。不要，因为，实验，出了，问题，就，追责，和，惩罚。否则，大家，就，不敢，做，实验，了。要，把，实验，出问题，当成，一次，学习，的，机会，而不是，追责，的，理由。
  5. 全员，参与：混沌工程，不是，只有，运维，或者，SRE，的，事。开发，测试，产品，都，应该，参与，进来。只有，全员，参与，才能，真正，提升，整个，系统的，可靠性。

六、坑六：工具，选型，盲目

混沌工程，的，工具，也，很，重要。我们，在，工具，选型，上，也，踩过，坑。

刚开始，我们，看到，Netflix，开源了，Chaos Monkey，就，直接，拿来，用。

但是，用了，一段时间，发现，Chaos Monkey，功能，比较，简单，只能，随机，杀，EC2，实例。我们，的，系统，比较，复杂，需要，更多，类型的，故障，注入，比如，网络，延迟，网络，丢包，CPU，压力，内存，压力，磁盘，IO，压力，等等。

而且，Chaos Monkey，和，我们，的，技术栈，也，不是，很，匹配。我们，的，服务，不是，都，跑在，EC2，上，还有，跑在，容器，里的，还有，跑在，物理机，上的。

后来，我们，又，试了，几个，其他的，工具，都，不太，满意。最后，我们，决定，自己，开发，一个，适合，我们，的，混沌工程，平台。

虽然，自己，开发，花了，不少，时间，和，精力，但是，最终，做出来的，平台，很，适合，我们，的，需求，用起来，也，很，顺手。

经验教训：

  1. 不要，盲目，跟风：不要，看到，别人，用，什么，工具，就，盲目，跟风。每个，团队，的，技术栈，需求，都，不一样。适合，别人的，工具，不一定，适合，你。
  2. 先，明确，需求：在，选，工具，之前，先，明确，自己的，需求。你，需要，哪些，类型的，故障，注入？你，的，技术栈，是什么？你，需要，哪些，功能？明确了，需求，再，去，选，工具，会，更，有针对性。
  3. 充分，调研：现在，混沌工程，的，工具，很多，开源的，商业的，都有。要，充分，调研，各个，工具，的，功能，特点，优缺点，适用场景。然后，选择，最，适合，自己的。
  4. 可以，自己，开发：如果，现有的，工具，都，不，适合，你，的，需求，那么，可以，考虑，自己，开发。混沌工程，的，核心，原理，并不，复杂。自己，开发，一个，简单的，混沌工程，平台，并不是，很难的，事。而且，自己，开发的，工具，最，适合，自己的，需求。
  5. 工具，只是，辅助：最后，要，记住，工具，只是，辅助。混沌工程，的，核心，是，理念，和，文化。没有，正确的，理念，和，文化，再好的，工具，也，没用。

七、写在最后

以上，就是，我们，在，混沌工程，实战中，踩过的，一些，坑，以及，总结的，经验教训。

混沌工程，是，一个，非常，好的，方法，能，帮，我们，提升，系统的，弹性，和，可靠性。但是，它，也，不是，银弹，不是，随随便便，就能，做好的。

要，做好，混沌工程，需要，有，正确的，理念，充分的，准备，合适的，工具，完善的，流程，以及，全员，参与的，文化。

希望，我们，踩过的，这些，坑，能，帮，大家，少走弯路，更好地，落地，混沌工程。

如果你，也，有，混沌工程，的，实践，经验，或者，踩过的，坑，欢迎，在，评论区，留言，我们，一起，交流。