SaaS 是否应让客户自选故障通知渠道？
题干与适用场景
一家 B2B SaaS 想让客户订阅服务故障和维护通知，候选渠道包括状态页、Email、短信、Slack、Teams 和 Webhook，且可按组件订阅。请决定是否做、先服务谁、如何避免告警疲劳，并说明严重故障、局部故障和维护通知的不同策略。假设产品服务多个时区和大型企业，不能把“发得越多”当作价值。
面试官考察点
面试官考察的是产品取舍：你是否把通知视为风险控制和行动入口，而非营销触达。强回答会按影响与紧急程度定义默认策略，区分可发现性、送达率、重复噪音和合规责任；能说明为什么组件订阅、Webhook 和退订链路会改变工程成本与客户价值。
回答前需要澄清的问题
- 谁需要行动？值班工程师、业务管理员和普通用户的时效、渠道和权限不同。
- 事件粒度是什么？全站中断、单组件退化、计划维护和安全事件不能共用一条通知规则。
- 客户已有何种集成？若已有 SIEM、ITSM 或值班平台，Webhook 的边际价值高于再做一个聊天机器人。
- 是否允许客户控制默认订阅？关键安全或合规事件可能必须发送，普通更新则应允许精细退订。
- 如何衡量成功？应同时看受影响客户的行动率、有效送达、误报退订和支持工单，不能只看发送量。
推荐方案与推导
先做“事件影响 × 紧急程度”矩阵。P1 全站不可用默认进入公开状态页，并向受影响订阅者发送 Email；客户主动选择时再增加短信或 Webhook。P2 局部组件退化只通知订阅该组件的管理员；计划维护提供提前提醒和变更窗口；安全事件按法律和合同要求处理，避免在公开消息中泄露内部细节。
第二步建立偏好模型：组件、事件类型、严重等级、渠道、时区、免打扰窗口和退订状态都应可见。每条消息携带事件 ID、当前状态、下一次更新时间和管理订阅入口。发送层要有去重键和重试上限，Webhook 需要签名、指数退避和可重放事件；短信需要成本上限和频率保护。
第三步分阶段发布：先状态页加 Email 订阅，验证覆盖率和有效行动；再开放组件订阅；最后为有明确集成需求的客户提供 Webhook、Slack 或 Teams。将“能否在受影响组件上做出正确动作”作为北极星结果，而不是渠道数量。
替代方案与取舍
只提供状态页最便宜、最少噪音，但要求客户主动查看，无法满足值班响应。全渠道默认推送可提高触达，却会增加成本、重复和退订。按组件与严重等级订阅提供更高相关性，但需要稳定的组件目录、权限模型、事件分类和迁移兼容。企业专属通知策略可满足合同需求，却可能造成产品分叉；应优先通过策略配置而非硬编码分支解决。
失败场景、边界与反例
- 把每次内部重试或短暂抖动都当作客户事件，造成告警疲劳。
- 允许客户完全退订安全或合同要求的通知，留下责任和合规风险。
- 只记录发送成功，不验证短信号码、Webhook 响应、邮件退信和最终行动。
- 组件重命名或拆分后没有迁移订阅，客户以为仍在接收保护范围内的通知。
- 将状态页、客户通知和内部值班消息写成三套事实，导致状态不一致；应由一个事件状态源派生不同受众的消息。
测试与验证清单
用历史事件回放验证矩阵：全站 P1、单组件 P2、计划维护、误报后关闭、重复更新和跨时区窗口。测试退订、重新订阅、组件迁移、Webhook 重放、短信频率限制与邮件退信。上线后按客户和事件等级观察有效送达率、受影响客户行动率、每事件消息数、退订率、支持工单变化和通知成本，并设置停止扩展的护栏阈值。
追问与延伸
默认渠道应该如何设定？
按风险设默认：受影响管理员接收 Email；P1 且客户主动启用时可接收短信或 Webhook；普通维护使用状态页和可选提醒。默认值必须解释原因，并允许客户在权限范围内修改。
如何避免多渠道重复轰炸？
以事件 ID 和订阅者为键做合并，设定更新窗口与渠道优先级；同一状态变化只发送一次摘要，除非严重等级升级。所有渠道共享状态源和退订状态，避免一个渠道退订、另一个继续发送。
什么时候不应做自选渠道？
当事件分类、组件边界或送达遥测尚未可靠时，先做单一状态页加 Email。若客户规模小、事件影响低且没有集成需求，多渠道的运营成本可能超过价值，应先用公开状态页验证真实需求。