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