9.7 融数数据面向微服务的研发团队介绍
要想成功地实施微服务架构，仅仅有服务框架、开发平台及 DevOps 平台是不够的，组织和文化也需要适应微服务的需求。根据康威定律，架构由组织决定，因此需要对团队的文化及组织划分结构进行调整。
融数根据 two-pizza team 的原则，按照业务来划分研发团队，建立全栈小团队，从而提高沟通效率、降低沟通成本，具体的团队策略如图 9.15 所示。
将团队切分后，我们按照业务线对组织进行架构规划，以便技术团队能够专注于解决对应业务问题（业务驱动，或者说业务优先）。这时，团队内部的设计决策将在团队内部消化，因为团队的规模已经是 7+/-2 人的量级，因此一般情况下不会对于团队内成员来说过于复杂的工作。但团队增多后，团队的协调将是一个问题，因此微服务从技术上帮助团队将负责的系统解耦，而计划流程会帮助团队在工作安排上找到合理的步骤。那么，虽然当一个大的业务被分解到各个小团队时，还是会有跨团队的设计工作，但是以上两点是要严格执行的。技术团队和业务团队的合作并非经由上层协调，双方的主要沟通都是团队之间直接进行水平沟通，也就是说，在底层的团队之间，需求、问题和日常交流都直接由业务团队反馈给技术团队的经理，而解决问题时容许业务团队直接接触开发人员，如图 9.16 所示。
我们在团队中强调以结果为导向的工作方式，如图 9.17 所示。
团队成员要有主人翁意识。团队的利益就是个人的利益，团队的成功才是个人的成功，团队成员之间要相互帮助和补位，不允许存在“事不关己，高高挂起”的情况出现。
在团队中，成员可以发表意见，也可以抱怨，但是不能只停留在语言层面，大家需要行动起来，找到解决问题的方法；我们希望每个开发人员都参与架构设计，而不是仅由架构师决定；我们还强调不要过度设计，鼓励通过抽象和简化解决问题，当然也鼓励引入新技术，但前提是能够有足够的掌控力而且不影响系统稳定。
软件工程师负责需求调研、设计、开发、测试、部署、维护、监控、功能升级等一系列的工作，也就是说软件工程师负责应用或者服务的全生命周期的所有工作。运维是团队成员的第一要务。在强大的自动化运维工具的支撑下，软件工程师必须负责服务或者应用的 SLA。
在团队中引入 oncall 机制，强调保障处理及时性，并引入卓越运维的思想，用数据统计每个团队的线上故障、解决及时性，并逐步要求故障数量递减，通过强大的数据支持保证团队解决问题的 SLA，并逐步改善软件质量。
9.8 总结
DevOps 的推行是按业务来组织团队，团队包含设计、开发、测试、运维等人员，这样一方面可以有效减少服务内部修改所产生的内耗；另一方面，团队边界可以变得更为清晰。DevOps 实际是一种文化上的变迁，打破了传统开发与运维之间的壁垒，帮助组织形成从开发、测试到部署、运维这样一个全功能化的高效能团队。
