前端做一个网站需要些什么软件,手机网站 方案,wordpress不要分页,企业网站开发 流程DevOps 精要:业务视角#xff08;七#xff09; DevOps历程什么是企业体系的DevOps#xff1f;DevOps的目标是什么#xff1f; DevOps的知识体系规范敏捷持续交付IT服务管理以TPS理念为基础 DevOps团队角色流程主管#xff08;Process Master#xff09;服务主管#xf… DevOps 精要:业务视角七 DevOps历程什么是企业体系的DevOpsDevOps的目标是什么 DevOps的知识体系规范敏捷持续交付IT服务管理以TPS理念为基础 DevOps团队角色流程主管Process Master服务主管Service MasterDevOps工程师DevOps Engineer把关人/发布协调员Gatekeeper/Release coordinator可靠性工程师Reliability Engineer可选开发团队Development team运维团队Operation team组织适合小型组织的扁平化组织适合大型复杂组织的矩阵组织架构 DevOps的流程业务战略和规划Business Strategy and Planning市场营销Marketing and sales管理Administration项目规划Project Planning需求和设计Requirements and Design开发Development部署Deployment运维Operation维保Maintenance客户服务Customer service生命周期终止End of life DevOps的实施丰田方式先进但复杂协同方式标准持续交付基本 结论术语表KAIZEN持续改善KAIZEN in Advance提前改善Ji-Koutei-KanketsuJKK质量检查TPI NEXT完整版术语表 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-ActPDCA戴明环来提升成熟度。企业级的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 codeIT服务需要以更频繁、更快速的发布周期来响应业务变化这取决于开发速度。工作质量是最重要的需要将工作分割为小任务来加以支持。
Ji-Koutei-KanketsuJKK概念认为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 InformationMRI且严格聚焦于业务持续性的轻量级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系统能够快速、准确做出决策加强沟通、保持一致、迅速收集信息、并形成重要的团队集体意识。
项目规划Project Planning
服务主管组织服务管理办公室SMO并定义团队的基本规则。服务主管创建愿景、目标和项目的价值然后整合DevOps的团队成员。
在这个阶段运行中的基础设施被定义。要设计一个整体流程的价值流图表。
需求和设计Requirements and Design
服务主管定义产品待办事项Product backlogs安排优先级。
用户故事角色职能业务价值/理由以及运维条件。测试故事验收测试用例和服务验收标准。运维故事设置IT服务的优先级的和业务连续性的运维条件。
创建服务级别和运维级别协议。
DevOps工程师和运维团队定义转换、测试和开发的基础设施。开发团队还创建了发布和迭代计划。
把关人研究IT服务的合规性以及IT服务的监管要求。可靠性工程师定义测试方法和测试用例。
开发Development
Scrum是这个阶段最适用的方法论。
开发团队应该提交并遵守发布计划并使用规范的敏捷方法。迭代Sprint的周期取决于业务的需要。
从质量的角度来看XPExtreme Programming极限编程的实践例如结对编程pair-programming、TDDTest-Driven Development测试驱动开发、重构Refactoring和十分钟构建Ten-Minutes Build都是有效的。
部署Deployment
在完成持续集成之后自动化流程开始进行验收测试、性能测试和部署。DevOps工程师应该建立单件流One-piece flow方式构建一个单一的自动化部署流水线pipeline。
可靠性工程师和DevOps工程师将共同提升测试流程。
把关人Gatekeeper监控整个过程的进度决定是否上线。运维团队研究如何保持业务连续性。
运维Operation
运维团队采用轻量级的ITSM流程来监控IT服务运行的状态。
发生灾难事件时确保关键服务依然正常运行是至关重要的。运维团队此时应该让可靠性工程师参与进来并需要注意两个关键参数恢复点目标Recovery Point ObjectiveRPO和恢复时间目标Recovery Time ObjectiveRTO。
维保Maintenance
服务主管和可靠性工程师决定是否允许进行维保。经允许它们被作为变更请求Request for ChangeRFC添加到待办任务中。
客户服务Customer service
服务主管和可靠性工程师负责收集客户的反馈例如包括用户体验和质量事件的运维问题。经允许它们被作为变更请求添加到待办任务中。
生命周期终止End of life
服务主管决定IT服务生命周期的终止条件包括发生事件以及如何发生。
下图显示了DevOps的一个配置示例。 ACDM为Architecture-Centric Design Method一种演进式软件架构设计方法。 轻量级的ITSM图表如下图所示。
DevOps的实施
DevOps有三种实施方式可以根据企业的业务模式进行选择。
丰田方式先进但复杂
丰田方式TOYOTA WAY重点在于关注IT服务战略并给予业务的战略优势。这需要由业务负责人或服务主管来领导。
在大型企业最好选择矩阵式管理组织架构并且在IT战略和业务战略之间保持密切的关系。这个结构很适合IT服务提供商IT Service Provider。
协同方式标准
协同方式Collaboration将专注如何快速和频繁的提供IT服务并保障可靠运行一般由服务主管来主导。
这种方式尤其适合需要将交互型系统SoE和记录型系统SoR联结在一起的企业。
持续交付基本
持续交付Continuous Delivery侧重于快速和频繁的软件发布可以由产品负责人主导。
它最适合数码产品提供商的软件部门
结论
显然对于大多数IT经验来说DevOps是一个整体的重大模式转变。因此关于DevOps的培训对员工来说十分重要。这是您DevOps旅程的开始。
术语表
KAIZEN持续改善
持续改进意味着按照周、日循环进行PDCA。为了找到根本原因问五次“为什么”。
问题需要通过数据的方式来定义和支持。是否大家都能清晰地认识到问题
设置一个你发现的问题的假设然后基于防范方式来思考并验证你的假设。
防范措施必须基于活动在日常进行定义也需要设定每周的KPI这样人们可以感觉到一种成就感。
KAIZEN in Advance提前改善
当下游的环节意识到有些问题可能来自上游最优的方式是他们站在整体流程的角度来为解决问题创造假设。然后他们可以向上游部门提出期望。这是一个反馈闭环的问题。
Ji-Koutei-KanketsuJKK质量检查
JKK的概念是一种完美状态在你所处在的工作流程中不要做低质量的工作不接受流程早期就出现错误的输出不把糟糕的情形输出到下一个流程。
工作标准要求能够采用正确的方法去完成工作这也意味着要定义一个度量方法去决定是否继续进行下一步。
TPI NEXT
TPI-Test Process Improvement测试流程优化是一种业务驱动的测试过程改进。
TPI是一套来自欧洲的软件测试最佳实践方法论
完整版术语表
