一、大規模集群管理問題
  首先我們先要明確集群的概念，集群不是泛指各功能服務器的總合，而是指為了達到某一目的或功能的服務器、硬盤資源的整合(機器數大于兩臺)，對于應用來說它就是一個整體，目前常規集群可分為：高可用性集群(HA)，負載均衡集群(如lvs)，分布式儲、計算存儲集群(DFS，如google gfs,yahoo hadoop)，特定應用集群(某一特定功能服務器組合、如db、cache層等)，目前互聯網行業主要基于這四種類型；對于前兩種類似，如果業務簡單、應用上post操作比較少，可以簡單的采用四層交換機解決(如f5)，達到服務高可用/負責均衡的作用，對于資源緊張的公司也有一些開源解決辦法如lvs+ha,非常靈活；對于后兩種，那就考驗公司技術實力及應用特點了，第三種DFS主要應用于海量數據應用上，如郵件、搜索等應用，特別是搜索要求就更高了，除了簡單海量存儲，還包括數據挖掘、用戶行為分析；如google、yahoo就能保存分析近一年的用戶記錄數據，而baidu應該少于30天、soguo就更少了。。。這些對于搜索準備性、及用戶體驗是至關重要的。
  接下來，我們再談談如何科學的管理集群，有以下關鍵幾點：
  I、監控
  主要包括故障監控和性能、流量、負載等狀態監控，這些監控關系到集群的健康運行，及潛在問題的及時發現與干預；
  a、服務故障、狀態監控：主要是對服務器自身、上層應用、關聯服務數據交互監控；例如針對前端web server，我們就可以有很多種類型的監控，包括應用端口狀態監控，便于及時發現服務器或應用本身是否crash、通過icmp包探測服務器健康狀態，更上層可能還包括應用各頻道業務的監控，常用方法是采用面業特征碼進行判斷，或對重點頁面進行簽名，以網站被黑篡改(報警、并自動恢復被篡改數據)等等，這些只是一部份，還有N多監控方式，依應用特點而定，還有一些問題需解決，如集群過大，如何高性能的進行監控也是一個現實問題。
  b、其它就是集群狀態類的監控或統計，為我們合理管理調優集群提供數據參考、包括服務瓶頸、性能問題、異常流量、攻擊等問題。
  二、故障管理
  a、硬件故障問題；對于成百上千或上萬機器的N多集群，服務器死機、硬件故障概率是非常大的，幾乎每時每刻都有服務硬件問題，死機、硬盤損壞、電源、內存、交換機。針對這種情況，我們在設計網站架構時需要充分考慮到這些問題，并將其視為常態；更多的依靠應用的冗余機制來規避這種風險，但給系統工程師足夠寬裕的處理時間。(如google不是號稱同時死800臺機器，服務不會受到任何影響嗎)；這就是考驗運維工程師及網站架構師功能的地方了，好的設計能達到google所描述自恢復能力，如gfs，糟糕的設計那就是一臺服務器的死機可能會造成大面積服務的連鎖故障反映，直接對用戶拒絕響應。
  b、應用故障問題；可能是某一bug被觸發、或某一性能閥值被超越、攻擊等情況不一而定，但重要的一點，是要有對這些問題的預防性措施，不能想當然，它不會出問題，如真出問題了，如何應對？這需要運維工程師平時做足功夫，包括應急響應速度、故障處理的科學性、備用方案的有效等。
  三、自動化
  自動化：簡而言之，就是將我們日常手動進行的一些通過工具，系統自動來完成，解放我們的雙手及枯燥的重復性勞動，例如：沒有工具前，我們安裝系統需要一臺一臺裸機安裝，如2000臺，可能需要10人/10天，搞爛N張光盤，人力成本更大。。。而現在通過自動化工具，只需幾個簡單命令就能搞定、還有如機器人類程序，自動完成以往每天人工干預的，使其自動完成、匯報結果，并具備一定的專家系統能力，能做一些簡單的是/非判斷、優化選擇等。。。這些好處非常明顯不再多說。。。應該說，自動化運維是運維工程師職業化的一個追求，利已利公，雖然這是一個異常艱巨的任務：不斷變更的業務、不規范化的應用設計、開發模式、網絡架構變更、IDC變更、規范變動等因素，都可能會對現有自動化系統產生影響，所以需要模塊化、接口化、變因參數化等因此，自動化相關，是運維工程師的核心重點之一，也是價值的體現。