【稿件】當(dāng)下，IT 運(yùn)維成為企業(yè)的核心競爭力，從過去人肉保障的階段，一直到現(xiàn)在引入 AI 和各種計算的方式來實(shí)現(xiàn)穩(wěn)定性。在進(jìn)階的過程中，如何評價運(yùn)維的質(zhì)量，是擺在運(yùn)維人員和服務(wù)對象/業(yè)務(wù)方之間的難題。

站在用戶的角度思考問題，與客戶深入溝通，找到臨邑網(wǎng)站設(shè)計與臨邑網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗(yàn)，讓設(shè)計與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗(yàn)好的作品，建站類型包括：網(wǎng)站制作、成都網(wǎng)站制作、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、域名申請、網(wǎng)頁空間、企業(yè)郵箱。業(yè)務(wù)覆蓋臨邑地區(qū)。

在由 主辦的第十四期“Tech Neo”技術(shù)沙龍活動中，搜狗 SRE 負(fù)責(zé)人黃昕老師以此難題為開端，逐步深入展開，講解具體實(shí)現(xiàn)細(xì)節(jié)。分享主線以時間為序：從建立、實(shí)現(xiàn) SLO，到預(yù)警的提出和成熟、預(yù)警系統(tǒng)的布設(shè)，再到運(yùn)維準(zhǔn)入門檻的提出、故障的自動恢復(fù)。

如何建立 SLO

SLO 即服務(wù)水平目標(biāo)，通過建立運(yùn)維 SLO，如穩(wěn)定性目標(biāo)、服務(wù)時長等，實(shí)現(xiàn)用數(shù)據(jù)的方式合理評價運(yùn)維工作效率。

十年前，沒有各種監(jiān)控系統(tǒng)，要以純?nèi)巳獾姆绞?，來?shí)現(xiàn)穩(wěn)定性，整個運(yùn)維行業(yè)是人跟著報警走的狀態(tài)。

這樣的方式非常累且毫無成就感，大家對運(yùn)維的概念除了悲觀，別無其他。所以建立一個能夠衡量運(yùn)維工作，通過數(shù)據(jù)就可了解到質(zhì)量的指標(biāo)成為運(yùn)維工程師們迫切要做的事情。

在做這件事情之前，其中非常重要的環(huán)節(jié)就是取得業(yè)務(wù)線的信任。大多運(yùn)維人員對業(yè)務(wù)架構(gòu)、線上服務(wù)狀態(tài)都非常了解，但對每個模塊、程序內(nèi)部邏輯了解的不是那么詳盡。進(jìn)而對程序在什么狀態(tài)下會出故障，以及出現(xiàn)故障的原因也不是很清晰。

這時，要針對業(yè)務(wù)線深度合作，在取得信任的前提下，熟知每個模塊的具體實(shí)現(xiàn)邏輯、每個請求包的大小、請求的正常狀態(tài)、返回標(biāo)準(zhǔn)等等。

因?yàn)闆]有百分百穩(wěn)定的系統(tǒng)，所以需要了解業(yè)務(wù)需求，明確穩(wěn)定性需求。就電商服務(wù)來說，能接受頁面展示微慢，但絕對不能丟失交易信息，不能算錯錢。

對搜索服務(wù)來說，能允許結(jié)果有些偏差，但不允許頁面不能訪問。也就是說，要對需求進(jìn)行逐一分類、分級，不能眉毛胡子一把抓，每個模塊都保證百分百穩(wěn)定，這是不現(xiàn)實(shí)的。

在 SLO 建立過程中，一定要注意避免不可抗力，因?yàn)橹笜?biāo)一旦建立，就是公司整個業(yè)務(wù)，對整個運(yùn)維部門的評價體系。故在制定指標(biāo)時，要可維護(hù)，可衡量，可提高。

如受到黑客攻擊，不設(shè)為故障。把恢復(fù)時長、范圍控制等構(gòu)成運(yùn)維 SLO，也就是承諾的服務(wù)質(zhì)量。

