本帖最后由 adminlily 于 2018-9-1 16:48 编辑
DevOps的历程始于2009年,在成功采用了Agile,Scrum和XP等方法论后,一些客户,开始极富想象力在使用网站服务时,从传统PC应用转移为移动设备应用了,比如说iPhone。当然Scrum团队是能够更快的开发和发布软件。不过业务主管却担心即使开发时间减少了一半,却依然不能提高业务的速度。表面上看起来开发的过程是瓶颈,但是在调查中发现开发的过程并不是瓶颈,反而业务流程却应该要被改善。
1、DevOps 如何应用于企业体系?
关于DevOps的书有很多,但不幸的是,大多数都是描述网站和产品开发中如何使用DevOps的。很少有相关资料是考虑DevOps如何用于企业体系的。企业往往兼有交互型系统(System of Engagement,SoE)和记录型系统(System of Record,SoR)。SoE关注的是速度,SoR关注的是业务连续性。问题是当SoE频繁变更的时候,如何保障SoR的业务连续性呢?
Gartner公司把这称为双峰挑战(Bimodal challenge)。大多数企业的SoR正努力使用着遗留的系统与应用,可以通过使用DevOps建立一个准时制(just-in-time, JIT)概念的流水线过程。DevOps不能简单认为是工具、方法、技能或组织结构,DevOps的框架结合所有这一切元素,去建立一个流水线的过程,使业务更快的运营并且更快地应对变化。DevOps还可以通过戴明博士的计划(戴明环)来提升其成熟度。企业级的DevOps不仅仅是增强敏捷开发和持续交付,同时也通过IT服务管理和应用程序管理最终实现促进业务增长并保障业务连续性。
2、DevOps 的目标是什么?
DevOps的目标是建立流水线式的准时制(JIT)的业务流程。DevOps旨在通过合适的准时制业务流程来最大化业务成果,例如增加销售和利润率,提高业务速度,或尽量减少运营成本。DevOps意味着在业务中建立了一条IT服务供应链,而业务以同样的方式作为其他产品的供应链以嵌入到业务中。这种从提供软件交付转移为提供IT服务的模式转变是巨大的。
从架构的角度来看,DevOps需要建立一个自动快速部署系统。有很多方法和工具可以利用。DevOps没有统一的实施模板,每个组织都有自己的考虑和并建立自己的DevOps流程来提高业务。因此,真正理解DevOps的概念,对员工遵循正确的流程有效执行来说是至关重要的。
3、DevOps 的知识体系
当实施DevOps时,我们将从很多知识源、方法论、实践案例和工具中去选择参考。然而DevOps主要由以下的三大支柱和一个基础组成。
3.1 规范敏捷
一支训练有素的敏捷开发团队是成功实施DevOps的关键。
规范敏捷意味着:
在IT服务生命周期中,越来越频繁和快速的发布反应取决于依赖开发速度的业务变更。因为工作的质量是最重要的,所以得通过将工作分割为小任务来进行支持。Ji-Koutei-Kanketsu(JKK)认为能100%的完成一个条目,是有助于保持一个高质量工作的。而“做完了”(Done)与“结束了”(Completion)的这些概念,对每个人来说都必须定义清楚。造成产品负责人可能改变他/她的任务的,未必一定是对待办项(Product Backlog)的管理,也可能是新的IT服务计划.
3.2 持续交付
持续交付指的是自动实现应用程序的构建、部署、测试和发布。
一个关键的关注点是测试,如验收测试和性能测试等。TPI NEXT®(测试流程优化)可以用于提高这个过程的成熟度。
每个组织都有不同的途径(Pipeline),这取决于发布软件的价值流。一个关键的成功因素是为IT服务建立一个单一的部署管线。
3.3 IT 服务管理
当技术成为大多数业务流程的核心环节时,IT服务的连续性和高可用性是业务存亡之道的关键因素。这可以通过引入降低风险措施和恢复方案来实现。就像IT服务管理所有要素都提及的,只有成功实现服务的连续性才能实现对高层的承诺,并支持组织的所有成员。对于保持高效性而言,持续维护其恢复能力是最基本的前提条件。服务连续性是服务保障的必要组成部分。如果服务无法按照业务的要求保持连续性或恢复,那么业务将无法实现所承诺的价值。服务将无法被提供,从而失去持续的功效。
传统的IT服务管理(ITSM)最佳实践,比如ITIL看起来很繁琐,不匹配DevOps中所倡导的快速流程。有必要考虑一下如何减少管理工作量。基于DevOps去重新调整ITSM是有必要的,创建一个轻量级的ITSM完全集中在业务连续性的最低要求信息上。每个组织的MRI设置取决于他们的业务。
3.4 TPS精益管理
建立一个流水线式的IT服务供应链并不容易,因为有许多项目要改变现有熟悉的开发周期和方法论,你很有必要观念上做改变。
TPS的概念包括JIT和自动化,TPS可以帮助做到以下环节:
JIT意味着要建立一个流水线式的单件流(one-piece flow)的供应链。而自动化意味着尽可能实现自动化并且当生产过程出现缺陷时能停止整个过程。这个过程需要设计并且员工也需要充分理解这两个概念。另一个关键问题是开发和运维的生命周期。需要通过敏捷的方法改变工作方式,包括开发和运维之间每周或每天的信息同步。
4、DevOps 团队角色
为了保证IT服务的业务连续性,希望在您的组织中建立DevOps团队。最好是组建一个小型优质的DevOps团队,这是根据亚马逊的“两个披萨规则”来设立的:就是说团队人数不能多到两个披萨饼还不够他们吃的地步。
团队角色描述如下:
流程主管(Process Master)
服务主管(Service Master)
DevOps工程师(DevOps Engineer)
可靠性工师(Reliability Engineer)(可选)
开发团队(Development team)
运维团队(Operation team)
5、组织
有必要在服务管理办公室(Service Management Office)中组建DevOps 团队来支持服务主管。
适合小型组织的扁平化组织
适合大型复杂组织的矩阵架构
6、DevOps 的流程
要建立一个流水线式的流程,采用JKK 在指导DevOps 团队是最有效的办法。JKK 是一种高质量的工作方式,它意味着对目标理解清晰,理解正确的工作方式,使工作正确的100%的完成,并在没有检查的情况下维护质量要求。
DevOps 的一个配置示例
6.1 业务战略和规划
IT 服务与业务策略和规划有密切的关系服务的主管应该参加业务规划会议并提出如何通过IT 服务获得业务优势的建议。
6.2 市场营销
6.3 管理
流程主管很希望了解如何将整个过程可视化。一种方法是使用Obeya(丰田的一种工程合作方式)为整个流程进行设定。Obeya 这个作战室具有两个目的——信息管理和现场决策。这里面有很多可视化管理工具。团队成员可以很快看到他们在过程中的方方面面。当跨职能团队在一起工作时,Obeya 系统能够快速,准确做出决策,加强沟通、保持队形、迅速收集信息、并形成重要的团队意识。
6.4 项目规划
服务主管组织服务管理办公室(SMO)并定义团队的基本规则。服务主管创建愿景、目标和项目的价值,然后整合DevOps的团队成员。在这个阶段,运行中的基础设施被定义。一个整体流程的价值流图表被设计。
6.5 需求和设计
服务主管定义待办任务(Product backlogs)和并安排优先级。DevOps团队使用待办任务(Product backlogs)来定义故事(Story)。
• 用户故事:角色,职能,业务价值/理由,以及运营条件。
• 测试故事::验收测试用例和服务验收标准。
• 运营故事:设置IT 服务的优先级的和业务连续性的运营条件。
创建服务级别和运营级别协议。
6.6 开发
Scrum 是这个阶段最适用的方法论。开发团队必须提交发布计划并使用规范的敏捷方法。每次迭代的周期需要遵循业务的需要。从质量的角度来看,XP(极限编程)的实践,例如结对编程、TDD(测试驱动开发)、重构和十分钟构建都是有效的。
6.7 部署
6.8 运维
运维团队采用轻量级的ITSM 流程来监控运行的IT 服务状态。发生灾难事件时,确保关键服务保持运营是至关重要的。这个团队应该包括可靠性工程师,需要注意两个关键参数:恢复点目标和恢复时间目标。
6.9 维保
服务主管和可靠性工程师决定是否允许进行维保。经允许,它们被作为变更请求添加到待办任务中。
6.10 客户服务
服务主管和可靠性工程师负责收集客户的反馈,例如包括用户体验和质量事件的运营问题。经允许,它们被作为变更请求添加到待办任务中。
6.11 生命周期终止
服务主管将决定IT 服务生命周期的终止条件,包括发生事件,以及如何发生。
7、DevOps 的实施
DevOps 有三种实施方式,可以根据企业的业务模式进行选择。
7.1 丰田方式(先进复杂)
这种方式重点在于关注IT 服务战略,并给予业务的战略优势。这需要由业务负责人或服务主管来领导。在一个大型企业最好选择矩阵式管理组织架构,并且在IT 战略和业务战略之间保持密切的关系。这个结构很适合IT 服务提供商。
7.2 协同方式(标准)
这种方式将专注如何快速和频繁的提供IT 服务,并保障可靠运行,一般由由服务主管来主导。这种方式尤其适合交互型系统和记录型系统共存。
7.3 持续交付(基本)
这种方式侧重于快速和频繁的软件发布,可以由产品负责人主导。它最适合数码产品提供商(许多新型的互联网企业都属于此列)。
作者: Koichiro (Luke) Toda Nobuyuki Mitsui
译者:刘颋,史鹏程
|