开发人员该如何应对线上故障
极客时间编辑部
讲述：初明明大小：4.73M时长：05:10
你好，欢迎收听极客视点。
一、及时汇报、多部门协作排查
发生故障后，不要只顾闷头排查问题，还要及时向你的直属领导汇报故障现象、影响范围、修复措施和修复进度，如果可以，最好再汇报一个大概的恢复时间。
这不是浪费时间，而是让你的领导快速了解故障情况，评估风险，以便于协调内外部资源，同时争取更多的决策时间应对老板或业务部门的催促。
如果是等级较高的故障就需要联系该系统相关人员一起排查，同时与该业务线的前后端开发、测试、运维及 DBA，多线程并行作战。在清楚故障现象后，各自排查自己负责的模块，最大限度地动用可利用的资源。
严重的线上故障一定要协调各方资源一起排查，因为只有掌握了足够多的信息，才能做出解决问题的正确决策。
二、稳定第一，快速止损
当你的领导一遍一遍地催促修复，业务部门在各种群里不断报出系统不可用时，每耽误一秒都会给公司带来损失，如何快速止损和恢复，常用的几种方式如下。
1. 重启回滚
能重启解决的先重启，重启能更快的释放资源，快速恢复线上运行是首要任务，当然有条件的话最好能保留现场，把某台应用从负载中摘除，以便后续分析。重启不限于应用、虚拟机，还可能是数据库。针对数据库相关的问题，作为开发人员遇到最多的还是数据库连接池被打满的情况，此时除了重启应用释放资源，也可以让 DBA 杀掉慢连接。
相对于看不见何时恢复业务正常运行的时间，重启所消耗的时间更容易评估，所以重启是个简单粗暴且往往有效的方式，当然重启的同时其他同学继续跟进排查。
回滚有数据回滚、代码回滚和版本库回滚这几种常用操作，上线新功能的时候，测试场景不充分或环境因素导致某个隐藏 Bug 产生，此时需要回滚部分代码重新发布，或直接全量回退到上一个稳定版本，先保障主业务正常运行。
2. 快速修复
大部分问题一般能通过异常快速判断、定位问题。这时可通过修改代码、修复异常数据或临时调整配置参数等方式立刻上线。
3. 限流降级
当流量异常时，限流是常用方式，减轻对底层资源的压力。限流主要包括接入层限流、应用层限流、分布式限流。算法大多采用漏桶、令牌桶、信号量。这些基础的工作需要在平时就部署完成，否则当流量来了只能是被动挨打的份了。
当无法保障全部功能恢复时就需要打开降级开关，确保核心流程不受影响。降级需要开发者提前理清那些是强依赖，系统资源不足时去掉那些弱依赖或者直接自动熔断读取提前设置的常量。降级会带来用户体验上的降低，却保障了主业务流程的高可用。
4. 扩容隔离
扩容是提升系统承载能力最快的方式，一台应用扛不住就再部署一台，一个数据库不行就分库分表，做读写分离。当然数据库的扩容需要时间，需要一个有计划的演进过程。
隔离是最容易被忽略的，隔离通常分资源隔离和业务隔离。举个例子，以前京东订单核心服务给所有系统调用时，出现订单服务不可用的情况，三方合作商家产生的订单在调用订单服务时，产生了很多异常数据，这就是没有做好业务隔离所导致的。后来京东为三方系统单独部署了订单服务才互不干扰。
三、清扫战场，及时复盘自我检讨
复盘不是找谁背锅，而是分析问题原因，从故障中找到系统的瓶颈，做好改进计划，避免在同一个坑再次跌倒。复盘可以让团队梳理核心业务上下游的依赖，增强对故障的认识，加深对系统底层资源的理解，更能看到一个人的学习欲望和责任担当。
复盘的方式可以借鉴蘑菇街赵成的复盘黄金三问：
故障原因有哪些？
我们做什么、怎么做才能确保下次不会再出类似故障？
当时如果我们做了什么，可以用更短的时间恢复业务？
聚焦这三个问题，反复讨论，直至大家认为找到了改进的措施。
以上就是今天的内容，应对线上故障的第一要素就是：在现有可利用资源的基础上怎么做才能快速恢复，“简单粗暴”远胜于“严谨优雅”。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论