在建立各種指標(biāo)后，緊接著是根據(jù)需求來選擇監(jiān)控系統(tǒng)（監(jiān)控部分后文有展開說明），搜狗最早采用第三方系統(tǒng)，之后逐步轉(zhuǎn)為自研。

最后是 SLO 的具體實(shí)施過程，我們秉承一個觀點(diǎn)是：數(shù)據(jù)先行，不要在意一城一池的得失。也就是發(fā)現(xiàn)一個問題，首先展示現(xiàn)實(shí)狀態(tài)，哪怕數(shù)據(jù)下跌了 50%。

在此這基礎(chǔ)上，通過運(yùn)維人員的介入，實(shí)現(xiàn)數(shù)據(jù)不斷提升，才能取得優(yōu)先的信任。這是一個互相交互，正反饋的方式。

如何避免不可抗力呢？首先，我們永遠(yuǎn)無法知道硬件什么時候出現(xiàn)故障，所以，要對架構(gòu)進(jìn)行相應(yīng)優(yōu)化，將硬件的故障全部容錯掉。

最簡單的辦法就是關(guān)鍵節(jié)點(diǎn)必須冗余，避免群死群傷。切記從用戶視角來定義 SLO，就算服務(wù)器宕機(jī)，但是用戶感受不到，那么，對于服務(wù)就是穩(wěn)定的。

還有就是代碼上線，經(jīng)過一系列檢查沒問題，運(yùn)行一段時間以后，可能是因?yàn)閮?nèi)存泄露，也可能是因?yàn)榫€下測試無法覆蓋線上所有的情況，突然崩潰。

這時可以采用服務(wù)降級&快速擴(kuò)容的方式來應(yīng)對；也可以利用緩存，在很大程度上解決代碼故障導(dǎo)致的問題，讓用戶無感或近似無感，給用戶展示一個 5 分鐘前的結(jié)果要好過用戶什么都看不到。

如何實(shí)現(xiàn) SLO

搜狗實(shí)現(xiàn) SLO 首先是運(yùn)維人員一定避免自己操作失誤，同時需要 7×24 及時響應(yīng)報警。其次是模塊的原子化與標(biāo)準(zhǔn)化，謹(jǐn)記要拋棄運(yùn)維手冊，簡化故障恢復(fù)手段。

常規(guī)運(yùn)維狀態(tài)是各管一部分，最多是二人互備。在這樣情況下，當(dāng)運(yùn)維人員離職，就出現(xiàn)斷檔情況。把所有的模塊原子化，就是為應(yīng)對在這個時期也可做到故障順利恢復(fù)。

模塊的原子化就是每個模塊把自有代碼、配置、數(shù)據(jù)、上線統(tǒng)一做成一個黑盒，對外是一個個接口。

模塊內(nèi)部隨意調(diào)整，相互之間溝通協(xié)調(diào)不容易出現(xiàn)問題。模塊的操作標(biāo)準(zhǔn)化是要制定一個標(biāo)準(zhǔn)流程。還有就是一定要備份，尤其是環(huán)境變量的備份。

基于模塊的原子化和操作標(biāo)準(zhǔn)化之后，要拋棄運(yùn)維手冊，把運(yùn)維手冊簡化成幾條原則。

這個階段，通過手快的方式，提高故障響應(yīng)速度，運(yùn)維得到好評，故障降低，線上穩(wěn)定性提升，運(yùn)維靠譜并贏得業(yè)務(wù)的信任。

這背后的苦，只能運(yùn)維自己扛，但不能一直這樣持續(xù)下去。所以我開始反思運(yùn)維到底是做什么的？如何能不出現(xiàn)故障？

•     從簡單的為了不背鍋而干活，轉(zhuǎn)變?yōu)榫€上服務(wù)的管理者/服務(wù)者，管理線上整個環(huán)境和線上所有的流程，提升主觀能動性。
•     雖然職責(zé)上不對線上程序的策略負(fù)責(zé)，但要比開發(fā)更明白模塊和模塊之間的關(guān)系。
•     需要冗余資源，來保證某些服務(wù)能達(dá)到更高的穩(wěn)定性。
•     雖然冗余資源，但還是會出現(xiàn)難以避免的故障，如模塊所在機(jī)器網(wǎng)卡流量、IO、內(nèi)存突漲等等，需要有快速擴(kuò)容的能力。
•     鐵打的公司，流水的開發(fā)，經(jīng)常會有一些重復(fù)性的故障，做運(yùn)維的要在項(xiàng)目制定的時候就開始介入，建立和不斷完善運(yùn)維準(zhǔn)入門檻這個制度，幫開發(fā)把好關(guān)。

