站点可靠性工程之旅

SRE 经过谷歌的实践和推广，已经被很多互联网公司所采用。如果想要实践 SRE，成为 SRE 工程师，需要做好哪些方面的知识储备？本文介绍了 SRE 相关的技术，提供了大量有益的资源，有志于这一方向的同学可以以此作为技术发展路线图。原文：A Journey To The Site Reliability Engineering^[1]

Mukuko Studio @ Unsplash

很多组织都已经开始采用站点可靠性工程（SRE，Site Reliability Engineering）实践来代替传统的运维。LinkedIn 上最新的工作搜索显示，全球范围内有超过 19 万个 SRE 工程师职位空缺。

LinkedIn 职位搜索

如果你还不熟悉 SRE，那么可以看看谷歌是如何描述的~

SRE 是当你要求软件工程师设计一个运营团队时所发生的事情。

SRE 由 7 个重要原则定义 --

• 运维是一个软件问题（Operations is a software problem）

• 按服务水平目标管理（Managed by Service Level Objectives）

• 尽量减少工作量（Work to minimize the toil）

• 把今年的工作自动化（Automate this year’s job away）

• 通过减少失败的代价来快速行动（Move fast by reducing the cost of failure）

• 与开发者分享所有权（Share ownership with the developers）

• 无论是什么职能或职位，都使用相同的工具（Use the same tooling, regardless of function or job title）

对于拥有运维支持、系统管理、基础架构、DevOps 工程师等背景的人来说，SRE 工程是一个很好的职业发展方向。

在本文中，我将提供各种资源，帮助你开始 SRE 工程师之旅。

掌握 SLO 的艺术（Mastering the Art of Service Level Objectives(SLOs)）

为了旅程顺利，我们有必要从理解服务水平指标(SLIs, Service Level Indicators)和服务水平目标(SLOs, Service Level Objectives)的概念开始。

SLI: 服务可靠性的可量化度量

SLO: 为 SLI 设置可靠性目标

有很多关于 SLI 和 SLO 的资源，但我建议通过 SLO 艺术工作坊^[2]来深入理解这一概念。

如果你是某个尝试采用 SRE 实践的组织的一员，那么我建议在组织内为有抱负的 SRE 开展这个工作坊。

工作坊旨在向你介绍如何以数据驱动、客观和以用户为中心的方式通过 SLO 和错误预算（Error Budgets）来度量和管理服务的可靠性。

工作坊可以指导我们选择正确的 SLI，并通过案例帮助我们获得定义 SLI/SLO 的实践经验。

在学习的过程中，请保持开放的思维和新鲜的视角，因为我看到很多人认为 SLI/SLO 类似于他们使用的 APM 工具所做的基础设施监控，但事实并非如此！

云技术（Cloud Expertise）

根据 Gartner 的报告^[3]，超过 75%的企业都有云优先战略。

来源-https://www.gartner.com/en/information-technology/insights/cloud-strategy

因此，熟悉 AWS、GCP 和 Azure 等云服务是非常必要的。

许多组织都在积极使用云技术进行应用程序现代化转型之旅，SRE 被要求在这一转变过程中发挥重要作用。

在互联网上有很多像 Udemy, PluralSight, Coursera, CloudGuru 等网站来提升我们的知识储备。

基础设施即代码（Infrastructure as Code(IaC)）

随着组织在云中迁移工作负载，高效、动态的管理基础设施的需求就更加突出了。因此，SRE 应该拥有下面这样的 IaC 工具：

• Terraform

• Ansible

• Chef

• 等等

即使所有云服务提供商都有自己的 SDK/Shell 来管理服务，使用 IaC 工具仍然有很多好处。

下面的内容引用自《Quickly Deploy Applications Using Terraform With Kubernetes on GCP^[4]》：

Terraform 能够显示当前状态和期望状态之间的差异，这意味着一旦我们编辑了 Terraform 配置文件，就能看到将要做的改变。

