故障

作者：vivo 互联网服务器团队- Liu Xin、Yu Dan本文基于故障定位我的项目的实际，围绕根因定位算法的原理进行开展介绍。鉴于算法有肯定的复杂度，本文通过图文的形式进行阐明，心愿即便是不懂技术的同学也能了解。 一、背景介绍1.1 程序员的困扰作为一名IT从业人员，比方开发和运维，多少有过相似的经验：睡觉的时候被电话叫醒，过节的时候在值班，玩耍的时候被告诉解决故障。作为一名程序员，咱们时时刻刻都在想着使用信息技术，为他人解决问题，晋升效率，节省成本。随着微服务架构的疾速倒退，带来一系列简单的调用链路和海量的数据。对于咱们来说，排查问题是一个大挑战，寻找故障起因犹如海底捞针，须要破费大量的工夫和精力。 1.2 现状剖析vivo曾经建设了一套残缺的端到端监控体系，涵盖了根底监控、通用监控、调用链、日志监控、拨测监控等。这些零碎每天都会产生海量的数据，如何利用好这些数据，开掘数据背地的潜在价值，让数据更好的服务于人，成为了监控体系的摸索方向。目前行业内很多厂商都在朝AIOps摸索，业界有一些优良的根因剖析算法和论文，局部厂商分享了在故障定位实际中的解决方案。vivo有较完整的监控数据，业界有较完整的剖析算法和解决方案，联合两者就能够将故障定位平台run起来，从而解决困扰互联网畛域的定位问题。接下来咱们看下施行的成果。 二、施行成果目前次要针对均匀时延指标的问题，切入场景包含两种：被动查问和调用链告警。 2.1 被动查问场景当用户反馈某个利用很慢或超时，咱们第一反馈可能是查看对应服务的响应工夫，并定位出造成问题的起因，通常这两个步骤是别离进行，须要用到一系列的监控工具，费时费力。如果应用故障定位平台，只需从vivo的paas平台上进入故障定位首页，找到故障服务和故障工夫，剩下的事件就交给零碎实现。 2.2 告警场景当收到一条对于均匀响应工夫问题的调用链告警，只需查看告警内容下方的查看起因链接，故障定位平台就能帮忙咱们疾速定位出可能的起因。下图是调用链告警示例： 图1 调用链告警 调用链是vivo服务级监控的重要伎俩，上图红框内起因链接是故障定位平台提供的根因定位能力。 2.3 剖析成果通过以上两种形式进入故障定位平台后，首先看到的是故障现场，下图示意服务A的均匀响应工夫突增。 图2 故障现场 上图红框区域，A服务从10:00左右，每分钟均匀时延从78ms开始增长，突增到10:03分的90ms左右。 间接点击图2蓝色的【根因剖析】按钮，就能够剖析出下图后果： 图3 根因剖析后果 从点击按钮到定位出起因的过程中，零碎是如何做的呢？接下来咱们看下零碎的剖析流程。 三、剖析流程 图4 剖析流程 红色箭头各局部组成了一个递归调用 图4是根因剖析的次要流程，上面将通过文字详细描述： 第一步：前端将异样服务名和工夫作为参数通过接口传递到后端；第二步：后端执行剖析函数，剖析函数调用检测算法，检测算法剖析后，返回一组上游数据给剖析函数(包含上游服务及组件、稳定方差及pointType)；第三步：剖析函数依据pointType做不同逻辑解决，如果pointType=END\_POINT，则完结剖析，如果pointType=RPC\_POINT，则将上游服务作为入参，继续执行剖析函数，造成递归。 RPC_POINT蕴含组件：HTTP、DUBBO、TARS END_POINT蕴含组件：MYSQL、REDIS、ES、MONGODB、MQ 最终剖析后果展现了造成服务A异样的次要链路及起因，如下图所示： 图5 链路及起因 在整个剖析过程中，剖析函数负责调用检测算法，并依据返回后果决定是否持续下钻剖析。而外围逻辑是在检测算法中实现的，接下来咱们看下检测算法是如何做的。 四、检测算法4.1 算法逻辑检测算法的大体逻辑是：先剖析异样服务，标记出起始工夫、稳定开始工夫、稳定完结工夫。而后依据起始工夫～稳定完结工夫，对异样服务按组件和服务名下钻，将失去的上游服务工夫线分成两个区域：失常区域(起始工夫~稳定开始工夫)和异样区域(稳定开始工夫～稳定完结工夫)，最初计算出每个上游服务的稳定方差。大体过程如下图所示： 图6 检测算法 图中异样服务A调用了两个上游服务B和C，先标记出服务A的起始工夫、稳定开始工夫、稳定完结工夫。而后将上游服务按工夫线分成两个失常区域和异样区域，规范是起始工夫 到 稳定开始工夫属于失常区域，稳定开始工夫 到 稳定完结工夫属于异样区域。 那么稳定方差和异样起因之间有什么关联呢？ 其实稳定方差代表以后服务稳定的一个量化值，有了这个量化值后，咱们利用K-Means聚类算法，将稳定方差值分类，稳定大的放一起聚成一类，稳定小的放一起聚成一类。如下图： 图7 K-Means聚类       最初咱们通过聚成类的稳定方差，过滤掉稳定小的聚类，找到最可能造成异样服务的起因。以上是对算法原理的简要介绍，接下来咱们更进一步，深刻到算法实现细节。 4.2 算法实现（1）切分工夫线：将异样工夫线从中点一分为二，如下图： 图8 切分工夫线 (2) 计算稳定标准差：使用二级指数平滑算法对前半段进行数据预测，而后依据观测值与预测值计算出稳定标准差，如下图： 图9 计算稳定标准差 ...

