混沌工程-自动巡检前的阵痛期

前言：

    混沌工程由理论转为实战，特别是进入生产环境这一环节时会面对着最小爆炸半径和工具安全问题，这两点已经在前面文章中《混沌工程之-最小爆炸半径》、《混沌工程-故障工具的安全问题》给出了解决方案。当我们跨过这一阶段，享受着混沌工程带来的红利和乐趣时，随之而来又会面临一个新困境。对于具备一定韧性的应用，如果我们再想通过普通Test & Observe的方式来发现隐患就变成了一种劳动密集但回报甚微的体力活了。

期望：

    具备一定韧性的服务其本身具备一定容灾能力，我们可以适当扩大最小爆炸半径增加异常触发的几率，同时把复杂的人力验证演化成自动巡检，通过牺牲算(电)力(费)来进行自动挖掘。

困难：

     向ChaosToolkit这样的混沌框架把演练过程简单拆分为两个阶段：演练和稳态。演练是下发异常的动作，稳态是对异常动作影响面的判断。再通俗的点说它俩就是手和眼。手负责捣蛋，眼负责观察。手和眼的运作过程如下图：

    当我们是纯人力手动演练时，我们的“眼”可以是多个维度的，例如：错误码、用户行为、启播率、应用日志、展示页面是否跟预期一样等，都可以作为我们判断的依据；但是当我们进行自动巡检时是没有人工干预的，我们的“眼”只能看到数字化、指标类的东西，像用户行为、是否预期页面这些都看不到了，但这些确实跟我们稳态息息相关，甚至它们就是“强制终止”混沌演练的必要因素，如果舍弃这些维度，混沌演练就变成了瞎子，日常巡检不仅发现不了问题，还可能白白造成生产故障。（强调一点：混沌工程一定会造成生产故障的，但它的意义在于提前量和最小的代价）。

解决：

    混沌工程是推动监控体系完善的动力和方向，换句话说凡是混沌需要关注的指标就是有意义的指标，所以为了解决上述问题我们必须把这些指标数字化并纳入监控体系。对于用户行为此类复杂的指标设计在DataOps体系中不难找到标准答案，但对于混沌工程来说痛苦的点在于如何确定这些指标的结果是正确的？举个例子，用户行为指标因为设计或者落地上的原因导致数据不准确，我们在混沌过程中觉得一切安好，但其实用户是苦不堪言的，这期间混沌的“眼”看到的是个幻想。
    如何解决“幻想”的问题？没啥好办法，把指标是否正确做为混沌演练的目标，看看出现问题的时候指标是否能正确反映真实情况，也就是说我们得先人工对“眼”做一次混沌，确保这个指标的可信性再借助这个指标进行日常巡检。这个过程是枯燥漫长但不可省略的。

总结：

    影响混沌工程最终效果的是方案力和执行力，二合一后就是混沌文化。方案力要求我们在架构设计一开始就植入混沌的理念，为混沌留好接口；执行力要求研发过程中贯彻执行。这一切建立在企业对混沌工程的接收程度和人员的理解能力，因为毕竟在以业务为导向的开发模式下，混沌工程并不能带来直接业务上的成效，甚至可以视为“累赘”，而混沌工程又是个木桶原理，一环有问题会影响整体效果。