进程正在运行，与能够接收业务流量是两件事。一个永远返回 200 的健康接口，只能证明请求到达了某段代码；一个检查所有外部依赖的探针，又可能在共享依赖故障时引起集体重启。
给检查划分明确职责
存活检查关注进程是否需要重启，就绪检查关注是否适合接收流量，启动检查处理初始化过程。具体检查内容应结合应用特点，避免所有探针调用同一套复杂数据库查询。
依赖故障不一定靠重启恢复
数据库暂时不可用时，重启应用可能增加连接压力而不解决根因。决定是否摘流或重启前，应明确应用能否自恢复、是否存在降级路径，以及整个服务集群会发生什么。
关键业务需要独立验证
健康检查适合轻量信号，完整业务可用性可以通过受控的合成检查或关键指标观察。合成请求要避免真实扣费、发信等副作用，并明确测试数据与清理责任。
验收三种不同故障
分别模拟启动慢、进程卡住和共享依赖不可用，检查平台行为是否符合设计。正常启动一次不足以证明探针配置正确，应观察错误重启与流量切换情况。
常见问题：探针越频繁越容易发现问题吗？
频率需要与检测成本、误判容忍和恢复目标配合，过于频繁可能增加负载并放大短暂抖动。
技术参考：Kubernetes：应用探针。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果你的 .NET 应用还缺少可重复的部署、观察或恢复流程，可以通过容器化与自动化交付服务梳理现状，约定实施内容、演练场景与运维交接方式。