作者：徐文梁 爱可生DBA成员，负责客户我的项目的需要和保护。目前在数据库新手村打怪降级中。喜爱垂钓，如果你也喜爱垂钓，能够约个晴好天气，咱们一边钓鱼一边聊聊数据库，岂不快哉。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 问题景象某天早上，正在搬砖，客户发来音讯，反馈某个实例主从延时值重复在一万多到0之间来回跳动，如下: 手动执行show slave status\G命令查看Seconds_Behind_Master延时值，后果如下： 问题定位接到问题，作为一个认真工作的我，立马口头起来。首先确认了下客户的数据库版本，客户反馈是5.7.31，紧接着找客户确认了下复制形式，如下图: 客户现场的slave_parallel_type值为DATABASE,slave_parallel_workers值为0，此时主从同步应用的是单SQL线程形式，在遇到大事务时产生提早的可能性更大。举荐客户换成MTS形式，然而客户反馈之前始终应用的是该种形式，之前未产生此种景象，须要排查起因。 于是和客户确认异样期间是否有业务变动，客户反馈产生问题之前有新业务上线，qps绝对平时大很多，同时存在大量insert和update批量写操作，另外，客户服务器应用的云服务器，配置不高。呈现问题后，新业务曾经长期下线。 理解背景后，就有了排查的方向了。从本源进行剖析，second-behind-master值与三个值无关，1.以后从服务器的零碎工夫。2.从库服务器和主库服务器的零碎工夫的差值。3.mi->last_timestamp。 对于单线程模式下的dml操作，记录在binlog中，query_event 的ev->exec_time根本为0，能够疏忽，因为query_event的exec_time只记录第一条数据更改耗费的工夫，且咱们个别看到是begin。所以last_master_timestamp就根本等于各个event中header的timestamp。一个事务中，GTID_EVENT和XID_EVENT中记录的是提交时刻的工夫，而对于其余event都是命令发动时刻的工夫，此时second-behind-master的计算形式为从库服务器工夫-各个event中header中time stamp的工夫-主从服务器时间差，因而如果存在长时间未提交的事务或者存在大事务在SQL线程利用的时候可能会察看到seconds_behind_master的霎时跳动。 因为目前新业务曾经下线，业务量曾经慢慢复原到失常状态，故暂未做其余解决，倡议客户察看一段时间，一段时间后客户反馈恢复正常，到此，问题解决了。 问题思考问题解决了，然而爱推敲的我却陷入了思考。脑海中浮现出几个问题，第一，怎么尽可能防止这种景象？第二，怎么确定是否有长时间未提交的事务和大事务呢？第三，发现这种问题如何解救呢? 其实从事务倒退历程来看，这三个问题也恰好对应着问题处理过程中的预防，诊治，医治三个阶段。 对于预防，即第一个问题，能够从以下几个点登程:1.生产环境条件容许的状况下倡议开启并行复制。2.在业务上线前进行业务量评估和SQL审核，防止某些不标准SQL或业务逻辑导致呈现上述问题。 对于排查，即第二个问题，排查长时间未提交的事务或者大事务能够通过show processlist命令或查看information_schema.innodb_trx表进行排查，然而这个只能查问以后的事务，对于历史的则无奈进行查找，此时能够通过mysqlbinlog或者my2sql工具解析binlog日志，然而后果往往不直观，征询了一些前辈，举荐了一款infobin工具，本人测试了下还是挺好用的，应用示例: 执行命令 infobin mysql-bin.000005 20 2000000 10 -t >/root/result.log 其中，mysql-bin.000005示意须要解析的binlog文件名，20示意是分片数量,将binlog分为大小相等的片段，生成工夫越短则这段时间生成binlog量越大，则事务越频繁，2000000示意将大于2M左右的事物定义为大事务，10示意将大于10秒未提交的事物定义为长期未提交的事务，-t 示意不做具体event解析输入，仅仅获取相应的后果。 输入后果如下: #示意是小端平台Check is Little_endian[Author]: gaopeng [QQ]:22389860 [blog]:http://blog.itpub.net/7728585/Warning: This tool only Little_endian platform!Little_endian check ok!!!-------------Now begin--------------#MySQL的版本Check Mysql Version is:5.7.25-log#binlog格局版本Check Mysql binlog format ver is:V4#binlog不在写入Check This binlog is closed!#binlog文件总大小，单位字节Check This binlog total size:399899873(bytes)#load data infile场景不做查看Note:load data infile not check!-------------Total now--------------#事务总数Trx total[counts]:1345#event总数Event total[counts]:58072#最大的事务大小Max trx event size:7986(bytes) Pos:560221[0X88C5D]#均匀每秒写binlog大小Avg binlog size(/sec):610534.125(bytes)[596.225(kb)]#均匀每分钟写binlog大小Avg binlog size(/min):36632048.000(bytes)[35773.484(kb)]#binlog调配大小--Piece view:(1)Time:1671419439-1671420094(655(s)) piece:19994993(bytes)[19526.359(kb)](2)Time:1671420094-1671420094(0(s)) piece:19994993(bytes)[19526.359(kb)](3)Time:1671420094-1671420094(0(s)) piece:19994993(bytes)[19526.359(kb)](4)Time:1671420094-1671420094(0(s)) piece:19994993(bytes)[19526.359(kb)](5)Time:1671420094-1671420094(0(s)) piece:19994993(bytes)[19526.359(kb)](6)Time:1671420094-1671420094(0(s)) piece:19994993(bytes)[19526.359(kb)](7)Time:1671420094-1671420094(0(s)) piece:19994993(bytes)[19526.359(kb)](8)Time:1671420094-1671420094(0(s)) piece:19994993(bytes)[19526.359(kb)](9)Time:1671420094-1671420094(0(s)) piece:19994993(bytes)[19526.359(kb)](10)Time:1671420094-1671420094(0(s)) piece:19994993(bytes)[19526.359(kb)](11)Time:1671420094-1671420094(0(s)) piece:19994993(bytes)[19526.359(kb)](12)Time:1671420094-1671420094(0(s)) piece:19994993(bytes)[19526.359(kb)](13)Time:1671420094-1671420094(0(s)) piece:19994993(bytes)[19526.359(kb)](14)Time:1671420094-1671420094(0(s)) piece:19994993(bytes)[19526.359(kb)](15)Time:1671420094-1671420094(0(s)) piece:19994993(bytes)[19526.359(kb)](16)Time:1671420094-1671420094(0(s)) piece:19994993(bytes)[19526.359(kb)](17)Time:1671420094-1671420094(0(s)) piece:19994993(bytes)[19526.359(kb)](18)Time:1671420094-1671420094(0(s)) piece:19994993(bytes)[19526.359(kb)](19)Time:1671420094-1671420094(0(s)) piece:19994993(bytes)[19526.359(kb)](20)Time:1671420094-1671420094(0(s)) piece:19994993(bytes)[19526.359(kb)]#超过大事务规定的事务--Large than 2000000(bytes) trx:(1)Trx_size:13310235(bytes)[12998.276(kb)] trx_begin_p:560029[0X88B9D] trx_end_p:13870264[0XD3A4B8](2)Trx_size:385990249(bytes)[376943.594(kb)] trx_begin_p:13909131[0XD43C8B] trx_end_p:399899380[0X17D5FAF4]Total large trx count size(kb):#389941.870(kb)#超过规定长时间未提交的事务--Large than 10(secs) trx:No trx find!#每张表执行对应操作的binlog大小和次数--Every Table binlog size(bytes) and times:Note:size unit is bytes---(1)Current Table:test.sbtest2::Insert:binlog size(0(Bytes)) times(0)Update:binlog size(107440(Bytes)) times(1343)Delete:binlog size(0(Bytes)) times(0)Total:binlog size(107440(Bytes)) times(1343)---(2)Current Table:test.sbtest1::Insert:binlog size(0(Bytes)) times(0)Update:binlog size(399300036(Bytes)) times(50001)Delete:binlog size(0(Bytes)) times(0)Total:binlog size(399300036(Bytes)) times(50001)---Total binlog dml event size:399407476(Bytes) times(51344)对于解救，也即是第三个问题，当然是隔靴搔痒了，利用排查阶段找出的信息，让业务侧去革新了。如果业务侧固执利落，拒不革新，下次早晨中午收到告警的时候先一个电话打给业务人员，要熬夜一起熬，哈哈，开个玩笑。DBA同学大多数都像我一样性情温和的。好了，就到这里吧。 ...

