杂谈SRE的重要性

辛弃疾奋笔
269 阅读14分钟

SRE的职责

SRE在Google不负责某个服务的上线、部署，SRE主要是保障服务的可靠性和性能，同时负责数据中心资源分配，为重要服务预留资源，SRE并不负责某个业务逻辑的具体编写，主要负责在服务出现宕机等紧急事故时，可以快速作出响应，尽快恢复服务，减少服务掉线而造成的损失。（高效运维）

加纳利空难 vs 生产环境故障

加纳利空难

加纳利空难（Canary Islands Airport Disaster）是发生在1977年3月27日的一起严重空难，涉及两架波音747客机的相撞。以下是事件的具体过程和关键点：

事件背景

  • 地点：发生在西班牙加纳利群岛的特内里费南部机场。
  • 参与航空公司：荷兰皇家航空（KLM）和潘美航空（Pan Am）。

事件经过

  1. 天气状况：当天机场能见度差，浓雾弥漫，导致航班无法正常起降。
  2. 延误：由于机场关闭，两架飞机在跑道上等候，KLM 航班决定在没有明确塔台许可的情况下，提前起飞。
  3. 误判与沟通：塔台与KLM飞行员之间的沟通存在误解，导致KLM飞行员误以为已获得起飞许可。而此时，潘美航空的飞机正停在同一条跑道上。

关键事件

  • 相撞：KLM飞机在未确保跑道清空的情况下起飞，导致与潘美航班相撞。结果造成大量人员伤亡。

伤亡情况

  • 死亡人数：此次空难导致583人遇难，是航空史上最致命的空难之一。

影响与后果

  1. 航空安全改进：该事故引发了航班间和空管之间沟通流程的重大改革，提高了航空安全标准。
  2. 培训与规范：后续对飞行员和地面控制人员的沟通与程序培训进行了加强，以防止类似悲剧再次发生。

总结：加纳利空难是一起因沟通不畅和误判造成的重大航空事故，强调了航空安全管理和操作规范的重要性。

生产环境故障

在生产环境中，故障可能会导致重大影响和损失。以下是几个真实的生产环境故障实例及其相关数据：

1. GitHub 服务中断（2018年10月）

  • 故障描述：GitHub 遇到了一次大规模的服务宕机，导致用户无法访问其代码库。
  • 原因：由于数据库升级过程中出现了问题，导致 GitHub 的一部分功能遭到影响。
  • 影响：GitHub 宣布服务中断超过了 6 小时，期间数百万用户无法访问其平台。

2. Amazon S3 中断（2017年2月）

  • 故障描述：在2017年，亚马逊的 S3 存储服务在美国东部地区发生了大规模故障。
  • 原因：故障是由于一名工程师在进行后台服务维护时，错误地删除了部分服务器。
  • 影响：该故障影响了大约 1500 个网站，包括 Netflix、Twitter 和 Quora，造成数小时的服务不可用。

3. 马航 MH370 航班失联（2014年3月）

  • 故障描述：马航 MH370 航班在执行从吉隆坡到北京航行时失联。
  • 原因：机载通信和导航系统故障及飞行员行为不明。
  • 影响：航班上239人失踪，至今未找到残骸，成为航空史上最神秘的事故之一，导致对民航安全的广泛审视和多项改进。

4. Slack 服务中断（2020年1月）

  • 故障描述：Slack 在2020年出现服务中断，导致用户无法发送信息或进行语音通话。
  • 原因：数据中心问题，导致流量转发异常。
  • 影响：在中断期间，受影响的用户数量达到数千万，Slack 公开承认并道歉。

5. Facebook 大规模停机（2021年10月）

  • 故障描述：Facebook、Instagram 和 WhatsApp 等多个服务在全球范围内出现数小时中断。
  • 原因：数据中心的配置更改导致路由问题，阻止了对所有平台的访问。
  • 影响：估计损失约为 1 亿美元，用户流失和品牌信任受损。

这些实例展示了生产环境中的故障可能会对用户、业务和品牌造成严重影响，强调了持续监控和故障应急响应的重要性。

加纳利空难

  • 恐怖袭击
  • 天气大雾
  • 被迫飞向小机场
  • 机场跑到太窄
  • 口音、模棱两可的词汇
  • 无线电干扰
  • 机长的焦虑

生产环境故障

  • 热点攻击、黑天鹅事件
  • 可识别的风险
  • 限流/初步止血
  • 尝试恢复，机器性能不行
  • 沟通没有标准
  • 群信息爆炸
  • 长时间OnCall

在减少资源消耗的同时，从可用性和性能层面，提升用户的体验。

Operations should NOT be a part of SRE missions. Operation is a way to understand production.

研发为生产环境负责！

SLI/SLO/SLA

SLI、SLO 和 SLA 是与服务管理和性能监控相关的术语，下面用形象的方式解释它们的含义：

SLI（服务级别指标）

