当事故拒绝结束

📌 One-Sentence Summary 一位 SRE 负责人认为，长时间运行的事故揭示了「想象的工作」与「实际的工作」之间的差距，并通过两个详细案例说明真正的修复存在于社会技术系统中，而不仅仅是代码里。 📝 Summary Vanessa Huerta Granda 在 Enova 领导韧性工程，她审视了一类「拒绝结束」的事故——那些从冲刺演变为通宵鏖战的马拉松式事件，暴露了「想象的工作」与「实际的工作」之间的差距。她不按固定的 SLA 来定义长时间运行的事故，而是按它们给人的感受来界定，并指出它们放大的四种压力：时间、协调、认知和可见性。随后她详细讲述了两个案例。「周二问题」（2015 年）最初表现为联络中心和数据库的模糊性能退化，被反复「解决」却从未进行根因调查，并在每个月的第一个周二复发；一个老虎小组最终将其追溯到与月末薪资文件相关的一系列问题组合，真正的修复来自优化查询、硬件、后台任务和团队结构——理解社会技术系统，而非调试代码。「消防队长」事故（2020 年）涉及数据中心电池冒烟、全面宕机、高管加入电话会议，以及关于灾难恢复切换的紧张 go/no-go 决策。贯穿始终，她强调事故教会我们技术、组织和人方面的教训，事故指挥官必须关心响应者的基本需求，以保持他们排查问题的能力。 💡 Main Points 长时间运行的事故是由感受来定义的，而非固定的时长或 SLA，它们揭示了「想象的工作」与「实际的工作」之间的差距。 Granda 拒绝用小时数或 SLA 来定义长时间运行；如果你凌晨 3 点还醒着等待重启、错过了孩子的足球比赛，或者只是感到沮丧，那就算。这些事故暴露了干净的时间线和架构图所隐藏的技术现实、组织约束和人的需求。 长时间运行的事故放大四种压力——时间、协调、认知和可见性——而高管注视带来的可见性压力尤为尖锐。 时间压力来自每一分钟都在烧钱；协调压力来自轮换响应者和不断变动的环节；认知压力来自复杂性过载；可见性压力来自所有人——包括高管层——都在注视。识别这些压力有助于指挥官管理它们，而不是被压垮。 「周二问题」表明，反复发生的事故往往在没有真正根因调查的情况下被关闭，而真正的修复在于社会技术系统，而非调试代码。 该事故被反复解决，事后复盘记录写着「找到根因」，但从未进行调查，因此它在每个月的第一个周二复发。一个老虎小组发现这是与月末薪资文件给系统带来压力相关的一系列问题组合；真正的修复是优化查询、硬件、后台任务和团队结构。 事故指挥包括关心响应者的基本人类需求，因为工程师如果脱水或情绪崩溃就无法排查问题。 Granda 描述了提醒人们去洗手间、在响应者失去脑功能之前轮换他们、开门通风、告诉高管回到自己的工位。这种类似家长式的职责不在职位描述中，但对将事故推向解决至关重要。 「消防队长」事故说明了物理数据中心事件如何触发全面宕机、高管升级介入，以及高风险的灾难恢复 go/no-go 决策。 一块冒烟的电池导致疏散，并有谣言称数据中心着火了；所有警报都触发了，高管们开着摄像头加入，两名工程师驱车赶往现场。指挥官重组为两个焦点团队，并为灾难恢复决策设定了午夜截止时间，最终推迟到凌晨 12:20——展示了协调和可见性压力的实际运作。 💬 Key Quotes 正是在那翻涌的混乱中，我们看到了系统和团队中的真相。 它们向我们展示了「想象的工作」与「实际的工作」之间的差异。 因为工程师如果脱水或情绪崩溃，就无法排查问题。 真正的工作、真正的修复不在于调试代码。而在于理解我们的社会技术系统。 事故是工程师被锻造出来的地方。 📊 Article Meta AI Screening： 90 Featured： Yes Source： InfoQ Author： Vanessa Huerta Granda Category： 软件编程 Language： 英文 Read Time： 29 min Word Count： 7245 Tags： 编程与工程 , 系统设计 , 技术领导力 , 分布式系统 , 云原生 / DevOps Read Full Article