程序员版《On Call 24 小时》

身为开发者的你，一定有过不止一次的 On Call 24 小时爆肝经历，随时待命，随叫随到……

作者 | Henrik Warne
译者 | 弯月
责编 | 仲培艺
出品 | CSDN（ID：CSDNnews）

我现在正在做的系统需要我每七周中有一周要做到“随时待命”。在过去十年的大部分时间里，我都需要为我开发的系统轮流当值。我认为随叫随到是工作的职责所在，同时我们也可以从中学到很多东西。但很显然，这种工作模式所带来的压力也是不容小觑，也未免会有诸多不便，所以我们理应得到与付出相应的报酬。

为什么开发人员应该「随叫随到」

许多系统需要全天候在线，所以必须有人随时准备好提供支持，而该系统的开发人员则无疑是提供相关支持的不二人选。

共同进退

作为开发人员，你应该对你的代码负责，这意味着不仅需要编写代码，还要测试代码，确保它能够完成预期的工作，即使在产品环境中也不会出问题。当你清楚出了问题的代价将是大半夜爬起来工作，那么写代码和做测试的时候就会更加小心谨慎。Nassim Nicholas Taleb 在其著作《反脆弱》（Antifragile）中曾提到罗马工程师会在他们建造的桥梁下住一段时间，以确保他们的工作做得更好。

全盘考虑

在对系统进行故障排查的时候，你可以充分理解其工作原理。如果你不提供支持，那么最终很可能导致你非常了解某些部分，但是却不清楚系统的整体情况，比如所有的部分如何连接在一起以及如何交互。此外，提供支持也可以让你直接了解客户使用系统的方法。

推动改进

在修复系统问题的时候，你可以清楚地看到日志记录或故障排除工作是否不尽如人意。作为系统的开发人员，你可以在遇到这些问题的时候立即解决。你可以通过添加更多相关信息来改善日志记录，也可以删除造成日志阻塞的语句。你可以编写脚本和其他有助于故障排除和恢复系统的工具。你还可以删除错误的警告——日积月累，最终这样的小改进可以建立更好更有弹性的系统。

警报

电话与警报

在 TriOptima，我们有一个紧急号码，如果系统出现问题，可以拨打该号码，呼叫后会转给开发人员。随着时间的推移，我们还增加了很多监控，例如异常抛出、队列长度以及内存、CPU和磁盘利用率。这些监控会生成警报，然后即时反馈给开发者。那段时间里，我们几乎从未在半夜被电话吵醒，因为在大多数客户发现问题之前，我们就从监控中获得了警报。

心跳作业（Heartbeat jobs）

我们在两个主要的交互系统上按周期运行心跳作业（每一分钟和每五分钟）。如果未按预期执行，就会引发警报。事实证明这非常有用，因为这些作业常常会捕捉到一系列的问题。例如，最近给我们发送数据的服务器线程耗尽，其中一个反馈表现就是我们的心跳作业没有运行，因此我们得到了警报。有时，我们还可以通过心跳作业捕捉到连接问题。在《Release It!》这本书中，作者 Michael T. Nygard 称这些为合成事务（synthetic transaction）。

轻松回滚

在工作中，功能开发好后，我们需要部署新功能并修复 bug。这意味着全天都有许多小型部署。如果半夜因为出现问题而被叫醒，那么通常的解决方案就是回滚到最近的一次部署。感谢 Kubernetes，我们可以轻松快捷地完成回滚。然而，有些改动比如数据库迁移等可能很难回滚，但既然我们已经清楚认识到这一点，而且我们需要承担其中的责任，我们自然会想办法在编写代码时注意令其更方便回滚。我们还会在早间进行高风险部署，这样就可以有一整天的时间来监控系统了。

改善警报

我们不断地调整警报，使其更准确，同时也清除了误报。一个例子是队列长度的警报。刚开始我们设置的警报是，如果过去10分钟内的平均长度超过阈值，那么就会发出警报。但是，在修复了这类问题后，队列长度警报会一直响，直到平均值低于阈值。如果不立即清除警报，那么可能会掩盖新出现的问题。所以我们将其更改为在达到阈值时立即报警，并在队列长度降至零时立即将其清除。这样一来这个特定的警报就更加准确和敏感了。前不久，我刚刚调整了另一个警报：一些同步的问题可以等到正常办公时间再进行，这样就不会在大半夜吵醒别人了。

报酬与时间计划

加班费

随叫随到的人理应获得额外的报酬——如果说必须准备好在一周内的任何时间随时到位并解决问题，这对个人的生活影响很大，所以额外的报酬会是个必要条件。我认为最好的情况是，你可以拿到固定的 “On Call” 加班费，而且无论是否有意外发生，每次你半夜出勤都可以获得报酬。同时也可以进行相应的调休。

时间计划

在我值班的时候，通常是一周被叫一次。我认为这个时间间隔度很好。最好提前制定时间计划（提前几个月）。这样你就可以更好地规划生活中的其他活动。能够与团队中的其他开发人员换班也非常好，我们很难说理想的换岗时间是多长。很多时候，值夜班就无法过正常的生活，如果时间间隔太长，那么可能会得不到足够的练习，技艺生疏。每隔 7-8 个星期对我来说是相对合理的间隔选择。

危机升级

一旦危机真正出现，我们随时都应为危机进一步升级做好准备。如果整个系统都停止了工作，而且你在解决问题方面没有取得任何进展，那么就需要更多的帮助。通常情况下，下一步你应该通知经理，他们会找其他人来帮忙。同时我也告诉我的同事，我不介意被吵醒，即使我不值夜班，如果需要我帮忙的话也可以给我打电话。在过去十年中，我只接到过几次电话，但如果事先知道在必要情况下还可以求助队友，那么随时待命带来的心理压力也会小很多。

入职培训

团队中的新成员需要时间来了解系统，并在加入轮岗之前练习故障排除。入职培训过后，我们将与新成员两两结对，共同承担为期一周的随时待命工作，然后再让他们单独操作。

总结

尽管随时待命可能会带来很大压力，但是我认为这种工作也有很多好处。随叫随到意味着对你开发的东西负责，在此过程中，你可以了解系统的工作原理（或故障的原因），还可以利用其间的反馈来改进系统。但是，团队成员之间需要分担随叫随到的重任，而且你理应获得相应的报酬。

原文：https://henrikwarne.com/2018/12/03/developer-on-call/

作者：Henrik Warne，瑞典斯德哥尔摩人，TriOptima的软件开发。

本文为 CSDN 翻译，如需转载，请注明来源出处

 热 文 推 荐 

print_r('点个赞吧！');
var_dump('点个赞吧！');
NSLog(@"点个赞吧！");
System.out.println("点个赞吧！");
console.log("点个赞吧！");
print("点个赞吧！");
printf("点个赞吧！\n");
cout << "点个赞吧！" << endl;
Console.WriteLine("点个赞吧！");
fmt.Println("点个赞吧！");
Response.Write("点个赞吧！");
alert("点个赞吧！")
echo "点个赞吧！"

点击“阅读原文”，打开 CSDN App 阅读更贴心！