那个没被云原生做掉的运维转头就做了SRE

发布时间：2022-06-17 14:47 所属栏目：124 来源：互联网

导读：Google在10年前创造了SRE这个工种。SRE，Site Reliability Engineering的缩写，其中site是指Website，可以翻译为网站可靠性工程。几年前资深Google SRE Chris Jones等人联合撰写了《Google SRE: How Google runs production systems》，首次向外界解密了Goog

　　Google在10年前创造了SRE这个工种。SRE，Site Reliability Engineering的缩写，其中site是指Website，可以翻译为网站可靠性工程。几年前资深Google SRE Chris Jones等人联合撰写了《Google SRE: How Google runs production systems》，首次向外界解密了Google的生产环境以及整个SRE的方法论。那么如何从零搭建一套SRE体系呢？下面内容主要介绍了站点可靠性工程（SRE）以及如何在系统扩展时监控和保持系统快速可靠。

　　在云时代，客户体验是所有重要企业的新口号，即使命宣言。客户体验、可用性和可访问性是在端决定的，在这里站点应当始终可用 [24/7/365]。对用户来说，可靠性才是最重要的；一个未使用的应用程序对用户和企业毫无价值。

　　如今，每家公司都在努力推动科技变革。公司业务战略都围绕云功能构建。这对他们来说是一项重大的运维挑战。站点性能下降、客户体验的下降都将导致现金、收入和竞争力的损失，并导致传统运维无法应对可观察性的大问题（包括实时监控和告警）。

　　为什么存在站点可靠性工程（SRE）？敏捷运动提升了跨职能团队之间协作的重要性，这催生了DevOps。

　　DevOps是关于深入研究自己组织的具体问题和挑战的。它还与速度、效率和质量有关。从本质上讲，它是一种以实现组织的预期结果的文化、一种运动、一种价值观、原则、方法和实践。

　　这种速度也造成了一定的不稳定性，开发人员的行动速度比以往任何时候都快了，但却给运维团队带来了挑战。IT运维团队没有能力应对这样的速度，这让他们遇到了瓶颈和严重的积压，导致生产中产生了不稳定的因素，结果使系统变得不可靠。因此，Google提出了对SRE的要求：“一群能够将工程专业知识应用于运维问题的开发人员。”

　　误差预算是100减去服务的SLO。99.99%的SLO服务有0.01%的误差预算。

　　错误预算是SLO的另一个例子，其中每个服务都受其带有惩罚条款的服务级别协议的约束。它衡量你有多少空间来满足你的另一个SLO。

　　例如，如果你有一个服务级别指示器，它显示99.99%的交易必须在5秒内提交记账，则只有0.01%的交易可以超过5秒。一个主要版本发布后，你可能会意识到系统运行开始缓慢，突然耗尽你所有的错误预算。

　　请记住，变更是中断的最重要原因，发布是变更的主要来源。如果你一直超出你的误差预算，你将需要重新审视你的一些SLO和过程。

　　你是否在单个版本中引入了太多更改？请保持简单，并将你的版本分成更小的需求变更。

　　SLO是否过于严格？你可能需要协商并放宽SLO。

　　你的发布过程中是否有任何导致问题的手动步骤？尝试引入自动化和测试。

　　系统的架构是否容错？硬件故障、网络包丢失、上游或下游应用程序可能会出现异常行为。你的系统架构应该能够容忍这些故障。

　　开发团队是否解决了技术债问题？在急于发布新功能时，技术债常常被忽视。

　　你的监控和告警是否抓住了主要指标？不断增长的队列规模、网络速度变慢、潜在客户变更过多等都可能导致下游事件。

　　你是否定期监控日志并保持其清洁？你的日志中可能存在不会立即导致问题的警告。但是，再加上其他基础设施问题，这些告警可能会导致重大事故。

（编辑：ASP站长网）

那个没被云原生做掉的运维 转头就做了SRE

那个没被云原生做掉的运维转头就做了SRE