可以理解为一个 "量度工具"。就像你在运动时记录自己的成绩，例如跑步的时间、跳高的高度。SLI 是用来衡量服务性能的关键指标，比如系统的响应时间、可用性等。通过这些指标，我们可以了解服务的实际表现。

SLO（服务级别目标）

可以看作是一个 "期望值"。就像你设定一个目标，希望在每次跑步中都能达到某个时间。SLO 是对 SLI 的期望值或者目标，比如希望系统的可用性达到 99.9%。它定义了服务应达到的性能标准。

SLA（服务级别协议）

可以视为一个 "合同"。就像你和教练签订的一份协议，承诺在一定时间内达到某个目标或提供某种服务。SLA 是在服务提供方与用户之间达成的正式协议，具体说明了服务的标准、指标和提供服务的责任。这通常包括补救措施，比如如果未达到约定的 SLO，将会采取什么措施或赔偿。

总结一下：

  • SLI 是测量工具，帮助我们量化性能。
  • SLO 是我们设定的期望目标。
  • SLA 是双方达成的正式协议，确保服务提供者遵守承诺。
错误预算 = 单位时间的请求数量 * 时间窗口 * （1 - SLO）

结果导向的告警，不是原因导向的告警

SLO是如何指定的：需要反映用户的真实体感，而不是单纯的技术细节。
  • MTTR：平均恢复时常
  • Blast Radius：影响半径

当平台服务不可用，或访问速度变慢时，往往会影响到产品的整体质量，目前了解到的一些基础监控指标就达到上百种，通常的做法是在这些指标当中需要选取平台或业务比较关注的指标进行监控报警。Google的网站可靠性工程师小组（SRE）定义了四个需要监控的关键指标。他们称之为“四个黄金信号”：延迟（Latency），流量（Traffic），错误（Errors）和饱和度（Saturation），具体含义可Google查询。这四个信号应该是服务级别非常关键部分，因为它们对于提供高可用性的服务至关重要。

如何定义高质量的监控：

  • 明确业务服务的SLO（应该与该业务提供给客户的期望达成一致），并采用合理的SLI来描述；比如计数信息（总量、成功量）、测量信息（同比、环比）；
  • 主观上监控应该有丰富的内部状态数据、具备高可观测性条件；客观上具备业务视角，能够快速定位是全局问题还是局部问题；系统本身的鲁棒性，不会因为某个局部问题影响监控的权威性；具备quota限制能力，防止出现容量的问题；
  • 报警清理和定期的规则优化，定期进行盘点告警，并优化掉无SLO影响的规则；

Latency SLOs Done Right

Theo Schlossnagle 的分享主题 "Latency SLOs Done Right" 主要关注于如何有效地定义和管理延迟相关的服务级别目标（SLO）。在这次分享中，他探讨了在系统性能监控和服务质量保证中，设定合理的延迟 SLO 的重要性。

主要内容通常包括：

延迟的定义：讲解什么是延迟，如何测量和评估它。 SLO 的重要性：讨论合理的 latencies SLO 配置对用户体验和服务可靠性的影响。 最佳实践：分享关于设定、测量和监控延迟 SLO 的策略和最佳实践，以确保可以有效满足用户需求。 该主题旨在帮助技术团队更好地理解和应对延迟问题，从而提高服务的可靠性和用户满意度。

  • 延迟SLOs的统计比较容易受到统计策略的影响，比如如果设定为平均耗时小于100ms，当有51%的业务处理延迟为50ms，49%的业务延迟为150ms，平均延迟是小于100ms的，但是这个数据并不能反映当前系统的问题；
  • 延迟SLO应该定义为：计算分位数的时间段，计算目标成功的时间段，例如在任意5分钟时间段内，99.5%低于100ms；
  • 核心的分析方法：
    • 采用原始数据或者分块直方图的工具
    • 能够量化你得到的每一个答案的统计误差
  • SLOs需要持续的改进，一开始的规则可能是武断的，注意需要制定一个无法超额完成的目标，需要持续的改进，来指导业务的优化目标。

元数据的管理

如何建立完善的运维元数据管理体系？

本次大会上看到了不少公司的产品，体感上每个产品都有仪表盘和持续的迭代，通过仪表盘可以快速看到平台的核心信息，能够快速使用数据指导用户或者平台自身进行迭代升级。对比我们内部的产品更多实现的是功能和平台，只完成了0->1的核心功能实现，没有看到1->N持续的产品能力提升以及利用数据驱动产品提升。

SRE vs. DevOps

很有趣的对比，DevOps 和 SRE 都会关心应用生命周期，特别是生命周期里面中变更和故障。 但是 DevOps 工作内容是主要为开发链路服务，一个 DevOps Team 通常会提供一串工具链， 这其中会包括：开发工具、版本管理工具、CI 持续交付工具、CD 持续发布工具、报警工具、故障处理。 而 SRE Team 则关注更为关注变更、故障、性能、容量相关问题，会涉及具体业务，产出工具链会有： 容量测量工具、Logging 日志工具、Tracing 调用链路跟踪工具、Metrics 性能度量工具、监控报警工具等。

