1.5 团队结构
本节讨论在承担DevOps职责的开发团队中，团队一般是多大规模，包含哪些角色。
1.5.1 团队规模
虽然不同的方法论推荐的准确团队规模是不一样的，但是大家都认为团队的规模应该相对较小。亚马逊（Amazon）有一个“两个比萨饼的规则”。即，团队规模应该是两个比萨饼就够吃。虽然这个规则本身有一点模糊（比萨饼有多大，团队成员有多饿），但是这个规则的意图很明确。
小团队的优势在于：
可以快速做出决定。在每次会议上参会者都希望表达自己的意见。参会者越少，表达的意见就越少，用来听取不同意见的时间也就越少。这样，与大团队相比，表达意见、统一意见的速度就快。
人少比人多更容易组成一个关系密切的群体。关系密切的群体是每个人都相互理解，并遵循为他们制定的同一套目标。
人们在小团队面前比在大团队面前更容易表达意见。
小团队的不利之处是较大的任务是少数几个人无法完成的。在这种情况下，这个任务只能拆细，每一部分分给不同的团队，各部分需要高效地融合在一起，这样才能完成一个大任务。为了做到这一点，团队之间需要配合。
团队规模成为整体架构的一个主要驱动因素。一个小团队需要完成一小部分代码。我们将会看到，围绕着一组微服务构建架构是一种好方法，它能够把这些小任务打包在一起并减少显式配合——所以我们把开发团队的输出成果称为“服务”。我们将在第4章讨论迁移到小团队驱动的微服务架构的方法及挑战，并在第13章中学习一个来自Atlassian的案例研究。
1.5.2 团队角色
我们从Scott Ambler对敏捷团队中角色的描述中挖掘两个团队角色。
团队领导。这个角色在Scrum中称为Scrum Master，在其他方法中称为团队教练或项目领导。他负责协调团队、获取资源、保护团队不受问题的干扰。这个角色包含了项目管理的软技巧，但是不包含诸如制定计划、安排日程这样的技术能力。这些活动最好留给团队作为一个整体去完成。
团队成员。这个角色有时候称为开发人员或程序员，负责系统的创建和交付。包括建模、编程、测试和发布等其他活动。
团队中执行DevOps过程的其他角色还包括服务所有者、可靠性工程师、看门人和DevOps工程师。一个人可以承担多个角色，一个角色也可以由多人承担。角色的分配取决于个人能力、个人的工作负荷以及这个角色所需的能力和工作量。我们将在第12章的案例研究中讨论一些采用DevOps和持续部署的团队角色的例子。
1.服务所有者
服务所有者在团队中负责外部协作。服务所有者参与系统范围的需求活动，安排团队工作内容优先级，向团队提供来自团队服务的客户信息和提供给团队的关于服务的信息。下一个迭代的需求收集和发布计划活动与当前迭代的概念阶段是可以并行的。这样，虽然这些活动需要协作与时间，但不会延缓交付时间。
服务所有者维护并与其他人交流服务的愿景。每个服务相对都较小，愿景包含了解团队服务所面向的客户以及团队服务所依赖的服务。即，愿景包括了整个系统的架构以及这个架构中每个团队的角色。
对服务所有者的一个关键要求是：既能与其他干系人交流，又能与团队的其他成员交流。
2.可靠性工程师
可靠性工程师有多个职责。首先，可靠性工程师在部署完成之后立即就要对服务器进行监控。这可能包括使用金丝雀测试集（对最少节点的现场测试）和取自服务的各种不同的指标。本书后面将更详细地讨论这两个概念。其次，可靠性工程师是服务执行期间出现问题后的联系人。这意味着对于高可用性服务，他需要随时待命。在Google，这个角色称为“现场可靠性工程师”。
在出现问题后，可靠性工程师执行短时间分析以诊断、缓解及修复问题，通常会借助于自动化工具。这可能是在压力非常大的情况下做的（例如，在深夜或是浪漫的晚餐时间）。问题还可能涉及其他团队的可靠性工程师。不论何种情况，可靠性工程师都必须出色地排查故障、诊断问题。可靠性工程师还必须深入理解服务的内部，这样才能修复故障或者采用临时解决方案。
除了短时间分析之外，可靠性工程师还应当发现或者与团队一起发现问题的根本原因。“5个为什么”（5 Whys）是一个确定根本原因的技巧。不停地问为什么，直到发现原因。例如，部署的服务很慢，直接原因是负载量意外激增。第二个“为什么”是什么因素造成了意外激增，以此类推。最终，答案是服务的压力测试未包含适当的负载量特性。这个原因可以通过提高压力测试的负载特性而修复。可靠性工程师需要逐步成长为有能力的开发人员，因为他们需要编写高质量的程序并且以自动化的方式实现不断重复发生的诊断、迁移和修复工作。
3.看门人
Netflix使用图1-3所示的从本地开发到部署阶段的步骤。
图中每个箭头都表示进入下一步的决策。这个决策可以自动实现（Netflix的做法），也可以手动实现。在部署流水线中，决定将服务进入下一步的手动角色称为看门人角色。看门人决定服务的某个版本或服务的某个部分是否能够通过“门”并进入下一步。看门人可以依赖于详尽的测试结果，使用一个检查表做出决策，也可以与其他人商量，但是代码或服务是否允许进入部署流水线的下一步，这个职责最终落在看门人身上。有时候，在部署到生产环境之前，原来的开发人员成了看门人，根据得到的测试结果做出决定，但是对此负全部责任。在金融行业中，按照监管要求，可能需要有看门人（但不是原来的开发人员）。
图1-3 Netflix部署到生产环境的路径（改编自http://techblog.netflix.com/2013/11/preparing-netflix-api-for-deployment.html）[标注法：业务流程建模标注]
Mozilla有一个叫作发布协调人的角色（有时称为发布管理员）。这个人要承担协调整个发布的职责。这个发布协调人参加决定发布包含或不包含哪些内容的仲裁会议，了解发布中包含的所有工作的背景和环境，对缺陷严重程度定级过程中存在的争议进行仲裁，可以批准最新添加的内容，可以做出取消的决定。此外，到了最后的发布日，发布协调人是开发人员、质量保证人员（QA）、发布工程师、网站开发人员、公共关系人员和市场人员之间的所有交流的汇聚点。发布协调人就是一个看门人。
4. DevOps工程师
再次检查图1-2，看看这个过程中工具的使用。有些工具是代码测试工具、配置管理工具、持续集成工具、部署工具或部署后的测试工具。
配置管理不仅适用于服务的源代码，而且适用于各种工具的输入信息。这可以让你了解诸如“在上一次部署和这次部署之间有什么变化？”“上一次构建之后增加了什么新的测试？”之类的问题。
工具在进化，工具需要专业知识，工具需要专门的信息输入。DevOps工程师的角色负责DevOps工具链中使用的各种工具的护理和保养。这个角色可以是个人、团队或组织层面。例如，组织可能决定所有人都应该使用某个特定的配置管理工具。团队仍旧需要确定分支策略，每个开发人员可能需要进一步创建分支。需要有关于命名及访问的策略，并且可能是自动强制实施的。选择开发团队使用的配置管理工具的哪个发布是DevOps工程师职责的一部分，为开发团队定制工具并监控开发人员是否正确使用也是DevOps工程师的职责。以自动化方式实现开发和部署流水线是DevOps工程角色的固有职责。这个角色必须存在并有人填补，至于这个角色在组织或团队结构中如何体现，是另一个问题。
