The Good Student！ - SRE 可靠性工程
type: channel
link: https://www.hxy.bj.cn/category/SRE-%E5%8F%AF%E9%9D%A0%E6%80%A7%E5%B7%A5%E7%A8%8B/
items: SRE Google解密
items: “如何做好一个SRE？如何培养一个SRE？”
items: 用 ERROR 日志做告警
items: 可观测性理念：宽事件实践指南
items: 怎么记日志才算专业，SRE应该了解的实践指南

SRE Google解密
type: item
date: 2026-08-20T21:15:34+08:00
description: 本文整理自书籍《SRE 原理与实践》第一部分 概览第1章 介绍不能将碰运气当成战略。——SRE俗语系统管理员模式雇佣系统管理员（sysadmin）运维复杂的计算机系统，是行业内一直以来的普遍做法。传统冲突：研发部门（Dev）关注快速发布新功能；运维部门（Ops）关注避免值班期间发生故障。矛盾根源：绝大部分生产故障由部署变更（新版本、配置修改、流量变化）触发，两个部门的目标本质上互相矛盾。Google的解决之道：SRE核心理念：通过雇佣软件工程师，创作软件系统来维护系统运行，以替代传统模型中的人工操作。团队构成：50%~60%：标准软件工程师。40%~50%：基本满足软件工程师标准，并具备其他技术能力的工程师。SRE特点：对重复性、手工操作有天然的排斥感。有足够的技术能力开发软件系统以替代手工操作。用软件工程的思维和方法论完成系统管理员的任务。终极目标：推动整个系统趋向于无人化运行。经验法则：SRE团队必须将50%的精力花在真实的开发工作上。优势：消除了研发和运维的冲突，促进部门整体水平提高，人员可自由流动，知识共享。DevOps还是SRE？DevOps：是SRE核心理念的普适版，适用于更广范围的组织结构。SRE：是DevOps模型在Google的具体实践，带有特殊的扩展。SRE方法论SRE团队承担以下职责：可用性改进、延迟优化、性能优化、效率优化、变更管理、监控、紧急事务处理、容量规划与管理。确保长期关注研发工作：运维工作限制在50%以内，剩余时间用于研发项目。On-call准则：每8~12小时的轮值期间最多处理2个紧急事件，确保有足够时间正确处理故障、恢复服务并撰写事后报告。事后总结（Postmortem）：包含事故发生、发现、解决的全过程、根本原因、预防或优化的解决方案。原则：对事不对人，目标是发现和堵住漏洞，而非绕过和掩盖。在保障服务SLO的前提下最大化迭代速度：SLO（服务等级目标）：指定服务所提供功能的期望状态。错误预算（Error Budget）：起源：任何产品都不应追求100%可靠（对最终用户而言，99.999%和100%无实质区别）。作用：解决研发团队和SRE团队之间的组织架构冲突。SRE目标从“零事故”转变为共同管理风险，事故成为创新流程中不可避免的环节。管理：只要系统表现高于SLO，研发可继续发版；预算耗尽时，需降低发布速度或优先修复可靠性问题。监控系统原则：不应依赖人分析警报，系统应自动分析，仅当需要用户执行操作时才通知。三类输出：紧急警报（Alert）：需立即执行操作。工单（Ticket）：需执行操作，但非立即。日志（Logging）：平时无人关注，供调试和事后分析使用。应急事件处理可靠性是MTTF（平均失败时间）和MTTR（平均恢复时间）的函数。降低MTTR：通过事先预案并将最佳方法记录在“运维手册（Playbook）”上，可使MTTR降低3倍以上。经过多次演习的on-call工程师比初期几个万能工程师更可靠。变更管理数据：约70%的生产事故由部署变更触发。最佳实践（自动化）：渐进式发布机制（如蓝绿部署、滚动更新）。迅速检测问题。安全快速地回退改动。需求预测和容量规划定义：保障业务有足够的容量和冗余度去服务预测中的未来需求。步骤：准确的自然增长需求预测模型。准确的非自然增长需求来源统计。周期性压力测试，将系统原始资源与业务容量对应起来。主导：SRE应主导容量规划和资源部署过程。资源部署是变更管理与容量规划的结合物，需要小心谨慎地执行。效率与性能责任：SRE负责容量的部署和配置，也必须承担有关利用率的讨论及改进。驱动因素：用户需求（流量）、可用容量、软件的资源使用效率。延迟与容量：负载上升导致延迟升高，延迟升高等同于容量损失。SRE的目标是根据预设的延迟目标部署和维护足够的容量。总结Google SRE代表了对行业现存管理大型复杂服务的最佳实践的一个重要突破。它由“我是一名软件工程师，这是我如何来应付重复劳动的办法”这一简单想法，发展成一套指导思想、方法论、激励方法和独立职业。第2章 Google生产环境：SRE视角本章阐述Google如何将SRE方法论落实在生产环境中，其生产环境本身是一个高度工程化的大系统。硬件数据中心：Google自己设计，从供电、制冷、网络拓扑到计算硬件统一设计。概念区分：物理服务器（Machine）：具体硬件。软件服务（Server）：对外提供功能的软件系统。组织层次：机器 → 机柜（Rack） → 机柜排（Row） → 集群（Cluster） → 数据中心（Datacenter） → 园区（Campus）。硬件故障常态：系统软件将硬件故障对业务的影响隔离掉。管理物理服务器Borg：分布式集群操作系统，负责在集群层面编排任务。职责：接收job、拆分为task、选择物理机、监控、…

