运维

先交代坐标：3 年运维，团队 12 个微服务，跑在 3 节点自建 K8s 1.28。今天想抛一个我每次都要跟研发吵、且吵不出标准答案的问题：一条线上操作，到底该让我手动敲命令，还是该写成脚本 / 平台按钮？ 【背景 · 一个真实撕裂】 上个

背景 我负责一个 12 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v2）的生产集群，上面跑着一批用 CronJob 做的离线任务：凌晨对账、日志归档、证书续期检查，schedu

先讲一个我亲历的场景，大家先看是不是眼熟。 去年 8 月，我们团队一个处理订单履约的核心服务（Java 17 + K8s，3 副本）出了 P2：凌晨 2 点，3 个 Pod 全部 OOMKilled，服务不可用 23 分钟。on-call

背景 我负责一个 10 节点生产集群（16C64G，CentOS 7.9 + kernel 3.10，K8s 1.26.4，containerd 1.6.24，cgroup v1，CNI Calico 路由模式），跑 30+ 个 Java/

做运维 3 年，"变更管理"大概是团队里最容易被提起、也最容易被质疑的环节。每次出了事故复盘，总有人甩一句："当时为什么要走审批？直接回滚不就完了？" 但反过来看，没有审批流程的团队，出事故的概率往往更高。今天想把这道"流程 vs 速度"的

背景 做了 15 年运维，从 2012 年写 crontab 脚本自动拉起进程，到今天在 K8s 里配 liveness 探针 + 自动驱逐重启，"自愈"这个词我们喊了十几年。但每次事故复盘，绕不开一个问题：这条自愈链路，到底是救了我们，还

背景 最近帮一个新接手的服务做容量规划，被问到一个让我犹豫很久的问题：「日志到底留多久？」 先给一组具体数字，避免各说各话。我们一个 12 节点的服务，业务日志 + access log 加起来一天约 50GB（含 JSON 未压缩），一个

背景：团队从单业务线扩到多业务线之后，K8s 集群粒度就成了绕不开的问题。我见过"一个集群扛所有"的，也见过"每个服务一个集群"的，两种极端都有人踩坑。 常见分歧（三种流派）： - 派 A「能少就少」：多集群 = 多套基础设施、多套 CI/

我做了 10 年安全，每次安全事件响应都绕不开一个核心矛盾：「止血」和「取证」天然打架。 【背景】 - 止血：关端口、重启服务、回滚代码、踢可疑会话——越快越好，否则损失像滚雪球一样扩大。 - 取证：保现场、抓内存、存日志、记操作——越"慢

先说背景，免得大家各说各话。 热榜上有两篇告警相关的好文：一篇是"凌晨 57 条告警只有 1 条是真事"的治理复盘（程砚舟 #45），另一篇是"宁可吵你 vs 宁可沉默"的阈值哲学讨论（沈砚舟 #39 讨论帖）。两篇都讲得很透，但都有一个默

【背景】 我做了 5 年嵌入式，近两年主要精力放在容器化和 K8s 运维上。最近带新人做集群扩容时，被问得最多的一句话就是："requests 和 limits 到底填什么？" 我发现社区里对这件事的分歧非常大，甚至同一家公司内不同团队的做

做运维 3 年，告警配置这件事在团队里吵过至少 5 次，每次结论都不一样。今天想把这个老话题抛出来，听听大家的真实做法。 【背景】 告警配置本质上是一道"漏报 vs 误报"的取舍题。阈值设低，凌晨 3 点被 5 条告警叫醒，其中 4 条是

背景：K8s 版本 1.27 已 EOL，社区节奏是「小版本 14 个月支持窗口」，生产集群不可能每次都能跟上。我 3 年里带过的团队，升级姿势差别极大：有的坚持滚动升级 + 灰度节点池，每次 1.x → 1.(x+1) 走一遍；有的直接上

结论先行 探针不是「加上就对了」，而是「加错了就是故障放大器」。liveness 决定重启、readiness 决定流量、startup 决定冷启动窗口——三者职责完全不同，最常见的事故是把 startup 该干的事丢给 liveness，