《DevOps 精要:业务视角》- 读书笔记（七）

最新推荐文章于 2024-09-25 17:53:40 发布

壹只菜鸟

最新推荐文章于 2024-09-25 17:53:40 发布

阅读量321

点赞数

分类专栏： # devops 文章标签： devops 运维

本文链接：https://blog.csdn.net/u010230019/article/details/133701961

版权

devops 专栏收录该内容

40 篇文章 2 订阅

订阅专栏

DevOps 精要:业务视角（七）

DevOps历程

我们的DevOps旅程始于2009年，在我们为某客户（该客户提供将Web从PC转换到iPhone等移动设备的优质服务）成功实施了敏捷、Scrum和XP方法之后。

当时，客户的Scrum团队已经能做到更快地开发和发布软件。即使开发时间减少了一半，业务总监依然吐露业务速度的提升并不如意。

看起来，开发过程是瓶颈，但经过调查发现开发过程并非瓶颈，而是业务流程应该改进。

我们据此将TMS这一概念从业务战略和规划一直到客户服务的整个业务流程实施起来。而使用DevOps的概念将有助于建立一个流水线式（stream-lined）的业务运营过程，并缩短交付前置时间（delivdery lead-time）。

这个项目于2012年成功完成。整个流程从端到端进行了重新调整，并使用可视化控制、单件流（One-piece flow）、每周进程同步、每天反馈循环以及KAIZEN建立起整个业务的协作。经理、管理员、销售、设计师、程序员、运维和客服形成了一个团队，大家在可视化看板上共享所有业务信息。

项目实施后，业绩得到了明显的提升：交付前置时间缩短、销售量提升、利润率和员工积极性也都得到了提升。这些是DevOps的真正价值。

DevOps框架应该直接支持到业务结果，不仅仅是为了IT服务中开发与运维的协同，而是要能帮助企业使用IT服务来支持和提升他们的业务。

DevOps的价值应以业务结果来衡量，而不是根据IT项目范围和IT成果来评判。

什么是企业体系的DevOps？

关于DevOps的书有很多，但不幸的是，大多数都是描述在网站和产品开发中是如何应用DevOps的。很少有相关资料讲述DevOps如何应用于企业体系。

企业往往同时拥有交互型系统（SoE）和记录型系统（SoR）。SoE系统关注的是速度，SoR系统关注的是业务连续性。问题是SoR系统也受到面向速度的SoE系统频繁更改的影响，SoR系统如何适应频繁更改影响的同时还要保持业务的连续性？Gartner公司把这称为“双峰挑战”（Bimodal challenge）。

大多数企业的SoR既有传统的系统与应用需要维系和使用，使用DevOps建立及时制（just-in-time, JIT）概念的流水线式过程可以助力这类系统。

DevOps不能简单认为是一种工具、方法、技能或组织结构，DevOps的框架是结合所有这些元素来建立一个流水线的过程，使业务更快地运营，并能更快地应对变化。DevOps还可以通过戴明博士的Plan-Do-Check-Act（PDCA，戴明环）来提升成熟度。企业级的DevOps不仅仅是增强的敏捷开发和持续交付，同时也通过IT服务管理和应用程序管理来实现和促进业务增长并保障业务连续性。

DevOps的目标是什么？

DevOps的目标是建立流水线式的及时制（JIT）的业务流程。DevOps旨在通过调整及时制（JIT）业务流程来最大化业务成果，例如增加销售和利润、提高业务速度或最小化运营成本。

DevOps意味着在业务中建立一条IT服务供应链，与其他产品的供应链嵌入业务的方式相同。这种从提供软件交付到供给IT服务的模式转变是巨大的。

从架构的角度来看，DevOps需要建立一个自动化的快速部署系统。有很多方法和工具可以利用。DevOps没有统一的实施模板，每个组织都应该考虑并建立自己的DevOps流程来提升业务。因此，真正理解DevOps的概念，对员工遵循正确的流程有效执行来说至关重要。

DevOps的知识体系

当实施DevOps时，我们将从很多知识源、方法论、实践案例和工具中去选择参考。DevOps主要由以下的三大支柱和一个基础组成。

规范敏捷

一支训练有素的敏捷开发团队是成功实施DevOps的关键。规范敏捷（Disciplined Agile）意味着下面三个方面。

速度稳定（Stabilized Velocity）
适应变化（Adaptability for change）
总是能发布优质的无错误代码（Always release high quality bug free code）IT服务需要以更频繁、更快速的发布周期来响应业务变化，这取决于开发速度。工作质量是最重要的，需要将工作分割为小任务来加以支持。

Ji-Koutei-Kanketsu（JKK）概念，认为100%的完成每个条目，是有助于保持高质量工作的。而“完成定义”（Definition of Done）或“结束”（Completion），对每个人都必须清楚定义。

产品负责人需要改变他/她的使命，不单单是管理待办事项列表（Product Backlog），也需要规划IT服务的运维成本。在丰田，这项工作是由首席工程师来完成的。

持续交付

持续交付（Continuous Delivery）是应用程序的构建、部署、测试和发布流程的自动化实施。

一个关键的关注点是测试，如验收测试和性能测试等。TPI NEXT（测试流程优化）可以用于提高这个过程的成熟度。

每个组织部署流水线（Deployment Pipeline）的实现都会有差异，因为软件发布的价值流不同。成功的关键因素是该部署流水线应该为单一流程构成，而非多个。

IT服务管理

