传统保险企业运平台化探索之路.pptxVIP

传统保险企业运维平台探索之路 目录 太保运维体系介绍 传统的痛，运维的苦 保险运维1.0时代 保险运维2.0时代 展望未来，运维平台与人工智能 1 2 3 4 5 1. 太保运维部门 • 应用运维 可用性、业务支持、服务运维、运维研发 • 基础设施 • 安全内控 太保的运维体系介绍 目录 太保运维体系介绍 传统的痛，运维的苦 保险运维1.0时代 保险运维2.0时代 展望未来，运维平台与人工智能 1 2 3 4 5 • 服务器数量增多 • 发布频率提高 传统的痛、运维的苦 • 业务系统增加 加班调休无序循环 传统的痛、运维的苦 • 数据量增多 • 性能引发故障增多 • 问题定位困难或不及时 频繁救火，日常工作搁置 • 专人专职维护少数系统 • 运维人员流失导致方案失传 传统的痛、运维的苦 • 运维方案五花八门 不会做或做的慢 传统的痛、运维的苦 • 运维人员没有开发技能 • 有想法，实现困难 没有统一工具平台 怎么破？ 目录 太保运维体系介绍 传统的痛，运维的苦 保险运维1.0时代 保险运维2.0时代 展望未来，运维平台与人工智能 1 2 3 4 5 保险运维1.0时代 • 运维平台从无到有 自动发布 程序包校验、文件下发、自动脚本 执行。 业务类监控 业务关键指标监控、页面相应速度 监控、日志关键字分析。 故障自愈 应用服务自愈，文件系统自动 清理。 巡检与排障 数据库常见故障分析、服务可 用性分析。 保险运维1.0时代 • 运维平台第一版取得的收益 • 执行效率提升，值守岗位人力释放。 • 技术方案沉淀，人员可负责的系统增多。 • 常见问题可以定位速度提升。 • 热线人员能够参与运维工作。 • 建立有研发能力的运维团队。 • 支持平台运作需要的信息多，无法直接使用CMDB中的信息，都需要人工配置， 配置信息不全或更新不及时。 • 脚本虽然做了封装，但还是分散部署，版本难以管控。 • 监控系统、流程管理系统、CMDB系统与运维平台信息没有共享，运维人员需要 多个平台上进行操作。 保险运维1.0时代 • 运维平台不足之处 目录 太保运维体系介绍 传统的痛，运维的苦 保险运维1.0时代 保险运维2.0时代 展望未来，运维平台与人工智能 1 2 3 4 5 • CMDB改造 • 配置信息自动采集。 • 完善服务接口和通知机制。 • 关联影响分析。 • 测试、生产、预生产信息汇总 保险运维2.0时代 保险运维2.0时代 保险运维2.0时代 • 运维平台架构改造 1 2 3 4 5 •自动发布升级为持续部署。 •客户端与无代理模式共存。 •配置文件集中管控。 •基础数据完全从CMDB同步。 •决策服务，处理冲突操作及与监控和流程系统信息交互。 保险运维2.0时代 客户端管理（协议包转发流量控制） 命令 插件 主机 采集 功能 插件 接口 插件 日志 插件 拨测 插件 文件 插件 Protobuff协议框架 分布式消息队列 插件框架 即插 即用 保险运维2.0时代 中心平台 命令守护模块 采集守护模块 文件守护模块 保险运维2.0时代 日志集中管理平台 使用的技术：ElasticSearch、KafKa、flume、Spark Streaming、自研 客户端。 解决的问题：日常问题不再组要逐一台登录服务器。 可将多台服务器上 的日志做组合分析，告警内容更有价值。无法定义日志格式的成品软件， 也能够进行分析处理。 业务数据的量的能够更安全有效的监控。 坚持自主可控，拥抱开源技术，量身打造属于自己的运维平台。 保险运维2.0时代 保险运维2.0时代 Ø展现层：HTML5 + AnguleJS Ø平台服务层：RestFul风格接口服 务。 ØMySql：运维平台运行数据。 ØMongoDB：CMDB数据，操作 执行历史，配置文件内容。 ØRedis：登录用户信息、运行指令 缓存。 Ø客户端管理组件：信息交互及指 令执行控制。 Ø自研Agent：指令执行、文件传 输、信息采集。 目录 太保运维体系介绍 传统的痛，运维的苦 保险运维1.0时代 保险运维2.0时代 展望未来，运维平台与人工智能 1 2 3 4 5 展望未来，让Oncall不再痛苦