如何提高 SLO

經(jīng)過實(shí)現(xiàn) SLO 的過程，我總結(jié)了很多經(jīng)驗(yàn)教訓(xùn)。很多故障在發(fā)生之前，都會產(chǎn)生一些表象?；谶@些因素，在了解代碼策略的基礎(chǔ)上，要分析所有可能出問題的點(diǎn)。

預(yù)警的提出和成熟

預(yù)警策略需要做的三件事分別是：

•     系統(tǒng)資源層面。如 IO 性能，CPU、內(nèi)存等。
•     模塊存活情況。這里指通用規(guī)則，保證服務(wù)面向整體順暢，允許 1 到 2 個節(jié)點(diǎn)出現(xiàn)問題。
•     各模塊的特殊監(jiān)控需求。如常見的 AB 請求，請求或出現(xiàn) 504 次數(shù)過多，就需要特殊監(jiān)控。

對于系統(tǒng)資源層面，運(yùn)維可以通過 TOP 或 PSO 來進(jìn)行，但對于模塊存活情況和各模塊的特殊監(jiān)控需求就需要開發(fā)從接口和 log 上給予支持。

預(yù)警系統(tǒng)的實(shí)現(xiàn)

預(yù)警系統(tǒng)自始，我們就采用自主研發(fā)的方式，第一階段就是信息的產(chǎn)生和收集，框架如下圖：

在各個服務(wù)節(jié)點(diǎn)上布設(shè)腳本進(jìn)行收集，對于系統(tǒng)的資源層面，簡單計算這個模塊當(dāng)前系統(tǒng)使用情況，對于各模塊特殊的監(jiān)控需求，提供可擴(kuò)展功能。

一類是開發(fā)將自己的監(jiān)控需求，寫入 log，運(yùn)維去計算單位時間 log 出現(xiàn)的次數(shù)。

另一類，是模塊提供接口，運(yùn)維訪問接口，進(jìn)而拿到當(dāng)前模塊多少線程，線程數(shù)的處理情況等信息。

針對單機(jī)收集之后，然后發(fā)給消息列隊，只要完成在沒報警之前通知運(yùn)維人員就好，所以對性能的要求不是很高，消息隊列的時效性在 1 分鐘，甚至是幾分鐘都可接受。

消息列隊還對數(shù)據(jù)進(jìn)行清洗和合并，將同一產(chǎn)品，同一模塊的數(shù)據(jù)進(jìn)行合并之后，洗成一個服務(wù)這一分鐘的狀態(tài)。

預(yù)警系統(tǒng)還布設(shè)一個規(guī)則庫，對于規(guī)則庫的管理，其實(shí)就是一個用戶的 UI，自己寫規(guī)則，將規(guī)則存到庫中，并將規(guī)則庫做成詞典，供給程序加載。

在匯總規(guī)則過濾環(huán)節(jié)，規(guī)則作為加載的數(shù)據(jù)文件，從消息隊列中取出所有數(shù)據(jù)進(jìn)行過濾，過濾之后，決定要不要報警。達(dá)到在故障前報警，人工介入處理，對用戶無感。

如下圖，是某模塊規(guī)則展示與規(guī)則進(jìn)行的繪圖情況：

左上是某模塊規(guī)則展示，每條規(guī)則都包含規(guī)則名和規(guī)則明細(xì)。右下是規(guī)則進(jìn)行的繪圖情況，采集過來的每個指標(biāo)都有一個趨勢。

