一、運維可用性的思考
業務的不斷演進，系統的數據量不斷擴大，技術棧越來越複雜，系統模塊越來越多，造成信息系統中斷的風險場景越來越多，中斷事件的頻率和種類持續增長，且有相當一部份事件會造成業務中斷，可用性問題越來越嚴峻。
一個嚴重的業務可用性問題通常是多個層面上的可用性保障均失效的結果，比如：架構的高可用能力、監控能力、自動化工具能力、應急能力等，所以說運維組織的事件管理能力特別重要，應該本著“不浪費故障”的理念去深挖故障背後的問題，不斷完善每個環節的不足（當然，這裡不提倡追責的方式分析故障）。
可以用“海恩法則”來進一步解釋可用性問題由量變向質變轉變的過程：
海恩法則強調兩點：一是事故的發生是量的積累的結果；二是人自身的素質和責任心。將法則運用到運維領域，我覺得可以從技術手段與管理手段進行可用性能力建設。
其中技術手段主要是運維把控技術架構的高可用的標準化策略的生產環境准入門檻、運用數據分析及專家意見進行信息系統架構的持續優化、運維工具建設提高問題的預測或加快可用性的恢復；管理手段則主要從演練與應急方面分解。
二、運維可用性標準方法論
在梳理可用性能力建設前，我們先看看關於可用性的一些基本概念與方法論。
在方法論的研究上，我暫時還沒看到一個完全針對運維的信息系統可用性的建設方法論，所以暫以BCM（業務連續性管理），以及Google src中提到的可用性的理解。
這些方法論有助於培養一個體系化的知識體系，串起運維可用性能力的知識碎片。
1可用性概念
業界通常會用N個9來體現可用性程度，計算方法是：可用性=平均故障間隔時間MTBF/(平均修復時間MTTR +平均故障間隔時間MTBF)
用直觀的數據展示如下：
在實際情況下可用性的計算會做一些局部調整：
由於系統7*24小時不停機是不太可能的情況，故通常會以名義可用性作用計劃，即停業時間只考慮非計劃性的情況。
由於組織資源有限，不同的維護對象的穩定性不一樣，所以可用性的目標也不是一成不變，比如機房、核心網絡相對穩定、且可用性問題將是全局性的，所以通常的目標是100%或6個9；重要交易系統直接面向客戶，需要投入更多資源進行保障，可用性目標是5個9或4個9；一般的內部管理系統，可能是4個9或3個9。
在運維保障過程中，影響可用性的因素通常有性能問題、功能問題、設備問題、應急處理效率等，相關保障方式後續會提及。
講完可用性的概念，我們再看看RPO與PTO的恢復能力標準。
RPO（Recovery Point Obejective，恢復點目標）是指業務系統所允許的在災難過程中的最大數據丟失量，用來衡量容災系統的數據冗餘備份能力。
RTO（Recovery Time Objective，恢復時間目標）是指信息系統從災難狀態恢復到可運行狀態所需的時間，用來衡量容災系統的業務恢復能力。
以下是《信息安全技術信息系統災難恢復規範》對災備數據中心根據RPO與RTO兩項指標分成了6個相應的等級：
在明確了災備建設中災難恢復能力等級目標之後，另一個重要問題是在具體建設中應該考慮哪些資源要素。下表是對災備建設的七要素：
2業務連續性管理
以下從互聯網下載的一張關於BCM的整體解決思路，從中可以看出業務連續性管理涉及到方方面面。
從上圖可以看出BCM的方法論是一個體系化的業務連續性管理，從災難恢復，風險管理，應急管理等維度進行分解，其中多個行業都提出相應的業務連續性管理指引：
這其中，銀監會於2011年發佈的《商業銀行業務連續性監管指引》在多個角度進行規定：
上述的指引是體系化的連續性管理，己超出我當前的分析梳理能力，有興趣的同學可以找找具體的指引、BCM方法論細讀。
3Google SRE的可用性保障
關於Google SRE的理解在之前梳理的文章中做了一些總結，以下仍引用那篇小文中的理解：
SRE這個名詞最早是從《Google SRE運維解密》一書中獲得，全稱是Site Reliability Engineering，翻譯過來就是：站點可靠性工程師。Google對SRE的職責描述為：確保站點的可用，為了達到這個目的，一方面他需要對站點涉及的系統、組件熟悉，也要關注生產運行時的狀態。
為此，他需要自開發並維護很多工具和系統支撐系統的運行，比如自動化發佈系統，監控系統，日誌系統，服務器資源分配和編排等。SRE是一個綜合素質很高的全能手，如果對他的能力進行分解主要有三塊：
熟悉系統架構與運行狀態：SRE需要懂服務器基礎架構、操作系統、網絡、中間件容器、常用編程語言、全局的架構意識、非常強的問題分析能力、極高的抗壓能力（以便沉著高效地排障），他們還需要懂性能調優理論。為了保證系統架構的高可用，SRE甚至會有意識的破壞自己的系統，以提高系統可用性。
熟悉運維涉及的管理方法：SRE需根據企業自身發展需要，清楚運維涉及的各項工作的流程方法論，比如故障處理、應用發佈、可用性管理等等，SRE十分重視運維流程的持續改善，比如對故障的追丁溯源，懷疑一切的方式持續改進。
總的來說，BCM更關注於從管理層面可用性能力建設方法論，而從Google現有的分享來看，Google SRE更關注於技術層面的可用性能力建設，兩者都值得我們在可用性能力建設中借鑑，以下僅從一個局部梳理我理解的可用性能力建設的一些方面。
三、運維可用性能力建設（技術手段）
關於技術手段方面的可用性能力建設，將從運維把控技術架構的高可用的標準化策略的生產環境准入門檻、運用數據分析及專家意見進行信息系統架構的持續優化、運維工具建設提高問題的預測或加快可用性的恢復三方面進行梳理。
1架構的可用性標準化
不同運維領域的運維人員在局部都會有很多架構可用性建設的經驗，由於我對基礎設施、網絡、服務器、數據庫、系統等方面的可用性能力建設接觸較少，故在本章只從信息系統架構的可用性進行梳理。梳理架構的可用性是希望以運維團隊可以把控的角度，對信息系統的架構可用性的准入條件進行提前的標準化。
從運維團隊看，有些大型的互聯網運維團隊具備研發基礎組件的能力，比如騰訊QQ團隊提到的它們研發了服務名詞服務模塊，應用系統的開發團隊按這個模塊進行服務註冊與消費的設計；或者是建立基於容器的PaaS平臺，開發團隊按PaaS平臺規範進行設計等等。
基於系統穩定性角度看，我覺得這些由運維團隊建立的標準化模塊需要建立在一個強大研發能力的運維團隊與相對開放式的運維開發協同大環境之下。從相對比較普適的架構可用性建設看，可以考慮先從以下幾方面進行建設：
1）應用架構高可用
雙機備份
我們提到的雙機備份通常有兩種方式，一種是冷備，一種是熱備，兩者區別是，前者的主備切換需要人工介入，後而不需要人工介入。這種方式，像windows操作系統的群集管理工具，Linux操作系統HACMP等具備這種雙機切換的能力。
從信息系統上，當前傳統的關係型數據庫，以及一些版本比較舊的應用系統通常是採用這種雙機備份的方式。在處理雙機備份時，需要重點關注主備機實時的異常探測，數據的同步問題，以及備機服務的接管能力。
通常來說，主備機之間會有一個心跳機制定時進行檢測主機是否處理正常運行狀況，比如windows的群集會主動探測主機的資源是否在線，這裡的資源包括IP、服務等是否可用；
數據的同步上，主要針對實時更新的數據更新，採用共享存儲、將非共享存儲作為一個資源在異常時加載到備機服務，或採用數據實時複製的方式；
備機服務的接管則依靠切換軟件在異常時執行提前準備好的切換腳本實現服務的接管；
運維團隊需要針對雙機備份的架構要求提前制定標準，避免主機異常時無法自主發現，發現後備機無法接管完整的數據，或備機服務接管需要人工進行復雜的操作介入等問題。
雙機備份架構雖然簡單，但也有一些缺點，比如主備切換期間的業務不可用，需要突破單機的性能瓶，備份機閒置狀態帶來的資源浪費，備份機的可用性管理也經常出問題，容易出現緊急情況下備機不可用的情況，所以如果有條件儘量減少採用雙機備份的方式。
集群&負載均衡&分佈式
負載均衡與分佈式的架構概念比較容易混淆，在我的理解中，負載均衡架構是多個服務做一堆同類的事情，每件事情相互獨立；分佈式的架構則是將一件複雜的事情分解出多個部份，由多個服務去做，再通過架構實現多個分解事情處理結果的合併。
負載均衡的架構的出現主要是解決單一服務器設備或服務無法承擔性能要求，因為通常對單機服務器性能的優化帶來的成本遠大於橫向多臺負載服務器的擴展，且帶來更靈活的擴展性，尤其是X86化、虛擬化、容器化等雲化技術的推動。
負載均衡架構通常需要具備負載均衡算法、健康檢查、會話保持的負載均衡軟件或硬件來提供架構上的可用性，其中常用見負載均衡算法有輪詢、最小連接數、最快響應時間，或基於數據包內容的分發；健康檢查則通常是對網絡連通性、服務端口監控等方式檢測；會話保持則是需要有一個機制保證一個用戶多次請求由同一臺服務器處理（當然，現在互聯網公司也提出無狀態的解決思路）。
Hadoop的mapreduce、HDFS等組件是分佈式架構典型的例子，比如mapreduce的運算過程即是“input - > map -> reduce -> output"，它的作用就是為了縮短單個計算任務的執行時間來提升效率。
理論上講由於分佈式架構可能會影響某一個節點的異常導致這個業務的失敗，所以類似於mapreduce、HDFS這類分佈式架構在設計之初就考慮了系統可能是異常的情況，在這些組件的設計上考慮了異常機制。
另外，為了進一步提高可用性還增加了一些關聯組件來保障可用性，比如運用Yarn來實現資源的調配，運用ZK實現服務的註冊消費等。
從上述三種架構看，正常情況下負載均衡/分佈式架構優於雙機備份的架構，至於負載均衡與分佈式架構哪個好，我覺得只有哪個更適合具體的應用場景，所以我們在架構的可用性能力標準化建設方面，可以考慮如下：
針對不同的業務模塊的類型制定優先選用的架構部署方式作為運維准入的門檻，並提前提交應用系統開發團隊。
針對標準化架構，考慮建立統一的標準化組件模塊，比如硬件的負載均衡模塊、軟件的負載均衡及分佈式架構模塊、標準化的PAAS層的集群管理模板，標準化的腳本等優化工作。
在非功能性層面考慮高可用的保障，在非功能性層面的高可用保障，運維的人都知道開發團隊很少主動考慮應用系統的非功能性功能的設計，比如讓開發提供服務異常時的報警這件事情況上，我覺得運維在工具建設過程中需考慮更多一些，為開發提供事件集中處理平臺的標準接口，方便開發團隊將異常信息提供給運維。同樣，在應用部署工具中考慮應用程序在多個節點上的應用同步機制；在監控工具層面考慮應用服務異常時的服務重啟自愈等等，這些高可用保障方式需要有一定的標準化程序包的落地。
上述的高可用架構主要是針對同一數據中心內的部署架構，如果放在多中心的角度，還會有跨中心的高可用解決方案，比如災備環境的業務負載能力，這就不僅從請求分流、應用負載等要求，對數據同步等能力也要求很高這裡不再作進一步細化。
2架構優化
在架構優化方案中，運維用得比較多的是：
縱向擴展：加服務器資源，換性能更強的服務器提升服務能力
橫向擴展：增加節點，比如拆分數據庫、增加負載均衡的服務節點、按地區分拆應用等方式提升服務能力
在一些數據量發展相對少的系統中，縱向擴展是最快也是最有效的解決方案，但對於業務量高速擴張的應用，第1種方案顯然無法解決問題，這時候需要用到橫向擴展的架構優化思路。具體的實施思路如下：
1）業務垂直拆分，服務化：從業務角度規劃Service，Service化完成後，業務就獨立了，這樣DB讀寫權限可以得到劃分。
梳理應用系統交易類型，把查多寫少、查少寫多的交易進行分離，再進行拆分，實現交易服務化。
2）數據庫讀寫分流：數據庫讀寫分流帶來的好處是，數據庫可以分庫了。
在數據庫中將不同的應用拆分不同的實例
在數據庫前面加上cache，減少對數據庫的壓力
將查詢類比較多的業務從交易數據庫中拆分出來，並在此基礎之上再進一步拆分查詢類的數據庫，拆分寫的數據庫，實現了讀寫分離（不是完全的讀與分離，但是有側重讀與寫，我們認為根據不同的應用需要有主與從數據庫。
分佈式數據庫，即將第3）點的主、從數據建立多個集群，分佈式部署數據庫。USERID來區分，比如1000001是第一個庫；2000001是第二個庫，以此類推；按地區來區分，比如長江以南與長江以北的客戶來分別部署數據庫
3）服務邏輯分組：上面是物理上的分離，但硬件成本、維護成本高，所以需要從應用層對服務進行擴展，分組。
橫向增加應用服務節點，通過負載均衡分發策略來實現應用性能負載。
4）應用業務流程的優化：業務流程的改造是最根本的解決，去掉一些花俏的業務功能，分拆業務流程到不同的服務，或限制業務功能的使用時間或數量等等。
5）同步改異步的方案：增加併發性。異步本身不是什麼高深的技術，關鍵是哪些業務可以走異步，這更體現架構師的業務理解能力和綜合能力。
6）限制峰值：運維人員需要知道一個應用或數據庫的峰值是多少，知道峰值後就可以考慮如何限制峰值。
7）數據庫監控：SQL是影響數據庫性能的重要因素，系統會對慢查詢SQL進行分析，分析後的慢查詢自動發給相關研發和DBA進行優化。
8）適度才好：在平時，流量上來後數據庫的性能出現瓶頸時，要具體問題具體分析，不能盲目的進行擴容、拆分、硬件升級等，先要根據具體的SQL效率、性能，結合數據庫本身情況分析判定，也許調整一下索引，SQL語句做一下調整即可解決併發量上來後的性能問題。
3工具建設輔助可用性能力的提升
以往講運維工具體系，主要會從“監、管、控”三方面建設，隨著規模不斷增大，複雜度不斷提升，從運維數據平臺也尤為重要，詳細的工具體系建設將在後續梳理。
本節先從被動式的事件集中管理場景與主動式的可用性分析場景的建設來看看提升運維的可用性能力：
1）事件集中管理場景：
前面提到的” 海恩法則“提到一個重大的業務可用性問題的出現，很可能己發生了多次事件，是一個量變的過程，所以，事件的有效管理在應用可用性能力建設中起到一個很重要的作用。
一個企業的業務系統要運行良好，需要保證一系列的軟硬件設施的穩定運行，比如機房環控、網絡設施、服務器設施、系統軟件、數據庫、中間件、應用服務，以及交易與客戶體驗層面等等因素都與穩定息息相關。在現實工作中，由於以下兩個因素影響導致一個企業監控工具很多：
運維涉及的領域很多，沒有哪一個監控工具能夠做到一籃子解決方案，往往硬件廠商擅長硬件監控，軟件廠商擅長軟件監控，DBA擅長數據庫監控，業務運維擅長業務監控、性能分析團隊擅長性能體驗監控等。
同類的監控也可能存在多套監控工具，一方面是由於同類監控的工具之間的功能也有優缺點差異，另一方面也有使用者的一些歷史原因因素等；
基於上面監控工具多的問題，建立建立一個事件集中管理的場景工具，該工具具備以下能力：
事件彙總：數據層面彙總不同層次、不同專業條線、不同類型事件是監控集中管理的基礎。可視化層面，提供統一的事件處理管理，提供多維的角色，整合應急操作工具等事件豐富的能力。
事件收斂：前面提到同一個故障會觸發多類指標的告警，同一個指標在故障未解除前也會重複產生大量的告警事件，如果將全部事件都展示出來，那對於監控處理人員將是災難性的，所以需要進行事件收斂。
事件分級：對於不同的事件需要有適當層次的事件分級，事件升級的策略。事件分級是將事件當前緊急程度進行標識顯示，事件升級是對於低級的事件當達到一定的程度，比如處理時間過長，則需要進行升級。
事件分析：事件分析是建立事件的關聯關係，關聯分析可以從縱向和橫向關係進行分析，縱向是指從底層的基礎設施、網絡、服務器硬件、虛擬機/容器、操作系統、中間件、應用域、應用、交易；橫向是指從當前的應用節點、上游服務器節點、下游服務器節點的交易關係。事件分析是形成故障樹，自愈的基礎。
2）主動式的可用性分析場景：
基於運維數據的主動式的運維或運營分析場景的ITOA，它特別值得運維團隊去建設，不過一方面有不少團隊忽略這個工作方向，另一方面由於AI太熱，很多團隊基於這類ITOA的建設直接被縮小為AIOps，聚焦到了智能算法可以應用的場景：智能監控。
當然，我並不認為智能監控的場景建設不好，只是忽略了性能、可用性、運營等方面的運行分析，直接為了智能而智能的建設思路不太贊同。後續有專門一篇梳理運行分析的能力建設，這裡暫不擴展。
四、運維可用性能力建設（管理手段）
前面一節提到了基於技術手段的可用性能力建設，本節從演練與應急兩個管理層面進行梳理。
1應急演練
應急演練是檢驗、評估、提高運維組織可用性管理的一個重要手段，通過模擬故障的發生，發現軟硬件運行環境、系統架構、系統性能、應急預案、協作溝通、人員技能等存在的不足，並持續改進應急體系。
由於缺少持續改進的應急演練的思路，實際的演練工作的開展通常變成一個為演練而演練的過程，比如演練方案長年不變、演練的問題反覆出現、只重視主備切換而忽視其它的可用性演練等等。
為了提高演練的成效，建議要將應急演練作為一個專項工作，有專人不斷調整演練的目標，分步不斷完善，讓演練真正發揮其重要的作用。
針對上面的演練目標，可以將應急演練可以分為模擬演練和實戰演練，以下簡單介紹。
1）模擬演練
模擬演練是指在非業務時段或非生產環境進行的演練工作，這類演練又分為生產環境例行的可用性演練，為了某個項目而在測試環境進行演練，或為了檢驗應急協作溝通而開展的桌面演練。
（1）例行可用性演練
例行關機維護
系統軟件在運行一段時間後會產生一些臨時文件，或一些內存碎片無法釋放等問題，所以運維組織通常會制定一些例行關機重啟維護的工作。結合這類維護操作的演練可以發現系統是否在運行期間進行了一些配置修改在重啟後引起了應用故障，系統性能的變化等問題；也可以演練當操作系統或服務器異常不可用時，應用應急恢復的時效能力。
關於這類演練可以做到計劃性，可以考慮在年初制定全年的演練計劃，針對不同的操作硬件、操作系統、業務系統分類制定不同頻率的關機維護計劃，如在實施前己臨時實施關機維護則進行調整，在具體的實施當天通常排出一個例行關機的窗口，在非業務時斷進行,這個窗口集中安排多個團隊的關機維護工作，這樣有助於提高工作效率。
高可用主備切換
雖然當前大部份系統都強調分佈式部署的方式，但在實際的生產環境中還是有很多系統是主備架構，或主應用是分佈式但局部是假負載的情況，所以強調主備切換在當前還很有意義。
主備切換中類似於數據庫，或單服務部署的應用系統（一個OS中只部署一個應用服務），因為架構比較簡單，可以參考上面例行關機維護的計劃方式，甚至建議和上面例行關機放在同一個窗口執行。除了上面相對標準的模塊，現實中還存在不少應用雖是分佈式部署，但局部有些配置需要在故障期間進行修改，或一個操作系統部署了多個服務，這種情況則需要先進行摸底梳理。針對這種情況，如組織內有一些標準化的規範，比如必須熱備、一個操作系統上必須只部署一個服務等，則需要將這類梳理出的架構進行整改，在整改前納入應急演練。
（2）準生產環境演練
這類演練工作通常是跟進項目走，比如某個重要變更需要上線，或為了在測試環境模擬驗證生產環境的真實的性能，運維會與開發、測試團隊進行聯合的演練工作。準生產環境可以考慮選擇備機、災備、測試，或一些企業會有專門的準生產環境，比如券商的週末通關測試會選擇一部份數據在備機開展。
（3）桌面演練
桌面演練指參加演練的人員根據應急操作手冊、應急協調流程等文檔，藉助多媒體會議等手段，對事先假定的演練情景進行交互式討論、推演應急決策、現場處理的過程，從而發現應急預案、溝通協調等方面存在的問題。關於桌面演練，既可以考慮提前預知的方式開展演練，也可以考慮臨時通知演練參與人介入演練。前者適合針對方案、溝通流程的完善，後者適合驗證參與人是否理解並掌握應急過程的實施。
2）實戰演練
（1）非交易期的實戰切換
非交易期的實戰切換和前面“例行可用性演練”中的切換差不多，只是切換後不馬上切換回來，需要生產系統在備份模塊中運行一段時間，或長期運行。比如，單數據中心內的雙機切換、多數據中心或災備數據中主的切換後的運行。通過這類驗證，能更好的發現主備機的高可用，並在實戰運行的過程中發現運維日常過程中存在的問題，比如配置未更新、程序未同步等。
（2）破壞性演練
破壞性演練是在交易期對應用某個模塊，或關聯繫統的某個模塊，當運行負載規模下降或不可用情況下的實戰演練。這類演練在金融企業很少提及，在互聯網公司中有提到，比如 ：Netflix為提高可用性能力，解決無法在測試環境完全模擬出真實的線上環境，可用性問題在測試環境測試時沒法發現，但是在線上環境卻頻繁發現微服務並不是完全高可用的問題， Netflix 決定在線上環境進行破壞性測試。採取的破壞性措施包括：關閉特定服務接口，關閉特定緩存服務，關閉特定 DB 服務，增加網絡丟包率，增大網絡延遲等。
2應急手段
1）最好的應急手段
最好的應急手段是提前消滅潛在的故障， 應該要不斷的反思己制定的應急場景是否有優化的空間，不斷減少或更新這些場景。
2）做好應急預案
提前制定好故障應急方案是很有必要的，但在日常工作過程中我們的應急方案遇到一些問題：
應急方案缺乏持續維護，缺乏演練，信息不及時、不準確；
應急方案過於追求大而全，導致不利於閱讀與使用；
應急方案形式大於實際使用效果，方案針對性不強；
只關注應急方案的內容，但沒有關注運維人員對方案的理解；
針對上述常見問題，應急方案需要做到以下幾點：
（1）內容精&簡
很多人可能會認為故障出現的形式各種各樣，所以應急方案需要涉及到方方面面。但實際的故障處理過程中，我們可以發現其實我們的應急措施往往重複使用幾個常用的步驟，所以應急方案要有重點，如果一個應急方案可以應對平時故障處理80%的場景，那這個應急手冊應該是合格的。
過於追求影響應用系統方方面面的內容，會導致這個方案可讀性變差，最終變成一個應付檢查的文檔。以下是應用系統應急方案應該有的內容：
系統級
能知道當前應用系統在整個交易中的角色，當前系統出現問題或上下游出現問題時，可以知道如何配合上下游分析問題，比如：上下游系統如何通訊，通訊是否有唯一的關鍵字等。
另外，系統級裡還涉及一些基本應急操作，比如擴容、系統及網絡參數調整等。
服務級
能知道這個服務影響什麼業務，服務涉及的日誌、程序、配置文件在哪裡，如何檢查服務是否正常，如何重啟服務，如何調整應用級參數等。
交易級
能知道如何查到某支或某類交易出現了問題，是大面積、局部，還是偶發性問題，能用數據說明交易影響的情況，能定位到交易報錯的信息。這裡最常用的方法就是數據庫查詢或工具的使用。
知道最重要的交易如何檢查是否正常，重要的定時任務的應急處理方案，比如開業、換日、對賬的時間要求及應急措施。
（2）輔助工具的使用
有時候，需要藉助一些工具或自動化工具輔助分析並應急，這時需要有輔助工具如何使用的方法。
（3）溝通方案
溝通方案涉及通訊錄，包括上下游系統、第三方單位、業務部門等渠道。
上述3點內容如何都完備，相信這個應急手冊己可以解決80%的故障恢復工作。
3）應急三把斧思路
故障應急方法很多，在不同的業務場景、不同的自動化水平等因素背景下，同類的故障的應急處理方法也不一樣，如果對每一類的應急方法的重視程度都一視同仁，比如演練、自動化工具等工作的投入上就會失去重點，所以建議在應急方法的管理過程中也要有側重的、分階段的完善。
比方說在眾多的應急方法中，不同的團隊也會有一些常用的應急方法，比如應用運維的“三把斧”：重啟、回撤、切換；DBA的“三把斧”：殺鎖、加索引、清理數據。在歸納出這些常用的應急方案後，就可以有針對性圍繞這類重點的痛點進行完善。
當然，強調應急三把斧的思路並不代表不用重視比較少出現故障的應急方案。是希望在人力資源有限的情況下，針對最常用的應急方法，要加大力度去實現自動化，並通過應急演練加強實際落地的能力。
以下以服務重啟為例：
（1）痛點：
分佈式部署，需要登錄多個應用進行重啟；
重啟過程中遺忘保存現場，增加故障後的問題根源分析；
重啟後檢查方法複雜，效率不高且容易出錯。
（2）解決方法：
針對最佳實踐的重啟應急的操作流程，先保存現場（比如針對JAVA服務先保存CORE），應急處理，彙總應檢查的服務狀態的數據。
針對不同的操作系統，新建服務重啟工具，工具支持重啟應急的操作流程（保存現場、重啟、技術檢查），並與監控事件的豐富整合在一起，提高應急的效率。
可用性是運維KPI或SLA中很重要的一個可量化指標，在基本的底線保障的基礎之上，將可用性能力的建設提煉出來，以橫向的角度進行建設，有利於集中力量，積累最佳實踐，是一項投入產出比很高的工作。
可用性是運維KPI或SLA中很重要的一個可量化指標，在基本的底線保障的基礎之上，將可用性能力的建設提煉出來，以橫向的角度進行建設，有利於集中力量，積累最佳實踐，是一項投入產出比很高的工作。
近期熱文
閱讀更多 DBAplus社群 的文章
