ITPub博客

从源代码到docker compose再到k8s云集群，开发与部署前后端分离web应用。练了3个月，文章写了4天。一万三千字。分享了8个避坑指南。先发布mac版。Windows10和unbuntu版随后发布。[憨笑]

Chaos Mesh 是针对K8S的云原生混沌工程开源平台。 可以用它方便地模拟开发、测试、生产环境中可能出现的各种异常情况，发现系统中潜在的问题。

LitmusChaos 是一个在故障创建与编排方面更胜一筹的K8S混沌工程开源平台，如提供故障注入实验库 ChaosHub，使团队能够以受控方式，引入故障注入实验来识别基础设施中的弱点和潜在停机隐患 。

ChaosBlade可针对多达7个场景开展故障注入实验，但网上官方的中英文文档质量欠佳，内容缺失，真心没有站在一般用户的角度来写，只能通过运行blade命令的help了解究竟有什么功能。

在K8S上部署的微服务，经常会依赖不受你控制的其他微服务。当两者之间的HTTP交互出现延迟或错误后，你的微服务能否按预期正常工作？应该做一个故障注入实验来检验一下。如果在K8S上使用了Istio，那么恭喜你，你已经拥有了简单易用的混沌工程开源工具。

开发、测试和运维这三个岗位之间的关系，可以转变为红蓝军对抗。这样就能有效克服管理者和工程师的过度自信、确认性偏见、从众效应和注意力顾此失彼等心理特点所带来的负面影响，减少意料之外的软件系统生产环境稳定性故障，并提升故障的修复速度和质量。

开发和测试人员的岗位，分别改名为*系统红军*和*系统蓝军*。系统红军需要对所设计和编写的软件特性在整个系统中正常运行负全责，而系统蓝军需要从整个系统的角度模拟现实生产环境各种刁钻的场景来考验系统红军所设计和实现的软件特性，能否正常运行。那么这两个岗位之间的关系，就转变为红蓝军对抗。这样是否能摆脱锚定和心理账户，从而助推开发人员进行自测？

如果将工位附近的流水线健康显示屏撤掉，并要求每位开发人员，在向流水线合并代码后，需要通过自己的电脑显示器，观察流水线健康状态。直到状态变为健康的绿色，才算合并成功。若其间发现红色/黄色告警，因为只有她/他一人在场，周围没有旁观者，那么她/他主动修复流水线所发现的问题的概率会达到最大。

读书虽然能很快得到结论，但难以说明结论一定适用于你，且难以揭示结论背后的原因。访谈只能揭示相关性，无法揭示因果性。相关性不等同于因果性。揭示因果性的唯一方法，就是用科学方法做实验。

人们普遍具有的7个社会和心理特点，让我们难以挡住所有校园安全事故。为此应该跳出框框和“惯例”来排查校园安全隐患，并且承认安全事故会像火灾一样必然发生，需要加强事后安抚家长的应急演练。

人们普遍具有的7个社会和心理特点，让我们难以挡住所有校园安全事故。为此应该跳出框框和“惯例”来排查校园安全隐患，并且承认安全事故会像火灾一样必然发生，需要加强事后安抚家长的应急演练。

如果你们的混沌工程实践，给你一种在小池塘中荡舟的四平八稳的感觉，那你就搞错了。混沌工程要给你的，是面对大海般动荡和不确定的生产环境事件的震撼感觉。

*开发团队持续集成流水线纪律落地的实际成效，还取决于在一条流水线上工作的开发人员数量*。数量越少，效果越好。在一条流水线上工作的开发人员，意味着他们的代码最终都会合并到这条流水线上。上述预测，是根据社会心理学的*责任稀释假说*做出的。

企业制定的包含了技术和过程的软件开发规范，好比葡萄酒。而软件人的人性化心理特点好比氧气。如果无视氧气的存在，在打开葡萄酒后任其氧化，后浓郁的葡萄酒，就会变成酸涩的葡萄酒醋。

业界只重视技术和过程，忽视软件人的心理，导致软件人消极应付开发规范。懂人心的软件开发，将心理学和行为经济学研究成果，应用于软件工程和敏捷软件开发，用助推方法，以较低成本，让软件人在工作中自然做出提升软件产品质量和用户价值的行为。