保险公司主动运维与智能运维实践

如果无法正常显示，请先停止浏览器的去广告插件。

2. 海保人寿保险股份有限公司应用运维部经理康守兵

3. 目录 | contents 01 背景介绍 02 运维实践 03 未来规划

4. 01 | 背景介绍

5. 1.1 传统运维的困境 IT运维之痛 u工作繁琐 u鸭梨山大 u值班加班 u设备系统故障 u到处救火 u背黑锅 u7*24*365 痛痛痛

6. 1.2 传统运维的困境传统运维定义为被动运维，由问题驱动，被动的维持系统稳定运行。解决思路由问题驱动、被动处理转变为主动运维防控，降低生产问题，提高生产稳定运行传统运维特点 1、运维在重复处理简单的问题； 2、预警机制不完善，运维人员无法提前发现故障； 3、上线前，系统质量不高，导致生产问题较多； 4、运维介入滞后，在系统功能将上线时，才着手学习相关运维功能； 5、缺乏关联分析能力，交易往往跨多个系统，分析问题耗时长且困难。传统运维困境，是由传统运维特点导致的。

7. 1.3 运维发展的历程 05 智能运维 04 主动运维 03 流程系统 02 脚本工具 01 人工作坊小规模分工模糊大数据分析架构清晰运维体系化平台一体化简单自动化规范效率工具配置管理单体监控人工运维智能告警由运维发展历程来看，传统运维处于第三阶段。

8. 1.4 引入主动运维和智能运维 1 主动运维 2 智能运维主动运维主动防控风险，使运维过程高效、可控。通过机器学习算法自动的从海量运维数据中不断的学习，不断训练模型，最终通过模型来综合分析，形成决策。智能运维可很好的规避传统运维的问题驱动、被动处理的的局面。可对复杂的场景进行综合分析

9. 02 | 运维实践

10. 2.1 主动运维模式开发需求响应平台对接技术支持应急协同问题响应系统优化运维运维经理提出需求测试支持变更评审组织应急问题跟踪总结归纳技术平台基础类平台项目研发工具类平台运行维护运维规范管理类规范优化改进技术类规范基于DevOps的主动运维模式，很好的解决了运维团队与开发团队关系，将运维前移到开发阶段。

11. 2.2 技术类规范完备的规范是主动运维与智能运维工作顺利进行的前提需求类规范开发类规范 1、核心系统需求分析指导规范 1、信息系统集成规范 2、互联网应用安全开发规范 3、信息系统设计开发规范 4、应用接口日志输出规范 5、核心系统功能矩阵说明应用运维需求 6、核心系统开发编码规范 7、核心系统开发设计规范测试类规范 1、核心系统功能矩阵说明及测试策略 2、SIT核心项目测试指导 3、核心项目系统功能矩阵说明及预生产验证点。运维类规范 1、运维手册规范 2、应急预案规范 3、系统巡检规范 4、应用监控规范

12. 2.3 技术平台灾备恢复平台数据核对平台运维技术平台在主动运维活动中发挥着重要的支撑作用 SQL 执行风控平台批处理平台堡垒机监控平台技术平台运维平台自动化测试日志分析自动发布平台系统集成管理

13. 2.4 需求分析矩阵需求分析矩阵指导需求分析、测试等环节工作调用端服务端功能模块官微官网服务功能矩阵电话中心服务功能矩阵核心团险功能矩阵子功能点功能点渠道接口服务功能矩阵关联系统特殊场景说明关联模块需求分析矩阵内容详细说明服务接口范围预生产验证点核心个险功能矩阵需求分析矩阵销管系统功能矩阵出口结果入口条件需求分析重点幂等性校验涉及金额交互逻辑

14. 2.5 生产稳定运行控制措施上线前需求设计开发 SIT 测试 UAT 测试自动化测试安全扫描预生产测试生产发布自监监生控动控产化验脚测证本试检核上图为系统生命周期，运维工作前移，主动预防风险自动化测试上线后(运维阶段) 业务发生前 (事前) 业务发生中业务发生后 (事中) (事后) 风控生产监控日志采集数据核对

15. 2.6.1 监控平台实践建设目标集中监控缺点 1 救火队员 2 解决时效慢 70% 的故障是业务的使用者首先发现的；存在监测盲点，缺少主动预警完善监控指标适应IT 多样性统一管理重要应用系统及其所使用的网络、中间件、服务器等资源，都纳入监控范围监控系统不统一，不能快速定位出问题的系统；监控前移将预生产环境纳入监控范围

