读书笔记（SRE：Google运维解密）：第13章紧急事件响应

github_37320188

墨衍会员 · AI 创作全网分发 墨衍智能分发 本文由作者通过墨衍一键同步至各平台 1分发平台 400+累计阅读 444平均单平台已同步平台优快云微信公众号微博知乎掘金百家号博客园抖音小红书 你的文章也可以这样分发 墨衍会员 ¥399起/年，写一次发全网我也要 → 码龄10年

关注

原创最新推荐文章于 2026-04-23 00:00:00 发布 444 阅读 AI 写同款· GEO 优化 ›

matsim教程及其案例 MATSim 是一个强大的交通仿真工具，适合研究交通政策、出行行为优化和城市规划。建议从官方示例入手，逐步尝试修改参数和扩展功能。遇到问题时，优先查阅官方文档和社区讨论。（Multi-Agent Transport Simulation Toolkit）的教程和案例资源整理，涵盖基础入门、核心概念、实际应用案例及学习路径。MATSim 是一个开源的、基于多智能体的交通仿真框架，用于模拟城市交通系统中的出行行为、交通流量和交通政策影响。阅读详情

          
          向过去学习，而不是重复它

（a）为事故保留记录：在记录中，请一定要诚实，一定要事无巨细。尤其重要的是，提出关键的问题。时刻寻找如何能在战术及战略上避免这项事故的发生。公布和维护事后报告，确保全公司的每个人都能从中学到你所学到的知识。

（b）提出那些大的，甚至不可能的问题：假如……

（c）鼓励主动测试

收录于

读书笔记（SRE：Google运维解密）

当前文章被收录于：

读书笔记（SRE：Google运维解密）

27 篇文章 9 人学习

读书笔记，SRE：Google运维解密

订阅专栏查看详情

当前文章被以下社区和专栏收录：

标签

#运维

opencv 双目摄像头拍照（分别左右镜头拍照）准备一个usb线的双目同步摄像头：运行环境是vc2015,opencv3.1。将左右两个摄像头拍到的图片分别保存起来。 1）适用条件双目同步摄像头（两个镜头，共用一个设备ID）使用语言：C++ 、opencv库摄像头分辨率2560*960 或以上。源程序： #include"stdafx.h" #include<iostream&g... 阅读详情

相关推荐

【ros】ROS1的安装和相关使用方法

主要学习ros相关内容

Greary的博客 2380

美团围绕故障管理谈SRE体系建设

本文根据石鹏老师在〖deeplus直播第227期〗线上分享演讲内容整理而成。（文末有获取本期PPT&回放的方式，不要错过）石鹏美图SRE负责人 2016年加入美图，运维技术专家，目前担任产品SRE负责人。负责美图社交、直播、电商、商业化等全线产品的运维工作。我们都知道SRE是一个体系化的工程，SRE体系的建设涉及的内容繁多，比如日常需求处理、容量规划、资源部署、监控告警、预案梳理、灾备演练、OnCall值班、应急事件响应、故障处理、运维自动化建设等等；其中「故障」

jj1130050965的博客 1773

AD（AltiumDesigner）封装导入allegro生成allegro封装

AD（AltiumDesigner）封装导入allegro生成allegro封装貌似PCB的封装问题是一个无尽话题，为了简单我总是想找捷径（主要还是太懒了），因为也是近期才开始学习使用allegro进行PCB设计，在最近的一个设计中，很多器件封装allegro中都没有，一个一个画感觉很费时间，但是在AD（AltiumDesigner）的封装库中是有的，于是便想着AD的封装库能不能倒入到alleg...

yangh2560的博客 2万+

夸张的扩容盘！

测试CopyU！的新功能设备容量鉴定时检测到了一个扩容比例超过70%的设备，JS们真是节操无底线啊！ [这个设备的虚报容量竟然高达74%，我和小伙伴们都惊呆了！]

kflizcst的图形世界 1006

cadence capture CIS 之使用access创建数据库（.mdb）

cadence capture CIS 之使用access创建数据库（.mdb）准备工作新建数据库准备工作 1、一台电脑； 2、安装 Microsoft access database；新建数据库打开你准备创建数据库的位置，右键单击——》新建——》 Microsoft access database（注意：文件格式要选*.mdb）打开数据库文件，创建——》表；对数据表进行编辑，编辑表头、编辑表的内容、增加表的数量；编辑表头：选中要编辑的表——》表设计编辑内容：类似于excel添

weixin_42256550的博客 3152

