背景：团队新人又慌了 七月一次支付成功率骤降，新来的同学第一反应是「我先重启试试」。结果重启把现场冲了，后面复盘只能靠猜。这种事不是第一次，我干脆把我们的线上排查 SOP 固化成文档，要求所有人遇事先照流程走，别凭直觉乱动。 第一原则：止血优先 出问题第一时间想的不是「为什么」，是「怎么不让它继续坏
我们为什么离不开 Nginx 后端是 Spring Boot 起的 8080 服务，但直接把 8080 暴露在公网既不安全也难扩展。一来没有 TLS 卸载，二来单实例挂了没容灾，三来限流得在每个应用里写。Nginx 在我们架构里身兼数职：反向代理、负载均衡、限流、长连接优化。它配一次能管一片服务，是
一次误删 ConfigMap，让我重新想发布这件事 年初我们还是"人肉发布"：本地打镜像、kubectl set image、改几个 ConfigMap。有次同事手滑把生产环境的 ConfigMap 改错了一个 value，Pod 起来就读不到正确配置，故障持续了 12 分钟。事后复盘，我意识到问题
滚动发布时，监控里出现了 0.3% 的 5xx 毛刺 4 月一次常规滚动更新，发布过程中 Grafana 的 5xx 曲线冒出一排小毛刺，单个实例发布期间大约丢了 0.3% 的请求。量不大，但每次发布都有，说明是上下线姿势不对，不是偶发。 我们的 Java 服务跑在 K8s 上，Spring Boo
上了 K8s 之后，Pod 每天重启三四次 6 月初把订单服务迁到公司新搭的 K8s 集群（1.19）。上线第一天就发现问题：Pod 频繁重启。 $ kubectl get pod -l app=order-service -n trade NAME
新人装环境装了两天，我写了份 docker-compose.yml 组里 2 月来了个新同事。第一天拉代码，第二天还在拉代码——不是网速问题，是在装环境：MySQL 8.0、Redis 5.0、RocketMQ 4.6.1、Nacos 1.1.4、Elasticsearch 7.5，一个一个装，中间
一个 780 MB 的镜像，让每次发布多等三分钟 我们去年底把服务容器化了，当时赶时间，Dockerfile 写得非常粗糙： FROM openjdk:8-jdk WORKDIR /app COPY target/order-service.jar app.jar EXPOSE 8080 ENTRY
每次发版都有几十个 502，终于找到原因了 我们服务是 2019 年 11 月上的 Kubernetes，1.16 版本，Deployment 配 4 个副本。从上线那天起，每次滚动发布，网关那边都会报几十个 502，持续时间一两秒。因为量不大、用户基本无感，一直没排。 直到 1 月初做活动，晚上八
第一次独立部署：catalina.out 里那几行看不懂的报错 九月份，师傅让我自己往测试服务器部署一次项目。我以为就是把 war 包扔进去，结果从下午两点折腾到晚上八点。这篇把我那天遇到的四个坑和后来整理的排查顺序记下来，免得下次再花六个小时。 环境：CentOS 7.4，JDK 8u151，To
第一次登生产服务器，我连日志在哪都不知道 入职第二周，导师丢给我一台测试机的账号，说"你自己把服务起起来"。我 cd 了半天，连 jar 包放哪都找不到，最后是靠 ls 一个个目录翻出来的。那天之后我把常用的命令整理成了这份清单，现在贴出来，也给刚上手的同学参考。 环境是 CentOS 7 + JD
