我们也许应该定期记录每台服务器有多重要
当数据中心或大学机房的冷却或供电失败时，清楚知道哪些系统可以牺牲、哪些必须保持在线变得至关重要。评论者对比了“宠物 vs. 牛群”的基础设施理念，指出即使是在现代、类似云或基于 Kubernetes 的环境中，你仍然需要清晰的资产清单、依赖关系图，以及对服务关键程度的共识。预算限制、遗留硬件和学术治理结构往往阻碍理想的冗余，因此组织依赖文档、打标签和经过演练的负载卸载方案来降低故障影响。
冗余冷却和设施限制
- 许多人主张采用 N+1 或多机组冷却（例如 4–5 个更小的机组），以避免单点故障；更小的标准化机组整体上可能更便宜，也更易维护。
- 其他人指出，大学往往缺乏资本、物理空间和设计影响力，尤其是在老旧的“历史性”建筑中，因此即使长期来看能节能，冗余和现代化也很难获得资金支持。
- 还有人把冗余比作保险：跳过冗余是一个明确的风险决策，而其真实成本会在停机时显现出来。
“宠物 vs 牛群”与服务器重要性
- 几位评论者表示，“牛群而不是宠物”的口号并不适用于许多环境：学术界、HPC、电信以及遗留系统很多的企业仍然有独特、不可互换的系统。
- 即使在“牛群”环境中，你也必须优先决定在容量受限时哪些服务能继续运行；这个隐喻可能会掩盖真实依赖关系以及脆弱的“隐藏宠物”（例如存储、DNS、SDN 根节点）。
- 其他人为这个隐喻辩护，认为它推动了标准化、自动化和可替换的基础设施，但也承认它可能会变成一种限制思维的 meme。
资产、文档和依赖关系跟踪
- 多条评论强调应当有资产清单，按应用和关键程度打标签，并记录服务器用途及其相互依赖关系。
- 一些组织拒绝运行那些没有关联到已记录服务的机器；当所有者在停机后感受到因被误分类为“无关紧要”而带来的痛苦时，文档质量会提升。
- 跟踪依赖图（并定期通过关闭一些东西来测试）被视为至关重要，可避免意外的传递性故障。
优先级、政治与组织现实
- 关键性评级方案可能会被政治因素扭曲；如果一切都被标成“关键”，规划就会失败。将成本分摊或运维义务与高关键性状态绑定，可以起到制衡作用。
- 学术性和“封建式”的组织结构，使集中式优先级排序和平台化方法更加复杂。
虚拟化、云和 Kubernetes
- 虚拟化因能够迁移 VM、制作快照，以及集中关闭不那么重要的主机而广受好评。
- 云被认为非常适合多数据中心和地理冗余，不过有人认为它的成本高得多，而且许多工作负载仍然不适合。
- Kubernetes 被强调有助于在 pod/工作负载层面削减负载，并抽象出具体由哪台物理机器运行什么，但它仍然需要明确的优先级划分和谨慎的存储设计。