一分钟精髓速览混沌工程作为一种进步技术架构弹性能力和容错能力的简单技术手段，近年来探讨声音一直，相比在分布式系统上进行随机的故障注入试验，基于混沌工程的大规模自动化故障演练，不仅能将“作战演习”常态化，还能通过进步覆盖面而取得更高的产出价值，帮忙更全面地欠缺故障应急预案和解决体系。此前 TakinTalks 分享了去哪儿在过来 3 年里 4 个阶段的混沌工程能力建设（毁坏零碎是为了更稳固？混沌工程在去哪儿的4个阶段实际）。如果说能力建设是从 0-1，那么从 1-100 的大规模自动化演练又是怎么进行的？ 作者介绍去哪儿网高级技术总监 - 朱仕智TakinTalks 社区特聘专家，2013 年退出去哪儿网，负责过公共业务、国内机票、基础架构等团队，善于高并发高可用高性能的零碎设计和落地，多年的技术治理教训。目前负责基础架构部门，蕴含根底平台、中间件架构、大前端、品质保障等团队，近期专一公司整体技术演进和云原生、数字化技术落地。 舒适揭示：本文约 4000 字，预计破费 7 分钟浏览。「TakinTalks 稳定性社区」公众号后盾回复 “交换” 进入读者交换群；回复“1151”获取讲师课件；回复“混沌”获取《混沌工程实际指南》。 背景过来 3 年的混沌工程实际中，咱们对基础设施、利用、依赖、攻防等做了 4 个阶段的能力建设，搭建了能力绝对欠缺的混沌工程平台。那么，在有这些根底能力的前提下，咱们怎么确保它们可能失去执行、能最大限度施展价值？ 可能你常常能看到，业界有这样一种声音，既然线上的随机性演练能力曾经具备了，那么在公司内造就混沌工程文化，让团队被动去执行这些演练，就能达到大规模演练的目标了。而从我的实践经验来看，这样做会导致时效十分慢。 因为齐全靠文化驱动，其实很难保障覆盖面——很多时候可能只有 20% 的同学是喜爱尝试新技术的，他们本身热衷参加到这些翻新的事件中来，但剩下的大部分同学，有的因为开发和日常工作多，并不会十分被动地、自发地去做。所以，齐全依附“文化建设”这个软性条件束缚，很难达到大规模的演练成果。 在去哪儿的实际中，咱们保障落地成果最外围的动作，是建设了一套大规模演练的机制，接下来我会具体介绍这套机制，以及大规模故障演练的落地成果。 一、大规模演练前遇到了哪些问题？1.1 覆盖面的问题利用数量和零碎现状，很大水平限度了咱们的人工演练覆盖面。在去哪儿网，咱们的利用数量高达 3000 多个，同时提供超过 18000 个 dubbo 服务接口，在网关上注册的 HTTP 域名也超过 3500 个，在 MQ 上注册的音讯主题也有超过 13000 个，公司外部大略有 5 种语言技术栈（以 Java 为主）。在这样状况下，咱们要去动员所有人进行人工演练，来保障大规模故障演练的覆盖面，其实是不太事实的——咱们能够做一个假设性的尝试，对每一个利用发动人工演练，假如每个利用只须要 0.2 人日做完（这是一个十分短的工夫），在 3000 +利用的规模状况下，则至多须要大几百人日能力实现。而且，稳定性的保障并不是静止式的做一次就可能一劳永逸了，零碎始终在演进、始终在变动，就须要咱们跟随着一直去演练，能力发现新增的问题。如果是以这么高的人力付出来看，演练很难达到十分大的覆盖面，也就无奈达成很好的演练成果。 1.2  人工成本问题咱们下面说的 0.2 人日，其实曾经是十分小的数据，真正的人力老本会比它高很多，因为在演练过程中，很多中央须要人工参加，比方，演练之前的筹备、打算的制订、演练过程中的察看、人工触发复原，而后还有复盘、改良打算等等，这些都须要有人工的参加。人力老本这部分，从去哪儿的实际来看，次要集中在以下这几个外围点上：触发演练：这里肯定须要有人工的参加，因为尽管有可能是定时的，然而在那个工夫点，是必须要有人工盯着的，去察看和触发执行。依赖关系标注：演练中，每个接口都须要强弱依赖的关系标注，也会消耗掉一部分的人力老本。人工断言：演练的后果进去后，须要人工断言这个论断到底对不对、是强弱依赖的外面的哪一种、要确保演练的流量通过了这次注入的这个问题点等等。部分正确：在没有全链路的状况下，须要对部分演练产生的断言论断，进行全局性的正确性修改。以上这些，都须要人力投入，而且这部分人工的老本想要革除，其实是比拟难的。 1.3  大规模演练技术难点之前咱们大略形象进去大规模的非人工主动演练，它会有几个难点。线上环境须要隔离当咱们要进行十分大规模的演练时，线上环境中的数据，比方，产生的无用订单、各类计费的数据、日志的净化、其余的存储等等，一系列的数据都须要隔离进去，不然大规模的演练流量会影响线上失常业务数据的保留。演练流量从何而来从人工的随机演练变成了主动的大规模演练后，人工触发就不事实了，此时就须要思考流量从哪来的问题。如何主动断言后果须要做到主动断言强弱依赖的后果，演练过程中到底有没有产生影响，这个断言如何做？如何确保命中率命中率是指对依赖进行演练时，流量是否真的通过了依赖。从去哪儿的实际来看，失常状况下，只有大略 40% 的命中率。 二、问题是如何一一解决的？2.1  全链路演练流量和隔离为了解决前两个问题——线上环境隔离和演练流量，咱们应用了全链路压测平台（这个平台也是咱们团队在负责）来反对。去哪儿的全链路压测平台可能做到用例主动生成，线上数据、日志数据都能通过它做隔离，而且它的老本非常低——去哪儿当初基本上全公司的外围场景压测，大略只须要 3 人日就能全副压测一遍，而且它可能进行主动熔断、主动报告。有了这个压测的平台后，咱们就能够把它和混沌工程的过程组合起来，实现线上环境隔离和演练流量的生成。 2.2  全链路演练断言对于全链路演练的断言，咱们做了一个比拟无效的实际——把所有的断言逻辑挪回到入口级别。咱们零碎的拓扑是非常复杂的，但判断当下演练的上游依赖有没有产生故障，最终的判断规范无非就是那么几个—— 第一个：对于 C 端的用户，这个性能真正的用户有没有受影响。第二个：有没有金额上的损失，有没有数据上的问题。第三个：一些外围的数据，比方用户或者订单会不会受烦扰。基于此，咱们就能够做这样的收敛。第一，对入口的后果数据进行后果比照，外围的业务字段比照产生断言论断。第二，对立监控告警平台的外围面板，不便演练过程中监控告警信息，用于熔断演练过程和断言论断。第三，在每个利用上对外围指标进行标注，去看它有没有产生大的抖动，进而用于断言论断。 ...

