做软件的人：“工作体验好，好事才能来。” 双十一后第一天，阿里云崩了 从下图能看出，这次虽然只崩了3个多小时，但受影响的产品多，地域广。如图1。 图1这次崩了受影响的产品多，地域广 应该说，阿里云的健康状态页设计得还是很不错的。 我很快就能找到这次崩了的持续时长，以及所影响的产品和地域。点赞！ 我在8月3日发过一篇知乎想法，对比了阿里云从2018到2022年这5年来，崩得很严重的3次生产事故复盘报告对比图。如图2。图2阿里云从2018到2022年这5年来，崩得很严重的3次事故复盘报告对比图 相信阿里云这次崩了后，很快也会发布一份详细的“事件说明”。 但…… 阿里云崩了，我们更愿意读“事件说...

做软件的人：“工作体验好，好事才能来。” 1太长不读 从2023年8月到10月，我花了3个月自学docker和k8s。踩了一路坑，到10月22日终于把一个带有vue.js3前端、springboot后端以及postgres数据库的shoppinglistwebapp，部署到azurek8sservice云上，并能正常运行。 之所以说踩了一路坑，是因为网上分享的k8s部署webapp的样例，都是部署一个web服务。讲ingressnginxcontroller的样例虽然会涉及两个微服务，但在这种根据path设定将请求分配给两个helloworld的web微服务场景中，两个微服务之间，是没有前...

注意：本文已过时。请看最新版：2023-07-05修订版：懂人的软件开发：不现实的机器化软件人假设 https://zhuanlan.zhihu.com/p/641562423 我是70后。1993年从大学计算机应用专业毕业后，就一直在企业IT部门一线团队，从事软件开发和咨询工作。先后在国企、私企和外企，做过IT系统管理、Web应用开发、软件测试、项目管理和软件开发咨询。2014至2022年，我在Thoughtworks公司做过8年的软件开发技术教练，帮助几十家企业的IT部门，落地持续集成和自动化测试等敏捷软件工程实践。2022年底我从Thoughtworks公司离职，成为独立咨询师...

注意：本文已过时。请看最新版：2023-07-05修订版：不现实的“机器化软件人假设”v2.0与“容许自由的温和家长制”助推 https://zhuanlan.zhihu.com/p/639754786 在上一篇文章“懂人心的软件开发：不现实的机器化软件人假设”中，我们谈到了机器化软件人假设，是不懂人心的软件开发背后的原因。对于这个假设，当时的定义是“软件人，尤其是企业IT部门的管理者和相关业务部门的管理者，会不自觉地把非管理者的软件人，看作是可按照预设好的逻辑，随时运转的机器，或者运行指令的代码模块，且能随时替换”。由于作为管理者的软件人，也会被她/他的管理者在锚定效应的作用下，当...

什么是混沌工程？用一句简单的话来解释，就是使用科学方法，用做有对照组的实验，来实证复杂的分布式软件系统，能够在生产环境抵御来自现实世界不可预知的各种状况。 混沌工程在官网(PRINCIPLESOFCHAOSENGINEERING)的正式定义，是一门对软件系统进行实验的学科，目的是建立对系统承受生产环境中动荡条件的能力的信心。 承受生产环境中动荡条件 根据InfoQ最近3年推出的DevOps和云技术趋势鸿沟曲线显示，在国外，混沌工程实践已经在2022年跨过早期采纳者和早期大众之间的鸿沟，进入业界主流。因为国内业界对于创新工程实践的采纳相对滞后，估计混沌工程在国内应该有3～5年左右就能跨过鸿沟...

做软件的人，不管你是管理者、业务人员、需求分析人员、开发人员、测试人员、运维人员，在IT技术和过程推陈出新和突飞猛进的时代，很容易被人忽悠。你是不是经常发现，出于从众心理，你投入时间和金钱，读书和听课，学习并实践了身边其他人所热捧的新技术和新过程，从设计思维，到敏捷，到精益，到DevOps，到持续交付，到TDD，到DDD，到整洁架构，到基础设施即代码，到混沌工程，到AIGC。学了和用了一圈下来，结果发现，软件质量仍然较差，用户价值仍然较低，软件交付仍然延期。你感觉被人忽悠了。 如何才能不被忽悠？ 如何才能不被别人忽悠？方法只有一个，就是用科学方法自己动手做实验，来验证书上和大佬所说的技术和过程...

作为企业IT部门某个开发团队负责人的你，从书上和大佬那里得知，软件开发团队，如果采用持续集成实践，那么就能降低软件开发过程中的返工。 于是你按照书中和大佬所说的，在团队工位显眼位置，摆放了一个大显示器，并接上持续集成流水线。 你喊团队中所有的5位开发人员来开会，告诉他们，一旦流水线运行出现问题，比如编译打包错误或自动化测试运行失败，显示器就会显示告警的红色/黄色画面。团队中无论谁看到了红色/黄色告警，第一时间就要放下手中工作，及时修复流水线。团队中的其他人，也要配合这位同事的修复工作。 开发人员都答应了。 但很快你就发现，你所辛辛苦苦搭建的流水线健康显示屏，其实就是一个摆设。团队开发人员根本就...

