运维体系建设介绍分解.ppt

运维工作体系建设之技术 目前的研究进度 -- 对一些开源软件进行可行性研究 数据存储层 HDFS 逻辑层 展示层 数据收集层 数据展示 监控信息管理 规范化管理 监控工具 自动化部署 数据分析 拨测工具 Cache工具 数据中间层 NoSQL（mysql、Hbase…） 监控信息管理 规范化管理 cacti、 ganglia Puppet、kick、mcollective、func zabbix 后羿 运维工作体系建设之技术 技术演进路线图 学习搭建私有云的策略、原则及相关技术，大量在现有系统中采用虚拟化技术作为实践经验积累 完善对IT基础设施和应用的监控自动化，建设配置管理自动化工具 学习Itil规范相关知识，确定Itil实施范围和步骤 完成公司内部信息门户需求整理，产品和解决方案调研 2012 2013 2014 需求收集 初步建设 整合阶段 测试选型资源管理软件，搭建小规模实验云 实现安装、部署、变更、交易模拟、健康检查等自动化运维 选定ITSM解决方案供应商，梳理事件管理、问题管理、配置管理、变更管理流程 建立企业内部信息门户的基础运行环境和软件平台，并逐步集成已有管理信息系统 扩大IaaS规模和覆盖范围，完善运营服务和管理措施，打造稳定可靠的云计算平台 整合各种自动化工具，建立统一运维管理平台，并加入知识管理、发布管理、服务级别管理等功能和相应流程，实现Itil的完整落地 完成各信息系统的集成整合，完善内部信息门户及运行维护支撑体系 使用与完善 向公司推广各种支撑平台 搭建各种支撑平台的架构 需求业务需求，建设 技术体系演进路线图 目录 运维部门的价值与挑战 运维部门的工作内容 运维工作体系建设之流程与制度（Process） 运维工作体系建设之人员（People） 运维工作体系建设之技术（Technology） 运维工作的现状与展望 运维工作现状 几组数字 – 8月份举例 网络部生产系统上线次数： 应用上线次数： 应用上线团队加班数： 处理投诉数量： 处理报警和故障事件： 深夜问题对应的数量： 接入商户数量： 处理商户问题： 设备总数： 监控应用数量： 监控返回码数量： 自动化运维率： 265次 124次 232小时/2人 1594次/2人 125次 36次 41家 530个/2人 911台 297个 1296个 不足5% 运维工作现状 不良循环： 良性循环： 业务量和用户 商户和用户投诉 机械性上线 系统优化 人员流失 业务质量 用户满意度 告警和排障 现状的两个突出矛盾 矛盾一，业务上线频度和系统稳定性之间的矛盾： 为适应市场需求，新业务频繁上线，前后端的沟通流程和规范并没有建立，缺乏业务交维，后端部门对上线质量无法掌控，维护难度大，无法可依； 矛盾二，高标准的售后服务和落后的运维手段以及紧张的人力之间的矛盾： 依靠长期的加班，用人眼巡检、查询日志，来保证业务稳定、投诉处理和判断问题，时效性差且非常不准确 运维工作展望 运维体系建设方针 高层领导的支持是首位的 从人力运维转变为技术运维 从救火队转变为主动预防 建立前后端沟通模型，技术的价值以服务的形式体现 一次规划，分步实施 维护人员数量增加及能力建设、规范的流程、自动化的工具三个方向同步推进 运维工作展望 运维体系框架 问题管理 事件管理 变更管理 配置管理 发布管理 运维流程 运维指标 连续性 可用性 容量 成本 配置管理数据库 运维支撑手段 综合监控平台 安全控制 效率提升 业务人员 产品人员 一线运维人员 二线运维专家 研发人员 业务拨测 运维模板、技术手册等 运维流程规范化，有据可依、有迹可循。增强各角色责任感。加强前后端沟通，形成PDCA闭环 自动化支撑手段可以减少手工重复性操作的成本，提升对操作的控制性 标准化的模板和手册，固化技术经验，有利于多平台分布、人员流动大的公司 制定具有业务意义的管理指标，可以评估人员和流程的性能表现 建立高素质的运维队伍，职责分工明确。一线人员对故障和问题进行预判，以恢复业务为主，保留日志等痕迹；二线专家分领域对故障进行追根溯源，不断将更深技术前移至一线 运维工作展望 运维体系建设 工具技术体系 指标体系 流程体系 变更管理：统一网络部所有上线流程，使对生产环境的变更有统一的入口； 事件管理：快速回复业务为宗旨，不断提升中断处理能力； 问题管理：深挖故障背后的根本原因，不断优化产品和系统； 配置管理：对系统各层面进行细颗粒度的分解，精细运维； 客户端类指标：登录成功率、客户端交易成功率等 短彩类指标：短信上下行成功率、彩信上下行成功率等 语音类指标：接通成功率、平均通话时长等 支付类指标：交易成功率、各类失败比率等 门户类指标：登陆成功率、点击