运维体系建设介绍ppt课件.ppt

目录 运维部门的价值与挑战运维部门的工作内容运维工作体系建设之流程与制度 Process 运维工作体系建设之人员 People 运维工作体系建设之技术 Technology 运维工作的现状与展望 运维部门的定位 运维部门在公司的位置图例 产供销售后 运维部门的价值 以流程为导向 以客户为中心 以技术为支点 提供低成本 高质量的IT服务 以满足业务快速发展的需要 全面管控企业范围内基础设施 信息资产等资源 实现前端业务的快速上线 售后用户的投诉等问题实现第一时间 一次性的完善解决 提升内外部客户的满意度 业务快速响应要求 业务连续性要求 业务安全性要求 成本预测与量化要求 对在线业务从系统层到业务层实现全面的监控 从被动处理转变为主动预防 制定SLA考核指标 提升故障的快速定位和解决 保障业务达到超出竞争对手的稳定运行率 运维服务实现标准流程化管理 统一计费单元 对服务进行计费管理 服务价值与业务发展相符 采用先进的技术 低成本对应业务转型 技术创造价值 横向从人员 流程 制度 技术手段等方面 纵向从网络层 主机层 存储层 数据层 业务层等方面 形成网状结构全面梳理安全问题 保障业务的机密 完整和可用性 运维部门的价值 运维部门在公司的地位和作用 大背景 产品的前期设计和开发在整个生命周期中只占20 左右 80 时间集中在运维和运营工作 随着各行各业的大规模信息化建设时代接近尾声 IT运维时代已经来临 不同的公司 公司不同的发展阶段 运维部门地位和作用不同 网络和产品缺乏可用性等指标评价体系 系统优化缺乏依据 运维人员在运维流程中缺乏服务评价指标体系 从而不能作为绩效考核的依据 生产环境中单点设备较多 业务中断风险高 老旧设备对新技术支持较差 资源分配不灵活 监控 拨测等自动化运维工具缺乏 工作效率差 人力成本高 CMDB缺乏 生产环境中 僵尸节点 较多 影响业务更新 甚至带来平台重构的风险 运维部门处于生产和销售的中间环节 对前后端各条业务线提供多种服务 规范的流程缺失 导致解决问题靠英雄和人情 责任定位不明确 各种特批流程泛滥 运维人员的工作处于无序化 紧急且重要的业务需求得不到优先支持 影响内外部客户的满意度 运维部门规模较小 人员紧张 分工粗泛 要求一人多能 一人管理多条业务线 导致人员专业性不强 人员数量和技能与实际要求差距较大 业务需求得不到快速良好的支持 运维人员的职业规划和能力培养尚不完善 不规律的作息和巨大工作压力 导致了运维人员大量流失 工作分工不明确 经验固化随之薄弱 运维部门的挑战 运维部门的困境和挑战 目录 运维部门的价值与挑战运维部门的工作内容运维工作体系建设之流程与制度 Process 运维工作体系建设之人员 People 运维工作体系建设之技术 Technology 运维工作的现状与展望 运维部门的工作内容 概念介绍 系统分层 业务层 数据层 存储层 主机层 网络层 DB层 DB层的运维目前不在网络与系统运行部 运维部门的工作内容 工作内容的分类 配置梳理 配置间关系梳理 日常巡检 全面监控 售前方案 系统调优 投诉处理 备份灾备 问题排查 故障处理 上线割接 商户接入 业务推广活动支撑 业务数据提取 告警处理 容量分析与报告 安全扫描 安全加固 安全工具更新 安全策略制定 配置管理 变更管理 事件管理 问题管理 容量管理 持续性管理 可用性管理 业务支撑 安全管理 X网络 主机 存储 数据 业务5层 X公司的业务线的数量 运维的工作量估算 123456789101112131415161718192021 应急演练 运维部门的工作内容 运维工作部署演进 运维工作多而杂 通过把复杂的运维工作从项目 系统分层 业务线进行三个维度的切分 使工作内容职责清晰 更易于落地执行 对细分的工作内容进行梳理 固化工作经验 形成专业的操作手册 对于可以自动化实现的部分 做成运维工具 达到降本增效的目的 降低人为操作的误差 将细分的专业化的工作模块化 由一线运维团队 二线支撑团队 和临时的虚拟项目组承担 或者考虑成本的要求 在安全性要求较低的工作上购买外包服务 目录 运维部门的价值与挑战运维部门的工作内容运维工作体系建设之流程与制度 Process 运维工作体系建设之人员 People 运维工作体系建设之技术 Technology 运维工作的现状与展望 运维工作体系建设之流程制度 流程制度分类 部门内部的流程制度 部门与外部的流程制度 部门内各团队间的工作流程一线 二线团队之间的工作流程 虚拟团队的工作流程 服务产品外包的工作流程 部门内的操作规范 安全制度银联的安全规范 制度移动的安全规范 制度公司的安全基线规范 运维相关的编码的安全规范 售前技术支撑流程上线流程投诉处理流程事件管理流程问题管理流程敏感数据提取流程业务推广活动支撑流程商户接入流程 服务目录 运维工作体系建设之流程制度 流程制度举例 北京移动安全管理实施细则V5 为了防止客户信息泄露等事故再次发生 重铸公司的品牌和信誉 北京移动公司网络部牵头 历时1年 各个部门均有参与 参与编写人员近百名 完成了公司内部的安全管理实施细则 共35个分类 全面梳理了公司内部各重要的流程中人因因素的部分 制定了操作和审计制度 系统的安全制度体系方面我们公司比较缺失 运维工作体系建设之流程制度 部门间服务接口 服务目录概念 服务目录是管理内外部客户期望 使服务产品化 提升服务交付质量的重要工具 服务项目 服务内容 运维工作体系建设之流程制度 服务目录举例 上线服务 目录 运维部门的价值与挑战运维部门的工作内容运维工作体系建设之流程与制度 Process 运维工作体系建设之人员 People 运维工作体系建设之技术 Technology 运维工作的现状与展望 运维工作体系建设之人员 研发团队和运维团队的关系举例 运维工作体系建设之人员 运维团队内的架构举例 产品1 一线运维团队 产品2 产品n 二线应用运维团队 一线运维团队 一线运维团队 二线网络运维团队 二线主机运维团队 二线数据库运维团队 安全团队 北京移动 一线运维组 购买各产品原厂的维保 二线应用运维组 系统负责人A B角 二线的网络 主机 数据库运维组购买神码的专业团队支撑所有产品 安全组 移动员工专业团队运营商 银行 证劵公司多采用 腾讯公司 一线运维组 按各产品划分二线的应用运维组 支撑产品组合 二线的网络 主机 数据库组 按照机房物理地点划分安全组 管理所有产品互联网公司多采用 研发团队 运维工作体系建设之人员 根据公司的运维人员来源 人员架构如下 商户组 运行组 主机组 网络组 维护组 技术支撑组 一线团队 二线团队 技术支撑团队 运维工作体系建设之人员 运维人员的发展路径 目录 运维部门的价值与挑战运维部门的工作内容运维工作体系建设之流程与制度 Process 运维工作体系建设之人员 People 运维工作体系建设之技术 Technology 运维工作的现状与展望 运维工作体系建设之技术 业务支撑能力建设 IaaS 基础设施即服务 主要是将网络 服务器等基础设施和操作系统 数据库等基础软件看作资源 对这些资源进行虚拟化 以CPU 内存 存储容量 操作系统等为单位向用户提供应用软件运行环境的服务模式 IAAS平台可提供的网络资源 计算资源 存储能力等构建成资源池 随时随需进行分配和调度 底层硬件设施的采购不会受制于应用的制约 对于业务增减变化频繁的的情况 不仅可灵活弹性的分配资源 还可及时对下线业务占用的资源进行回收再利用 实现投资保护并减少系统建设成本 通过资源的分配量 可计量每个业务所占用的系统成本 并使服务可度量 为公司预算管理提供依据 对于公司移动金融云的战略 IaaS也是基础 运维工作体系建设之技术 运营支撑能力建设 北京移动企业信息门户 内部信息门户 企业内部信息门户是一个基于Web的系统 它是企业内部员工与团队之间互动 信息和知识共享的门户 信息门户可为员工提供一个统一入口 只需单点登录 即可处理各类工作和流程 快捷获取所需信息可为整个企业的信息发布和集成提供统一的渠道 实现统一的用户认证 授权和安全管理 企业内部的员工之间是有分工的 不同员工由于角色不同 层级不同 因而不同的员工具有不同的工作 内部信息门户为每位员工提供独特的工作的平台 由于公司办公地点分散 不同的部门 项目组 也应该有自己的工作场景的门户 包括团队的工作方法 规范和共享的信息等 使大家感觉协同办公的 运维工作体系建设之技术 自动化运维能力建设 自动化运维建设 本着 网络质量是第一生命力 的宗旨 移动大力建设技术支撑平台 实现对业务的全面 实时的监控 不断提升业务的连续性和可用性 主要部分包括 运维流程平台 变更 配置 问题 事件等流程工具 业务管理平台 端到端拨测 业务指标呈现及分析工具 监控管理平台 系统各层的监控工具 诊断工具 性能管理工具等 资源管理平台 CMDB 知识库 资源展现等安全管理平台 漏洞扫描 日志审计 权限控制等安全类工具 运维工作体系建设之技术 现有的自动化运维工具 系统层的监控工具Mocha 网络设备的连通性 主机的CPU MEM DISKNagios 进程 端口大部分监控工作依靠人工日志停刷大面积的返回码报错 随着业务增长迅速 被监控的应用数量成倍递增 日志的复杂度加大 人工轮询的速度降低 受人因因素影响越加严重 且缺少对返回码的个性化监控规则定制能力 只能发现大面积错误 应着力发展自动化运维 取代人工监控 运维工作体系建设之技术 Nagios 通过mocha已监控到底层设备的关键指标 但是对于应用层仍无法进行自动化监控 无法第一时间发现应用的异常 而应用层又是出现问题较多的区域 因此对应用的监控需求非常迫切 通过对市场上开源的监控软件进行调研 nagios的成功案例较多 基于nagios之上 运行人员深入研究 定制开发 性能调试 配置优化 试运行后 正式上线已经一年多 运行稳定 达到了预期的目标 通过新建一套自动化监控工具 可以监控到应用层面的状态 细化到指标级别 期望可以监控到应用进程和端口的存活状态两个关键指标 由于开源软件 且利用维护人员下班后时间自行研发 因此为零投资 目前已经监控了247个进程 457个端口 大概产生了3万个左右的报警 为及时发现应用异常提供了有力的支撑 运维工作体系建设之技术 自动化运维工具体系框架 运维工作体系建设之技术 逻辑层 监控工具基础监控服务器监控 如 cpu memery I O 并发量等 操作系统监控 堆栈监控 线程栈监控等网络监控 如 连通性 流量等应用监控对交易状态 返回码 Exception 监控用户端URL监控进程和端口的存活状态监控负载均衡监控等业务监控对业务量 成功率进行监控等安全监控外部攻击监控等 运维工作体系建设之技术 逻辑层 自动化部署工具自动化配置快速且一致对集群内所有设备的系统参数进行配置 如 管理配置文件 用户 软件包 系统服务等对设备的系统参数的修改进行记录和跟踪 矫正个别设备的异常配置应用的配置文件自动化上线统一进行上线 发布及时 准确的进行应用回滚和监控工具无缝集成根据上线内容能够进行自动化监控各业务线之间的影响关系分析 运维工作体系建设之技术 逻辑层 数据分析工具应用日志分析实时日志分析非实时日志分析用户行为分析产品成功率分析交易量分析安全分析网络异常流量分析外部攻击行为分析内部人员行为审计系统信息分析容量分析 性能分析等 运维工作体系建设之技术 目前的研究进度 对一些开源软件进行可行性研究 数据存储层 HDFS 逻辑层 展示层 数据收集层 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 运维工作现状 不良循环 良性循环 业务量和用户 商户和用户投诉 机械性上线 系统优化 人员流失 业务质量 用户满意度 告警和排障 现状的两个突出矛盾矛盾一 业务上线频度和系统稳定性之间的矛盾 为适应市场需求 新业务频繁上线 前后端的沟通流程和规范并没有建立 缺乏业务交维 后端部门对上线质量无法掌控 维护难度大 无法可依 矛盾二 高标准的售后服务和落后的运维手段以及紧张的人力之间的矛盾 依靠长期的加班 用人眼巡检 查询日志 来保证业务稳定 投诉处理和判断问题 时效性差且非常不准确 运维工作展望 运维体系建设方针高层领导的支持是首位的从人力运维转变为技术运维从救火队转变为主动预防建立前后端沟通模型 技术的价值以服务的形式体现一次规划 分步实施维护人员数量增加及能力建