企业DevOps的成功之路

数字经济时代，所有业务都将长在技术之上，企业如何做到业技融合实现绩效增长？个人如何理解业务与技术的关系以适应数字时代的快速发展？DevOps转型需要哪些实施步骤，需要怎样的DevOps团队？本文告诉你答案。

• DevOps白皮书：企业DevOps的成功之路
• 1.整体介绍
  • 从业务流程角度编写
  • DevOps旨在建立软件／IT服务供应链（Software/IT service supply chain)
  • DovOps概念有助于
    • 建立流水线式（Stream-lined）业务运营过程
    • 缩短交付前置时间（dolivory load-time）
  • DovOps框架应该直接支持到业务结果
    • 而不仅仅是为了开发与运维的协同
    • 要能帮助企业使用IT服务来支持和提升业务。
• 2.什么是企业体系的DevOps
  • 双峰挑战（Bimodal challenge）
    • SoR如何适应频繁更改的影响，同时还要保持业务连续性
    • 交互型系统（System of Exchange,SoE）-关注【速度】
    • 记录型系统（System of Record，SoR)-关注【业务连续性】
  • 大多数企业有传统应用要维系和使用，使用DovOps建立JIT（即时制）的流水线式过程可以帮助到这类系统
  • DevOps框架
    • 工具
    • 方法
    • 技能
    • 组织结构
    • 组合所有元素建立流水线
      • 使业务更快运营
      • 更快应对变化
  • 企业级DevOps
    • 敏捷开发
    • 持续交付
    • IT服务管理
    • 应用程度管理
    • 实现和促进业务增长、保障业务连续性
• 3.DevOps的目标
  • 【即时制流水线】建立流水线式的、即时制的业务流程-最大化业务成果
  • 【IT服务供应链】实现从软件交付到供给IT服务的巨大模式转变
  • 【自动化快速部署系统】利用丰富的方法和工具
  • 没有统一的实践模板
• 4.DevOps的知识体系
  • 4.1 Disciplined Agile规范敏捷
    • 含义
      • Stablized Velocity
        • 稳定速率
      • Adaptability for Change
        • 适应变化
      • Always release high quality bug free code
        • 总能发布高质量无错误的代码
    • 更频繁、快速的发布周期，才能更快地响应业务
    • 质量至关重要
      • 工作分解为小任务
      • JKK（Ji-Koutei-Kanketsu)-100%完成某个条目。
        • 这是一种完美状态：
          • 在你的流程中不要做低质量的工作
          • 不接受流程早期就出现错误的输出
          • 不把糟糕的情形输出到下一个流程
      • 为每个角色清晰定义DoD
  • 4.2 持续交付
    • 应用程序构建、部署、测试和发布流程的自动化实现。
    • Key focus: 测试，如
      • 验收测试
      • 性能测试
    • 部署流水线实施
      • 每个企业不同，因为业务不同，软件发布的价值流不同。
      • 成功的关键是该部署流水线由单一流程构成，而非多个。
  • 4.3 IT服务管理
    • 业务存亡的关键因素
      • 高可用性
      • 服务连续性
      • 需要得到高层的承诺、组织所有成员的支持
    • 需要持续维护恢复方案以保持其有效性
    • 服务功效(warranty,fitness for use)
      • 服务连续性是其组成部分
    • 服务功用 (utility, fitness for purpose)
      • 服务连续性若无法按照业务要求维持或恢复
        • 业务无法获得被承诺的价值
        • 服务功用无法评估
  • 4.4 以TPS(Lean精益)理念为基础
    • JIT(Just-In-Time)
      • 以单件流方式
      • 建立流水线式供应链
    • 自动化
      • 尽可能实现自动化
      • 当出现缺陷时停止整个过程
    • 以上两个概念需要
      • 设计
      • 员工充分理解
    • 开发和运维周期管理
      • 采用敏捷方法
      • 开发和运维间每周或每天的信息同步
• 5.DevOps团队角色
  • 为保证业务连续性,建立小型优质的DevOps团队,原则: Two-pizza Team
  • 团队角色
    • 流程主管Process Master
      • 领导、引导团队，类似于Scrum中的Scrum Master
      • 对整个过程实施可视化管控
        • 在不需要解释的情况下
        • 通过看板每个人可以很容易地理解当前状况
        • 不显示状态，但是可以表达是否有问题出现
      • 特别注重单件流流水线式流程
      • 经验需求：Scrum Master，敏捷项目领导Agile Project Leader)
    • 服务主管Service Master
      • 对即时地（JIT）提供IT服务服务有全责，类似于Scrum 中的Project Owner
      • 管理和排序Product Backlog
      • 负责IT服务成本规划
      • 经验需求
        • 服务负责人（Service Owner)
        • Scrum产品负责人（Scrum Product Owner)
    • DevOps Engineer
      • 优化和维护自动化流程
      • 检查整个自动化过程和工具
      • 经验需求：开发和工具
    • 把关人／发布协调员 Gatekeeper／Releasecoordinator
      • 监控I服务运维状态
      • 监控下一次发布的进展
      • 参照相关标准做部署决策
        • 安全性
        • 合规性
        • 监管要求
        • 运维团队成熟度以及他们的流程观念
    • 可靠性工程师Reliability Engineer
      • 监控部署过程中的测试质量，以提升测试流程为使命
      • 处理服务运行中所产生的问题
      • 监控流程状态以确保开发团队准守CI／CD规则
      • 监控和管理复杂的构建流水线工作
      • 流经验需求：测试、工具、质量保证
    • 开发团队Development team
      • 规范的敏捷团队
      • 以可持续的速度来满足发布计划和发布质量
      • 经验需求：开发、敏捷
    • 运维团队Operation team
      • 采用轻量级TSM
      • 在总体战略范围内支持服务的设计、实施、运维
      • 采用TPS的“KAIZEN in Advance”(提前持续改善)
      • 经验需求：运维、KAIZEN(持续改善)
