通知与发布协作
通知的目标是让负责人在需要行动时获得上下文，而不是为每一次正常同步制造消息。生产环境应区分发布成功、同步失败、长期 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. 降噪原则
- 同一个 revision 的失败应聚合，避免每次重试重复通知；
- 为开发、测试、生产设定不同路由和严重级别；
- 应用长时间未恢复才升级给平台值班，短暂 Progressing 不直接告警；
- 维护窗口前创建静默或暂停自动同步，结束后补做健康验证；
- 每条通知都应有责任团队和可点击的排障入口。