吾真本-从右往左混沌考验：“意外事件助推避坑”与混沌工程_

从右往左混沌考验：“意外事件助推避坑”与混沌工程 吾真本-独立软件开发咨询师 吾真本 独立软件开发咨询师 很多人35岁不写代码，我53岁仍在享受写代码，测试，咨询。 吾真本 独立软件开发咨询师 2021年开始涉足混沌工程咨询，曾为某金融公司的运维部门，成功交付混沌工程咨询服务，成为Thoughtworks公司中国区首批交付混沌工程咨询项目的咨询师； “吾真本说混沌工程”知乎专栏主； 目录 当前生产事故复盘实践的三大缺点1 三大缺点给做软件的人所带来的三大痛点2 “意外事件助推避坑”四大价值点3 什么是“意外事件助推避坑“？4 如何实现“意外事件助推避坑”？5 作为看到IT系统生产意外事件，就有如何助推避坑冲动的混沌工程迷，我这3年研究了不少“意外事件助推避坑”案例，今天就和大家聊聊我这几年“意外事件助推避坑”与混沌工程实践的经验，干货如下： 2023.10.23语雀意外事件时用户界面 当前生产事故复盘实践的三大缺点 当前生产事故复盘实践的三大缺点 1复盘报告分享难：生产意外事件复盘报告一般仅供IT团队相关少数几人阅读，使得企业大部分做软件的人不了解以往生产意外事件所揭示的避坑要点，增大了重蹈覆辙的风险，导致再次踩坑； 2演练考试非考验：仅针对运维部门感兴趣的基础设施层的意外事件（如CPU/内存/磁盘/进程/服务/主机等事件）进行演练，而忽视因程序bug所导致的意外事件演练。当在现实中真正遇到后者，由于缺乏演练，忙乱中难以做出正确判断和行动； 3缺乏亲身体验感：仅阅读复盘报告，难以亲身体会意外事件发生场景，容易忽视之前所发现过的陷阱。 三大缺点给做软件的人所带来的三大痛点 三大缺点给做软件的人所带来的三大痛点 1难被认可 “不出问题，不懂的人不知道你做了什么。”“出了问题，就生气指责你到底做了什么。”（复盘报告分享难）； 2心里发虚 意外事件抢修中由于缺乏演练心发虚（演练考试非考验）； 3很快遗忘 读完意外事件复盘没有实操很快就忘（缺乏亲身体验感）。 “意外事件助推避坑”四大价值点 “意外事件助推避坑”四大价值点 1领导更认可 将避坑指南写得利他且易懂以提升稳定性保障领导认可度；2更多人学到将生产事故复盘改名为避坑指南以方便扩大分享学习范围；3练过心不慌练过各方重视的停机长和损失大的意外事件后遇事则不慌；4印象更深刻避坑指南与定期演练相配套以让已发现陷阱印象生动深刻。 什么是“意外事件助推避坑”？ 什么是“意外事件助推避坑”？ 什么是“事件”？ 指导致系统不可用或离线的特定事情的发生。包括计划外事件和计划内事件。意外事件指计划外事件。 什么是“助推”？ 营造容许自由选择的温和环境，引导人们从意外事件中体验到避坑要点，从而印象深刻，有助于避免重蹈覆辙。比如将“生产事故复盘”改名为“意外事件避坑指南”以方便扩大分享学习范围。 如何实现“意外事件助推避坑”？ “意外事件助推避坑”的原则 预防虽重要，难免遇意外。修复意外时，系统仍可用。不去指责人，实操印象深。利他且易懂，领导更认可。 业界普遍缺乏“可隔离”、“可替换”和“可避坑”这三种有助快速修复的思维 2023.10.23语雀意外事件简介 起止时间：2023.10.23 14:00 ~ 22:00 影响：华东地区生产环境存储服务器被误下线。导致语雀数据服务发生严重故障，造成大面积的服务中断。 根因：新的运维升级工具bug导致。 修复方案：从备份中恢复数据，新建存储系统 时间线： 15:00确认因存储系统使用的机器类别较老，无法直接操作上线，立即调整恢复方案为从备份系统中恢复存储数据。 15:10开始新建存储系统，从备份中开始恢复数据，由于语雀数据量庞大，此过程历时较长； 19:00完成数据恢复；同时为保障数据完整性，在完成恢复后，用时2个小时进行数据校验； 可隔离-以语雀意外事件为例说明如何实现“意外事件助推避坑” 稳态假说：华东地区生产环境存储服务器被某种原因下线后，在重新上线之前，存储服务器事件点可隔离，即不影响前端应用正常使用，且前端应用仍可向用户报告整个系统现状。 可避坑-反模式-以语雀故障公告为例说明如何撰写“意外事件避坑指南” 1缺少上下文：只站在意外事件直接负责团队的角度撰写，缺乏“存储系统所使用的机器类别较老，无法直接操作上线”的背景介绍，导致其他团队的读者在阅读避坑指南时，产生误解，难以理解。 2使用术语且不做解释：避坑指南中使用了“Region”、“多副本容灾”、“两地三中心”等术语，但是没有解释，导致不是做软件的读者在阅读时，难以理解，进而对避坑产生怀疑。 3缺乏意外事件确切的影响数据：只提到意外事件持续7个多小时，缺乏其他数据，导致难以判断事件所影响的用户范围等规模程度，也难以判断意外事件何时完全恢复。 4缺乏触发因素的底层细节描述：只提供了意外事件的高层次描述，难以判断意外事件的最底层根本原因，比如难以了解“在升级中新的运维工具”具体出了什么bug，这难以在将来实现避坑。 可避坑-反模式-以语雀故障公告为例说明如何撰写“意外事件避坑指南”（续） 5缺乏意外事件恢复的细节描述：读者希望了解如何能缓解意外事件的影响的实际措施细节，比如数据恢复、数据校验和联调细节，以便学习和分析。 6缺乏可验证的预防措施：“运维团队加强运维工具的质量保障与测试，杜绝此类运维bug再次发生”听起来不错，但是缺乏具体的可执行的措施，更缺乏可验证性，让读者怀疑是否能真正实现。 7具有指责意味：在避坑指南中，提到“运维团队加强运维工具的质量保障与测试，杜绝此类运维bug再次发生”，这句话的潜台词是，运维团队没有做好工作，导致意外事件发生。这种指责会促使运维团队产生抵触情绪，会心里反问：“为何语雀不做异地双活？”，难以实现避坑。 8分享范围有限：避坑指南只在内部分享，导致其他团队和用户无法学习和了解，无法重塑信心，也无法提供反馈。（语雀这一点做得较好） 9延迟发表：避坑指南在意外事件发生后，经过了很久才发表，难以实现避坑。（语雀这一点做得较好） 可避坑-模式-以语雀故障公告为例说明如何撰写“意外事件避坑指南” 1提供上下文：避坑指南中提供意外事件的背景介绍，包括语雀的用户规模、用户分布、用户使用场景、用户使用习惯、用户使用时段等，让读者能够更好地理解意外事件的影响范围。 2解释术语：避坑指南中解释“Region”、“多副本容灾”、“新的运维工具”等术语，让读者能够更好地理解意外事件。 3提供意外事件确切的影响数据：避坑指南中提供意外事件的持续时长、影响用户数、影响用户比例、影响用户使用时长、影响用户使用频率等数据，让读者能够更好地理解意外事件的影响范围。 4提供触发因素的底层细节描述：避坑指南中提供意外事件的底层细节描述，比如运维工具的bug如何触发问题的过程，让读者能够更好地理解意外事件的根本原因。 5提供意外事件恢复的细节描述：避坑指南中提供意外事件的恢复细节描述，比如数据恢复的过程、验证过程、验证结果等，让读者能够更好地理解意外事件的恢复过程。 6提供可验证的预防措施：避坑指南中提供可验证的预防措施，比如存储服务器离线后可快速上线的预期时长、如何验证运维动作的灰度范围和灰度时长等，让读者能够更好地理解意外事件的预防措施。 可避坑-模式-以语雀故障公告为例说明如何撰写“意外事件避坑指南”（续） 7不具有指责意味：明确系统设计改进已考虑用异地双活应对此类意外事件，没有个人或团队会因该事件而受到指责。重点关注“出了什么问题”，而不是“谁”导致了事件。旨在改善机制和系统，而不是惩罚个人。 8分享范围广泛：将“关于语雀23日故障的公告”更名为“语雀23日意外事件相关避坑指南”，有助于让当事人放下难堪而愿意在避坑指南中分享事件细节，让其他团队能够学习和提供反馈。（语雀这一点做得较好） 9及时发表：避坑指南在意外事件发生后，一周之内及时发表，让其他团队能够及时学习，也能够及时提供反馈。（语雀这一点做得较好） 10数据驱动结论：提出的所有结论均基于事实和数据。 11提供图表辅助说明：以图表的形式提供更多有用的信息，以便为了向不熟悉该系统的读者提供背景信息。 分布式计算的八大谬误 *1网络可靠->依赖可靠；*2延迟为零；*3带宽无限；*4网络安全；5拓扑不变；6一人管理；7传输免费；8网络同构。（*为经常被忽视） 榜样：当chatgpt后端无法访问时…… 可避坑-演练-针对“依赖可靠”谬误 可避坑-演练-针对“延迟为零”谬误 总结 总结 当前生产事故复盘实践的三大缺点 1复盘报告分享难2演练考试非考验3缺乏亲身体验感三大缺点给做软件的人所带来的三大痛点：1难被认可2心里发虚3很快遗忘“意外事件助推避坑”四大价值点：1领导更认可2更多人学到3练过心不慌4印象更深刻实现”意外事件助推避坑“原则：预防虽重要，难免遇意外。修复意外时，系统仍可用。不去指责人，实操印象深。利他且易懂，领导更认可。业界普遍缺乏“可隔离”、“可替换”和“可避坑”这三种有助快速修复的思维