后端开发教程 - Java、Spring Boot 实战 - msg200.com
SRE 及其任务详解✅
SRE 是如何诞生的？为什么需要 SRE？🤔
什么是 SRE？- 官方定义
什么是系统可靠性？为什么它如此重要？🧐
如何使系统可靠？
SRE 实践：SLA 和错误预算
SRE 的任务和职责
谁在做 SRE？SRE 的角色
SRE 与 DevOps
SRE 在 DevOps 乃至整个软件开发领域正成为一个非常流行的术语。可能有些人已经听说过它，但并不清楚它到底是什么。
因此，本文详细介绍了SRE或站点可靠性工程的真正含义，旨在澄清围绕它的所有问题和疑虑。
这是我的新 YouTube 视频的书面版本✍️🙂
目录📝
- 为什么需要 SRE？
- 什么是 SRE？- 官方定义
- 什么是系统可靠性以及它为何重要？
- 如何使系统可靠？
- SRE 实践：SLA 和错误预算
- SRE 的任务和职责
- 谁在做 SRE？SRE 的角色
- SRE 与 DevOps
首先，我建议你先读一下我最近写的 DevOps 文章，里面我详细讲解了 DevOps。这样你肯定能更容易理解本视频的主题😊
SRE 是如何诞生的？为什么需要 SRE？🤔
在传统的软件开发流程中，我们将开发和运维视为两个独立的团队。他们各自有自己的目标：
- 开发人员：希望尽快向最终用户推送应用程序更改
- 运营：希望保持应用程序稳定
因此，运营部门对每个变化都非常谨慎，这导致了这两个角色之间的利益冲突，迫使他们相互对抗而不是合作：
而 DevOps 的出现正是为了解决这个问题。然而，尽管 DevOps 加快了发布流程，但这些版本并不像 DevOps 原则所期望的那样稳定。此外，DevOps 团队中也没有专门的职位或人员全职负责维护系统的可靠性。
这就是对 SRE 和站点可靠性工程师作为独立角色的需求产生的缘由。💡
那么什么是 SRE？
什么是 SRE？- 官方定义
SRE 是由 Google 的软件工程师 Ben Traynor 概念化的，他的任务是管理一个由其他软件工程师组成的小团队来做以前的运营工作。
而按照他自己的定义：
当您将操作视为软件问题并配备一群软件工程师时，就会发生 SRE。👩💻🧑🏻💻
其核心是：
但这个定义当然过于模糊和高深，以至于我们无法真正理解它在实践中是如何实现的。🧐 所以，让我们逐步分解并分析这个定义的各个部分。👍
什么是系统可靠性？为什么它如此重要？🧐
首先，我们想要保持可靠性的系统是什么？或者说，在这个定义中，“系统”究竟意味着什么？
什么是系统？
系统包括服务器、基础设施和平台，也就是应用程序运行的整个部署环境。
什么是可靠性？
那么可靠性到底是什么？为什么保持系统可靠性如此重要？🤔
不可靠的服务⛔️
想象一下，你每天都要处理电子邮件，而你的电子邮件提供商每周都会宕机一次，或者你的网上银行应用程序宕机了，无法定期访问。这些都属于不可靠的服务。🤨 你无法指望它在你需要的时候随时可用。
可靠的服务❇️
另一方面，许多流行的服务（如 Gmail、Twitter、Youtube 等）很少无法访问。👏 所以这些系统非常可靠。
但问题是，用户通常不会注意到系统的可靠性。🙄 只有在出现问题、服务瘫痪时，它才会显现出来。你还记得最近 Facebook、Instagram 和其他相关服务引发的重大新闻中断吗？还有 AWS 服务器中断，它还影响了托管在其上的其他应用程序，这又是怎么回事呢？
当然，当它发生时，每个人都会注意到并知道。因此，产品或服务越受欢迎、规模越大、使用量越大，它的影响就越大👀，如果服务中断，这意味着他们的团队应该更加担心其可靠性。
为什么可靠性很重要？
中断或系统不稳定会带来什么影响？对大多数服务来说，这会导致大量客户不满，并造成巨额收入损失。
想象一下，一家网店在节假日期间停业，或者一家网上银行因为流量过载而无法使用。这意味着大量的业务损失，因为人们无法在该商店订购任何东西。
如何使系统可靠？
好的，我们知道系统需要可靠，但是我们如何才能使系统可靠，或者换一种问法：
是什么让系统不可靠，又是什么影响了它的可靠性？🤔
系统变得不可靠的主要原因是，当你对系统进行更改时⚡️：
比如改变一些东西：
⚡️在基础设施中
⚡️应用程序运行的平台
⚡️应用程序本身及其服务
⚡️等等
这些变化可能会造成中断并破坏整个设置。
糟糕的解决方案👎🏼
为了确保系统可靠性，我们可以规定不允许更改或限制更改次数🙅🏻♂️，但这实际上会限制业务。我们希望对我们的应用程序进行更改和改进，使其变得更好，提升其商业价值，保持竞争力等等。💪
因为如果我们的竞争对手推出了新功能，我们就需要跟上，而这正是软件开发人员关注的主要内容，即做出这些改变和改进。
但另一方面，如果应用程序无法访问，对业务来说也是不利的，因为即使你拥有很棒的功能，却没人能用。而运维的工作就是处理这个问题，确保应用程序可访问。
这意味着开发人员希望快速发布，而运维人员希望保持稳定性。因此，传统上，开发人员会进行更改，运维人员会使用数百个检查表和机制进行分析，以确保更改不会影响系统：
整个分析和评估过程会拖慢发布流程，而这一直是传统软件开发方式面临的主要挑战。而这正是DevOps 和 SRE 试图解决的问题。🚀
那么 SRE 的具体解决方案是什么呢？💡
SRE试图自动化分析和评估变更对系统可靠性的影响的过程。自动化意味着无需核对清单或与运营团队讨论是否发布变更，也无需讨论涉及哪些威胁和风险：
相反，评估基于自动化流程，这使得发布更改既快速又安全。🚀
SRE 实践：SLA 和错误预算
那么，自动评估是如何完成的呢？🤩
它的工作原理是使用所谓的SLA。那么什么是 SLA？SLA 本质上是一个系统对其最终用户的可靠性。也就是说，它能运行多久，能宕机多久。它以百分比表示。
一个始终正常运行、永不宕机的服务，就拥有 100% 的 SLA。💯
无需 100% 可靠性
现在你可能会想：“任何服务当然都应该 100% 可靠，这难道不是一个理所当然的目标吗？” 👀
其实并非如此。首先，实现 100% 的可靠性非常困难，而且世界上真正需要 100% SLA 的服务非常少。
例如，如果您的互联网提供商或客户的设备本身并非 100% 可靠（大多数笔记本电脑、手机等都是如此），那么您的服务也无需如此。它可以以与底层网络或设备相同的速率提供最高可用速度。💡
在这种情况下，三个九、四个或五个九的可靠性可能就足够了，这样用户甚至不会注意到存在问题。👌
你越接近 100%，就越需要付出努力，但正如你所见，这是不必要的努力，因为对于大多数应用程序来说，你不需要 100% 的 SLA
SLA 示例
例如，您可以定义有关应用程序可访问性的服务级别协议：来源：https ://en.wikipedia.org/wiki/High_availability
例如，99% 的应用程序可访问性 SLA 意味着系统一年内最多可以宕机3.65 天。5 个 9 或 99.999% 的 SLA 允许应用程序一年内最多有5 分钟无法访问，因此其余时间应用程序应该可以正常工作。
您实际上可以定义多个这样的协议或 SLA，而不仅仅是系统的可访问性或可用性。
其他 SLA 示例：
- 应用程序响应时间
- 错误率
例如，如果您有一个应用程序每周处理一百万个请求，且 SLA 为 99%，则您定义其中 990 000 个请求将会成功。
谁定义这些 SLA？💁🏻♀️
好了，现在你可能想知道这些 SLA 是谁定义的？那么，究竟是谁决定了这百万个请求中有多少个请求必须成功，或者应用程序允许多少停机时间？谁来做这些决定？
由于这一决策会影响最终用户及其用户体验，因此业务人员自然也会参与其中。因此，业务人员会与SRE 和 DevOps 工程师等工程师一起决定他们希望为其应用程序定义哪些服务级别协议：
根据行业基准、竞争、用户反馈等，业务人员将在更高层次上定义所需的 SLA ，然后工程师将在技术层面上定义它们，并确保将它们集成到他们的 DevOps 和 SRE 流程中。
错误预算
正如我所提到的，可用性 SLA 定义了服务可用多长时间或允许该服务停机多长时间，而允许的停机时间也称为错误预算：
在 SRE 中，团队可以“花费”错误预算来做出不可靠的更改。所以，基本上，错误预算意味着，我们的系统可以承受这么长时间的停机，而不会造成业务损失、客户不满等等。
调节释放速度的方法⚖️
所以SLA 就像一个晴雨表，你可以根据系统所需的可靠性来调高或调低它。当然，SLA 越接近 100，你就越需要付出努力来保证系统的可靠性。
现在，一旦定义了 SLA，就可以根据这个数字来衡量系统性能。
⛔️ 如果系统可靠性超出了 SLA 的允许范围：那么 SRE 团队将投入更多资源来确保系统可靠性。同样是因为我们已经超出了允许的停机时间。在系统恢复到定义的 SLA 范围内之前，允许的更改将减少：
✅ 另一方面，如果系统的性能远远超出定义的 SLA：SRE 团队中的开发人员可以发布更多更改。
因此，这是一种调节开发人员发布速度的简单方法。⚖️如果我们提高 SLA，发布速度就会变慢，反之亦然：
SRE 的任务和职责
1）自动化——为运营方面创建自动化流程👏
SRE 或站点可靠性工程师是创建自动化流程来计算和评估服务是否在 SLA 范围内的人。
因此，现在发布的策略不再是运营人员用来决定是否发布的无休止的清单，而是由 SRE 帮助设计可以自动评估 SLA 的流程。✅
2）配置监控和日志记录（系统性能的可观察性）🔎📈
现在，当然要衡量我们系统的性能以及服务是否在 SLA 范围内，我们需要对我们的系统进行适当的监控。
因此，SRE 任务和职责的另一个重要部分是配置适当的系统监控和日志记录，以了解内部发生的情况。
3）配置监控和日志记录（用于检测问题的可观察性）🔎📉
我们之前说过，大多数应用程序的 SLA 并非 100%，这意味着我们接受它无法 100% 正常工作。所以总有一天，我们会出现服务中断 😱
现在的问题是，当发生中断时我们该怎么办？或者说，我们该如何做好准备？而这正是 SRE 的另一项重要任务和职责所在。
第一个是监控和警报，我已经提到过了。它除了能让你清晰地衡量系统性能之外，更重要的是，它还能帮助你在问题发生之前或发生时尽早发现任何迹象，并及时向团队发出警报：
4）开发定制服务以实现此目标
现在，整个配置的另一个重要部分是，当问题被警告时，理想情况下团队中的合适人员会收到消息，警报消息应该包含快速识别和修复问题所需的所有信息。
不要使用：
❌"something is wrong in the cluster"
更详细的信息，例如：
✅"service a in cluster b is throwing 500 error"
所以你知道确切的：
👉哪个服务有问题
👉在哪个集群中以及
👉这个问题到底是什么
因此，警报信息越详细越好！
在许多情况下，SRE 会开发自己的定制服务来实现其系统的适当监控警报和日志记录配置。
5）提供随叫随到的支持☎️
SRE 做的另一件事是随叫随到的支持。
基本上，当出现问题，用户需要实时支持时，总有人会负责，那就是值班支持团队。将 SRE 纳入这个支持团队有几个好处：
- 它可以帮助人们真正地看到并理解将会出现哪些问题
- 支持如何处理这些问题？
- 可以进行哪些改进来使支持流程更加高效？
例如：
- 警报消息和日志是否有足够的信息来快速识别问题和原因？
- 哪些问题发现得太晚了？
- ETC
因此，总体而言，SRE 的主要目标是确保发生中断时的范围很小，这意味着
- 👍 中断持续的时间不长，而且很快就修复了
- 👍 受此次中断影响的人数和服务较少
6）事后回顾
修复问题或中断并不意味着 SRE 团队工作的结束。我们希望利用这次中断作为吸取教训的机会，当然也希望避免将来再次发生类似的情况。
因此，SRE 的一个原则就是进行所谓的“事后分析”（Post Mortem），拉丁语意思是“死后”。所以，在 SRE 术语中，它指的是“问题发生后”或“中断后分析”。
这包括彻底的分析，意味着要花时间真正深入了解问题：
但当然，在分析过程中，保持无可指责是非常重要的，这是事后分析的重点之一，以鼓励人们承认自己和他人的错误并从中吸取教训✅
最后，记录一切以供将来参考非常重要！
谁在做 SRE？SRE 的角色
现在你可能会想：
“软件开发人员还需要学习多少？他们已经必须了解所有这些软件开发技术，现在他们还必须接手运营任务并学习所有这些运营工具？” 🤯
SRE 作为其自身的角色
这就是为什么我们设立了 SRE 作为其独立职位。因此，我们需要一个专职人员，全职负责维护系统的可靠性：
因此，在许多项目中，除了开发人员之外，还有 SRE 团队，也就是新的运维团队。SRE 本质上是一个负责运维的团队，两个团队的目标都是一样的：确保系统符合既定的 SLA 要求。
因此，SRE 团队负责维护和处理自动化交付操作以及各种自动化，以帮助开发人员安全、快速地发布他们的更改。🚀
软件开发人员作为 SRE
然而，也经常会有SRE 和软件开发人员组成一个团队，其中 SRE 也负责软件开发工作。这意味着站点可靠性工程师也必须了解软件开发，这一点与 DevOps 工程师不同。
但在这两种情况下，正如你所看到的，我们都是从传统的软件开发方式开始的，将开发和运维分开，并提供相反的激励措施，而通过 SRE，我们为开发人员和运维人员提供了相同的激励措施，并将他们放在了同一边。💙
SRE 与 DevOps
最后，该领域主要讨论的问题之一是：SRE 和 DevOps 工程师之间有什么区别，或者这两个概念之间通常有什么区别？
如果您已经看过我的“什么是 DevOps”视频，那么您就会知道 DevOps 有两个定义：
- 原始定义更高层次、更宽泛，并没有具体说明 DevOps 应该如何实施
- 还有一种更实用的，随着时间的推移，它逐渐发展出自己的 DevOps 工程师角色。
因此，当我们将 DevOps 与 SRE 进行比较时，了解我们使用哪种 DevOps 定义进行比较非常重要？
1. 首先 DevOps vs. SRE 更广泛的定义
DevOps 是一个更高级的概念，它定义了实现自动化精简发布流程需要做什么，而 SRE 则更具体地说明了如何精确地实现这个过程以及如何实现 DevOps 原则。
很多人会说SRE 是 DevOps 概念的具体实现：
2. 实用 DevOps 与 SRE 的比较
但正如我们所见，DevOps 本身也变得更加实用，拥有其独特的角色、特定的技术和实现方式。那么
，两者之间的比较是什么呢？🤔 在许多公司中，这种实用的 DevOps 实施更加注重应用程序变更的交付速度。当然，尽管快速发布和高质量代码是 DevOps 原则的一部分，但许多 DevOps 团队在实践中似乎更注重速度而不是可靠性。
因此，作为DevOps 的一个重要补充部分，SRE 应运而生，秉承着相同的原则和目标，即快速发布高质量的代码，但顾名思义，它更注重可靠性和保持系统稳定，同时允许快速更改：
所以，SRE 本身就是一个角色，它有一套自己的工具来确保系统可靠。所以，这两者曾经是并行发展的，现在常常被视为同一事物的两个方面。团队同时拥有 DevOps 工程师和 SRE 来帮助实施 DevOps 原则的情况并不少见。
现在我希望您从这篇文章中学到了很多东西，并且我能够回答您关于 SRE 的所有问题。🙂
喜欢、分享并关注我😍以获取更多内容：
鏂囩珷鏉ユ簮锛�https://dev.to/techworld_with_nana/sre-and-tasks-of-an-sre-explained-3ah9