当技术成为大多数业务流程的核心环节时，IT服务的连续性和高可用性是业务存亡的关键因素。这可以通过引入降低风险措施和恢复方案来实现。就像IT服务管理所有要素都提及的，成功实现服务的连续性需要得到高层的承诺，以及组织中所有成员的支持。要保持恢复方案的有效性，持续维护是至关重要的。服务连续性是服务功效（warranty, fitness for use）的必要组成部分。如果服务连续性无法按照业务的要求维护和/或恢复，那么业务将无法实现所承诺的价值。没有了连续性，服务的功用（utility, fitness for purpose）也无法使用。

传统的IT服务管理（ITSM）最佳实践，比如ITIL看起来很繁琐，不匹配DevOps中所倡导的快速流程。有必要考虑一下如何降低管理工作量。

基于DevOps去重新调整ITSM是有必要的，创建轻量级的只包含所需最少必要信息（Minimum Required Information，MRI）且严格聚焦于业务持续性的轻量级ITSM。每个组织的MRI设置取决于他们的业务。

以TPS理念为基础

建立一个流水线式的IT服务供应链并不容易，因为其包含的内容很多，并且要改变现有熟悉的开发周期和方法论，你很有必要观念上做改变。

TPS（精益管理Lean）的概念包括JIT和自动化，对建立这样的供应链有很大的帮助。

JIT意味着以单件流（one-piece flow）的方式建立一个流水线式的供应链。而自动化意味着尽可能实现自动化，并且当出现缺陷时能停止整个过程。这个过程需要设计并且员工也需要充分理解这两个概念。另一个关键问题是开发和运维的管理周期。需要在工作方式上采用敏捷的方法，包括开发和运维之间每周或每天的信息同步。

下图展示了DevOps的知识体系：
在这里插入图片描述

DevOps团队角色

为了保证IT服务的业务连续性，推荐在组织中建立DevOps团队。最好是组建一个小型优质的DevOps团队，根据亚马逊的“两个披萨规则”，团队成员的规模为两个披萨饼就可以喂饱。团队角色描述如下。

流程主管（Process Master）

领导并引导团队，这个角色类似于在Scrum中的Scrum Master。

对整个过程实施可视化管控，并特别注重建立单件流的流水线式的流程。

可视化管控意味着“在不需要解释的情况下，通过看板是否每个人都能很容易理解当前的状况？”它并不显示状态。但它可以用来表达是否有问题出现。

经验需求：Scrum Master或敏捷项目领导（Agile Project Leader）。

服务主管（Service Master）

对及时（JIT）提供IT服务负有全责。

这个角色就类似于Scrum中的产品负责人（Product Owner）或对待办事项（Product Backlog）做管理和排序，另外还负责IT服务的成本规划。

经验需求：Scrum产品负责人（Scrum Product Owner）、服务负责人（Service Owner）。

DevOps工程师（DevOps Engineer）

以优化和维护自动化流程为主要使命。

工程师将检查整个自动化过程和工具。DevOps流程需要很多工具。

经验需求：开发（Development）和工具（Tools）。

把关人/发布协调员（Gatekeeper/Release coordinator）

负责监控IT服务的运维状态和下一次发布的进展。

做关于部署是做或不做的决定，需要参照的标准包括安全性、合规性、监管要求或运维团队的成熟度以及他们的流程观念。

经验需求：IT服务管理（IT service management）、运维（Operations）。

可靠性工程师（Reliability Engineer）（可选）

监控部署过程中服务的测试质量，处理服务运行中所产生的问题。

监控流程状态以确保开发团队严格遵守CI（持续集成）和CD（持续交付）的规则。监视和管理复杂的构建管线的工作流。以提升测试流程为使命。

经验需求：测试（Testing）、工具（Tools）或质量保证（Quality assurance）。

开发团队（Development team）

DevOps的关键成功因素之一是建立一个规范的敏捷团队。

规范的敏捷团队致力于以可持续的速度来满足发布计划和发布质量。

经验需求：开发（Development）或敏捷（Agile）

运维团队（Operation team）

采用轻量级的ITSM并在总体战略范围内支持对服务的设计、实施、运维与改进。

采用TPS中的“提前持续改善（KAIZEN in Advance）”的实践。

经验需求：运维（Operations）或持续改善（KAIZEN）。

组织

有必要在服务管理办公室（Service Management Office）中组建DevOps团队来支持服务主管。

有两种类型的组织架构展示如下：

适合小型组织的扁平化组织

下图是小型组织的基本架构。
在这里插入图片描述

适合大型复杂组织的矩阵组织架构

在这里插入图片描述建立专家池并安排他们作为一个团队给到服务主管。这个矩阵组织的想法来自丰田的首席工程师。

DevOps的流程

要建立一个流水线式的流程，采用JKK来指导DevOps团队是最有效的办法。

JKK是一种高质量的工作方式，它意味着对目标理解清晰，理解正确的工作方式，使工作百分百地正确完成，并在没有检查的情况下维护质量要求。

业务战略和规划（Business Strategy and Planning）

IT服务与业务战略和规划有密切的关系。

服务主管应该参加业务规划会议并提出如何通过IT服务来获得业务优势的建议。

市场营销（Marketing and sales）

服务主管应该与市场部门讨论如何从IT服务中获得优势。

服务主管识别IT服务的客户，收集具有业务价值的需求，并约定时间范围。

管理（Administration）

流程主管就如何可视化整个过程与团队成员达成一致。一种方法是使用Obeya（作战室，丰田的一种工程合作方式），它可以设定为可视化整个流程。Obeya作战室具有两个目的：信息管理和现场决策（on-the-spot decision）。这里面有很多可视化管理工具。团队成员可以很快看到他们在过程中的方方面面。

当跨职能团队在一起工作时，Obeya系统能够快速、准确做出决策，加强沟通、保持一致、迅速收集信息、并形成重要的团队集体意识。