DevOps 文字培训

应如何组建 DevOps 组织并设计软件架构？

根据康威定律，设计系统的组织所能构建的系统，必然映射出其自身的沟通结构。换句话说，团队的沟通与互动效率决定了软件能够达到的水平。因此，组建团队的方式必然会影响软件架构、IT 绩效，最终也会影响业务表现。

组织结构决定你会得到什么样的软件

大多数企业，很可能也包括你的企业，会将软件交付组织划分成若干团队，最后构建出层数与团队数完全相同的软件架构。受控实验也证明，让一个由 6 支团队组成的组织构建软件，他们会设计出 6 层架构。让另一个由 3 支团队组成的组织开发完全相同的软件，他们会设计出 3 层架构。实际上还有许多类似例子。

一家在全球拥有 86,000 名员工的知名保险公司，在负责交付客户、合同、发票及服务管理后端的一个 IT 组织中，恰好设有 2 个主要职能团队。其中一支负责 Java 编程，另一支负责 PL/SQL 存储过程。此外，他们还依赖全组织统一的 IT 运维、数据库管理、IT 基础设施、IT 网络、IT 安全和 IT 质量保证服务台，这进一步增加了安全交付软件的难度。

这个组织的另一个难题是，尽管团队彼此分开，他们却无法在架构中有效分离 Java 的业务编排逻辑和 PL/SQL 的数据访问逻辑。他们交付了数百项功能，每项功能都把 Java 和 PL/SQL 代码缠在一起。因此，每项变更和新功能请求都需要在团队之间交接数十次。即使是小改动，也会造成排队和漫长的前置时间。此外，在如此复杂的环境中，即便很小的变更也难以预见其整体影响。他们不断破坏生产环境的现有功能并造成停机，解决这些问题又需要很长时间，带来返工、逐级上报和压力。

为改变这种工作方式，两支职能团队合并为一支产品团队。他们逐步重新设计软件，将数据访问层改造成一组 API 函数。此外，他们构建了一套新的业务系统，使其与数据访问 API 的内部工作方式完全解耦。计划尚在早期就提高了团队士气，因为 Java 和 PL/SQL 专家开始共同为产品团队的成功努力，而不再受各自原有职能部门的利益驱使。构建松耦合架构后，变更的影响更容易确定，变更更容易且更快实施，缺陷也更容易定位和修复。结果，新功能的平均前置时间从 4 个月缩短到 3 周，团队的待处理事件队列如今几乎为空，可以利用腾出的时间进一步审查、重构并改进代码库。

矩阵式组织、职能团队与成本优化的错觉

企业由若干职能团队组成，分工涉及数据库、网络、运维、信息安全、质量保证、发布管理、项目管理、产品管理等专业领域。项目团队由来自不同职能部门的人员组成。在这些尝试交付业务产品与服务的矩阵式项目组织中，项目经理通常负责确保有成果交付，而产品经理负责确保交付的是正确的成果。

这种组织结构的问题在于，职能团队对自己所参与工作的整体范围几乎或完全不了解。在极端却常见的情形下，职能团队既不关心全局，也不关心其所参与的产品与服务对 IT 和业务的总体产出。他们只关心出了问题、大家开始相互指责时，自己是否会被追责。

职能团队通常要处理很长的工单队列，因此往往需要很长时间才能为你的项目提供支持。各项目都在争夺职能资源，想让自己的项目尽快受到重视，就只能向上级反映。不断向上反映问题显然会损害工作氛围及团队间的信任。

多次跨团队交接、延误、质量问题、返工、瓶颈和压力，如今已经成为日常工作的一部分。只要矩阵式组织仍一味追求不透明而虚假的成本优化，就很难有更好的表现。事实上，考虑到质量问题、返工和延误，按职能组织的成本可能比你能想到的其他任何重组方式还要高。如果组织还把质量保证和 IT 运维等关键职能外包给地理位置遥远的团队，IT 组织恐怕只能勉强维持安全交付，满足对业务连续性至关重要的需求。

这确实是个大问题。DevOps 如何解决？答案是组建面向产品和服务的团队

为解决这个问题，DevOps 建议从职能团队的成本优化错觉，转向已证实有效的 DevOps 交付速度优化。事实上，只要做法得当，你和团队在快速持续交付的同时，也能节约成本。

DevOps 建议组建面向产品和服务的团队。这些团队相互独立、具备跨职能能力、能够自主开展工作，通常规模较小。它们负责某项产品或服务（并非临时项目）的整个软件工程生命周期，包括架构设计、详细设计、编码、测试、实验、部署、运维和维护。没错，你没有看错。还有谁能比软件的创作者更好地运维和维护它？当然没有。因此，Amazon 和 Netflix 最成功的 DevOps 团队发布产品和服务后不会撒手不管，他们也负责在自己的生产系统中运维和维护软件。

