之前的晒货文章
有说过，后端程序员多数避免不了的就是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体验，从我做起~
好了，先说这么多吧，虽然这篇科普可能很小众，但还是希望能给需要的朋友一些帮助~
最新评论 4
:感觉和我同学做医生晚上120值班差不多
:还真是！不过我们这种是心累+身体累，医生的责任感和压力会更大~
:oncall疯狂的时候是真的受不住。非常实用的科普贴了哈哈![[赞]](/assets/emoji/comment-emoji/dm_zan@2x.png?v=1)
:谢谢亲爱的![[飞吻]](/assets/emoji/comment-emoji/dm_feiwen@2x.png?v=1)
这周真的快哭了，Page基本没停过![[裂开]](/assets/emoji/comment-emoji/dm_liekai@2x.png?v=1)
所以想着要不写一下oncall相关，希望给和我一样被oncall折腾得怀疑人生的兄弟姐妹们一点点小帮助