“如何做好一个SRE？如何培养一个SRE？”
type: item
date: 2026-08-09T01:35:00+08:00
description: SRE 团队转型与业务接手实践指南本文整理自书籍《SRE 原理与实践》"可靠性管理能力"，聚焦团队转型、新人培养、以及以 SRE 方式接手业务三大核心主题，帮助你理解如何从传统运维团队走向工程化的可靠性团队。主要是和大家分享一下如何培养新人和新人如何学习的一些方法吧！一、为什么要强调团队转型专业的 SRE 团队职责及工作方法与传统运维团队有较大不同。SRE 的使命是提升产品在线持续运行的可靠性/稳定性，很多以传统运维为主的团队都在寻求转型为 SRE 团队的方法。团队转型包括几种类型：培养原先做技术运维的成员转型为 SRE；招聘新人从零开始培养为 SRE；把运维团队整体转型为 SRE 团队，优化团队能力结构，培养和引入可靠性工作所需要的多个方向的工程师。运维工程师与 SRE 的核心区别传统运维工程师偏重运维操作，以满足业务需求为主；而 SRE 以保持和提升系统可靠性为主要职责。两者的岗位职责和工作目标大为不同：维度传统运维工程师SRE核心职责运维操作，满足业务需求保持和提升系统可靠性工作性质偏被动响应较高比重的主动性工作工作方法依赖个人经验手工操作工程化方式改变架构设计能力抓手—感知、反脆弱、保障、快恢故障参与参与处理主导应急协同，参与故障生命周期管理SRE 会使用运维技术，但使用目的是加强可靠性，使用方法是用编程的方式，运维操作只是 SRE 日常工作的一部分。从运维工程师转型为 SRE，既是互联网平台提升可靠性稳定性的要求，也是运维工程师职业发展的需要。平台、团队与个人都面临转型问题，而且必须是体系化的转型——运维工作会逐渐实现自动化，部分工作由产品研发工程师通过系统执行，部分工作交给可靠性工程师来执行，SRE 工程师应进行更多可靠性工程工作。二、运维工程师如何转型为 SRE1. 通过学习提升能力，找到发展方向一个优秀的 SRE 需要具备多方面的能力，以及专业的系统运维技能。如果 SRE 同时具备软件开发能力、产品架构设计能力（初级阶段可以是理解架构的能力）、沟通协调能力、项目管理能力等，将非常有优势。SRE 的能力模型应该是"一专多能"：有自己的专业方向（如软件开发、基础设施、系统架构等）；技术广度同样重要，只有这样才能熟练应用可靠性技术、专业能力和综合能力完成可靠性工作；在专业方向深入耕耘的同时，在其他技术面也要达到一定广度和深度。2. 从度量所负责业务的可靠性开始SRE 和业务方（包括产品、业务负责人、SRE 团队负责人）一起找到业务核心技术指标并进行度量，形成可靠性 SLO。通过 SLO 这个抓手：了解现状、分析风险、暴露问题；驱动产品研发、基础团队、SRE 团队一起改进；开展可靠性工程领域内的各项工程活动（提升感知能力、保障能力、快恢能力等）；把改进后的能力持续反馈出来，分析项目效果；持续分析新的业务现状和风险，逐步建立自己在业务质量和可靠性方面的权威性。3. 对故障生命周期负责SRE 要在故障的整个生命周期内积极主动推动各项可靠性工作，而不仅是参与处理故障。在过程中不断提升对故障发生、发现、定位、处理、总结、改进等环节的理解力和掌控力。三、如何将新人培养为 SRE成为 SRE 需要掌握系统性、累积型的学习方式，也需要有一套成长手册，而非向运维操作方向成长。1. 团队与导师SRE 团队的新人要在各业务运维组中轮训，在小组内安排一位导师负责试用期间的指导工作（一个新人配一位导师）。2. 熟悉业务，学习知识和技术新人进来首先要熟悉业务，了解业务使用的技术，与其他资深 SRE/产品研发工程师沟通，学习业务：熟悉 CMDB、架构文档，了解用户请求是如何进入系统的；从前端、中间、后端到数据库、存储，对整个架构进行反向工程；自己整理文档——每个新人要为团队撰写新文档以及完善现有文档，不仅有利于传承知识，而且有利于激发新人的探索精神；深入研究一个具体的问题，对架构、感知、脆弱性、快恢、保障能力中的某一方面研究透彻；通过统计学、比较思维学会数据运营，学习监控技术，熟悉监控系统。3. 系统性的培训如果没有系统性的培训，新人会在混乱、庞大的信息量和无边的未知信息中惶恐工作，随时提心吊胆、不敢工作、工作效率低，经常找导师咨询问题，不仅成长速度慢，还会影响导师的工作。系统性培训包括以下几个方向：(1) 学习监控认识常见的监控指标，包括 SLI 监控、基础监控（系统、网络）、业务层监控（APM 上报、服务调用、服务日志）、DB/缓存监控。可安排日常基础监控的处理任务帮助新人加深理解。学习常用的监控上报流程：监控程序 → 上报服务 → 存储 → 告警规则 → 展示 → 收取告警。目的是熟悉整体流程及每个组件的监控感知能力，了解如何发现异常。可安排任务：为系统增加一个指标监控、编写监控程序、取出数据告警判断、配置告警、发送并收取告警、在监控系统配…

