故障定位的初期，一般会先通过邮件+电话的方式进行沟通，如果几分钟之后事态变糟糕，且没有眉目，则需要紧急启动会议形式的联合排障，所有相关人员需要放下手头事情，集中到一个特定会议室进行联合排障。这样的好处也在于能够迅速共享信息，快速做出决策。联合排障人员通常会包括：开发、运维、测试、产品，主力应当是开发和运维，测试和产品需要帮忙快速确认一些东西，如复现问题，或者确认业务逻辑等。
从上面可以看到，故障定位过程中，追求‘快速’二字，为此多项事情是并行去做的。为了避免出现群龙无首的慌乱局面，需要有一个主心骨坐镇，把握排障的方向并最终做出决策，这个人是master，需要冷静沉着，且要能调度尽可能多的资源，所以技术leader或者运维leader会比较合适。这个类似于分布式系统的设计思路。
另外，在故障定位过程中，获得的线上一线信息需要通过某种形式记录下来，邮件往来是一种比较好的方式，在完成通信和信息共享的基础上，也无形中保留了现场。其他的信息包括：error log，dump文件，服务器各个指标的状态值等等。
故障排除一旦定位到故障原因，对症下药地排除故障就不是什么难事了，具体的措施可以参考下图中的总结：
这里需要特别指出一个特别的场景：无法定位故障的情况下如何迅速排除故障。
很多时候无法及时找到故障原因，必须直接进入故障排除，这时候的思路就在于：尽最大可能降低线上服务影响了。可以采用的手段有如下几项:
还是那句话，故障排除的原则是：确保线上服务快速恢复，不能完全恢复的情况下，确保线上服务尽可能少地受到影响。
故障回溯故障回溯的目的是在故障排除后，冷静地回溯整个线上故障的发现/定位/排除过程，找出流程中/架构中/制度中的缺陷，并将该缺陷消灭掉，同时推而广之到其他系统。在‘跳坑’--‘填坑’之后，我们需要通过故障回溯的过程达到‘避坑’的效果，即要保证自己能‘避坑’，也保证团队/公司能够避开类似的坑。
故障回溯的过程，因人因团队而异，最重要的是要有严肃的‘形式’和最终的产出物。之所以提到严肃的‘形式’，是因为线上故障无小事，一定要让大家牢记在心。
至于如何达到‘严肃’，可以参考如下形式：
总之，故障回溯的最终的目标不是为了追责，更重要的是让大家长记性，避免后续再次踩坑，而且线上故障报告的产出物一定要有，一方面是经验的积累，便于分享，另一方面也让当事人撸清楚事件过程，吃一堑长一智。
可以参考的一个流程如下：
前面谈了线上故障处理的目标、思路和步骤，回过头来看下，要快速准确地定位和排除线上故障，需要很多基础设施支撑，它们是线上故障处理的‘后勤保障’。结合上面的内容归纳总结如下：
完善的监控/告警体系通过告警，能让我们迅速知道自己的服务出了问题，通过监控可以从时间维度进行对比分析，找到可疑点，进而定位故障。
监控通常分为：
告警方面，需要根据实际情况和业务场景进行阈值设定，告警阈值的设定是一个动态调整的过程。
监控系统最基本的需要保证：按照时间序列进行统计、对比。
完善的日志trace体系在线上故障处理过程中，日志尤其重要，通过日志能够定位到问题或者bug细节。在分布式架构的系统中，多实例的部署导致日志分散在多台机器上，靠人肉查看耗时费力，效率低下；另一方面，业务发展壮大后，业务系统越来越多，系统间依赖越来越多，各个业务系统的日志需要通过唯一的标识串联起来，否则会出现信息断层的问题，日志变得无用。所以完善的日志trace系统非常必要。
日志trace体系的几个关键点：
推荐使用开源的日志架构：logstash+elasticsearch+kibana。
完善的故障处理机制线上故障处理的要点在于快速，所以需要有完善便捷的事件流转机制和故障处理机制来保证：生产事件能快速推送到相关责任人进行联合排除，保证事件排查过程中快速共享信息，快速完成决策。
对于事件上报，一般的公司会有专用的通道给到一线客服人员，客户人员填报工单，上报事件，关键点在于事件处理中担任‘路由’角色的人员，他需要对业务系统比较熟悉，对于上报的问题能快速确定相关的业务系统和负责人，并通知到对方，这个角色既要熟知业务，也要熟知系统架构和组织架构，这个角色一般会交由专门人员处理，称之为‘二线’人员，或者由运维人员兼职。
排查生产事件/故障时，推荐进行集中版本，便于快速共享信息，同时需要有一个master，以便把握大的方向，并快速完成决策。
总结以上，对线上故障处理的目标、思路、步骤及基础设施进行了讨论，先总结如下：
对于线上排障的流程整理了一个大图，如下：
可参考：线上故障处理——大量异常堆栈日志输出影响服务可用性
参考资料本文中部分观点来源于goole出版的《Google SRE》一书，这本书中有很多实用的且经过实践证明了的详尽的例子，该书的读书笔记可参考：《Google SRE读后感》
相关文章
精彩导读
热门资讯
关注我们
