云原生组织的建设，不只是把应用迁移到 Kubernetes、引入微服务或上线 CI/CD 流水线。更本质的问题是：技术团队如何围绕业务目标重新分工、协作和度量，让用户更开心，让业务更成功，并持续为社会创造价值。我们暂且把这个企业发展的核心目标称为 Business KPIs。
过去十年，随着云计算的发展，云原生技术架构逐步被更多科技企业采纳，典型实践包括持续交付（continuous delivery）、微服务、容器化（containerization）和可观测系统（building observable system）。技术架构变化之后，组织架构也会随之变化：传统架构中规模庞大的集中化职能团队，会逐步被打散并重新组合为更小、更敏捷、相互独立的闭环应用开发团队（Application Development Team）。
这些应用开发团队通常以 feature team 的方式围绕具体业务目标快速迭代、快速验证，和业务一起推动 Business KPIs。但这种变化不是自然发生的，它背后需要一整套云原生时代的配套技术支撑。
核心要点摘要
- 云原生组织建设要先从 Business KPIs 出发，而不是从工具、平台或团队名称出发。
- 技术团队的核心价值可以归纳为：更快交付用户需要的功能，保障功能稳定运行，并通过软件工程方法持续降低成本。
- 技术团队和业务团队需要建立统一目标、统一语言的对话体系，避免技术规划和业务诉求脱节。
- 一个云原生技术团队可以抽象为 8 个要素：3 类团队、2 套指标体系、3 个指导思想。
- 平台团队、SRE 团队和应用开发团队之间的协作机制，决定了 DevOps、GitOps、IaC、SLOs 等实践能否真正落地。
建立云原生组织，先回答三个问题
虽然当下技术分工越来越细，有人负责 coding，有人负责 CI/CD，有人负责 infra，有人负责 monitoring，有人负责 chaos，但归根结底，技术团队的角色不是为了完成某个局部职能，而是为了协同业务达成 Business KPIs。
从这个目标出发，技术团队的核心价值可以提炼为一句话：
如何把用户需要的、对用户有用的功能，更快地提供给用户，并保障这些功能稳定地工作；同时在持续迭代过程中，通过软件工程等方法提升效率，进而降低成本。
因此，搭建云原生的配套技术支撑，可以转化为三个具体问题：
- 如何支持业务更快迭代？
- 如何保障业务平稳运行？
- 如何通过软件工程方法论和工程实践持续提升自动化水平，从而降低成本？
这三个问题决定了云原生团队不是单纯的基础设施团队，也不是单纯的运维团队，而是连接业务目标、工程效率和服务可靠性的组织系统。
技术团队要和业务建立有效的对话体系
很多技术 lead 和团队最常遇到的问题，是技术规划和业务诉求之间缺少有效对话。如果不重视这个问题，最后往往会以“业务方不懂技术”以及“技术团队要有技术追求”为台阶，双方渐行渐远。
一旦业务不理解技术团队的规划和升级，就很难给予资源，尤其是人力资源支持。接下来，技术改造升级就会举步维艰。
软件系统是一个熵增环境。如果没有持续的技术投入，没有持续的升级改造，系统复杂度迟早会从量变走向质变，反过来影响业务发布迭代速度和质量。严重时，新功能迭代甚至会停滞。
建立有效对话体系，核心要把握两点。
统一目标：技术和业务都服务于 Business KPIs
技术团队和业务团队的目标是统一的，都是为了同样的 Business KPIs。区别只是各自承担的职责不同。
在技术范畴内，团队要解决的是：如何把用户需要的、对用户有用的功能，更快地提供给用户，并保障这些功能稳定工作。
当目标统一后，技术改造、平台建设、稳定性投入、自动化建设才不再是孤立的技术追求，而是服务业务结果的工程手段。
统一语言：用用户视角建立量化指标
统一目标之后，还要说双方都听得懂的话。从用户视角出发，建立数字量化体系，是连接技术团队和业务团队的一种有效方式。
例如：
- 每个月内，每完成一笔购物订单，在 infra 层面花费的费用。这个指标可以按月度量资源使用效率。
- CI/CD 工作流每天能够支撑 200 次线上发布迭代，且用户满意度高于 8 分。这个指标可以度量迭代支撑效率。
- 电商交易系统，一个季度的服务不可用时长不超过 13 分钟，其中“服务不可用”指无法完成正常交易的订单数量损失超过 10%。这个指标可以度量核心系统的季度稳定性。
- 终端用户访问网站并返回正确数据的延时，其 95 分位小于 500ms。这个指标可以表示网站访问体验。
这些指标的共同点是：它们不是从某个技术组件出发，而是把技术能力翻译成业务、用户和组织都能理解的语言。
云原生技术团队架构的 8 个要素
一个云原生技术团队架构，可以抽象为以下 8 个要素：
- 三大团队：应用开发团队、平台团队、可靠性保障团队。
- 两套指标体系：Business KPIs、Service Level Objectives。
- 三个指导思想：DevOps、GitOps、IaC。
8 个要素总览
| 要素 | 类型 | 在云原生组织中的作用 | 主要服务对象或协作对象 |
|---|---|---|---|
| 应用开发团队 | 团队 | 围绕业务目标快速迭代和验证功能，是业务交付的核心单元 | 业务团队、平台团队、SRE 团队 |
| 平台团队 | 团队 | 以产品方式建设内部开发者平台，提升研发自助交付效率 | 应用开发团队 |
| 可靠性保障团队（SRE） | 团队 | 通过软件工程方法建设可靠性工具、产品和工作流 | 应用开发团队、平台团队、业务团队 |
| Business KPIs | 指标体系 | 作为业务和技术团队的共同目标，连接企业发展目标与技术投入 | 业务团队、技术团队 |
| SLOs | 指标体系 | 以服务可靠性目标拉齐业务、研发、平台和 SRE 的稳定性认知 | SRE 团队、应用开发团队、平台团队 |
| DevOps | 指导思想 | 打破 Development 和 Operation 之间的壁垒，推动自动化和可靠性建设 | 开发、运维、SRE |
| GitOps | 指导思想 | 聚焦应用发布和集群管理，通过声明式配置、版本化管理和流水线自动化提升一致性 | 平台团队、应用开发团队 |
| IaC | 指导思想 | 用代码和软件工程方法管理基础架构，提升自动化、可审计性和可重复性 | 平台团队、基础设施团队、应用开发团队 |
三大团队：应用开发、平台和 SRE
云原生组织不是简单地增加一个平台团队或 SRE 团队，而是要明确三类团队之间的关系。应用开发团队负责业务功能交付，平台团队负责提升交付效率，SRE 团队负责建设可靠性保障能力。
平台团队：用产品方式服务研发团队
平台团队，即 Internal Developer Platform Engineering Team，简称 IDP 团队。它的目标是建立一个服务于应用开发团队的平台，简称 IDP 平台。
IDP 平台通过软件工程方法，帮助应用开发团队加快应用发布速度。这个平台应当以产品形式提供给用户自助使用（self service），而不是长期依赖人工支持。
既然 IDP 平台是一个产品，平台团队就要考虑用户需求、用户满意度、上手学习曲线和用户教育等工作。这些工作短期内会带来一定工作量，但长期来看，通过产品赋能研发团队，效率远高于人工支持。
可靠性保障团队：用软件工程方法保障稳定性
可靠性保障团队通常对应 SRE 团队。它是一个横向团队，通过软件工程方法提供可靠性保障的工具和产品，并协同应用开发团队、平台团队一起构建可靠运行的系统。
SRE 可提供的兵器库包括 SLO、monitoring、incident management、failure mitigation 等。这些能力不是孤立工具，而是围绕服务可靠性目标形成的一整套稳定性保障体系。
应用开发团队：围绕业务目标快速交付
应用开发团队是平台团队最主要的用户。在企业内部，通常会有很多这样的 feature team。它们围绕具体业务目标进行功能开发、验证和迭代，是云原生组织里人数最多、离业务目标最近的团队。
在实际组织中，应用开发团队和平台团队、SRE 团队的人数比例可能达到 20 比 1，或者 50 比 1 的水平。正因为应用开发团队规模更大，平台能力和可靠性能力才必须尽可能产品化、自动化和自助化。
两套指标体系：Business KPIs 和 SLOs
云原生组织需要同时关注业务结果和服务可靠性。Business KPIs 解决“为什么做”的问题，SLOs 解决“服务可靠性如何被定义和度量”的问题。
Business KPIs：业务和技术团队的共同目标
Business KPIs 是业务和技术团队最根本的共同目标。不同团队对 Business KPIs 承担的比重不同，通常自上而下不同团队承担的比重依次下降。
这并不意味着技术团队可以脱离 Business KPIs。相反，技术团队越是投入平台、稳定性、自动化、工程效率建设，越需要说明这些投入如何支撑业务目标、用户体验和交付效率。
SLOs：拉齐可靠性认知的服务目标
SLOs，即 Service Level Objectives。SLO 在 Google SRE Book 中有详细阐述，是 SRE 兵器库中最重要的兵器之一。
SRE 团队通过定义 SLO，并围绕 SLO 搭建稳定性度量系统、保障系统和工作流，可以有效拉齐 SRE 团队、业务团队、应用开发团队、平台团队在服务可靠性保障工作上的认知。
不同团队对 SLOs 的投入精力比重也不同。对于越靠近可靠性保障职责的团队，SLOs 的投入比重越高。
三个指导思想：DevOps、GitOps 和 IaC
DevOps、GitOps 和 IaC 不是三个互相替代的概念，而是云原生组织在协作方式、发布方式和基础设施管理方式上的三类指导思想。
DevOps：打破开发和运维之间的壁垒
DevOps 旨在打破 Development 和 Operation 之间的壁垒，让双方紧密配合，共同构建高度自动化和高度可靠的复杂系统。
具象来讲，DevOps 可以看作是一种对 Site Reliability Engineering 的最佳实践集合。它强调协作、自动化和共同负责，而不是把开发、运维、稳定性保障割裂成彼此独立的职能孤岛。
GitOps：用版本化和声明式方式管理应用发布
GitOps 聚焦于应用发布（Application Delivery），缘起于解决 Kubernetes 集群管理及其上应用发布的问题。
声明式配置、版本化管理、高度 pipeline 自动化，是 GitOps 的典型特征。GitOps 也可以理解为 infrastructure as code 在 Kubernetes 生态下的一种演变。
GitOps 有助于保障配置变更的可审计、可重复和一致性。从实际落地角度看，GitOps 可以看作是 Platform Engineering 的最佳实践集合。
IaC：用代码管理基础架构
IaC，即 Infrastructure as Code，是通过代码、以软件工程方式管理基础架构的方法，而不是依赖手动流程。
自动化、可审计、可重复运行、一致性，都是 IaC 的显著特点和优势。利用 IaC，团队可以创建包含基础架构规范的声明式或命令式配置文件，便于编辑和分发配置，同时确保每次生成的环境都完全相同。
云原生组织的协作机制
把 8 个要素放在一起看，可以形成一条清晰的协作链路：
- 企业以 Business KPIs 明确业务目标。
- 应用开发团队围绕业务目标快速交付和验证功能。
- 平台团队通过 IDP 平台降低交付摩擦，提升研发自助效率。
- SRE 团队通过 SLOs、monitoring、incident management、failure mitigation 等能力保障服务可靠性。
- DevOps 改善开发和运维协作方式。
- GitOps 提升应用发布和集群管理的一致性、可审计性和可重复性。
- IaC 让基础架构管理进入软件工程流程，降低手动操作带来的不确定性。
这条链路的核心不是“技术越多越好”，而是每个要素都要回到最初的问题：能否帮助业务更快迭代，能否保障业务平稳运行，能否通过工程方法降低成本。
云原生组织的先行者
- Weave.works 被认为创造了 GitOps 的术语和理念。Continuous delivery for application teams and continuous control for platform teams. Automate Kubernetes with GitOps one pull request at a time.
- Terraform 是 Infrastructure as Code 领域的事实标准。Terraform is an open-source infrastructure as code software tool that provides a consistent CLI workflow to manage hundreds of cloud services. Terraform codifies cloud APIs into declarative configuration files.
- Flashcat 提供了针对 SLOs 系统性落地的解决方案，并围绕 SLOs 构建了一套实时、智能、统一的故障应急协同平台，结合 SRE 的最佳实践和方法论，帮助企业技术人员高效协同，从大量报警和异常事件中快速定位关键问题，降低服务中断时间。
关于 Flashcat
企业的 IT 技术分工越来越细，微服务让系统数量和相互依赖关系变得更多，服务架构也越来越复杂。各个技术团队通常只熟悉自己负责的系统，而当公司核心业务发生全局故障时，往往没有一个独立技术团队有能力、有足够的 Context，可以为此次 Incident 的处理全权负责。这会拉长故障止损的时间。
针对这种困境，企业需要在服务稳定性保障领域，通过产品技术和方法论层面的创新，找到系统性的应对方案。快猫星云推出的「Flashcat」解决方案，将其抽象为三步走的处理模型：
- 建立全面、实时的度量体系（Realtime Extend Service Level Objectives）：从业务视角出发，建立自上而下、层层下钻的故障处理模型。
- 加强信息协同处理：将数据收集、数据分析的工作自动化和可视化。
- 最佳实践 + 数据 + 算法：实现特定场景的智能辅助决策。
结论：云原生组织首先是协作系统，其次才是工具系统
建立云原生组织，不能只从工具或岗位名称开始。更可靠的路径，是先明确 Business KPIs，再定义技术团队如何支撑更快迭代、稳定运行和持续降本。
平台团队、SRE 团队、应用开发团队解决的是组织分工问题；Business KPIs 和 SLOs 解决的是目标和度量问题；DevOps、GitOps、IaC 解决的是协作方式、发布方式和基础设施管理方式问题。
只有当这 8 个要素围绕同一个业务目标运转，云原生技术架构才能真正转化为组织效率和服务可靠性。
FAQ
建立云原生组织应该先做平台团队，还是先做 SRE 团队？
应当先从 Business KPIs 和当前业务瓶颈出发判断。如果主要问题是应用交付效率低、研发依赖人工支持多，平台团队和 IDP 平台会更直接；如果主要问题是服务稳定性、故障止损和可靠性认知不一致，SRE 团队和 SLOs 会更关键。两者最终都需要协同，而不是彼此替代。
为什么云原生组织需要 SLOs？
SLOs 能把服务可靠性从抽象要求转化为可讨论、可度量、可协作的目标。通过 SLOs，业务团队、应用开发团队、平台团队和 SRE 团队可以围绕同一套可靠性语言展开协作，减少“稳定性到底做到什么程度才够”的认知偏差。
平台团队为什么要用产品方式服务研发团队？
应用开发团队通常数量多、规模大。如果平台能力主要依赖人工支持，平台团队很快会成为瓶颈。把 IDP 平台作为产品来建设，并提供 self service 能力，可以让应用开发团队更高效地完成发布、配置和交付相关工作。
DevOps、GitOps 和 IaC 有什么关系？
DevOps 关注开发和运维之间的协作方式；GitOps 聚焦应用发布和 Kubernetes 生态下的声明式、版本化管理；IaC 则关注用代码管理基础架构。三者分别对应协作、发布和基础设施管理，但共同目标都是提高自动化、可审计性、一致性和可靠性。
参考资料
- IDP, https://internaldeveloperplatform.org/
- SRE vs Platform Engineering, https://blog.getambassador.io/the-rise-of-cloud-native-engineering-organizations-1a244581bda5
- Implementing Service Level Objectives, https://learning.oreilly.com/library/view/implementing-service-level/9781492076803/
- weave.works, https://www.weave.works/technologies/gitops/
- Terraform, https://www.terraform.io/
- Flashcat, https://flashcat.cloud/
