上周我们一行去了美团进行进行交流，美团分享了 Mesh 、DB 、云存储三个主题，我们分享了 Mesh 、虚拟化、混沌工程三个主题。
其中我们分享混沌工程时引起了大家较大兴趣，我用 QA 的方式总结记录了当时大家关心的几点，分享给大家，一起讨论。
Q：为什么搞？
A：架构在设计上避免了很多故障诱因，但故障诱因自己发生的概率太小，也不可控，无法达到主动检查系统健壮性的目的。
Q：你们真随机宕机啊？
A：是的。我们每天选择两组，一组人工指定的，用于针对性的检查；一组随机选出的，用于保证覆盖面（因为人会在主观上避免选择重要服务的）。
Q：宕机造成数据不一致怎么办？
A：服务器自然宕机，也会造成数据不一致。如果对此无法接受，应从架构上予以解决。
Q：业务同意你们这么做吗？
A：同意，这样可以帮助业务提前发现自己系统中的问题。流程恰当不给业务带来太多烦恼的话业务自然不反对。
Q：搞出问题来谁负责？
A：谁的技术模块出的问题谁负责。
Q：提前约定好什么时候操作吗？
A：提前通知大概范围，但不告知具体时间，因为系统稳定时期，大家对生产环境中的异常会越来越生疏，还要借此培养技术同学对线上问题的响应敏感度（尤其是在和平时期）。
Q：发现了多少问题？
A：很多问题。一类是系统自身缺陷；第二类是系统原来没问题，在漫长的变更后，变得有问题了。
Q：除了宕机还有什么操作？
A：主要是宕机，所有自然发生、完全无法避免的故障诱因都算。
Q：你们怎么控制爆炸半径？
A：事前预估起到主要作用，若业务方在通知阶段反馈有较大风险则不予执行，但会记录并设定一个修复时间，到时优先重新检测；
在执行过程中，因为各种意外事件导致的问题，则承担风险（因为操作时诱因明确，解决起来更快一些，否则问题自然发生时，肯定会是个更严重的问题，从这个方面讲是有很大收益的）。
大家若在北京望京附近，也欢迎线下交流哈哈哈哈

大佬有話說 (2)