GitHub 又遭遇严重故障：一次部署如何引发 9 小时级联宕机
GitHub Actions 在 8 月 6 日因一次常规部署触发级联故障，宕机约 9 小时。部署本身会减少可用 pod 数量，当系统已接近容量上限时，这种"部署态"会让系统越过临界点，发生脆性崩溃。GitHub 的公开报告缺少恢复细节，但提到一个潜伏 bug 让 runner 卡在无效任务上，进一步加剧了问题。文章最后指出 GitHub 开始重视快速恢复能力，而不仅仅是预防。
评论
点赞
收藏Traditional versus resilience engineering views
As a fan of resilience engineering, I often differ with people on where we should focus our scarce engineering cycles in order to improve reliability. I thought it would be a useful exercise to brains...
我在“软件应该能正常工作”大会上的演讲
最近新成立了一个名为 软件应该能用 的软件可靠性会议，我有幸在会上做了演讲。借此机会，我向大家分享了自己最喜爱的一个话题：饱和度。以下是相关录音…… 
用 TLA+ 将 MVCC 扩展为可串行化
基于 Michael Cahill 等人的论文，使用 TLA+ 形式化验证将 MVCC 扩展为可串行化快照隔离（SSI）。文章详细推导了导致非串行化的“枢轴事务”与反依赖环，并通过 TLC 模型检查器生成具体追踪案例，演示了如何在读操作和提交阶段动态检测并中止冲突事务。包含完整的 TLA+ 代码模块扩展细节与精炼映射验证过程。
我担心未来会出现全由LLM撰写的事故报告
作者对完全由大语言模型编写的事故报告未来表示担忧。他认为这种自动化趋势可能掩盖真正的问题，降低复盘质量。 事故复盘需要深刻的人类洞察和责任感，而不仅仅是文本生成。LLM 生成的报告可能缺乏对根本原因的深入挖掘。
致研究人员专栏：软件从业者的视角
介绍《系统与软件杂志》开设的“致研究人员”专栏。该专栏由业界从业者撰写，以公开信形式向软件工程学术界发声，旨在弥合学术研究与工业实践之间的鸿沟。
我无法忍受阅读 AI 生成的散文
作者明确表示，虽然日常使用 ChatGPT 和 Claude 等工具查询具体问题，但他拒绝阅读他认为由 AI 生成的文章或散文。 这种区分基于对“问答辅助”与“创造性表达”的不同态度，反映了部分技术用户对 AI 生成内容在文学性或深度思考层面的排斥。
形式追随功能，但使用并不追随设计：GitHub 稳定性危机引发的迁移潮
Mitchell Hashimoto 因 GitHub 近期频繁的可用性故障，决定将 Ghostty 项目迁移出 GitHub。他在一个月期间记录了每次服务中断的情况，以此作为迁移的直接动因。 这一举动反映了开发者社区对 GitHub 垄断地位及其服务稳定性的日益不满。文章探讨了在基础设施依赖与自主可控之间，用户如何重新评估平台选择。
可靠性：一场提升胜率的博弈
作者将可靠性工程与概率论结合，提出可靠性本质上是提升成功几率的游戏。文章通过类比赌博中的赔率概念，重新审视系统稳定性的衡量方式。 这种视角为传统工程问题提供了新的思维框架，有助于理解复杂系统中的不确定性管理。 
从事故中看清系统已有的优势
文章利用著名的视觉错觉图作为隐喻，阐述在事故复盘或系统分析中，我们往往容易聚焦于“哪里出了问题”，却忽略了系统中原本已经运行良好的部分。 作者主张通过逆向视角，从事故中识别出那些成功抵御了风险、保持稳定的机制。这种分析方法有助于团队发现现有的韧性来源，而不仅仅是寻找故障点。
创造可靠性的日常工作
文章介绍“Safety-II”理念，认为日常工作中防止事故发生的成功适应才是常态。 建议关注这些“没出事”的工作，而非只盯着故障复盘。 
评 GitHub CTO 关于可用性的博文：故障复盘与弹性工程思考
作者深入分析了 GitHub CTO 关于近期可用性问题的博文，拆解了三次故障的技术细节。 文章指出了缓存 TTL 调整与流量激增叠加导致的数据库过载，以及自动化故障转移机制引发的意外安全策略阻断。 作者强调在可靠性工程中，除了依赖自动化，必须为运维人员保留手动干预的灵活性。这种对“弹性工程”和“人为容错空间”的探讨，对架构师极具参考价值。
无法逃避阿什比定律：为什么自动化系统总会失效
文章以“手顶扫帚”为例，解释控制论中的“必要多样性定律”，即控制系统必须具备与被控对象同等甚至更多的状态处理能力。 在软件工程中，这意味着我们构建的基础设施很难覆盖所有未知故障场景，因为人类无法想象未来可能出现的所有状态。 
AI SRE工具泛滥，但缺乏真正的AI事故管理能力
作者指出当前AI SRE工具多聚焦于故障诊断与修复，却忽视了关键的“事故管理”协调工作。 事故处理需要多人协作以克服“思维定势”，维持团队共同认知。现有工具缺乏主动协调能力的深入讨论。 
增长过快导致系统过载：AI 巨头可靠性困境解析
文章对比了 OpenAI 和 Anthropic 的可靠性数据，指出其服务大多未达到 99.9% 的稳定率。作者引用内部员工回应，认为问题并非源于开发速度快，而是用户激增导致的服务过载。 文中引入韧性工程概念，解释这种因用户创新使用方式带来的不可预测负载增长。作者预测厂商将通过资源重分配和优雅降级来应对，但这将是长期挑战。
Cloudflare 2月20日故障的快速复盘与深度观察
作者深入分析了 Cloudflare 2月20日故障的根本原因：旨在提高可靠性的自动化脚本因逻辑缺陷误删了活跃前缀。文章探讨了自动化运维中的风险与两难困境。 作者特别关注故障恢复阶段工程师的具体操作细节，指出不同客户受影响方式各异，需要复杂的数据恢复步骤。这种对工程实践和人为因素的细致观察，极具技术参考价值。
没人知道整个系统是如何运作的
文章探讨了现代复杂系统中无人能完全掌握底层原理的现象，引用了Simon Wardley、Adam Jacob等人的观点以及MIT教授Louis Bucciarelli关于电话系统的论述。作者认为虽然AI加剧了这一趋势，但这是复杂技术的固有属性，我们只能拥有部分认知。
阿什比定律启示：我们要用魔法打败魔法
文章从软件工程中“增加间接层解决复杂问题”的老生常谈切入，引用自旋锁实现中简单方案因硬件复杂性而失效的案例，引出阿什比定律：应对复杂问题需要同等复杂的控制系统。作者进一步将这一逻辑延伸至大语言模型领域，认为LLM本身极其复杂，但我们可以利用这种复杂性来对抗由软件自身产生的复杂性。文中提出了一个有趣的类比：AI不应像失控的奥创，而应像《电子世界争霸战》中的特隆，作为人类代理人去对抗其他软件系统的复杂性。
SSL 证书的危险之处：从 Bazel 构建中断谈起
Google Bazel 团队因 SSL 证书过期导致构建服务中断。作者借此案例指出，自动化续期掩盖了团队对证书管理的实际经验缺失。 证书失效具有突发性且无预警，一旦自动化流程出错，缺乏经验的工程师难以快速恢复，这种“黑盒”机制存在巨大隐患。 