线上应急之药到病除篇一、心有近忧        本文主人公小白负责公司的一块重要业务，因业务所涉及的系统链路比较多且逻辑

一、心有近忧

       本文主人公小白负责公司的一块重要业务，因业务所涉及的系统链路比较多且逻辑复杂，线上应急挑战压力大！当发生线上问题时，目前主要依靠TL小白以及团队中少部分核心人员支持应急。在节假日期间，小白也不敢懈怠，无论去哪都时刻背着电脑以应对随时可能发生的应急事件。        小白心想如何将团队里每个人的应急能力都提升起来？做到团队成员人人都可应急，这样依靠团队的力量才能走的更稳更远也更轻松。

二、深入调查

       为了解决该问题，小白决定对大家的线上应急过程进行深入研究。通过对大家平时的应急案例的进行观察、分析，小白总结出了线上应急的三个关键步骤以及当前各步骤的具体做法。

步骤序号	步骤目标	当前做法
1	定位链路哪里出了问题	- 通过翻阅代码、查询日志、查看监控等多种方式进行问题定位- 问题定位时长依赖个人对不同问题排查工具的熟悉程度
2	确定问题对业务的影响	- 有时需综合客户端/后端/测试多人意见才能准确地确定问题影响
3	针对问题如何快速应急	- 临时翻阅代码确定业务预案-从预案库中查找预案

       小白发现当前做法存在以下两个问题：

• 较强依赖个人经验 ：对领域业务逻辑熟悉或参与应急问题排查多的成员，应急能力表现相对较好
• 应急表现时好时坏：对发生问题的影响/应急预案正好熟悉时，应急表现较好

       小白进一步发现，对于线上问题的应急，团队成员里并不是没有人做不好，而是大家在不同领域的应急能力、应急经验没有沉淀总结，平移给团队里的每个人。如果团队里每个人都是各领域应急能力的集大成者，那么人人皆可应急方能真正实现。        因此，小白开始了新的应急探索。

三、寻诊悟道

       一天，小白身感不适，去医院进行检查。医生首先通过望闻问切、仪器监测等方式收集了身体各项指标数据，然后在医生的医疗诊断平台很快地输出了小白身体存在的问题原因、问题影响及其治疗方案。        小白通过观察医生诊断过程，意识到人体系统亦如软件系统，也是由各个器官组件构建而成，医生对身体问题的诊断过程亦如自己平时应急时对软件系统问题的诊断过程。        医生的诊断过程整体分为如下四个步骤：        小白想到此，对心中的问题似乎有了答案。

四、独具匠心

4.1 整体设计

       小白回到家中，对所要实现的系统进行了一番整体构思，核心围绕链路异常做平台能力的设计，旨在快、准、简单的应用到团队每一位同学，整体设计如下：

1. 诊断管理后台： 负责异常数据采集、根因诊断、快速应急的参数配置及应急经验沉淀，同时做不同场景下关联预案的维护，如：异常编码及对应预案的维护、依赖服务的状态及异常影响等等
2. 异常数据采集： 从业务系统中实时采集链路异常数据，主要分为以下三类：
   • 基础数据：采集异常所发生的环境信息，如AppId、机器Host、机器IP、环境Env、集群、链路Trace等
   • 链路数据：采集异常所属链路信息，如系统链路调用入口、从入口到异常发生处的系统调用路径等
   • 异常数据：采集异常点的基本信息，如异常坐标编码、发生异常时的请求参数、响应信息 、上下文等
3. 根因诊断服务： 基于实时采集的请求异常坐标数据，做如下根因分析动作：
   • 问题根因诊断：对异常坐标数据做横向和纵向的聚合叠加，然后基于问题发生的原则做干扰排除，从而诊断出链路问题根因
   • 应急措施关联：根据诊断出的根因节点的异常坐标关联事前维护的应急预案及历史经验
   • 应急信息触达：将链路异常基本信息、影响范围、可能的根因、应急措施等信息基于告警、消息等方式触达给相关负责人(值班人员)
4. 快速应急方案： 相关人员(值班人员/团队leader)基于触达的消息内容并结合团队应急标准流程做相应的信息同步及应急措施的执行

4.2 关键设计一：如何定义“异常坐标编码”才能快速定位到链路问题

问题挑战：

1. 调用链路难确定： 针对系统中的同一个异常点，多条调用链路可能均经过此异常点，如何知道哪一条调用链路有问题？
2. 异常种类难明确： 系统中的异常种类繁多，对于服务内部异常有参数异常、逻辑处理异常、中间件异常等；对于服务外部异常有二方调用异常、外部三方调用异常等；在服务调用过程中，有超时异常、路由异常、鉴权异常、限流异常等。如何快速定位到具体的异常？

解决思路：        如同现实生活中基于经纬度对地球任意地理位置进行坐标定位，通过在系统中针对异常设计坐标编码从而实现对系统中的异常实现精确位置定位。异常坐标编码由两部分组成：请求链路坐标以及节点异常坐标。

请求链路坐标： 用于标识异常发生时所在的链路及问题系统在链路中的位置，由两部分组成

