本文开始介绍具体的实现过程。为了表述方便，先定义一些术语，AutoRepairSystem：__AutomaticFaultRepairSystem，简称ARS原子操作：_task最小化操作，机器任务通常指重启和重装_运维人员：运维工程师=SRE=OP，systemengineer=sysRemotemanagementtools：远程控制和操作物理机的工具，如ipmi，ilo首先看ARSOverallviewandflowchart,ARSworkflow,faultdetection：每5分钟发起一次故障检测，获取故障列表当前时刻整个集群的机器，推送到工作流子系统安全策略：遍历故障机器列表，依次执行安全策略，过滤不符合要求的机器，得到符合要求的机器列表可以安全地重新启动和重新安装。服务下线：遍历可安全运行的机器列表，进行下线服务故障维护：服务下线后，发起重启维护操作，轮询机器状态，直到重启成功或维护完成。环境初始化：执行环境初始化，确保机器环境满足业务需求。服务上线：恢复服务，检查服务是否达到可服务状态，流程结束。接下来介绍工作流子系统，就是具体的操作。任务执行的依据；然后依次介绍上述过程中的关键环节：服务下线、故障检测、安全策略、维护工具和SLA；然后使用一个在线示例来说明整个工作流程；最后分享一下系统上线后的运行数据。2.1工作流子系统工作流最基本的功能是驱动一系列预定义的任务依次执行，达到一个明确的结束状态；在机器故障自动处理的问题域中，也有工作流闭环和可扩展性的要求（详见第一篇分析）。在对机器相关的操作任务，如机器重启、重装、初始化环境、启动/停止服务、查看信息等进行分析统计后，抽象出机器操作的任务模型，即“对于一组机器执行同一个任务，而任务又可以进一步拆分成一系列更小的原子操作组合”，如图，上图表示在一组机器上执行相同的任务，下图表示有此任务原子操作中有4个任务。由此，我们可以定义工作流的几个关键类及其关系。注：为了简化表达，这里只列出流程执行、任务分支、通用性相关的字段和逻辑，完整的工作流子系统信息将在后面的文章中写到。Job，定义要操作的任务类型和目标集Task，定义具体的操作目标，action_tree的根节点Action，定义业务逻辑的内容和加载方式Scheduler，调度Job的运行Monitor，并监控Job和Task，Action状态的Executor，控制Job下的task/action的执行顺序和并发度接下来，我们将重点关注工作流系统如何满足上述的可扩展性和闭环需求。第一点是可扩展性。可扩展性需求最初来自于不同服务在线和离线操作的差异，主要是有状态服务。它们之间的区别体现在操作步骤的数量和顺序上。比如推荐模型服务，需要先找到可用的机器资源，在新的资源上部署同版本的服务，启动服务加载数据，判断数据加载的进度。直到达到某个阈值，“迁移”才算完成。Docker服务实现可修复状态相对简单。只需要向docker下发迁移命令，等待docker返回迁移进度即可。迁移完成后，您可以修复Hadoop服务。主要痛点是磁盘故障。要求维护过程中不能长时间停止服务，所以维护逻辑非常复杂。必须先停止本地服务，umount故障磁盘，启动服务，修复故障磁盘，修复后停止服务，启动服务器，让Hadoop重新使用这个磁盘。其他的无状态服务比较简单，通常直接Maintenance就可以看出来，不同服务的差异化不胜枚举。如果ARS要介入具体的维护逻辑，无异于“往上拉屎”，最终会陷入无法自拔的泥潭。我们的想法是：提供一套机制，方便地将维护逻辑嵌入到工作流子系统中。实现步骤如下，将复杂的任务拆解成多个原子操作，每个原子操作实现为一个python方法，返回值Format固定定义原子操作的执行顺序和分支只要满足以上条件，系统可以支持任意顺序的任意数量的原子操作。原子操作的python实现如下图所示。action1为原子操作名称，do_hard_work()方法由业务sre完成，工作流子系统只负责调用。is_succ表示操作是否执行成功，result一般为操作结果信息。只要按照这个协议写的任务能够注册到系统中执行，即使作者只是用python包装了一堆shell脚本，也可以嵌入到系统中，虽然我们会“建议”他在审查期间重写它们。随着原子操作的执行，我们可以定义它们的执行顺序。我们使用“树”的概念，如下图的json配置示例所示。可以看到整棵树由多个子树组成，每个子树指向一个Nodes列表，每个节点就是一个动作，动作的数量和顺序可以在nodes列表中任意配置和展开。在example_trees中，action1~action6是原子操作，执行顺序有两种可能的分支，action1->action2(true)-->action3->action4->end；action1->action2(false)-->action5->action6->结束；假设现在业务有一个比较大的变化，需要在action2之前增加一个actionaction7，在action6之后增加一个分支action8，这个可以通过配置上的小改动来实现，example_trees会保存在action_definition字段中Action类的，这个配置记录了执行逻辑的python文件、类和方法；工作流运行时，会动态加载相应的类，并根据方法名调用方法，如下图所示。有了这些特性，业务sre可以灵活定义自己的任务树，其中公共的部分由平台sre编写，业务相关的部分由业务sre编写。第二点是闭环。以无状态web机器自动宕机处理流程为例，_（这里为了表述方便，简化了）_检测宕机机器，如果能起来就重启机器，检查程序版本，启动web服务，如果不能起来就结束进程，然后报告硬件故障。如果可以修复，返回步骤3。如果无法修复，请检查是否不在保修范围内。如果是这样，请卸下机器。进程树的配置如下。repair_host等动作是原子操作；这棵树有两个分支节点，如果reboot_host后check_host_alive为True，则执行online_service分支，流程结束；如果为false，则执行repair_host分支，如果可以修复，则返回tree2，最后也到达online_service状态，流程结束；（只要不是过保的都可以修）如果不能修，则进入off_rackremoval流程，流程结束。（一般都是机器过保）这里之所以反复强调task分支，是因为有了task分支，可以在各个可能执行失败的环节指定下一个操作，最终目标操作会在一个可预测状态（机器要么修好重新投入使用，要么修不好就下架），形成闭环，无需人工干预，真正提高了自动化程度。同时，由于一开始就设置了维护只有重启和重装两个操作，这两个操作都是由sys来保证投递时间的，所以这棵树可以保证流程是闭环的。ARS上线前，早期的自动工具发出重启命令后，机器无法启动。通常是手动通知sys报修。维修完成后，sys会根据机器是否过保，将维修情况上报给sre。这个过程就像一个黑洞，吞噬了rd-sre-sys-外包机房需要大量的通信时间。如图所示，工作流子系统还涉及到状态机、并发控制、重试、任务重入、超时、执行进度等，后面再写一篇。下一节将介绍故障检测、安全策略等。2.2故障检测故障检测的完整性和正确性是故障维护自动化的前提。通过分析历史机器故障的类型，可以将故障分为五个等级，如下表所示，基本涵盖了sre日常出现的故障。ARS主要涵盖机器层和系统层，下面分别介绍。磁盘故障磁盘故障率高的业务类型很多，比如hadoop、索引服务、分布式文件系统服务、机器学习模型训练服务等，这些服务的机器最大磁盘块数可达36个，大量磁盘读写，导致磁盘故障率高。常见的磁盘故障类型包括丢失磁盘、输入/输出错误、浮动磁盘、挂载错误、只读错误和性能急剧下降（ls/disk/超过10分钟无响应）；磁盘故障的累积，可能会导致数据丢失并拖慢整个系统的性能，因此需要尽早发现并尽快处理。宕机故障宕机故障分为完全死机和假死。彻底死机（指机器连续3小时失去心跳，主动ssh检测失败），这种情况好处理，直接进入自动重启流程；假死，有以下几种，lConnectiontimedoutlConnectionclosedbyremotehostlConnectionresetbypeerlConnectionrefusedlConnectionclosedby这些假死状态可能会导致业务受损。比如机器死机了，服务口还能连上，但是实际业务流程就不能正常工作了。如果前端web机出现这种情况，会导致业务5xx监控飙升；这时候如果想手动重启，ssh已经连接不上了。通过ilo重启，或者紧急联系机房，处理往往需要半个多小时。内存故障发生内存故障时，通常机器还没有死机，（/var/log/message中显示CEerroronCPU#1Channel#2_DIMM#1）rd认为机器还能运行，不愿意停机服务;如果有多个机器出现类似的错误，很可能会在短时间内连续死机，导致服务能力骤减，服务性能急剧下降。因此，对于一些敏感的服务，这种故障应该被视为崩溃。停电双路供电是突发停电和市政建设的保障。如果电源出现故障且未修复，在这种情况下，机器将断电并停机。如果积累太多，服务能力会突然下降，影响业务。风扇故障不会立即导致崩溃，但会产生连锁反应。风扇故障会导致CPU温度升高，导致死机。以上故障检测的实现主要是通过Falcon监控系统+脚本实现的，涉及到大量的系统命令和系统信息如ping/ssh/ipmi/dmesg/proc/sar...Falcon运行这些脚本进行检测故障列表，外部应用可以通过该接口查询故障列表信息。如下，ARS从Falcon中拉取集群中当前时刻所有故障机器的列表，并附上相应的故障信息，推送到工作流中。进行维修。2.3安全策略对机器的操作通常是重装、重启、修改根环境、部署基础代理等；此类操作往往是不可逆的，无法暂停，因此需要严格的安全策略来确保机器操作不影响在线服务或影响最小。在“故障检测”环节之后，会得到当前时刻所有故障机器的列表。安全策略将分析和过滤这个列表。下表是我们使用的安全策略列表。这个安全策略表是对多个业务线的总结和分析。根据历史案例分析，上线至今未出现误判，保证了自动化任务的安全性。每个安全策略在工作流中被实现为一个原子操作，即action。结合上面重启的例子，json配置如下。（维护过程中也可以使用这些安全策略，这里不再一一列举。）这些策略可以复用，也可以自由组合和调整，对于连接不同服务的机器进行自动维护非常方便灵活，并且同时降低了连接成本。如果业务有自己的安全策略需求，只需要根据上面的action方法规范自己写一个安全策略方法，在配置中指定即可使用。2.4维修工具和SLA机器硬件故障维修是现实世界中的一个事件。这个过程需要人到机房现场，从仓库里取出配件，走到机架边上，拆机，组装硬件。因此，该环节是发生“不可抗力”的地方，如备件库存不足；厂家人员去机房的节假日；机房被封锁，不允许在两场会议期间及时进入。1交货时间为了实现闭环流程，我们（甲方）和机器制造商（乙方）约定一个机器维修的交货时间，一般在交货后36小时内（不同公司和制造商可能不同）.至于上述“不可抗力”如何解决，由乙方负责。2远程管理工具的使用率远程管理工具是实现机器操作自动化的必备工具。reboot_host/repair_host底层调用ipmi；为了尽量减少机房现场人员操作，我们要求sys保证远程管理工具的可用率达到99.9%。比如ilo和ipmi这两个SLA，我们可以认为reboot_host和repair_host这两个原子操作的最长耗时是36小时，所以维护过程必须是闭环的，避免任务中断造成的人工干预.当然，有了这些，只是修复了硬件，还有系统参数设置、环境初始化、基础代理等方面的问题。关于这方面的内容比较多，下一篇再说。总结上面提到的技术细节以获得ARS的完整视图。最后看一个自动重启的例子，可以看到任务树中定义的动作是如何执行的。首先执行一系列filter_*安全策略，然后阻塞告警，下线执行服务，发起重启，然后轮询机器状态，直到任务结束。2.5系统运行数据ARS上线后自动处理覆盖数万台机器的故障，死机数保持在10台左右，所有硬件故障总数保持在100个以下，非常理想的状态。在人力方面，对于一个20人的sre团队来说，只需要0.5个人力就可以维持机器故障时系统的正常运行，比如接入新服务、业务需求抢修等；当机器规模增大时，人力无需相应增加。2.6小结最后总结几个重点，标准定义了存在什么类型的故障，对什么故障进行什么样的修复，以及标准的闭环修复流程。对于机器的运行，使用任务分支覆盖运行成功或失败，使用SLA约束厂商在约定的时间内交付机器，保证流程可以达到明确的结束状态，避免人工干预安全,由10个安全策略组成的过滤链，支持低成本添加新策略，保证自动化任务的安全在本文中，还有一个重要的项目没有提到，那就是环境初始化，将在下一篇。整理文字，整理感情。我是曲星人。每天写代码，空闲时间写一些文字。如果觉得有趣或者有用，可以关注我。当大脑中的思维原子在做布朗运动时，我就会输出文字。公众号:qxren7二维码:
