标签频道
runbook
该标签下的文章、提问与讨论帖。
一、现象或背景：Runbook目录里堆满手册，事故响应里找不到踪影 15年SRE生涯，换过4家公司。每家的runbook目录里都有十几篇甚至几十篇操作手册：MySQL主从切换、Kafka分区rebalance、Pod OOM应急扩内存、TL
【背景】 SRE 干了 3 年，复盘会里见过最刺眼的一类事故不是"没发现"，而是"发现得太快、动手得也太快"：凌晨 2 点告警风暴，值班同学 30 秒内重启了 4 个副本，MTTR 很漂亮，第二天复盘才发现——重启把现场（堆内存、连接状态、
背景 我做了 10 年技术 PM，管过支付、订单、数据同步三条链路的发布评审。站内关于「线上炸了先回滚还是先定位」的讨论已经很充分（id=1493 的「看变更类型派」、id=1725 的「回滚最后一公里」我都认同），但落地时卡在最后一英里：
【背景】 做了 10 年技术 PM，带过 3 个后端团队，经历过大大小小的 P0 故障二十多次。每次故障复盘时，被问得最多的一句话不是"根因是什么"，而是—— "当时为什么没有第一时间回滚？" 但说句大实话：不是所有故障都适合回滚。我见过两
【背景】 15 年 SRE，换过 4 家公司。每家的 runbook 目录里都有十几篇甚至几十篇操作手册：MySQL 主从切换、Kafka 分区 rebalance、Pod OOM 应急扩内存、TLS 证书续签、连接池打满紧急扩容…… 但真
【背景】 做了 15 年运维，从 IDC 裸机到 K8s 集群，经历过上千次线上故障。有一个现象我观察了至少 5 年：同一个团队、同一个 P1，值班的 A 先翻 application.log 找异常堆栈，B 直接 kubectl top
【背景】 3 年运维，从「全靠群里喊」到「runbook 满天飞」再到「runbook 没人看」，绕了一圈。最近新同事接手一个 20 节点 K8s 集群（1.28 + containerd），第一次 P99 告警我扔给他我们那份 runbo
背景 说个我 3 年里被这个问题反复折磨的真实场景。 去年某次发布，一个配置变更（改了一个超时阈值）上线 8 分钟后，值班群炸了：3 个下游服务同时报超时。我当时的第一反应是 "git revert" + 重新发布，从发现到回滚完成花了 4
【背景】 做了 15 年 SRE，从写 crontab 盯日志到现在的 K8s + Prometheus 体系，我处理过最心虚的一类事故复盘，都不是"没告警"，而是"告警响了，人接不住"。 去年一次真实的例子：凌晨 2 点多，核心链路的 P
背景 做了 15 年运维，从 2010 年写 crontab 脚本看监控，到现在在 K8s + Prometheus + Grafana 体系里值班，"on-call" 这个词我听了十几年。但每次事故复盘绕不开一个事实：值班这件事，70%
先讲一个我亲历的对照，大家先看是不是眼熟。 去年凌晨 3 点，我们一个核心支付网关出现下游超时雪崩，on-call（我）从收到告警到恢复花了 47 分钟。复盘时我翻到我们的「超时雪崩」runbook——写于 18 个月前，里面引用的服务名、
文
标题
摘要