用 ERROR 日志做告警
type: item
date: 2026-03-09T19:51:00+08:00
description: 用 ERROR 日志做告警：低成本高 ROI 的兜底监控实践作为服务的研发、运维人员，你会给服务配置哪些告警规则？机器性能相关的？很多人首先想到机器的 CPU、内存、磁盘、网络、IO 相关的指标，虽然在现代微服务架构下，这些指标的重要性下降了，但是这些指标确实比较容易配置，能够给你安全感。但这不是我今天要聊的。服务的SLI指标？如果对 Google SRE 稍微有点了解，大概率会听过 Google 四个黄金指标、RED 这样的方法论，必然不会遗漏 SLI 指标，这也不是我今天要聊的。我想提醒大家的是：服务的ERROR日志数量！很多人遗漏了这个监控告警，原因可能是：日志告警工具缺失日志不规范不好做告警配置已经有了SLI等重要指标了，觉得够用了统计服务的ERROR日志数量并做告警，ROI极高，大道至简，我来讲讲原因。驱动你建立日志中心化收集、ETL、告警链路指标体系相对容易，Prometheus、VictoriaMetrics 等几乎是每个公司的标配，指标的告警也相对容易，所以大家一般都是有的。在指标领域，有问题的通常不是工具，通常是业务研发只在意 CRUD，对程序稳定性、可观测性等关注较少导致的 SLI 缺失。日志通常是后于指标体系的，各个公司的建设通常没那么完备。好在 ELK、Loki、VictoriaLogs 等工具的流行度越来越高，用这些开源项目完全可以把日志体系搭建起来。驱动研发梳理日志级别ERROR日志的告警，通常只需要根据级别过滤，比如告警规则配置（以VictoriaLogs举例）为：_time: 5m AND _stream:{module="a"} AND level:ERROR | stats count(*) error_total | filter error_total:>0只要发现 ERROR 级别的日志，就告警。这会让乱打日志级别的情况得到一定的治理。有些研发不太在意日志级别，有时即便是用户参数错误也会打印 ERROR 日志，这给故障排查带来很多噪音。通常来讲：只有确实影响了服务运行的情况才打印 ERROR 日志。个别用户的问题通常只需要打印 Warning。清晰的日志级别，可以大幅减少排障时的噪音干扰。加速故障定位。要求使用 level:ERROR 这样的字段过滤，要求日志提前做好 ETL，驱动研发人员采用更结构化的日志格式。目前来看，JSON 格式的日志已经成为可观测性领域的共识。指标告警的兜底指标告警很重要，但有时容易漏掉一些问题。使用 ERROR 日志作为兜底，非常关键。因为通常来讲，只要代码逻辑遇到问题，一定会打印 ERROR 日志，所以一般问题都可以通过这一条告警规则命中。