京东技术产品经理面试全记录：从简历投递到一面45分钟实战复盘

本文深度复盘京东技术产品经理面试全流程，从策略准备、思维题拆解、项目阐述到反问谈判，提供了一套可演练的求职策略体系。文章强调该岗位需具备横跨技术与商业的枢纽能力，并通过“QQ分组vs微信标签”等案例，剖析了产品思维与结构化表达在面试中的关键作用，助力候选人将紧张转化为掌控感。

weixin_29275257的博客 630

史上最长最全！围绕故障管理谈SRE体系建设

本文转载自dbaplus社群 id:dbaplus本文根据石鹏老师在〖deeplus直播第227期〗线上分享演讲内容整理而成。（文末有获取本期PPT&回放的方式，不要错过）石鹏美...

杨建荣的学习笔记 4786

DFRobot MGC3130电容式手势传感器库深度解析

电容式近场感应（Electric Near Field Sensing）是一种非接触、抗干扰的三维空间感知技术，其原理基于人体介电特性对高频电场的扰动响应，具备低功耗、高鲁棒性与零物理接触等核心优势。该技术广泛应用于医疗人机交互、工业HMI、智能家电等对可靠性与环境适应性要求严苛的嵌入式场景。DFRobot_MGC3130库正是面向Microchip MGC3130芯片的工程化实现，封装了I²C驱动、ASU硬件加速调度及多层抽象API，支持手势识别、触控检测与接近唤醒等功能动态切换。结合电容式近场感应与嵌入

weixin_34620658的博客 551

SRE 系列（四）| MTTI 与 On-Call：高效故障响应之道

本文重点探讨了SRE体系中如何通过优化MTTI（平均确认时间）来提升故障响应效率。核心观点包括：1）基于SLO和错误预算快速判断故障等级，比依赖用户反馈更及时；2）组织协作机制（如On-Call轮值、War Room）比技术监控更能缩短MTTI；3）提出On-Call五步法：关键角色保障、快速组建应急小组、合理呼叫机制、资源升级通道、云厂商联动。通过优化MTTI这一关键环节，可为后续故障处理赢得时间，从而有效降低系统不可用时长。（149字）

weixin_48711696的博客 1542

多模态情感识别（MER）数据集实战指南：从IEMOCAP到应用落地

本文提供了多模态情感识别（MER）从数据集到应用落地的完整实战指南。以经典IEMOCAP数据集为例，详细讲解了音频、视觉、文本等多模态数据的预处理、特征提取与融合技术，并分享了模型训练调优心得及面向智能客服、在线教育等场景的部署考量，帮助开发者快速构建高效可用的MER系统。

h3i4j的博客 1071

电池管理系统(BMS)软件：CATL BMS二次开发_（1）.CATL BMS软件概述

CATL BMS软件的保护机制是确保电池组安全和可靠运行的关键部分。通过高精度的传感器和智能算法，BMS可以实时监测电池组的状态，及时采取保护措施。二次开发中，可以根据特定的应用需求，增加新的传感器、优化算法、扩展通信接口等，进一步提高系统的性能和可靠性。维护和扩展则是确保系统长期稳定运行的重要手段。希望以上内容对您理解CATL BMS软件的保护机制有所帮助。如果您有任何进一步的问题或需要更详细的解释，欢迎随时提问。

zhubeibei168的博客 1460

《SRE：Google 运维解密》读书笔记14: 紧急事件响应 - 从“可控破坏”到“极限生存”

通过对三个案例的纵向复盘，可以提炼出应急响应中贯穿始终的四条“黄金法则”。法则核心要义体现案例为何重要冷静是前提专业人员受过训练，即使回滚失败也能迅速切换思路寻找备用方案案例一恐慌是有效决策的最大障碍协作是关键事件触发后立即升级、全员同步信息；依赖带外通信系统保障协作通道案例二信息孤岛会让小问题演变成大灾难止损是底线恢复服务的优先级高于追溯根本原因三个案例均体现用户永远优先于完美分析复盘是保障事后必须留出时间撰写报告，将经验沉淀为制度三个案例均体现未能从失败中学习的组织，注定重蹈覆辙。

1701

使用 Python 爬取网易云音乐歌单数据（完整教程）