正视故障和复盘的意义故障也有积极意义在简单零碎中，故障是必然的，无奈彻底防止。从定性的角度来看，并非所有的故障都是好事，有些故障是有侧面意义的，比如说通过一个线上的小故障发现了一个大隐患，或者是某次故障中相干人员的意识和应急预案都很到位，然而因为故障的起因十分非凡最初依然造成了较大的影响等等，相似这样的故障都要找出其中的亮点。 所以，咱们要用辩证的眼光去对待，防止大家“闻故障色变“。为了往这方面疏导，咱们在规章制度方面也做了很多设定，因而在咱们的故障管理制度上，咱们也是激励疾速复原(对于疾速复原的故障定级比拟低)、激励通过演练发现更多的线上问题(对于因为演练导致的故障有肯定的豁免权)等等。然而，大家也应该充沛意识到咱们对故障的理念：即偶然的零碎生效是能够容忍的，人为的犯错是要庄重看待的，比如说不合乎高可用标准的零碎设计模式、强弱依赖设计不合理、因为人员意识不到位带来的故障解决工夫较长、值班人员未及时接通oncall、因为对线上零碎不够器重带来的变更隐患、不恪守变更三板斧标准等等。 复盘的3个目标复盘的目标是为了总结和改良，要充分利用好每一次故障的机会，从中吸取教训进行学习，晋升咱们的教训，欠缺零碎的设计，咱们心愿达到三个目标: 找到根因，从根本上进行优化和改良，给别人带来参考，防患未然。找到升高故障产生概率的办法 - 增大MTBF。找到让业务疾速复原的办法 - 缩短MTTR。零碎和组织都要高可用每一次的线上故障，也是实战练兵的好机会，除开零碎自身的高可用，咱们的组织也应该是高可用的，咱们常常说好的零碎架构是具备韧性的，那么好的团队组织也应该是反软弱的。所以复盘的过程中，除了找零碎自身的问题，还要找工具的问题、流程机制的问题、治理的问题等等。这样，咱们能力由点及面的系统化地解决问题，即治本又治标。 复盘的整体过程 复盘前的筹备故障参会方间接起因方、关联(受影响)方必须全副参加，在复盘文档中记录参会人员名单。工夫线提前梳理分明，做了哪些操作，产生了什么后果等，先与相干人员提前梳理分明，要害信息通过截图等进行佐证。复盘owner每个复盘会议，都必须有惟一的复盘owner，故障的复盘owner要被动疏导大家，推动复盘进度，避免出现一些无意义的指摘、与故障无关的发散探讨等等。 理念宣导提前申明：摆正心态，防止甩锅、批评故障复盘的目标是为了探讨问题，找出改良计划防止再次踩坑。最重要的是要敞开心扉，无所顾虑的裸露问题。会议开始前当时申明复盘探讨的主题、目标。要尽量对事不对人，防止造成对某一方的批评会。营造良好的复盘气氛诚恳：基于事实，敢于抵赖本人的问题；凋谢：对事不对人，在尊重别人的前提下，每个人都能够充沛分享本人的观点与认识；担当：每个团队或集体先从本身找问题，被动提出本人须要改良的中央。复盘的关键环节故障背景概述故障的背景要解释分明本次故障复盘的背景，即产生了什么故障，影响了什么业务(产品)等故障的根本状况。在复盘文档中，能够通过结构化的语言进行表白。例如：“x月x日xx时，xxx零碎出现异常，导致了xxx，影响了xxx业务，表象为用户无奈失常下单，点击下单按钮呈现网络开小差，呈现了大量客诉等等”。故障背景的意义在于让他人第一眼理解分明这个复盘的前因后果，根因能够不必写太多，上面会有根因环节。 对齐故障影响范畴讲清楚本次故障的影响范畴，包含影响时间段、影响的业务(产品)线、影响的零碎(服务)、订单量、用户量、客诉量，以及有无产生资损等等。故障工夫线回放晋升系统可靠性的两个要害伎俩：升高故障产生概率和缩短故障持续时间。回放故障的工夫线，即先从旁观者的角度来理一遍故障过程，是为了思考如何缩短故障持续时间(MTTR)，MTTR即故障的均匀修复工夫，咱们对MTTR其进行拆解，失去如下几个时间段:MTTR = MTTI + MTTK + MTTF + MTTV。 Mean Time To Identify (MTTI): 从故障开始到应急响应染指的工夫，个别是考查监控告警、人员值班oncall的合理性。Mean Time To Know (MTTK):从应急响应染指到故障定位的工夫，次要考查根因剖析、可观测性等工具的能力。Mean Time To Fix (MTTF): 从故障定位到故障复原的工夫，次要考查应急预案、快恢体系的能力。Mean Time To Verify (MTTV):从故障复原之后到确认故障曾经解决的工夫，个别通过用户反馈、自动化测试等确认复原。 因而在回放工夫线的过程中，也要留神对以下几个要害工夫点进行辨认，而后一一沟通探讨如何缩短其中的每一个环节耗时。 须要留神提前辨认进去的要害工夫点: 故障引入工夫点: 即这个故障实际上是从什么时候开始的，可能是某次变更公布/线上操作/其余等。业务指标变动工夫点: 业务指标开始上涨、开始复原等。监控告警收回工夫点: 即监控是从什么发现异常的，告警什么时候收回的。告警的级别、接管人是否响应超时等相干信息都要记录进来。人员染指响应工夫点: 故障对应的零碎值班owner是从什么时候开始响应的。异样定位工夫点: 即定位到故障的异样点，留神:故障处理过程中的根因定位，并非是最底层的根本原因，而是指初步确认了故障的异样点，能够进行下一步的应急止血动作。要害操作工夫点:是否做了一些应急预案，包含重启、复原、止血、高可用配置等。还须要写分明每个操作的后果，即每个操作之后，报错面有无放大、系统资源水位有无变动等。确认故障复原工夫点: 通过测试验证或者观测业务指标、系统日志等确认零碎曾经复原。深挖根因个别状况下，故障是由两类起因引起的，包含间接(诱发)起因和根本原因，也就是所谓的诱因和根因。 因而在复盘过程中，既要明确诱因，更要深挖根因。比如说，某个业务零碎由A/B/C 3个服务组成，依赖关系顺次是A依赖B、B依赖C，某次开发同学批改了线上C服务的一个配置，应用了谬误的格局，导致了整个业务零碎不可用。那么在起因剖析过程中，把配置文件批改为谬误的格局这个动作必定是间接起因，然而也要留神，B服务对C服务的依赖关系是强依赖么？如果C服务出现异常的状况下，B服务是否要进行兜底？等等。 能够基于5why分析法深挖根因，多问几个为什么，层层递进，比如说这样的一个场景: 线上零碎运行过程中，某个ES节点忽然抖动，RT工夫显著变长，95线由200ms升至800ms，而后引发了上游业务异样。 那么在剖析起因的时候，要问以下几个问题: 为什么ES会抖动？ES的可用性规范是什么？ES抖动之后，有呈现告警吗？相干人员有第一工夫染指解决吗？ES抖动之后，上游间接应用它的服务有兜底措施吗？是否为强依赖？对于这个业务场景来说，ES的间接上游零碎是这条链路的外围依赖吗，从整个链路上有无兜底机制？要层层递进深挖根因，千万不要浅尝辄止，那样可能会错过真正的改良事项。从以往的故障来看，很多问题背地都是零碎设计的问题，这样的问题挖得越深，咱们的零碎可用性才会越强，能力缓缓朝咱们现实中的高可用架构后退。 改良项汇总把工夫线和根因别离确认分明之后，就能推导出咱们对于本次故障复盘的改良事项了。在梳理改良事项的时候，除了与故障相干零碎的改良项之外，还须要从整个故障处理过程来看，在故障的各个环节中有无须要优化改良的中央。 比如说某个故障是靠人工(用户投诉)发现的，那么要思考下这个业务的监控告警是否欠缺，是否可能升高故障触达工夫；比如说某个故障的告警收回之后，迟迟没有人响应，那么要从管理制度来看，对于应急值班政策的执行是否到位；比方某个故障的排查过程中，定位比拟苦难，很多中央要靠人工去梳理很多信息，那么要思考相应的排障工具是否好用、应急预案机制是否欠缺等等。 还有很多的问题，大家能够参考下面的MTTR合成环节和故障根因合成环节，本人开展思考下，这也是下面说要深挖根因和详细分析工夫线的目标，这样咱们能力不节约每一次故障的机会。 在记录改良项的时候，能够思考联合SMART准则来设计改良项: S - 必须是具体的（Specific），改良项必须是能够落地的，不要泛泛而谈，例如”优化零碎设计“这类就属于反例。从新设计A系统对B零碎的依赖关系，使其可能对异样进行兜底，这种就属于具体的。M - 必须是能够掂量的（Measurable），即改良项是能够评估的，比如说通过故障演练来测验依赖关系的有效性。A - 必须是能够达到的（Attainable）,在以后的技术环境下，这个改良项是可行的，不要写将来太远的无奈达到的事件。R - 与其余指标具备肯定的相关性(Relevant)，能够了解与本次故障中其余改良项有关联性。T - 必须具备明确的截止期限（Time-bound），要写分明改良项的截止工夫，在到期之后进行验收。最初，改良事项重在闭环，这个环即PDCA循环，Plan（打算）-> Do（执行）-> Check（查看）-> Act（解决），对于咱们的故障复盘来说，即所有的改良事项都必须通过故障演练，通过实战演练来确保改良打算肯定是无效的。 ...

