现实世界的SRE：FAANG公司正在做的不是什么

这是第一期的SRE团队。在这里，我将与大家分享一些有趣的公司是如何实施现场可靠性工程实践的。什么是有效的，他们面临着什么挑战，以及对也在建立SRE团队的公司有什么建议。

接下来的3期已经准备好，将在未来几天发布。请确保您订阅了直接在您的收件箱中接收它们。

我有机会和约翰谈谈。在哈什，他领先于SRE。我们讨论了他们是如何构建SRE组织的，以及他们对新团队有什么建议。

哈希是巴西人金融科技打造的下一代支付基础设施。他们目前提供终端解决方案，商家可以接受实体卡支付。它就像广场，但是在巴西。他们还有更多的事情要做。

Hash针对他们正在运行的业务类型使用非常高级的堆栈。大多数金融科技在技术方面都是保守的，但哈希不是这样。他们用Istio在库伯内斯经营集装箱。使用普罗米修斯、警报管理器和Grafana进行监控和警报。以及用于CI和CD的GitLab。

Hash的团队正在使用Google SRE原则。SRE团队在公司拥有自主权。他们制定了成熟度策略，并运行任务关键型应用程序。但前提是他们必须通过准备情况检查表。SRE团队提供了产品团队可以使用的标准工具。SRE拥有CI/CD管道、基础架构代码等。但开发人员可以自由贡献功能或编写自己的定制版本。自定义功能将失去SRE团队支持。

选择退出或没有为SRE准备好应用程序的产品团队自己运行。他们拥有对所需资源的完全访问权限。在这些情况下，与SRE团队的接口最少。负责该产品的团队在K8中有自己的命名空间。受网络策略、资源配额和其他因素的限制。它们可以快速迭代，而不会危及集群中的其他产品容器。

从基础设施资源到监控警报，所有东西都是由Git代码管理的。这使得任何更改(包括基础架构和警报)都能以极快的速度进行。他们还对基础设施资源运行测试。它确保新的更改不会破坏现有的行为。

SRE团队负责他们运行的产品的SLO和SLA。定义明确的警报将与产品相关的问题发送给产品团队。寻呼仅在与他们负责的事情相关的关键事件中发生。

Hash团队拥有健康的DevOps文化。产品团队为基础架构代码做出贡献，并对平台有很好的理解。这使得Hash的SRE团队只需2个人即可完成所有工作！运行平台应用程序、跟踪指示器、创建进程等等。他们是一个由22名产品工程师组成的两人团队。这是1：11的SRE与产品工程师比率。它们正在快速增长，预计到今年年底将达到40名工程学人员。

业务的快速增长产生了一些副作用。它需要改善与产品团队的沟通，以便对平台服务进行重大更改。而制作这些过程是一项具有挑战性的任务。成熟度模型规范正在发生很大变化。接受公司其他部门的捐款。随着团队的快速发展，保持这种文化也是具有挑战性的。

使Hash能够快速、高质量扩展的关键因素之一是文化。该团队的一个重要教训是，在招聘时不要在文化契合度上妥协。吸引新人来减轻两人团队的压力是很有诱惑力的。但是一个不合适的人会破坏多年的工作。

SRE团队@Hash正在招聘！如果你想加入这个伟大的团队和项目，请联系约翰。

然后和你工作中的朋友分享这个词。这将确保他们获得其他SRE团队正在发生的最新情况。