54 | 业务的可支持性与持续运营

客户支持

线上无问题不代表客户无问题，大部分公司会成立客服支持部门

对于客户支持部门，我们如何评估他们的业务价值？

一般来说是通过客户满意度 但不是重点
重点是如何减少人工成本

问题反馈的分类：

• 使用姿势类
  • 小白，需要一步步引导如何使用
  • 接入产品，但发生了非预期的结果，客户感到迷茫，需要帮助
    • 出错的信息非常关键，出错很难理解会导致与用户去查文档，一旦无法解决，客户会觉得产品不行，转而投向其他的产品
    • 我们有必要将错误的信息表述的能够贴近自然语义
  • 产品中植入必要的引导是非常重要的
    • 带入客户的使用场景，预见可能的问题
    • 历史行为分析也可以帮助寻找关键问题是什么
  • 问题应该是产品来解决，而不是依靠文档来解决
• 报障类
  • 用户认为服务出问题了
    • 用户自身环境
    • 服务真的出问题了
    • 但是一定要给用户一个明确的问题说明和建议方案
    • 有了 Tracing 机制，客户端基本上就可以做到一键报障。在报障时客户端会携带自己的 IP 和 Tracing 日志
    • 需要建立一个合适数据运营体系，要迅速找到用户经常遇到什么问题，并加以改进
• 投诉与建议类

go语言中的map不是多线程安全的，go语言实际上是多goroutine安全的，但是如果仅仅在文档中有提示，那么会给用户带来很多困扰。
go语言团队的做法是，针对上述使用姿势不正确直接抛出异常，并且让程序停止，并且在异常信息中告诉你，你的代码出现了什么问题

当线上发生故障的时候，什么时候对外宣布事故，什么时候主动通知客户？

1. 先宣布事故发生，随后找到一个简单解决方案，然后宣布事故结束，要比在问题已经持续几个小时之后才想起告知客户要更好。
2. 满足以下条件任何一条即可宣布：
   • 是否需要引入 SRE 之外的团队来一起处理问题？
   • 在处理了一小时后，这个问题是否依然没有得到解决
   • 这次事故是否正在大范围地影响了最终用户？

怎么才能使工程师不忘记他们的流程管理的技能呢？

一个可能的思路是，经常针对之前发生过的灾难进行角色扮演式的演习，比如演习另外一个地区处理过的问题，以更好地熟悉事故流程管理体系。
当然，事故流程管理框架其实也往往适用于其他的跨团队的常规运维变更过程

BOSS 系统

客户使用上的困扰、排错、事故告知、投诉与建议，这些是客户支持所面临的常规工作

还有更常规的业务支持工作要做，比如客户的业务开通、财务与发票、业务管理等。这类系统我们往往把它叫 BOSS 系统。

什么样的事务，应该被加入到 BOSS 系统

基本的策略是越高频执行的业务动作，越应该被固化到系统中
业务固化的好处：

1. 业务效率提升，员工执行业务有更高的便捷性
2. 安全风险管理 通过固化业务过程，进行必要的风险检查，可以避免掉最常见的已知风险。
3. 业务过程进一步被数字化，业务行为被记录，这为系统性地进行业务优化提供了可能。

客户增长运营