记一次oncall演练

导语

”智者千虑，必有一失；愚者千虑，必有一得“。

处于云计算时代，云原生软件是高度分布式的，必须在一个不断变化的环境中运行，而且自身也在不断地发生变化。云环境下我们的软件面向可预测的故障设计，但是面对双重变化，我们可能也是力有不逮的愚者。

面对如此的复杂性，为了保障服务的稳定性，oncall是一项不可或缺的机制。每个公司都会制定自己的oncall应急标准和流程，什么”一分钟发现五分钟解决十分钟恢复“不一而足。规范和流程的根本目的是为了提升我们处理故障的效率，尽快恢复，减少对用户的影响和损失。但是光有规范和流程，没有足够的熟练度，处理起来也不会得心应手吧，就像卖油翁滴油不漏，亦是”我亦无他，唯手练尔“。不定期的演练成了提升oncall技能的一种行之有效的手段。

演练

周六，天微雨，寒风料峭。正在理发店理发拯救发际线的我，突然收到来自工作软件上的语音，周末又正好有事，这个时候我是拒绝的。但奈何这兄弟没有眼力劲儿很负责任的夺命连环call，一打开工作软件就弹出下图：

redis sync data erro这是个定时任务同步故障，我又不在电脑前，就让oncall值班同学看下预案文档，被告知的开发同学写的是redis故障找xxx同学，一想这确实是不是办法的办法锅先都甩到中间件去。 看似是redis的故障，然后我让oncall同学帮我看redis监控发现查询数增加，查询耗时变长

发现tedis代理监控发现是代理的cpu被限制资源不够了，为什么会cpu使用超标了，监控上显示redis的exists命令被大量执行，看应用的监控面板发现一个接口突然有激增流量访问 我们联想到这个接口中可能使用exists作为判断条件每次访问均会执行此操作，从熟悉这里逻辑的同学得到确认，我们随后对接口进行限流，然后对tedis代理进行垂直扩容，随后故障恢复。整个处理过程还是比较顺畅的。

总结

告警和故障很烦，当在应用开发设置的指标和告警阈值不合理时，真的是麻烦缠身，从来没觉得自己这么重要过，不停的认领告警和处理，这应该就是被打扰的感觉。合理的告警太重要了，但是如何营造这种环境应该是一个不断实践和优化的过程持久战。 大多故障的发生都是有先兆性的，比如流量的突增，集群网络波动等。 更清晰的告警上下文形如xxx execute error because of xxxx原因，有助于定位故障原因，模糊的告警可能只有看代码才能发现到底干什么因为什么出错，对于不是项目维护或者开发人员来说简直就是灾难，你面临的可能是一大堆问题代码权限，容器权限等等。所以当不熟练的同学来处理问题时，可能更偏爱依赖一份靠谱的处理预案。故障溯源更依赖于完善的监控以及日志按规范接监控按最佳实践记录日志。 系统核心链路是系统故障高发区常使用故障自然容易发现，针对核心链路常做蓝绿攻防巡检以及稳定性跟踪，及早发现系统隐患，防患于未然。 云原生时代，面向可预测的故障设计，针对资源的场景，是否可以有更灵活的自动扩缩容策略自动基于使用量做垂直扩容，以及可定制化的冗余策略基于流量分布规律做闲时忙时的节点数控制。