On-Call 链接到标题

要说具体的 On-Call，早在 2016年还在负责运维工作的时候，就是 On-Call 的状态，那时候虽然没有明确的规定，但是做得事情就是 On-Call。在年会之后，公司正式宣布执行 On-Call，并且我在上周又重新体会了下 On-Call，感觉涉及到的东西可太多了。

售后服务 链接到标题

在一家做 2B 市场的公司，销售所售卖的，或者说客户所购买的，远远不仅是你的软件。如果单论软件，那么有无数的公司产品比你牛，销售比你多，研发比你强，又怎么争得过呢。我理解 2B 公司最大的卖点是服务：软件安装了，产品运行了，业务上线了，之后呢？无穷尽的服务，小到一项报警项，大到节点故障，都是靠着服务堆起来的。

怎么才能服务好呢？ 有一个良好的售后团队，或者说一个良好的售后体系支撑。因为我没有经历过太多的公司，只能就自己接触到的做 2B 公司的目前情况来说，没有见到那种让人眼前一亮的售后服务。

接触到的小公司售后团队（甚至一些国产2B 大厂）大多都是这么做的：

  1. 安装实施
  2. 定期巡检
  3. 故障处理

能做到上述 3 点尤其是第 2 点的并不多。我理解的 3 个阶段：
安装实施：了解客户环境，及时记录并沟通确定环境中不稳定的点，做好 PlanB，最终实施完成也要形成实施报告，无论是交付客户，还是公司内部之后的持续跟踪，都是只有好处没有坏处。

定期巡检：周期性与客户沟通进行巡检，很多客户在使用你的产品，其实他们是没有了解过多的使用上的内容的，毕竟产品说明书（使用文档）几百上千页，应该没有哪些真实用户会一点点的研究了解，大多只是出于使用上。那么这时就需要售后同学定期去进行巡检，帮助客户去发现问题，同时也是在教育用户去了解更多的产品细节。

故障处理：这里就涉及到今天聊得主题，当线上环境出现问题，怎么做？如何做？我理解的故障处理，无论 Bug 多难复现，无论操作多苛刻，都要第一时间恢复线上业务，如果业务不能恢复，其他一切免谈。

为什么 On-Call？ 链接到标题

在我上述提到的 3 点中，1、2通常是由售后同学来完成，最重要的第 3 点通常是由研发同学修复。

在售后同学，遇到了线上故障：

  • 如何去了解这个故障的影响范围？
  • 如何准确全面的去提供这个故障相关信息？
  • 如何第一时间找到功能模块负责的相应研发同事？
  • …

上述问题在工作中经常遇到，在产品没有完全成熟前，需要售后同学对产品了解不仅限于使用，而需要更多的去了解产品内容，产品通过何种方式提供这个功能。

当然，在一个小公司中，我们无法要求更多，我们需要做的是，第一时间修复问题，恢复业务，于是有了 On-Call。

如何 On-Call？ 链接到标题

轮值表：On-Call 的要求其实是一个售后岗位的基本职责，只是对于研发同学来说可能略微难过，7 * 24 小时 * 365 响应。具体落实下来就可能是以 7 * 24 为周期的轮值。这期间可能有很多要求，比如多久要接通电话，多久要接入远程等等。

故障时间线：可能一次故障设计到了多个功能模块的同学，那么我们要根据这个事故，编写文档，记录详细的时间线（当然我们现在做的并不好），至少可以让我们再进行任务交接时，了解到这个任务目前的状态，不至于一脸懵逼。永远保持这个事情处于跟踪状态。永远。哪怕是定了闹钟去提醒自己。

事故报告：之前没觉得事故报告的编写需要花费很多的时间，这周明显当头一棒，要想写好一份报告，大部分情况下需要花费的时间精力远远要比这次事故的解决方式多得多。这份报告不仅交付给客户，还能让我们针对后续的产品开发设计上避免踩坑。

后续工作：在恢复线上业务之后，我们针对该问题进行修复，无论是代码修复，还是文档修复，都需要多次验证，保证自己的代码是健全的（当然我往往考虑不周。。。）。

个人感受 链接到标题

在上周 On-Call 过程中，占用的时间远远超出预期，整整 2人天的时间。整个人精神紧绷，因为 On-Call 的事情永远是优先级最高的事情，你随时都面临着工作内容被打断的状态，也可能因为太久没有经历这种状态，导致我在 On-Call 期间本职工作的工作进度，工作效率都不能让自己满意，很多时候需要远离工位，进行彻底的放松，才能继续下去。
同时也让自己更多的注意代码内容，用更多的时间保证自己代码的稳定性是值得的，无论是对自己，还是对于其他同事都是一种负责的体现。

人，才是最大的 Bug。

参考链接 链接到标题