作为企业IT部门某个开发团队负责人的你，从书上和大佬那里得知，软件开发团队中的开发人员，如果在将所完成的功能提交给测试人员之前，加强自测，那么就能降低软件开发过程中的返工。 于是你为每位开发人员，都准备了自测环境。然后告诉开发人员，在完成功能的开发，向测试人员提测前，需要在自测环境完成自测。 但很快你就发现，测试人员还是经常抱怨，开发人员即使拥有自测环境，但所提测的代码，经常连基本的功能都没有跑通，需要打回去修复。 这个问题该如何破？ 你读了塞勒和桑斯坦的《助推》，其中行为经济学的“锚定效应”和“心理账户”给了你很大的启发。即开发人员对于自测的态度，被其岗位名称“开发”所锚定，即“开发”意味着...

系统红蓝军，不仅可以引导开发人员做好功能自测，更可以在不增加成本的情况下，引导企业有效应对生产系统稳定性意外故障。 1基于观察 企业经常出现意料之外的软件系统生产环境稳定性故障。 2问出问题 是什么原因导致企业经常出现意料之外的软件系统生产环境稳定性故障？ 3形成可验证的解释性假说 企业经常出现意料之外的软件系统生产环境稳定性故障，原因来源于管理者和工程师存在以下4种心理特点。 第一，过度自信(Overconfidence)。即人们经常高估自己的绝对能力，并高估与其他大部分人相比的相对能力。在判断和决策方面，没有什么问题比过度自信更容易发生，也更有可能造成灾难。 第二，确认性偏见(Confir...

在K8S上部署的微服务，经常会依赖不受你控制的其他微服务。当两者之间的HTTP交互出现延迟或错误后，你的微服务能否按预期正常工作？应该做一个故障注入实验来检验一下。如果在K8S上使用了Istio，那么恭喜你，你已经拥有了简单易用的混沌工程开源工具。 官网 https://github.com/istio/istio 一句话介绍 虽然Istio主要作为K8S服务网格，用于连接、保护、控制和观察服务，但在其流量管理功能中也支持故障注入。 关键特性 Istio可以将HTTP延迟或HTTP错误注入任何虚拟服务之间的网络流量中。实验以Kubernetesmanifest形式定义。可以使用现有的Isti...

ChaosBlade可针对多达7个场景开展故障注入实验，但网上官方的中英文文档质量欠佳，内容缺失，真心没有站在一般用户的角度来写，只能通过运行blade命令的help了解究竟有什么功能。 官网 https://github.com/chaosblade-io/chaosblade 一句话介绍 ChaosBlade是阿里巴巴开源的针对7个检验软件系统稳定性场景的混沌工程故障注入开源工具：主机基础资源、CRI容器、K8S平台、Java应用、C应用、阿里云平台、其他服务。 关键特性 以下关键特性，是我下载ChaosBladev1.7.2，在运行blade时带上help参数，一点点试出来的。官网gi...

Litmus最初是OpenEBS（K8S下存储系统）的测试工具，后来发展成为知名的Kubernetes原生混沌工程开源平台。 创建者 MayaData 一句话介绍 LitmusChaos是一个在故障创建与编排方面更胜一筹的K8S混沌工程开源平台，如提供故障注入实验库ChaosHub，使团队能够以受控方式，引入故障注入实验来识别基础设施中的弱点和潜在停机隐患。 Litmus2.0关键特性 故障注入实验场景创建与编排 可用以下方式创建实验：实验模板，使用ChaosHub的实验从头自定义，预先创建的YAML实验。支持故障注入实验调度（并行和顺序执行步骤）。可安排单次或Cron定时故障注入场景。可以...

ChaosMesh是针对K8S的云原生混沌工程开源平台。可以用它方便地模拟开发、测试、生产环境中可能出现的各种异常情况，发现系统中潜在的问题。 创建者 研发支持混合事务与分析处理的开源数据库TiDB的PingCap公司 一句话介绍 ChaosMesh是针对K8S的云原生开源混沌工程平台。 关键特性 ChaosMesh的关键特性包括可注入的故障、实验工作流、可视化操作和安全控制。 可注入的故障 可注入的故障，包括基本资源故障，平台故障和应用故障这3类。 基本资源故障，包括模拟Pod失效，网络失效，DNS失效，HTTP通信延迟，CPU或内存使用高负荷，文件读写失效，时间跳跃异常，应用内存分配异常...