在互联网架构的金字塔中，存储位于最底层，它是沉默的基石，却承载整个数字世界的重量。应用层挂了尚可重启，网络层抖动亦能重传，唯独存储层崩了，那就是真实世界里的“天塌了”。数据丢失或不可用，往往是不可逆的业务灾难。虽然每次故障都是独特的“黑天鹅”，从未有标准解法，但我们仍可从历次“枪林弹雨”般的故障复盘中，提炼出一套在危局中求生的生存法则。

战时法则：不整虚的，先保业务

故障的时候就像水管爆了：你先别趴地上研究 “是水管质量差还是工人没接好”，赶紧先找个桶接水、把总阀关掉再说，不然水漫金山，损失的可就不止 “水费”了。这里介绍下两个概念RTO和RCA。

• RTO(Recovery Time Objective)：系统可容忍的最长恢复时间（你的命有多硬）

• RCA(Root Cause Analysis)：根本原因分析（到底谁惹的祸）

线上故障恢复的核心矛盾是业务受损时长。你哪怕咬碎后槽牙也要保持冷静，并死死守住第一法则：RTO高于一切，RCA先靠边站。

抢救现有资源

只有活下来的系统才有资格谈优化。

无论是把剩余的粥转移到其他干净的锅，还是把已经污染的粥捞干净，核心目的都是要保证其他的粥不受影响（别让还没死透的业务陪葬）。结合COS排障的经验，下面总结了一些常用的手段。

降级是王道：别当赌狗。如果系统有降级预案，先执行。比如在收到机房掉电风险群呼时，不要花时间去确认是不是误告，先进行降级，把损失尽可能地降到最低，哪怕最后没有实际故障，预案的代价也远小于业务挂掉的损失。对于COS来说，哪怕是小集群每秒的请求也有几百万，多犹豫1秒，数据安全风险就呈指数级上升。我们建立了一个风险看板，只要在收到高危风险时关联涉及的实例或者IDC信息，系统会根据内部的容灾要求自动计算风险影响比例，再针对性地进行降级或者屏蔽，确保在分钟级的时间窗口内输出确定的操作止损范围。

隔离是本能：发现某个节点延时高、还疯狂报错？在保障数据安全的前提下，第一时间把它隔离下线。千万别在这个时候满腔热血地想“我一定要现在登上去看看由于什么问题导致的”。你的好奇心，可能会害死整个集群。为了将“本能”固化为系统能力，COS建设了完善的异常自动化隔离体系，除了SDK侧的熔断机制，还能通过秒级监控分析上下游的的异常实例，并结合机器软硬件的异常事件进行隔离，能规避人工操作的滞后性，也显著缩短了MTTR。

离线靠边站：第一时间暂停所有离线计算、数据迁移、回收任务、异步删除等，这必须是刻进骨子里的反应。之前遇到不少玄学问题，从监控、日志、上下游链路排查均未发现异常，并且所有的现象和线索都未指向离线服务可能有问题，但失败却时不时的冒个尖，怒从心头起，把离线服务暂停，失败立刻就恢复了。福尔摩斯有一句名言“排除一切不可能的，剩下的即使再不可能，那也是真相”。我想这也适用于排障。离线任务往往就是那个“隐形杀手”。COS重点优化了离线服务的管控逻辑，将全链路的启停动作封装为标准化的应急预案按钮，能够以最小的认知成本快速执行操作，内部会做好完善的校验。

重启增可能： 虽然听起来很土，像网管修电脑，但在毫无头绪的情况下，重启往往是最有效的“除颤仪”。现网环境是个混沌系统，CPU异常、内存泄漏、死锁、句柄耗尽等由于代码不健壮引发的“软硬件叠加态”，你没法现场Debug，重启一个节点验证一下，如果有效，那就是最快的止血钳。由于状态重置带来的短暂恢复，能为你争取宝贵的排查时间。

揪出害群之马

稳态系统不会无缘无故自己崩溃，一定是某个“变量”打破了平衡。

《SRE: Google运维解密》书中有提到，70% 的线上故障是由变更引发的。在存储运维领域，这个比例我觉得可以大胆地加到 80%。

当故障发生，且无法一眼看穿原因时，不要陷入代码逻辑的深渊。请立即从“极客模式”切换为“刑侦模式”，梳理最近的时间线，拷问三个问题：

1、我干了什么。有没有什么现网操作？操作是否观察到位？操作是否符合变更规范？

2、程序动了什么。异常模块最近有没有变更？最近新上的特性有哪些？

3、周边系统动了什么。依赖服务最近有没有变更？上下游链路有没有调整或变更？整个集群有哪些关联的事件？

