去年接手一个上线小十年的系统，由于这个系统是出于上下游的中间环节（意味着会跟几乎所有系统打交道），并且存在着大量的历史包袱（意味着很多黑盒，一些奇怪的用法以及机制），导致这个系统的日常工作最为繁重。
我们面向的用户是所有的系统开发者，问题涉及各类调用问题，白名单，权限审批，机制，线上问题排查等等，其中很大一部分需要有实时反馈，这就意味着日常工作中的打断非常多，进而导致团队的效率下降，以及整体产出变少。
对此，经过近一年的优化和改进，我们已经成功地将打断减少了 90% 以上，并且确保服务质量。
以下分享一些过程中的经验
打断所有人都需要真切感受到被打断、拉群
跟吃自己的狗粮类似，所有人参与到轮值中，就能覆盖到各类咨询问题的方方面面。
轮值的助手需要记录：
有记录，才有统计，有统计，才能更高效直接地解决问题
我们的项目轮值经过 2 个月左右，基本已经清楚地知道所有打断的来源
分析所有的记录，将相同的问题汇聚计数，得到一张表格
分类：
二八定律，先处理 20% 的核心问题，解决掉 80% 的打断
我们发现，虽然这个系统已经存在了小十年，但是并没有太多的文档，并且文档非最新、含糊不清。
大量的咨询原因是没有文档，或者文档看不懂， 所以我们决定重新构建文档体系，替代掉原先的文档站点。
注意：
之前有参考一些最佳实践，文档体系由 4 个部分组成
而具体划分，可能还会涉及
这样，文档就成了一张网，用户不管从什么页面进去，都能够找到相关的概念、背景、用法、DEMO、FAQ， 足够清晰就将用户可能的问题全部在这个阶段解决掉。
并且，在面对咨询的时候，可以通过直接扔文档链接的方式解决，无须废话。
目前大模型已经足够聪明，能够辅助解决问题，所以我们将整个文档站点喂给了大模型，问题咨询的时候直接拉机器人进群，用户发问题的时候机器人协助解答，也拦截了很大一部分问题。
对于操作类，我们首先评估合理性，是否有存在的必要？
例如，有一个加调用方 IP 白名单的操作类，每一个调用方都需要找过来加白，而原先的老系统也做了一个快速加白的入口，用户找过来申请加白-打开系统-完成加白，这似乎没毛病，也存在了很多年一直是这么做的。
但是这样做有意义吗？ 无脑加白=没有白名单限制，后来才发现，是 N 年前的安全团队扫描推动加的，但是其实已经不需要了，形同虚设。后来直接给内网网段加白，废弃掉这个流程
同样，还有一些接口权限申请，最早可能有用，但是随着时间流逝，有些权限审批变得不再必要，所以系统上改变，非敏感的不需要审批直接通过，敏感的走自动审批流审批，而不是集中在系统开发这里进行人工审批
能自动化的绝不手工做，能别人做的绝不自己做
有一些操作是有其存在的合理性的，但是这类操作的操作链路特别长，涉及多套系统。
我们其实是有职能类的人工助手的，但是在这个阶段他们没法做任何协助。
后来我们做了一套系统（3 人、一周），将高频的十个操作整合在一起，配合权限控制、审计，然后将这类操作直接分派给了职能化助手。
这套系统直接在前置步骤拦截了几乎所有的操作类问题， 3 人一周的成本非常划算
我们发现有几个高频操作是其他系统带来的，他们在文档上直接指引使用者，找到我们系统的开发做一些操作、配置。
实际上这样给我们带来了非常大的工作量，以及困扰。
所以我们最终：
然后反向推这些系统的维护者改文档说明和入口，直接让用户自助解决问题。
咨询中很大一部分是接口调用后的返回问题
我们直接在文档中，将所有报错返回进行枚举，并将每种报错的可能原因，排查方式明确，直接让用户通过关键字搜索就能自行排查问题
另外咨询中一部分是关于一些系统的限制配置，我们直接将代码中各类限制放到了文档中。
我们发现，总是有一个问题：用户无法识别是自己的问题还是我们系统的问题，所以总是发起咨询。
后来我们将这个做成一个专题，并且置顶，放入用户排查问题的必经链路中。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。