站点可靠性工程之旅

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]，建议大家在日常生活中学习并运用其中的原则，当然如果你有时间的话也可以报名参加有导师指导的培训课程。

另外，我也写过一篇关于工程师技术写作最佳实践的文章《软件工程师文档写作最佳实践》^[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