一个SRE的平常

本文主要介绍了SRE的平常工做及存在的各方面问题。
上篇文章回顾: TiDB应用实践

1.平常巡检发现新扩容的一台web转发服务器负载异常。比原来的稍高仍然在正常范围内，but做为一个SRE是不能放过任何异常。

2.安排好其余平常工做开始排查。

(1)新增服务器系统版本跟原来不一致。（原来为centos6.x，异常服务器为centos7.x） ，异常服务器从lvs下线重装，保证系统版本都为6.x依然没有恢复。（论：保持环境统一重要性。）
为何要从新装centos6.x呢？当时怀疑线上nginx是在centos6.x环境下编译的，运行在centos7.x下面，可能会是这个缘由。

(2)仔细对比下环境，确认系统版本nginx版本nginx配置彻底同样。

3.经过火焰图分析大部分cpu占用为https握手阶段函数（bn_sqr8x_interna，mul4x_internall），查看log发现问题服务器及正常服务器https及http请求数量相同。（此路不通。）

4.既然软件环境同样来看硬件及驱动。经过监控肯定新增一批服务负载都比原来的稍高,新增服务器及原来服务器从cpu，内存硬盘配置同样。肯定新增服务器没有节能没开，cpu内存频率正常硬盘读写正常,找系统同事查看未见硬件故障。部分驱动版本信息不一样，进行了替换验证，整个过程是痛苦的，感谢系统及dell同窗。（你们一个team一块儿背锅）

5.经过找不一样没有解决问题了。可是咱们仍是要继续，如今咱们很好奇很想知道答案。继续分析咱们发现了问题服务器cpu很不均衡。为何不均衡了，strace一下发现大量的(Resourcetemporarilyunavailable)cpu在空转。

来看下nginx对请求分配的模型。master进程监听端口号（例如80），全部的nginx worker进程开始用epoll_wait来处理新事件（linux下），若是不加任何保护，一个新链接来临时，会有多个worker进程在epoll_wait后被唤醒而后只有一个线程处理这个请求其余的则会失败。cpu空转负载升高。这就是所谓epoll_wait惊群效应。固然nginx会有办法处理这个问题：加锁。

6.剩下的就简单了。对问题服务器手动配置上锁（accept_mutex），而后负载正常了（每把锁都是双刃剑，加不加要具体问题具体分析）。可是，你可能会有疑问版本是同样的啊，正常的服务器也没手动加锁啊。伟大福尔摩斯说过：When you have eliminated the impossibles,whatever remains,however improbable,must be the truth真相就是线上nginx根本不是一个版本（一脸懵逼）。手动查看下线上运行的nginx文件被删除了，线上运行了一个不存在的版本，存在的版本是更新了的。原来正常的而服务器上线是reload新版nginx不会生效，新增的服务器是start运行的是新版nginx。

7.下面的问题就是tengine2.1跟tengine2.2accept_mutex参数由默认的on改成了off为何要改呢。与时俱进。当初这个参数是为了不在epoll_wait所出现惊群效应。能够参考（https://www.jianshu.com/p/21c3e5b99f4a）新版内核已经有了处理这个方法再也不须要nginx单独配置。

总结：反思并完善整个运维流程，以免相关问题再次发生，对SRE来讲永远是最重要的。
一些启示：

(1)线上环境尽可能彻底一致（容器化能够很好的解决这一点）；

(2)每次变动都要谨慎及测试

本文首发于公众号”小米运维“，点击查看原文。