DevOps 是个神马？【实践开始】

最新推荐文章于 2021-04-26 11:57:14 发布

jinzhengquanqq

最新推荐文章于 2021-04-26 11:57:14 发布

阅读量196

点赞数

分类专栏：软件工程

本文链接：https://blog.csdn.net/jinzhengquanqq/article/details/115320511

版权

软件工程专栏收录该内容

12 篇文章 0 订阅

订阅专栏

接着上篇概念篇（https://blog.csdn.net/jinzhengquanqq/article/details/114990499），一起来看看DevOps的实践从哪里开始，都需要做些什么？

1 选择合适的价值流作为切入点

选择合适的价值流进行DevOps转型，这一工作值得仔细斟酌，它不仅决定了转型过程的难度，而且还决定了转型过程的参与者，它不仅影响到如何组建团队，而且还影响到如何让团队及其成员以最佳方式参与其中。

绿地项目与棕地项目：绿地项目是指全新的软件项目。通常是指一些试点项目，用于证明公有云或私有云方案的可行行，或者尝试采用自动化部署工具或相关工具等；棕地项目是指那些已经服务客户长达几年甚至几十年的产品或服务，这种项目通常背负大量的技术债务，比如无自动化测试、运行在无人维护的平台上等。

兼顾记录型系统和交互型系统：传统的记录型系统是指类似于ERP的系统，它的交易和数据的正确性是至关重要的；交互型系统则是指面向客户或员工的可交互系统。记录型系统的变化速度通常较慢，并且有监管和合规性要求，侧重于“做得正确”；交互型系统的变化速度通常较快，因为它需要快速响应反馈，通过实验找到最能满足客户要求的方式，侧重于“做得快速”。高绩效组织能够兼顾高水平的生产能力和可靠性。

从最乐于创新的团队开始：找到那些相信DevOps原则和实践，并有意和能力对现有流程进行创新和改进的团队。

扩大DevOps的范围：不管如何选定切入点，都要尽早展示成果，并积极宣传，将大的改进目标分解成渐进式的小步骤。这样能提高改进速度，还可以在错误选择价值流后及早发现，通过及早发现错误，团队可以快速回滚和重试，并根据新的经验做出不同的决定，基于已经取得的成功，逐步扩大DevOps计划的应用范围。遵循低风险的顺序，有条不稳地提高可信度和影响力，并获得支持。

2 理解、可视化和运用价值流

一旦确定应用DevOps原则和模式的价值流后，就要深刻理解如何向客户交付价值：做什么工作？谁来做？该采取什么措施改善流程？

探讨以下步骤：确定创造客户价值所需的团队；绘制价值流图，把必要的工作可视化；以价值流图为导向，帮助团队更好、更快速地创造客户价值。

确定创造客户价值所需的团队：在选择好DevOps试点应用或服务后，必须确定价值流的所有成员，他们有责任共同为客户创造价值。一般来说，包括以下成员：产品负责人，开发团队，QA团队，运维团队，信息安全团队，发布经理，技术主管或价值流经理。

针对团队工作绘制价值流图：确定流价值流的相关成员之后，下一步是深入理解工作方式，并用价值流图进行记录。绘制价值流图的目标并不是记录所有的步骤和细节，而是识别出阻碍快速流动的环节，从而缩短前置时间和提高可靠性。根据价值流参与团队所提供的全部信息，应该重点分析和优化下面两类工作：需要等待数周甚至数月的工作；引发或处理重大返工的工作。价值流图包含重要的流程模块，每个模块至少包括工作项的前置。时间和处理时间，以及下游消费者测量的%C/A，一旦确定了想要改进的度量指标就可以进入分析和度量的下一阶段，绘制理想化的价值流图，并以此作为下一阶段的改进目标。领导者帮助确定改进目标，并指导团队就假设和措施集思广益，通过实验探索各种假设，然后分析结果，以判断假设是否正确，通过不断地重复和迭代，团队把新获得的经验用于下一次实验和验证。

组建专门的转型团队：组建专门的转型团队，并使之独立于负责日常运作的部门。这个团队应该负责实现明确定义的、可度量的、系统级的可目标。包括如下措施：转型团队的成员专门执行DevOps转型工作，选择熟悉多个领域的通才作为团队成员；选择与其他部门长期保持良好关系的人作为团队成员；如果可能，为团队找一个独立的办公区域，使各位成员尽可能多地相互交流，并和其他部门保持适当的距离。如果可能，要将转型团队从诸多现有的规则和规定中解放出来，毕竟，既定的流程属于一种群体意识，专门的转型团队需要创建新的流程，从而得到想要的结果，创造新的群里意识。

拥有共同的目标：改进计划首要内容就是为未来一段时间设定可度量目标，为了实现目标，团队需要付出相当的努力，而且目标的实现应该能为整个组织和客户创造出显著的价值。一旦明确整体目标，团队就应该制定改进工作的详细计划与节奏，以迭代、增量的方式进行，对于每次迭代，团队应该制定出一组能够产生价值的小目标，并朝着长期目标靠近，在每次迭代结束时，团队应该检查进度，并为下一次迭代设定新的目标。

