程序员版《On Call 24 小时》
身为开发者的你,一定有过不止一次的 On Call 24 小时爆肝经历,随时待命,随叫随到……作者 |Henrik Warne译者 | 弯月责编 | 仲培艺出品 | C...
身为开发者的你,一定有过不止一次的 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 翻译,如需转载,请注明来源出处
热 文 推 荐
☞ 马化腾评 ofo 溃败原因;京东到家否认裁员;王兴质押全部摩拜股权 | 极客头条
☞ 这段 JavaScript 代码能挖出你所有的访问记录!
☞ 刚发布!Python 一二线城市月薪 15K 起!12 月再夺语言榜首
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 阅读更贴心!
![640?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/93c3a1e9f3ca014b1ba529bff5a5fc54.png)
更多推荐
所有评论(0)