这可能是一篇非常小众的知识帖：如何应对7/24 oncall

之前的晒货文章

有说过，后端程序员多数避免不了的就是oncall，好一些的可能是一周5天，朝九晚五这种，坏一点的，比如我们，就会是7/24，半夜被alert Page起来，甭管是不是false alert，真的不要太正常…

之所以想写一下这篇，是因为我这周oncall的体验实在太差了，感觉自己每时每刻都在被Page，光今天一天就处理了3个大incident，虽然最终证明都不是自己组的锅，但是root cause的过程真的非常熬人，从大清早（8点）从床上被Page起来，没刷牙洗脸喝水上厕所吃早餐，就一直坐在电脑前不间断开会root cause到中午12点半，去了我半条命，结果晚上9点多又来了第三个，真的弄得我快怀疑人生了💔

oncall可能都不会太轻松，尤其是如果你的service是那种牵一发而动全身的部分，那么几乎半数的incident可能都能和你们组扯上关系，这时候，如何尽可能高效oncall就很关键了

💉💉💉💉💉

首先来说说false alerts

这一类是最好处理的，只要保证你能观测的所有metrics都在正常范围，并且并没有收到来自upstream或者downstream的相关消息，基本可以直接忽略

之后要做的就是如何调整threshold以减少false alerts

💉💉💉💉💉

一般alerts

大多数的真实alerts都来自bad deployment，如果是自己的service刚好deploy了，那么第一个考虑的就是roll back

如果不是，那么可能要看看是不是downstream/upstream的deploy造成的，可以联系相关的组协同解决

💉💉💉💉💉

incident

这一类基本是影响比较大的outage，可能源于第三方的service，也可能是bad deployment，甚至可能是某些操作失误、fraud，原因千变万化，往往root cause比较麻烦，需要多组合作，这个时候，如果自己没办法handle，千万不要硬扛，毕竟快速解决outage才是第一要务，所以一定要快速地联系所有你能想到的可能可以提供帮助的人，不要害怕给别人造成麻烦或者是联系错了人，在大的outage面前，如何尽快mitigate才是第一要务

✔️✔️✔️✔️✔️

上面大致说了一些应对不同级别的outage该如何应对，那么这里再说说如何做好oncall

🍒快速响应很重要

🍒解决不了的任何alert，哪怕是小的false alert，也要立刻提出来，让熟悉这一方面的人员快速介入，同时，你需要做的是记好笔记，这样下次再遇到的时候自己就知道如何处理了

🍒脸皮要厚，该抱大腿不要犹豫。这一条和上一条类似，毕竟oncall的首要任务就是快速mitigate outage，所以在发现自己无能为力的时候，一定要快速找更有经验的人寻求帮助。对于自己，这也是一个学习的过程，只要在寻求帮助的过程用心记录和学习，慢慢你自己也能变成大腿啦~

🍒提升oncall体验的办法之一就是提高代码质量，增加unit test/integration test/end to end test，减少bad deployment，提升oncall体验，从我做起~

好了，先说这么多吧，虽然这篇科普可能很小众，但还是希望能给需要的朋友一些帮助~