白癜风医院电话 http://pf.39.net/bdfyy/bdfjc/140703/4419219.html

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

图1构建SRE架构思维导图

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

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

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

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

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

SRE是一种规范的DevOps方式。它是系统管理任务的一种思维方式，侧重于通过缩短交付周期和事件管理生命周期，并通过减少工作量来支持开发人员和运维人员来运维服务的原则。SRE团队的日常任务包括：

可用性

延迟

性能

效率

变更管理

监控和告警

应急响应

事件响应

准备工作

容量规划

—1—那么，什么是站点可靠性工程（SRE）？

SRE团队的角色是在生产“关键任务系统”中运行应用程序，并执行任何必要的事情来保持站点正常运行。它通常被定义为从事运维工作的软件工程师。SRE团队负责维护和建立其系统的服务水平指标（SLI）、目标（SLO）、协议（SLA）和错误预算，并确保满足这些指标。

他们预计将花费一定的时间进行运维工作（确保系统按期工作）并改进他们管理的系统。SRE专注于编写软件来自动化流程并减少“脏活累活”的工作量。这个“脏活累活”就是目前还未实现系统自动化并且需要手动处理的工作。

SRE的战略目标是：

使部署更加容易

提高或维持正常运行时间

针对应用性能去建设可视化能力

设置SLI和SLO以及错误预算

通过承担计算风险来提高速度

消除手动操作任务

降低故障成本以缩短新功能的周期时间

—2—SLI和SLO

服务水平目标（SLO）只是SRE团队与产品所有者或业务线（LOB）之间的协议。指标在很大程度上取决于团队管理的系统的性质。服务水平指标（SLI）是为系统定义的量化指标，也称为“我们正在度量的内容”。

这些指标取决于所管理的系统。对于典型的Web应用程序，这些指标可能是可用性、请求延迟或错误率。但是，例如HyperledgerFabric区块链应用程序可能会使用每秒背书和分类帐提交率来衡量网络的吞吐量。

SRE团队最终将管理多个系统。跨各种应用程序定义一组标准的服务水平指标将帮助团队标准化整个堆栈的监控、日志记录和自动化。

SLO是系统应该运行的“应该有多好”的目标值或范围。这些是之前定义的SLI的预期操作值。例如，区块链网络必须以不到5秒的端到端延迟来维持50到个事务提交速率的事务吞吐量。当然这也有可能存在过度设计SLI和SLO的倾向。一开始就让它们保持简单是很重要的。随着你对系统的了解随着时间的推移而增长，你可以设定更严格的目标。

—3—SLA关键业务价值

当客户对所提供的服务不满意，未能按照相关协议交付时，服务水平协议（SLA）就会发挥作用；它可能是一个系统的可靠性。SLA是产品与其最终用户之间的协议，是与客户就服务可靠性签订的合同，简单表述为“SLA=SLO+consequences”。SRE团队可能不参与定义SLA的过程，但是他们需要确保满足SLO。

SLA通常包含一段时间内服务正常运行时间的计算。

图二用9展示SRE

99.9%是三个9的正常运行时间，允许每天有1.44s的停机时间。如上表所示，每周、每月和每年的停机时间分别为10.1分钟、43.8分钟和8.78小时。

例如，SLA可以保证电信线路99.9%的正常运行时间；因此，服务只能减少0.1%的停机时间，超过这一时间将被视为违反SLA，后果将是罚款。

—4—减轻工作负担并控制SRE团队的工作量

SRE团队中总会存在一些手动、乏味的事情需要执行。在你的日常工作中，无论你是软件开发人员还是架构师，你都需要完成自己不喜欢的这类任务。这些通常是手动的、无聊的和重复的任务也可能会导致错误。SRE团队也必须执行类似的任务。这是SRE可以使用他们的开发技能并尽可能消除手动流程的一个实例。让SRE花费多达50%的时间来改进他们管理的系统是一种很好的做法。

—5—错误预算

错误预算是SRE团队用来平衡服务可靠性的工具，计算如下：

Availability=(Numberofgoodevents/Totalevents)*Errorbudget=(—Availability)=failedrequests/(successfulrequests+failedrequests)

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

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

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

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

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

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

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

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

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

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

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

—6—监控分布式系统的四个黄金指标

SRE的四个黄金指标是构建成功的监控和告警系统的一些基本原则和最佳实践。它们是大型生产应用程序的服务级别目标（SLO）的关键部分。他们的目标是帮助识别和修复你系统中的任何潜在问题。

他们主动解决你的基础架构问题，每当你的运维团队需要快速了解问题，并需要近乎实时地跟踪所有服务的延迟、流量、错误和饱和度时。

让我们简要描述每个指标，然后看看如何利用四个关键指标来监控你的系统：

延迟：延迟是信息发送方和接收方之间的时间延迟，以毫秒（ms）为单位。而原因往往是由于数据包丢失网络拥塞和网络抖动造成的，称为“数据包延迟差异”延迟对客户体验有直接影响，转化为成功请求的延迟和失败请求的延迟。

流量：流量是系统工作量带来的压力。它通过每秒查询数（QPS）或每秒事务数（TPS）来衡量。企业通过数量来衡量这一点：关键绩效指标（KPI）是在给定时间来到站点的人数。这与商业价值有直接关系。

错误：错误是根据整个系统中发生的错误来衡量的。被认为是服务错误率的重要指标！有两类错误：显式错误，如失败的HTTP请求（个错误代码，例如）；隐含错误是成功的响应，但内容错误或响应时间长。

饱和度：饱和度定义了服务的过载程度。它衡量系统利用率，强调服务的资源和整体容量。这通常适用于CPU利用率、内存使用、磁盘容量和每秒操作数等资源。仪表板和监控警报是帮助你密切

转载请注明:http://www.aideyishus.com/lkjg/912.html