周末，看到三位英雄航天员在“天宫”的太空舱住满 6 个月顺利凯旋，神舟十三号工作获得圆满成功，情绪十分冲动。其实，Kindling 也有一个“太空舱”我的项目，当然，这里的“太空舱”并不是指“天宫”这种真正的太空舱，而是一种比喻，就像航天员在上太空前，不可能去实在的太空环境做训练，而是在水下搭建一套模仿的太空舱做训练，这样不仅能够以最小的老本实现各种训练和操作，而且能够让航天员体验太空环境和可能遇到的问题。
太空舱我的项目的目标是打造一套云原生环境故障模拟零碎，帮忙用户更好地了解可观测性产品的价值，并对各类故障进行预演，提前制订复原计划，这样即便呈现故障，也能够第一工夫复原，最大限度缩小损失。就像火灾演习，模仿各种火灾场景，并给出应答计划 (如何逃生、如何灭火等)。劫难(故障) 是大家都不想遇到的，但往往又是不可避免的，而劫难 (故障) 一旦呈现，个别都是影响微小的，会造成巨大损失。咱们能做的是，升高劫难 (故障) 产生的概率，缩短劫难 (故障) 复原的工夫，缩小损失。
太空舱我的项目是在 chaosblade 和 chaos-mesh 等混沌工程的根底上，构建了一套规范的业务链，实现故障的一键注入和复原，并以 demo 的模式出现进去，从而防止将故障注入实在环境引发的一些平安危险。
demo 业务链
1. 故障注入(以注入 case1 为例)
2. 故障复原(以复原 case1 为例)
目前太空舱已构建了十几个故障场景，用户能够间接应用咱们的太空舱环境 (为防止抵触，须要提前申请，能够通过文末微信与咱们分割)，也能够只用故障脚本在本人的环境上模仿故障，如果用户感觉故障脚本不全，或者遇到新的故障类型，欢送补充和丰盛故障脚本，一起将其打造成能够模仿云原生畛域全故障域的零碎，以推动云原生可观测性产品的演进和倒退。针对模拟出的故障能够自行抉择监控工具来定界问题，通过比照选出最优和最适宜本人的解决方案(效率、应用门槛、准确性等)。
已构建故障场景和起因列表
当然，太空舱我的项目目前还有一些不欠缺的中央，如 (1) 以后的故障是依据咱们已有的教训设计的，与真实情况是否存在差异以及是否有缺失还须要工夫验证和欠缺；(2)以后故障脚本的实现存在较多依赖，如果在本人的环境上运行可能会呈现一些未知的谬误。如果在应用过程中遇到问题，欢送通过下方二维码与咱们交换或者间接在我的项目中提 issue。
我的项目 Github 地址：太空舱我的项目
在云可观测性方面有任何疑难欢送与咱们分割：
微信
公众号