在过去的一年里，FullContact 的 DevOps 团队已经转型为 SRE 团队，我们对此感到非常高兴。我们的 DevOps 团队的运作方式与许多其他 DevOps 团队一样，与我参加过的每个 DevOps 导向会议（从 DevOps Days 到 KubeCon）上从其他与会者那里听到的情绪非常吻合。“DevOps 只是一个重新命名的系统管理员/运维人员……”
我们主要处理基础设施和 CI/CD 等工具，以使开发人员的生活更加高效和富有成效。但我们仍然与我们的团队分开运作，彼此脱节，有时还会与其他团队计划的工作发生冲突。
在我看来，DevOps 是一种文化，而不是一种角色。当然，它以一些工具为中心，这些工具需要由某人维护，通常需要具备更多的运维技能。但 DevOps 带来了一种授权工程师的文化，为快速发布、自动部署、高效配置的基础设施等铺平了道路。
对我们来说，SRE 角色是 DevOps 文化应用的体现。当我们开始着手拥有 SRE 时，我们花了一点时间来了解我们想要 SRE 角色具备什么素质、他们应该具备或努力获得哪些技能，以及他们将如何与他们所在的团队合作。
我们希望 SRE 具备什么素
为了确定我们想要 SRE 具备什么素质，我们退后一步来了解他们对我们的基础设施的影响。我们希望我们的基础设施不断朝着高度自动化和自我修复的系统发展。从工程师的角度来看，该系统要能够抵御故障，但又易于维护。这就要求我们的 SRE 具有协作精神。他们将与团队合作，设计和实施由数据驱动的系统，朝着我们期望的更具弹性、高度自动化和自我修复的系统状态前进。
我们还希望我们的基础设施是可见的。添加和优化我们的指标和警报系统以在正确的时间提供正确的信息，使我们能够更快地做出反应并做出更好的软件开发决策。这将要求我们的 SRE 通过可观察性为我们的服务和平台发声。
除了可观察性和弹性之外，我们还希望我们的基础设施井然 WhatsApp 数据 有序且结构化。作为 FullContact 的 SRE，我们需要我们的工程师为他们的团队提供建议，帮助他们以最佳实践和一致、可重复的方式设计系统。
SRE 应该具备什么
现在我们了解了 SRE 的输出应该是什么样的，我们可以概述他们应该具备或达到 大自然的艺术大师 会自己作画的花朵 哪些预期能力才能取得成功。我们列出的清单如下：
计算机科学基础知识（至少是数据结构、算法和系统设计）
能够使用多种语言编写
能够调试、基准测试和为我们堆栈中的任何系统添加可观察性
深入了解我们的基础设施
其中一些是理论性的，而另一些则是理论与现实世界的交汇。获得或拥有这四 BZ 列表 种能力将使我们的 SRE 能够理解性能权衡，编写甚至建议使用基于 JVM 的默认语言之外的语言编写软件，协助调试这些语言的实时服务，并能够从大局出发做出调整和建议。
SRE 如何工作？
我们的 SRE 最终融入到他们合作的团队中。从功能上讲，这使他们能够融入该团队的流程和工作节奏。此外，SRE 将倡导 DevOps 文化思维，在此过程中为同事提供支持。我们仍然以 SRE 团队的身份开会，处理全球基础设施需求，并相互通报可能的变更，以改进我们的代码编写、测试、部署和运行方式。
流程目前进展如何
进行这样的更改可能会很麻烦。可能需要几次迭代。这种转变需要的思维转变和角色转变一样多。但我们在 FullContact 坚持不懈地交付和改进。到目前为止，我们的团队很高兴有一名 SRE 加入团队，这不仅仅是因为他们有一个可以随时求助的 Ops 导向型人员。我们的工程师努力提高自己的技能，而如今，这意味着了解如何创建 IAM 角色、更新 Terraform 或自行调整管道。
我们了解到，获得 SRE 的所有技能可能具有挑战性，尤其是因为许多公司仍然通过工作职责严重孤立员工，同时试图称之为 DevOps。了解到这一点，我们实践同理心，并努力通过持续、有意义的投资来增强我们的 SRE 的能力。我们首先花了整整六个月的时间指导、辅导和协助我们的 SRE 与他们团队的整合。一旦我们融入团队，我们就会建立反馈循环来检查上述结果的影响和里程碑。即使是现在，我们也在让整个 SRE 团队学习
