引言
巡检平台是一个面向运维人员的开箱即用的巡检产品，提供自动诊断问题的自动化运维能力。产品不仅提供了自动化的巡检能力和巡检报告给运维工程师使用，还针对巡检报告中的问题提供了运维专家经验的优化建议供修复时参考。运维人员也可以根据自己的定制需求，通过多样化巡检原子能力灵活定制个性化巡检项加入到定期巡检任务中，巡检原子能力包括脚本巡检、HTTP(S) 接口巡检和 IP 巡检；该平台还具备覆盖多个垂直产品和多个维度巡检的分类能力，运维人员可以根据产品归属不同人员等方式，让不同用户订阅不同的巡检报告，从而大大减少运维工程师定期手工巡检的工作量。
01巡检现状
随着专有云接入的云产品、交付的客户越来越多，云平台在日常运行过程中总会有一些疑难杂症和隐性的问题让运维人员头疼，为了保障云平台的稳定运行、业务的连续性，监控、日志、巡检这些成了云平台标配组件，其中巡检作为运维保障体系中重要的环节之一，能够帮助运维人员发现系统存在的隐患，提前治理，做到防患于未然。
在老巡检方案中，巡检由执行机 定时器 Excel，在大规模集群下，这种老巡检方案逐渐暴露出了一些问题：
- 巡检任务的执行依赖执行机，存在单点故障
- 巡检结果分散在 Excel 中，不利于结果的收集和分析统计
- 巡检脚本烟囱式发展，没有和 CMDB、监控告警、消息平台等系统打通
- 巡检脚本分散在各云产品，没有平台统一管理
- ......
这样的问题还有很多，并且随着云平台在可用性、可靠性、性能、水位、安全等方面要求越来越高，会有越来越多的产品需要巡检，一个灵活、稳定、可扩展的巡检系统就显得极其重要了。
02平台特性
巡检平台具有如下优势：
开箱即用：平台默认配置了大量巡检项和巡检计划，定时自动发起巡检任务和发送巡检报告；
专家优化建议：巡检任务定时执行成功后，平台会自动发出巡检报告，报告内容包含运维专家经验的优化建议供参考，即使运维新手也能相对容易的诊断运维问题；
灵活定制巡检项：针对高级运维人员，可以使用平台的上传脚本、HTTP(S) 和 IP 巡检方式定制巡检项，按照接入规范可以快速扩展新的巡检项；
订阅报告和告警：可以通过邮件、微信、短信等方式订阅不同巡检项的巡检报告，还可以根据告警级别及时订阅最近的巡检结果。
03产品架构
应用层
应用层作为巡检平台的统一入口，提供巡检项管理、计划管理、任务管理、报告详细查看和下载等功能。
概览：展示历史报告中告警数量（严重/警告/提醒）排序 TOP5 和趋势图、展示历史计划数和任务数的趋势图、展示历史报告中巡检分布比例和数量，包括产品、巡检分组、告警类别。
巡检计划：自定义巡检计划的巡检项、执行频率、告警接收人，启停操作。
巡检项：支持脚本巡检、HTTP(S) 巡检、IP 巡检（TCP、UDP、ICMP协议等，支持为巡检项设置超时时间，支持对巡检结果配置警报规则。
巡检任务：查看任务进度、停止任务、查看任务日志。
巡检报告：支持查看巡检报告报告的概览和详情，并能下载 HTML/CSV 格式的报告。
存储层
存储层负责保存巡检平台的相关数据，分成 Etcd、MySQL、包管理 3 个模块：
- Etcd：存储动态数据，例如巡检计划、巡检项、执行中的巡检任务等，这里引入 Etcd 主要是使用了 Watch 机制来实现计划的定时调度和巡检任务的触发；
- MySQL：用于存储静态数据，例如巡检报告、执行结束的巡检任务、操作记录等；
- 包管理：包管理是巡检平台之外一个独立的服务，提供了软件包上传、下载、版本管理的功能，这里引入包管理来实现巡检脚本的管理。
逻辑层&调度层
逻辑层&调度层负责巡检任务调度执行、结果收集、规则判断、报告发送等核心逻辑。巡检平台借助流程编排引擎实现巡检任务调度执行这部分功能，流程编排引擎是专有云自动化运维的基础组件，提供了流程编排和流程调度到指定机器执行的能力，在编排能力上提供了超时控制、子流程、分支拆分以及合并等，在执行能力上提供了命令执行、执行结果收集、执行结果上下文共享等，这些能力足以覆盖巡检平台的需求：
- InspectionItem Controller：负责将巡检平台巡检项翻译成流程编排引擎认识的流程模板，同时维护巡检项和流程模板之间的映射关系，每个巡检项对应流程编排引擎中的一个流程模板；
- Job Controller：负责消费 Etcd 中的巡检任务，一个巡检任务关联着一个或者多个巡检项。首先根据巡检任务关联的巡检项生成一个父流程模板，每个巡检项都与父流程模板中一个 SubWorkflow 类型的 Node 对应；接着会以这个父流程模板创建一个流程实例，每个巡检任务都对应流程编排引擎的一个流程实例，实例创建后会不断查询流程实例的状态，直到流程实例为终态（Succeeded、Failed）；然后会根据流程实例的执行输出收集巡检结果；最后根据巡检结果进行规则判断、巡检报告生成和通过消息平台实现巡检报告的发送；
- CronJob Controller：负责周期性创建巡检任务，实际是往 Etcd 生产一个巡检任务。
在大规模巡检下，为了保障巡检平台的稳定性以及防止大量并发任务把巡检目标打爆，巡检平台提供了并发控制策略、超时控制策略。在并发控制方面提供了 3 种策略供使用者选择，用户可以根据不同业务场景选择相应的策略：
- AllowConcurrent：允许并发策略，如果上一个巡检任务还未结束同时又到下一次调度的时间点，这时候调度器会正常创建巡检任务，同时跑两个任务；
- ForbidConcurrent：禁止并发策略，如果上一个巡检任务还未结束同时又到下一次调度的时间点，这时候调度器会放弃创建这个时间点的任务，直到上一个巡检任务结；
- ReplaceConcurrent：替换策略，如果上一个巡检任务还未结束同时又到下一次调度的时间点，这时候调度器会停止上一个任务的执行，然后创建一个新的巡检任务；
在超时控制方面，用户可以为每个巡检项设置超时时间，执行超时的巡检项会自动被 kill 掉继续执行下一个巡检项。
执行层
执行层由一个或者多个执行机组成，每个执行机都部署着流程引擎命令通道依赖的 agent、python 环境，由 agent 执行来自逻辑层&调度层下发的巡检任务，任务的执行结果通过 stdout 或者公共函数 set_output 导出的方式收集到巡检平台。巡检很依赖巡检目标服务的稳定性，当出现网络抖动的时候很可能就会出现巡检失败，为了弱化这些环境因素带来的影响，在执行层的加入了优雅的重试机制，会在巡检失败的时候进行重试，默认重试次数是 3 次，会在一定范围内随机等待一个时间后重试。
04效果实现
内置巡检项
巡检平台内置了 400 巡检项，覆盖了计算、网络、存储、平台等核心产品，巡检类型涵盖了可用性、可靠性、性能、水位、安全，这些内置巡检项开箱即用，一键巡检，无技术门槛。
巡检成果
巡检平台已经稳定运行大半年的时间，接入了 400 个巡检项，巡检项覆盖专有云大部分产品，执行了 30000 次巡检任务，总共发现了 200000 个系统隐患。
最近 7 天巡检发现的系统隐患趋势图如下：
最近 7 天巡检报告-巡检项分布图如下：
目前巡检平台通过制定巡检项开发规范来巡检标准化，通过平台来调度执行巡检来实现巡检流程化、自动化，但是对于巡检后发现的隐患仍需人工去解决，无法做到巡检 治理全自动，下一步将在联动智能诊断、大数据分析方面进行探索尝试，配合运维平台实现自动化处理。
-END-
