本篇要回答的问题：当线上服务已经稳定，业务还需要哪些"可支持性"建设？客户支持与BOSS 系统这两类持续运营工作，本质上要优化的成本是什么？
前几讲我们围绕 SRE、故障排查、过载保护把"保障 7x24 不间断服务"讲透了。本讲把视野从"服务稳定"扩展到"业务持续运营"：就算线上不出问题，用户仍会遇到麻烦，于是有了客户支持团队；而支撑业务正常运转还需要 BOSS 系统。核心立场是——产品被开发出来不是结束，从持续运营角度它只是开始。
客户支持：核心是降低人工成本
评估客户支持部门，很多公司盯着"服务满意度"，但许式伟认为最核心的关注点是 如何减少客户服务的人工成本。客户反馈大体分三类：
| 反馈类型 | 细分 | 应对思路 |
|---|---|---|
| 使用姿势类 | 完全不知道怎么用 | 产品内植入引导/向导/DEMO，代入客户场景预想问题 |
| 使用姿势类 | 接入后出现非预期结果 | 错误信息贴近用户语言，给出建议或文档链接 |
| 报障类 | 用户认为服务出问题 | 客户端+服务端全链路 Tracing，支持一键报障 |
| 投诉与建议类 | —— | 本讲不展开 |
关键判断：绝大部分客户问题应依靠产品自身来解决，而不是依靠产品文档来解决。文档应该有，但不是第一道防线。
误用要在"现场"就暴露：Go map 的例子
有些误用不在误用现场报错，而在别处才崩——很难排查。Go 语言团队的处理方式是范本：
| 常规做法 | Go 团队的做法 |
|---|---|
| 在文档里提醒"map 非多 goroutine 安全"，误用是用户自己的责任 | 在代码逻辑里主动检测并发误用，检测到直接抛异常停止运行，异常信息告诉你哪里错了 |
洞见：让用户更快找到错误根因，本身就是在降低运营成本——SRE 成本、客户支持成本、客户找问题的时间成本，都值得认真优化。
报障与事故宣布
报障依赖 request id + Tracing，且需延伸到客户端（携带 IP 与 Tracing 日志）。签署用户体验改进协议后，日志可主动同步，从而做全局性问题改进，而非逐个客户救火。
线上真故障时，报障会爆发式增长。什么时候宣布事故？ 设立明确条件，满足任一即应及时宣布：
| 宣布事故的条件 |
|---|
| 是否需要引入 SRE 之外的团队一起处理？ |
| 处理一小时后问题是否仍未解决？ |
| 事故是否正在大范围影响最终用户？ |
关键判断：先宣布事故、找到简单解法、再宣布结束，远好于拖几个小时才想起告知客户。事故流程不常用就会萎缩，靠角色扮演式演习（如演习其他地区处理过的问题）来保鲜，同时这套流程也适用于常规跨团队运维变更。
BOSS 系统：把高频业务动作固化进系统
BOSS 系统面向企业内部员工，支撑业务开通、财务与发票、业务管理等。准入策略很简单：越高频执行的业务动作，越应该被固化到系统中。
| 固化的好处 | 说明 |
|---|---|
| 业务效率提升 | 员工执行业务更便捷 |
| 安全风险管理 | 固化过程中加入风险检查，规避已知风险 |
| 业务数字化 | 行为被记录，为系统性优化提供可能 |
除客户支持、BOSS 系统外，还有"客户增长运营"这一极重要但复杂的话题，本讲不展开。
总结
本讲是一次"视野"的扩展：产品功能之外，要构建售前/售后的支持能力。无论是 SRE 的保障成本、客服的服务成本，还是客户自己找问题的时间成本，都应被认真优化；而支撑这一切的基础，是把用户行为写入日志系统，以便后续分析与挖掘。
先把"是什么"回答清楚
| 概念 | 一句话说明 |
|---|---|
| 客户支持 | 服务客户的团队，核心 KPI 是降低服务人工成本 |
| 一键报障 | 客户端携带 IP + Tracing 日志主动上报，快速定位 |
| 事故宣布 | 按明确条件及时对外宣布故障，比拖延后告知更好 |
| BOSS 系统 | 面向内部员工、把高频业务动作固化的支撑系统 |
| 数据运营体系 | 通过日志分析找到高频问题并持续改进（如七牛 Pandora） |
一句话速记
产品上线不是终点而是起点——把"用产品解决用户问题、用系统固化高频动作、用日志驱动全局改进"三件事做好，才算把业务的可支持性建起来了。
几条值得记住的判断
- 绝大部分客户问题应靠产品自身解决，而非文档。
- 误用要在现场就暴露（Go map 的范例），降低全链路排查成本。
- 事故宁可早宣布；流程靠演习保鲜。
- BOSS 系统准入原则：越高频越该固化。
思考题
回到你自己的产品：有没有哪类用户报错，目前只是写在文档里"提醒一下"，但其实可以像 Go map 那样在误用现场就主动检测并抛出清晰提示？把它挑出来，估算一下能省下多少客服与排查成本。