可观测性理念：宽事件实践指南
type: item
date: 2025-12-16T14:47:00+08:00
description: 宽事件实践指南采用宽事件（Wide Event）式的监控手段，这一改变缩短了对所有变更的反馈周期，让系统调试变得异常轻松，那些曾让人望而却步的系统，也突然变得易于管理。简单来说，对于系统中的每个工作单元（通常是HTTP请求/响应，但并非绝对），你只需输出一个“事件”，并在其中包含该工作单元相关的所有可收集信息。在遥测领域，“事件”是一个含义宽泛的术语，你也可以根据喜好将其替换为“日志行”或“追踪跨度（span）”，它们在本质上是相同的概念。查里蒂·梅杰斯（Charity Majors）近期将这种方法称为“可观测性2.0”（Observability 2.0）并大力推广，为该概念注入了新的活力，但实际上这并非全新理念。布兰德·利奇（Brandur Leach）早在2016年就在其个人博客中提及“标准日志行”（Canonical Log Lines），2019年又介绍了Stripe公司对该概念的应用。此外，亚马逊云服务（AWS）多年来也一直将其列为最佳实践。好的……大概理解了这个概念，但该如何实践“宽事件”呢？这正是许多开发者感到困惑的地方。从理论上看，这个理念很棒，我们确实应该尝试！但现实是，还有一堆功能等着开发上线，有个bug让我夜不能寐，昨天还冒出30款新的人工智能工具需要学习。而且，到底该从哪里入手？又该添加哪些数据呢？与软件领域的其他事物一样，实现宽事件的方法有很多种。接下来，我将分享一种对我行之有效的实践方案，内容涵盖工具与代码层面的实现思路、一份详尽的属性添加清单，以及对该方法常见质疑的解答。本文将重点聚焦于Web服务场景，但这套思路同样适用于其他各类工作负载。第一步：选择合适的工具我们需要借助工具来为代码添加监控（通过追踪数据或结构化日志行），同时还需要一个接收这些监控数据的平台，以便进行查询和可视化分析。理想的工具应支持快速迭代式的数据查询。我个人推荐使用Honeycomb，不过，只要是基于现代OLAP（在线分析处理）数据库构建的可观测性工具，在紧急情况下都能满足需求，例如：Honeycomb：配备Retriever功能DataDog：配备Husky功能New Relic：配备NRDB功能Baselime：基于ClickHouse构建SigNoz：基于ClickHouse构建Honeycomb、New Relic和DataDog均自行研发了列式OLAP数据存储。如今，随着ClickHouse、InfluxDB IOx、Apache Pinot和DuckDB等工具的普及，各类新的可观测性工具也在不断涌现。若不受环境限制，我强烈建议优先选择OpenTelemetry搭配Honeycomb，这会让后续工作更高效。即便你身处企业环境，且对2010年后出现的技术有所抵触，也可以在紧急情况下使用ElasticSearch这类日志搜索工具。Stripe的博文中还介绍了如何使用Splunk实现类似功能。无论选择哪种工具，都需要熟练掌握以下3种核心技巧，以便筛选事件数据。你运用这些技巧进行迭代查询、挖掘数据价值的速度越快，就越能高效排查问题，深入了解系统的实际运行状态。当可观测性领域的从业者提及“数据切片分析”时，通常指的就是这一系列操作。下文将使用一种自定义的SQL方言来示例查询语句，你可以在所用工具的查询语言中找到对应的实现方式。1. 可视化（Visualizing）人类的身体存在诸多局限，但视觉皮层在识别模式方面能力极强。要充分发挥这一优势，需熟练掌握系统数据的可视化呈现方法，常用的统计函数包括COUNT（计数）、COUNT_DISTINCT（去重计数）、HEATMAP（热力图）、P90（90分位数）、MAX（最大值）、MIN（最小值）以及直方图（Histogram）。请务必熟悉所用工具提供的各类图表功能，勤加练习，提升操作速度。示例：Honeycomb热力图截图示例：Splunk直方图截图2. 分组（Grouping）为宽事件添加的每一个新标注，都会成为一个可用于数据切片的维度。通过GROUP BY语句，我们可以沿着该维度分析数据，验证数据值是否符合预期。GROUP BY instance.id -- 按实例ID分组GROUP BY client.OS, client.version -- 按客户端操作系统和版本分组3. 筛选（Filtering）当锁定某个感兴趣的维度后，通常需要进一步深入分析数据。通过筛选，可将关注点缩小到特定的流量片段，例如某一个端点、某一个IP地址、来自iOS应用的请求，或是开启了特定功能标志的用户请求。WHERE http.route = "/user/account" -- 筛选HTTP路由为“/user/account”的请求WHERE http.route != "/health" -- 排…