保持小跨度的改进计划：DevOps转型项目中，应该努力在数周内（最差应该在数月内）获得可度量的改进成果或者可用的数据。

为非功能性需求预留20%的开发时间，减少技术债务：为了积极管理技术债务，要确保至少把20%的开发和运维时间投入到重构、自动化工作、架构优化以及非功能性需求上，例如可维护性、可管理性、可扩展性、可靠性、可测试性、可部署性和安全性等。

提高工作的可视化程度：为了能明确团队是否正朝着既定目标前进，组织中的每个人都有必要了解当前的工作状态，将状态进行可视化的方法有很多，最重要的是有效展示最新状态，而且要不断修订，以确保团队了解最新进展。

用工具强化预期行为：在DevOps价值流中，使用工具来强化文化，并加速实现行为的改变。我们的目标是强调，开发人员和运维人员不仅有着共同的目标，而且还有同一份任务列表，在理想的情况下，任务列表存储在公共的工作系统中，使用统一的术语，并能全局地进行优先级排序。采用这种方式，开发人员和运维人员可以创建共享的工作队列，而不是使用不同的工具。建立机制并允许团队成员互相帮助，甚至帮助其他团队的成员。

3 参考康威定律设计组织结构

团队的组织方式会影响工作方式。康威定律指出，系统设计受限与组织自身的沟通结构，组织的规模越大，灵活性越差，这种现象也就月明显。软件开发团队的结构对软件产品的架构和成果有着巨大的影响，为了使工作从开发到运维快速地流动，并保证产品质量和客户满意度，必须利用康威定律发挥团队的优势，并灵活地组织团队。

组织原型：在决策科学领域，主要有3种组织结构类型：职能型、矩阵型和市场型。职能型：组织结构注重提高专业技能，这些组织以专业技能为中心，有助于促进职业发展和技能发展，并且通常具有多层次的组织结构，运维部门通常采用这种组织结构；矩阵型：组织结构试图结合职能型和市场型。市场型：祖师结构注重快速响应客户需求，这种组织往往有着扁平化的结构，由多哥跨职能的部门组成，整个组织可能往往存在冗余现象。

过度职能导向的危害：过度职能导向，例如数据库归为一组，网络管理员被归另一组，这样的方式会延长交付周期，在大规模部署活动中，不得不向多个团队发出一堆工单进行协调，这导致每一步骤都面临长时间等待。

组建以市场为导向的团队：以市场为导向的团队不但要负责特性开发，而且在整个应用生命周期中还要负责测试、安全、部署和生产环境的运维。这些跨职能团队可以独立运作----能够设计和开展用户实验，构建和交付新特性，在生产环境中部署并运行服务，不依赖于其他团队就能修复任何缺陷，从而加快行动的步伐。

使职能导向有效：组建跨职能和以市场为导向的团队是实现快速流动和可靠性的一种方式，但并不是唯一的方式，只要价值流中的所有人都能意识到客户和组织的目标，不管他们在组织中处于什么位置，都可以通过职能导向取得所预期的DevOps成果。组织拥有高度信任文化，所有部门都能够有效地协作，所有工作的优先级设置都是透明的，并且系统预留流足够的容量，能够迅速完成高优先级的工作，这在某种程度上依靠自动化的自助服务平台实现的，它保证了产品质量。

将测试、运维和信息安全融入日常工作：在高效能组织中，人们有着共同的目标，保证质量、可用性和安全性不是某个部门的职责，而是所有人的日常工作的一部分。

使团队成员都成为通才：鼓励团队成员学习，帮助客服学习焦虑和获得相关技能，并让他们有明确的职业生涯规划等，这样做有助于培养员工的成长型思维模式，毕竟，学习型组织需要的是愿意学习的人，通过鼓励每位员工积极学习并为其提供培训和支持，我们将以可持续性最强、成本最低的方式造就强大的团队。

投资于服务和产品、而非项目：实现高绩效的另一种方法是组建稳定的服务团队，持续提供资金，让他们执行自己的战略和计划。这些团队应该有工程师专门负责对内部或外部客户的具体承若，如特性、故事和任务等。

根据康威定律设定团队边界：随着组织的发展，保持人员和团队之间的有效沟通和协作成为最大的一个挑战。在理想情况下，软件的架构应该保证小团队能够独立运作，彼此充分解耦，从而避免过多不必要的沟通和协作。

创建松耦合架构，提高生产力和安全性：松耦合的架构意味着在生产环境中可以独立更新某一项服务，而无需更新其他服务，该服务必须与其他服务以及共享数据库解耦。

保持小规模：康威定律帮助我们根据期望的沟通模式设定团队边界，但也鼓励缩小团队规模，减少团队间的沟通，并保持团队的专业领域小且有界限。