为什么我们绕过SRE，直接转而投入平台技术

想象一下：你是一名SRE，被大量的直接消息淹没了。新的数据库、新的地理区域，甚至偶尔有人问“如何访问这个工具？”、“为什么这次构建失败了？”、“我可以有生产环境的权限吗？”（提示：不行！但请读到最后）。遇到生产问题了吗？SRE们迅速解决后就消失了。开发人员？一头雾水。

这在小团队里确实挺有用的。

以下是情况：开发人员编写应用程序，SRE 运行基础设施。我们监控仪表盘，搭建云资源和流水线，并提升基础设施的韧性……一种只有 SRE 才能懂的行话。它勉强算是运行吧。但我们开始壮大。开发人员数量猛增（20 倍！），而 SRE 的数量仅增加了 3 倍。我们看到了即将到来的风暴，超负荷的 SRE 和被卡住的开发。

每个请求都涉及需求收集、资源创建、测试和修复bug——这是一个耗时的过程，没有捷径。有限的人手意味着无法同时兼顾这些任务。

就像许多在基础设施领域工作的人一样，我们问自己这是否是我们的未来。
但是我们又希望未来会是怎样的呢？SRE 团队可以永久休假，而开发团队会让生产环境顺畅运行。开发人员不仅能够维护，还能发布新功能，所有这一切都不需要依赖于过度劳累的 SRE。

这个故事讲述了我们迈向那个未来的旅程，但有一个转折：SRE 团队不会被淘汰。相反，我们会集中精力开发开源工具，来进一步提升开发者的技能。

但是，让我们回到这一切开始的地方。

我们都知道Google关于SRE实践的那本优秀的书。问题在于如何将这些实践应用于我们公司？我们首先需要明确要解决什么问题。

我们的旅程可以用三个步骤来描述：

第一步：转向SaaS

作为一个小团队，我们决定尽可能采用SaaS。

你可以阅读这篇文章了解我们是如何开始让平台团队与开发团队共同负责监控和故障排除的，以及我们如何通过一个新的可观测性平台来支持这一点。

我们使用由咨询公司配置的Jenkins，它包含一个用于超过40个服务的流水线。平台团队则会频繁地根据请求来调整流水线代码。我们选择了CI/CD平台，并为我们的开发团队提供了支持。

• Python、Java 和 Lambda 无服务器共享包，用于构建应用程序
• 将镜像交付到 ECR（因为我们使用 AWS）
• 用于在 K8s 中部署所有服务的部署包
• 自托管的运行器，以提高安全性并降低成本，通过在我们自己的基础设施中运行大多数构建来实现

提供这些之后，开发人员知道了CI/CD是如何运作的，并开始自定义和维护自己的流水线（pipelines）。

这种转向SaaS解决方案让开发团队能够掌控自己的流水线，并解决基础设施相关的技术问题，从而释放了平台团队，加快了开发速度。

第二步：自动处理最常遇到的请求

利用我们获得的空闲时间，我们着手自动处理开发人员最常要求自动化的任务。

1. 基础设施配置
2. 服务开通
3. 用户开通/注销（授予/撤销访问权限）

我们使用Backstage作为一个单一平台来实现自动化工具，并将这些功能实现为插件。然而，我们发现开发者在各个工具间导航并适应新插件变得相当困难。

我们决定建立一个内部开发者平台（IDP），作为所有开发团队所需各项内容的单一入口点。利用Scaffolder Backstage插件，我们开发了自己的后端服务和一些UI，涵盖了软件开发生命周期（SDLC）的主要步骤。

我们为开发者创建了模板，以帮助他们创建云资源，从AWS的EKS、Kafka、Redis等开始，之后又加入了MongoDB、Vault等，最终支持了超过60种云资源。

为了服务上架，我们增加了repo（代码库）创建、密钥管理、容器镜像仓库以及CI/CD流水线功能等。

通过建立内部开发者平台，我们为开发人员打造了一个自助服务的开发环境，他们可以轻松地管理和优化基础设施和服务，大大提升了效率和自主性。

步骤3：将IDP重新构建为开源项目。

我们发现开发团队有时需要一些我们的IDP没有设计来处理的资源。
然而，我们的IDP并没有设计成这样。因此，我们开始重建我们的IDP作为一个开源产品名为InfraKitchen。更多详情，请参阅链接。
IDP的一个小部分最近作为单独产品InfraWallet发布了。https://github.com/electrolux-oss/infrawallet

随着我们组织的发展，由于团队规模较小，我们在培训开发人员方面遇到了挑战。我们没有扩大培训力度，而是为开发团队提供了平台，帮助他们独立实施SRE（站点可靠性工程）实践。

这张图展示了站点可靠性工程（SRE）中的核心实践及其在组织中的当前状态。图中的颜色标注表示每个实践的当前状态。

• 绿色 ：已实现并被积极使用
• 蓝色 ：正在开发中
• 黄色 ：计划在接下来的几个季度内实施

我们相信，贯彻SRE理念通过平台工程的方式来要高效很多，因为它让开发人员可以自己解决基础设施需求，让SRE团队能够专注于战略项目和工具开发。

这一演变标志着我们从传统SRE转向了平台工程。伊莱克斯也在采用这种方法，处理开发者需要越过平台限制的情况。平台工程为我们带来了更高的生产效率、更好的基础设施使用可见性，以及更快的市场进入速度。

我们的旅程从曾经不堪重负的SREs（系统可靠性工程师）到一个未来，在这个未来，开发者和SREs能够共同成长和繁荣——在自动化和协作的支持下——突显了自助服务模型的力量，同时也强调了赋能开发者的重要性。

这是我们每个人的故事，你的故事又会怎么写呢？

附：我们找到了让开发人员通过我们的IDP完全访问其基础架构的方法。想知道我们是如何在不牺牲安全性和稳定性的前提下实现这一目标的吗？留下您的评论吧！