一個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)每次變動都要謹慎及測試

本文首發於公衆號」小米運維「，點擊查看原文。