COS接入的业务场景和客户需求日益复杂，每天进行的变更单就有15+，叠加日常运营的现网操作，基本上是在“刀尖上跳舞”。为了在保障敏捷迭代的同时实现现网状态的极致“透明化”，我们在夯实容灾兜底机制的基础上，还接入了事件中心，将离散的变更动作收敛为可追溯、可视化的轨迹，在收到告警时也会附带该集群或模块在故障窗口期内的所有操作记录，能大幅减少异常的排查时间。

不做添乱之人

永远敬畏现网。

比故障更可怕的，是救援导致的“二次故障”。 司内外有太多案例，原本只是一小部分节点故障，结果运维人员一顿操作猛如虎，把整个集群搞挂了。

在救火的时候紧张是正常的，操作变形也是正常的，所以执行任何操作时都可以在心中默念：“接下来我要看xx应用监控，指标是xx，不能选错”，“接下来我要操作xx，预期影响是xx，需要关注xx”。这不是多此一举，这叫“指差确认”，当你的大脑被告警声吵得一团浆糊时，把操作默念出来能强制你进行逻辑自检。

下面总结了三个保命原则，能在做恢复操作时尽可能地降低风险。

1、高危操作必须要审批： 当局者迷旁观者清，无论你多资深，在执行高危命令的时候一定要进行审批和确认。

2、预案执行必须要演练： 没经过演练的预案无异于皇帝的新衣，真打仗时就是一颗哑弹。

3、变更操作必须要灰度：不要有梭哈思想，控制爆炸半径是运维的基本素养。先在一台机器上试，再逐渐灰度，没问题了再全量。不要相信“我只是改了个空格”，空格也能搞死系统。

成为守夜之鹰

故障处理不是个人英雄主义的独角戏，而是一场精密协作的团战。

“守夜鹰”不仅要有洞察黑暗的眼睛，更要有刺破寂静的喉咙。最怕那种闷着头自己查，把自己绕进死胡同，最后业务快炸穿了才被发现的人。 如果你评估短时间（5分钟）搞不定，或者这事超出了你的认知，立刻摇人！ 大声喊出来：“大家安静！全部抬头看向我！现网有故障！我现在搞不定！业务要挂了！速来支援！”这不丢人，这叫专业。越早升级，能调动的资源就越多。

在故障群或者会议上，通常是这种混乱场面：

内部人员： 谁动了配置？最近有啥变更？

老板： 恢复了没？什么问题？有多少客户被影响了？

前端： 电话被打爆了，用户在骂娘，什么时候恢复？能不能给个准信？

乱战之中，需有“鹰眼指挥官”坐镇塔台。 这个人的职责不是去查问题，而是挡拆和路由。他负责对外同步信息、安抚一线、挡住无意义的催促，让干活的人能心无旁骛地排查。

之前有一个问题，甚至连问题都不算。当时我们都在闷头查，和一线的沟通比较有限，从前端的视角来看，这么长时间都没有同步，问题、影响一概不知，客户情绪又很激动，明显是个大问题，赶紧升级，于是在短时间内从L4升到了L2，虽然影响远远达不到L2的级别，但由于没及时同步，导致了小问题被无限放大。

所以在排障的时候一定要避免以下四点：

1、沉默是金： 对内闷头操作不说话，同事不知道你干了啥，极易导致重复操作或冲突操作；对外不同步进展，让别人误以为系统要挂了。

2、模糊判断：“好像是网络问题”、“大概是磁盘坏了”，没有证据支撑的猜测就像耍流氓。

3、情绪宣泄：故障时大家压力都大，毫无作用的情绪攻击只会让氛围变差，严重影响排障进展。

4、半场庆祝：告警停了不代表故障结束了。要确认业务已完全恢复、数据一致性无问题、存储系统运行正常、无潜在隐患。半场开香槟乃兵家大忌。

战后重建：不搞批斗，榨干价值

故障复盘

故障不可避免，但重复的错误不可原谅。

如果复盘变成了分锅大会，那么下一次大家只会学会如何更隐蔽地甩锅，而不是解决问题。复盘的核心目标是避免重蹈覆辙，对事而不对人：

1、找到故障的根本原因。

2、梳理故障处理过程中的不足（如排查效率低、沟通不畅、操作失误）。

3、制定可落地的改进措施。

4、更新文档，把这次流的血变成明天的疫苗。

错误是成长的催化剂，关键是如何转化。只要不是恶意的，我们就要坦然面对，这是成长的代价。一个优秀的运维，是在一次次“背锅”中练就的。

价值提取

让系统反脆弱，让团队长肌肉。

故障发生了，学费已经交了。如果我们只是把这次故障处理完，那这笔钱就纯粹是打水漂了。战后重建的核心目标不是回到过去，而是进化到未来，我们要从故障里榨干每一滴价值。

1、榨干技术价值。这只能单点吗，能优化成分布式吗？这必须是强依赖吗，能优化成弱依赖吗？这必须是强耦合的吗，能解耦出来吗？