Terraform 不仅负责初始部署，还负责维护。我们可以使用命令轻松的创建、更新和删除跟踪的资源。

清理 Terraform 构建的所有东西非常容易。如果使用脚本，我们还必须编写一个清理脚本。但对于 Terraform，可以简单的通过“terraform destry”命令来实现。

Terraform 能够检查配置文件中声明的动作的顺序。这意味着，如果我们想运行基于 Kubernetes 的服务或部署，即使我们错误的声明了操作的顺序，Terraform 仍然将首先创建集群。

你可以查看以下链接来了解关于这个主题的更多信息。

1. https://learn.hashicorp.com/terraform
   

2. https://www.ansible.com/resources/get-started
   

容器及容器编排平台（Containers & Container Orchraction Platforms）

由于 SRE 在应用程序部署中扮演着关键角色，所以了解容器和容器编排平台非常重要。

许多组织使用 Docker 和 Kubernetes 平台进行服务部署，可以在网上找到大量关于这个话题的资源。

这里有一些可以作为开始的链接：

1. https://www.docker.com/101-tutorial
   

2. https://kubernetes.io/training/
   

持续集成及持续部署（Continuous Integration & Continous Deployment(CI/CD)）

SRE 需要将尽可能多的工作自动化，为应用程序提供适当的 CI/CD 流水线是快速交付的重要部分。许多组织使用下面这样的平台：

• GitLab

• GitHub

• Azure DevOps

• Jenkins

• 等等

因此，拥有建立 CI/CD 流水线的专业知识是一项基本技能。这些平台中有很多都支持免费服务，可以不用花一分钱就能自学。

这里有一些学习资源：

1. https://about.gitlab.com/learn/
   

2. https://lab.github.com/
   

3. https://azure.microsoft.com/en-us/overview/devops-tutorial/
   

发布策略（Release Strategies）

来源-https://sre.google/workbook/canarying-releases/

作为 SRE 角色的一部分，我们需要不断为用户部署新特性。这么做的同时，还需要确保在部署新特性时没有消耗错误预算（Error Budget），因此需要熟悉如下发布策略：

• 金丝雀发布^[5]
  

• 蓝绿发布^[6]
  

• 等等

熟悉特性标记(feature-flag)^[7]的开发策略将增加优势。如果使用像 Kubernetes 这样的容器编排平台，可以使用 Kubernetes 的定义文件描述这些策略^[8]。

在谷歌的 SRE 工作手册中深入介绍了金丝雀发布的过程^[9]。

事故响应和非指责的事后剖析（Incident Response & Blameless Postmortems）

随叫随到是 SRE 的另一个重要职责。因此，SRE 需要对事故响应流程有非常好的理解。

PagerDuty 事故响应课程^[10]涵盖了如下话题：

• 什么是事故？

• 事故级别

• 事故管理的各种角色

• 事故电话礼仪

• 等等

将事故响应过程记录下来是很重要的，因为如果人们知道事故发生时如何应对，就能更好的管理突发事故。

PagerDuty 还有另一个关于如何在 SRE 团队中培养非指责文化的课程^[11]，其中提供了一些非常详细的模板，可以用来执行无指责的事后分析。

强烈推荐这两门课程。

安全（Security）

因为 SRE 负责整个应用，对应用安全性有基本的了解总是好的。

强烈建议你熟悉下面提到的概念：

1. OWASP Top 10^[12]
   

2. Application Threat Modelling^[13]
   

对于自动化部署，SRE 需要管理各种服务凭证，因此应该熟悉凭证管理工具，如 HashiCorp Vault^[14]或云原生加密管理解决方案，如 Azure 密钥库、谷歌加密管理器等。

文档（Documentation）

SREs 需要确保所有重要的文件都定期更新，易于遵循，因此应该专注于制作高质量的文档，比如：

• 运维操作手册（Operation Runbooks）