16. 2.6.2 监控平台实践统一监控平台实现集中监控自动化脚步监控完善指标，全面监控建立覆盖全面统一监控平台，减少监测盲点性能监控 Prometheus监控新增监控统一监控平台异常监控：全部业务应用系统，纳入监控全部服务器等硬件网络设备，纳入监控可用性监控：全部业务应用系统，已纳入监控全部服务器等硬件设备，已纳入监控性能监控：重要应用系统的交易，纳入监控全部主机、数据库、存储等，已纳入监控业务监控：重要业务系统，已纳入监控监控前移至预生产环境监控前移至预生产环境、生产发布过程，及时发现问题，确保代码质量，降低生产环境问题。

17. 2.6.3 监控平台实施后效果 01 2020年，某云网络问题，2次导致我司生产环境不可用，监控平台及时报警，避免了生产事故的发生 04 2020年，主动发现两次预生产性能问题，避免了生产事故发生 02 处理时效大幅度提高，报警信息包含地址及IP地址，实时获知出问题的系统和设备；实现通过日志查看交易链路，快速定位出问题的具体地方 05 出单交易时间，平均近2秒降为0.9秒左右 03 避免了中间件，硬件等设备资源满，导致的问题

18. 2.7.1 自动化测试平台实践建设目标实现自动化测试问题 1 测试任务重、时间紧 2 案例覆盖度不高渠道多，产品多，在短的时间内，很难完成代替人工，自动化执行测试案例提高测试覆盖率在合作渠道，在售的产品，重要接口涉及功能点，都要覆盖到提高测试效率提高测试效率，将预生产环境纳入监控范围不能快速定位出问题的系统

19. 2.7.2 自动化测试平台实践制定核心系统功能矩阵运维团队与开发团队，整理完成核心项目系统功能矩阵；测试团队依据核心项目功能矩阵，编写自动化测试案例；测试案例的覆盖率大幅度提高。自动化测试平台方案自研自动化测试系统基于postmain自研自动化测试系统多个阶段实施自动化测试 SIT、UAT、预生产环境等阶段，实施渠道、产品以及接口自动测试，提高了测试效率与覆盖率

20. 2.7.3 自动化测试平台实践上传自动化测试案例，点击“测试”按钮进行测试。实施后效果 01 02 03 渠道、产品功能点，回归覆盖度达到80%以上测试效率提升85%以上生产系统BUG由每个月平均20个，降至7个，已经持续 10个月。

21. 2.8.1 自动化发布平台实践建设目标前端用户无感知问题 1 升级发布完成后，不可用风险 2 发布过程中，系统可用性降低系统节点多，功能多且复杂，人工验证覆盖率小统发布过程中，保持高可用性，保障前端客户使用正常提高测试覆盖率通过自动化验证，在发布窗口内，将所有合作渠道，都测试一次出单流程缩短发布时间预生产验证时间，需控制在 20分钟以内，保障整个发布时间逐个节点发布，节点需要先停止应用，再发布，发布过程中应用系统不可用，导致系统可用性降低

22. 2.8.2 自动化发布平台实践自动化发布平台方案 1 实现自动化蓝绿发布 2 自研基于selenium+python自动验证系统事故 2020年下半年至今，60余次发布未出现一次事故用户感知 2020年下半年至今，90% 以上的发布，客户无感知自动化发布系统，升级一个节点前，向负载均衡发起摘除节点请求，过20秒向负载均衡查询节点摘除情况，然后再进行发布，发布完成后，通知负载均衡挂起该节点。依次发布其他节点每次发布完成，可在短时间内，对正在合作伙伴渠道，都要进行一次投保出单验证测试

23. 2.9.1 日志分析平台实践建设目标问题 1 日志规范化日志分散在各个业务系统 2 日志缺少关联分析的基础 3 多线程日志输出混乱日志统一存储快速定位问题各业务系统根据日志规范，改造日志输入格式日志统一收集到ELK平台根据业务流水号，串联起交易日志，便于快速定位问题

24. 2.9.2 日志分析平台实践日志分析平台方案 1 应用系统改造 u 支持发起请求时，添加交易串联标TraceID、SpanID u 根据日志规范，改造输出日志格式 TraceID、SpanID、渠道编码、交易编码、交易流水号、系统编码+ 原系统日志 2 基于ELK搭建日志分析平台 u 日志信息，都归集到ElasticSearch库； u 通过业务ID，在Kiabana页面查看交易日志信息。 2020年下半年至今，90% 以上的发布，客户无感知

25. 2.9.3 日志分析平台实践根据业务流水号，串联起交易日志，便于快速定位问题实施后效果 01 1分钟内获取到日志信息 02 问题定位耗时，由原来平均20分钟，提高到5分钟

