继上篇概念篇(https://blog.csdn.net/jinzhengquanqq/article/details/114990499 )之后，DevOps的实践从哪里开始以及需要做什么
目录
1选择合适的价值流作为切入点
2理解、可视化、活用价值流向
3借鉴清秀毛刷规律设计组织结构
4将运维纳入日常开发工作
1以适当的价值流为切入点选择适当的价值流进行DevOps变革值得仔细研究。 这不仅决定了变革进程的难度，也决定了变革进程的参与者。 这不仅影响到如何构建团队，还影响到如何以最佳方式参与团队及其成员。
绿地项目与棕地项目:绿地项目是指全新的软件项目。 通常是指证明可以提出公共云或私有云方案，或者尝试采用自动部署工具或相关工具等的试点项目。 布朗项目是指已经为客户服务了几年到几十年的产品和服务，通常有很多技术债务，例如没有自动化测试，在非维护的平台上运行。
兼顾记录型系统和交互型系统:传统的记录型系统是指像ERP这样的系统，交易和数据的正确性很重要； 交互式系统是面向客户或员工的交互式系统。 记录型系统变化速度通常较慢，有监管和合规要求，重点是“正确进行”； 交互式系统需要快速响应反馈，因此变化速度通常更快。 重点是通过实验找到最能满足客户要求的方法，“快速”。 高性能的组织可以兼顾高生产能力和可靠性。
33558 www.Sina.com/:相信devo PS的原则和实践，找到有意识、有能力地创新和改进现有流程的团队。
从最乐于创新的团队开始:无论如何选定切入点，都要积极宣传尽早展示成果，把大的改进目标分解成渐进的小步骤。 这样可以提高改进速度，并在错误选择价值流向后尽早发现。 通过早期发现错误，团队可以快速回滚和重试，根据新经验做出不同的决定，并根据已经取得的成功逐步扩大DevOps计划的适用范围。 按照风险从低到高的顺序，切实提高可靠性和影响力，获得支持。
在理解、可视化、运用DevOps原则和模式所适用的价值流程后，必须深刻理解如何为顾客提供价值。 做什么工作？ 谁来做？ 我应该做什么来改进流程？
考虑下一步：确定创造客户价值所需的团队； 注重创建价值流图表和可视化所需工作的价值流图，帮助团队更好、更快地创造客户价值。
33558 www.Sina.com/:选择devo PS试点计划或服务后，必须确定价值流的所有成员。 他们有责任共同为顾客创造价值。 通常包括产品主管、开发团队、QA团队、运输团队、信息安全团队、发布经理、技术主管或价值流经理。
扩大DevOps的范围:确定流价值流的相关成员后，下一步是深入了解工作方法并在价值流图表中记录。 价值流图的目标不是记录所有步骤和详细信息，而是确定阻碍快速流动的部分，从而缩短提前期并提高可靠性。 根据价值流参与团队提供的所有信息，需要重点分析和优化以下两种类型的工作： 需要等待几周到几个月的工作； 或者引起重大返工的工作。 价值流程图包含重要的流程模块，每个模块至少包含工作项的前置。 时间和处理时间以及下游消费者测量的%C/A，一旦确定了想要改善的测量指标，就进入分析和测量的下一个阶段，绘制理想化的价值流程图，从而
作为下一阶段的改进目标。领导者帮助确定改进目标，并指导团队就假设和措施集思广益，通过实验探索各种假设，然后分析结果，以判断假设是否正确，通过不断地重复和迭代，团队把新获得的经验用于下一次实验和验证。组建专门的转型团队：组建专门的转型团队，并使之独立于负责日常运作的部门。这个团队应该负责实现明确定义的、可度量的、系统级的可目标。包括如下措施：转型团队的成员专门执行DevOps转型工作，选择熟悉多个领域的通才作为团队成员；选择与其他部门长期保持良好关系的人作为团队成员；如果可能，为团队找一个独立的办公区域，使各位成员尽可能多地相互交流，并和其他部门保持适当的距离。如果可能，要将转型团队从诸多现有的规则和规定中解放出来，毕竟，既定的流程属于一种群体意识，专门的转型团队需要创建新的流程，从而得到想要的结果，创造新的群里意识。
拥有共同的目标：改进计划首要内容就是为未来一段时间设定可度量目标，为了实现目标，团队需要付出相当的努力，而且目标的实现应该能为整个组织和客户创造出显著的价值。一旦明确整体目标，团队就应该制定改进工作的详细计划与节奏，以迭代、增量的方式进行，对于每次迭代，团队应该制定出一组能够产生价值的小目标，并朝着长期目标靠近，在每次迭代结束时，团队应该检查进度，并为下一次迭代设定新的目标。
保持小跨度的改进计划：DevOps转型项目中，应该努力在数周内（最差应该在数月内）获得可度量的改进成果或者可用的数据。
为非功能性需求预留20%的开发时间，减少技术债务：为了积极管理技术债务，要确保至少把20%的开发和运维时间投入到重构、自动化工作、架构优化以及非功能性需求上，例如可维护性、可管理性、可扩展性、可靠性、可测试性、可部署性和安全性等。
提高工作的可视化程度：为了能明确团队是否正朝着既定目标前进，组织中的每个人都有必要了解当前的工作状态，将状态进行可视化的方法有很多，最重要的是有效展示最新状态，而且要不断修订，以确保团队了解最新进展。
用工具强化预期行为：在DevOps价值流中，使用工具来强化文化，并加速实现行为的改变。我们的目标是强调，开发人员和运维人员不仅有着共同的目标，而且还有同一份任务列表，在理想的情况下，任务列表存储在公共的工作系统中，使用统一的术语，并能全局地进行优先级排序。采用这种方式，开发人员和运维人员可以创建共享的工作队列，而不是使用不同的工具。建立机制并允许团队成员互相帮助，甚至帮助其他团队的成员。
3 参考清秀的画笔定律设计组织结构团队的组织方式会影响工作方式。清秀的画笔定律指出，系统设计受限与组织自身的沟通结构，组织的规模越大，灵活性越差，这种现象也就月明显。软件开发团队的结构对软件产品的架构和成果有着巨大的影响，为了使工作从开发到运维快速地流动，并保证产品质量和客户满意度，必须利用清秀的画笔定律发挥团队的优势，并灵活地组织团队。
组织原型：在决策科学领域，主要有3种组织结构类型：职能型、矩阵型和市场型。职能型：组织结构注重提高专业技能，这些组织以专业技能为中心，有助于促进职业发展和技能发展，并且通常具有多层次的组织结构，运维部门通常采用这种组织结构；矩阵型：组织结构试图结合职能型和市场型。市场型：祖师结构注重快速响应客户需求，这种组织往往有着扁平化的结构，由多哥跨职能的部门组成，整个组织可能往往存在冗余现象。
过度职能导向的危害：过度职能导向，例如数据库归为一组，网络管理员被归另一组，这样的方式会延长交付周期，在大规模部署活动中，不得不向多个团队发出一堆工单进行协调，这导致每一步骤都面临长时间等待。
组建以市场为导向的团队：以市场为导向的团队不但要负责特性开发，而且在整个应用生命周期中还要负责测试、安全、部署和生产环境的运维。这些跨职能团队可以独立运作----能够设计和开展用户实验，构建和交付新特性，在生产环境中部署并运行服务，不依赖于其他团队就能修复任何缺陷，从而加快行动的步伐。
使职能导向有效：组建跨职能和以市场为导向的团队是实现快速流动和可靠性的一种方式，但并不是唯一的方式，只要价值流中的所有人都能意识到客户和组织的目标，不管他们在组织中处于什么位置，都可以通过职能导向取得所预期的DevOps成果。组织拥有高度信任文化，所有部门都能够有效地协作，所有工作的优先级设置都是透明的，并且系统预留流足够的容量，能够迅速完成高优先级的工作，这在某种程度上依靠自动化的自助服务平台实现的，它保证了产品质量。
将测试、运维和信息安全融入日常工作：在高效能组织中，人们有着共同的目标，保证质量、可用性和安全性不是某个部门的职责，而是所有人的日常工作的一部分。
使团队成员都成为通才：鼓励团队成员学习，帮助客服学习焦虑和获得相关技能，并让他们有明确的职业生涯规划等，这样做有助于培养员工的成长型思维模式，毕竟，学习型组织需要的是愿意学习的人，通过鼓励每位员工积极学习并为其提供培训和支持，我们将以可持续性最强、成本最低的方式造就强大的团队。
投资于服务和产品、而非项目：实现高绩效的另一种方法是组建稳定的服务团队，持续提供资金，让他们执行自己的战略和计划。这些团队应该有工程师专门负责对内部或外部客户的具体承若，如特性、故事和任务等。
根据清秀的画笔定律设定团队边界：随着组织的发展，保持人员和团队之间的有效沟通和协作成为最大的一个挑战。在理想情况下，软件的架构应该保证小团队能够独立运作，彼此充分解耦，从而避免过多不必要的沟通和协作。
创建松耦合架构，提高生产力和安全性：松耦合的架构意味着在生产环境中可以独立更新某一项服务，而无需更新其他服务，该服务必须与其他服务以及共享数据库解耦。
保持小规模：清秀的画笔定律帮助我们根据期望的沟通模式设定团队边界，但也鼓励缩小团队规模，减少团队间的沟通，并保持团队的专业领域小且有界限。
4 将运维融入日常开发工作我们的目标是能够以市场为导向，让小团队快速、独立地为客户提供价值。通过使开发团队拥有更强的运维能力，可以以市场为导向创造出更多的业务成果，并能最终提高效率和生产力。
集中式运维团队如何取得以市场为导向的成果，以下是3个通用的策略：构建自服务能力，帮助开发人员提高生产力；将运维工程师融入服务团队；如果运维工程师人数紧张，则可以采用运维联络人模式。
创建共享服务，提高生产力：运维部门若想取得以市场为导向的成果，一种做法是创建一套集中式的平台和工具集服务，让所有开发团队都能够通过使用这套平台和服务来提高生产力，例如搭建类生产环境、部署流水线、自动化测试工具、生产环境遥测控制台。
将运维工程师融入服务团队：开发团队和运维工程师的紧密配合和协作是一种极其有效的方式，能将运维知识通过交叉培训的方式融入服务团队，还可以将运维知识逐渐转换为自动化的代码，使之更可靠和更广泛地重用。
为每个服务团队分派运维联络人：由于资源不足，可能无法给每个产品团队都分派运维工程师，但可以给每个产品团队指定一位运维联络人，通过这种方式同样也能得到类似的好处。
邀请运维工程师参加开发团队的会议：在融入运维工程师或分派运维联络人之后，可以邀请他们参加开发团队的各种会议。邀请运维工程师参加每日站会、邀请运维工程师参加回顾会议、使用看板图展示运维工作。
参考书《DevOps实践指南》，《持续交付发布可靠软件系统方法》