技术问答500题

昨天有个做运维的技术朋友问我，说他们机房里一台老服务器突然开始频繁丢包，问答交换机端口指示灯闪得跟迪厅似的技术。他换了网线、问答重启了交换机，技术甚至把服务器网卡驱动降级了一遍，问答问题还在。技术我让他把服务器网卡的问答中断聚合参数看一下，果然，技术rx-usecs 设成了 0，问答中断全打到一个 CPU 核上。技术改成 64 之后，问答丢包立刻消失。技术这事让我想起一个老问题：很多技术故障的问答根因，其实藏在你根本没注意的技术默认值里。

《技术问答500题》这个册子，最初是我自己整理的一份内部文档。那会儿刚带团队，新人每天问的问题翻来覆去就那么几十个。干脆攒起来，按场景分类。后来发现，真正有用的不是答案本身，而是问题背后暴露出来的认知盲区。比如“为什么我的 Docker 容器时间不对”，答案通常是宿主机 UTC 和容器时区没同步。但更深一层的问题是：很多人以为容器共享内核就等于共享一切，其实命名空间隔离的边界在哪，根本没搞清楚。

写技术问答，最忌讳写成词典。词典按字母排序，查得到就行。但实际工作中，问题从来不是孤立出现的。磁盘满了，可能是日志轮转没配好；日志没轮转，可能是应用根本没写标准输出；应用不写标准输出，可能是开发觉得反正有文件日志。你看，一个磁盘告警能扯出整个团队的运维习惯。所以这份问答的编排逻辑是按“故障现场”来分的，不是按技术栈。网络、存储、计算、权限、性能，每个大类下面再按症状细分。你遇到什么现象，翻到对应章节，大概率能找到相似案例。

举个具体的。第 217 题：“Kubernetes Pod 一直 Pending，但节点资源明明够”。新手第一反应是看 describe pod，看到 Insufficient cpu 就以为是 CPU 不够。实际上可能是节点上已经跑了太多 DaemonSet，或者 kubelet 的 reserved 资源没算对。更隐蔽的一种情况：Pod 的 affinity 规则写得太死，把节点全排除了。这题我特意放了三个不同集群的真实日志片段，因为光看结论记不住，看到报错原文才有肌肉记忆。

还有一类问题，答案会随时间变。比如“MySQL 主从延迟怎么排查”，五年前的标准答案是看 Seconds_Behind_Master，现在这个值在并行复制下已经不太准了。所以每道题后面我都留了一行“时效备注”，标注这个答案在哪个版本区间有效。技术书最怕的就是读者拿着旧地图找新大陆。

有人问我为什么不直接写博客，非要搞成 500 题的问答集。博客是线性的，你得从头读到尾。但工程师查问题的时候是跳跃的，是 Ctrl+F 搜关键词的。问答体的好处是每一条都自包含，读哪条都不影响理解。坏处是容易碎片化，所以我在每个章节开头加了“关联阅读”，把散落的点串成线。比如看完“TCP 重传率高的五种原因”，会提示你去看“网卡多队列配置”和“交换机 buffer 溢出”那几题，它们经常是同一个故障的不同侧面。

最后说个观察。这份文档在团队内部传了三年，被引用最多的不是那些复杂的分布式事务问题，而是第 8 题：“如何用 tcpdump 抓取指定端口的 HTTP 请求头”。简单，但每天都要用。技术问答的价值不在于覆盖多少冷门知识，而在于把高频问题的解决路径固化下来，让新人不用在同一个坑里摔两次。至于那 500 题之外的，才是真正需要动脑子的事。