不要仅凭一个绿色状态就结束部署
一句话总结
部署完成不是一个状态值，而是确认预期提交、已应用资源、就绪进程和真实请求结果彼此一致。GitOps 会忠实应用错误的 Git，所以与 Git 同步不等于服务可用。
为什么需要它
假设订单 API 的 readiness 路径被改错。语法和 API 验证通过，Argo CD 显示 Synced，但新 Pod 不 Ready，Service 也没有 Ready endpoint。此时应先收集证据，而不是猜网络故障或盲目回滚。GitOps 控制器只应用和观察声明状态，不知道业务答案；Healthy 也不能证明价格正确或所有用户成功。
工作原理
| 问题 | 证据 | 尚不能证明 |
|---|---|---|
| 想部署什么 | targetRevision、Git 提交与 diff | 是否已应用 |
| 是否同一提交 | status.sync.revision、Synced | Pod 就绪、请求成功 |
| 控制器是否认为就绪 | health、generation、副本、条件 | 业务结果正确 |
| 请求是否真实成功 | 经 Service 的 HTTP 状态和正文 | 所有路径、用户与负载成功 |
单副本 Deployment 应核对 desired、observedGeneration、updated、ready、available，并查看 EndpointSlice。缺字段不能随意当作 0 或成功，必须暂停或失败并说明证据不足。
以下命令只用于自己建立的隔离环境。把 demo 换成实际名称。
kubectl -n argocd get application demo -o json
kubectl -n demo get deployment web -o json
kubectl -n demo get endpointslices -l kubernetes.io/service-name=web -o json
kubectl -n demo describe pod -l app=web
随后发送真实请求。VM 内访问 ClusterIP 只证明该路径，外部用户还会经过 DNS、网关、TLS、认证。kubectl exec 中访问 Pod 自身成功，不能代表 Service 或外部路径成功。
正常 nginx readiness 检查 /，若改成不存在的 /not-ready，YAML 和进程仍可能正常，Application 也可 Synced，但 Pod 不 Ready。单副本 Recreate 可用于明显观察故障，但不是高可用推荐设置。RollingUpdate 中旧 Pod 仍服务时，新 Pod 失败也可能继续返回 200，因此要同时看策略与剩余正常 Pod。
main 跟踪分支最新提交；固定 SHA 的 Application 不会因分支新提交自动移动，需更新 targetRevision。固定 Git SHA 也不等于固定使用移动标签的镜像内容。
无状态配置错误可用 git revert 创建新恢复提交。内容可能等于旧正常提交，但 SHA 不同；应核对选定新 SHA、树、集群状态和响应。selfHeal 会把手工修补重新改回 Git 状态，因此也要修正声明源。Argo CD rollback 与 Git revert 后发布新提交并非同一操作。
现场表现
报告应区分正常、失败、恢复提交，并记录 sync revision、健康、probe 原因、endpoint、HTTP 结果。不要保存令牌或敏感正文。门禁还要双向测试：旧提交的 200、Synced 但 Degraded、无 endpoint、200 但正文属于其他版本、缺字段，都必须拒绝。
这只是无状态 Web 配置恢复，不代表 DB 模式回滚或消息撤销。数据发布还需兼容性、备份恢复、重处理和去重设计。
下一步
后续练习会区分文件检查与真实运行检查，并在真实 Argo CD 中观察正常、故障、恢复，保存 Git 历史与持续证据，最后重测当前服务。