随着在线音乐平台的普及，网易云音乐（NetEase Cloud Music）凭借其个性化的推荐算法和丰富的用户互动，吸引了大量用户。网易云音乐的歌单中包含了丰富的音乐数据，包括歌曲名、歌手、专辑、播放量、评论数等信息。通过爬取这些数据，可以对音乐流行趋势进行分析，挖掘音乐推荐策略，甚至训练个性化推荐模型。网易云音乐的 API 并未官方开放，但开发者通过抓包和逆向分析，找到了若干可用接口。✅ 数据清洗与存储（CSV/数据库）✅ 网易云音乐 API 接口分析。✅ 网易云音乐接口解析。✅ 同步与异步爬取实现。

2201_76125261的博客 1373

《SRE：Google 运维解密》读书笔记12: on-call轮值 - SRE的“生命线”

on-call 轮值是 SRE 保障服务可靠性的核心机制，通过主副值班制、多地团队、25%运维时间红线和12小时≤2事件的质量标准，让应急响应可持续。关键点一句话概括on-call 的核心目标服务可靠性（分钟级响应）+ 团队可持续性（避免疲劳战）主副值班制主 on-call 负责主要响应，副 on-call 作为备份和协助多地团队优势避免夜间值班损害健康 + 控制团队规模保障熟悉度数量平衡纯运维时间 ≤ 25%，至少 50% 投入研发质量平衡。

1742

win10 跳过U8环境检测的IE WebControls.rar

win10 安装u8的时候提示IE WebControls 不通过，这个工具可以欺骗u8的检查。跳过U8环境检测的IE WebControls。提示导入失败后，重新检测通过。

NTscan扫描工具

ntscan是一个扫描器，可以扫描没有密码和弱密码的共享，先到配置文件中填写猜测的用户名和密码，扫描过程中右侧出现的是扫描日志。

《SRE：Google 运维解密》读书笔记11: 基于时间序列数据进行有效报警 - 新型的监控

在正式进入第10章之前，有必要对“具体实践”这一部分的整体结构有所了解。章节主题核心内容第10章基于时间序列数据进行有效报警Borgmon、时间序列数据库、报警规则设计第11章on-call 轮值多地团队、轮值频率与生产环境熟悉度第12章有效的故障排查手段假设-排除法、常见陷阱第13-14章应急事件管理降低影响范围、管理事故响应第15-16章事后总结与根源分析无指责文化、事故跟踪系统第17章测试避免已知类型问题重复发生第18-22章容量规划与负载均衡Auxon、GSLB、BwE、连锁故障。

1933

OV9734 DATASHEET，完整规格书

OV9734完整规格书，包括电气参数，尺寸规格，寄存器配置表等

《SRE：Google 运维解密》读书笔记15: 紧急事故管理 - 从“救火”到“管理系统”

事故管理是在事故发生时，通过有序的组织和流程，将影响范围降到最低，并尽快恢复业务的系统化方法。在危机时刻，用结构取代混乱。然而，有一个残酷的事实必须正视：事故发生时才想起建立流程，已经太晚了。流程的建立必须在平静时期完成——通过制定响应计划、明确角色职责、定期进行演习，才能在真正的事故发生时让系统发挥作用。紧急事故管理 = 借鉴 FEMA 事故指挥系统，通过角色分离、控制中心和实时文档，将混乱的危机转化为有序的响应。关键点一句话概括事故管理的核心价值限制破坏 + 尽快恢复，用结构取代混乱理论基础。

1552

jdk-8u144-linux-x64.tar.gz.

该资源为搭建Linux系统Java环境用，资源的后缀为tar.gz格式的压缩包

Google SRE 读书笔记 扒一扒SRE用的那些工具

写在前面最近花了一点时间阅读了《SRE Goolge运维解密》这本书，对于书的内容大家可以看看豆瓣上的介绍。总体而言，这本书是首次比较系统的披露Google内部SRE运作的一些指导思想、实践以及相关的问题，对于我们运维乃至开发人员都有一定的借鉴意义。书中的一些思想也令我印象深刻，例如SRE工程师要保证投入50%的时间在项目上、错误预算、命运之轮、事故总结等等，对于从业者有很大的启发。...

aifeier1982的博客 1267

《SRE：Google 运维解密》读书笔记13: 有效的故障排查手段 - SRE的“暗面”

有效的故障排查 = 通用方法论（假设-演绎法）+ 深厚的系统知识 + 主动分享负面结果。其核心是：先定位恢复、再诊断根因，先假设最简原因、不混淆相关与因果。关键点一句话概括两个核心条件通用排查方法论 + 对特定系统的深入理解，缺一不可核心理念故障排查是假设-演绎法的反复应用：观察 → 假设 → 测试 → 排除六步实践流程报告 → 定位 → 检查 → 诊断 → 测试与修复 → 治愈四大陷阱误判现象、无法安全测试、过早聚焦小概率、混淆相关与因果奥卡姆剃刀。