怎么记日志才算专业，SRE应该了解的实践指南
type: item
date: 2025-12-15T23:59:00+08:00
description: 坦白说：很多日志都只是无用信息…[INFO] Starting process … probably. [DEBUG] Made it to line 42 — still alive. [TRACE] Function entered. Leaving soon. [INFO] User clicked a button. Which one? No idea. [WARN] Everything’s fine, just felt like warning you. [DEBUG] Variable x = 7. Might change. Might not. [INFO] Operation completed successfully (we think). [TRACE] Loop iteration #12 of infinite sadness. [DEBUG] Placeholder for meaningful message. [INFO] Shutting down gracefully … except when not.作为开发人员，常常像撒彩纸一样随意记录日志 —— 每个函数的入口、每个变量、每一次系统 “心跳” 都不放过。没过多久，数太字节的无意义日志行就会堆积如山，填满那些没人看的仪表盘。我们向可观测性供应商支付数百万美元，却只是为了存储这些 “垃圾”。每一条无用的日志行都在消耗计算资源、磁盘空间和资金。没有明确目的的日志记录不是可观测性实践，而是 “乱扔垃圾”。即便现在的可观测性平台借助列式存储大幅提升了压缩效率，也没有理由记录所有内容。这种无差别记录仍会让根本原因分析变成 “大海捞针”—— 稀释你真正需要的有效信号，而且你还得为此支付更高成本。我们需要有选择性地记录日志：只记录那些有助于理解系统、调试实际问题或说明业务影响的信息，其他无关内容都不必记录。日志记录的核心原则每一条日志记录都是一个主动选择，而非下意识的操作。如果这条日志无法帮未来的你在凌晨 3 点排查出 bug，那就删掉它。日志记录不是记日记，要做到简洁、清晰且真正有用。在敲下 logger.info（信息级日志记录代码）之前，先停下来问问自己：我之后真的会用 grep（一种文本搜索工具）查找这条日志吗？如果答案是否定的，就删掉它。日志不是叙事流水账，而是证据。它们的存在，是为了在系统出现问题时，告诉你当时系统的运行状态。日志不应被排在可观测性实践的末尾。它们不只是用于验证问题的 “显微镜”，更是用于发现问题的 “地图”。有时候，获取洞见最快的方式，就是直接探索原始文本 —— 通过 grep 搜索、筛选，跟着直觉去挖掘。日志能激发探索欲：它们能展现出指标可能掩盖的细微差别，以及追踪数据无法传递的上下文信息。不要把日志当作最后的求助手段，而应将其视为 “实时输出的真相来源”，从一开始就主动去探索。无上下文，不日志只写 “发生错误”，却不包含输入数据、ID 或系统状态，这样的日志毫无意义。要添加足够的上下文信息，以便还原当时的场景 —— 比如请求 ID、用户 ID、输入参数、操作名称等。如今，借助 OpenTelemetry（一种开源可观测性框架），你可以免费获取追踪 ID（trace ID）和跨度 ID（span ID），一定要善用它们。通过追踪 ID 与追踪数据（甚至指标）关联起来的日志，其价值远胜于孤立的文本行。日志不是可观测性实践中独立的一环，而是根本原因分析的 “收尾章节”。你通过指标触发告警，通过追踪数据展开调查，然后再查看日志，了解到底发生了什么。当日志通过追踪 ID 和跨度 ID 关联起来后，它们就不再是无用信息，而成为了精准、有上下文的证据 —— 直接与单个请求的路径相关联。这才是有明确目的的可观测性实践，而非一堆杂乱无章的文本。结构化日志，而非自由文本自由文本形式的日志早已过时。结构化日志（无论是 JSON、CSV 格式，还是键值对形式）不仅更易于查询，更是数据分析的基础。一旦日志具备了结构化格式，规律便会自然浮现：“这个错误从上周开始激增。”“这个问题大多在事件 X 之后出现。”“这个警告与某次特定部署相关。”日志的未来发展方向，不是逐行阅读单条日志，而是从成千上万条日志中发现整体规律。图片来自网络结构化日志让图表展示变得简单高效。虽然很多可观测性平台支持 “读取时解析 schema”（schema on read），但这种灵活性是有代价的：每一次查询，系统都要逐行扫描并解析原始文本，推断出本该从一开始就存在的结构化格式。这类查询计算成本高、速度慢，而且用户编写查询语句也更困难。预先结构化的日志则能彻底扭转这种低效局面。当你的数据本身就具备结构化格式时，就可以充分利用列式存储和原生聚合功能 —— 在毫秒级时间…