Linux 危机工具

预先安装“危机工具”

• 许多人主张建立一个标准的“危机必备”软件包组，类似于 build-essential，并在所有服务器上提前安装。
• 有些人已经通过配置管理（Ansible/Salt/Chef）以诸如 devops_tools 之类的名称维护这样的清单。
• 人们担心，出于“安全”而精简系统和容器，往往会移除关键的调试工具，使事故更难解决。

云、牛群，以及“直接杀掉机器”

• 一派赞赏虚拟化的“牛群”（通常在云中）：故障节点可以迅速替换，从而恢复服务并离线调试。
• 也有人反对：替换会掩盖根因，削弱排障能力，而且有时问题在新实例上仍然存在。
• 还有几位指出，这种“先重启/替换”的文化，类似于初级开发者只会重新克隆 git 仓库，而不是理解问题。
• 有人区分短期与长期的取舍：快速重启是合理的，但如果滥用，就会导致“技术神秘主义”。

存储、网络和非平凡故障模式

• 评论强调，在复杂存储（RAID、Ceph、MD、分布式文件系统）场景下，盲目替换 VM 是有风险的；重建可能增加故障风险。
• 网络和 DNS 问题很常见，也经常被误诊；关于“永远不是 DNS……直到它真的是”的调侃很有代表性。
• 在大型“硬核设备”或 HPC 集群上，故障可能涉及编排层（例如调度器）、分层存储以及奇特的互连网络。

容器、Kubernetes 和无服务器

• 这些工具在 EC2 和容器内仍然有用，因为容器只是主机上的进程；主机层工具仍可对其进行检查。
• 对于没有 OS 访问权限的无服务器环境（例如 Lambda），人们会退回到应用层可观测性/性能分析。
• 安全优先的 Kubernetes 环境通常没有 shell 和工具；有人建议加入调试镜像或包含静态二进制文件的卷，但管理层可能会因为测试和扫描要求而不愿意。

提到的具体工具和方法

• 系统与跟踪工具：perf、eBPF 工具、strace（作为“最后手段”）、lsof、fuser、sar 系列、atop（有注意事项）、tmux/screen。
• 网络/磁盘/调试辅助：nmap、netstat、nc、Docker 中的 tcpdump、ncdu、rsync、busybox、静态救援二进制文件。
• 有些人主张在包管理器坏掉时使用 Docker 提供的工具，而另一些人指出，在空气隔离环境中这行不通。

安全性 vs 可运维性

• 一方担心预装强大工具会增加攻击面。
• 另一方反驳说，攻击者通常可以自己带工具；真正的代价是在危机时反复被困在几乎没有工具的环境中。