SRE 与 DevOps：你知道它们之间区别吗？
公众号「架构成长指南」，专注于生产实践、云原生、分布式系统、大数据技术分享
DevOps专注于消除阻碍开发和运维之间协作的隔阂，而SRE致力于设计和实施可扩展、可靠的系统，确保最大可靠性。
这篇文章将探讨DevOps和SRE之间的差异，它们的角色和责任，它们解决的问题以及它们使用的工具。
DevOps 和 SRE 之间的差异
- 实施新功能 - DevOps负责实施对产品的新功能要求，而SRE确保这些新变更不会导致生产环境的故障率。
- 流程流向 -DevOps 团队从开发环境的角度出发，将变更从开发阶段落实到生产阶段。而SRE是从生产环境的稳定性角度出发，因此他们可以向开发团队提出建议，以限制新的需求变更而带来故障率。
- 焦点 - DevOps的主要关注点是产品开发的连续性和速度，而SRE的主要关注点是系统的可靠性、可扩展性和可用性。
- 团队结构 - 典型的DevOps团队由担任专门角色和职责的专业人员组成，如产品负责人、团队领导、云架构师、软件开发人员、质量保障工程师、发布经理、系统管理员。相比之下，SRE团队由具有运维和开发技能集的工程师组成。
SRE 和 DevOps 的工作角色差异
尽管 SRE 和 DevOps 的工作角色存在一些重叠，但职能存在广泛的分离：
| DevOps | SRE | |
|---|---|---|
| 角色 | DevOps团队的主要作用是解决开发问题，构建满足业务需求的解决方案。 | SRE 的主要作用是处理运营问题，例如生产故障、基础设施问题（磁盘、内存）、安全、监控。 |
| 重点 | 专注于持续集成/持续交付的产品开发。 | SRE 更加关注弹性、扩展性、可靠性、正常运行时间和稳健性。 |
| 工具 | 在 DevOps 角色中，最广泛使用的工具是用于开发目的的集成开发环境 (IDE)、用于持续集成和开发的[Jenkins 、用于变更管理的 JIRA等 | 在SRE角色中，最广泛使用的工具是Prometheus和Grafana，用于收集和可视化不同的指标（CPU使用率、内存、磁盘空间等）、事件警报工具（OP5、PageDuty、xMatters等）、Ansible、 Puppet，或 Chef、用于容器编排的 Kubernetes 和 Docker，云平台 |
| 错误报告 | DevOps 团队负责调试代码，以防最终产品中报告任何错误。 | SRE 团队负责向 Core 开发团队报告 bug，除非是生产中断，否则不会参与调试。SRE 团队还负责调试和修复基础设施问题。 |
| 测量指标 | DevOps 角色的典型衡量指标是部署频率和部署失败率。 | SRE 角色的典型衡量指标包括错误预算、SLO（服务级别目标）、SLI（服务级别指标）、SLA（服务级别协议）。 |
| 事件处理 | DevOps 团队处理事件反馈以缓解问题。 | 进行事件后审查，以确定根本原因并记录调查结果，以便向核心开发团队提供反馈。 |
DevOps 团队解决的问题
实施 DevOps 实践可以减少开发和运营团队之间的摩擦。它还可以帮助我们可靠地交付最终产品。
1. 降低开发和维护成本
DevOps 团队始终致力于 CI/CD，将更多精力投入到自动化测试而不是手动测试，并通过自动化来改进发布管理。
传统的软件开发生命周期，总是存在着重复的工作（开发、测试、发布），这增加了产品开发和生产维护的总体成本，而DevOps实施可以显着减少交付时间、开发和维护成本。
2. 更短的发布周期
DevOps 团队带来的最有效的改变之一就是以更短的发布周期更快地交付。DevOps团队之所以提倡较短的发布周期，是因为这样便于管理，并且在出现问题时可以回滚到稳定版本。
与传统的发布周期相反，传统的发布周期的重点是在一个版本中交付所有内容，这增加了生产失败的风险，并且很难回滚。如果严格遵循 DevOps 实践，组织将始终拥有一个版本发布系统。
以下是较短发布周期的好处：
- 更频繁地交付新的变更请求；
- 将升级（错误修复、安全补丁、版本升级）推送到生产环境要容易得多。
3. 自动化和连续测试
与传统的开发周期相比，在传统开发周期中，测试团队必须等待产品在测试环境中交付后才能开始测试，而在DevOps中，测试从开发生命周期的开始阶段就被注入进去。
DevOps通过持续且自动化测试，借助CI/CD工具（Jenkins）和版本控制（gitLab），实现了测试的早期介入。
SRE 团队解决的问题
1. 缩短平均恢复时间 (MTTR)
SRE 团队负责保持生产环境正常运行。如果出现错误或生产故障，SRE 团队可以回滚到产品之前的稳定版本，从而缩短平均恢复时间 (MTTR)。
2. 缩短平均检测时间 (MTTD)
SRE 团队解决的另一个问题是使用金丝雀部署来减少平均检测时间 (MTTD) ，以便在全面部署之前将新版本提供给一小部分用户。金丝雀发布可以帮助 SRE 团队在早期阶段发现系统问题，并且影响面小。
3. 一切自动化
自动化是SRE团队必须面对的最大挑战之一。经常观察到，部分人部署和支持任务是手动执行的，这导致了不一致性并增加了人为错误的可能性。
管理基础设施的一个良好实践是利用基础设施即代码（IaC），借助Terraform、Pulumi以及Ansible、Puppet、Chef等自动化工具。SRE团队可以利用这些工具来解决自动化方面的问题。
4. 生产中的自动化功能和非功能测试
开发人员可以在测试和阶段环境中自动化功能和非功能测试，但不能在生产中自动化。
SRE工程师可以帮助在生产环境中实施自动化测试，而不会影响最终用户。
5. 随时待命
通常，SRE工程师要经常值班，以处理难以预见事故，同时还必须编写事故报告文档和排查步骤，以帮助其他人执行。
SRE团队可以建立一个有关事故的有价值的知识库，以改善事故排除的时间。
DevOps 和 SRE 工具
当我们谈论 DevOps 和 SRE 的工具时，经常会发现大多数工具都是 DevOps 和 SRE 共同使用的。
常用工具
配置管理工具
- Terraform
- Pulumi
- Ansible
- Puppet
- Chef
版本管理
- GitHub
- BitBucket
- GitLab
日志监控
-
Elk
-
Loki
-
Splunk
DevOps 工具
持续集成
- Jenkins
集成开发环境
- Intellij
- Visual Studio
- Sublime
- Eclipse
自动化测试
- Jmeter
- Robot Framework
- Burp
- Wireshark
SRE Tools
- Kibana
- Prometheus
- Grafana
- New Relic
- Istio
- 夜莺
总结
以上我们介绍了 DeveOps 和 SRE 的指责分工，虽然有所不同，但是它们都致力于同一个目标 - 提升发布周期并实现更好的产品可靠性。