QCon 全球软件开发大会(北京站)门票 9 折倒计时 4 天,点击立减 ¥880 了解详情
写点什么

Google 诠释其它企业在实施 SRE 中的错误

2018 年 7 月 05 日

在近期的 DevOps Enterprise Summit 伦敦大会上,Google 客户可靠性工程师 Stephen Thorne 做演讲澄清了 SRE(站点可靠性工程, Site Reliability Engineering )的概念,并指出为什么很多企业并不了解 SRE 的基本前提和优点的原因所在(此处可下载演讲幻灯pdf 文件)。Thorne 在一些企业中看到的主要误解,在于将SLO(服务级别目标, service level objectives )和 SLA(服务级别协议, service level agreements )混为一谈。SLO 侧重于早期的故障检测,而 SLA 通常用做已发生故障的经济补偿,它不强制错误预算( error budgets ),也不会让 SRE 团队花费至少一半的精力去改进系统和工具,而是让人们继续疲于奔命,因此也称为在生产环境中“灭火”。

Thorne 补充说,SLO 是先期发现问题的基础,理想情况是先于客户感受到问题的影响。好的 SLO 应符合客户的输出(例如服务可用性、响应时间等),从而反映出一个系统(行为)是否满足用户的需求。系统监视资源的使用情况(例如 CPU 利用率、网络吞吐量等),但这些度量本身不应做为 SLO。Thorne 认为,“如果客户满意,那么就满足 SLO”。Google 的一些典型 SLO 包括:

  • 每月运行时长 99.9%(即每月只有 43 分钟宕机时间)。
  • 每月 99.99% 的 HTTP 请求成功返回“200 OK”。
  • 50% 的 HTTP 在 300 毫秒内返回。

另一方面,SLA 通常在客户已对服务产生不满意时才发挥作用,因此 SLA 并不会主动提高系统的可靠性。此外,SLA 可能会引发错误的行为。例如,如果同时面对一个两小时修复电子邮件问题的 SLA 和一个一天内修复生产系统严重问题的的 SLA,按规程会导致首先处理一个(或多个)电子邮件问题。但是很显然,生产系统出现的问题应该得到优先处理。

Thorne 警告说,仅定义 SLO 是不够的。错误预算策略是通过设置明晰的操作规则(而非货币补偿),在系统接近于 SLO 的阈值之前达成 SLO。一旦系统无法满足用户的需求,SLO 也可以最大限度减少运维和开发之间的对抗。Thorne 指出,“错误预算是存在于完美可靠性与 SLO 之间的差距”。Google 的典型错误预算政策是,一旦应用用尽其错误预算(例如,本月已超出 43 分钟的宕机时间预算),就禁止启动新功能;或者根据前期事故后分析(post-mortem analysis)所给出的更正操作,专门建立一个 Sprint。

然而 Thorne 强调指出,一些适用于 Google 的做法并非适用于每个组织。“SRE 需要 SLO,结果是在可接受的失败水平与必要的成本和交付速度之间取得平衡”。准确的 SLO 和政策必须适用于特定的组织,而不是复制和粘贴 Google 的做法,并且应该是聚焦于不断改善客户体验,而不是设定一些可能适得其反的崇高目标或严厉惩罚。Thorne 在演讲中给出了一个例子,一个组织在努力降低推荐系统的处理时间。原先用户平均在 6 小时后回访网站,才会看到这些推荐情况。一个适当的 SLO 将在 6 小时内处理所有建议,这意味着务可以省下三位解决响应时间慢“问题”的非全职工程师工作。

Thorne 提出 SRE 的第三个关键问题,即 SRE 团队应能够平衡日常(通常是无计划的)运维和规划工作间的工作量,以降低人员的操劳(也称为“灭火”)。在 Google,这意味着至少有 50%的 SRE 是用于项目工作,包括尽早研判新系统的架构,发现其中的弹性反模式(resiliency anti-pattern),并避免此后更多的操劳;改进监控,自动执行重复的任务,或协调故障后纠正措施的实施。

