供稿 | eBay ADI Team
作者 | 张晶
编辑 | 顾欣怡本文3121字，预计阅读时间10分钟更多干货请关注“eBay技术荟”公众号
1. 背景
ebay有十二万台服务器，机器的检测和维修需要耗费大量人力，而且有些问题单靠人力很难解决，比如稳定性问题的重现，一直是痛点和难点，需要自动化的解决方案。
2. 策略
ebay前后有来自于4个vendor的100多种机型，为了将机型多样性造成的复杂度降到最低，需要用统一的方式来解决问题，包括: 统一的测试流程和统一的测试集。
如下图， 整个流程的核心是系统的性能和稳定性测试。
（点击可查看大图）前一部分主要做烤机前远程操作问题的诊断和排除，包括网络问题，lom问题，dhcp问题，pxeboot问题等，从而使系统进入一个统一的测试环境。在排除网络，LOM和电源问题后，系统会通过minios从网络和内存启动公版unbunto18.04，同时进行bios版本检测和重置以及raid配置重置，从而最大限度排除软件问题的干扰。后一部分是测试结果的分析和问题的定位。整个流程除了以下三个地方外（黄色标记），不需人工介入：1）发现网络有问题，需要检查网络物理连接时；2）关键底层服务比如dhcpserver宕机时；3）发现硬件有问题，需要更换硬件时。这三个步骤的自动化我们可以通过和jira的整合来解决。通过自动开关，扫描jira ticket状态，可以做到无缝接入。当人工工作完成时，系统会自动验证并继续下一步。
测试集的作用主要是进行压力测试和产生性能跑分。
如下表所示，我们针对各组件尝试和选取了一些比较常用的测试工具。这些工具能通过参数配置使其利用最大的系统资源来进行压力测试。同时设置运行时间来满足短时间和长时间两种不同的测试需求。（点击可查看大图）短时间针对快速的需求，也是大多数情况下会被使用的，在最快的时间内检验机器的基本稳定性和性能。长时间针对能通过短时间测试但用户还是怀疑有问题的机器，通过长时间的烤机来暴露一些不太容易重现的问题。时间的设置是一个反复实践的过程，通过反复测试，我们发现短时间控制在两小时之内比较高效，可以发现90%的问题，剩下的10%可以通过把测试时间延长到一天暴露出来。同时我们还针对各个组件选取了一些会返回跑分的测试工具，比如针对CPU的linpack，针对memory的mlc，针对nic的iperf，目的是能定量地衡量机器的性能。我们会通过存储、计算、比较这些得分来判定系统是不是有性能问题。后面会提到具体的算法。如下图所示，我们将从各数据源收集的数据（包括测试工具的跑分和各种日志的扫描结果），以错误类型归类统一存入数据库。错误类型主要以各组件类型定义，并附上机型，厂商，时间等详细信息，以方便查询和统计，也为将来的机器学习积累数据（错误预测，库存预测，错误模式（关键字）自学习）。
压测结束后，如果存在稳定性问题，系统就会崩溃或者在各日志文件中留下错误信息，我们可以通过扫描它们来判定和定位硬件问题。错误的定位是个比较繁琐的问题，受机型多样性影响较大。每种机型的定位方式可能会略有不同，需要研究所有的机型来完成百分百的覆盖，下面列出可以总结出的一些共通点：
以扫描sel log为准，并且sel log能给出问题CPU/内存的具体定位如dimm / processor id。错误模式（关键字）如下表，memory问题也可以扫描mce log，但要注意排除偶发的correctable error，因为correctable error在大量的读写压测下偶尔会发生，很难完全避免。但它会被硬件自动纠正，不会对系统造成实质影响。以磁盘smart self test的结果为准。bad blocks造成的读写问题一般可以通过format磁盘修复，不需要换盘。而如果smart self test报错的话，就需要更换磁盘。
通过smartctl或读取raid卡的状态信息，可以定位错误磁盘的序列号。以比较iperf压测前后系统记录的丢包数量为准。如果压测后丢包数明显变多的话（特别是TX），则判定为网卡问题。4）备用电源、风扇问题以扫描 ipimi sensor状态为准，从ok变为ns或者fail/error，则判定为备用电源、风扇问题。主板上元器件众多，任意一个元器件的损坏都可能引起问题。但因为没有非常有针对性的测试工具，所以只能使用排除法。当排除以上所有问题但还是存在以下现象时，我们会判定为主板问题。※ 性能问题※ 系统崩溃首先，我们是如何判定机器的性能有问题的？vendor没有给出每种机型的衡量标准，而且机器种类众多，我们不可能有现成的可以直接使用的标准，通过探索，我们决定采取动态计算的方法来得到这个标准。在测试集统一的基础上，按机型（sku）来统计各组件（CPU，memory，disk...）压测跑分的均值（注意要排除异常数据）。从一个机型上架开始，我们就有了这个机型的测试得分记录。如果某台机器的某个组件得分低于其他机器统计均值的40%，就可以判定有性能问题。这也是建立在所有的测试是在统一的测试环境中进行的基础上的（相同的操作系统、固件版本、配置等）。其次，关于系统崩溃证据的抓取，一直是自动化的一个难点。因为系统是从内存启动，崩溃后自动重启，不一定会留下日志。崩溃后的重启也可能和人为的误操作重启混淆。如果能有一种方式时刻记录屏幕输出，我们就能抓到崩溃的证据。同时这种方式可以推广到整个流程的各个环节，相当于有个人时刻盯着屏幕并根据输出进行相应操作，从而使任何人为盯屏操作都可以被自动化。系统启动的过程也能被记录和监控，从而自动识别启动时发生的问题。经过探索，我们运用ipmi sol activate + screen实现了屏幕输出的实时监控和动态交互。其中实时监控需要用ansi2txt将ipmi sol activate输出流转码为可读文本进行扫描，动态交互需要用screen -X stuff 命令向屏幕发送指令。
庞大的测试需求需要我们有一个灵活，高效，稳定的执行框架。具体来说要满足以下三点：
1）测试流程的每个步骤可以模块化比如：重启模块，lom修理模块，压测模块等等。模块化方便了逻辑的重复利用和灵活组合。各模块的执行顺序可以灵活定义。我们的job系统采用基于quartz的设计，结合枚举类接口，实现了job的模块化。首先实现quartz的Job接口，使其根据不同的job名称来执行不同的job逻辑。比如我们这里要定义的job名称是StabilityTestJob。同时注意使用 @PersistJobDataAfterExecution 和 @DisallowConcurrentExecution annotation来持久化job执行数据并关闭并发模式以便job能按模块按顺序执行。然后定义StabilityTestJob的执行逻辑为判定当前执行模块并执行它的process方法。
再利用定义枚举接口来实现job的模块化定义，各个模块的具体执行逻辑通过接口方法process 实现，各模块之间的流传通过设置当前模块名称来实现。每个模块的具体逻辑可以定义在task中以便重复利用。
最后定义quartz的job触发方式为按一定时间间隔（比如10秒）在一段时间内（job最大允许运行时间）连续触发（如果job已经在执行则忽略该次触发），这样就能实现job的分模块按顺序执行。
2）高并发性根据不同需求，每天可能有30000+不同job需要执行，需要能支持3000+的并发。
3）高稳定性因服务器故障，如果job执行被意外中断的话可以自动failover并继续执行。单纯的quartz cluster模式能满足稳定性要求，但并不能满足我们的并发性需求。因为它是通过数据库来同步各调度服务器的，而各服务器需要争抢同一个db table lock会造成瓶颈。实测job并发数超过500就会有严重延迟。quartz local 模式结合hsqldb in memory虽然速度快，没有lock瓶颈，但各服务器独自为战没有相互备份能力又会影响稳定性。所以我们开发了特别的模式来同时满足这两个需求，具体设计如下图：各调度服务器使用quartz local +hsqldb in memory模式，同时利用Listener接口将本地执行数据同步到统一的mongodb（选择mongodb是因为更好的可扩展性） 。在此基础上设计了failvoer，recovery模块，能在某台服务器发生宕机时根据mongo数据将它的运行时job状态自动恢复到另一台比较空闲的服务器上，这样就做到了并发性和稳定性的统一。
ebay提供了一个很好的平台，让我们能有机会对海量的服务器进行测试、维护和修复。自动化的过程是一种挑战也是一种乐趣，它帮助我们大大提高了工作效率，提升了服务器的健康率，使我们从繁琐的手工重复工作中解放出来，转而投入更进一步的自动化或者数据挖掘的研究，形成了良性循环。在做自动化探索的同时我们也加深了对各种机型、配件、厂商和工具的了解。不断完善的通用统一的测试流程和测试集也为新一代机型的选取和使用做好了准备。
👇点击阅读原文，一键投递 eBay大量优质职位，等的就是你