作者：李鹏博 爱可生 DBA 团队成员，次要负责 MySQL 故障解决和 SQL 审核优化。对技术执着，为客户负责。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 <br/> <center>作者自画像</center> MySQL 8 增加了新的 clone 插件，被用于 MGR 的分布式复原当中，也能够用来进行物理备份复原。 然而在进行 clone 操作的过程中，当拉取数据实现并进行主动重启 server 时，总是会呈现重启失败的景象，如： 日志报错提醒 RESTART 失败，须要在前面手动重启，错误代码3707，即：ERROR 3707 (HY000): Restart server failed (mysqld is not managed by supervisor process)。 而在对于 clone 的官网文档相干链接：https://dev.mysql.com/doc/ref...中，也特地阐明了这个报错： 意思说是当 recipient server 在 clone 数据拉取实现后会进行重启操作，前提是监控过程可用。而当呈现相干报错时也不必放心，并不能阐明 clone 失败了，随后只须要手动重启就能够了。 通过下面的日志和官网文档咱们失去了呈现重启失败的两个线索：RESTART 、监控过程。 先看对于 RESTART 的相干官网文档阐明（https://dev.mysql.com/doc/ref...）： 通过这段文档咱们能够晓得，如果想要胜利执行“RESTART”命令，须要有一个监控过程，所以“RESTART”执行胜利与否的要害就在于这个监控过程，而这个监控过程到底是什么文档在前面也进行了阐明： 这时候咱们就晓得在类 Unix 零碎中应用 systemd 或 mysqld_safe 来实现这个监控过程。 然而有时当咱们应用自建的 systemd 的 MySQL service 服务时，仍旧不能实现主动重启，而问题的要害还是在于没有配置好相干的监控过程，咱们能够参考官网 rpm 包装置 MySQL Server 时生成的 systemd 的 service 文件的“[Service]”区域： ...

题目听起来很骇人听闻，不过的确没有夸张的意思，对于咱们来说的确算得上”血案“了。这个问题最终导致了某个底层的外围利用15分钟内不可用，间接导致下层很多利用也呈现了问题，尤其是一些领取相干的业务也呈现了不可用状况。因为故障影响较大，该故障在外部定级很高。故障排查过程也算是一波三折，两头的槽点也比拟多，特地是对网络比拟理解的大佬能一眼看进去问题。这个故障的排查工作我也深度参加了，这里做一下总结，心愿能给大家一些参考。 0. 文章导读本文约 7000 字，配图 26 张。文章绝对较长，因而这里对文章构造做一些介绍。本篇文章分为5个章节，各章节内容概括如下： 故障景象：本章对故障景象进行了介绍，在浏览后续内容前，需先搞清楚故障景象故障排查过程：本章介绍了故障排查过程，并给出了初步论断。故障复现：本章基于故障排查论断，针对性的进行了故障复现和验证，并给出了故障的解决措施再次摸索：从新对故障排查过程进行扫视，并针对其中疑点再次进行摸索，尝试寻找”假相“总结：本章对故障和排查过程中存在的一些问题进行了回顾与总结须要阐明的是，为了升高图片大小，一些异样栈信息被删除了，但外围调用都在。 1. 故障景象4月的某个周日下午2点前后，一个外围利用呈现大量的报警，然而一小会后又主动复原了，从监控上看故障持续时间约为15分钟。翻看了业务日志，发现外面有很多 druid 相干的报错，看起来像是 druid 出问题了。 图1：业务线程大量抛出获取连贯超时异样 图2：druid 连贯生产者线程抛出网络异样 起初从 DBA 那边得悉，阿里云 RDS 因为物理机产生故障，在13:57 进行了主动主备切换。因为 RDS 主备切换工夫与咱们的利用产生故障的工夫很靠近，因而初步判断该故障和阿里云 RDS 切换无关。从景象上看，阿里云 RDS 执行主备切换后，咱们的利用仿佛没有切换胜利，依然连贯到了故障机上。因为 DBA 之前也做过很屡次主备切换演练，始终都没产生过什么事件，所以这个问题在过后看起来还是挺费解的。 以上就是故障的背景和景象，上面开始剖析故障起因。 2. 故障排查过程在开展剖析前，先给大家介绍一下 druid 的并发模型，做一些技术铺垫。 2.1 背景常识介绍druid 数据源应用生产者消费者模型保护连接池，当连接池中没有连贯时，消费者线程会告诉生产者线程创立连贯。生产者创立好连贯后，会将连贯放到池中，并告诉消费者线程取连贯。如果消费者线程在设定工夫没没取到连贯，会抛出一个超时异样。 图3：druid 并发模型 留神，生产者线程是单线程，如果这个线程在某些状况下阻塞住，会造成大量的消费者线程无奈获取到连贯。 2.2 排查过程2.2.1 初步排查这个问题最早是我接手排查的，过后很多信息都还没有，只有异样日志。刚开始排查的时候，我翻看了其中一台机器上的日志，发现日志中只有大量的 GetConnectionTimeoutException 异样，没有 druid 生产者线程抛出的异样。 图4：消费者线程抛出异样 在消费者线程抛出的异样信息里，蕴含了两个与生产者无关的数据，通过这两个数据能够理解到生产者处于的状态。第一个是 creating，示意生产者以后正在创立连贯。第二个是 createElapseMillis，示意消费者超时返回时，生产者创立连贯所耗费的工夫。上图中，createElapseMillis 值约为900秒，这显著是有问题的，阐明生产者线程应该是被阻塞住了。因而依据这个信息，我给出了一个初步论断： 生产者线程被卡住，很可能的起因是在创立连贯时没有配置超时工夫，能够通过在数据库 URL 前面追加一个 connectTimeout 参数解决这个问题。排查到这里如同也能解释通，然而这里有很多疑难没有解决：到底是在哪个办法上卡住了？配置这个参数是否真的有用，是否复现验证？不答复掉这些问题，这个故障排查论断显然不能压服人。因而后续有更多人参加进来排查，收集到的信息也越来越多。 2.2.2 深刻排查这个时候，咱们的 DBA 开始找阿里云技术支持沟通，失去的回答 RDS 物理机呈现了故障，触发了主动主备切换机制。另一方面，其余共事具体浏览了更多机器的谬误日志，发现了生产者线程也抛出了异样。 ...