打造成功的 SRE 团队

一个成功的 SRE 团队可以为组织带来巨大价值，帮助组织高效完成价值交付。本文介绍了 Mission Lane 公司打造 SRE 团队的经验和实践。原文: Building a Successful SRE Team

简介

当我加入 Mission Lane 时，是公司仅有的两名站点可靠性工程师(SRE)之一，而另一位就是我的老板，SRE 团队的经理，后来成为了平台组织的主管。我们被要求组建一支拥有可观察性和开发者经验的 SRE 团队，从而开始了这一为期三年的旅程，建立了一个成功的 SRE 组织，并为 Mission Lane 带来巨大价值。如今 SRE 团队由四个人组成，支持 250 个微服务和 130 名开发人员，每天向各种环境发布数百个版本，每天产生近 10 亿次日志和跟踪。

SRE 团队专注于以下事项:

• 为 Mission Lane 开发者创建标准化 helm chart

• 管理自动分布式跟踪

• 创建可观察性技术栈，每秒处理 50 万条日志和跟踪

• 为应用自动化处理金丝雀发布，希望显著降低使用门槛

• 托管依赖自动更新

• 建立有用的服务目录

SRE 团队还和姐妹团队(云平台工程(CPE)和 DevSecOps(DSO))一起，建立了几乎完全自助服务的开发平台，开发人员只需要提交三个 PR(以及一些关于命名的讨论)，就可以完成从想法到生产的流程。

这也是我第二次参与建立成功的 SRE 团队(第一次是在 Capital One)，以下是我学到的四条经验教训，可以帮助我们建立成功的 SRE 组织。

1. 专注于开发人员培训

2. 专注于正确的抽象

3. 专注于自助服务

4. 用自动化取代工作

专注于开发人员培训

当我们花一整天时间研究某项技术或平台时，就能成为这方面的专家。而当我们成为某一技术领域的专家时，就会习惯平台的怪癖、问题和边缘情况。此外，我们很快就会遇到高级用户问题，并且希望尽可能多进行自定义。我们确切知道什么可用，系统如何工作/如何连接，并且对事物如何工作有很好的心理模型。

但 SRE 的客户是开发人员，他们专注于通过开发服务交付业务价值。开发团队有不同层次的工程成熟度，使得他们有能力关注可靠性、工具等，而非只是直接的业务需求。他们需要能够尽可能快速、轻松的交付价值，同时不损害安全性、可靠性或可伸缩性。因此开发人员培训至关重要。

在 Mission Lane 有中心化 SRE 团队，支持大约 20 个产品团队，拥有大约 250 个微服务。我们每个季度都会选择两到四个产品团队，将 SRE 嵌入团队一个月。在这个月里，SRE 需要关注项目健康状况检查清单，以保持目标专注，但主要目标是培训开发人员，了解开发人员如何与平台互动，了解开发人员遇到的所有小问题，并通过授之以渔来帮助他们更轻松的工作。以下是一些 SRE 可以帮助解决的问题:

1. 修复对某些特定非关键(但非常恼人的)端点不起作用的跟踪

2. 帮助开发人员了解使用Flagger和 Istio 的金丝雀版本如何工作

3. 帮助开发人员添加仪表板，创建警报，调整或抑制乱七八糟的告警

4. 帮助开发人员能够从本地部署到开发集群

这是我们成立 SRE 团队一年后开始的项目，非常成功。开发人员喜欢与 SRE 进行简短、集中的交互。SRE 与产品团队建立了联系，向我们展示了开发人员遇到的各种问题或关注点，并且帮助我们构建工程组织的一般知识。

专注于正确的抽象

DevOps 文化转型主要集中在"左移"。随着组织成熟，我们意识到也需要下移。我们需要编写正确的抽象，帮助团队用更少的资源做更多的事情。

在 Mission Lane 的早期，我们的 Kubernetes 集群上没有抽象。当时，我们有一个非常强大的基于ArgoCD、GKE 和CNRM的 GitOps 流水线。但开发人员需要手工编写 k8s 清单，然后通过 ArgoCD 将其应用到 k8s 集群中。虽然这会导致大量重复的 YAML，但真正的问题是当我们需要应用大规模更新时。需要为所有部署设置安全上下文吗？需要换一个新的 Ingress 吗？想要应用环境变量或注释吗？我们不得不编辑数百个 yaml 文件。虽然其中一些可以通过编程语言自动化，但社区已经解决了这个问题。

