专门写这一篇文章，是因为曾经遇到过有同事不熟悉数据库，甚至没用过 EXPLAIN，当遇到慢 SQL 之后，第一反应往往是问有经验的人。所以，本文不会假定你对数据库有很高的熟悉程度，但是写 SQL、建索引这些还是得会的，部分超出范围的内容也都有讲解。执行 EXPLAIN，屏幕上很快出现一堆内容：type=range、cost=35.50、Bitmap Heap Scan、USE TEMP B-TREE。如果使用过或者阅读过文档，看到这里可能会觉得问题已经有了答案，但实际上，排查

测试环境和生产环境到底差在哪？资源少的时候，问一圈同事，翻翻控制台，大概还能找到答案。当网络、数据库、IAM 和 Kubernetes 集群分散在几个平台，随着时间的流逝，这个答案就很难获取了，更不用说再搭一套相同的环境了。基础设施即代码 (Infrastructure as Code, IaC) 就是针对这个问题的一种解法：把资源及其关系写进文件，让变更能审查、能复现。Terraform 多年来是常见选择，围绕 HCL 配置语言、Provider 和 Module 积累了大

后端服务引入消息队列，开始时往往只是为了把一段耗时操作放到后台执行。后来又会加入事件通知、失败重试、广播、顺序消费和历史重放。看起来都在发消息，实际需要的存储方式和消费模型并不相同。选型时最容易比较的是吞吐和延迟，这个数字很重要，但有些问题更值得关注，例如消息丢失后如何恢复、扩容 Consumer 是否需要提前增加 Partition。以至于部署多少组件、如何升级、磁盘故障后怎样恢复，可能系统没上线之前都被忽略掉了。NATS、NSQ、Kafka、RabbitMQ 和 Puls

服务出了问题，通常先从指标发现异常，再到链路中定位耗时，最后结合日志查明原因。实际使用时，这三类数据往往来自不同的采集工具，字段名称也不一致。指标里叫 service，日志里可能叫 app_name；链路中有 trace_id，日志却没有记录。数据虽然都在，查询时却很难互相关联。业务代码如果直接使用某家监控厂商的 SDK，问题会更麻烦。更换后端时，不仅要迁移数据和仪表盘，还可能要重新修改各个服务的埋点代码。OpenTelemetry 用一套通用规范解决采集环节的问题，下文简称

Kubernetes 资源可以用 kubectl apply 部署，也可以交给 CI 在流水线中执行 Helm。服务不多时，这些方式足够简单。集群和环境增加以后，问题会逐渐出现：生产环境究竟对应仓库中的哪个版本？有人临时修改了 Deployment，Git 中的配置是否仍然有效？CI 已经结束，部署失败后由谁继续重试？集群重新创建时，怎样恢复到原来的状态？GitOps 的做法是把 Git 中的配置作为期望状态，再由运行在集群内的控制器持续比较并修正实际状态。Flux CD 是

在《博客重构》里，我专门解释过为什么选择 Mantine：我熟悉它，组件足够全，拿来就能用。那次重构的第一目标是尽快把博客从 Hexo 搬到 Next.js，而不是先花几个月造一套按钮、卡片、抽屉和响应式布局。Mantine 很好地完成了这个任务。问题是，将近一年之后，目标变了。页面早已能用，内容构建、搜索、代码高亮和移动端目录也逐渐稳定。我不再需要一个组件库帮我快速搭出所有东西，反而开始在意每个页面究竟带了多少 CSS、浏览器为什么要下载这些规则，以及一个看起来很简单的静态