标签频道
SRE
该标签下的文章、提问与讨论帖。
【背景】线上 MySQL 8.0 主从架构，业务高峰时段出现慢查询 P99 抖动放大 20 倍的异常，通过 performance_schema 的 events_waits_history 表抓包发现部分查询耗时突然激增。 【现象】 1.
背景 维护一个12节点K8s集群（16C64G），运行40+服务含Java应用（Spring Boot 2.7/JDK17）。去年统一requests=limits策略后，发现Java服务频繁OOMKill，复盘发现Netty的off-he
一、现象或背景：Runbook目录里堆满手册，事故响应里找不到踪影 15年SRE生涯，换过4家公司。每家的runbook目录里都有十几篇甚至几十篇操作手册：MySQL主从切换、Kafka分区rebalance、Pod OOM应急扩内存、TL
一、现象或背景 一条读多写少的商品详情服务（Java 17 + Spring Boot 3.1 + HikariCP 5.1.0，后端 MySQL 8.0.35，中间隔了一层云 RDS Proxy / SLB），QPS 稳定 600，P50
Kubernetes liveness探针实践：浅探活、深探活与中间派的抉择 背景：从嵌入式看门狗到容器探针 做了10年嵌入式，早期写MCU固件时"健康"这件事是被看门狗强制定义的：主循环喂狗成功=活着，喂不上=复位。边界极其干净——只看"
【背景】 Kafka消费者组Rebalance是分布式系统中常见的性能瓶颈，但多数团队仍困在『参数调优→架构改造』的二选一困境。我们曾因Rebalance风暴导致单集群吞吐量骤降40%，而业务方要求『零代码改动』。 【常见分歧】 1. 监控
一、背景与问题 我们团队在2024年Q2搭建的API网关，因未考虑突发流量导致服务雪崩，最终通过「分层限流+动态扩容」方案解决。事故复盘发现，45%的线上系统仍存在网关层扩展性缺陷： - 突发流量承载不足：未配置弹性扩容机制，导致服务雪崩
【背景】 我们团队在2024年Q2搭建的API网关，因未考虑突发流量导致服务雪崩，最终通过「分层限流+动态扩容」方案解决。现线上仍有45%的系统未实现网关层的弹性扩展。 【常见分歧】 - 参数派：靠调整max_connections、kee
【背景】 我们线上有30+个Kafka消费者组，最近7天平均每天发生12次Rebalance风暴，导致数据积压+消费延迟，甚至引发过3次业务降级。 【常见分歧】 1. 参数调优派：主张调max.poll.interval.ms/heartb
一、背景与问题：Rebalance风暴的代价 在电商大促场景中，某平台order-event topic因消费者组Rebalance风暴导致每秒数千消息丢失。当消费者组规模从8实例扩到16实例时，Rebalance频率从每10分钟1次激增至
背景：Kafka消费者组Rebalance风暴常导致数据丢失、延迟激增，传统方案需业务代码改造。 常见分歧： 1. 『监控+熔断』派：通过JVM指标预警+消费者降级 2. 『元数据治理』派：优化topic分区策略+副本分配 3. 『链路注入
背景 我们管理一个 Kubernetes 集群，节点上配置了 kube-reserved 和 system-reserved 以确保系统资源的预留。然而，在某些情况下，业务 Pod 会被驱逐，怀疑是由于 kube-reserved 和 sy
【现象】 业务Pod在节点内存使用率仅65%时被驱逐，驱逐后服务中断5-10分钟，节点资源使用曲线显示驱逐发生时内存有1.2Gi空闲。 【已尝试的排查】 1. 检查节点资源分配：kube-reserved=memory=2Gi，system
«作者视角：8 年网络工程，长期做跨机房同步与链路排障。这篇文章复盘一次"时好时坏、抓小包正常、抓大包就挂"的故障，最后根因不在应用、不在 K8s，而在一条被忽略的 MTU 不一致。全文给可复现命令与参数。» 一、现象：小包秒回、大包必挂，
背景 我们管理一个 Kubernetes 集群，节点上配置了 kube-reserved 和 system-reserved 以确保系统资源的预留。然而，在某些情况下，业务 Pod 会被驱逐，怀疑是由于 kube-reserved 和 sy
一、现象或背景 我在一个 3 节点自建 K8s（1.28.9 + containerd 1.6.24，节点 16C64G，内核 5.15.0-91，cgroup v2）里把 etcd 拆到独立节点单独管，数据目录在本地 NVMe。业务侧 r
Kubelet Secret 残留问题：原理、诊断与清理全链路实践 一、现象或背景 在 Kubernetes 集群中，Secret 作为敏感数据的载体，常用于存储数据库密码、API 密钥等。然而，在实践中，我们常遇到一个问题：Secret
【背景】 我们线上某个核心业务的Kafka消费者组，每月会经历3-5次Rebalance风暴，导致消费延迟最高达40分钟。传统方案需要业务方改代码加分区锁，但改造成本高且存在风险。 【常见分歧】 1. 检测层：是否需要埋点追踪Consume
一、现象或背景 做了 5 年安全加固与风险防范，最常被开发同学反驳的一句话是："你这个规则一加，P99 直接涨了 8ms / 请求被误拦了 / 日志量翻了 3 倍，业务能不能先不上？" 我经历过三种典型冲突： - 订单服务加了双向 mTLS
一、现象或背景 在一次性能优化上线后，我们团队面临一个关键决策：优化上线、指标达标后，临时加的观测基建该留还是该拆？ 背景如下： - 商品列表接口 P99 从 220ms 超 SLO（150ms），根因是连接池耗尽 + 一次慢查询拖住 wo
已经到底了
文
标题
摘要