26. 2.10.1 智能化运维实践已将应用、中间件等日志收集到ELK平台，借助平台中Machine Learning的组件进行智能运维分析探用户行为的异常检测索 u 建立不同业务流程的操作模型 u 根据每笔业务链路日志获取真实用户的操作流程 u 基于邻近算法分析筛查出异常操作用户信息 u 人工识别用户操作是否存在恶意指标数据的趋势分析 u 重点关注接口调用耗时、SQL执行耗时等性能指标趋势是否上升 u 其次关注健康检查中，节点或业务宕机次数是否趋势上升

27. 2.10.2 智能化运维实践决策分析异常交易的根因分析应用系统核心交易系统 1 2 跟踪业务链，根据指标分析精确查找影响交易的调用支付平台微信商城高中根据服务依赖模型，从高到低查找业务链对应的异常日志信息或告警事件软件服务数据库负载均衡 jsp容器基础架构服务器网络存储低

28. 2.11.1 事中风控实践建设目标问题 1 收、付费错误风险 2 对外发送信息错误风险实时发现问题在业务发生过程中，实时发现问题，规避风险。系统功能，持续升级更新，时间长了，会产生问题；运维日常会修改生产数据，给系统带来一些问题。系统功能，持续升级更新，时间长了，会产生问题；运维日常会修改生产数据，给系统带来一些问题。控制业务流转风控发现问题后，业务进入复合流程，由人工进行后续处理

29. 2.11.2 事中风控实践事中风控方案 1 2 事中风控的作业环节承保、保全、理赔、收付费 2020年下半年至今，60余次发布未出现一次重大事故。事中风控实现的处理模式 u 设置阈值：建立标准的预警机制，设置风险预警策略及时预警，防止风险向后流转。 2020年下半年至今，90% 以上的发布，客户无感知 u 数据核对：优化风控规则模型，提高甄别准确度，提高最终数据质量。 u 条件判断：判断条件时直接使 u 随机抽检机制：根据每个相关操作的频率进行相应的抽检规则设置，比如操作50件，随机抽取一件进入复核等。

30. 2.12.1 事后数据核对实践建设目标问题 1 数据准确性、完整性、一致性风险 2 对外发送信息错误风险及时发现问题系统功能，持续升级更新，时间长了，会产生问题；运维日常会修改生产数据，给系统带来一些问题；事中风控，漏掉的问题。系统功能，持续升级更新，时间长了，会产生问题；运维日常会修改生产数据，给系统带来一些问题；事中风控，漏掉的问题。保证数据准确在业务发生后，及时发现问题并进行处理，降低影响范围保证数据的准确性、完整性、一致性，避免因数据问题，造成的业务问题。

31. 2.12.2 事后数据核对实践事后数据核对作业环节事后数据核对方案承保、保全、理赔、收付费实施效果事后数据核对处理模式 2021年2月份上线至今，数据问题，由每天10条，降至为一周1条左右 u 以前端系统数据为准，核心业务系统库数据与前端数据核对。 u 核心系统库不同表的数据核对； u 以核心业务库中数据为准，对外发送信息系统数据与核心系统库数据核对。核对时间与范围每天早上5点核对前一天的业务数据

32. 2.13 运维实践效果实践平台实践效果 2020年，某云网络问题，2次导致我司生产环境不可用，监控平台及时报警，避免了生产事故的发生 2020年，主动发现两次预生产性能问题，避免了生产事故发生监控平台实践处理时效大幅度提高，报警信息包含地址及IP地址，实时获知出问题的系统和设备；避免了中间件，硬件等设备资源情况，导致的问题出单交易时间，平均近2秒降为0.9秒左右自动化测试平台实践渠道、产品功能点，回归覆盖度达到80%以上测试效率提升85%以上生产系统BUG由每个月平均20个，降至7个，已经持续10个月自动化发布平台实践 2020年下半年至今，60余次发布未出现一次事故日志分析平台实践 1分钟内获取到日志信息事中风控实践事后数据核对实践 2020年下半年至今，90%以上的发布，客户无感知问题定位耗时，由原来平均20分钟，提高到5分钟 2021年1月份上线至今，0 发生收、付费错误 2021年2月份上线至今，数据问题，由每天10条，降至为一周1条左右实施效果

33. 03 | 未来规划

34. 未来规划原始告警 alert 告警智能收敛（去燥和降纬）聚合后告警告警通知智能运维 CMDB 告警关联分析预警根因分析告警自愈设置告警自愈自动化系统

35.