从“救火”走向“防火”-商业平台业务运维实践.pptx

从“救火”走向“防火”——商业平台业务运维实践救火防火时间都去哪儿了救火防火? 越是做到高级阶段，防火的工作所占的 比重就会越高。? 从救火到防火，不是一蹴而就的事情， 应该是个逐渐演进的过程思考点发生发现响应开始处理全部恢复时间故障预防故障发现过程故障响应故障定位故障修复目标提升故障 发现率降低故障率提升故障处理速度 Agenda如何提升故障处理速度如何提升故障发现率如何降低故障率123目标与措施 快速判断 故障定位时间 准确识别故障响应时间 快速执行故障修复时间职责与分工 ? 故障运维手册 ? 数据修复工具故障预演 ? 任务修复工具?????7*24值班规范 ? 分析数据及图表 ? 流量切换工具 ? 报警内容 ? 服务降级工具故障响应规范? 回滚工具? 数据提取工具? ……应急处理预案这些都做了，还有提升的空间吗？主要受哪些影响因素 影响因素 1、新手2、故障处理步骤繁杂 应对方法优化报警内容，使报警内容变得可依赖。报警内容除了报告问题，还将故障的判断和处理方法附在其中。 利用数据任务调度管理系统， 对数据任务进行统一管理优化报警内容减少对运维人员经验的依赖，使得新人和值班人员都可以快速处理该报警对应的运维专员联系方式该报警对应的开发人员联系方式灵活配置报警内容降低维护成本，提升工作效率繁杂数据故障处理ABCDEFGIJKLMH…存在的问题：? 不能快速识别哪些任务失败了，影响了谁? 一个任务失败会导致多个任务失败，每个任务的任务都会发一个报警? 处理多个任务失败时，需要人工确认修复顺序，还要等待每个任务执 行完成后再人工执行下一个? 如果所需数据源存在短暂延迟到位，会导致任务执行失败并报警，有 时会对运维人员产生干扰繁杂数据故障处理ABCFGKM…IDLH…EJ数据任务调度管理系统：? 实时自动的可视化数据任务关系图? 能快速识别哪些执行失败及影响范围? 父节点任务失败后报警，子任务节点不再执行（也不会报警）? 恢复关键路径节点任务时，只需选择带依赖执行，后续子节点任务会 自动执行，无需人工干预，等待? 支持每个任务自定义重试次数和间隔，如果任务所需数据源存在延迟 提供现象，不会马上报警，直到达到最大重试次数为止，降低对运维 人员的干扰繁杂数据故障处理 Agenda如何提升故障处理速度如何提升故障发现率如何降低故障率123完善监控指标 常规业务类基础资源类自定义业务类端口进程Curl工作日志网络连通性机器存活远程可达丢包检测容量监控磁盘故障磁盘坏道内存条检测????????????任务始止类关键组件监控一致性类跨界类监控数据流监控超时/延时类失败率/成功率……????????自定义业务类监控………… 业务系统健康度趋势 高位警界线 监 控 项加强关注！ 加强关注！监控项低位警界线 全面短信报警过多导致麻木心理产生 降噪?监控的系统：300+?监控的实例：20000+?运维人员短信接收：人均每天6条?报警策略?报警分层?精准下发取得的效果采用的手段报警分层网段可用机器存活远程可达业务类数据依赖任务CABFGKM…DLHI…EJ报警精准下发运维值班1运维值班2运维专员1运维专员2运维专员3运维专员4运维专员N开发人员1开发人员2开发人员N Agenda如何提升故障处理速度如何提升故障发现率如何降低故障率123它山之石，可以攻玉数据说话有针对性的推动改进！ 避免重复性故障！代码发布是故障的导火索 上线次数趋势图异常处理趋势图推动开发人员有针对性解决 ? 程序Bug ? 设计缺陷 ? 代码配置 ? 部署问题变更操作是故障的导火索常见运维变更涉及哪方面的操作维护系统配置部署相关监控维护应用环境及配置维护访问控制关系更新代码配置（研发人员）……??????业务模块新增机器机房迁移，变更IP机器故障更换下线业务模块……?????涉及大量的IP、访问关系等信息，操作繁杂！ 操作繁杂，易出错某个业务机器N机器 1机器 2…系统配置监控策略访问关系其他抽象运维对象减少人工干预优化技术架构……………………抽象运维对象之前之后机器N机器 1机器 2…系统配置监控策略访问关系运维人员级别等 ……系统配置监控策略访问关系AppID机器1机器2…机器N其他…………………… 减少人工干预只需针对Appid设置一次相关策略，其他工作全部自动完成服务管理配置策略监控策略报警策略…机器列表机器规模越大效果越明显1. 当某App中有新机器 到位时，会对该机器 自动部署相关的系统 配置、监控项，同时 自动更新对应App的 代码发布地址列表2. 当某个App有系统配 置更新、监控策略更 新时，会下发到所有 相关的机器 新机器发现 自动生成监控项 基础监控部署 App1机器1 … 机器N策略变更嗅探 通用配置分发 私有监控部署 …… App2 机器1 … 机器N自动