2、榨干流程价值。所有的SOP和Checklist，最初都是空白的，每一条规则背后都是一次血淋淋的教训，要仔细审视处理过程中的每一秒。发现慢了，是监控阈值设太高？还是告警风暴把真警报淹没了？还是压根就没告警；止血慢了？ 是预案文档找不到？还是命令敲起来太繁琐？还是分析速度太慢了？

3、榨干团队价值。一人踩坑，全队长脑。最亏的故障是张三踩了个坑，张三学会了，过了两个月，李四又在同一个地方掉下去了。知识必须共享，经验必须传承。不要只写枯燥的报告，要还原“案发现场”的心路历程——当时看到了什么现象？为什么做出了错误的判断？这种“战争迷雾”下的决策过程，比最终结论更有意义。

4、榨干机会价值。平时说这模块问题太多需要优化，开发可能会说先别急，但故障后我们就可以借此机会推动优化，同时还可以升级老旧的基础设施。

不要浪费每一次故障。通过复盘，我们要拿回四样东西：更健壮的代码、更丝滑的流程、更强悍的团队、更充足的资源。把这四样都榨干了，这个故障才体现了应有的价值。

战前演习：不走过场，假戏真做

永远不打无准备的仗。

故障常看常新，故障治理绝非一劳永逸的静态任务，而是一个随着技术栈演进与业务增长不断动态迭代的认知过程，更新的方法论会指导我们对历史问题有更全面的认识。COS会定期回顾近几年的故障单和问题单，重新回看当时处理的流程和改进措施，这不仅仅是为了校验当时应急响应SOP的有效性和改进措施的落地情况，也是为了挖掘系统中隐蔽的长尾风险，针对这些风险我们也会进行专项演习。同时，我们也定期组织分享，针对新老模块、架构特性进行宣讲，确保每一位同事都能对底层逻辑保持清晰的认知与同频。针对友商出现的问题，我们也高度重视，坚持“视同己出”的原则进行深度的对照自查与问题推演。因此，结合COS运维工作的相关实践，总结了一些行之有效的举措。

练武功

平时多流汗，战时少流血。

加大对于工具，命令的熟悉程度，能在故障期间显著提升排查效率，时间是用来救火而不是搜索。

摸家底

别等家里水漫金山了才去找总阀在哪。

做运维最怕灯下黑，真正故障的时候不会给你时间去看文档、熟悉流程。我们需要对业务的架构了然于胸，每个模块调用、上下游链路、预案操作也都要摸的门清，才能在故障处理时最快的找到问题所在。同时也要构建动态更新的故障知识库，定期复盘回溯和演习，将历史故障的血泪经验沉淀为可传承的资产，不仅助力新同事快速跨越技术门槛，更从机制上规避重复性踩坑。

写工具

工具>文档>口口相传。

故障现场是高压环境，此时最可靠的不是高智商的人，而是防呆的工具。

把复杂的步骤封装成按钮，同时又赋予下发的人足够的勇气。做工具的人要有信心（经过充分测试），使用方要有信心（知道这个工具是救命的），敢无脑下发才是工具的终极形态。

学经验

他山之石，可以攻玉。

学会用别人的血交学费，不要只盯着自己的一亩三分地，看看外面世界怎么“崩塌”的，能帮助在工作中避免很多坑。下面分享几个故障复盘报告。

强心脏

一切的恐惧来源于火力不足。

运维都怕故障，但时间久了你会发现：恐慌比故障本身更具破坏力。我们要承认“火力不足”：存储系统的复杂度决定了没人能拥有上帝视角。如果你负责的模块突然大脑一片空白，或者你没见过这种报错，不要装懂；也要拥抱“不确定性”：故障处理不是考试，没有标准答案，保持开放心态，高效同步信息，不给故障添乱，这就足够专业了。

送给大家三个锦囊：

不怕背锅：锅背多了，背阔肌就厚了，经验也就来了。

不要偷懒：每次故障后的预案沉淀，都是你下次保命的护身符。

不要慌张：机器是死的，人是活的。我们尽可能地挽救，如果天真的塌下来，也有老板顶着（bu shi）。

结语

我们必须接受一个现实：硬盘会坏，网络会抖，代码会有 Bug。运维人追求的不是“永不故障”，而是故障发生时用户无感知。在业务飞速发展时，没人会记得底层的我们负重前行，甚至觉得存储就是个大硬盘，插上就能用；但一旦崩塌，千夫所指。 但也正是这种如履薄冰的危机感，倒逼我们构建出了日益坚固的防线。平时深藏功与名，只有在崩塌时，才会被世界看见。但愿我们做那个永远“看不见”的守护者，敬畏技术，敬畏生产，保持冷静。