• 发布/回滚文档（Release & Rollback documents）

• 等等

谷歌提供免费的技术写作课程^[15]，建议大家在日常生活中学习并运用其中的原则，当然如果你有时间的话也可以报名参加有导师指导的培训课程。

另外，我也写过一篇关于工程师技术写作最佳实践的文章《Best Practices When Documenting Your Code for Software Engineers》^[16]。

灾难恢复测试/混沌工程（Disaster Recovery Testing / Chaos Engineering）

为了测试平台的健壮性，SRE 还负责执行灾难恢复测试。谷歌将灾难恢复测试作为其健壮服务的一部分，《Weathering the Unexpected》^[17]是一篇关于谷歌 DiRT 项目的详细文章。

最近 Netflix 的混沌工程理念变得非常流行，我在《Why Every Software Developer Needs to Learn Chaos Engineering》^[18]里也写过关于混沌工程的内容。

非抽象大规模设计（Non-Abstract Large Scale Designs(NALSD)）

当我们开始讨论大型、复杂、分布式系统时，谷歌已经设计了一个流程^[19]，可以帮助 SRE 发展评估、设计和衡量大型系统的能力。

NALSD 过程包含了问题陈述、需求收集，以及帮助评估大规模系统对不同故障模式的容忍度的迭代系统设计。

谷歌还提供了一个工作坊，带领我们了解分布式消息队列(如 pub/sub)的系统设计，并解释如何对其实现 NALSD 原则。

我个人从中学到了很多。

社区

为了更多的向他人学习，并了解行业最新动态，建议加入以下在线社区：

• https://www.reddit.com/r/sre/
  

• LinkedIn — School of SRE — https://www.linkedin.com/groups/12493545/
  

结论

总的来说，SRE 工程流程非常有趣，并且正在被许多组织所采用。

References:

[1] A Journey To The Site Reliability Engineering: https://deshpandetanmay.medium.com/a-journey-towards-site-reliability-engineering-7c893dae23ab

[2] The Art of SLOs: https://sre.google/resources/practices-and-processes/art-of-slos/

[3] The Latest Cloud Computing Technology and Security: https://www.gartner.com/en/information-technology/insights/cloud-strategy

[4] Quickly Deploy Applications Using Terraform With Kubernetes on GCP: https://medium.com/google-cloud/quickly-deploy-applications-using-terraform-with-kubernetes-on-gcp-6a4d7d142839

[5] Canary Release: https://martinfowler.com/bliki/CanaryRelease.html

[6] Blue Green Deployment: https://martinfowler.com/bliki/BlueGreenDeployment.html

[7] Feature Toggles: https://martinfowler.com/articles/feature-toggles.html

[8] Kubernetes Deployment: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

[9] Canarying Releases: https://sre.google/workbook/canarying-releases/

[10] PagerDuty Incident Response: https://response.pagerduty.com/

[11] PagerDuty Postmortems: https://postmortems.pagerduty.com/culture/blameless/

[12] OWASP Top 10: https://owasp.org/www-project-top-ten/

[13] Application Threat Modelling: https://deshpandetanmay.medium.com/threat-model-what-is-that-b45eac2c4104

[14] Vault: https://www.vaultproject.io/

[15] Technical Writing Courses for Engineers: https://developers.google.com/tech-writing/

[16] Best Practices When Documenting Your Code for Software Engineers: https://betterprogramming.pub/best-practices-when-documenting-your-code-for-software-engineers-941f0897aa0

[17] Weathering the Unexpected: https://queue.acm.org/detail.cfm?id=2371516

[18] Why Every Software Developer Needs to Learn Chaos Engineering: https://betterprogramming.pub/why-every-software-developer-needs-to-learn-chaos-engineering-ef08992f4354

[19] Introducing Non-Abstract Large System Design: https://sre.google/workbook/non-abstract-design/

你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。

微信公众号：DeepNoMind