Thorne 进一步明确给出了一些实现 SRE 的反模式。例如,在并未率先让 SRE 原则和机制(SLO、错误预算政策和平衡工作负载)落地的情况下,仅是将运营团队重新命名为 SRE 团队,或仅是雇佣一些 SRE 工程师。

Thorne 认为 SRE 的成功实施之路具有 5 个关键步骤:

  1. 根据场景定义聚焦于客户的 SLO;
  2. 定义合理的错误预算策略;
  3. 雇佣(内部或外部)SRE 人员,并在领导层支持的情况下对他们授权;
  4. 支持 SRE 优化调整 SLO,并强制执行错误预算策略;
  5. 将任务关键系统的可靠性责任指定给 SRE 团队,其它系统的责任指定给相应的开发团队。

Google 在将自身的经验教训汇总为《 SRE 宝典——Google 生产系统是如何运维的》一书之前,就已在企业内部开发并扩展 SRE 原则达数年之久。Throne 提及,Google 将于月末推出相应的《 SRE 工作手册》一书。

查看英文原文: Google Explains Why Others Are Doing SRE Wrong

2018 年 7 月 05 日 11:41681
用户头像

发布了 376 篇内容, 共 94.5 次阅读, 收获喜欢 216 次。

关注

评论

发布
暂无评论
发现更多内容

架构师训练营 -week5 命题作业

J.Smile

极客大学架构师训练营

一致性Hash算法——架构师训练营第5周

架构 极客大学架构师训练营 一致性Hash算法 第5周作业 负载均衡算法

面试中必问的JVM应该怎么学(面试题含答案)

猿灯塔

区块链+金融赋能高原特色农业重点产业

CECBC区块链专委会

打破信息孤岛 区块链+咖啡 特色农业 咖云链

ConcurrentHashMap里面也有死循环

无予且行

Java jdk Java 面试 jdk8

80%会问到的18个Dubbo面试题,快来看看你都掌握了吗

小新

Java 程序员 架构 面试 dubbo

游戏夜读 | 简单认识一下爬虫

game1night

Python设计模式 单例模式

早睡蟒

Python 面向对象 设计模式 单例模式

从“金 木 水 火 土”到分布式系统架构设计

常平

分布式 架构设计

如何站在架构师的角度做框架

小新

Java 集合 框架

一篇告诉你什么是Spring

JavaPub

spring

分布式系统架构设计 - 一致性hash算法及其改进

常平

分布式 架构设计

spring 那点事儿——让你少走弯路

爱java爱自己

Spring Cloud Spring Boot

一文搞懂分布式消息中间件设计

小隐乐乐

消息队列

总结

Mr.Monkey

程序人生 | 春风得意马蹄疾,一日看尽长安花

YourBatman

Java 程序人生 大龄程序员

PHP实现一致性哈希算法

任小龙

授权专利争夺正当时

CECBC区块链专委会

数据隐私 授权专利 平台应用服务

Java架构-Apache POI Excel

猿灯塔

第一个Spring程序(代码篇)

JavaPub

spring

唯一路径的动态规划解法,阿里巴巴架构演化路径 John 易筋 ARTS 打卡 Week 07

John(易筋)

动态规划 ARTS 打卡计划 系统架构演化 唯一路径

分布式系统架构设计 - 从CAP到PACELC

常平

架构 分布式

架构师训练营第五周学习总结

张明森

ARTS|Week 6 合并有序列表、团队、MIME类型和IIS

Puran

LeetCode ARTS 打卡计划

极客大学架构师训练营 系统架构 消息队列 数据库备份 第10课 听课总结

John(易筋)

负载均衡 极客时间 极客大学 极客大学架构师训练营 消息队列

架构师训练营总结-20200705

caibird1984

极客大学架构师训练营

Git【入门】这一篇就够了

JavaPub

spring

LeetCode | 7. Merge Two Sorted Lists 合并两个有序列表

Puran

Python C# 算法 LeetCode

在Windows上使用IIS来托管站点

Puran

windows IIS Server

第五周作业

秦宝齐

学习

ARTS Week6

丽子

边缘计算隔离技术的挑战与实践

边缘计算隔离技术的挑战与实践

Google诠释其它企业在实施SRE中的错误-InfoQ