站点可靠性工程(SRE)和DevOps是两个密切相关的IT实践，可帮助团队创建更好的软件。无论您是开发人员还是高层管理人员，了解这两种做法之间的差异（以及它们重叠的地方）将有助于您创建和维护高质量的软件。
这篇文章解释了SRE和DevOps之间的异同。我们深入研究这两种做法。他们的优势、日常任务和首选工具，以解释他们在软件开发生命周期(SDLC)中的不同角色，并帮助您评估哪些值得添加到团队的日常运营中。
站点可靠性工程(SRE)是一组实践，使团队能够通过软件工程自动执行重复的IT操作任务。SRE自动化耗时的工作（代码部署、事件响应、生产管理等），同时提高DevOps基础设施的可靠性。
SRE背后的主要思想是，使用软件来自动化IT系统的监督是一种比手动执行所有操作更具可扩展性、成本效益和可持续性的策略。其他基本的SRE原则是：
开发按预期运行的最简单的系统。
接受没有零风险这样的事实，因此避免追求不必要的可靠性。
从一开始就计划停机时间、网络延迟和可扩展性风险。
争取最大的系统可观察性。
使团队能够以一致、稳定和可重复的方式构建和部署软件。
SRE弥合了开发和ITOps团队之间的差距，赋予两个部门权力：
开发人员可以尽快将新软件投入生产。
ITOps了解到新部署符合公司的服务水平协议(SLA)。
SLA是SRE中的一个关键因素，因为这些数字设定了可接受的正常运行时间和响应时间的基准。其他重要的SRE指标是：
服务级别目标(SLO)：这些指标跟踪系统的服务级别（例如可用性或恢复时间）并确保您满足基于SLA的期望。
服务水平指标(SLI)：?SLI使团队能够评估系统是否满足其SLO。错误率和系统吞吐量是SLI的典型示例。
错误预算：该指标规定了系统在不违反其SLA的情况下可以停机或运行不佳的最长时间。错误预算与RTO类似，但SRE团队更主动地使用错误预算（通常用于决定何时将更新推送到生产环境）。
SRE帮助公司解决IT运营和软件开发中常见的一系列问题。以下是最值得注意的：
无法满足公司SLA设定的IT标准。
想要将新软件发布到生产环境中的开发人员与不想导致操作问题的ITOps之间的关系过于紧张。
难以识别和解决性能问题和瓶颈。
上限或低效的可扩展性。
频繁的服务停机和过多的计划外停机。
缺乏系统或服务的可观察性（本地或云端）。
慢速MTTR（平均恢复时间，团队从系统故障中恢复所需的平均时间）和MTTD（平均检测时间，从事件开始到团队发现问题的平均时间）。
配置基础设施的问题。
缺乏有效的事件响应计划或灾难恢复策略。
低效或不可靠的部署流程。
缺乏可用性管理的结构化方法。
软件开发过程中有太多容易出错的手动过程。
难以识别和主动缓解安全漏洞。
无法满足合规需求。
使用云计算服务或基础设施的问题（或者仅仅是因为云账单过于昂贵）。
每家公司都会让他们的SRE专家承担不同的职责，但您会在每个团队中找到一些职责。以下是最常见的SRE任务列表：
使用服务器自动化来简化重复且耗时的任务（部署服务器、设置软件、运行网络安全检查等）。
定义和实施系统和服务的可靠性要求。
衡量可靠性目标（SLA、SLI、SLO和错误预算）。
帮助开发人员构建和部署高度可用、可扩展和容错的软件。
做出有关部署新功能或应用程序的数据驱动决策。
执行容量规划以预测未来的资源需求并确保系统处理不断增加的流量或数据。
向上扩展系统以确保最佳性能或向下扩展以降低费用。
跟踪系统的性能和可用性。
不断寻找改进IT流程和程序的方法。
改进事件响应计划，以最大限度地减少故障的影响，并在危机时刻快速恢复服务。
执行事后审查以确定故障的根本原因并防止将来发生类似事件。
开发（或监督创建）系统文档。
以下是采用SRE带来的所有优势的概述：
提高系统和服务的正常运行时间和可用性。
更好的应用可扩展性和性能。
更快、更可靠、更安全的软件交付。
重复性任务和流程的自动化。
更多容错服务，故障更少（影响更小）。
生产中的错误明显减少。
更好地了解服务运行状况。
整个SDLC中出现人为错误的可能性较小（加上开发人员有更多时间进行创新）。
深入了解产品生态系统（开发、测试、阶段和生产）。
全面提高安全性（事件预防、灾难恢复计划、风险缓解、最新安全实践、更多冗余等）。
更短的MTTR和MTTD。
在事件发生时识别根本原因的更多上下文。
提高客户满意度和保留率。
由于更少的停机时间、更好的可扩展性和资源的最佳使用，降低了运营成本。
更好地控制和使用技术债务。
SRE团队依靠各种工具来自动化流程和管理系统。以下是您可能会在任何SRE工具堆栈中找到的内容：
性能优化工具：这些平台帮助SRE团队识别和解决软件系统中的性能瓶颈。ApacheJMeter和LoadRunner是最受欢迎的选项。
配置管理工具：?SRE专家使用这些平台来自动化基础设施的供应和配置。Terraform、Ansible、Puppet、Pulumi和Chef是最常见的选项。
监控和日志记录工具：这些平台跟踪软件系统的性能和可用性。首选SRE监控工具是Prometheus和NewRelic，而Elasticsearch和Kibana是流行的日志记录解决方案。
事件管理工具：?SRE团队使用这些平台来最小化故障的影响（包括对最终用户和公司财务的影响）。PagerDuty、VictorOps和OpsGenie是三个常见的选择，而OP5、PageDuty和xMatters是首选事件警报工具。
容器化工具：这些平台使团队能够将软件打包到容器中，容器是可移植的代码包，可以在任何环境中无缝运行。Kubernetes、Rancher和Portainer是行业标准，DockerSwarm也享有相当大的追随者。
安全工具：这些平台确保系统安全并符合标准和法规。一些常见的SRE安全工具是Nessus、OpenVAS和Wireshark。
项目规划和管理工具：?SRE部门使用这些工具来协调职责并创建统一的信息源。大多数团队都依赖于Jira和Confluence的组合。
DevOps是一组实践和原则，使公司能够缩短SDLC并提高代码质量。使用DevOps，编写代码的团队还负责在生产中维护它，而负责后期制作职责的员工也参与开发。
DevOps改进了软件开发的文化和组织方面。以下是该方法的主要目标：
打破软件开发(Dev)和IT运营(Ops)团队之间的孤岛。
确保快速发布稳定、安全的软件。
减少团队从构思到代码部署所需的时间。
提高软件的整体质量。
在日常实践中，DevOps遵循精益或敏捷方法论。以下是DevOps的主要原则：
接受失败并快速失败（但永远不要重复同样的错误两次）。
通过小的增量更新逐步引入更改，而不是将大量更改部署到生产中。
争取更频繁地发布。
使用自动化来加速DevOps管道并最大限度地减少容易出错的手动任务的数量。
持续衡量成功（一些典型的DevOps指标是更改的提前期、部署频率、恢复服务的时间和更改失败率）。
DevOps解决了大型软件开发团队和项目中常见的各种问题。以下是推动公司转向DevOps的最常见问题：
新功能和更新的上市时间较慢。
软件项目中有太多的误解、代码返工和延误。
开发人员、IT运营团队成员和业务领导者之间的沟通效率低下。
模糊的软件交付流程。
代码质量和应用程序性能差。
表现不佳的开发团队。
不必要的高IT成本。
不稳定和错误的部署环境。
无效的软件测试程序。
整个软件交付过程中有太多耗时的手动任务。
开发和ITOps团队的员工保留率低。
新开发人员入职缓慢，以及开发人员离开公司时出现的问题。
DevOps团队的确切职责因组织而异，但每个团队都执行一些任务。以下是常见职责列表：
创建、维护和优化软件创建管道。
监督从开发到生产的整个软件开发生命周期。
组织冲刺（每周、每两周或每月）以管理工作流程和分配任务。
创建和配置支持软件交付过程的服务器、网络和其他组件。
编写脚本并使用工具来自动执行构建、测试和部署软件等任务。
监控错误并解决管道问题。
优化应用程序和服务性能。
识别并解决发展瓶颈。
设计、实施和领导灾难恢复策略。
跟踪系统中的所有软件和硬件组件。
确保系统安全并且所有团队都遵循DevOps安全最佳实践。
执行混沌工程（一种故意“破坏事物”并监控系统如何响应压力的策略）。
以下是您在组织中采用DevOps的主要好处列表：
更快的上市时间。
更好地使IT项目与业务目标保持一致（任何合理的IT战略计划的核心）。
更高效的软件开发团队。
提高软件质量，减少生产缺陷。
提高业务敏捷性和响应市场变化的能力。
更稳定的应用程序和服务。
大规模有效部署和管理应用程序的能力，使IT能够跟上业务增长的步伐。
一个运转良好的、计划好的软件交付管道（从概念和开发到后期制作监控和升级）。
更短的发布周期。
减少对手动任务的依赖。
改进性能监控和分析。
由于更好的应用程序性能、更少的错误和更频繁的更新，更快乐的客户和最终用户。
提高安全性并提高识别和解决软件相关风险的能力。
由于在SDLC期间重复性任务减少和人工干预需求减少，因此节省了IT成本。
始终追求改进、优化和创新的团队文化。
以下列出了组建有效的DevOps团队所需的工具类型：
源代码管理工具：这些平台使团队能够跟踪源代码、跟进问题并执行代码审查。最流行的工具是Git和Mercurial。
容器化平台：这些工具使工程师能够创建在不同IT环境中无缝运行的基于容器的应用程序。两种常用的解决方案是Kubernetes和Docker。
CI/CD工具：?CI/CD代表持续集成和持续交付，一种通过自动化频繁向用户交付更新的方法。流行的CI/CD工具的例子有Jenkins、Bamboo和CircleCI，
配置管理工具：这些平台使DevOps工程师能够自动化与基础架构相关的任务，例如配置和维护。大多数团队使用Ansible、Terraform或Puppet。
监控工具：这些解决方案帮助DevOps团队监控应用程序并对故障和风险做出及时响应。Splunk、Nagios和Raygun是常见的选择。
协作和规划工具：团队间协作是DevOps的核心，因此每个团队都有一个或多个工具来集中信息和规划项目。与SRE一样，大多数DevOps使用Jira和Confluence。
SRE和DevOps有很多相似之处（相同的工具、对自动化的强调、传统上独立团队之间的桥梁等），但这是两种截然不同的实践。
下表列出了SRE和DevOps之间的主要区别：
确保系统和应用程序可用、可扩展且高性能。 |
改进和加速软件创建，同时加强连续性。 |
生产中基础设施和系统的持续维护和操作。 |
通过CI/CD管道开发和部署软件。 |
可靠性工程、自动化、事件管理和性能优化。 |
自动化、CI、持续交付/部署和基础架构即代码(IaC)。 |
经验丰富的系统工程师和操作人员。 |
各种角色（产品所有者、开发人员、QA专家、工程师、系统管理员、发布经理等）。 |
软件工程、IT运营、监控、系统架构。 |
敏捷开发、云计算、脚本、生产自动化。 |
生产系统的管理和维护。 |
实施核心开发（自动化任务，同时最大限度地降低IT风险）。 |
核心开发（编写、测试并将软件投入生产）。 |
确保新更改不会增加生产中的故障率。 |
尽可能无缝、快速地实施新功能。 |
错误预算、SLO（服务水平目标）、SLI（服务水平指标）和SLA（服务水平协议）。 |
部署频率和故障率。 |
不参与调试（除非出现生产中断）。 |
负责解决最终产品中的任何错误。 |
通过SRE或DevOps（或两者）将IT提升到一个新的水平
SRE和DevOps是现代软件开发的两个基石实践。虽然他们侧重于IT的不同方面，但都致力于提高软件产品的可靠性和质量。选择这两种做法中的任何一种都不会出错。请记住SRE和DevOps并不相互排斥。如果您拥有足够的资源和足够的内部人才，那么同时采用这两种做法始终是一个值得做出的决定。
标签：
