转载

线上技术故障处理三板斧

“ 是软件就有bug，第一个bug是一虫子 ”，软件工程的老师是这样讲的。

当bug突破层层检查站，被释放到线上生产环境时，比如文案错误，xx交易系统不可使用等，根据其严重性不同，会引发线上的问题，甚至是线上故障。

而在大型软件工程中，讲究预期一致性，非预期内的线上表现，往往伴随着bug的产生：

可能影响不大，引发线上问题

比如运营图片没有更新，显示成了昨天的了，且今天无重大活动

可能影响巨大，引发线上故障

比如运营图片没有生效，原因是服务端最近一次发布，代码本身有bug，某些行为下会触发生效，导致全平台配置失效，App内所有图片坑位白屏

今天我们讨论的是后面一种场景。

线上故障带来的不仅仅是bugFix这么简单，对于有一定规模量的产品，尤其是toB或付费类产品更甚，引发的可能是公关甚至品牌。

让我们重新review一下，这种线上影响较大的技术故障处理的注意事项，当真的发生了线上故障：

线上技术故障处理三板斧

处理故障三板斧

1- 止血，止血，止血

先“ 止血 ”，再看为什么。线上故障就像是系统的破损，当发现并确认问题确实存在，第一件事情就是“ 止血 ”，让问题第一时间得到遏制，解法可以不是最优，但一定要最快。

2- 复盘

趁热打铁，在1-3天内，重新推演问题的发生的原因， 找到根本原因和触发原因 ，分析影响面，是否要主动安抚客户。在每个关键节点，当时为什么关键“卡点”处，没有发现该隐患，还是发现了，谁决策了“带伤上线”。

3- 改进

如果有类似的场景，怎么 保证不会再次发生 ，那么需要接下来做哪些Action？落实到具体负责人，确定落地的时间点。

避免故障三板斧

这里，简单分享下，目前业内比较常见的共识方法论

1. 发布前，确保有效的数字化监控

近些年，在一线工程团队里的一种思潮是， 重视有效的监控大盘 ，减少对个人操作经验依赖，重视流程信息化审批，减少“发布核按钮”掌握在单个人手里。

2. 发布时，逐步灰度

每一次新功能及新产品的发布，都 不要一把梭，要逐步放量 。可以从用户比例、uid分桶、服务端机房分批、非核心用户、VIP用户等逐步放到止100%流量。

3. 发布后，一键回滚的能力

只有 每次发布都具备一键回滚的技术能力 ，才能在真的发生问题时，瞬间做到问题止血。对软件工程中featrue更有控制力，上线还是下线，从容应对，灵活控制。

理解产品周期与线上故障

技术故障，在产品的初期，到发展期，到成熟期，到半衰期，是有着不一样的影响效力和重视程度。

产品初期

一切为了快速 试错+反馈
所有的功能和技术实现围绕的是，商业核心问题的是否被市场验证。这时想的是，解决方案是否有效，是YY的，还是击中了用户核心诉求。用户愿意花钱买你的服务吗？愿意花多少钱买？追求的更快的是错误反馈。

产品发展期

故障的快速处理 开始被要求
核心功能看似已得到市场验证，至少有部分人群，真的愿意“掏腰包”买你的服务，这时团队追求转变喂新用户拉新。运营力量开始介入，进一步提高新用户涌入，刺激体量上一个新台阶。产品服务的稳定性、一致性开始被重视，技术侧的工程能力逐步搭建，要求可用性比例， 故障可以有，但同样的故障决不允许出现第二次 。

产品成熟期

线上故障 几乎是0容忍态度
产品在细分领域占据了一定份额，很多时候没有可参照竞品。技术所维护的业务形态，变得越来越复杂，代码量越来越多。技术架构升级与产品横纵向整合同时推进，故障等级也在不断被细化，线上故障开始有了问题追责。

产品半衰期

既要业务创新，又要技术稳定
技术上既要维护前人的老代码，又要实现YY的新业务需求和老系统嫁接。对于组织来说，没有企业喜欢衰退期，要么尽力延长成熟期，扩大市场规模；要么寻求变革突破，宁可赴死也不等死。

现实的意义

在当下敏捷/精益迭代 + 狼性创业文化的大行情下，不论是一线技术主管还是一线扭螺丝的，其实大家每天都是在高强度+高并发的工作中度过。很多时候， 人每天的精力是有限的 ，扯皮、需求变更、开会等都会压缩工期，最可恨的是Deadline几乎很难延后。

质量和上线速度，落到实际工作中，有时候真的很难两全。这时候故障的被发现，有时候反倒是梳理这些事情的一个抓手，让类似的故障不再发生，就需要技术侧的架构更合理，监控更完善，流程更规范，这反倒是给技术同学争取了一些时间buffer和价值意义实践的窗口。产品侧不能只顾提新需求，不考虑整体可靠性及由于业务越来越复杂，必须要进行的基础技术能力升级。

线上技术故障处理三板斧

未来还能做什么？

对线上故障的重视，短期内可能会增加一线技术同学的心里负担与工作，但长期来看， 倒逼各角色对线上质量的重视程度 ，用户的体验，功能的稳定，对团队及核心服务可靠性的支持意义重大。

敬畏每一次线上操作变更的风险，落实发布能够灰度、数据大盘监控、业务数据指标是否符合预期。

加强有效报警，从对敬畏故障的思想做起，在基础能力建设完善的基础基础上，未来实现“无人盯守，发现问题，自动告警，风险预测，自动回滚”，让devOps从经常要搞到凌晨发布，无法安心入睡的困境中解救出来，减少一线拧螺丝人员的背锅次数，减少系统释放处来的背锅HC机会，最终实现已知领域内的线上功能服务的高可用。

欢迎关注微信公众号：土豆他爸爸

坚持每周写一篇生活|技术|时事的原创总结

线上技术故障处理三板斧