1.6 协作
DevOps的一个目标是最大程度减少协作，以缩短推向市场的时间。需要协作的两个原因是，首先，不同团队开发的各部分能够在一起工作；其次，避免重复工作。《Oxford English Dictionary》（牛津英语词典）对协作的定义是：对复杂个体或活动的不同元素进行组织，以便能够有效地一起工作。本节深入讨论协作的概念与机制。
1.6.1 协作的形式
协作机制有不同的属性。
直接的——需要协作的人彼此认识（例如，团队成员）。
间接的——协作机制的受众只能根据其特征识别（例如，系统管理员）。
持久的——在协作结束后，协作工件仍旧可以得到（例如，文档、电子邮件、公告牌）。
短暂的——按照字面意思，这种协作不产生工件（例如，面对面的会议、交谈、电话/视频会议），通过手工记录或机器记录仪，短暂协作可以转化为持久协作。
同步的——每个人是实时协作的（例如，面对面的）。
异步的——每个人不是实时协作的（例如，文档、电子邮件）。
协作机制构建到DevOps使用的很多工具中。例如，版本控制系统就是一种自动化协作形式，防止开发人员覆盖其他人的代码。持续集成工具是测试构建的版本是否正确的一种协作形式。
每一种形式的协作都有各自的成本和收益。同步协作需要安排日程，潜在地需要出差。花在同步协作上的时间对每个人来说都是成本。同步协作的收益包括：参与其中的人马上就能对问题的解决做出贡献。同步协作的其他成本和收益取决于通信带宽、时差、协作的持久性。每一种协作形式都可以根据成本和收益进行分析。
理想的协作机制的特点是，从是否有延迟、需要做的准备工作以及人们的时间这几方面讲，是低成本的，从所有相关干系人的协作的可视性、快速解决问题、有效交流所需信息这几方面讲，是高收益的。
前面提到的维基百科对DevOps的定义说明了DevOps过程的特征是，“交流、协作与融合”。根据我们对协作的讨论，可以看到有太多的人工交流与协作，特别是同步协作，让DevOps的快速推向市场的目标无法实现。
1.6.2 团队协作
团队协作机制有两种类型——人工过程和自动过程。DevOps人工过程取自敏捷过程，目的是用于持久性不高的高带宽协作。站立会议和信息发射源是人工过程协作机制的两个例子。
自动化团队协作机制的目的是保护团队成员不受自身或其他活动的干扰（版本控制和配置管理系统），用自动化方式完成重复单调的任务（持续集成和部署），加快发现并报告错误的速度（自动化单元测试、集成测试、验收测试和现场生产测试）。目标之一是尽可能快地向开发人员提供反馈。
1.6.3 跨团队协作
再次检查发布过程活动可以清楚地看到跨团队协作是一个最耗时的因素。必须在客户、干系人和其他开发团队以及运维人员之间协作。因此，DevOps过程试图尽量减少这种协作。从开发团队的角度看，有3种类型的跨团队协作：与干系人和客户的上游协作；与运维人员的下游协作；与其他开发团队的交叉流协作。
服务所有者的角色是进行上游协作。下游协作是通过把很多运维职责转移到开发团队来完成的。我们现在重点关注跨团队协作。开发团队之间需要协作的原因有两个——一是确保一个团队开发的代码能够与其他团队开发的代码很好地一起工作；二是避免重复工作。
1）让程序段能够融合在一起工作。支持不同的开发团队独立工作并简化这些工作的集成过程的方法之一是有一个软件架构。正在开发中的系统，它的架构将有助于各部分融合在一起工作。其他协作也仍旧是需要的，但是架构发挥了协作机制的作用。架构说明了创建整个系统的一些设计决策。其中的6个设计决策为：
a.职责分配。在DevOps过程中，在架构中说明概要职责，但具体职责是在每个迭代开始时确定的。
b.协作模型。协作模型描述了架构的不同组件在运行时是如何协作的。所有元素都使用一个协作模型，这样在协作模型之间就不需要再协作了。
c.数据模型。与职责分配一样，数据模型对象及其生命周期是在架构中说明的，但是可以在迭代开始后再细化。
d.资源管理。将要管理的资源是由架构决定的。对这些资源的限制（例如，缓冲区大小或线程池大小）可以在迭代开始时或者通过在架构中说明的系统范围的策略来决定。
e.架构元素之间的映射。如果在架构以及分配给团队的工作中说明了这些映射关系，团队之间需要最少的协作。在第4章中，在讨论使用DevOps过程开发的系统的架构风格时，我们会再次回到这个主题。
f.绑定时决策。这些是在整体架构中指定的。很多运行时绑定值（running binding value）都将通过配置参数指定，我们将在第5章讨论配置参数的管理。
2）避免重复工作。避免重复工作并鼓励复用，是不同开发团队之间协作的另一个理由。DevOps实践从根本上认为，为了缩短投向市场的时间，重复工作是必需付出的成本。有两个理由。首先，每个团队必须完成的任务都很小，重复工作量也很小。潜在的大面积的重复，例如每个团队都创建自己的数据存储，可以通过架构解决。其次，每个团队都负责自己的服务，在部署后如果自己团队编写的代码出现了问题，那么排除障碍较快，并且避免了把问题升级到其他团队。
