倒骑的驴不说之前在什么公司
- 线上故障通常是指大规模的影响线上服务可用性的问题或者事件；
- 线上故障的处理过程可以形象地表达为：‘踩坑’、‘跳坑’、‘填坑’、‘避坑’；
- 线上故障的处理不仅是一项技术活，更是对技术人员/技术团队反应能力、决策能力、判定能力、组织能力的考验。面对突发的生产故障，需要快速定位问题，找到解决方案，快速实施解决方案并不是一件容易的事情；
- 本文主要涉及线上故障处理的目标、思路、步骤、基础设施；
线上故障处理的过程也一样，优先级从高到低，线上故障处理的目标如下：
- ‘跳坑’——快速恢复线上服务，或者将对线上服务的影响降到最低； 遇到生产故障后的第一要务是：恢复生产服务，即使不能完全恢复线上服务，也要想尽办法将对线上服务的影响降到最低；
- ‘填坑’——找到问题原因，根本上解决问题； 通常情况下，‘填坑’和‘跳坑’是同步在做的，完成‘填坑’也就意味中‘跳坑’成功，但是也有一些紧急情况下的特别‘跳坑’方法，比如重启服务，或者服务降级/熔断等等，实际并未在当时完成‘填坑’，而是先采取非常规手段‘跳坑’，之后再慢慢‘填坑’；
- ‘避坑’——举一反三，消灭隐患； 找到了根本原因，解决了问题之后，我们需要举一反三，以此及彼，想想在这个故障排查和处理过程中，哪些环节存在弱点？哪些流程/规范/制度需要优化？这类问题是否在其他系统或者团队中也存在？通过这样的反思和自我批评，形成一份线上事故报告，不断完善流程，避免再次踩坑，也在团队中交流经验，共同提高；
依据线上故障处理的目标及目标的优先级，线上排障的第一目标是恢复线上服务或者降低对线上服务的影响，关键点在于“快速”二字，在‘跳坑’-‘填坑’之后，再行回溯总结，以便‘避坑’。因此，可以将线上故障处理的步骤分为：
- 故障发现（‘跳坑’）
- 故障定位（‘跳坑’）
- 故障排除（‘跳坑’）
- 故障回溯（‘填坑’和‘避坑’）
上述步骤并不是说要从上到下顺序进行，建议在不乱阵脚的情况下，并行去做，因为通常线上故障后会紧急启动故障处理程序，运维、开发、测试、产品各个角色都会参与进来，这时候分工下去，并行去做，不断汇总消息，做出判断，以求快速排障，恢复服务。
在无法快速找到故障原因的时候，需要果断跳过故障定位环节，直接进行故障排除，比如采用服务降级、服务器扩容等手段，确保对线上服务降到最低且可控。等到线上服务'撑'过去之后，我们再慢慢定位故障原因，根本上解决问题。
总结：
- ‘跳坑’、‘填坑’、‘避坑’ 的分工；
- 在线上故障后如何有效的协调各个角色的分工、汇总；
线上故障一般可以通过如下几种途径传递到开发/运维人员手中，按照从上到下的顺序，故障的严重程度依次变高；
线上故障传递途径（严重程度由低到高）：
- 主动发现——可能是开发或者运维不经意间查看生产环境的 error 日志，或者例行检查监控项时，看到了一些异常的现象，进而发现了故障；
- 系统监控告警——通常包括 cpu、内存、io、tcp 连接数、disk、线程数、GC、连接池等各个服务器指标异常，可能是服务器出现了异常，但是业务还未受到大面积影响；
- 业务监控告警——如用户登录失败率增加，订单堆积量增大，则意味中系统的异常已经很严重，影响了业务处理；
- 关联系统故障追溯——上游系统或者下游系统的故障处理邮件/电话追溯，可能和本系统有关系，而且情况已经变得很糟糕了，需要快速定位；
- 生产事件上报——通常业务异常带来的影响传递到用户，再从用户传递到客服人员，再到技术人员手里，会存在一定时延，所以一旦有生产事件上报，这个时候严重性已经到了最高，技术人员的压力也会增大，因为会有领导的关注，产品经理的询问和催促，客户人员的焦虑带来的压力。
上述途径传递过来的信息仅仅只是线上故障苗头，并非一定就发生了大规模的线上故障，所以首先需要确认的是
- 这是不是一次线上故障？
- 还是只是个例生产问题？
- 是否和本系统有关系？
一般来讲：‘系统监控告警’和‘业务监控告警’的情况下，大部分都和本系统有关，且可能是线上故障；而‘主动发现’和‘生产事件上报’则需要做甄别，可以根据上报事件个数或者问题复现的方式来评估是否是大规模线上故障，或者跟踪日志信息或者特定用户问题追溯来确定。至于‘关联系统故障追溯’的情况，首先不要慌，先从宏观上确定本系统服务正常，一般可以检查是否有服务器监控报警，是否有业务监控报警等来确定，如果上游或者下游提供了日志，可以通过日志进行追踪，从而确定本系统是否存在故障。
总结：
- 首先要大致确定故障的严重程度；
- 如何宏观的确定系统服务正常（服务器监控报警+业务监控报警）
- 如何确定指定服务是否正常（上下游日志分析）
故障定位的基本方向：
故障定位是一个不断‘收集信息--假设--验证--尝试’的循环过程，基本思路：拿到线上信息，产生怀疑点，拿到更详细的信息，进行推理验证，必要时刻，找到可行的验证措施，进行可控的尝试，或者在测试环境进行业务测试重现，性能测试重现。
可能存在的怀疑点有：
- 新版本发布有问题
- 潜在的程序 bug 被激发，比如在访问量暴增的情况下，并发 bug 被激发
- 业务量暴涨
- 遭遇攻击，如活动期间羊毛党刷积分等
- 上游服务调用异常，如上游系统升级 httpclient 后，将长连接改为短连接
- 下游服务异常，下游服务宕机
- 网络问题
- 服务器故障，如磁盘满，内存爆掉等
- 应用故障
- 数据库故障
为此，可以通过如下几方面收集信息，以便支撑你的怀疑点：
- 最近新版本的发布情况
- 本服务的异常/error 日志
- 本服务的调用量变化情况，是否存在暴涨？
- 本服务的吞吐量，是否出现下降？
- 本服务的时延，是否出现突然增大？
- 服务器 TCP 的链接情况，是否存在大量的 CLOSE_WAIT ？
- 服务器的 cpu 使用率，是否突然飙升？
- 服务器的 disk ，磁盘空间是否已经用完？
- 服务器的内存，内存是否爆掉？
- 数据库或者存储是否挂掉？
很多故障并不是由于单一原因造成的，而是多个条件同时满足时才出现的，所以，需要多收集信息，综合得到的信息，产生怀疑点，快速推理和验证，最后找到问题点，定位到故障。这个过程中可以集合大家的力量，并行去 check 各个点，并快速反馈信息。
由于组合情况众多，这里只将明显的故障定位场景列出，更多的需要总结归纳：
- 发布了最新版本，且故障最早出现时间在版本发布之后，很大程度上时由于新版本发布带来的问题，可能是 bug ，也可能是部署出现问题；
- 未发布新版本，业务访问量猛增，服务时延增大，吞吐量先上升后下降，到最后服务直接不可用，可能原因是：业务量暴涨/遭遇攻击/上游服务异常调用；
- 未发布新版本，部分服务失败，服务错误率增加，业务访问量增加，可能原因是业务访问量增大激发了潜在的并发 bug，或者出现了 io 瓶颈等；
- 业务访问量并未增加，但是服务时延下降，吞吐量下降，服务错误率增加，且服务器 TCP 的 CLOSE_WAIT 增大，这时候需要怀疑下游依赖服务是否异常。
- 业务访问量并未增加，服务大范围不可用，日志中出现大量数据库错，很明显数据库可能出现问题，或者应用的数据库连接池出现问题。
故障定位场景举例
故障定位的初期，一般会先通过邮件+电话的方式进行沟通，如果几分钟之后事态变糟糕，且没有眉目，则需要紧急启动会议形式的联合排障，所有相关人员需要放下手头事情，集中到一个特定会议室进行联合排障。这样的好处也在于能够迅速共享信息，快速做出决策。联合排障人员通常会包括：开发、运维、测试、产品，主力应当是开发和运维，测试和产品需要帮忙快速确认一些东西，如复现问题，或者确认业务逻辑等。
从上面可以看到，故障定位过程中，追求‘快速’二字，为此多项事情是并行去做的。为了避免出现群龙无首的慌乱局面，需要有一个主心骨坐镇，把握排障的方向并最终做出决策，这个人是 master ，需要冷静沉着，且要能调度尽可能多的资源，所以技术 leader 或者运维 leader 会比较合适。这个类似于分布式系统的设计思路。
另外，在故障定位过程中，获得的线上一线信息需要通过某种形式记录下来，邮件往来是一种比较好的方式，在完成通信和信息共享的基础上，也无形中保留了现场。其他的信息包括：error log，dump 文件，服务器各个指标的状态值等等。
总结：
- 饿了么正是这种模式：但这种模式也存在一个问题，但是 master 在做决策时也会失误，并且有可能导致问题恶化，因此这里对 master 具有较高要求，并且需要一个不断演进的过程；前期可以采用多 master ，或轮值 master ；
常规排障手段：
一个特别的场景：无法定位故障的情况下如何迅速排除故障。
很多时候无法及时找到故障原因，必须直接进入故障排除，这时候的思路就在于：尽最大可能降低线上服务影响了。可以采用的手段有如下几项:
- 服务降级——定位到某些服务有异常，但不清楚异常出现的原因，直接将这些服务降级，确保其他服务不受影响；
- 服务紧急扩容——无法定位到是哪些服务造成的，服务器资源彪升，扛不住压力时，紧急扩容服务器；比如恶意攻击、营销活动，秒杀等场景带来的突发情况；
- 回退版本——有新版本发布，但是不能迅速确定是否和新版本有关系，先做版本回退，确保线上服务回到上一个稳定版本。
还是那句话，故障排除的原则是：确保线上服务快速恢复，不能完全恢复的情况下，确保线上服务尽可能少地受到影响。
故障回溯的目的是在故障排除后，冷静地回溯整个线上故障的发现/定位/排除过程，找出流程中/架构中/制度中的缺陷，并将该缺陷消灭掉，同时推而广之到其他系统。在‘跳坑’--‘填坑’之后，我们需要通过故障回溯的过程达到‘避坑’的效果，即要保证自己能‘避坑’，也保证团队/公司能够避开类似的坑。
故障回溯的过程，因人因团队而异，最重要的是要有严肃的‘形式’和最终的产出物。之所以提到严肃的‘形式’，是因为线上故障无小事，一定要让大家牢记在心。
至于如何达到‘严肃’，可以参考如下形式：
- 可以和 kpi 挂钩。慎用，可能会伤害到技术人员的心，造成‘懒政’现象——“多干多出事，少干少出事”出现；
- 可以实施追责制度。同上；
- 还可以进行邮件或者会议形式的讨论，广而告之。
总之，故障回溯的最终的目标不是为了追责，更重要的是让大家长记性，避免后续再次踩坑，而且线上故障报告的产出物一定要有，一方面是经验的积累，便于分享，另一方面也让当事人撸清楚事件过程，吃一堑长一智。
故障回溯流程：
前面谈了线上故障处理的目标、思路和步骤，回过头来看下，要快速准确地定位和排除线上故障，需要很多基础设施支撑，它们是线上故障处理的‘后勤保障’。结合上面的内容归纳总结如下：
通过告警，能让我们迅速知道自己的服务出了问题，通过监控可以从时间维度进行对比分析，找到可疑点，进而定位故障。
监控通常分为：
- 服务器监控——针对操作系统资源使用情况（比如 cpu 使用率、内容使用率、磁盘空间、io、network 等），容器健康程度（内存使用情况、线程数、GC 情况等），application 健康程度的（服务的可访问性等）;
- 服务监控——包括吞吐量、时延等，这些指标至少包括：最大值、平均值，通过这些指标可以判断单个服务的变化情况和健康程度；
- 业务监控——包括访问量、错误率等，一个业务场景往往会包含多个服务调用，因此通过业务监控，可以发现一些关联问题。
告警方面，需要根据实际情况和业务场景进行阈值设定，告警阈值的设定是一个动态调整的过程。
监控系统最基本的需要保证：按照时间序列进行统计、对比。
在线上故障处理过程中，日志尤其重要，通过日志能够定位到问题或者 bug 细节。在分布式架构的系统中，多实例的部署导致日志分散在多台机器上，靠人肉查看耗时费力，效率低下；另一方面，业务发展壮大后，业务系统越来越多，系统间依赖越来越多，各个业务系统的日志需要通过唯一的标识串联起来，否则会出现信息断层的问题，日志变得无用。所以完善的日志 trace 系统非常必要。
日志 trace 体系的几个关键点：
- 有唯一的标识串联上下游系统日志
- 能自动收集分布式应用日志
- 日志收集时延不能超过 10 分钟（具体时间试实际情况而定，如果时延太长，日志没有多大意义）
- 支持多种形式的查询/过滤/统计等
- 可以看到时间序列上的变化趋势
推荐使用开源的日志架构：logstash+elasticsearch+kibana 。
线上故障处理的要点在于快速，所以需要有完善便捷的事件流转机制和故障处理机制来保证：生产事件能快速推送到相关责任人进行联合排除，保证事件排查过程中快速共享信息，快速完成决策。
对于事件上报，一般的公司会有专用的通道给到一线客服人员，客户人员填报工单，上报事件，关键点在于事件处理中担任‘路由’角色的人员，他需要对业务系统比较熟悉，对于上报的问题能快速确定相关的业务系统和负责人，并通知到对方，这个角色既要熟知业务，也要熟知系统架构和组织架构，这个角色一般会交由专门人员处理，称之为‘二线’人员，或者由运维人员兼职。
排查生产事件/故障时，推荐进行集中版本，便于快速共享信息，同时需要有一个 master ，以便把握大的方向，并快速完成决策。
以上，对线上故障处理的目标、思路、步骤及基础设施进行了讨论，先总结如下：
- 线上排障的第一目标是恢复线上服务或者降低对线上服务的影响，关键点在于快速二字，在‘跳坑’-‘填坑’之后，需要总结以便‘避坑’。
- 一切的流程或者手段都是为‘快速’二字服务的，所以线上故障是最高优先级的任务，任何人需要第一时间予以响应；同时，尽早地反馈故障问题，尽早地集结各个角色，群策群力地进行排障值得提倡；这个过程中，需要有一位有‘威望’的 master 坐镇，主持大局；在保证有序推进的情况下，尽可能地并行地收集信息，进行尝试。这个有点分布式架构的味道了，master 坐镇，slave 并行干活，提高效率。
- 必须要有一个‘严肃’的形式让当事人及旁观者‘吃一堑长一智’，线上故障处理报告是必须的产出物。
- 为了更加高效的处理线上故障，需要有完善的基础设施支撑：监控/告警体系、日志 trace 体系、事件流转机制。
对于线上排障的流程整理了一个大图，如下：
本文中部分观点来源于 goole 出版的《Google SRE》一书，这本书中有很多实用的且经过实践证明了的详尽的例子，该书的读书笔记可参考：《Google SRE》读后感
- 任何事情都没有表面看起来那么简单
- 所有事情的发展都会比你预计的时间长
- 会出错的事情总会出错
- 如果担心某个事情发生，那么它更有可能发生
墨菲定律暗示我们，如果担心某种情况会发生，那么它更有可能发生，久而久之就一定会发生。这警示我们，在互联网公司，对生成环境发生的任何怪异现象和问题都不要轻视，对其背后的原因一定要调查清楚。同样，海恩法则也强调任何严重的事故背后都是很多次小问题的积累，当到一定量级后会导致质变，严重的问题就会浮出水面。
那么，我们需要对线上服务产生任何现象，哪怕是小问题，都要刨根问底，对任何现象都要遵循下面问题
- 为什么会发生？
- 发生了该怎么应对？
- 怎么恢复？
- 怎么避免？
在生成环境发生故障时快速恢复服务，避免或减少故障带来的损失，避免或减少故障对客户的影响
- 应第一时间恢复系统，而不是彻底解决呢问题，快速止损
- 明显资金损失时，要第一时间升级，快速止损
- 指标要围绕目标，快速启动应急过程与止损方案
- 当前负责人不能短时间内解决问题，则必须进行升级处理
- 处理过程在不影响用户体验的前提下，保留现场
线上应急一般分为 6 个阶段
- 发现问题
- 定位问题
- 解决问题
- 回顾问题
- 改进措施
过程中要记住，应急只有一个总体目标：尽快恢复，消除影响。不管处于哪个阶段，首先想到的必须是恢复问题，恢复问题不一定能定位问题，也不一定有完美的解决方案，可能通过经验或者开关等。但这可以达到快速恢复的目的，然后保留现场，以及定位问题，解决问题和复盘；
通常我们通过系统层面、应用层面和中间件层面监控来发现问题
- 系统的 CPU 使用率
- Load average
- Memory
- I/O （网络与磁盘）
- SWAP 使用情况
- 线程数
- File Description 文件描述符等
- 接口的响应时间
- QPS
- 调用频次
- 接口成功率
- 接口波动率等
- 对数据库的负载、慢查询、连接数等监控
- 对缓存的连接数、占用内存、吞吐量、响应时间等监控
- 消息队列的响应时间、吞吐量、负载、堆积情况等监控
分析定位过程中先考虑系统最近发生的变化，需要考虑如下几方面
- 故障系统最近是否上过线？
- 依赖的基础平台与资源是否升级过？
- 依赖的系统是否上过线？
- 运营是否在系统内做过运营变更？
- 网络是否有波动？
- 最近的业务量是否涨了？
- 运营方是否有促销活动？
解决问题要以定位问题为基础，必须清晰定位问题产生的根本原因，在提出解决问题的有效方案，没有明确原因之前，不要使用各种方法来尝试修复问题，可能还没有解决这个问题又引入了下个问题，想想刚刚提到的墨菲定律；
解决问题后，需应急团队与相关方回顾事故产生的原因、应急过程的合理性、提出整改措施，主要聚焦在以下几个问题：
- 类似的问题还有哪些没有发生？
- 做了哪些事情，事故就不会再发生？
- 做了哪些事情，即使发生故障，也不会产生影响？
根据回顾问题提出的改进措施，以正式的项目管理方式进行统一管理，采用 SMART 原则来跟进
点评
能否确认业务的曲线是否异于基准线
主要包括：
- 判断影响范围
- 回滚，重启，扩容（线上处理最常用也是最管用的“三板斧”）
- 降级/临时方案
一些经验：
- 线上近 80% 的故障是因为新上线导致的；所以遇到线上问题的时候，如果短期内有项目上线，如果该故障影响范围较大，需要优先考虑将项目回滚或者将新功能的入口关闭以降低风险；
- 一些故障是系统运行到一段时间后系统自身的连接池，内存等耗尽，为了尽快解决问题需要马上重启；不过为了后续继续分析问题，一般会留一台线上机器尸体做后续分析；
- 还有一些问题是线上流量突然增大，如运营活动上线，这时候需要联合运维一起判断，该如何扩容来解决问题。一般的扩容方式是增加线上机器，增大数据库连接池，增加数据库读库等方式；
- 降级/临时方案一般是通过削减非必要功能来保证核心功能的正常运行；
- 有些故障修复虽然修复了，但发生故障过程中会有些脏数据已经写入，需要针对这些脏数据针对性的修复；
一般事故后处理主要包括以下内容：
- 线上脏数据处理，挽回可挽回的损失 一些事故会造成实质性的经济损失，其中部分经济损失可以通过技术手段挽回。比如在给商家结算打钱的时候多打了，这部分钱可以通过正常反结算方式追回；或者一些用户在未付款的情况下购买商品成功了，针对这部分订单可以通过取消订单的方式挽回。
- 测试环境复现 bug ，分析事故原因 尽量在测试环境复现 bug，这样可以仔细分析 bug 的根本原因，一般代码逻辑导致的 bug 在测试环境都可以复现。但一些 bug 只会在特定情况下才会程序出现，比如流量达到一定阈值之后，会触发 JVM 的 GC 问题等；针对这种问题优先分析线上日志信息及系统监控信息，分析线上留下的机器实体，之后再试图在测试环境复现。
- 修复及优化（改进）措施 代码逻辑 bug 的修复，通过正常的业务测试正常上线即可。针对上面系统问题导致的，可以灰度上线一台机器以验证是否解决了问题。
- 事故报告
非常完善、系统的文章，很多内容值得学习借鉴，建议反复阅读；
- 从技术思路出发，我们把故障处理分为预防、发现、定位、止损、恢复几个大的阶段。其中发现、定位、止损三个阶段是故障现场的重点阶段，故障处理的效率提升也主要是在这三个阶段。
快速发现除了传统的系统指标监控外，公司整体以业务不可用时长定义业务状态，当任一关键业务指标下跌一定比例，则认为当前业务不可用。这里最大的挑战是准确判断业务指标下跌，并且准确性难以保证，基于该背景，“核心业务监控”重点在异常检测上投入，实现智能报警，使得业务不可用能及时、准确的发现。快速定位方面，我们的目标是定位到可以确定一个止损预案即可。而定位能力可以说是一个无底洞，比如公网问题需要公网监控、内部交换机问题需要内网监控、机器环境问题需要系统级监控等等，只有相应的监控覆盖之后，才能直观的定位问题，因此各个团队都在发力提升监控覆盖面。但随着监控越来越多，业务规模越来越大，如何快速从众多监控、变更中找到故障根因成为当前的一个难点，建设中的“事件监控”应运而生。事件监控的目标是将各维度的监控报警、各系统的变更以事件的形式整合为一个 timeline，从众多的事件中智能筛选故障根因。快速止损方面，更重要的是平时对预案的建设，以此提升故障阶段的处理效率。在预案建设上，我们主要从时效性、完备性、可执行性三个方面综合来评估某个系统。时效性是指每个预案都应当有保质期，失效前或架构调整时需 review ，根据预案的新鲜程度给予评分；完备性考察各关键系统对预案场景的覆盖率，我们从网络、程序、安全几个方面综合梳理了一个比较通用的场景列表以此来规范各个系统需要建设的预案；可执行性指预案不能只呈现在文字上，还需时常通过演练确定能否达到预期目标，根据预案的执行效率和最终效果进行评分。通过上述的评分机制来引导各个关键系统完善其预案，提升故障处理效率。- 自研的监控平台以 OpenFalcon 为基础的监控体系，基于 OpenFalcon 进行了深度定制（详见《基于Falcon的滴滴内部监控系统》）；
- 收敛数据采集方式：借鉴了开源的 statsd 的解决方案，通过业务代码埋点将状态数据上报给监控系统；
- 数据实时聚合：基于 Spark Streaming, Flink 实现；
- 数据存储能力：主要使用的有 RRDTool、Druid 和 ES ；
- 异常检测智能化：异常检测是监控数据体现意义最重要的一环。比较传统的方式是根据历史曲线变化人为设定一个上下界进行异常报警，在指标项数量小且业务稳定的情况下，该方式成本小、收效快，是个不错的选择。但是对于滴滴来讲，业务高速发展带来的是监控指标类别变化快、量级变化快。因此我们不得不寻求更加智能的手段进行异常检测，现在主要应用的检测手段有三次指数平滑、上下界训练、斜率判定等手段。
- 报警事件统一收敛，智能过滤：目前正在将各个系统产生的事件统一收敛到事件库，同时开展基于时间、底层报警优先的基础规则做一些过滤尝试；
- 监控智能化：
- 异常检测：当前核心业务指标的报警控制完全是基于预测算法来实现的，误报漏报都比较符合预期；
- 智能定位：依赖相关基础建设的建设，比如事件库的统一收敛、事件分类、业务拓扑关系等。
- 从简单的系统监控到现在独立的监控系统的迭代思路：始终遵循着“快准稳全”来迭代；
- 贴合业务需求建立运维平台；
- 从数据准确性、监控系统稳定性两方面进行细节打磨；
- 在查询速度、数据存储上进行重大升级以解决业务的不断发展导致的监控数据不断增长问题；
- 全面铺开各类业务定制化的监控需求；
- 整合监控能力，智能定位根因；
- 导致故障的主要原因是变更操作，主要涉及：
- 手动操作
- 检查点不够完备
- 高峰期操作
- 稳定性建设除基础的技术能力外，各团队的有效协作也是非常重要的点；稳定性建设如何做到全员参与？故障现场如何有组织、有纪律地救火；
- 从业务角度定义故障，智能诊断业务问题。各个系统级的故障比较常见，子系统故障不代表最终用户看到的业务是受损的。因此滴滴从用户的角度出发，定义各个产品线的重点业务指标，并采用预测算法等手段进行故障的智能发现；
- 基础监控能力建设，故障处理最佳流程梳理。监控能力将给大家介绍滴滴现有的整体监控建设情况，并详细分享上面提到的监控基础技术数据采集、实时聚合、数据存储及异常检测智能化等技术体系的建设以及其中遇到的教通用的数据处理问题。
- 事件统一收敛，智能定位探索。目前我们对报警类及操作类事件进行统一收敛，形成事件库。初步以 timeline 的方式展现便于大家发现可能的相关事件。另外在智能定位上基于时间、底层事件优先等规则进行的小规模实践也逐一分享给大家。
故障处理最佳实践（处理+排查思路）：
- 通过 BI 业务报警发现业务故障；
- 随即通过“灭火图”快速圈定影响面；
- 在圈定的影响面，通过各个性化的监控来具体定位原因，确定止损方案；