開通博客後,第一篇文章.不周到處尚請見諒.
今天看到51開了一個關於談談那些年我們做過的運維. 看了些文章.頗有感觸. 在此也寫一些自己的想法和遇到的事情.
談到運維,由於IT運維是一個大的概念,涉及到了很多知識.有網絡的,有終端的,有服務器的,也有數據庫和業務應用的.
而我們做運維的,必須先要談論的一個問題,就是業務連續性. 一談到這個問題,就出來了很多關於數字9的話題. 如3個9,4個9,5個9的.每增加一個9，那可都是錢啊.成幾何倍數增長的軟妹幣啊.
業務連續性,業務恢復時間,故障恢復時間. 注意,根據不同的架構,這2個時間是不一樣的噢. 如NLB的, 一臺服務器壞掉,另一臺服務器同時接管所有業務響應. 業務中斷時間可以忽略,但是故障還沒有恢復,壞掉的還是壞的.要一直到修好了,才能確定了故障恢復時間. 而這2個時間,取決於3個因素. 第一個因素,是架構. 第二個因素,是故障處置與應急預案文檔. 第三個因素,個人業務技能與服務商.
實現業務連續性之架構設計,對於這種,我們可以參照討論的有NLB, Cluster, 主要思路是指,當一臺服務器出現故障時,不影響業務的運行. 當然,也可以考慮使用一臺應用備機,平時放着,當運行主機故障時用以替換的方式,這種方式是,不要使用Cluster,比較省錢吧.但是業務中斷時間肯定會多一點. 這就要根據你的業務重要性來判斷了.
業務連續性與廠商服務. 嗯,服務商提供各種產品和技術服務,也與我們的業務連續性看上去沒有直接關係,只是 ,服務商的服務質量確實影響着我們. 購買產品時,有他們. 部署和架構設計時,有他們. 故障處置時,還有他們. 如何找對服務商和使用服務商.
業務連續性與預案. 這裏介紹一個很多IT人員和管理人員都喜歡用的一個詞,troubleshooting. 如何理解這個詞呢? 直接翻譯的話是” 故障排除”,而這個狀態,我的理解時,當遇到一個未知故障發生時,需要進行的一些列活動.如檢查日誌,檢查主機狀態,查找資料,進行一些操作的嘗試等等.主要就是從未知開始,到解決問題的一系列活動. 但是,這對於業務連續性來說,是一個討厭的事情.因爲你無法預知故障解決時間,也無法預知業務恢復時間. 因此,非常重要的用於實現最短業務恢復時間的方法,建立故障處置和應急預案. 要是你說你現在沒有這種東西,那麼,你只是個入門的技術人員,而不是一個合格的運維人員.
業務連續性與個人技能,這個問題嘛, 如果你做好上述3點了.那麼在運維過程中,你的技能也就足以應對你現有環境中能遇到的問題了.