本文概述了携程IT管理数万台办公PC时面临的挑战及应对方案，介绍了通过全链路工具实现故障主动发现和自动修复的运营理念。详细阐述了背景、系统架构选型及各部件，深入说明了工具实践过程中面对的大数据量、脚本运行权限、交互弹窗等问题及其解决方案，并阐明了在运维故障定位和脚本统计优化方面的支持，希望能为大家带来一些启发。
一、前言
随着企业规模的增长，在满足合规、信息安全的要求下，管理大量电脑并满足多样化的员工需求，同时确保员工能够高效、稳定地工作，已成为一项很具有挑战性的任务。
二、现状
公司拥有大量的员工和电脑，电脑故障量较多，虽有各种自动化工具帮助员工自行解决，但仍有不少故障需要运维工程师人工排障。这种被动式的排障管理模式不仅效率较低、耗时长，而且容易遗漏，影响员工的办公效率。因此需考虑采用一种更加主动、高效的桌面运维模式，如自动化的故障检测和主动修复，以提高员工的办公效率和运维团队的工作效率。
三、全链路研发运营实践
为降低公司电脑故障量，引入主动监测电脑健康度的机制，及时发现电脑存在的已知问题，可以主动自行修复，或提醒用户当前电脑的健康情况，由用户自行处置。对一些特定的故障做到提前预警并提前解决，以保证用户能够持续高效办公。
3.1 架构选型
数据采集需开发客户端Agent常驻用户PC，并定期执行，考虑到公司电脑系统的多样性(Windows/Mac/Linux)，为避免多个平台的重复开发而带来的工作量，Agent选用新兴的内存安全和高性能的Rust语言，配合其生态下的跨平台桌面应用程序框架Tauri。实现具有跨平台能力的Agent；
Server端使用SpringBoot，为所有的Agent提供各类接口，完成策略下发、数据收集等；
客户端采集/修复脚本支持Powershell、Bat、exe等类型，脚本均可通过全链路Server端管理页面单独管理发布，功能脚本和Agent独立开，可以最大程度上做到Agent和脚本之间的松耦合，增加后续业务的可扩展性，提高运行效率；
管理后台选用Django、Django-Simpleui、Vue配合开发，通过配置化的框架，快速构建功能丰富的管理后台，并使用Vue对需定制的页面进行完善和补充，提高开发效率
3.2 前期业务评估和设计
公司电脑体量大，每台电脑数十个检测项，加上一小时采集周期，系统将在短时间内产生数千万条数据，在数据库索引设计、整体架构、多线程高并发编程等方面需做好充分设计。采用多线程、异步队列机制对上报数据实现高效落库，提高整体稳定性和时效性；
全链路数据采集有两种模式：定时客户端采集上报和其他系统接口的实时查询。后者依赖外部接口较多且响应时间相差较大，需要在用户检索查询时使用多线程同步等技巧，保证查询速度和用户体验；
全链路Agent和Server端交互数据包括数据采集、脚本下载、策略下发，各场景都需要保证其安全性，各接口均采用双向不对称加密对上报的数据和下载的脚本实现加解密，同时通过Server端的Token实现客户端的会话鉴权机制，保证系统的安全性；
3.3 实战业务流程
1) 客户端
执行调度：客户端用户登录后，Agent定时在客户端自动调度运行，执行权限为System；
下载任务：客户端Agent向服务端请求，获取客户端所需要检测的相关任务列表（检查项，如：C盘剩余空间、账号锁定状态等），任务列表中包含检查项Key、检测脚本名、脚本MD5值、脚本运行参数等信息；
采集脚本：客户端Agent获取对应任务列表后，首先检查本地缓存中是否存在相同MD5的文件，如果存在则直接运行，如果不存在则Agent发起请求从服务端下载最新的脚本文件检查校验MD5后缓存到本地，脚本类型可为：Powershell、bat、exe等；
采集数据：客户端Agent依次调度执行各检查项对应的脚本，采集客户端数据；
数据上报：所有检测项数据采集完成后Agent将数据加密后上报到Server端，由Server端进行解密、数据校验和存储；
修复脚本：Server端对采集数据结果检查，校验后会将检查结果异常需修复的项，下发到客户端Agent，返回数据中包含了检查项Key、修复脚本名、修复脚本MD5值、脚本参数、异常处理、超时时间类型等信息，参数类似采集脚本；
异常处理：修复脚本信息中，异常处理类型有“直接修复”、 “提醒修复”、“仅提醒”三种处理方案（处理类型可再后台页面配置）。Agent依次执行所有“直接修复”相关的脚本，执行后修复结果统一上报Server端进行修复结果存储。“提醒修复”、“仅提醒”相关异常信息在桌面右下角弹框提醒，并对“提醒修复”类型的检查项开放用户确认自助修复，用户自助修复的结果同时上报给Server端进行数据存储；
任务结束：数据采集完成后Agent退出运行，关闭与服务端的会话，释放系统资源；
2) Server端
下发采集任务：Server端缓存所有检查项信息（检测项信息中会包含脚本的MD5值，这在下载流程中会用到），缓存保存2分钟，当接收到客户端任务查询请求时，优先去缓存中查询，缓存中没有则去数据库查询并更新缓存，即能保证查询的速度，同时减轻数据库的压力；
下发采集脚本：检测脚本&修复脚本均为小文件，以BLOB二进制大对象存数据库，同时记录每个脚本的MD5值，与检查项一致，脚本信息同时缓存，客户端请求下载文件时，根据请求体中的MD5值匹配脚本；
数据校验保存：每个检查项均可独立配置检测结果的标准值和校验逻辑，系统对“标准值校验逻辑”列表中的校验项实现了不同的匹配逻辑，客户端上报检测结果时，Server端根据检查项配置的校验规则对每条检查数据进行校验，所有采集数据计算出正常/异常后保存数据库，数据采用了异步队列的方式落库存储，提高接口的时效性，减低客户端接口响应时长，同时所有检测异常的数据，Server端将相关检查项信息（包括修复脚本信息、异常处理类型等）返回给客户端进行进一步的修复工作；
保存修复结果：Server端接收客户端上报给修复结果，Server端保存修复结果；
3) 运维管理
全链路最终交付对象是桌面运维团队，运维管理模块必不可少，全链路提供的管理页面包含了检查项、脚本、灰度管理、修复日志、检测结果查询等模块。
检查项管理：工程师可以根据业务情况自定义新增检查项，检查项关键字段包括CheckKey（检查项唯一标识）、开关（检测项是否可用）、提醒类型（直接修复、提醒修复、提醒）、实时查询（检查项是否实时查询，只有非实时查询类的检查项才会在客户端采集数据）、灰度策略（检测项上线或变更时的灰度功能，保证检查项的平稳上线）、标准值（每个检查项的检测结果标准值或标准值集合）、校验逻辑（包括大于、小于、等于、不包含、被包含等，用于校验数据结果）；
脚本管理：该模块统一处理客户端检测、修复脚本。上传后的脚本会关联检查项CheckKey和脚本类型（检测脚本、修复脚本），以关联检查脚本、修复脚本和检查项的关联关系。此模块还关联到具体灰度策略（每个脚本均有独立灰度功能）、操作系统选项（包含Windows、Mac、Linux，目前只用到Windows，其它为未来扩展预留）、脚本参数（如hostname、username等，用于客户端执行脚本时的固定参数）和超时时间（限制客户端脚本的执行时间，保证采集过程的正常进行）。为确保流程完整性和安全性，脚本上传会启动审批流程，只有审批通过的脚本才能投入生产；
灰度策略管理：用于支持检查项和脚本的生产灰度，灰度维度包括：员工、邮件组、团队、工种、国家、员工批次、电脑名，灰度策略包含黑名单和白名单，黑白名单可以多维度单独配置，并支持黑白名单同时生效，可提高灰度场景的灵活性；
员工批次管理：员工批次是灰度策略中的一种，可以灵活自定义某些没有职级或组织结构关联关系的员工为一个批次，该逻辑可以覆盖补齐所有灰度场景，进一步提升灰度策略的灵活性；
数据查询：运维管理界面提供数据采集结果的查询、筛选，每条结果包机器名、用户、检查项、采集结果、校验结果、上报时间等；
其他：除以上的主要功能以外，全链路运维模块还提供了一些额外的板块，包含提醒配置（用于记录客户端用户选择提醒冷却周期）、权限管理（用于配置和管理每个管理板块的用户权限，提高系统的安全性）等；
4) 安全措施
客户端Agent和Server端之间的数据交互采用双向不对称加密方式，客户端和Server端分别持有一对公钥和私钥（Agent拥有Agent的私钥+Server端的公钥，Server端拥有Agent的公钥+Server端的私钥）。并增加Server端Token鉴权，实现会话机制，当Server端接收到Agent请求时，需要验证Token的有效性及时效性；
公司办公环境复杂（有内网、独立组网、零信任网络环境等），员工办公电脑可能同时存在于各种网络环境中，为了保证Agent能在各种环境内正常工作，Server端同时开通内、外网域名，Agent第一个请求首先使用内网域名，无法通信则自动切换外网域名，本次会话中的后续请求均使用确定好的域名。该机制实现了Agent在各种网络环境的自动适配，保证了系统的可用性；
每次Agent调度执行相关脚本时，都计算本地缓存文件和Sever端接口中的MD5，确保本地缓存文件不会被篡改，避免高权限执行危险命令和程序；
3.4 全链路业务流程图（FLT）
3.5 员工电脑健康度查询
3.6 困难和挑战
1) 采集数据量激增，数据库性能挑战
随着检查项和接入PC数量增加，累计的数据量急剧增加（超过5000W），数据库的性能和系统稳定受到严峻挑战。经过仔细研究后优化，采用数据增量更新策略，同一PC、用户、检测项的结果，如果与前一次执行结果一致，则只更新数据的采集时间，只有在数据不一致时才新增数据记录。通过额外字段标识记录采集结果是否为当前活跃结果，并配合每个客户端Agent执行日志，统计每次Agent采集明细，此机制在保证数据完整性的同时，大大减缓了数据量的增长，据统计数据量减少超过70%；
2) 实时检查项查询逻辑优化
实时检查项的数据均通过外部接口调用获取，工程师在线查询各个检测项的执行结果时后台实时触发接口调用查询，对查询的时效性要求较高，随着实时检查项数量的增加，查询速度逐渐难以满足工程师的要求。采用多个实时检查项并行查询机制，并配合查询结果缓存策略，提高了查询速度。
3) 弹框显示GUI交互问题处理
全链路Agent以System权限调度运行，System权限启动的应用不能直接与当前用户的GUI进行交互，导致用户客户端右下角的弹框提示也无法显示。对Agent调度程序进行了优化改造，拆分为FLT-System.exe和FLT-User.exe，分别以system权限运行和当前登录用户账号运行，FLT-System.exe主要负责执行系统级别的检测修复脚本（例如:网络信息检测），FLT-User.exe负责执行用户级别的检测修复脚本，同时用户弹框界面通过FLT-User.exe唤起。
Agent改造逻辑如下：
FLT-System.exe、FLT-User.exe为两个程序模块，依次调度执行，同时两者之间通过RPC通信实现数据交互；
FLT-User.exe向Server发送请求获取客户端所需要检测的相关任务列表及脚本的下载，脚本运行权限分为system权限、user权限，其中system权限的脚本FLT-User.exe向FLT-System.exe发起RPC调度请求，而user权限的脚本FLT-User.exe会直接调度运行；
FLT-System.exe启动开启心跳监测，FLT-User.exe每过5秒会向FLT-System.exe请求心跳状态，确保程序正常运行，防止系统资源占用。如果不存在心跳，则FLT-User.exe自行退出，释放系统资源。同时FLT-System.exe如果在连续3次都未获得心跳检测请求，也自行退出，释放系统资源；
两个exe之间交互采用双向不对称加密方式通信，RPC调用为localhost网络地址，防止其他应用调用exe接口，保证系统的安全；
FLT-User.exe可在电脑右下角弹出窗口，解决GUI交互的问题，实现用户交互；
Agent拆分的具体设计图:
客户端交互弹窗：
4) 客户端覆盖率提升
全链路工具FLT-User.exe使用当前登录用户权限启动，故在注销状态下无法运行，导致注销状态下的客户端数据无法采集，为了提升客户端的覆盖面，再次对全链路Agent调度逻辑进行优化。注销状态时FLT-System.exe和FLT-User.exe均采用System权限执行，同时限制只运行System权限相关的脚本(User权限相关脚本可能会执行异常，故在此情况下不再调度)，注销状态下无需弹框提醒，GUI交互无问题；
5) 运维故障快速定位和解决
全链路工具覆盖公司所有Windows客户端，全链路运维工作很容易造成线上故障，风险较大，例如：工程师无意修改错检查项标准值，就会导致采集的数据产生大量的异常值，对运维工作会造成极大的负面影响，且排障难度较大。为能快速定位和解决运维故障，在运维管理系统中增加了运维日志模块（审计日志），记录后台页面操作的所有日志，可以快速查询所有的配置修改，为系统长期稳定运行打好基础。
审计日志查询页面如下：
6) 采集链路脚本执行情况统计
由于采集数据是通过客户端单线程队列顺序执行脚本实现，脚本执行的耗时会直接影响采集的效率，再对所有采集工作耗时情况统计分析，正常情况单次采集工作的总耗时平均在2min～5min，非正常的采集耗时有的超过1小时，这种非正常采集降低了全链路的可用性和准确性。对FLT-System、FLT-User调度脚本采集数据的逻辑上进行优化，新增脚本执行耗时统计、脚本执行超时限制（在脚本管理后台可配置），同时数据采集记录表新增“采集耗时”字段，记录检测项脚本执行的时间，为后续各个检查、修复脚本的优化提供数据支持。同时对执行超时的脚本进行主动中止，避免过多消耗客户端资源。优化后提升了整个采集工作的效率，进一步完善了全链路工具。
四、成果
通过全链路工具的运营，实现了电脑故障的自动检测、提前发现、自动修复，改变了以往用户报障后被动式排障的运营管理模式。通过自动化故障检测和主动修复机制，全面提高了电脑的稳定性和安全性，整体人工事件量降低明显，提高了员工满意度。
全链路工具上线后，使得IT运维团队能够通过技术手段，更加有效的管理全公司数万台用途各异、配置不同的办公电脑，大大提高运维团队的工作效率。并且提供了准实时的电脑运行数据监控，同时为网络质量检测、办公电脑数据收集等业务场景提供了有力的支撑。确保满足多样化员工需求和信息安全的前提下，能够高效、稳定的开展工作。
系统上线前后，各类PC主要问题，周平均故障量下降20%-30%。运维团队人工服务量下降超过10%，业务效果显著。
上线前后主要检查修复项故障量下降：
全链路检测项范围内客户端健康度提升：
五、未来
全链路数据采集脚本的执行需要依赖于客户端的环境，相同的脚本在不同的客户端执行后可能有不同的结果（成功或者异常），后续需要具体分析脚本异常问题，提升数据有效性。在未来需要持续不懈地优化和完善系统，不断突破性能的极限，赋予全链路更加强大的功能，为企业提供更为卓越的桌面系统运营解决方案。
