DevOps 组织设计

前言

要基于 DevOps 构建 DevOps 平台体系，需要深入理解 DevOps 的目标，厘清 DevOps 体系中的能力和职责，设计适合自身实际情况的 DevOps 组织，这样才能让生产关系适应新的生产力的要求，促进企业生产效率的提升。

在《从 SRE 看 DevOps 建设》一文中笔者也提到过， DevOps 的重心在于运维而不是开发。开发最终依赖于运维团队的敏捷响应能力。如果运维做不到敏捷，开发的敏捷对整个应用生命周期来说，价值就没那么大。而运维通常追求的是稳定，能不变更就不变更，因为每次的改变都面临着不确定性，面临着意外异常，影响着绩效、评价和客户满意度。因此需要通过合理的组织和职责设计来平衡运维和研发的利益诉求，通过自动化的工具和自服务在保障业务稳定性的同时来提升运维的敏捷性，以匹配研发的敏捷响应需求。

理解 DevOps 的目标

DevOps 是一种思想、理念和方法论，以其来构建的工具、平台、组织、应用系统等都是这个 DevOps 体系的一部分。DevOps 的目标是平衡开发效率和稳定运维之间的利益分歧。既要追求研发的敏捷变更和交付，也要保障运行环境和业务应用的稳定与可靠。因此笔者在最早建设容器云平台的时候，就强调 “ 以应用管理为核心 ” 实现业务应用运行支撑环境的稳定和可靠。只有这样，才能实现研发的敏捷，保障运维的可靠。Google SRE 为什么强调站点可靠性？而国内大多数所谓的 DevOps 平台只考虑交付流水线、以及指标管控等研发过程，实和 DevOps 的目标有些背离。无论研发多么敏捷，如果运维做不到敏捷和稳定，一切都是徒劳的。

如何实现敏捷研发和稳定运行

研发追求的敏捷交付和运维追求的稳定运行之间是存在一定矛盾的。软件的质量往往取决于研发人员的个人素质，不过人的思维总是有局限的，所以软件总会有缺陷的。不是说敏捷交付一定会带来缺陷，但却无法保证不带来缺陷。在应用开发和运维由不同的团队人员来负责的时候，环境的每次变动都可能带来意外和异常，因此，对运维人员来说，不变动才是最佳的选择。人都有本能的避重就轻逃避倾向，这也是很多公司业务上线流程很复杂的原因之一。只有理顺了彼此的关系，解决了矛盾，才能实现敏捷研发和业务的稳定运行。如同 Google SRE 一样，可以在业务应用稳定运行之前由开发来维护和运维， SRE 只提供环境和工具支撑，这样开发导致的变更异常由开发负责。业务稳定运行之后交给运维来负责日常的维护。

研发的敏捷依赖于运维的敏捷响应

准确的说，研发的敏捷依赖于运维的敏捷响应。如果运维设置很多的流程和步骤，研发再怎么敏捷也没有意义。运维不只是应用运维，还有基础设施资源、安全、网络等，任何一个地方有阻碍，都会带来瓶颈和阻碍。比如说，应用的部署运行需要服务器、需要开通防火墙、需要配置 IP 地址、需要上线申请等，如果有一堆的流程需要申请审批，这个时间可能就需要好几天。在这几天里，研发可能已经迭代发布好几个版本了，但是发布再多的版本也无法及时更新上线，就是因为运维做不到敏捷响应。因此， DevOps 建设的关键是首先确保稳定的情况下实现运维的敏捷。这就需要消除团队之间协作的繁琐流程，合理设置 DevOps 团队，使运维支撑团队通过自服务能力来赋能上层团队，实现秒级 分钟级的响应能力。比如申请虚拟机，可能会涉及网络域、 IP 、网段、防火墙端口等，如果能实现自服务化，几分钟就可以完成虚拟机的申请、创建、配置和交付，会极大的提升效率。再者比如说应用的部署运维，通过容器化 PaaS 平台，自动调度匹配资源、自动弹性伸缩、自动故障恢复，用户无需关注服务运行在哪里，无需运维管理服务器，通过 PaaS 平台的可观测能力可以随时掌握应用的运行状况，通过 PaaS 平台的可管理能力随时进行应用的变更和配置调整。这就极大的提升了应用的敏捷性。

实现敏捷自服务，减少团队之间的交互

要实现敏捷，重要的一点是往往需要考虑团队之间的低交互。这就是为什么敏捷研发团队总是强调几人小团队的原因。DevOps 体系中涉及各个团队和众多系统和工具，总的团队规模是无法缩减的，那么要实现敏捷，减少团队之间的交互，就需要实现自服务的能力，赋能上层团队，使其实现自助（向上赋能 。在 DevOps 体系建设中，运维需要根据运维的职能职责进行分层，比如基础设施资源运维、平台工具运维、应用运维、业务运营等。基础设施资源运维为平台工具运维提供自服务的资源申请、扩容、维护能力；平台工具运维为应用运维提供资源服务、平台工具服务能力，比如通过容器云 PaaS 提供应用的托管、部署、运维自服务能力；而应用运维为业务运营团队提供应用服务，业务团队可以使用这些应用系统服务终端客户。

DevOps 体系职责设计