大约在 SRE 团队成立 9 个月后，我们发布了 ML Service Helm Chart 的 1.0.0 版本。这个 chart 最终被 Mission Lane 95%的服务所使用，并且出现了数百个版本。它允许团队在我们的集群中可靠、安全的启动和运行，允许极端定制，在大多数情况下遵循 k8s API 规范，完全允许重写所有设置，同时提供相同的默认值，以促进良好的应用健康状况和实践。

这个 helm chart 使我们能够为整个组织解决问题。当我们发现需要添加设置时，可以为整个组织发布带有更新配置的新版本 helm chart。新版本严格遵循"Don't Break User Space"原则，带有大量测试并自动管理非兼容 API 的更改。

这种下移而不是左移的范式出现在工具、我们编写的抽象以及我们谈论开发人员的方式中。把他们当作自己领域的专家，认识到他们可能不是你领域的专家，看看你能怎么帮助他们以自助的方式获得成功。

专注于自助服务

SRE 团队应该能够成为工程组织的力量倍增器。如果必须为每个产品团队雇佣一个 SRE，就意味着失败。专注于允许开发人员做出自助决策，并且只在出现问题时才来寻求帮助，这可以使力量倍增。亚马逊和谷歌不会强迫我们每次想要开启一项服务时都与技术支持沟通，也不会强迫我们在发布新产品时都与工程师沟通。相反，他们通过 API 和 UI 使我们能够自助服务，只有在无法解决问题时才会与他们交谈。如果我们编写了良好的文档并拥有直观的流程/API，那就可以帮助无数开发人员，而不用不得不与每个开发人员进行沟通。

这种理念在 SRE 团队成立之前就存在于 Mission Lane。在创建 SRE 时，底层 GKE 集群和自动化工具非常好，这是 CPE 团队的功劳。但是专注于自助服务让我们能够执行办公时间模式(office hours model)，即开发者可以每周来一次并提出问题，其他情况我们可以通过 slack 支持频道，让开发者能够提出问题并获得答案。

使用允许开发人员与集群和服务进行安全交互的工具，可以确保流程在不限制选择的情况下不会出现错误配置。当问题出现时，请确保评估流程或工具，看看哪里可以做得更好。信任你的开发者，开发者就像用户一样，他们很少故意做错事，出问题时可能只是有一个xy状况。

使用能够在相同位置快速给出反馈的工具。在早期，CPE 决定将 PR 作为所有反馈的中心。使用主线开发模式并让所有工具与 PR 交互意味着有一个一致的心智模型，团队可以只通过代码所有者和评审进行自助服务。几乎平台团队引入的每个工具都使用 PR 作为界面机制，极大提高了开发人员的速度和反馈。

用自动化取代工作

消除重复劳动是 SRE 的关键要素，是这份工作的基础，也是支撑这份工作的哲学。如果一遍又一遍重复做同样的任务，每次纠正同样的问题，或者甚至编写非常好的运行手册，都表明你没有消除足够的重复劳动。虽然机器不应该提供审批，但几乎所有其他工作都可以自动化。打开某些 PR，模板化 repo 和文件，甚至响应某些错误都可以自动化。

这是 SRE 在 Mission Lane 的核心原则，努力使自己尽可能自动化。这意味着使用Cortex.io这样的工具来构建模板和记分卡，编写自己的数据库分析器来帮助团队调整连接设置和数据库大小，编写自动修复 Elasticsearch 问题的工具，或者在 PR 中用现成的分析器来帮助捕获常见问题，我们努力消除做特定任务的需要，从而使我们能够专注于更高层次和更大组织范围的问题，同时还让我们可以基于有限数量的 SRE 来扩展和支持快速变化的开发组织。

结论

建立成功的 SRE 团队是困难的。需要非常优秀的工程师，他们知道如何专注于正确的问题，并且是优秀的沟通者。但这一切最终都是值得的，SRE 团队将成为整个组织的力量倍增器，帮助团队减少意外事件、改善开发人员体验、提高代码质量。只需记住:

1. 关注于开发人员培训。提高开发人员的知识和期望会带来巨大好处。

2. 专注于正确的抽象。下移，而非左移。抽象掉那些对客户不重要的东西。

3. 专注于自助服务。开发人员应该能够完全自主的与平台进行交互，任何标准操作都不需要和 SRE 交谈。

4. 让自动化帮助我们摆脱工作。继续努力，不要自满。推动不断改进自动化，这样就可以做新的和有趣的事情！

你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。为了方便大家以后能第一时间看到文章，请朋友们关注公众号"DeepNoMind"，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的支持和动力，激励我持续写下去，和大家共同成长进步！