2019 年 NGINX Conf 上 LinkedIn、Dell 和 Gremlin 站点可靠性工程小组的三大收获

在 2019 年 NGINX Conf 上，我们进行了50 多场涵盖各个主题的录制会议，但在这篇博客中，我将分享业界最热门话题之一的要点： 站点可靠性工程（以及混沌工程的相关主题）。 我只会关注三个关键要点，但鼓励您在这里观看整个会议。

1.    SRE 定义

讨论开始于小组成员如何定义“站点可靠性工程”这个术语，他们一致认为，它的本质是： “尽一切努力确保网站正常运行。” 但除此之外，他们还强调“在出现任何问题时要深入研究并尽快解决问题”和“以客户为中心的思维方式授权开发团队”。 此外，您是否在描述中认识到它与传统网络运营团队有一些近似的相似之处？ 是的，我也是，但一位小组成员确实读懂了我的心思，他强调说：“一些组织仅通过重命名其网络运营团队就建立了 SRE 团队，但这不是最好的方式。” 对此有一些讨论，但我的看法是，SRE 和 NetOps 之间最大的区别在于 SRE 人员“坐在开发团队或面向客户的团队中，真正专注于业务目标”。

2.    混沌工程与故障注入

SRE 功能的关键主题之一是混沌工程的概念。 我将把混沌工程的详细解释推迟到本文中，但在本次会议中，它实际上是关于“一种识别关键故障并快速修复的方法”——类似于消防演习。 尽管与消防演习有相似之处，但混沌工程的目标更广泛，因为它侧重于定量分析恢复、耐用性和可用性指标。

故障注入是一种相当常见的方法，由 Netflix 于 2014 年推出。 这是一种测试方法，将故障模拟元数据推送到生产环境中进行测试，但具有控制。 这些工作通常由 SRE 团队领导，以确保服务（或站点）的更高可用性和可靠性。

3.    SRE 的 KPI 和技能

关于如何衡量 SRE 有一些有趣的讨论。 虽然有几点意见认为 MTTD（平均检测时间）和 MTTR（平均响应时间）是重要指标，但所有小组成员都同意，指标会根据您所在的行业以及您运营的系统或站点而有所不同。 讨论中提出的一个很好的建议是：“你可以先问这个问题： “您最重要的 5 个系统是什么？这将有助于您确定事情的优先顺序。”

所涵盖的另一个主题是 SRE 职位所需的技能组合。 据小组成员称，这还取决于您运行的系统。 （例如，如果您正在运行 NGINX，那么 NGINX 经验对于 SRE 招聘来说至关重要。） 该小组提出的一个很好的建议是探索在公司不同领域和系统之间轮换 SRE 人员的方法，以扩大和更好地装备 SRE 资源。 此外，确保您的 SRE 团队参与 SRE 社区活动，例如培训、场外活动、专用 Slack 频道和“游戏日”以及其他有用的建议。

结论——2020 年是定义您自己的 SRE 策略的时候吗？

简而言之，讨论表明许多组织仍在学习如何定义和利用 SRE 的概念和作用——正如小组成员重申的那样，这些通常会因行业和系统（甚至是个别公司）而异。 总的来说，明年将继续致力于解决混沌工程问题——也许这是一个开始思考这对您和您的组织意味着什么的最佳时机？