理解了 DevOps 的目标，来规划设计 DevOps 体系职责，作为划分定义 DevOps 组织的基础和参考。以标准化交付来衔接开发和运维，便于实现自动化的 CI 、 CD 流程；以基础设施资源、平台工具、应用运维需求进行分层，实现自服务，向上赋能；用 DevOps 全局、顶层视角来规划应用、工具、平台、资源、团队、架构等才能真正体现其价值。这有点类似于 PMO 的职责。

标准化交付、研发和运维自动化

DevOps 最重要的就是协调研发和运维的关系，满足彼此的诉求。通过标准化交付（比如镜像 ，实现研发和部署流程的自动化，无需开发和运维之间的沟通和交互。应用研发和应用运维可以是一个团队来完成，也可以是两个独立团队，共同完成应用生命周期管理过程。在这个过程中需要众多的工具和自动化能力的支撑，比如说异常、 bug 的反馈与修复等，使之成为一个应用生命周期管理闭环。

自服务赋能，分层实现向上支撑

在 DevOps 设计时，笔者一直强调分层，很重要的就是通过分层来厘清职责，实现自服务，向上赋能。这也是 DevOps 设计的重要参考。比如说笔者一直强调通过多云管理平台管理各种基础设施资源，给容器云平台提供各种资源服务、支持弹性伸缩、按需调度。传统运维几乎从服务器资源、网络存储配置、环境、数据库中间件、应用服务等什么都负责，是一种竖井的管理方式，难以实现敏捷的弹性和快速响应，也带来很多的冗余和浪费。通过分层自服务，封装了底层细节，实现共享和复用，也带来了效率。

全局架构、应用、服务规划团队

在设计 DevOps 组织时，笔者觉得最重要的一个团队是全局的规划团队。不止要做架构规划，也要考虑项目、应用、服务等规划，厘清项目之间的联系和关系，定义项目依赖性和优先级，明确团队之间的职责界线和需要提供的服务能力，构建企业可复用中台服务，提升复用效率。SRE 侧重于运维端的稳定性，没有从全局进行考量，不过做为初始的 DevOps 组织设计也无不可。但如果要真正理顺 DevOps 体系之间的关系，还是需要一个中心化的顶层设计团队来进行规划设计。

DevOps 组织设计

按照前面的讨论， DevOps 组织可以从服务层次上进行设计划分，比如基础设置资源运维团队、平台环境运维团队、应用生命周期管理团队（可再分应用研发、应用测试、应用运维团队等 及业务运营团队（业务团队 。

基础设施资源运维团队

基础设施资源运维团队主要职责是保障服务器、虚拟机、网络、存储等资源的稳定运行和供给。可以通过统一的资源管理平台 多云管理平台来为上层平台、中间件工具等提供资源服务。比如说虚拟机服务、 GPU 服务、网络 IP 服务、网段服务、 NAS 存储服务、对象存储服务等等。这些资源需要构建为可复用的资源池，按需使用，其实就是云计算的思想。至于和传统网络域划分冲突的问题，可以考虑通过能力封装来解决，对上层透明。

平台、工具、环境运维团队

平台主要是指应用运行支撑平台比如容器云平台、容器化 PaaS 平台等；工具指 Kafka 、 ES 、 Redis 、 MySQL 等中间件；环境等基于这些平台工具所构建的开发、测试、生产等环境。这些都是由运维团队来进行管理和维护。为应用研发团队提供平台服务、工具服务和环境服务。这些服务能力其实也就是企业要构建的中台服务能力，各个业务所复用和共享的。由于各种工具平台很多，每个工具平台都可能需要相应的运维人员来负责，所以平台工具及环境运维团队可能需要根据实际情况来进行设置，可以分成几个小的团队，也可以作为一个大的团队，比如基于容器云平台的监控、日志、认证、权限、消息、缓存、安全等形成一个统一的平台服务团队。

应用运维、测试、开发团队

应用生命周期过程中涉及开发、测试、运维等职责。DevOps 提倡开发运维一体化（并不是既做开发又做运维 ，将开发运维作为一个整体来考虑，实现应用生命周期的平滑闭环 持续集成、持续部署、持续交付、持续监控、持续反馈。这个生命周期过程需要应用运行平台、中间件工具、运行环境等的支撑。应用研发、测试和运维不需要去关心基础设施资源、平台、工具、环境搭建，只是使用，类似于 SaaS 服务，这样就会简单很多。SRE 在应用稳定运行之后会接手运维，让研发人员有更多的时间去做业务研发，这很好的解决了研发人员关键能力释放的问题。研发可能不止一个团队，可能有很多业务研发团队，但运维可以不必那么多。研发和运维团队总体上来说还是可以职责分开的。

业务运营团队

业务运营团队也就是业务团队，使用运行中的业务应用系统服务终端客户。在使用过程遇到问题能够便利的反馈到应用研发团队，及时改进变更，形成闭环，不断提升客户体验和客户满意度。

总的来说， DevOps 组织设计需要深入理解 DevOps 建设的目的和目标，合适和设置 DevOps 组织职责，指导 DevOps 组织设计。通过分层赋能，明确层次职责划分，减少部门和团队之间的交互，形成交付与使用反馈、评价闭环，整个公司的 DevOps 组织架构就相对很清晰。各个团队以满足其上层团队需求为己任，提供自服务的能力。基于使用反馈和评价，促进工具和能力的持续改进，从而提升效率，实现运维的敏捷响应，以匹配研发的敏捷。