SRE技能堆栈

  • 语言和工程实现
    • 深入理解开发语言（假设是 Java）
      • 业务部门使用开发框架
      • 并发、多线程和锁
      • 资源模型理解：网络、内存、CPU
      • 故障处理能力（分析瓶颈、熟悉相关工具、还原现场、提供方案）
    • 常见业务设计方案和陷阱（比如 Business Modeling，N+1、远程调用、不合理 DB 结构）
    • MySQL / Mongo OLTP 类型查询优化
    • 多种并发模型，以及相关 Scalable 设计
  • 问题定位工具
    • 容量管理
    • Tracing 链路追踪
    • Metrics 度量工具
    • Logging 日志系统
  • 运维架构能力
    • Linux 精通，理解 Linux 负载模型，资源模型
    • 熟悉常规中间件（MySQL Nginx Redis Mongo ZooKeeper 等），能够调优
    • Linux 网络调优，网络 IO 模型以及在语言里面实现
    • 资源编排系统（Mesos / Kubernetes）
  • 理论
    • 容量规划方案
    • 熟悉分布式理论（Paxos / Raft / BigTable / MapReduce / Spanner 等），能够为场景决策合适方案
    • 性能模型（比如 Pxx 理解、Metrics、Dapper）
    • 资源模型（比如 Queuing Theory、负载方案、雪崩问题）
    • 资源编排系统（Mesos / Kurbernetes）

学术圈子

深：SRE核心技术栈的深入研讨

SRE的核心技术栈通常包含自动化、监控、发布、容量管理和SLO。

  • 会上来自Microsoft，Google的嘉宾对于如何SLO的制定阐述了他们的理解，包括技术细节上如何通过立方图来拿到正确的Latency SLO的数字。
  • LinkedIn分享了整个站点的监控系统的演进，从最初的数据采集，可视化，到告警的配置，通知和现在的自愈。Facebook分享了他们快速发布的理念以及背后的实现。架构方面，LinkedIn介绍了基于Couchbase的中心化缓存服务；
  • Facebook介绍了Instagram的跨洲的分布式架构，一句话概述就是拆分美洲和欧洲的用户数据，引入了内部对于用户数据优化存储区域的大脑Akkio。

ML在SRE生态中的地位提升

虽然说ML不是万能的，但是此次SRECon上Facebook，Google等分享了ML在SRE的不同日常场景下的尝试。比如在做灰度发布的过程中，引入无监督学习来对日志内的错误进行聚类，利用训练出来的模型做A/B校验。Google分享了利用大数据建立故障定位的思路，核心在于将各个系统的数据利用同一个模型定义出来，走统一的汇报接口，有统一的系统识别符。虽然效果暂时不是很理想，但是也沉淀了一些模型和数据，可以进行二次利用。

超越自动化

微软的SRE在会上分享了微软对于SRE在自动化工程建设中的思考，最初的核心思想来自于1982的一片关于工业界复杂系统自动化的学术论文。自动化对于SRE来说是一把双刃剑，既能够解决SRE平时的苦力活和痛点，但是如果建设不当，也会造成SRE自身能力的丢失。比如说，长久的自动化会让SRE逐步忘却一些重要的手工操作，导致SRE在工具不可用的时候无法及时处理问题。 分享者提出了一个有意思的悖论：如果一个自动化的系统能够在某件事情上做的比人好，那人是如何能够知道该如何监控这个自动化的系统？所以微软在SRE的人才培养上会格外重视模拟故障演习、学习故障复盘报告、尝试关闭自动化系统等。类比到蚂蚁今天的技术风险能力，对我们的红蓝攻防能提供新的思路，例如“关闭所有的管控UI，SRE该如何操作？”

1.“What Is ML Ops: Solutions and Best Practices for DevOps of Production ML Services” PPT www.usenix.org/sites/defau…

2."Unified Reporting of Service Reliability" PPT www.usenix.org/sites/defau… 这个session有意思的地方是它想解决的问题。作为软件研发，我们通常会从软件的维度定义SLO, 比如API调用成功率, RT等等。但是客户投诉到软件SLO的归因当前更多是人工做的，造成的问题有：(1) 归因分析的成本高，往往是通过复盘，involve大量团队参与，因此可能造成“小问题”被忽视掉；(2)无法对系统SLO与特定客诉的关系进行定量度量，进而依据客满指标对SLO的定义进行调整。 本文的解法是尝试将客诉数据和系统的SLO metrics, 系统日志建立关联，将问题转化成一个ML的预测问题。但其中落地的部分做的还比较简单。

3."How to trade off server utilization and tail latency" PPT www.usenix.org/sites/defau…

avatar
文章
阅读
粉丝