前言
Infrastructure as Code：基础设施即代码，IaC。
Kanban：看板管理，丰田生产模式中的重要概念，指为了达到及时生产方式控制现场生产流程的工具。及时生产方式中的拉式生产系统可以使信息的流程缩短，并配合定量、固定装货容器等方式，而使生产过程中的物料流动顺畅。
关于DevOps的一些最常见的误区：
- DevOps只适用于创业公司。
- DevOps将取代敏捷：敏捷通常是DevOps效率的保障，因为它专注于让小团队向客户持续交付高品质的代码。
- DevOps与ITIL不兼容：ITIL（Information Technology Infrastructure Library，IT基础架构库）或ITSM（IT Service Management，IT服务管理）。DevOps实践可以与ITIL流程兼容。DevOps追求更短的发布周期和更频繁的部署，ITIL流程的许多方面需要完全自动化，以解决配置和发布管理流程相关的许多问题。
- DevOps与信息安全及合规活动不兼容：安全和合规性应该集成到软件开发生命周期的每一项日常工作中。
- DevOps意味着去掉IT运维：即NoOps。IT运维人员变得更像是开发人员（或QA和信息安全人员），融入到产品开发过程中，而该产品则是开发人员在生产中用来安全快速地测试、部署和运行IT服务的平台。
- DevOps只是IaC或自动化：DevOps是一种文化、价值观、企业组织架构等。
- DevOps仅适用于开源软件。
DevOps是创建动态、学习型且强化高度信任的文化规范的公司的一种表现形式，这些公司一定会持续地在市场上创新并在竞争中脱颖而出。
导言：展望DevOps新世界
通用电气公司首席执行官伊梅尔特所说：没有将软件作为核心业务的每一个行业或公司都会受到影响。
微软技术院士Jeffrey Snover说：在过去的经济时代，企业通过移动原子创造价值。而现在，他们必须通过数字创造价值。
技术债务是指当前所做出的决定会导致一些问题，而这些问题随着时间的推移会越来越难解决，未来可采取的措施也越来越少。
开发部门和IT运维部门的目标是对立的，这通常是产生技术债务的一个因素。IT公司两个必须实现的目标：
- 对变化莫测的市场做出反应；
- 为客户提供稳定、可靠和安全的服务。
开发部门通常负责对市场变化做出响应，以最快的速度将新功能或者变更上线。而IT运维部门则要以为客户提供稳定、可靠和安全的IT服务为已任，让任何人都很难甚至无法引入可能会危害生产环境的变更。
恶性循环三部曲：
- 始于IT运维，其目标是让应用程序和基础设施持续运行，以便公司向客户交付价值；
- 开发去弥补最近未兑现的承诺
- 所有事情都变得更加困难
为什么恶性循环无处不在：
- 每个IT公司都有两个对立的目标；
- 每家公司都是一个科技公司。
想要做出一个不会带来任何IT变更的商业决策几乎不可能。
许多心理学家认为，创建一个让人感觉无能为力的系统，是我们能对人类同胞做的最具破坏性的一件事——我们剥夺了他人控制自己成果的能力，甚至营造了一种文化，让人们因为害怕遭受惩罚、失败或危及生存而不敢做正确的事。这创造了“习得性无助”的环境，人们变得不愿或无法采取行动来避免未来遇到同样的问题。
DevOps的准则：总有更好的方法。
用DevOps打破恶性循环
通过在流程中的每一个步骤创建快速反馈回路，每个人都可以立即看到工作效果。只要代码变更提交到VCS，就会在类生产环境中运行快速的自动测试，这持续地保证代码和环境符合设计预期，并且总是处在安全的可部署状态。
在代码和生产环境中无处不在的遥测（英文是Telemetry，可简单理解为监控），保证问题能被迅速地发现并纠正，确保一切都能按照预定的方式进行，并且客户能从软件中获得价值。
推荐阅读Observability vs Monitoring vs Telemetry: Understanding the Key Differences。
Dark Launch：暗启动，感觉类似于功能开关，其他相关的概念包括：金丝雀发布，软启动(Soft Launch)，AB测试。推荐阅读Martin Fowler-Dark Launch。
出现问题时，进行不指责的事后分析，这并不是要惩罚某人，而是为了更好地理解导致事故的原因，以及如何防止事故再次发生。强化团队的学习文化。通过举办内部技术研讨会来提高技能，保证所有人不是在教就是在学。
故意在生产环境中注入故障，从而了解系统是怎样以预期方式发生故障的。
阅读指南
本书的目标是向你提供从启动DevOps转型到实现目标成果所必需的理论、原则和实践。
全书分6个部分。
DevOps介绍
DevOps的三步工作法：
- 流动原则：加速从开发、运维到交付给客户的流程。
- 反馈原则：它使我们能建设出更安全可靠的工作体系。
- 持续学习与实验原则：它打造出一种高度信任的文化和一种科学的工作方式，并将对组织的改进和创新作为日常工作的一部分。
DevOps基于精益、约束理论、丰田生产系统、柔性工程、学习型组织、安全文化、人员优化因素等知识体系，并参考了高信任管理文化、服务型领导、组织变动管理等方法论。
丰田生产系统(TPS)：价值流映射、看板和全面生产维护。
Mike Rother：《丰田套路：转变我们对领导力与管理的认知》一书作者，精益工具箱制作者。提出：精益社区中大多数企业都没有抓住精益的核心——改善套路（Kata）。
敏捷、持续交付和三步法
精益制造：Lean Manufacturing，精益生产。
价值流：出自《Value Stream Mapping》一书。定义：一个组织基于客户的需求所执行的一系列有序的交付活动。或者是：为了给客户设计、生产和提供产品或服务所需从事的一系列活动，它包含了信息流和物料流的双重价值。
WIP：Work in Process，在制品。
技术价值流：
DevOps的定义：把业务构想转化为向客户交付价值的、由技术驱动的服务所需要的流程。
流程的输入是既定的业务目标、概念、创意和假设，始于研发部门接受工作，并将它添加到待完成工作列表中。
部署前置时间，价值流的一个子集。价值流始于工程师向VCS中提交一个变更，止于变更成功地在生产环境中运行，为客户提供价值，并生成有效的反馈和监控信息。
DevOps的目标是采用测试和运维与设计和开发同步的模式，从而产生更快的价值流和更高的质量。只有当工作任务是小批量的，并将质量内建到价值流的每个部分时，这种同步的模式才能实现。
三步工作法：
- 实现开发到运维的工作快速地从左向右流动
流动原则
提升技术价值流的流动性的几个手段：
- 将工作可视化
- 限制在制品数
- 减小批量大小
- 减少交接次数
- 持续地识别和改进约束点
- 消除日常工作中的困境
通过持续加强工作内容的可视化，减小每批次大小和等待间隔，内建质量以防止缺陷向下游传递，从而增强流动性。
使工作可见
采用看板或Sprint计划板等工作形式，还要设置各任务的优先级。
限制在制品数
技术工作者很容易被打断，降低效率。限制同步进行的任务数量，聚焦在阻塞任务上。
减小批量大小
建立平滑而快速的工作流的另一个关键点，是通过小批量的模式完成工作。在精益中，一个重要的经验：为了缩短前置时间和提高交付物质量，应当持续不断地追求小批量模式。理论上，最小的批量是单件流，每次操作只执行一个单位产品的处理。
小批量生产的在制品更少，前置时间更短，错误检测更快，返工量更少。在技术价值流中，单件流可以通过持续部署实现。每一个提交到VCS的变更都会集成、测试并部署到生产环境。
减少交接次数
代码在价值流流转的过程中，需要各个不同部门的协同才能完成相关任务，包括功能测试、集成测试、环境搭建、配置服务器、存储管理、网络、负载均衡设备和信息安全加固等。
一项工作在团队之间交接时，需要大量的沟通——请求、委派、通知、协调，而且经常需要排优先级、调度、消除冲突、测试和验证。这些工作可能还需要使用不同的工单系统或项目管理系统，编写技术规范文档，用会议、电子邮件或电话的形式进行沟通，可能还涉及文件共享服务器、FTP服务器和Wiki页面的使用。
有些信息或知识也不可避免地在交接过程中丢失。
为了减少这类问题的出现，要么努力减少交接次数，要么用自动化方式执行大部分操作，要么重新调整组织结构，让团队不必依赖其他人就可以独立地为客户提供价值。要通过减少队列中的等待时间以及非增值工作的时间来增加流动性。
持续识别和改善约束点
约束点，就是瓶颈，阻塞点。为了缩短前置时间、提高吞吐量，我们需要不断地识别系统中的约束点，提高工作产能。
Goldratt博士给出解决方案，定义如下5个步骤：
- 识别系统约束点；
- 决定如何利用这个约束点；
- 基于上述决定，考虑全局工作；
- 改善系统约束点；
- 如果约束点已经突破，回到第一步，但要杜绝惯性导致的系统约束。
在DevOps的转型过程中，一般需要依次优化如下约束点：
- 环境搭建：如果生产或测试环境的搭建总是需要数周或数月，则按需部署就无法实现。解决措施是按需建立完全自服务的环境，保证团队在需要环境的时候，能通过自动化方式创建；
- 代码部署：如果代码的部署需要花数周或更长时间，那么就无法按需部署。解决措施是尽可能自动化部署的过程，以便让任何开发人员都可以按需自动化地部署；
- 测试的准备和执行：如果每次代码部署都需要两周的时间来完成测试环境的准备和数据集的配置，手动执行所有的回归测试还需要另外四周时间，那么就无法实现按需部署。解决措施是实现自动化测试，这样才能在安全、并行地执行部署的同时，使测试的速度能跟上代码开发的速度；
- 紧密耦合的架构：如果架构是紧密耦合的，那也无法实现按需部署，因为每次要做代码变更时，工程师都不得不从变更评审委员会里获得执行变更的许可。解决措施是创建松散耦合的架构，这样开发人员才能安全、自主地进行变更，提高生产力。
消除价值流中的困境和浪费
制造业里7种主要的浪费类型：库存、过量生产、过度加工、运输、等待、移动和缺陷。
浪费和困境是软件开发过程中导致交付延迟的主要因素，举例如下，真实工作中远不止这些：
- 半成品：它指的是价值流里任何还没有彻底完成的工作（例如，需求文档或尚未审核的变更单）、处于队列中的工作（如等待QA审核或服务器管理员审核的工单）。部分完成的工作会逐渐地过期，随着时间的推移最终失去了价值；
- 额外工序：在交付过程中执行的、并未给客户增值的额外工作，可能包括那些在下游工作中心从没使用过的文档，或是对输出结果做出的并不增值的评审或审批。额外工序不仅增加了处理的工作量，还增加了前置时间；
- 额外功能：在交付过程中构建的那些组织或客户完全不需要的功能。增加功能测试和管理的复杂度和工作量；
- 任务切换：将人员分配到多个项目和价值流里后，他们需要进行上下文切换，并管理工作之间的依赖关系，这会在价值流中耗费额外的工作量和时间；
- 等待：资源的竞争使工作产生等待，将增加周期时间；
- 移动：信息或数据在工作中心之间移动的工作量。例如，在一个需要频繁沟通的项目里，团队成员实际上不在一起办公，无法坐在一起紧密协作，这时人员移动的浪费就产生了。工作交接也会产生移动的浪费，需要额外的沟通来澄清所有歧义的部分；
- 缺陷：由于信息、材料或产品的错误、残缺或模糊，而需要一定的工作量来确认。缺陷的产生和被检测出来的时间间隔越长，解决问题就越困难；
- 非标准或手动操作：需要依赖其他人的非标准的或手动的工作，例如使用不能自动化反复重建的服务器、测试环境和配置。理想情况下，任何依赖运维团队手动完成的操作，都应该配置成自动化的、按需提供的，或者是自助服务；
- 填坑侠：为了实现组织的目标，不得不把有些人和团队置于不太合理的处境，这甚至会成为他们的家常便饭。
DevOps的目标是将这些浪费和困境（任何需要填坑侠的场合）都可视化，并系统地进行改进，减轻或消除这些负担，从而实现快速流动的目标。
反馈原则
第一步工作法描述的原则，使得工作能够在价值流中从左向右快速地流动。第二步工作法描述的原则，则使得在从右向左的每个阶段中能够快速、持续地获得工作反馈。
在复杂系统中安全地工作
复杂系统的特点：
- 无法将系统视为一个整体，去理解各个部分是如何组合在一起的。复杂系统的组件之间通常是紧耦合且紧密关联的，不能仅仅依据组件的行为来解释系统的行为。
- 相同的事情做两次，结果未必相同。
复杂系统中的故障是存在且不可避免的。
4项可以让复杂系统更安全地工作的措施：
- 管理复杂的工作，从中识别出设计和操作的问题；
- 群策群力解决问题，从而快速地构建新知识；
- 在整个组织中，将区域性的新知识应用到全局范围；
- 领导者要持续培养有以上才能的人。
及时发现问题
要不断地对设计和假设进行验证。目标是更早、更快、以尽可能低的成本、从尽可能多的维度增加系统的信息流，并尽可能清晰地确定问题的前因后果。能排除的假设越多，定位和解决问题的速度就越快，从而提高我们的顺应力、敏捷性以及学习和创新能力。
在工作系统中建立反馈和前馈回路，包括创建自动化的构建、集成和测试过程，以便尽早检测出那些可能导致缺陷的代码变更。
反馈回路不但能让问题的快速探测和修复成为可能，而且还能告诉我们如何防止问题复发。这样做不但提高了工作系统的质量和安全性，还创造了组织性知识。
群策群力
群策群力的目的是遏制住问题，防止蔓延，然后定位和处理问题，避免复发。不应绕开问题，也不应该用有更多时间时再解决来搪塞，而要立刻群策群力修复问题。
群策群力的原因如下：
- 防止把问题带入下游处理环节，否则不但修复的成本和工作量会呈指数级增加，还会欠下技术债；
- 防止工作中心启动新工作，那样可能会在系统中引入新的错误；
- 如果问题没有得到解决，在下一次操作中，可能还会遇到相同的问题，修复成本更高。
休哈特提出的PDCA循环：Plan（计划）、Do（实施）、Check（检查）、Act（改进），由爱德华兹·戴明推广并得到迅猛发展。
阻止开展新工作有助于实现持续集成和部署，这就是技术价值流中的单件流。
在源头保障质量
在复杂的系统中，通过加入更多的检查步骤和审批流程，实际上还增加了故障发生的可能性。做决策的地方一般远离执行工作的地方，这导致审批流程的有效性有所下降。这样做不仅降低了决策质量，而且还增加了决策周期，进而减弱了因果关系之间反馈的强度，降低了在成功和失败中学习的能力。
为下游工作中心而优化
可制造性设计（Designing for Manufacturability）原则旨在设计零件和工艺过程，让成品能够以最低的成本、最高的质量和最快的流程生产出来。
精益定义必须为两类客户而设计：外部客户（最有可能为我们提供的服务付费的人）和内部客户（紧随我们立即接收和处理工作的人）。
根据精益原则，最重要的客户是我们的下游。为他们而优化我们的工作，需要我们对他们的问题给予同情心，从而更好地识别出会阻碍快速和平滑流动的设计问题。
在技术价值流中，通过为运维而设计来为下游工作中心做优化，包括运维的非功能性需求（如架构、性能、稳定性、可测试性、可配置性和安全性）与用户功能同样重要。
持续学习与实验原则
技术价值流的核心是建立高度信任的文化。强调每个人都是持续学习者，必须在日常工作中承担风险；通过科学的方式改进流程和开发产品，从成功和失败中积累经验教训，从而识别有价值的想法，摒弃无用想法。所有局部的经验都会快速转化为全局性的改进，从而帮助整个组织尝试和实践新技术。
为日常工作的改进预留时间，进一步促进和保障学习。通过不断向系统加压，来强化持续改进。在可控的情况下，通过在生产环境里模拟或注入故障来增强弹性(resilience)。
通过建立持续、动态的学习机制，帮助团队快速并自动地适应不断变化的环境，进而帮助企业在市场竞争中脱颖而出。
建立学习型组织和安全文化
这些问题在技术价值流中显得特别突出：技术类工作几乎都是在复杂系统中进行的，管理层对事故责任人进行惩罚不但会引起恐惧感，还会导致问题和故障的隐瞒不报，直到下一个灾难性事故的发生。
Ron Westrum博士定义的三种类型的组织文化：
- 病态型：特点是组织中存在大量恐惧和威胁。由于政治原因，个体为了保全自身利益，通常会隐瞒真相或者歪曲事实。在这种组织中，故障和事故经常被隐瞒。
- 官僚型：特点是规则和流程僵化，所有部门通常都自扫门前雪。在这种组织中，通过评判系统处理事故，结果往往恩威兼施。
- 生机型：特点是积极探索和分享信息，让组织更好地履行使命。在这种组织中，整个价值流中所有的员工共同承担责任，对事故进行积极反思，并进行真正的根因调查。
将日常工作的改进制度化
如果团队没有能力或者意愿去改进现有的流程，那么就会持续饱受眼前问题的困扰和折磨，而且痛苦指数还会与日俱增。就算不去优化现状，流程也不会是一成不变的——由于混乱和无序，流程会随着时间的推移持续恶化。
通过明确预留时间来改善日常工作，包括预留时间来偿还技术债、修复缺陷、重构和优化代码和环境。可以在每个开发周期的间歇中预留一段时间，或者安排改善闪电战（kaizen blitze）时段，让工程师通过自组团队的方式来解决他们感兴趣的问题。
对于技术价值流而言，让工作系统更加安全也一样有助于发现和解决潜在风险。
把局部发现转化为全局优化
一旦在局部范围内取得成果，就应当把它分享给组织里的其他人，让更多的人从中获益。
隐性知识：即很难通过文档或沟通的方式传递的知识。
出现任何流程或操作偏差都要写故障报告，以便积累经验。不管故障信号强弱，或者风险大小如何，都会基于这些经验持续地更新流程和系统设计。
在技术价值流中，也应该通过类似的机制建立全局知识库。
在日常工作中注入弹性模式
高绩效组织则通过改善日常运营，持续地引入张力提高生产效率，同时在系统中注入更大的弹性，来实现或达到更佳的结果。
antifragility：抗脆弱性，通过加压来增强弹性。
在软件系统中引入张力，可提高开发人员的生产效率及可靠性，做法包括：
- 缩短部署的前置时间
- 提高测试覆盖率
- 缩短测试执行时间
- 必要时解耦架构
- 大规模故障预演
领导层强化学习文化
领导力的优秀并非体现在做出的所有决定都是对的。相反，更卓越的领导力其实是为团队创造条件，让团队能在日常工作中感受到这种卓越。换句话说，这需要领导者和员工们共同的努力，每个人都相互依存，缺一不可。
领导者必须强调解决问题的能力和学习的价值。
领导者帮助一线工作者在日常工作中发现并解决问题，实际上就是丰田生产系统的核心，也是学习型组织、改善套路和高可靠性组织的核心。
从何处开始
首先评估组织的价值流，再找到合适的切入点，并制定策略，以组建专门的转型团队、设定改进目标并最终进行推广。
任何转型在开始时都充满着不确定性——我们正在策划的旅程有着美好的目的地，可是几乎所有的中间步骤都是未知的。
选择合适的价值流作为切入点
理解、可视化和运用价值流
确定创造客户价值所需的团队
复杂系统有若干个团队组成，没有一个团队或个体完全熟悉创造客户所需的价值的每一项工作。
Teamwork：
- 产品负责人：作为业务方的代言人，定义系统需要实现的功能；
- 开发团队：负责开发系统功能；
- QA团队：给开发团队提供反馈，并确保系统功能符合需求；
- 运维团队：负责维护生产环境，并确保系统能够良好地运行；
- 信息安全团队：负责系统和数据的安全；
- 发布经理：负责管理和协调生产环境部署以及发布流程；
- 技术主管或价值流经理：（根据精益方法论的定义）负责从始至终地保障价值流的产出满足或超出客户（和组织）期望。
针对团队工作绘制价值流图
组建专门的转型团队
用工具强化预期行为
开发人员和运维人员可创建共享的工作队列，而不是使用不同的工具（如开发使用JIRA，运维则使用ServiceNow）。
共享队列的好处：
- 当生产事故在开发人员的工作系统中可见时，人们能清楚地知道事故会在什么时候影响到其他工作，这在使用看板图时尤为明显；
- 统一任务列表，每个人都能从全局的角度思考优先级最高的事情，选择对组织最有价值的工作，或能最大限度地偿还技术债务的工作。
为了强化共同目标，可使用聊天室，例如IRC频道、HipChat、Campfire、Slack、Flowdock和OpenFire。
参考康威定律设计组织结构
康威定律：系统设计受限于组织自身的沟通结构。组织的规模越大，灵活性就越差，这种现象也就越明显。
在决策科学领域，RobertoFernandez博士定义如下3种组织结构类型：
- 职能型：注重提高专业技能、优化分工或降低成本。以专业技能为中心，有助于促进职业和技能发展，通常具有多层次的组织结构；
- 市场型：注重快速响应客户需求，往往有着扁平化的结构，由多个跨职能的部门组成，整个组织往往可能存在冗余现象；
- 矩阵型：试图结合职能型和市场型，通常都非常复杂；有时职能型和市场型的目标都实现不了。
过度职能导向，会延长交付周期，需要提一大堆工单，审批流程漫长。这种僵局阻碍组织实现重要目标，而实现这些目标的意义却远远地超过降低成本的愿望。
只要服务团队能够快速（且按需）从运维团队获得可靠帮助，集中式的职能型运维组织也可以实现高效运转，反之亦然。
这些组织的共同之处是拥有高度信任的文化，所有部门都能够有效地协作，所有工作的优先级设置都是透明的，系统预留足够的容量，能够迅速完成高优先级的工作。这在某种程度上是依靠自动化的自助服务平台实现的，可保证产品质量。
在高效能组织中，人们有着共同的目标。保证质量、可用性和安全性是所有人日常工作一部分。共同的痛点可以强化团队的共同目标。
使团队成员都成为通才，全栈工程师，几种人才：
- I型：专家，精通某个领域，其他领域的技能和经验很少，很快遇到瓶颈，对下游的浪费和影响不敏感，抵制灵活和可变的计划
- T型：通才，精通某个领域，拥有很多领域的技能，能突破瓶颈，对下游的浪费和影响敏感，帮助制定灵活和可变的计划
- E型：精通某几个领域，有多个领域的实践经验，执行能力强，能持续创新，潜力无限
学习型组织需要的是愿意学习的人。
投资于服务和产品，而非项目。
不合理的团队组织方式可能产生不良后果：康威定律的副作用。
在紧耦合的软件架构中，即使是微小的变更也可能导致大规模的故障。
两个比萨原则：两个比萨够团队的所有成员吃，这样的团队通常有5～10人。
这种规模限制有4个作用：
- 确保团队成员对系统有清晰、相同的理解。当团队规模变大时，如果要让所有人都了解系统状况，需要沟通的信息量就会成倍增加；
- 限制正在开发的产品或服务的增长率。通过限制团队的规模，系统的发展速度也受到限制，这也有助于保证团队成员对系统有相同的理解；
- 分散权力并实现自主。每个团队都尽可能地自主工作。团队负责人直接向管理层汇报，由他决定团队负责的关键业务指标（适应度函数），并将其作为团队实践的总体评估标准。然后，团队能够自主采取行动来最大限度地提升该指标；
- 团队领导者可让员工获得领导经验，即使失败也不会有灾难性后果。
康威定律运用得好，团队就能够安全、独立地开发、测试和向客户交付价值；而运用得不好，就会产生不良的后果，导致安全性和敏捷性遭到破坏。
将运维融入日常开发工作
让开发具备更强的运维能力，以市场为导向创造出更多的业务成果，并能最终提高效率和生产力。
将运维融入日常开发工作的实现方式，包括参加每日站会、计划会议以及回顾会议等。
创建共享服务，提高开发生产力
理想情况下，运维提供的所有平台和服务应该是全自动化的，并且能按需提供，不需要开发人员提交工单，然后再等待运维团队手动处理，这能保证运维不成为客户的瓶颈。
将运维工程师融入服务团队
在大型项目启动阶段就融入运维工程师（而不是快到交付阶段才申请运维资源），参加开发团队的相关讨论，如计划会议、每日站会以及新特性的演示，并帮助决定可以交付哪些特性。
为每个服务团队分派运维联络人
集中式运维团队依然管理着所有环境，负责确保它们的一致性。派遣的运维工程师的责任是理解下列内容：
- 新产品的功能是什么，为什么要开发这个产品；
- 怎样工作的，可运维性、可扩展性和监控能力如何（强烈建议以图示说明）；
- 怎样监控和收集指标，如何确认应用的功能正常；
- 架构和模式是否与以往的做法不同，为啥不同；
- 是否对基础设施有额外的需求，它的使用对基础设施容量的影响如何；
- 特性的发布计划。
目标是确保运维不会成为产品团队的瓶颈。
邀请运维工程师参加开发团队的会议
DevOps的目标是帮助运维工程师和其他非开发人员更好地了解目前开发团队的文化，并主动地参与规划工作和日常工作，从而使运维团队可以更好地为产品团队植入运维能力，并在产品上线以前就落实相关工作。
一些形式：
- 每日站会：运维部门应该充分理解开发团队的活动，从而更好地进行规划和准备；
- 回顾会议：运维团队的反馈应该帮助产品团队更好地认识和理解自己所做出的决策对下游团队的影响；
- 使用看板图：看板图是工作可视化管理的理想工具。可视化是将运维工作融入产品价值流的关键。