组织将资金从临时项目转向产品和服务

为了促进业务发展，组织不再为长期业务成果难以评估的临时项目拨款。采用 DevOps 后，组织将资金投入自身使命、宗旨及相关的产品和服务。现在，团队是否成功取决于其 IT 和业务绩效，具体体现为在相应业务领域中，为内部和/或外部客户提供产品、服务与微服务的投资回报。现在，你的团队像自己创建并提供的产品和服务的负责人一样开展工作，不再只是很少关注业务成果的职能部门成员。

如何组建 DevOps 团队和构建软件架构？

DevOps 当然不建议一次性打乱并重组组织内的所有在建项目。可以将各领域的职能专家安排到项目团队中，这是一种既不会造成干扰又能产生实际影响的适应 DevOps 的方法。有了质量保证、信息安全、数据库、网络、服务器、运维等领域的专家后，就可以期待团队自主设计、部署和维护软件产品与服务。

在新组建的产品和服务型 DevOps 团队中，可用性、质量、性能、信息安全和合规是每个人的日常职责。如果团队等到设计和开发完成才关注这些非功能性需求，怎么可能构建高可用、安全、优质，且能应对客户所需压力和负载的软件应用？如果外部专家没有参与产品和服务的软件工程各阶段，他们又能多准确地判断和验证应用的安全与质量？因此，高绩效 DevOps 团队只向外部领域专家寻求咨询，并在软件工程生命周期的各阶段对所有非功能性需求负全责。

还有一种可考虑的做法

Google 是一个取得极大成功的 DevOps 组织，至今仍大量采用职能团队，并将其与面向产品和服务的 DevOps 团队结合起来。在 Google，DevOps 团队和职能团队都将通过产品和服务实现组织使命视为共同目标。职能团队构建蓝图（如模板、核对清单、应用骨架等）及自助系统（例如让其他团队独立预配和配置服务器与网络），确保不会成为拖慢 DevOps 产品和服务团队的瓶颈。Google 的职能团队在软件工程生命周期早期就与产品和服务团队协作，为他们提供支持，建设性地对设计、代码和测试进行同行评审，并持续提供咨询。

DevOps 团队应该有多大？

DevOps 团队的理想规模是 5 至 10 人。这么小的规模可以降低团队内部沟通和协调的复杂性，也让团队负责人和成员不必在杂务和管理工作上耗费太多时间。这也将团队负责的产品和服务限制在一定规模内，进一步降低应用的复杂性、维护和运维难度。小团队的每个成员都能看到全局，也都能通过参与组织的重要使命积累一些领导经验。团队负责人与高层管理人员合作，理解各项目标，并向团队成员传达。

如果一支不超过 10 人的团队已无法负责产品和服务，该怎么办？

可以拆分出新的产品和服务，再组建另一支 DevOps 团队接手。产品和服务也可以面向内部客户，不一定是向付费的外部客户提供。你完全可以为内部客户开发内部产品、服务或所谓的“微服务 API”，并组建相应的 DevOps 团队。例如，如果计费系统变得过于庞大，一支不超过 10 人的团队难以处理，就应拆分出另一支 DevOps 团队接手数据库访问 API。还可以再组建团队接手在线支付 API，或另建团队接手批处理流程。当然，所有这些团队都应使用共用的代码存储库和统一的部署流水线，以确保持续集成、快速交付和组织的成功。

你已经知道，在紧耦合架构中，一个应用中的小改动最终可能给众多工作流带来不良影响。因此，架构中的产品、服务和微服务 API 必须保持松耦合。每个 DevOps 团队应只负责松耦合架构的一部分，并能独立设计、开发和部署自己的软件。部署流水线内置的早期预警机制应自动、迅速地通知 DevOps 团队，告知每次代码提交可能造成的不良影响。

不超过 10 人的小团队如何独立完成从架构到运维的软件工程生命周期各阶段？

为此，应鼓励团队中的每个人都成为通才，并鼓励和帮助他们持续培养新技能。

无论当前专业知识和经验水平如何，都只应聘用渴望学习和成长的团队成员。应坚决避免聘用希望按一组固定角色和职责接受考核的人。你已经知道，组织、产品和服务都不会一成不变。

就算需求今天不变，明天也会变化。

总结

本章介绍了矩阵式组织及其职能壁垒带来的不良结果，以及 DevOps 如何解决这些问题。

DevOps 建议组建不超过 10 人的小团队，每支团队面向特定产品、服务或微服务 API。

这些 DevOps 团队应由全栈软件工程通才组成，能够独立覆盖从设计到维护的软件工程生命周期各阶段。

DevOps 依赖松耦合的面向服务架构（SOA），每支 DevOps 团队负责并运维其中的一部分。