前言构建基于DevOps的DevOps平台体系，需要深刻理解DevOps的目标，明确DevOps体系中的能力和职责，设计适合自己实际情况的DevOps组织。只有这样，生产关系才能适应新的生产力要求，促进企业生产效率的提高。开发最终依赖于运营团队的敏捷响应能力。如果运维不能敏捷，那么敏捷开发对整个应用生命周期的价值就没有那么大了。但是运维通常追求稳定，不能改就不改，因为每一次变更都面临着不确定性和意想不到的异常，影响性能、评估、客户满意度。因此，需要通过合理的组织和职责设计来平衡运维和研发的利益，在保证业务稳定性的同时，通过自动化工具和自助服务来提高运维的敏捷性，以匹配敏捷响应研发要求。理解DevOps的目标DevOps是一种思想、理念和方法论，建立在其上的工具、平台、组织、应用系统等都是这个DevOps体系的一部分。DevOps的目标是平衡开发效率和稳定运维之间的利益分歧。不仅要追求研发的敏捷变更和交付，还要保证运行环境和业务应用的稳定性和可靠性。因此，笔者在最初搭建容器云平台时，就强调“以应用管理为核心”，实现业务应用运行支撑环境的稳定可靠。只有这样，才能实现敏捷研发，保障可靠运维。为什么GoogleSRE强调站点可靠性？然而，国内所谓的DevOps平台大多只考虑交付流水线、指标控制等研发过程，这实际上偏离了DevOps的目标。研发再敏捷，如果运维不能敏捷稳定，一切都是白费。如何实现研发敏捷和稳定运行研发追求的敏捷交付和运维追求的稳定运行存在一定的矛盾。软件的好坏往往取决于研发人员的个人素质，但人的思维总是有限的，所以软件总会有缺陷。并不是说敏捷交付一定会带来缺陷，但不能保证不会带来缺陷。当不同的团队成员负责应用开发和运维时，环境的每一次变化都可能带来意外和异常。所以，对于运维人员来说，不改是最好的选择。人们有一种避重就轻的本能倾向，这也是很多公司的业务启动流程非常复杂的原因之一。只有理顺彼此之间的关系，化解矛盾，才能实现敏捷的研发和稳定的业务运营。就像GoogleSRE一样，可以在业务应用稳定运行之前由开发者维护和运维。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组织可以从服务层面进行设计和划分，如基础设施资源运维团队、平台环境运维团队、应用生命周期管理团队（可进一步分为应用开发、应用测试、维护等团队）和业务运营团队（businessteams）。基础设施资源运维团队基础设施资源运维团队的主要职责是保证服务器、虚拟机、网络、存储等资源的稳定运行和供应。可以通过统一的资源管理平台或多云管理平台，为上层平台、中间件工具等提供资源服务。比如虚拟机服务、GPU服务、网络IP服务、网段服务、NAS存储服务、对象存储服务等等。这些资源需要构建成可复用的资源池，按需使用，这其实就是云计算的思想。至于与传统网络域划分的冲突，可以通过对上层透明的能力封装来解决。平台、工具、环境运维团队平台主要指容器云平台、容器化PaaS平台等应用运维支撑平台；工具是指Kafka、ES、Redis、MySQL等中间件；基于这些平台工具的环境和其他开发、测试、生产等环境。这些由运维团队管理和维护。为应用研发团队提供平台服务、工具服务、环境服务。这些服务能力其实就是企业想要构建的中台服务能力，被各个业务复用和共享。由于工具平台较多，每个工具平台可能需要相应的运维人员负责，因此平台工具和环境运维团队可能需要根据实际情况组建，可以分为几个小团队，或者作为一个大的团队，如基于容器云平台的监控、日志、鉴权、权限、消息、缓存、安全等，组成一个统一的平台服务团队。应用运维、测试、开发团队参与应用生命周期过程的开发、测试、运维等职责。DevOps提倡开发运维一体化（不是开发和运维都做），将开发和维护作为一个整体来考虑，实现应用生命周期的平滑闭环：持续集成、持续部署、持续交付、持续监控，持续反馈。这个生命周期过程需要应用运行平台、中间件工具和运行环境的支持。应用开发、测试和运维不需要关心基础设施资源、平台、工具和环境搭建，只管使用，类似于SaaS服务，会简单很多。SRE在应用稳定运行后接手运维，让研发人员有更多的时间做业务研发，解决了研发人员关键能力的释放问题。研发团队可能不止一个，业务研发团队可能有很多，运维团队可能没有那么多。一般来说，研发和运维团队还是可以职责分离的。业务运营团队业务运营团队也就是业务团队，利用运行中的业务应用系统服务于终端客户。使用过程中遇到的问题可以方便的反馈给应用研发团队，及时改进和改变，形成闭环，持续提升客户体验和客户满意度。总的来说，DevOps组织设计需要深刻理解DevOps建设的目的和目标，合理设置DevOps组织职责，指导DevOps组织设计。通过分层赋能，明确职责分工，减少部门和团队之间的交互，形成交付使用反馈和评价的闭环，整个公司的DevOps组织架构相对清晰。每个团队负责满足其上层团队的需求并提供自助服务能力。基于使用反馈和评估，推动工具和能力的持续改进，提升效率，实现运维敏捷响应，匹配研发的敏捷性。王朝晖，中国银河证券架构师，专注于容器云、微服务、DevOps、数据治理、数字化转型等领域，对相关技术有独到的理解和见解。擅长软件规划设计，其“平台集成”观点越来越被事实所认可和证明。发表多篇探讨容器平台建设、微服务技术、DevOps、数字化转型、数据治理、中台建设等方面的技术文章，受到广泛关注和肯定。
