文章的翻译是专门为课程的学生准备的 .
Intercom 的使命是个性化在线业务。 但当产品不起作用时，你就无法对其进行个性化。 。 性能对于我们业务的成功至关重要，不仅因为我们的客户付钱给我们，还因为我们自己使用 。 如果我们的服务不起作用，我们确实能感受到客户的痛苦。
能否顺利运行取决于很多因素，例如软件架构和日常工作质量。 然而，通常情况下，这一切都归结于这样一个事实：始终保持联系的人接听电话 。 这种技术支持可以成为一种以客户为中心的强大工具，它将工程师的帮助与客户在购买您的产品时获得的帮助结合起来。 这也是一个学习和成长的绝佳机会，因为毕竟失败和错误可以成为练习技能和理解复杂工作机制的好机会。
在工作时间之外“一直在线”会对您的生活产生不利影响。
但与此同时，“永远在线”可能会对您的生活产生不利影响。 您必须准备好快速、有效地响应出现问题的警报。 即使您在任何特定时刻都没有被寻呼，“永远在线”也会产生焦虑，正如我从个人经验中了解到的那样。 因此，睡眠质量尤其严重恶化。 一天中任何时间经常处于访问区域可能会导致倦怠、冷漠，或者一般来说，希望再也见不到计算机。
Intercom 中“始终连接”状态的历史
在 Intercom 的早期阶段，我们的技术总监 Ciaran 单枪匹马地为整个团队提供了办公室内外的 XNUMX/XNUMX 技术支持。 随着 Intercom 的发展，成立了一个特别工作组来帮助 Ciaran。 不久之后，新的开发团队开始创建许多新功能和服务，并接管了所有技术支持职责。
在任何特定时刻，都有太多的人“待命”。
当时，这种方法似乎是理所当然的，因为这是一种立即扩展我们的技术支持团队的简单方法，它符合我们的价值观，并且适合我们的需求。 。 最后，在没有任何计划的情况下，我们只剩下四五个团队在非工作时间定期联系客户。 其余的开发团队并没有遇到太多可能引发错误的复杂问题，因此他们很少（如果有的话）被调用。
我们意识到我们所处的情况是我们无法引以为豪的技术支持机制，以及我们想要解决的一些关键问题，例如：
- 在任何特定时间都有太多人准备好接受挑战。 我们的基础设施不够大，不足以需要至少五名开发工程师在没有定期休息日的情况下工作。
- 我们的警报和呼叫程序的质量在各个团队中并不一致，我们使用临时流程来审查新的和现有的问题警报。 操作手册中的说明（在收到问题通知时应遵循的说明）大多因缺失而引人注目。
- 根据工程师所在的团队，他们的期望是相互冲突的。 例如，只有第一个技术支持团队才能获得随叫随到的轮班和周末中断的补偿。
- 对于在非正常时间拨打不必要的电话似乎存在普遍的容忍度。
- 最后，这种工作并不适合所有人。 生活环境有时表明，职责轮班对人们并没有产生最好的影响。
找到正确的“始终开启”状态
我们决定创建一个新的虚拟团队，在非工作时间为每个团队执行技术支持工作。 该团队将由志愿者组成，而不是组织中任何团队的应征入伍者。 虚拟团队的工程师大约每六个月轮换一次，花费数周的时间“随叫随到”。 幸运的是，我们毫无问题地找到了足够的志愿者来组建虚拟团队。
结果，我们的支持团队从 30 人减少到只有 6 或 7 人。
然后，团队商定并定义了运行手册中的问题警报和描述应是什么样子，并描述了将警报转发给新支持团队的流程。 他们使用 Terraform 模块定义了代码中的所有警报，并开始对每个更改进行同行评审。 我们推出了让值班人员非常满意的周班补偿水平。 我们还创建了一个仅由经理组成的二级升级团队。 该团队应该是技术支持工程师的单点升级。
我们经过几个月的努力，建立了这个流程，现在待命的工程师不再是以前的30人，而是只有6、7人。服务，这是通常发生故障最多的时间，但在所有其他时间，技术支持都是由志愿者提供的。
我们学到了什么
在我们启动虚拟技术支持团队后，我们预计会有大量新任务涌入，例如调查问题的原因或聚集在一起解决导致中断的单个问题。 然而，我们的开发团队对导致失败的因素承担全部责任，任何后续响应通常都是立即的。 我们还需要避免出现技术咨询任务被发回原来团队的情况，以免迫使工程师在下班后联系。
下班后的电话数量已降至每月不到 10 个。
我们的升级流程很少被正式使用。 更普遍的看法是，工程师得到了当前在线团队的非正式帮助，尤其是我们旧金山办公室的人员。 通过团队合作和即时解决，许多问题被消除或减少。
我们旧金山办事处的工程师全职加入团队，提供超出典型的技术支持。 我们面临一些管理费用，但将我们的支持团队成员分散到多个办事处对我们有利，因为事实证明，这是建立、加强关系并更多地了解我们所使用的技术堆栈的好方法。
对讲开发人员的工作在我们的团队中变得更加一致，我们可以自信地谈论成为我们网站上的系统工程师的好处 ，表示除非您愿意，否则无需始终保持连接。
除了稳定和扩展数据存储的基础工作外，持续关注问题解决已使非工作时间呼叫数量降至每月不到 10 个。 我们对这个数字感到非常自豪。
我们将继续致力于维护和改进我们的技术支持团队，随着 Intercom 的发展，我们可能必须重新考虑我们的决定，因为今天有效的方法不一定在下次我们的员工翻倍时有效。 然而，这种经历对我们的组织来说非常积极，极大地提高了我们开发工程师的生活质量、我们对呼叫的响应质量，以及最重要的是，我们的客户体验。
来源： habr.com