通知与发布协作

通知的目标是让负责人在需要行动时获得上下文，而不是为每一次正常同步制造消息。生产环境应区分发布成功、同步失败、长期 Degraded、漂移和高风险删除，并按 Application 或 Project 路由到对应团队。

1. 事件设计

事件	默认建议	接收对象
生产同步成功	可选，汇总或变更单回写	发布人、发布记录
同步失败	立即通知	应用责任团队、值班人员
长期 Degraded	立即通知并附资源原因	应用责任团队、平台值班
OutOfSync	有自动同步时延迟通知	应用责任团队
开发环境同步成功	默认不通知	无

2. 订阅应用通知

Notifications Controller 与触发器、模板的实际名称需按团队安装配置确认。应用侧可通过 annotation 声明订阅关系：

metadata:
  annotations:
    # 示例：将同步失败事件发送到团队维护的 Webhook 接收器
    notifications.argoproj.io/subscribe.on-sync-failed.webhook: platform-alerts
    # 生产同步成功通常只发给发布记录，不建议群发
    notifications.argoproj.io/subscribe.on-sync-succeeded.webhook: release-audit

模板应至少包含 Application 名称、Project、目标集群、Namespace、Git revision、失败资源和 Argo CD 链接。不要把 Secret、完整 Kubernetes 对象或访问令牌放入通知正文。

3. Webhook 与企业 IM

Webhook 接收服务应验证签名或来源网络，并将 Argo CD 通知凭据保存在 Namespace Secret 中。企业 IM 集成的机器人 Token 应按团队隔离、定期轮换，并限制其可发送的群组。

# 检查通知控制器是否运行；名称依安装方式可能不同
kubectl get deploy -n argocd | grep notifications

# 查看失败事件时优先看应用状态与控制器日志
argocd app get user-center-prod
kubectl logs -n argocd deploy/argocd-notifications-controller --tail=200

4. 降噪原则

1. 同一个 revision 的失败应聚合，避免每次重试重复通知；
2. 为开发、测试、生产设定不同路由和严重级别；
3. 应用长时间未恢复才升级给平台值班，短暂 Progressing 不直接告警；
4. 维护窗口前创建静默或暂停自动同步，结束后补做健康验证；
5. 每条通知都应有责任团队和可点击的排障入口。