1475

《SRE：Google 运维解密》读书笔记18: 测试可靠性 - 从“预防故障”到“验证可靠性”

金丝雀测试（Canary Testing）的名字来源于“矿井中的金丝雀”——过去矿工会把金丝雀带入矿井，利用其对有毒气体的高敏感性来预警危险。在正式全面部署之前，先将新版本部署到一小部分机器上，让这些机器承接一小部分真实用户流量，观察一段时间后再决定是否全面推广。测试可靠性 = 通过传统测试验证代码正确性 + 通过金丝雀测试在真实流量中验证变更 + 通过DiRT主动破坏系统验证灾难恢复能力，最终实现“变更可信、事故可控、灾难可恢复”。关键点一句话概括测试的本质。

1589

《SRE：Google 运维解密》读书笔记16: 事后总结 - 失败是通向可靠性的“路标”

书写事后总结不是一种惩罚，而是整个公司的一次学习机会。事故是不可避免的，但重复的事故是可以避免的。SRE负责的系统随着功能迭代和规模扩大，事故难以避免；若无事后总结从事故中学习，事故可能随系统复杂度增加而倍增，最终影响用户，因此事后总结是SRE的必要工具。事后总结的主要目的是为了保证该事故被记录下来，理清所有的根源性问题，确保实施的有效措施在未来重现的几率降低甚至避免重现。书写事后总结的哲学可以概括为四个字：“对事不对人”。

1483

Deeplus直播：解锁中台架构、金融监控、运维平台&工具新实践

本期主题属于Deeplus直播系列公益课程，由dbaplus社群主办，目前已连续举办5年。精选运维、数据库、金融科技、大数据、架构、云等技术方向的深度干货内容及实战经验，每周三晚20:0...

SRE运维部落 1395

读书笔记（SRE：Google运维解密）：第14章紧急事故管理

紧急事故的流程管理要素（a）嵌套式职责分离：在事故处理中，让每个人清楚自己的职责是非常重要的（b）控制中心：受到事故影响的部门或者人需要知道他们可以与事故总控负责人联系。在很多情况下，可以设立一个“作战室”（warroom），将处理问题的全部成员挪到该地办公。（c）实时事故状态文档（d）明确公开的职责交接以下是系统中可以分配给某个人的角色：事故总控（incident command）：事故总控负责人掌握这次事故的概要信息。他们负责组建事故处理团队，按需求和优先级将一些任务分配给团队成员。.

lo_ong的博客 578

应急响应

最近对应急响应特别感兴趣，特意去搜索了一下，发现网上最多的是对应急响应的6个步骤进行的说明，真正涉及到网络安全的应急响应文章只看到两篇文章，一个是在先知上，一个是在t00ls上。特此整理。其中主要参考链接是：https://xz.aliyun.com/t/1140/#toc-6。常规的应急响应应该主要包括两个方面： 1.未雨绸缪，即在事件发生前事先做好准备，比如风险评估、制定安全计划、安全意...

Amdy_amdy的博客 4549

关于SRE方法论的一些笔记

写在前面阿里系列有一本《云原生操作系统Kubernetes》中作者在前言里讲到 Google开源的Kubernetes和《SRE Google运维解密》这本书是剑法和气功的关系换句话讲Kubernetes是术，SRE Google运维解密是道作为云原生基础设施的Kubernetes小伙伴么应该多少有些了解但是对于SRE却很少有人谈及，和小伙伴分享一些SRE的基础知识博文主要为《SRE Google运维解密》读书笔记整理主要为第一部分，摘一些感觉重要。傍晚时分，你坐在屋檐下，看着天慢慢.

山河已无恙 1088

谷歌是如何做应急响应的

简介Google 如何帮助保护客户数据应急响应团队架构应急响应流程识别协调处置完成持续改进总结参考资料简介为客户数据维护安全的环境是 Google Cloud 的首要任务。Google 通...

weixin_47208161的博客 966

一个Google SRE工程师眼中的8点运维原则

我是 Google 一名 SRE （运维）工程师，在过去系列文章中对『SRE: Google 运维解密』一书提出了自己的见解。本文所有见解皆为个人观点，不代表 Google 公司立场。我们来看书中第一章的一些观点： Google 对运维的解决之道：网站可靠性工程（Site Reliability Engineering）[1]。虽然每个 SRE 团队都有自己的工作流程、优先级定义以及日常工作规范，...