|
快速止血
问题排查的第一步，一定是先把血止住，及时止损。如何快速止血?常见方式包括：
-
发布期间开始报错，且发布前一切正常?啥也别管，先回滚再说，恢复正常后再慢慢排查。
-
应用已经稳定运行很长一段时间，突然开始出现进程退出现象?很可能是内存泄露，默默上重启大法吧。
-
只有少数固定机器报错?试试隔离这部分机器(关闭流量入口)。
-
单用户流量突增导致服务不稳定?如果不是惹不起的金主爸爸，请勇敢推送限流规则。
-
下游依赖挂了导致服务雪崩?还想什么呢，降级预案走起。
保留现场
血止住了?那么恭喜你，至少故障影响不会再扩大了。卸下锅，先喘口气再说。下一步，就是要根据线索找出问题元凶了。作为一名排查老手，你需要有尽量保留现场的意识，例如：
-
隔离一两台机器：将这部分机器入口流量关闭，让它们静静等待你的检阅。
-
Dump 应用快照：常用的快照类型一般就是线程堆栈和堆内存映射。
-
所有机器都回滚了，咋办?别慌，如果你的应用监控运维体系足够健全，那么你还有多维度的历史数据可以回溯：应用日志、中间件日志、GC 日志、内核日志、Metrics 指标等。
定位原因
OK，排查线索也有了，接下来该怎么定位具体原因?这个环节会综合考验你的技术深度、业务熟悉度和实操经验，因为原因往往都千奇百怪，需要 case by case 的追踪与分析。这里给出几个排查方向上的建议：
-
关联近期变更：90% 以上的线上问题都是由变更引发，这也是为什么集团安全生产的重点一直是在管控“变更”。所以，先不要急着否认(“肯定不是我刚加的那行代码问题!”)，相信统计学概率，好好 review 下近期的变更历史(从近至远)。
-
全链路追踪分析：微服务和中台化盛行的当下，一次业务请求不经过十个八个应用处理一遍，都不好意思说自己是写 Java 的。所以，不要只盯着自己的应用不放，你需要把排查 scope 放大到全链路。
-
还原事件时间线：请把自己想象成福尔摩斯(柯南也行)，摆在你面前的就是一个案发现场，你需要做的是把不同时间点的所有事件线索都串起来，重建和还原整个案发过程。要相信，时间戳是不会骗人的。
-
找到 Root Cause：排查问题多了你会发现，很多疑似原因往往只是另一个更深层次原因的表象结果之一。作为福尔摩斯，你最需要找到的是幕后凶手，而不是雇佣的杀人犯 —— 否则 TA 还会雇人再来一次。
-
尝试复现问题：千辛万苦推导出了根因，也不要就急着开始修 bug 了。如果可以，最好能把问题稳定复现出来，这样才更有说服力。这里提醒一点：可千万别在生产环境干这事(除非你真的 know what you're doing)，否则搞不好就是二次伤害(你：哈哈哈，你看，这把刀当时就是从这个角度捅进去的，轨迹完全一样。用户：...)。
解决问题
最后，问题根因已经找到，如何完美解决收尾?几个基本原则：
-
修复也是一种变更，需要经过完整的回归测试、灰度发布;切忌火急火燎上线了 bugfix，结果引发更多的 bugs to fix。
-
修复发布后，一定要做线上验证，并且保持观察一段时间，确保是真的真的修复了。
-
最后，如果问题已经上升到了故障这个程度，那就拉上大伙好好做个故障复盘吧。整个处理过程一定还有提升空间，你的经验教训对其他同学来说也是一次很好的输入和自查机会：幸福总是相似的，故障也是。
3 排查工具
手里只有锤子，那看什么都像钉子。作为工程师，你需要的是一整套工具箱。
（编辑：保山站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