當(dāng)這些規(guī)則產(chǎn)生之后，整個服務(wù)應(yīng)用在每次掛之前，都會有一個預(yù)掛狀態(tài)，預(yù)掛時報警就會產(chǎn)出，運(yùn)維人員收到報警，就會對故障有一定的心理準(zhǔn)備，針對問題定向處理，速度也會快很多。

在很多情況下，都能在服務(wù)還沒有整體出問題暴露給用戶之前，就實(shí)現(xiàn)很好的人工介入，保證不產(chǎn)生報警和用戶體驗(yàn)的下降。

運(yùn)維準(zhǔn)入門檻

經(jīng)過建設(shè)、實(shí)現(xiàn)、提高 SLO 整個過程之后，又提出運(yùn)維準(zhǔn)入門檻。

這里主要分享三方面：

•     所有模塊必須有預(yù)警邏輯。開發(fā)交付給運(yùn)維的所有模塊，必須有綜上所有機(jī)制，否則無法保證此模塊的穩(wěn)定性。
•     所有可能產(chǎn)生的故障點(diǎn)必須有相應(yīng) log，即可被監(jiān)控到。不能出現(xiàn)開發(fā)私自寫邏輯，不告知運(yùn)維，等線程出現(xiàn)故障查不出的情況。
•     帶病堅持工作的模塊，運(yùn)維不負(fù)責(zé) SLO。因?yàn)榛ヂ?lián)網(wǎng)公司日新月異，要保障業(yè)務(wù)的快速發(fā)展，允許快速迭代，但不承諾服務(wù)質(zhì)量或降低服務(wù)質(zhì)量標(biāo)準(zhǔn)。

故障自動恢復(fù)

做了 SLO，定下了運(yùn)維準(zhǔn)入門檻，可以提前預(yù)警，但只是穩(wěn)定性不受影響，還是要去處理故障。目前，搜狗正在做的事情是故障自動恢復(fù)。

基于過往經(jīng)驗(yàn)來看，重啟可以解決 90% 的問題，回滾可以再解決 90% 的問題，真正重啟和回滾都解決不了的問題，出現(xiàn)的幾率很小。

如果重啟和回滾無法解決，那就是系統(tǒng)扛不住，就需要快速擴(kuò)容的能力，獲得足夠的資源。再就是在故障恢復(fù)時，可對服務(wù)降級。

目前實(shí)施的手段，將請求給予全系統(tǒng)唯一的 id，通過對逐層模塊的 log 進(jìn)行定位和分析，定位到具體出問題的點(diǎn)，并和預(yù)警/報警同步以頁面的形式提供給運(yùn)維人員。

正在嘗試將部分確定故障的處理方式固化，在故障定位頁面提供一鍵操作的邏輯，實(shí)現(xiàn)部分故障的快速恢復(fù)。

未來的展望

對未來，主要有兩方面展望，分別是：將人工智能引入到規(guī)則庫的管理和故障的根因分析。

•     對于規(guī)則庫的管理。這是一件很頭痛的事情，引入人工智能的方式，可根據(jù)歷史情況去對閾值進(jìn)行隨時調(diào)試，而不是純依賴于運(yùn)維人員的經(jīng)驗(yàn)。
•     故障的根因分析。一方面查詢整個系統(tǒng)的各個層級出現(xiàn)的情況，根據(jù)實(shí)際展示的情況去進(jìn)行原因的分析。另一方面，由查詢引起模塊在其他資源層面的變化反推某個模塊產(chǎn)生的故障及原因。

2008 年加入搜狗，目前帶領(lǐng)團(tuán)隊負(fù)責(zé)搜狗搜索的所有運(yùn)維事務(wù)，主導(dǎo)了搜狗搜索的多次重大升級，在運(yùn)維標(biāo)準(zhǔn)化和自動化方面進(jìn)行了多方面的實(shí)踐并取得良好的結(jié)果，在 SLO 實(shí)現(xiàn)方面具有豐富經(jīng)驗(yàn)。

【原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請注明原文作者和出處為.com】

分享標(biāo)題：運(yùn)維逼格提升心法：從報警到預(yù)警，如何有效提升SLO
網(wǎng)站網(wǎng)址：http://uogjgqi.cn/article/djchcgo.html