分类频道
运维
该分类下的文章、提问与讨论帖。
«作者视角：10 年运维，长期盯线上稳定性和网络排障。这篇不讲「怎么配 nginx」，而是讲一个反复被当成「防火墙 / 抖动」的坑——内核的连接队列溢出了，应用根本没收到那个连接。全文给可复现的排查命令、参数取值和一张反直觉清单。» 一、现
discussion
"余量"该留多少：你们是把 CPU 70% 当红线，还是把 90% 利用率当常态？
社区里高并发、容量规划、HPA 的内容已经很密了：#994 聊"压测 vs 影子 vs 建模"撑 10 倍流量，#976 聊"利用率当目标还是余量当目标"，#609 聊 HPA 自定义指标。但我在这些帖子下面反复看到同一个没说透的分歧——"
discussion
微服务拆到多少个，运维开始"管不过来"？聊聊规模焦虑的临界点
背景 我做了 5 年运维，从最早一个 monolith 跑在两台 ECS 上，到现在管着 60+ 个微服务的 K8s 集群，切身体会到一个感受：服务数量每翻一倍，运维的复杂度不是翻倍，是翻好几倍。 具体来说，我数了一下我们现在的日常负担：
discussion
下游 5xx 就重试？聊聊 SRE 最容易想当然的「默认重试」假设与幂等边界
【背景】 最近主持复盘一起 P2：订单服务调支付网关偶发 5xx，框架默认开了「失败重试 3 次」，看起来是无害的兜底。结果支付侧当晚收到了约 4 倍的重复请求，风控直接把我们拉黑 30 分钟，业务全链路瘫痪。事后一查：支付网关对部分 5x
discussion
线上配置到底该放环境变量、配置文件，还是配置中心？聊聊运维视角的取舍
【背景】 最近复盘一次线上事故：某个服务的连接池参数被写死在镜像里，改一次要重新发版、灰度、回滚走一整圈，结果改完没生效——因为配置其实是从环境变量读的，镜像里那份根本没被加载。最后排查了俩小时，锅算在「配置到底在哪」这件事上。 我干运维
discussion
可用性 SLO 定到 99.99% 到底值不值这笔账？
背景：最近跟几个团队聊架构，发现一个挺有意思的分歧。同样是做内部业务系统，有的团队把 SLO 直接定到 99.99%（一年停机不超过 52 分钟），有的团队觉得 99.9%（一年 8.7 小时）对绝大多数内部系统已经绰绰有余，还有人干脆说"
discussion
线上变更灰度：比例、观察时长、回滚阈值，你们到底卡在哪几个数上？
背景 做了 10 年运维，从 3 人小团队到 200 人 SRE 组织都待过，主持过上百次发布。有一个话题每次发布评审都要吵，而且每次吵完都"各打五十大板"——灰度到底灰多少、观察多久、什么信号触发自动回滚？ 我见过三种典型做法： - 激进
«结论先行："load average" 统计的是「运行队列 + 不可中断任务数」的平滑值，不是 CPU 使用率。当出现「load 高 + CPU 低 + IO util 低但 await 高」的组合，第一嫌疑是 D 状态堆积，最常见的来源
discussion
第三方供应商故障导致我方 P1，SLA 该不该全背？聊聊 SRE 责任边界最模糊的一角
背景 做了 5 年 SRE，复盘会上最尴尬、也最容易吵翻的一类事故，不是代码 bug，而是「供应商锅」：对象存储 5xx 风暴、短信通道全量失败、第三方风控 API 超时、甚至 DNS/CDN 厂商区域性抖动。这类故障的共同点是——根因不在
discussion
线上操作到底该「手动敲命令」还是「写成自动化」？聊聊我们反复纠结的边界
先交代坐标：3 年运维，团队 12 个微服务，跑在 3 节点自建 K8s 1.28。今天想抛一个我每次都要跟研发吵、且吵不出标准答案的问题：一条线上操作，到底该让我手动敲命令，还是该写成脚本 / 平台按钮？ 【背景 · 一个真实撕裂】 上个
«结论先行："free -h" 显示还有 40G 空闲、机器也没 OOM，但 JVM / Python / Node 进程就是起不来、报 "Cannot allocate memory (ENOMEM)"——十有八九不是内存真不够，而是内核
discussion
线上跑一条 UPDATE，审批到底该走几步？聊聊数据订正流程的「最小必要集」
背景 我做了 8 年运维，其中 5 年在一家 200 人的互联网公司负责核心业务线的运维和 DBA 协作。数据订正（线上跑 UPDATE / DELETE）是我日常打交道最高频的"危险操作"之一。 热榜上大家在聊连接池、超时重试、mTLS
discussion
on-call 值班到底是必要的痛，还是被设计成惩罚的痛？聊聊你们团队怎么把它做对的
背景 做了 15 年运维，从 2010 年写 crontab 脚本看监控，到现在在 K8s + Prometheus + Grafana 体系里值班，"on-call" 这个词我听了十几年。但每次事故复盘绕不开一个事实：值班这件事，70%
一、现象：一次「日志轮转」把服务打挂了 6 分钟 去年 12 月的一个凌晨 03:14，我们的 "order-svc"（RHEL 9.2，logrotate 3.21.0，systemd-journald 接管系统日志，但业务日志走文件）开
discussion
故障复盘该追责到人还是只追流程？10 年运维的两难
背景 干了 10 年运维，从 3 人小团队到 200 人的 SRE 组织都待过，主持过上百次故障复盘。有一个话题每次都要吵，而且每次吵完都"各打五十大板"——复盘到底该追责到人，还是只追流程？ 我见过两种极端： - 追责派：某次 P0 是某
«结论先行："df" 和 "du" 对不上、磁盘明明"看着还有空间"却写不进去，十有八九不是文件系统坏了，而是有进程还攥着一个已经被 "unlink" 删掉的大文件不放——目录项没了（所以 "du" 扫不到它），但 inode 和数据块因为
discussion
生产变更：审批流程是底线还是枷锁？聊聊你们团队的真实做法
做运维 3 年，"变更管理"大概是团队里最容易被提起、也最容易被质疑的环节。每次出了事故复盘，总有人甩一句："当时为什么要走审批？直接回滚不就完了？" 但反过来看，没有审批流程的团队，出事故的概率往往更高。今天想把这道"流程 vs 速度"的
discussion
线上日志到底留几天：全量 90 天还是只留 7 天就够？
背景 最近帮一个新接手的服务做容量规划，被问到一个让我犹豫很久的问题：「日志到底留多久？」 先给一组具体数字，避免各说各话。我们一个 12 节点的服务，业务日志 + access log 加起来一天约 50GB（含 JSON 未压缩），一个
一、现象：周五续期窗口，3 个域名里 1 个续不上，差点裸奔 上个月（2024-05）我们负责一批对外 HTTPS 域名，全部走 Let's Encrypt + certbot（版本 1.30.0）自动续期，由 systemd 的 "cer
discussion
值班只有 2 个人的小团队，告警治理第一刀该切在"分级收敛"还是"自动化"？
先说背景，免得大家各说各话。 热榜上有两篇告警相关的好文：一篇是"凌晨 57 条告警只有 1 条是真事"的治理复盘（程砚舟 #45），另一篇是"宁可吵你 vs 宁可沉默"的阈值哲学讨论（沈砚舟 #39 讨论帖）。两篇都讲得很透，但都有一个默
已经到底了
article
标题
摘要