• 系统坐标定义： 用于标识当前请求所属系统及入口方法，定义方式为：{服务AppId}@{入口请求方法名}
• 链路坐标定义：用于标识当前请求所路由的各个系统，由系统坐标串联而成，定义方式为：系统坐标1#系统坐标2#系统坐标N。实时追加系统坐标后在链路的请求上下文中传递（不同的通信框架实现方式可能不同，如果使用头传递时担心链路坐标过长，可以对appId等固化信息做短编码映射后再传递） 节点异常坐标： 通过请求链路坐标定位到异常所在的具体系统后，再通过节点异常坐标进一步定位异常所在系统中的位置。系统中的异常有不同的类型，大致可以按照如下分类(根据实际情况自行定义)：服务内部逻辑异常(参数异常、其他逻辑异常等)、依赖调用过程异常(超时、限流、鉴权、熔断、降级等)、依赖调用结果异常(依赖服务内部异常、依赖服务正常异常等)
• 坐标定义： 对系统中不同类型的异常定义异常编码，用于异常位置定位
• 坐标规约： 为了防止对线上正常运行系统产生影响同时又能达到快速定位的效果，异常编码的定义需要遵循如下的几条规约：
  • 同一系统中定义的异常编码不能重复，避免不知道是哪里有问题
  • 该异常编码为风险点位置专用编码，不应作其他业务语义用途
  • 为了和已有的业务异常码关联，可以在已有业务异常码的基础上扩展

  4.2 关键设计二：针对采集的“异常坐标编码”，如何准确诊断出链路的问题根因

问题挑战：       当系统链路中的某个节点发生异常时，整个链路中的多个系统可能同时上报异常，并且随着时间的推移异常坐标数据非常多，如何快速从众多异常坐标中确定问题根因？ 解决思路：       通过将异常坐标的调用路径做叠加，从而得到请求链路异常树，最后通过指定规则做干扰异常节点的排除，最后剩余异常节点即为链路异常可能的根因 异常链路聚合： 首先对采集到的“异常坐标编码”按照时间区间（最近1min/5min/10min）先在纵向维度做单个请求维度的链路聚合，然后在横向维度做多条链路的聚合，构建异常链路请求树

• 纵向维度聚合： 一次请求中，系统链路中可能多处上报“异常坐标编码”，需要将多个坐标编码聚合成一个完整的请求链路中。聚合流程如下： 单节点异常链路解析：根据上报的“异常坐标编码”构建异常链路节点信息 多节点异常链路聚合：将多个单节点异常解析后的链路构建成一次请求的完整异常链路
• 横向维度聚合： 将特定时间区间内的多个异常请求链路进行聚合 干扰节点排除： 根据链路聚合后的结果基于如下原则进一步分析具体哪一个坐标可能是根因
•  时间优先：链路中最早发生问题的地方可以归因为根因
•  深度优先：链路最底下的异常可以归为根因
•  数量优先：链路中发生异常数量最多的节点可以归为根因
•  噪音降噪：在系统链路中针对同一业务错误码的传递而导致不同系统上报异常进行降噪处理

  4.2 关键设计三：诊断出链路问题后，如何实现人人都可应急

问题挑战：        诊断出链路问题后，如何应用到实际工作中，并确保团队人员都能简单快速的处理好线上应急 解决思路：

• 有响应：通过建立应急保障机制，在问题发生时通过多渠道触达到相关同学并基于多人兜底的响应机制确保线上问题能第一时间介入处理
• 会应急：通过建立应急操作SOP，让团队成员都按照标准化的姿势进行应急
• 止血快：
  • 缩短应急信息确认时长：通过对链路中风险点的问题描述、止血措施等应急经验知识提前梳理，并维护到后台系统，避免问题发生时因需要临场确定而延长止血时长
  • 缩短应急措施操作路径：通过在问题的告警内容中关联异常特征、核心应急操作步骤等信息，让应急人员更快地决策应急

五、养兵实操

1. 收到问题反馈： 产品反馈线上订单详情某个模块不展示了
2. 告警响应处理： 当日团队值班的小A同步收到告警通知后，立即响应处理
3. 了解异常特征： 小A首先想知道该告警的问题的异常特征，是只在具体的某些城市/某个端版本/某个集群等出现，还是所有维度范围均有出现。于是，小A点击告警内容的中“链路异常分析”链接，跳转到诊断管理后台中链路诊断页面，从“链路异常统计”信息中了解到了问题的异常特征是一个广维度范围的异常。
4. 查找异常根因： 接着，小A想知道导致该问题发生的异常根因。小A在链路诊断页面的“链路诊断结果”内容中通过查看可视化的异常链路，知道了产生该问题的根异常节点为服务A，且知道了对该服务的依赖状态为弱依赖，可以进行降级处理。
5. 应急处理—影响同步： 小A点击告警内容的“预案执行确认”链接，跳转了到预案详情页面。基于应急标准流程在执行预案前，需要先将问题描述、问题影响、预案内容、预案执行影响等内容同步到应急处理群，于是小A点击页面中“一键生成同步内容”将相关信息同步到了应急处理群。
6. 应急处理— 预案 执行：在应急处理群里得到应急指挥官对预案的执行许可后， 小A立即点击页面中的“立即去执行预案”按钮，跳转到了预案平台执行预案。 应急成果： 1、单枪匹马搞定： 整个应急过程小A一个人就搞定了，并且出问题的领域还不是小A熟悉的领域 2、应急指标达标： 从告警发生到问题止血，不到5min就完成了线上应急 小白看到小A通过使用该平台的能力顺利完成了应急，心中的石头终于可以落地了！

六、云展云舒

       通过以上的系统设计，小白团队终于实现了人人皆可应急的目标。在节假日，小白也终于过上了轻松的假期生活。