罗晶 - ITIL先锋论坛.PDF

罗晶  介绍DevOps  别人家的DevOps  生产环境  如何进行DevOps ◦ 评估管理 ◦ 服务质量和目标 ◦ 减少琐事  沟通失真与业务响应时间  “DevOps思维”不就是“互联网思维”  DevOps不一定需要用微服务和容器支撑  DevOps云平台功能架构  DevOps打通工具链  上云后DevOps自动化运维现状需求 ◦ 混合云多云是多数企业的选择，企业基础设施形态为混合 云多云混合IT形态 ◦ 应用分布物理机，虚拟化平台，公有云，私有云，容器云 ◦ 多数企业上云后应用直接运行在IaaS，而不是PaaS，容器 云  介绍DevOps  别人家的DevOps  生产环境  如何进行DevOps ◦ 评估管理 ◦ 服务质量和目标 ◦ 减少琐事  云DevOps自动化运维现状，需求和目标  现状： ◦ 混合云多云是多数企业的选择，企业基础设施形态为混合 云混合IT ◦ 上云后应用分布运行在物理机，虚拟化，IaaS以及容器云 ◦ 上云后多数应用直接运行在IaaS上，而不是PaaS上 ◦ 云提供了可编程的基础设施和全栈自动化基础 ◦ 云平台本身及传统现有工具离实际的需求有一段距离  需求目标：实现混合云混合IT环境下DevOps高效 自动化运维 ◦ 充分基于云可编程特性提升自动化程序，实现全栈自动化 ◦ 现境上实现混合IT混合云多云环境下的DevOps自动化运 维 ◦ 应用上支持各种类型的应用，平台，中间件，操作系统运 行环境 ◦ 实现上能够落地，能够以小代价无风险方式支持已有主机 环境应用自动化  SRE site Reliability Engineering  系统管理员模式：系统管理员的日常工作和研发工 程师相差甚远，通常分属两个不同的部门：开发部 （Dev）和运维部（Ops）  Dev/Ops分离的团队模型存在些问题：  1 直接成本 系统管理员团队大部分依赖人工处理 系统维护事件以及变更实施。  2 间接成本 研发团队和系统运维团队分属两个部 门所带来的间接成本就没那么容易度量了，但是间 接成本往往大的多  SRE团队里基本上有两类工程师  第一类标准软件工程师，具体来说就是那些能够正 常通过软件工程招聘的人  第二类基本满足软件工程师标准，同时具有一定程 度其他技术能力的工程师  DevOps这个名词是2008年年末流行起来，目的是 想将IT相关技术与产品设计和开发过程结合起来， 着重强调自动化而不是人工操作，以及利用软件工 程手段执行运维任务等。SER是DevOps模型在 google具体实践。  SER团队要几类职责：可用性改进，延迟做强化， 性能优化，效率优化，变更优化，效率优化，变更 管理，监控，紧急事务处理以及容量规划与管理  SRE团队的运维工作限制在50%以内，SRE团队应该 将剩余时间在研发项目上。  将生产环境中发现Bug和产生的工单转给研发管理 人员去分配，或者将开发团队成员加入on-call体 系中共同承担轮值压力等。  产品事故都应该对应的事后总结，无论有没有触发 警报。  监控系统：  SRE团队监控服务质量和可用性的一个主要手段。 所以监控系统的设计策略是针对某个特定的情况或 者监控值，一旦出现情况或者监控值超过阈值就触 发E-mail警报。但是这样的报警并不是很有效果。  如何提高报警效率  1 紧急警报  意味着收到警报用户需要立即执行某种操作，目标是解 决某种已经发生的问题，或者是避免即将发生的问题  2 工单  意味着接受工作单的用户应该执行某种操作，但非立即 执行。系统羡慕不能自动解决目前情况，但是如果一个 用户几天内执行这项操作，系统 也不会受到任何影响  3 日志  平时没有人去关注日志信息，但是日志信息依然被收集 起来以备调试和事后分析时使用。正确的做法是平时没 人会去主动阅读日志，除非有特殊需要。  应急事件处理  MTTF (Mean Time To Failure，平均无故障时间)，指系统 无故障运行的平均时间，取所有从系统开始