當(dāng)下,IT 運(yùn)維成為企業(yè)的核心競(jìng)爭(zhēng)力,從過(guò)去人肉保障的階段,一直到現(xiàn)在引入 AI 和各種計(jì)算的方式來(lái)實(shí)現(xiàn)穩(wěn)定性。在進(jìn)階的過(guò)程中,如何評(píng)價(jià)運(yùn)維的質(zhì)量,是擺在運(yùn)維人員和服務(wù)對(duì)象/業(yè)務(wù)方之間的難題。
在由 51CTO 主辦的第十四期“Tech Neo”技術(shù)沙龍活動(dòng)中,搜狗 SRE 負(fù)責(zé)人黃昕老師以此難題為開(kāi)端,逐步深入展開(kāi),講解具體實(shí)現(xiàn)細(xì)節(jié)。分享主線(xiàn)以時(shí)間為序:從建立、實(shí)現(xiàn) SLO,到預(yù)警的提出和成熟、預(yù)警系統(tǒng)的布設(shè),再到運(yùn)維準(zhǔn)入門(mén)檻的提出、故障的自動(dòng)恢復(fù)。
如何建立 SLO
SLO 即服務(wù)水平目標(biāo),通過(guò)建立運(yùn)維 SLO,如穩(wěn)定性目標(biāo)、服務(wù)時(shí)長(zhǎng)等,實(shí)現(xiàn)用數(shù)據(jù)的方式合理評(píng)價(jià)運(yùn)維工作效率。
十年前,沒(méi)有各種監(jiān)控系統(tǒng),要以純?nèi)巳獾姆绞剑瑏?lái)實(shí)現(xiàn)穩(wěn)定性,整個(gè)運(yùn)維行業(yè)是人跟著報(bào)警走的狀態(tài)。
這樣的方式非常累且毫無(wú)成就感,大家對(duì)運(yùn)維的概念除了悲觀,別無(wú)其他。所以建立一個(gè)能夠衡量運(yùn)維工作,通過(guò)數(shù)據(jù)就可了解到質(zhì)量的指標(biāo)成為運(yùn)維工程師們迫切要做的事情。
在做這件事情之前,其中非常重要的環(huán)節(jié)就是取得業(yè)務(wù)線(xiàn)的信任。大多運(yùn)維人員對(duì)業(yè)務(wù)架構(gòu)、線(xiàn)上服務(wù)狀態(tài)都非常了解,但對(duì)每個(gè)模塊、程序內(nèi)部邏輯了解的不是那么詳盡。進(jìn)而對(duì)程序在什么狀態(tài)下會(huì)出故障,以及出現(xiàn)故障的原因也不是很清晰。
這時(shí),要針對(duì)業(yè)務(wù)線(xiàn)深度合作,在取得信任的前提下,熟知每個(gè)模塊的具體實(shí)現(xiàn)邏輯、每個(gè)請(qǐng)求包的大小、請(qǐng)求的正常狀態(tài)、返回標(biāo)準(zhǔn)等等。
因?yàn)闆](méi)有百分百穩(wěn)定的系統(tǒng),所以需要了解業(yè)務(wù)需求,明確穩(wěn)定性需求。就電商服務(wù)來(lái)說(shuō),能接受頁(yè)面展示微慢,但絕對(duì)不能丟失交易信息,不能算錯(cuò)錢(qián)。
對(duì)搜索服務(wù)來(lái)說(shuō),能允許結(jié)果有些偏差,但不允許頁(yè)面不能訪(fǎng)問(wèn)。也就是說(shuō),要對(duì)需求進(jìn)行逐一分類(lèi)、分級(jí),不能眉毛胡子一把抓,每個(gè)模塊都保證百分百穩(wěn)定,這是不現(xiàn)實(shí)的。
在 SLO 建立過(guò)程中,一定要注意避免不可抗力,因?yàn)橹笜?biāo)一旦建立,就是公司整個(gè)業(yè)務(wù),對(duì)整個(gè)運(yùn)維部門(mén)的評(píng)價(jià)體系。故在制定指標(biāo)時(shí),要可維護(hù),可衡量,可提高。
如受到黑客攻擊,不設(shè)為故障。把恢復(fù)時(shí)長(zhǎng)、范圍控制等構(gòu)成運(yùn)維 SLO,也就是承諾的服務(wù)質(zhì)量。
在建立各種指標(biāo)后,緊接著是根據(jù)需求來(lái)選擇監(jiān)控系統(tǒng)(監(jiān)控部分后文有展開(kāi)說(shuō)明),搜狗最早采用第三方系統(tǒng),之后逐步轉(zhuǎn)為自研。
最后是 SLO 的具體實(shí)施過(guò)程,我們秉承一個(gè)觀點(diǎn)是:數(shù)據(jù)先行,不要在意一城一池的得失。也就是發(fā)現(xiàn)一個(gè)問(wèn)題,首先展示現(xiàn)實(shí)狀態(tài),哪怕數(shù)據(jù)下跌了 50%。
在此這基礎(chǔ)上,通過(guò)運(yùn)維人員的介入,實(shí)現(xiàn)數(shù)據(jù)不斷提升,才能取得優(yōu)先的信任。這是一個(gè)互相交互,正反饋的方式。
如何避免不可抗力呢?首先,我們永遠(yuǎn)無(wú)法知道硬件什么時(shí)候出現(xiàn)故障,所以,要對(duì)架構(gòu)進(jìn)行相應(yīng)優(yōu)化,將硬件的故障全部容錯(cuò)掉。
最簡(jiǎn)單的辦法就是關(guān)鍵節(jié)點(diǎn)必須冗余,避免群死群傷。切記從用戶(hù)視角來(lái)定義 SLO,就算服務(wù)器宕機(jī),但是用戶(hù)感受不到,那么,對(duì)于服務(wù)就是穩(wěn)定的。
還有就是代碼上線(xiàn),經(jīng)過(guò)一系列檢查沒(méi)問(wèn)題,運(yùn)行一段時(shí)間以后,可能是因?yàn)閮?nèi)存泄露,也可能是因?yàn)榫(xiàn)下測(cè)試無(wú)法覆蓋線(xiàn)上所有的情況,突然崩潰。
這時(shí)可以采用服務(wù)降級(jí)&快速擴(kuò)容的方式來(lái)應(yīng)對(duì);也可以利用緩存,在很大程度上解決代碼故障導(dǎo)致的問(wèn)題,讓用戶(hù)無(wú)感或近似無(wú)感,給用戶(hù)展示一個(gè) 5 分鐘前的結(jié)果要好過(guò)用戶(hù)什么都看不到。
如何實(shí)現(xiàn) SLO
搜狗實(shí)現(xiàn) SLO 首先是運(yùn)維人員一定避免自己操作失誤,同時(shí)需要 7×24 及時(shí)響應(yīng)報(bào)警。其次是模塊的原子化與標(biāo)準(zhǔn)化,謹(jǐn)記要拋棄運(yùn)維手冊(cè),簡(jiǎn)化故障恢復(fù)手段。
常規(guī)運(yùn)維狀態(tài)是各管一部分,最多是二人互備。在這樣情況下,當(dāng)運(yùn)維人員離職,就出現(xiàn)斷檔情況。把所有的模塊原子化,就是為應(yīng)對(duì)在這個(gè)時(shí)期也可做到故障順利恢復(fù)。
模塊的原子化就是每個(gè)模塊把自有代碼、配置、數(shù)據(jù)、上線(xiàn)統(tǒng)一做成一個(gè)黑盒,對(duì)外是一個(gè)個(gè)接口。
模塊內(nèi)部隨意調(diào)整,相互之間溝通協(xié)調(diào)不容易出現(xiàn)問(wèn)題。模塊的操作標(biāo)準(zhǔn)化是要制定一個(gè)標(biāo)準(zhǔn)流程。還有就是一定要備份,尤其是環(huán)境變量的備份。
基于模塊的原子化和操作標(biāo)準(zhǔn)化之后,要拋棄運(yùn)維手冊(cè),把運(yùn)維手冊(cè)簡(jiǎn)化成幾條原則。
這個(gè)階段,通過(guò)手快的方式,提高故障響應(yīng)速度,運(yùn)維得到好評(píng),故障降低,線(xiàn)上穩(wěn)定性提升,運(yùn)維靠譜并贏得業(yè)務(wù)的信任。
這背后的苦,只能運(yùn)維自己扛,但不能一直這樣持續(xù)下去。所以我開(kāi)始反思運(yùn)維到底是做什么的?如何能不出現(xiàn)故障?
-
從簡(jiǎn)單的為了不背鍋而干活,轉(zhuǎn)變?yōu)榫(xiàn)上服務(wù)的管理者/服務(wù)者,管理線(xiàn)上整個(gè)環(huán)境和線(xiàn)上所有的流程,提升主觀能動(dòng)性。
-
雖然職責(zé)上不對(duì)線(xiàn)上程序的策略負(fù)責(zé),但要比開(kāi)發(fā)更明白模塊和模塊之間的關(guān)系。
-
需要冗余資源,來(lái)保證某些服務(wù)能達(dá)到更高的穩(wěn)定性。
-
雖然冗余資源,但還是會(huì)出現(xiàn)難以避免的故障,如模塊所在機(jī)器網(wǎng)卡流量、IO、內(nèi)存突漲等等,需要有快速擴(kuò)容的能力。
-
鐵打的公司,流水的開(kāi)發(fā),經(jīng)常會(huì)有一些重復(fù)性的故障,做運(yùn)維的要在項(xiàng)目制定的時(shí)候就開(kāi)始介入,建立和不斷完善運(yùn)維準(zhǔn)入門(mén)檻這個(gè)制度,幫開(kāi)發(fā)把好關(guān)。
如何提高 SLO
經(jīng)過(guò)實(shí)現(xiàn) SLO 的過(guò)程,我總結(jié)了很多經(jīng)驗(yàn)教訓(xùn)。很多故障在發(fā)生之前,都會(huì)產(chǎn)生一些表象;谶@些因素,在了解代碼策略的基礎(chǔ)上,要分析所有可能出問(wèn)題的點(diǎn)。
預(yù)警的提出和成熟
預(yù)警策略需要做的三件事分別是:
-
系統(tǒng)資源層面。如 IO 性能,CPU、內(nèi)存等。
-
模塊存活情況。這里指通用規(guī)則,保證服務(wù)面向整體順暢,允許 1 到 2 個(gè)節(jié)點(diǎn)出現(xiàn)問(wèn)題。
-
各模塊的特殊監(jiān)控需求。如常見(jiàn)的 AB 請(qǐng)求,請(qǐng)求或出現(xiàn) 504 次數(shù)過(guò)多,就需要特殊監(jiān)控。
對(duì)于系統(tǒng)資源層面,運(yùn)維可以通過(guò) TOP 或 PSO 來(lái)進(jìn)行,但對(duì)于模塊存活情況和各模塊的特殊監(jiān)控需求就需要開(kāi)發(fā)從接口和 log 上給予支持。
預(yù)警系統(tǒng)的實(shí)現(xiàn)
預(yù)警系統(tǒng)自始,我們就采用自主研發(fā)的方式,第一階段就是信息的產(chǎn)生和收集,框架如下圖:
在各個(gè)服務(wù)節(jié)點(diǎn)上布設(shè)腳本進(jìn)行收集,對(duì)于系統(tǒng)的資源層面,簡(jiǎn)單計(jì)算這個(gè)模塊當(dāng)前系統(tǒng)使用情況,對(duì)于各模塊特殊的監(jiān)控需求,提供可擴(kuò)展功能。
一類(lèi)是開(kāi)發(fā)將自己的監(jiān)控需求,寫(xiě)入 log,運(yùn)維去計(jì)算單位時(shí)間 log 出現(xiàn)的次數(shù)。
另一類(lèi),是模塊提供接口,運(yùn)維訪(fǎng)問(wèn)接口,進(jìn)而拿到當(dāng)前模塊多少線(xiàn)程,線(xiàn)程數(shù)的處理情況等信息。
針對(duì)單機(jī)收集之后,然后發(fā)給消息列隊(duì),只要完成在沒(méi)報(bào)警之前通知運(yùn)維人員就好,所以對(duì)性能的要求不是很高,消息隊(duì)列的時(shí)效性在 1 分鐘,甚至是幾分鐘都可接受。
消息列隊(duì)還對(duì)數(shù)據(jù)進(jìn)行清洗和合并,將同一產(chǎn)品,同一模塊的數(shù)據(jù)進(jìn)行合并之后,洗成一個(gè)服務(wù)這一分鐘的狀態(tài)。
預(yù)警系統(tǒng)還布設(shè)一個(gè)規(guī)則庫(kù),對(duì)于規(guī)則庫(kù)的管理,其實(shí)就是一個(gè)用戶(hù)的 UI,自己寫(xiě)規(guī)則,將規(guī)則存到庫(kù)中,并將規(guī)則庫(kù)做成詞典,供給程序加載。
在匯總規(guī)則過(guò)濾環(huán)節(jié),規(guī)則作為加載的數(shù)據(jù)文件,從消息隊(duì)列中取出所有數(shù)據(jù)進(jìn)行過(guò)濾,過(guò)濾之后,決定要不要報(bào)警。達(dá)到在故障前報(bào)警,人工介入處理,對(duì)用戶(hù)無(wú)感。
如下圖,是某模塊規(guī)則展示與規(guī)則進(jìn)行的繪圖情況:
左上是某模塊規(guī)則展示,每條規(guī)則都包含規(guī)則名和規(guī)則明細(xì)。右下是規(guī)則進(jìn)行的繪圖情況,采集過(guò)來(lái)的每個(gè)指標(biāo)都有一個(gè)趨勢(shì)。
當(dāng)這些規(guī)則產(chǎn)生之后,整個(gè)服務(wù)應(yīng)用在每次掛之前,都會(huì)有一個(gè)預(yù)掛狀態(tài),預(yù)掛時(shí)報(bào)警就會(huì)產(chǎn)出,運(yùn)維人員收到報(bào)警,就會(huì)對(duì)故障有一定的心理準(zhǔn)備,針對(duì)問(wèn)題定向處理,速度也會(huì)快很多。
在很多情況下,都能在服務(wù)還沒(méi)有整體出問(wèn)題暴露給用戶(hù)之前,就實(shí)現(xiàn)很好的人工介入,保證不產(chǎn)生報(bào)警和用戶(hù)體驗(yàn)的下降。
運(yùn)維準(zhǔn)入門(mén)檻
經(jīng)過(guò)建設(shè)、實(shí)現(xiàn)、提高 SLO 整個(gè)過(guò)程之后,又提出運(yùn)維準(zhǔn)入門(mén)檻。
這里主要分享三方面:
-
所有模塊必須有預(yù)警邏輯。開(kāi)發(fā)交付給運(yùn)維的所有模塊,必須有綜上所有機(jī)制,否則無(wú)法保證此模塊的穩(wěn)定性。
-
所有可能產(chǎn)生的故障點(diǎn)必須有相應(yīng) log,即可被監(jiān)控到。不能出現(xiàn)開(kāi)發(fā)私自寫(xiě)邏輯,不告知運(yùn)維,等線(xiàn)程出現(xiàn)故障查不出的情況。
-
帶病堅(jiān)持工作的模塊,運(yùn)維不負(fù)責(zé) SLO。因?yàn)榛ヂ?lián)網(wǎng)公司日新月異,要保障業(yè)務(wù)的快速發(fā)展,允許快速迭代,但不承諾服務(wù)質(zhì)量或降低服務(wù)質(zhì)量標(biāo)準(zhǔn)。
故障自動(dòng)恢復(fù)
做了 SLO,定下了運(yùn)維準(zhǔn)入門(mén)檻,可以提前預(yù)警,但只是穩(wěn)定性不受影響,還是要去處理故障。目前,搜狗正在做的事情是故障自動(dòng)恢復(fù)。
基于過(guò)往經(jīng)驗(yàn)來(lái)看,重啟可以解決 90% 的問(wèn)題,回滾可以再解決 90% 的問(wèn)題,真正重啟和回滾都解決不了的問(wèn)題,出現(xiàn)的幾率很小。
如果重啟和回滾無(wú)法解決,那就是系統(tǒng)扛不住,就需要快速擴(kuò)容的能力,獲得足夠的資源。再就是在故障恢復(fù)時(shí),可對(duì)服務(wù)降級(jí)。
目前實(shí)施的手段,將請(qǐng)求給予全系統(tǒng)唯一的 id,通過(guò)對(duì)逐層模塊的 log 進(jìn)行定位和分析,定位到具體出問(wèn)題的點(diǎn),并和預(yù)警/報(bào)警同步以頁(yè)面的形式提供給運(yùn)維人員。
正在嘗試將部分確定故障的處理方式固化,在故障定位頁(yè)面提供一鍵操作的邏輯,實(shí)現(xiàn)部分故障的快速恢復(fù)。
未來(lái)的展望
-
對(duì)未來(lái),主要有兩方面展望,分別是:將人工智能引入到規(guī)則庫(kù)的管理和故障的根因分析。
-
對(duì)于規(guī)則庫(kù)的管理。這是一件很頭痛的事情,引入人工智能的方式,可根據(jù)歷史情況去對(duì)閾值進(jìn)行隨時(shí)調(diào)試,而不是純依賴(lài)于運(yùn)維人員的經(jīng)驗(yàn)。
故障的根因分析。一方面查詢(xún)整個(gè)系統(tǒng)的各個(gè)層級(jí)出現(xiàn)的情況,根據(jù)實(shí)際展示的情況去進(jìn)行原因的分析。另一方面,由查詢(xún)引起模塊在其他資源層面的變化反推某個(gè)模塊產(chǎn)生的故障及原因。
核心關(guān)注:拓步ERP系統(tǒng)平臺(tái)是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用,蘊(yùn)涵了豐富的ERP管理思想,集成了ERP軟件業(yè)務(wù)管理理念,功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理,全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域,是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴(lài)品牌。
轉(zhuǎn)載請(qǐng)注明出處:拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標(biāo)題:運(yùn)維逼格提升心法:從報(bào)警到預(yù)警,如何有效提升SLO
本文網(wǎng)址:http://www.ezxoed.cn/html/support/11121521033.html