凭借 AWS DevOps 和 Google SRE 的实践经验，我想就这两个系统的比较提供我的见解。事实证明，两者都可以有效地为云提供商提供可扩展且可靠的服务。但是，管理不当会导致团队和组织无法正常运作。在本文中，我将简要概述 AWS DevOps 和 Google SRE，研究它们何时最有效，深入探讨要避免的潜在陷阱，并提供最大限度发挥各自优势的技巧。
DevOps 是一个广泛使用的术语，有多种解释。在本文中，我将重点介绍 AWS DevOps，根据AWS 博客，它将开发和运营团队合并为一个单元。在这种模式下，工程师的工作贯穿整个应用程序生命周期，从开发到部署再到运营。他们拥有广泛的技能，而不是局限于特定的功能。
因此，编写代码的工程师负责运行服务、监控服务和响应事件。在实践中，每个团队可能都有自己的方法，但在实践上存在某种程度的统一，例如CI/CD、事件预防和无过错事后分析。就个人而言，我认为 AWS 在我合作过的所有组织中拥有最有效的运营文化。
当 DevOps 得到有效实施时，它可以提供多种好处，尤其是在开发的早期阶段。对于希望将新产品快速推向市场的初创企业，DevOps 可以提供速度和敏捷性。同样，推出新服务或产品的老牌公司也可以从 DevOps 模型中受益。
虽然是同一个团队在操作系统，但可能会有一些专业化，一些团队成员更专注于运营，而其他人则更专注于开发。随着时间的推移，随着产品的成熟，团队可能会分裂，平台团队（类似于 SRE）与开发团队（类似于 SWE）一起工作。
然而，开发工程师对操作活动的集成和重叠以及操作工程师对系统的深入理解仍然很紧密。这种紧密的反馈循环可以让所有团队成员更好地了解系统的运行方式、其局限性和客户体验。
这反过来又使决策制定和迭代周期更快。这可能是AWS在市场上占据主导地位及其提供的大量产品的一个促成因素。
一般来说，操作可以分为三大类：
虽然服务运营通常被软件工程师视为令人愉快的事情，但事件预防可能并不那么吸引人，而且事件响应可能变得势不可挡，尤其是当工程师负责开发和运营时。他们花在运营任务上的时间越多，他们用于开发的时间就越少，他们对自己的工作就越不满意。
这可能会导致工程师过度劳累、高流动率、工作质量下降以及运营工作量增加的恶性循环。
站点可靠性工程（SRE）是谷歌开发的一门学科，旨在提高软件系统的可靠性和可用性。它涉及一个专门的 SRE 团队，他们只专注于这些目标，而软件工程师 (SWE) 则负责编写代码。SRE 带来了一套正式的原则和术语，例如服务水平指标 (SLI)、服务水平目标 (SLO)、错误预算、工作量等，以确保软件可扩展并满足性能标准。
当 SRE 得到有效实施时，它可以在衡量客户体验方面提供高水平的标准化和一致性。这种方法不一定会产生更可靠或更高效的服务，但它可以确保在多个产品中遵循最佳实践。通过拥有专门的 SRE 团队，它减轻了软件工程师的运维负担，他们不再需要日以继夜地处理运维问题。因此，软件工程师可以更好地平衡工作与生活，而 SRE 团队则确保以一致且高效的方式满足运营需求。
在 SRE 模型中，软件工程师 (SWE) 从运维负担中解放出来；然而，这可能会导致缺乏对系统工作的了解，从而导致风险评估模糊，并且对其代码在不同条件下的行为方式的理解有限。另一方面，SRE 可能因过多的页面而负担过重，这会因过度规避风险而减慢开发速度。反过来，这会影响 SWE，他们会变得规避风险并努力获得 SRE 的批准。
两个团队之间的这种脱节，SWE 将服务视为黑盒，而 SRE 缺乏对代码和意图的理解，可能会导致一个半功能组织，其中将代码部署到生产中可能需要数月时间，而且大多数计划从未见过白天的光。
答案并不那么简单。DevOps 和 SRE 都没有天生的好坏之分，它们都有自己的优点和缺点。
就 DevOps 而言，确保工程师不会因操作任务而负担过重，并确保他们在工作与生活之间取得健康的平衡至关重要。这可以通过对工具的适当投资和对质量输出的关注来实现。此外，重要的是要在开发和运营之间取得平衡，以避免出现两者中的任何一方变得更占主导地位并阻碍另一方进步的情况。
另一方面，SRE旨在减轻软件工程师的运维负担，并保护他们免受事件管理和其他运维任务的干扰。但是，重要的是要避免 SWE 和 SRE 之间的脱节，并确保每个团队都对系统有全面的了解。此外，SRE 不仅应该关注运营指标，还应该对交付感兴趣，并且应该参与其中。
换句话说，DevOps 和 SRE 都有自己的优点和缺点，最好的方法将取决于您组织的需求和文化。关键是要避免每个系统的陷阱，并争取一种平衡有效的软件交付方式。
平衡速度和稳定性是 DevOps 与 SRE 辩论中的一个关键方面。公司采取的方法将取决于其阶段和目标。初创企业通常优先考虑速度和敏捷性，以便将其产品快速推向市场，这使得 DevOps 成为理想的选择。随着公司的发展，稳定性和可靠性对于维护客户信任变得更加重要，使 SRE 更适合。
然而，从DevOps到 SRE 的转变并不意味着放弃速度和敏捷性原则。通过确保 SWE 和 SRE 之间的密切协作，有效的 SRE 模型仍然可以在可靠性和速度之间取得平衡。SWE 推动开发过程，而 SRE 确保系统的可靠性和可扩展性。定期换帽轮换和联合运营会议可以使两个团队保持紧密联系，并与交付和稳定性目标保持一致。这种方法提供了两全其美的解决方案。
DevOps 和 SRE 之间的选择并不简单。最佳方法取决于贵公司的情况及其需要。通过结合两者的优势，您可以找到速度和稳定性之间的最佳平衡点，确保您不断交付出色的软件。为了使这成为可能，技术和运营工程师的密切合作至关重要。分担责任和定期开会有助于让每个人都保持一致，专注于交付和保持平稳运行。这可以使 DevOps 和 SRE 都有效地工作。
关注微信
