建立云原生组织的8个要素

让用户更开心，让业务更成功，为社会创造更多价值，用科技让生活更美好，是科技企业发展的核心目标。我们暂且把该目标简单的表示为 Business KPIs。

过去十年，随着云计算的发展，云原生技术架构逐步被更多的科技企业采纳和应用，主要体现在持续交付（continues delivery）、微服务和容器化（containerization）、构建可观测系统（building observable system）等等方面。在这个过程中，在组织架构上，也发生了相应的一些变化，主要体现为传统架构中，规模庞大的集中化职能团队，逐步打散后重新组合为更小更敏捷、相互独立的闭环应用开发团队（application development team），其作为一个个独立的 feature team，就着某个目标，快速迭代和验证，和业务一起为努力达成 Business KPIs 增砖添瓦。在这个看似自然而然的转变背后，却需要有着强大的「配套技术支撑」。

那么在云原生时代，如何架构技术团队，搭建好该「配套技术支撑」呢？本文将会从以下几个方面来阐述。

首先要从企业发展目标出发，明确好技术团队承担的角色

虽然在当下，技术分工越来越细，有负责 coding 的，有负责 CI/CD 的，有负责 infra 的，有负责 monitoring 的，有负责 chaos 的，等等，但是归根结底，作为技术团队，为了协同业务达成 Business KPIs，核心价值不外乎提炼为：如何把用户需要的、对用户有用的功能，更快地提供给用户，并保障这些功能稳定的工作，同时在这个持续迭代的过程中，通过软件工程等方法提升效率，进而降低成本。

所以，最基本的，搭建云原生的「配套技术支撑」，就可以转化为以下三个具体问题：

• 如何支持业务更快的迭代；
• 如何保障业务平稳的运行；
• 如何通过软件工程方法论和实践（software engineering principles），持续提升自动化水平，以降低成本；

其次，技术团队要和业务建立有效的对话体系

这是很多技术 lead 和团队，最常困扰的问题之一，如果不加以重视和积极寻求解法，最后往往以业务方不懂技术、以及技术团队要有技术追求为台阶，双方渐行渐远，导致业务不理解技术团队的规划和升级，进而不能给予资源尤其是人力的支持，接下来的技术改造升级举步维艰。大家都知道，软件系统是一个熵增的环境，如果没有持续的技术投入，对其进行升级改造，那么最终有一天，系统的复杂度量变引起质变，此时反过来会影响到业务的发布迭代速度和质量，严重者甚至于造成新功能迭代停滞。

建立有效的对话体系，核心要把握以下两点：

1. 统一目标：技术团队和业务，目标是统一的，都是为了同样的 Business KPIs，在技术范畴内，解决「如何把用户需要的、对用户有用的功能，更快地提供给用户，并保障这些功能稳定的工作」。
2. 统一语言：统一了目标之后，要说双方都听得懂的话。从用户的视角出发，建立数字量化体系，就是一个不错的主意。譬如我举几个例子，来说明：
   • 每个月内，每完成一笔购物的订单，在 infra 层面所花费的费用。// 用该指标可以有效的按月度量资源的使用效率。
   • CI/CD 工作流每天能够支撑 200 次线上的发布迭代，且用户满意度高于 8 分。// 该指标可以有效度量迭代支撑效率。
   • 电商交易系统，一个季度的服务不可用时长，不超过 13 分钟，其中「服务不可用」指无法完成正常交易的订单数量损失超过 10%。// 用该指标可以有效的度量核心系统的季度稳定性。
   • 终端用户访问网站，并返回正确数据的延时，其 95 分位小于 500ms。// 用该指标可以有效的表示网站的访问体验。

最后，一个云原生的技术团队架构可以抽象为以下 8 个要素

1. 三大团队：应用开发团队、平台团队、可靠性保障团队
2. 两套指标体系：Business KPIs、Service Level Objectives
3. 三个指导思想：Devops、GitOps、IaC

平台团队（Internal Developer Platform Engineering Team，简称 IDP 团队）

旨在建立一个服务于「应用开发团队」的平台（简称 IDP 平台)，通过软件工程的方法，帮助应用开发团队，加快应用的发布速度。IDP 平台以产品的形式，提供给用户自助使用（self service）。此外，IDP 平台既然是一个产品，那么就要考虑用户的需求、用户的满意度、用户的上手学习曲线、用户的教育等工作，这虽然会带来一定的工作量，但是长期来看，通过产品赋能研发团队，效率远远高于人工支持的效率。

可靠性保障团队（SRE）

是一个横向团队，通过软件工程的方法，提供可靠性保障的工具和产品，协同「应用开发团队」、「平台团队」一起，构建可靠运行的系统。SRE 可提供的兵器库中有 SLO，有 monitoring，有 incident management，有 failure mitigation 等等。

应用开发团队（Application Development Team）

是平台团队最主要的用户，在企业内部，会有很多这样的 feature team，应用开发团队的总人数也是最多的，和平台团队、SRE 团队的人数比例可能会达到 20 比 1，或者 50 比 1 的水平。

Business KPIs

是业务和技术团队的最根本的共同目标，当然承担的比重不同，对于 Business KPIs，自上而下不同团队承担的比重依次下降。

SLOs（Service Level Objectives）

SLO 在 Google SRE Book 中有详细的阐述，是 SRE 兵器库中，最重要的兵器之一。SRE 团队通过定义 SLO，以及围绕 SLO 搭建相关的稳定性度量和保障系统，搭建工作流，有效的拉齐了 SRE 团队和业务团队、应用开发团队、平台团队在服务可靠性保障工作上的认知。当然，对于 SLOs 的投入精力比重，在各团队中也是不一样的，自上而下，比重依次增加。

DevOps

旨在打破 Development 和 Operation 之间的壁垒，职能双方一起紧密配合构建高度自动化和高度可靠的复杂系统。具象来讲，DevOps 可以看作是一种对 Site Reliability Engineering 的最佳实践集合。

GitOps

聚焦于应用发布（Application Delivery），缘起于解决针对 Kubernetes 集群管理和其上应用发布的问题。声明式的配置、版本化管理、高度 pipeline 自动化是 GitOps 的典型特征（GitOps 是 infrastructure as code 在 Kubernetes 生态下的一种演变）。GitOps 有助于保障配置变更的可审计、可重复、一致性。实际落地中来讲，GitOps 可以看作是 Platform Engineering 的最佳实践集合。

IaC (Infrastructure as Code)

是通过代码，以软件工程的方式（而非手动流程）来管理基础架构的方法。自动化、可审计、可重复运行、一致性，都是 IaC 的显著特点和优势。利用 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）：从业务视角出发，建立自上而下、层层下钻的故障处理模型；
• 加强信息协同处理：将数据收集、数据分析的工作自动化和可视化；
• 最佳实践 + 数据 + 算法：实现特定场景的智能辅助决策；

参考资料

• 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/