On-Call 链接到标题 要说具体的 On-Call，早在 2016年还在负责运维工作的时候，就是 On-Call 的状态，那时候虽然没有明确的规定，但是做得事情就是 On-Call。在年会之后，公司正式宣布执行 On-Call，并且我在上周又重新体会了下 On-Call，感觉涉及到的东西可太多了。 售后服务 链接到标题 在一家做 2B 市场的公司，销售所售卖的，或者说客户所购买的，远远不仅是你的软件。如果单论软件，那么有无数的公司产品比你牛，销售比你多，研发比你强，又怎么争得过呢。我理解 2B 公司最大的卖点是服务：软件安装了，产品运行了，业务上线了，之后呢？无穷尽的服务，小到一项报警项，大到节点故障，都是靠着服务堆起来的。 怎么才能服务好呢？ 有一个良好的售后团队，或者说一个良好的售后体系支撑。因为我没有经历过太多的公司，只能就自己接触到的做 2B 公司的目前情况来说，没有见到那种让人眼前一亮的售后服务。 接触到的小公司售后团队（甚至一些国产2B 大厂）大多都是这么做的： 安装实施 定期巡检 故障处理 能做到上述 3 点尤其是第 2 点的并不多。我理解的 3 个阶段： 安装实施：了解客户环境，及时记录并沟通确定环境中不稳定的点，做好 PlanB，最终实施完成也要形成实施报告，无论是交付客户，还是公司内部之后的持续跟踪，都是只有好处没有坏处。 定期巡检：周期性与客户沟通进行巡检，很多客户在使用你的产品，其实他们是没有了解过多的使用上的内容的，毕竟产品说明书（使用文档）几百上千页，应该没有哪些真实用户会一点点的研究了解，大多只是出于使用上。那么这时就需要售后同学定期去进行巡检，帮助客户去发现问题，同时也是在教育用户去了解更多的产品细节。 故障处理：这里就涉及到今天聊得主题，当线上环境出现问题，怎么做？如何做？我理解的故障处理，无论 Bug 多难复现，无论操作多苛刻，都要第一时间恢复线上业务，如果业务不能恢复，其他一切免谈。 为什么 On-Call？ 链接到标题 在我上述提到的 3 点中，1、2通常是由售后同学来完成，最重要的第 3 点通常是由研发同学修复。 在售后同学，遇到了线上故障： 如何去了解这个故障的影响范围？ 如何准确全面的去提供这个故障相关信息？ 如何第一时间找到功能模块负责的相应研发同事？ … 上述问题在工作中经常遇到，在产品没有完全成熟前，需要售后同学对产品了解不仅限于使用，而需要更多的去了解产品内容，产品通过何种方式提供这个功能。 当然，在一个小公司中，我们无法要求更多，我们需要做的是，第一时间修复问题，恢复业务，于是有了 On-Call。 如何 On-Call？ 链接到标题 轮值表：On-Call 的要求其实是一个售后岗位的基本职责，只是对于研发同学来说可能略微难过，7 * 24 小时 * 365 响应。具体落实下来就可能是以 7 * 24 为周期的轮值。这期间可能有很多要求，比如多久要接通电话，多久要接入远程等等。