• 6.组织
  • 在服务管理办公室中组建DevOps团队来支持服务主管
  • 适合小型组织的扁平化组织架构（Flat Organization)
    • 服务负责人 Service Owner
      • 开发团队
      • 运维团队
    • 服务管理办公室
      • 流程主管Process Master
      • DevOps工程师
      • 把关人Gatekeeper
      • 可靠性工程师Reliability Engineer
  • 适合大型复杂组织的矩阵型组织架构（Matrix Organization）
• 7.DevOps的流程
  • 要建立流水线式的流程，采用JKK指导DevOps 团队最有效
    • 清晰理解目标、理解正确的工作方式
    • 使工作100%正确完成
    • 在没有检查的情况下维持质量要求
  • 7.1业务战略和规划（Business Strategy and Planning)
    • 【服务主管】
      • 参加业务规划会
      • 提出如何通过IT服务获得业务优势的建议
  • 7.2市场营销（Marketing and sales）
    • 【服务主管】
      • 与市场部门讨论 如何从IT服务中获得优势
        • 识别IT服务的客户
        • 收集有业务价值的需求并约定时间范围
  • 7.3 管理（Administration）
    • 【流程主管】：就如何可视化整个过程与团队达成一致
    • 使用Obeya可视化整个流程， 团队成员可利用可视化管理工具看到过程中的方方面面
      • 信息管理
      • 现场决策（one-the-spot decision）
    • 跨职能团队使用Obeya可以：
      • 快速准确决策、加强沟通、保持一致
      • 迅速收集信息、形成重要的团队集体意识
  • 7.4 项目规划（Project Planning)
    • 【服务主管】
      • 组织服务管理办公室（SMO）、定义团队基本规则
      • 整合DevOps团队成员
      • 创建愿景、目标和项目的价值
    • 在这个阶段
      • 定义运行中的基础设施
      • 设计整体流程的价值流图
  • 7.5 需求和设计（Requirement and Design)
    • 【服务主管】
      • 定义Product Backlog并安排待办事项优先级
    • 【DevOps团队】
      • 使用Product Backlog来定义故事（Story)
        • 用户故事：角色、职能、业务价值/理由，以及运维条件
        • 测试故事：验收测试用例和服务验收标准
        • 运维故事：设置IT服务的优先级和业务连续性的运维条件
      • 创建服务级别协议（SLA)和运维级别协议
    • 【DevOps工程师】 和【运维团队】
      • 定义转换（Transition)测试和开发所需的基础设施
    • 【开发团队】
      • 创建和发布迭代计划
    • 【把关人】
      • 研究T和服的合规性以及监管要求
    • 【可靠性工程师】
      • 定义测试方法和测试用例
  • 7.6 开发（Development)
    • Scrum是这个阶段最适用的方法论
    • 【开发团队】
      • 提交并遵守发布计划
      • 使用规范的敏捷方法
      • 选代（Sprint）周期取决于业务需要
    • 使用质量内建措施
      • XP
      • TDD
      • 重构
      • 十分钟构建
  • 7.7部署（Deployment）
    • 【DevOps工程师】建立单件流的、单一的自动化部署流水线
    • 【可靠性工程师】与【DevOps工程师】共同改进测试流程
    • 【把关人】监控过程进度，决定是否上线
    • 【运维团队】研究如何保持业务连续性
  • 7.8运维（Operation）
    • 【运维团队】
      • 采用轻量级TSM流程来监控服务运行状态
      • 发生灾难事件时确保服务正常运行，让【可靠性工程师】参与进来
      • 关注两个参数：
        • 恢复点目标RPO（Recovery Point Objective）
        • 恢复时间目标 RTO （Recovery Time Objective)
  • 7.9维保（Maintenance）
    • 【服务主管】和【可靠性工程师】决定是否允许进行维保
    • 经允许， 作为变更请求(Request for Change， RFC) 添加到待办任务(Product Backlog)中
  • 7.10 客户服务（Customer Service） （闭环到需求阶段）
    • 【服务主管】和【可靠性工程师】负责收集客户反馈，例如用户体验和质量事件等
  • 7.11生命周期终止（End of Life，EOL）
    • 【服务主管】决定IT服务生命周期的终止条件
      • 服务的生命周期在何时终止
      • 服务的生命周期如何终止
• 8.DevOps的实施
  • 8.1丰田方式（TOYOTA Way）
    • 先进但复杂
      • 聚焦战略IT服务，并给与业务的战略优势
      • 需要由【业务负责人】或【服务主管】来领导
      • 大型企业选择矩阵式组织架构
      • 在IT战略和业务战略之间保持密切关系
      • 【适合】：IT服务提供商
  • 8.2协同方式（Collaboration）
    • 标准
      • 聚焦如何快速和频繁提供T服务并保障可靠运行
      • 由【服务主管】来主导
      • 【尤其适合】
        • 将交互型系统(SoE)和记录型系统(SoR)连接在一起的企业
  • 8.3持续交付（Continuous Delivery）
    • 基本，关注点在快速上线
      • 侧重于快速和频繁的软件发布
      • 可由【产品负责人】来主导
      • 【最适合】
        • 数码产品提供商的软件部门
        • （例如新型互联网企业）