第一篇：再談大型數據中心的運維工作（本站推薦）

再談大型數據中心的運維工作

隨著數據中心的建設規模不斷擴大，新技術層出不窮，數據中心變得越來越復雜。數據中心往往是由很多規模龐大的集群系統組成的，運維工作需要具備方方面面的知識，包括硬件上，業務上的東西，需要上下打通地去做運維工作。因為很多數據中心的規模非常大，面臨的挑戰和問題非常超前，很多不是問題的問題在這樣的規模下也就凸顯出來了，所以要做好大型數據中心的運維工作，對整個數據中心技術的系統的學習就要花費比較長的時間，只有對這個數據中心整體非常了解，才能有針對性地制定一些運維方案，甚至可以二次開發一些監控軟件，對整個數據中心進行管理與監控，提升整個數據中心的運行效率，減少故障的發生，從而將運維工作推向新的高度。一個大型的數據中心內部包含了很多小系統，運維工作都是圍繞著這些具體的應用系統展開的，具體的可以分為五大部分，三十多個小項，覆蓋了數據中心的所有組成部分，本文就來說一說一般大型的數據中心應該具備的哪些運維方法。

從數據中心安全方面來考慮，運維工作就是十幾個小項：攻擊保護、固件管理、備份、抓BUG/找BUG、腳本工具、自動化維修、數據安全、性能優化、服務巡檢等項目，其中每一項拿出來其實都包含很多的內容。比如說到攻擊與保護，這個主要指的是防止外來的異常入侵者對數據中心發起的惡意和無意攻擊，惡意攻擊就是有人故意的使用各種攻擊方法，進入到數據中心內部，將重要的數據竊取或者破壞，達到其不可告人的目的。也有的是無意的攻擊，因為整個數據中心是要與外界保持互聯互通的，運行是動態的，變化的，不可避免會有一些異常流量攻擊數據中心，有時甚至來自于數據中心內部，比如某些服務器中毒，或者硬件故障，構造出了環路，異常流量等網絡故障，這些都會影響到數據中心的運行，所以如何做好數據中心的攻擊與保護是一個很大的題目，這并不是在數據中心里部署幾臺安全設備就能解決的，需要對整個數據中心進行全面的統一規劃，并有針對性地部署一些安全防護措施，而且隨著各種黑客技術的提升，安全防護措施也要不斷提升，這是一個不斷學習與完善的過程，只要數據中心還在運行，這個完善就不會停止。為了方便運維，也要做好一些執行腳本，以便在出現突發事件時，能夠快速部署。比如如果一個數據中心的業務出現異常，為了快速恢復業務，需要將路由進行調整，將流量全部引到其它的數據中心，這就需要在核心路由器上進行調整，這時有個現成的腳本就可以自動執行，達到快速切換的目的。數據中心還應該準備很多其它工作的腳本，以便緊急的時候快速使用。從數據中心的基礎運維管理方面考慮，則主要有網絡抓包/過濾、可維護性優化、配置管理、監控、報警處理、自動化運維、斷網，斷電、機房容災等運維工作。其中自動化運維能提升運維的工作效率，盡量減少人為的參與，讓數據中心自己管理自己，釋放人力。同時針對數據中心可能發生的故障還做好監控與報警處理，以便能夠在故障發生的第一時間知曉問題，往往一次大的故障都是從開始的一點小故障逐漸擴展最終引發整個大系統的崩潰的，所以在出現一些小的異常時一定要及時消除，而這些異常就要靠完善的監控和報警系統來檢測。

從數據中心的日常業務運維方面考慮，則主要有資源、機器分配、Coredump、服務、內存使用、網絡吞吐、故障恢復、應用，集群搭建、流量，壓力，擴容，升級、上下級業務關聯情況、資源利用率、異常處理、降級預案等等。這些日常運維工作實際上要花費大量的人力和時間，是運維工作的主體，也最煩瑣，但卻最不能體現業績的部分。一個數據中心能夠長久安全穩定運行，就是靠這些日常的工作積累的，只有平時注意這些細微的變化，才能不斷優化。壓力測試、軟件升級、業務部署、異常處理等幾乎成為了運維工作的日常必修課，只有將這些工作做好，才能避免出現大的故障，并能夠快速部署新的業務，新的擴容設備。從數據中心網絡方面考慮，則主要有網絡硬件設備、ACL、VIP、流量、負載均衡、二三四七層情況、網絡監控、萬兆板卡、SAS/SATA/SSD等。網絡是數據中心的重要組成部分，是一切工作運行的基本，沒有網絡數據中心就無法運轉起來，所以保證網絡穩定是數據中心運維工作中的重中之重。這里主要關注的就是網絡的硬件問題，ACL部署還有流量情況。網絡可以說是包羅萬象，涉及太多的設備和協議技術，所以也需要不斷地學習，加深對網絡技術的理解，這樣才能做好網絡運維工作。

從數據中心服務器方面考慮，則主要有文件系統、內核參數調優、各種硬盤驅動、內核版本、Kernel panic等。Linux系統不僅在服務器，在網絡操作系統也占據著主流地位，掌握Linux系統的使用才能更好地處理服務器和網絡設備的運維工作，Linux是運維工作的一項基本技能。除了熟悉Linux系統的操作，還要對服務器的運行狀態和內核運行狀態進行監控與管理，減少服務器故障的發生。一般大型的數據中心都包含有成千上萬臺的服務器，幾乎每天都會有服務器出現各種各樣的問題，只有對服務器有深入理解才能很好地消除問題。為了防止服務器故障引發業務中斷，所以一般在服務器上都要部署虛擬化技術或者集群技術，當一臺服務器物理硬件故障時，業務可以平滑切換到其它服務器上，業務不會受到任何影響。這些虛擬化技術增加了運維的難度，也需要對虛擬化技術進行不斷學習。通過上面的羅列您一定很驚訝，原來數據中心運維包含這么多內容，大大小小數十項，而且每一項包含的內容說起來都不那么簡單，也涉及很多的技術知識。一個數據中心能否穩定運行，能夠高效運行，運維是關鍵。只有將這些運維工作很好地部署和執行下去，數據中心才能長期穩定。【編輯推薦】

淺析建設綠色數據中心供電系統的意義

數據中心發展吹響“綠色”集結號

利用廢棄建筑建設數據中心

解密公有云數據中心擴張背后的驅動力量

“互聯網+”時代 數據中心如何做“減法”？

第二篇：數據中心運維題目

運維部第二季度考試試卷

部門：__________________ 姓名:__________________ 分數:_____________

一、填空題（每空 1分，共 10分）

1、IDC 機房溫濕度應嚴格符合設備運行要求。溫度正常工作范圍 18-26 度；相對濕度正常工作范圍 40%-70% ；當發現溫濕度異常時，應及時（）

2、嚴格機房進出制度，外來人員應（）

3、UPS 電源三相電壓 Vab、Vbc、Vca 正常時顯示應為（），用藍，黑顏色和字母（）來標識零線，用 黃 綠 顏色和字母（）標識保護地線。

4、空調非標柜分閘燈亮表示該路電源（），合閘燈亮表示該路電源閉 合。當機房外供電出現中斷以后，空調非標準柜上市電燈亮起時，需要 按非標柜上的（）按鈕，手動合閘。

5、啟動機房氣體消防系統滅火的方法有三種，按照啟動級別依次為 按監控 室控制端的（）、擊碎機房大門側面的（），到氣瓶間拔出對應樓層的（）。

二、選擇題（每題 4 分 共 20 分）

1、MAC地址表示方法正確的是（）A、0778 B、202.201.32.100 C、011111110.01001000.11110101.00101010 D、00-60-58-70-C8-9A

2、以下那一項不含在PUE計算的電子信息設備能耗之中（）A．通訊機房的傳輸設備 B．模塊機房中客戶的交換機

C．模塊機房中我司自有的云平臺設備 D．值班室的辦公電腦

3、下面不是 IDC 機房的服務器操作系統的是（）A、Windows Server 2003、Windows 2008 Server B、Andorid、Symbian、BlackBerryOS、windows mobile C、LINXU、Centos、SUSlinux D、UNIX、freebsd

4、某公司申請到了一個C類IP地址，需要分配給8個子公司，最好的子網掩碼應設為（）A、255.255.255.0 B、255.255.255.128 C、255.255.255.240 D、255.255.255.224

5、Cisco 交換機端口指示燈為（）的情況下，為正常工作。A．熄滅

B．橘色固定時間間隔緩慢閃動 C．綠色快速閃動

D．綠色固定時間間隔緩慢閃動

三、判斷題（每題 1分，共 10分）

1、值班人員不得隨意屏蔽設備報警。（）

2、機房技術檔案可以在論壇中與其他人分享。（）

3、各種滅火器材應定位放置，隨時保持有效，人人會使用。（）

4、在機房服務器故障巡檢中漏檢，錯檢，在下次注意即可，不同通知相關負責人。（）

5、設備測試遠距離取電，多個插排串接不會對設備用電產生安全隱患。（）

6、客戶入室維護時發現未收到入室工單，應安撫客戶并立刻與客響中心確認。（）

7、當發現隱患尚未解決，上一班次已經傳報，接班人無須二次傳報。（）

8、氣體消防氣體采用無毒惰性氣體，因此在氣體釋放時人員可以站在機房內或者機房大門旁。（）

9、電源線和網線在條件允許下，可以在同一個走線架上走在一起。（）

10、發現服務器電源模塊與電源線插接處電纜外皮剝落，可能發生漏電情況，應先保障設備安全，操作設備進行關機操作。（）

四、簡答題（每題10分，共60 分）

1、請簡要劃出你所在 IDC 機房的弱電路由圖（包括光纖odf分布，布線弱電橋架分布）。

2、請簡要說明你所在 IDC 機房的設備設施的供電方式和斷電處理方式。

3、簡述下常用網絡命令操作；

（1）檢測機房到“百度網”的網絡連通性；

（2）查看機房到“百度網“的網絡路由，并說出最大延遲和丟包所在 的 IP 地址；

（3）連續 ping 百度網 50 個包，查看丟包率；

4、簡述配置linux環境下，windows環境下，開啟遠程桌面的命令或者步驟；

5、請簡要描述你所在 IDC 機房的機柜單路空開跳閘的處理過程和注意事項。

6、請簡要說明下你所在的IDC機房汛期的重要關注事項及位置。

第三篇：數據中心運維操作標準及流程

數據中心運維操作標準及流程

鄭州向心力通信技術股份有限公司

二零一八年 1 機房運維管理前期準備 1.1 管理目標

機房基礎設施運維團隊應與業主管理層、IT部門、相關業務部門共同討論確定運維管理目標。制定目標時，應綜合考慮機房所支持的應用的可用性要求、機房基礎設施設施的等級、容量等因素。目標宜包括可用性目標、能效目標、可以用服務等級協議（SLA）的形式呈現。不同應用的可用性目標的機房，可設定不同等級的機房基礎設施的運維管理目標。1.2 參與數據中心建設過程

機房運維團隊應充分了解自己將要管理的場地基礎設施。對于新建機房，應盡早參與機房基礎設施的建設過程，以便將運維階段的需求在規劃、設計、建造、安裝和調試等過程中得到充分的考慮；同時為后期做好運維工作打下基礎。1.2.1 應參與規劃設計

機房的規劃設計是一個謹慎和嚴謹的過程，需要所有參與機房建設的相關方共同完成，才能確保規劃和設計的有效性、實用性等要求。其中，基礎設施運維團隊應提出運維要求，從運維經驗、實際運維難度、提高運維可易性等方面對規劃和設計過程進行配合。1.2.2 應參與相關供應商遴選

機房基礎設施運維團隊應參與機房基礎設施設備供應商選擇的全過程，及時地了解各種產品及服務的品牌、型號、規格等關鍵參數，使之更能滿足運維的要求。并就在安裝、調試過程中的注意事項等提出建議，還需要對后續的設備保修等服務提出要求。1.2.3 應參與建造管理

機房的基礎設施運維團隊應積極參與機房基礎設施的建造工作，并協助做好建設項目的項目管理工作，著重關注工程建造中如材料的使用、工序、建造過程等工作，重點關注隱蔽工程的安裝工藝和質量。機房基礎設施運維團隊應充分了解施工過程中的工藝。對于新建數據中心，從施工質量和日后運維方便性出發，盡早發現施工過程的問題，及時糾正，方便日后運維和節省日后整改成本。1.3 測試驗證

機房基礎設施投產前的測試驗證是確保機房基礎設施滿足設計要求和運行要求的關鍵環節。1.3.1 時間和預算

機房的業主應設立測試驗證專項預算，預算應包括外部測試驗證服務提供商的相關費用，以及在測試驗證階段產生的電費、水費、油費等相關費用。應制定測試驗證的工期規劃，以更準確地預測機房基礎設施交付投產的日期。1.3.2 測試驗證參與方

項目建設管理部門可作為測試驗證工作的主體責任單位；運維管理部門可作為測試驗證工作的主體審核單位；第三方測試服務商可作為測試驗證的實施單位及整體組織工作的協調單位。但運維管理部門應要求測試服務商預先提供測試方案，在運維管理部門審核后方可進行。機房基礎設施運維團隊可參與測試驗證工作，在此過程中熟悉設施和設備，可建立相關運維技術文檔庫，為后期的運維工作做好準備。

機房關鍵設備提供商及工程總包商，應積極配合測試驗證工作，應在供應商合同中對此項有明確要求。1.3.3 測試驗證內容

驗證應覆蓋所有關鍵子系統和設備應具備的功能和關鍵的操作程序，確保滿足設計要求，必要時可做故障情景模擬來檢驗。

測試驗證中發現設計或者建設階段的問題，應該在報告中充分體現；可以改造的部分，應要求建設單位進行改造；不能改造或暫時不需改造部分，應作為風險點在運維過程中予以特別的重視，并制定相關預案。

1.3.4 設施健康評估

當接手已在運行的機房基礎設施的運維工作前，運維團隊應對設施的情況進行健康評估，了解潛在風險點，其中能夠改造的部分，應該申請予以優化改造。不能改造的部分，應該作為風險點在運維中予以特別的重視，并制定相關預案。1.4 技術文檔

完整并準確的技術文檔是后期運行、維護、維修、故障診斷、優化改造的基礎。運維團隊在開展運維工作前，應從施工單位得到場地基礎設施的全套相關文檔，包括但不限于：機房的規劃設計資料及竣工圖紙、全套設備的清單及相關操作文檔和保修保養資料、機房自動操作系統的邏輯圖及說明文檔、監控系統的點表、驗收測試文檔、機房所在建筑的建筑設計資料、竣工圖紙。整體文檔應在限定時限內進入運維管理知識庫,并按照質量管理的原理和要求設定文檔的起草、變更、審核、批準、保存、分發等職責權限。1.5 管理邊界

為了明確管理責任，機房基礎設施運維團隊應將可能影響機房基礎設施運維目標達成的外界因素整合成管理邊界報告，提交業主管理層并組織研討，形成明確的決策，制定完整的協調溝通機制及權責界限。這些因素包括但不限于：不歸本部門負責，但可能對于本部門有重大影響的供電、供水、供暖、制冷、消防、安防、監控、運營商線路接入等系統。安全管理和質量管理建議 2.1 人員安全

機房基礎設施運維團隊要編制正式的機房生產環境（工作場所）的安全方針，設定嚴格的安全生產規范；并根據安全方針制定有效的、明確的安全計劃，來教授和培訓安全原則、危險識別、糾正缺陷和控制風險。并加強對于該部分規范的合規度的培訓、考試和審核檢查，以確保機房運維人員的人身安全。相關安全生產規范主要包括：

●機房生產環境安全管理規范； ●機房基礎設施各系統安全管理手冊； ●機房基礎設施涉及安全的應急預案； ●機房基礎設施管理過程涉及的技術方案中的安全管理策略。機房基礎設施中與電氣相關的工作存在著固有危險。設施運維團隊應當創建一份正式電氣安全計劃，以最小化所有工作人員受到電氣傷害的風險，確保現場電氣系統達到相關法規標準。電氣安全計劃中的條款應規定電氣工作人員在有資質和具備合理安全工作流程的前提下才能進行操作，并應利用防護設備和其他控制手段，如上鎖掛牌設備。此計劃的創建旨在防止員工受到電擊、燒傷、電弧和其他潛在電氣安全隱患，同時要求其遵守法規標準。

相關國家、行業規程包括但不限于：

●GB 26860電力安全工作規程 發電廠和變電站電氣部分； ●DL 408 電業安全工作規程。2.2 物理環境安全

應了解周邊社會環境信息，評估潛在的安全風險并制定預案。這些信息宜包含但不限于：周邊交通路況、醫院、供油站、消防站、變電站、供水、供電、供氣、網絡通信線路等。可建立周邊社會環境管理資料庫。

應了解機房所在地的歷史自然災害情況。包含但不限于GB50174 及TIA-942中提到的所有評估機房選址的外部因素，并制定相應的管理預案。

應建立并執行嚴格的機房設備、人員、車輛進出管理制度。應設立不同安全區等級(參考ISO27001信息安全管理中的物理安全控制)并制定訪客管理制度,用以有效管理訪客。2.3 質量管理

在機房基礎設施運維過程中建立完善的質量管理體系，是保障以上機房基礎設施運維趨于卓越的重要因素和手段。機房基礎設施運維團隊的所有關鍵工作應包括以下的質量管理要素： 2.3.1 質量保證

●過程制定； ●程序制定； ●過程審核和批準； ●過程和程序培訓。2.3.2 質量控制

●事件回顧； ●質量檢查和檢驗； ●定期質量審核。2.3.3 質量改進

●故障分析； ●經驗教訓； ●優化及創新計劃。人員管理建議 3.1 組織及人員 3.1.1 組織架構

機房運維團隊應有清晰的組織架構，同時對各崗位有明確的崗位職責說明并在計算機化維護管理系統（CMMS）中實現權責匹配，同步更新。中大型數據中心場地基礎設施運維團隊中除現場負責人外，可按照工作內容分設以下幾個主要職能崗位：

●運維巡檢團隊

主要職責：對基礎設備設施進行巡檢，擔任值班工作，第一時間發現故障或問題，并作為管理程序的執行者。

●技術管理團隊

主要職責：對機房基礎設施提供運維技術支持，解決技術問題，承擔機房基礎設施一般性的優化改造工程的項目管理工作，宜包括電氣、空調、弱電等系統的技術人員。

● 物理環境安全管理團隊

主要職責：對物理環境安全進行管理，進行安全巡檢等工作。3.1.2 人員配制

機房基礎設施運維人員的配備應根據運維管理目標或SLA來確定。中高等級的機房，可按照7X24的運行要求配置運維人員。上崗人員應具備國家要求的相應資格證書。應在運維管理程序中明確規定資質等級與操作權限的一致性。

高等級以及具有一定規模的機房，每個班組應配備具有電力、暖通、弱電專業能力的運維人員，以達到“即時應急響應”的工作狀態。等級相對低的機房，每個班需要至少配備一人，達到“即時報警”的工作狀態。

運維團隊的關鍵崗位應有人員備份和儲備。機房基礎設施運維管理團隊的關鍵管理人員或關鍵崗位人員在正常運維工作開展中應采用A、B 角色配置，日常工作中應注意角色的分配和工作的配合。其它崗位人員宜建立良好的循環機制，人員可進行崗位輪換和交叉培訓，使所有人員掌握全面的基礎知識。3.1.3 績效管理

為了提高機房運維人員的技術技能、職業素養和提倡團隊合作精神，專業地、高效率地運行和維護機房基礎設施，有必要建立人員的關鍵績效指標，定期對所有人員的短期和長期績效進行評估，獎優罰劣，推動整個運維團隊技術和素質的發展和改進。3.1.4 人員管理制度

為了保障機房基礎設施運維團隊的創新性、穩定性、持續性，應通過建立合理的人員管理制度，約束人員的工作態度、行為規范，提高人員的工作熱情、工作效率和執行力，激發人員正面影響，使團隊一直保有活力來共同努力達成服務等級協議的要求，運維團隊應該建立運維人員的各項管理制度。這些管理制度應該主要包含（但不限于）：

●《日常活動管理制度》； ●《人員安全操作制度》；

●《運維人員基本素質養成管理制度》； ●《安全運行獎懲制度》； ●《節能運行獎懲制度》； ●《技術創新獎勵制度》； ●《人員晉升制度》； ●《人才儲備制度》； 3.2 培訓及認證

3.2.1 員工培訓及資格認證計劃

對于機房基礎設施運維團隊新員工應進行完整及嚴格的培訓，以確保其盡快具備崗位需要之知識及能力。培訓內容應包括機房基礎設施的所有系統的工作原理、操作流程、應急預案、以及管理制度等。

對于所有運維人員宜設定以知識更新、技能提高為目標的培訓及認證計劃。宜要求運維人員不斷提升理論知識，以便于在缺乏操作程序的應急狀態下進行正確的處置。

可借助行業第三方專業培訓及職業技能鑒定平臺，積極開展運維人員任職資格的評定工作。3.2.2 歷史事件分析學習

運維團隊應將機房基礎設施歷史事件的總結分析作為培訓的重要素材，進行全員培訓；對于新員工應在上崗前予以培訓，以避免相同的事件再次發生。3.2.3 組織學習

運維團隊管理者應積極參與行業交流，了解行業最佳的運維管理實踐，并從行業故障案例中總結經驗，做好自身整改。3.3 運維外包服務商

3.3.1 基礎設施運維外包服務商的選擇

機房基礎設施屬于關鍵性設施，選擇外包運維團隊時應考察其機房基礎設施的運維服務的資質、能力和經驗。如機房作為商業物業的一部分整體外包運維，應要求外包運維機構針對機房基礎設施設施部分設立專門的有機房基礎設施運維經驗的團隊，并嚴格按機房基礎設施的運維規程規范執行。3.3.2 運維外包服務商的管理

對于外包服務商的員工的管理原則應該參照運維團隊內部員工同等要求，相關人員只有在進行培訓并得到相關的認證后才能從事相關的工作。

外包服務商需要嚴格遵循數機房基礎設施既定的操作流程和安全守則。

機房基礎設施運維管理的最終責任承擔者是機房管理者，責任無法外包。因此，機房應保留運維核心管理人員，對于外包團隊的工作進行審核、監督和績效評估管理。設施管理建議 4.1 資產數據庫

數據中心應建立完整及實時更新的資產數據庫。數據庫應包括所有關鍵基礎設施設備的清單，還應記錄設備設施的運行情況、事件情況、變更情況、維護保養頻次等信息。

資產數據庫應最少包括以下信息： 資產ID：每個資產的唯一標識號

種 類：一級分類（如電氣、制冷、消防系統）子 類：二級分類（如 UPS、電池、PDU等）描 述：資產的文字說明 制 造：資產的制造廠家 型 號：制造廠家的產品型號 規 格：資產的規格或者標稱值 位 置：位置 ID（房間或區域）購 買 人：資產維護的負責人 序 列 號：制造廠家的序列號 安裝日期：資產的投產日期 保修期限：保修到期的日期 更 換：預計的資產更換日期 維護頻次：年檢、季檢、月檢等 4.2 預防性維護 4.2.1 預防性維護計劃

預防性維護是為了延長設備的使用壽命和減少設備故障的概率而進行的有計劃的維護。其目的是通過定期檢查和保養，使設備的某些缺陷或隱患在變得更嚴重之前被發現。

運維團隊應根據系統設備情況與供應商進行溝通，按照供應商的建議提前制定、季度、月度預防性維護計劃。各專業運維人員需按照各設備系統特性、維護流程及規范，及時、完整地落實維護工作，并形成客觀實際的記錄和報告予以存檔。運維團隊還應定期對設備的運行狀態數據進行統計和趨勢量化分析，對于異常的趨勢，做出報警及相關預案。預防性維護包括并不限于以下系統設備或內容： ●冷水機組、精密空調； ●UPS，開關、和發電機組； ●消防系統和監控系統檢驗； ●蓄電池放電測試；

●配電裝置（高低壓配電裝置）的絕緣性定期試驗； ●二次保護定值實驗；

●每年雨季之前進行的數據中心防雷接地裝置測試等。4.2.2 工單管理

運維團隊應建立預防性維護及保養的工單管理系統，工單應列出工作內容、完成相應工作需要的工具及備件、工作預計完成的時間、工作負責人等信息。

計算機化維護管理系統應該對每份工單從產生到完成進行全程的跟蹤。4.3 操作流程

機房基礎設施的所有操作，均應事先制定詳細的操作流程，經過審核后存檔并在后期運行階段嚴格執行。4.3.1 維護作業程序MOP 對機房關鍵基礎設施設備的每次維護、維修、安裝操作，都應事先制定一份MOP。可要求設備供應商提供MOP的建議，但對于MOP最終確認審核的責任在于運維團隊，批準責任在于運維管理團隊。4.3.2 標準操作流程SOP 所有關鍵基礎設施設備在各種情況下都能執行的常用操作都應制定標準操作流程SOP。例如手動啟動發電機組的操作流程，或將UPS轉換到旁路的操作流程等。4.3.3 應急操作流程EOP 應急操作流程適用于有可能發生的嚴重故障情況。以下為部分嚴重故障的例子：

●一路市電供電時中斷； ●雙路市電供電時同時中斷； ●單個精密空調時故障停機； ●全部精密空調都故障停機； ●單臺UPS時故障停機。4.4 工具及備件管理

運維團隊應根據資產分類清單及其分類制定最低備件庫存清單并及時補充備件。

測試分析儀器儀表方面可配備進行電氣性能參數測試、電池測試、接地電阻測試、絕緣性能測試、設備運行溫度測試、風速測試、環境溫度測試、噪音測試等的儀器儀表。儀器儀表應該定期校準。

應制定相關規定對操作工具、儀器儀表實行人員負責制或者交接班負責制等管理制度。備件和工具應定期進行盤點。4.5 供應商管理

應該按照機房基礎設施運維的資質、以往的經驗、業界的口碑等因素，以注重預防性和預測性維護和提高可用性的相同標準來選擇合格的供應商。

所有供應商到達機房執行維護程序之前，應通過機房相關規程的培訓，獲得機房運維團隊和運維管理層的批準。在執行維護活動的過程中要嚴格遵循操作流程。操作時需由運維團隊的人員陪同并監督記錄流程的執行情況。

供應商的每次機房維護活動都應該提交現場服務報告并存檔。運維團隊應該建立供應商的績效評估方案，并定期對供應商進行績效評估。應設立供應商管理文檔，記錄所有供應商的聯系方式、服務承諾（SLA）、工作范圍、針對設施的培訓和認證情況等信息。4.6 生命周期管理

應基于設施設備的合理生命周期，結合風險評估，制定設備維護、升級或更換的計劃及預算，及時報告給運維管理部門。

風險評估主要評估內容包括： ●資產重要性識別； ●資產威脅識別； ●資產脆弱性識別； ●風險值的計算；

●在評估更換設備的方案時，可綜合考慮原有設備的維護費用以及新設備在能效方面的改進，做好綜合投資回報分析；

●對于冗余設備宜設立輪換運行機制，以延長整體設備的生命周期。

4.7 運維管理系統 機房可建立自動化維護管理系統（MMS），集中實現資產管理、維護調度、信息安全、文檔管理、工單管理的職能并記錄所有的運維工作任務及完成情況。運行管理建議 5.1 運行管理制度

機房基礎設施運維團隊應建立并嚴格執行運行管理制度，包括：5.1.1 巡檢相關管理制度

●日常巡視巡檢管理制度； ●值班管理制度； ●交接班管理制度； ●通知矩陣。

5.1.2 工作流程相關管理制度

●工單處理流程； ●例會制度；

●工作總結報告制度（日、周、月、季、年總結報告）；●交付管理規范；

●運維質量管理辦法文檔管理制度； ●工具備件管理制度。5.1.3 安全相關管理制度

●機房出入管理制度； ●機房現場管理制度；

●機房衛生管理制度； ●信息安全相關管理制度。5.1.4 故障處理管理制度

●設備操作管理制度； ●設備故障處理流程； ●應急準備和應急響應流程； ●維護作業計劃管理制度； ●故障隱患跟蹤反饋管理制度； ●緊急事件匯報流程。5.1.5 經營相關管理制度

●員工行為規范； ●考勤管理制度； ●人員管理考核制度。

5.2 設施監控、巡檢、及交接班管理

應配備環境、動力、安防等監控系統以便于運維人員及時了解設施各系統及設備的運行狀態和及時發現異常情況。

應規定相應的運行人員對設施運行狀態的巡視頻次、巡視工作內容及規范。

運行人員交接班時應對當班執行的操作、變更及觀察到的任何異常數據或現象進行交接和簽收。5.3 機房清潔管理

應劃定保潔區域，定期做好機房保潔工作，保證地板及地板下的無塵狀態。重要區域進行保潔工作時應有運維人員現場監督和指導。5.4 標簽標識管理

應建立針對數據中心場地基礎設施設備和物理環境完整的、清晰的標簽標識管理系統。應至少包括：

●設備標識：包括設備名稱、型號、編號、資產編號等； ●線纜標識：包括起始端信息、終止端信息、設備名稱等； ●警示標識：如“設備已帶電/危險”、“禁止合閘”、“禁止分閘”等；

●物理環境標識：如位置標識、區域標識等；

●系統圖展板標識：如電氣、暖通、消防、弱電系統圖展板。這類標識便于運維人員清晰、快捷地掌握區域及整個數據中心系統的配電、制冷、消防、弱電的原理及關鍵點位。5.5 變更管理

任何對于設施運行狀態的變更應進行預先的風險分析，并基于風險等級，設定相應級別的事前審核流程。在變更方案及變更時間窗口確認后，應進行相應范圍的告知。變更結束后，應向相應范圍部門通報變更結果。5.6 事件管理

應制定事件管理流程，明確不同等級事件下相應的處理流程。5.6.1 事件等級定義

一般事件：任何沒有達到機房設計和運行標準的異常事件； 嚴重事件：任何沒有達到機房設計、運行標準的事件，且對提供的服務造成中斷的事件；

重大事件：任何沒有達到機房設計、運行標準的事件，且對提供的服務造成中斷，且影響范圍大的事件。5.6.2 事件升級

當事件暫時無法排除，需要逐級報告，進入事件升級流程。如遇特殊情況，與直接主管聯系不上時，可越級向上一級主管報告。

5.7 應急響應

5.7.1 設施應急預案演練

運維團隊應針對應急操作流程EOP進行定期的演練工作，主要包括：

●沙盤演練：參與演練的運維人員集合，并分別口述在發生緊急情況下自身所應承擔的職責及將會執行的方案及步驟；

●跑位演練：參與演練的人員跑位到模擬故障現場，模擬處理故障，參與人員應清晰地說出故障的處理方案及步驟。

應急演練的演練原則是：盡量接近真實情況，在條件允許的情況下盡量真實地處理故障。在運行中的一些特定場景下也可以進行應急演練，如發電機帶載實驗等。5.7.2 人員安全應急流程

機房基礎設施運維團隊應針對影響運維人員健康的人身事故制定應急流程并定期演練。應急流程可包括設置現場急救包以及聯系當地醫療急救機構的方式等。5.8 容量管理

容量管理可包括但不限于以下方面： 5.8.1 空間容量

●IT設備擺放空間； ●基礎設備設施擺放空間； ●綜合布線線路空間，配線架管理。5.8.2 能力容量

●電力供應容量； ●空調供應容量； ●綜合布線信息點容量； ●互聯網接入容量。

設施運維團隊應與IT 部門定期溝通，動態了解IT需求的預測，并通報設施容量的使用情況。可制定3個月至36個月周期的IT需求及設施可用容量兩者的對比分析表。

當機房基礎設施不能滿足IT增長的需求時，應提前制定并上報擴容或者新建機房的計劃。5.9 能效管理 5.9.1 能效監測

機房基礎設施運維團隊應了解并記錄機房在不同工況及不同外界氣候條件下的電力使用效率 PUE 的變化情況，從中發現趨勢，以不斷優化運行方案。5.9.2 了解IT設備運行特征 機房基礎設施運維人員應具備一定的IT設備相關知識，了解服務器、網絡、存儲等設備的運行特點和功耗情況。還應了解客戶或用戶的業務基本情況，了解IT 設備的運行峰谷期。

應與客戶或用戶相關部門做好溝通，針對高密度IT負載的部署做出預測，并制定相關應對方案。5.9.3 管理氣流組織

應封堵設施建筑所有可能的漏風口，維持設施的正壓。應疏導設施內氣流的流向、封堵所有可能的漏風口、對機柜內所有空閑U位安裝盲板、關閉不必要的出風口、保證冷空氣的最佳使用效率。

5.9.4 運行閾值設定

應基于安全性及運行效率的綜合考慮，建立運行閾值設定指南，設置監控報警閾值、空調回風溫度等。5.10 預算管理

運維團隊應做好運維財務預算，上報主管領導及財務部門，并做好預算必要性的溝通解釋工作。

預算應包括但不限于以下內容： ●基于SLA的人力預算； ●備件及工具、儀器采購費用； ●應急維護材料費用；

●專業外包維保和應急服務費用； ●政策性等強制檢測服務費用； ●整改或節能改造預算； ●突發問題備用金。

第四篇：云數據中心運維問題解析

1、云計算時代的到來，數據中心的運行管理工作必然會產生新的問題，提出新的要求，您認為，數據中心運維工作發生了哪些改變？

云計算是當下的技術熱點，云數據中心是提供云計算服務的核心，是傳統數據中心的升級。

無論是傳統的數據中心，還是云數據中心，從他們的生命周期來看，運維管理都是整個生命周期中歷時最長的一個階段。

云數據中心的運維工作需要我們仔細分析，認真對待。從開源云計算社區openstack發布的模塊來看，截止2014年11月，社區共有項目模塊450個左右，模塊數量前三的類型是“運維”、“易用性”、“上層服務”，其中運維模塊數量第一，占到了153個。可見云計算的技術動向基本上圍繞“如何運維”和“如何使用”。

我們今天的話題就先來說一說云數據中心運維的變化。說到云數據中心運維工作的變化，就要分析云的特點。云時代數據中心最明顯的特點就是虛擬化技術的大量應用，這使得運維管理的對象發生了變化：

一、云數據中心運維對象數量激增。虛擬化技術將1臺物理服務器虛擬為多臺虛擬服務器，如果數據中心支撐業務需求規模不變的話，所需要的物理服務器數量將會減少，這與很多人認為的運維服務器數量激增是不符的，那么這個“激增”認識是如何產生的呢。可以這樣分析，由于虛擬化技術進一步提高了數據中心各種資源的使用效率，同時大幅提高了業務需求響應能力，所以多個傳統數據中心合并為一個云數據中心在技術上成為了可能。很多跨國企業采用云計算技術，實現數據中心10：1到20：1的合并效果，也就是說如果原來在全球建設1000個數據中心，那么現在可以由50到100個云數據中心實現對業務的支撐，在一個合并后的云數據中心內，所要運維的服務器數量絕對可以稱得上“激增”，這里所說的服務器既包括物理服務器也包括虛擬服務器。與此同時，運維崗位也就是運維人員雖然也進行了調整，但是人員增加的幅度遠低于設備的增漲幅度，也就是人均運維設備數量增加了很多，在這種情況下，如果不借助工具、系統，很難完成運維工作。

二、在傳統數據中心中，設備都是物理的、真實的，位置也是相對固定，對業務系統來講，交換網絡、服務器、存儲設備對象之間關聯也是比較固定的，管理起來相對直觀。在云數據中心，虛擬化帶來了資源的池化，使得一切管理對象變成虛擬的、可靈活遷移的邏輯存在。虛擬資源可以隨時創建、刪除，再加上高可用需求、性能優化需求帶來的虛擬資源遷移，虛擬資源所在的位置變得不固定了，虛擬資源與物理資源的關系也被解耦了，原來很多能說得清、找得到的資源現在不借助工具就再也無法說得清、找得到了。

三、在傳統數據中心中，設備監控主要是采集故障、性能數據，容量一般來講還不是運維層面的問題，而是規劃的問題，當然這也帶來了業務系統豎井、數據中心豎井的問題，以及業務資源申請周期長的問題。在云數據中心中，容量不僅是規劃問題，同時也是一個運維問題。也就是說，在日常工作中，需要隨時采集資源池容量數據，不僅要看資源池的總容量，還要看容量在各個物理宿主機上分布情況，以便滿足高可用和遷移的需要。

四、云數據中心在管理虛擬設備時，接口的標準化問題。在傳統數據中心內，物理設備已經形成了接口標準，提供運維數據，如snmp、netflow等。而對虛擬化設備，還沒有形成國標或行標，對虛擬設備的運維還需要采用廠家標準。如果在一個云數據中心中采用了多個廠家的虛擬化系統，運維人員就需要熟悉多個廠家的界面。這個問題的解決，短期來看，需要一個融合的系統，為運維人員屏蔽多廠家虛擬化系統的差異，長期來看，希望能夠形成各廠家虛擬化系統的統一接口標準。

云計算帶來了IT服務成本的降低，提高了應對業務需求的敏捷性，同時，我們也要看到，如果云數據中心運維管理調整不及時，不但運維工作量不減反增，而且運維水平還會降低。

2、當數據中心發展到一定的規模，人們在數據中心管控要求的基礎上，強調了流程化、自動化運維的模式，以便數據中心的運維工作能夠更加快捷高效的開展起來，數據中心步入云時代，對于運維工作的流程化、自動化要求，云管理系統能給用戶帶來哪些價值？ 虛擬化技術是云數據中心的特點，但是云數據中心不僅僅是虛擬化。云數據中心響應業務需求的敏捷性，基于虛擬化，這是云數據中心的技術基礎。

云數據中心以租用的方式向資源用戶提供云服務，包括IaaS、PaaS、SaaS。從運維的角度講，云服務的提供者要如何保障用戶獲得需要的服務呢。

云管理系統保障分配資源給用戶的動作是自動化的，也就是說所有操作完全在線上完成，并且支持批量處理。

在云管理系統中，可創建并保存三個層面的資源模板，分別對應IaaS、PaaS、SaaS三個服務層面。用戶申請某個或某些服務時，云管理系統就會按照相應的模版去創建資源。這是最基本的虛擬資源分配動作。

復雜一些的操作是可配置參數的資源模板，用戶在申請服務時或運維人員在點擊資源創建按鈕前，可以傳遞一些參數給創建程序，如操作系統的用戶名、密碼，那么云管理系統在基于相應模板創建虛擬服務器時，會按照參數設置服務器操作系統管理員的賬號信息。

再復雜一些的自動化動作，是基于模板組合進行的、有順序的、有條件的動作序列，一般用作響應需要多個資源進行部署的業務系統的服務申請，通過一系列操作，為該業務系統分配網絡地址、服務器、存儲空間，并進行相關的配置，可定義動作執行的順序以及后續動作執行的前提條件。對于特別復雜的動作組，允許進一步分割，也就是定義子動作組。

上述三種操作都是線上的、自動化完成的，這樣的好處就是提高效率。云計算的好處之一就是敏捷分配，如果用戶申請后，還要線下做很多配置，就會明顯延長服務交付時間。同時基于模板的自動化操作也減少了人工線下操作的不確定性。

上面說完了運維的自動化，下面再說一下流程化。在云管理系統中，服務流程既包含了ITIL流程，如事件管理、問題管理、變更管理、發布管理等，同時也包含了云服務申請和審批的流程，如服務開通、服務變更、服務終止等。云管理系統還提供流程設計器和表單設計器，方便運維人員修改系統提供的服務流程，或者根據需要新建流程。

3、云時代數據中心最明顯的特點就是虛擬化技術的大量應用，這使得管理的對象也在變化。以前的設備都是真實的，位置也是相對固定，管理起來相對直觀。而應用虛擬化技術的結果是將這些資源進行“池化”，使得一切管理對象變成虛擬的、可遷移的存在，如何幫助用戶面對這種挑戰？

我們在談云數據中心運維變化時，曾經提到過這個問題。在云數據中心，虛擬化帶來了資源的池化，使得管理對象變成虛擬的、可靈活遷移的邏輯存在。運維人員很難再說清楚虛擬資源與物理資源的對應關系。

云管理系統會采集虛擬資源的運行數據，即時掌握資源之間的關系。首先是虛擬資源與物理資源的關聯信息，比如虛擬機運行在哪臺物理機上。其次，虛擬資源與虛擬資源的關系，如某臺虛擬機與哪個虛擬網絡設備的端口連接，某個虛擬磁盤掛載到了哪個虛擬服務器上。第三，物理資源與空間資源的關聯，可以定位資源的實際部署位置。第四，物理資源與物理資源的關聯關系。第三點與第四點與傳統數據中處理方式并無不同。第五，云管理系統，還能夠管理資源與業務系統的關系，以及資源與用戶的關系。

通過云管理系統，運維人員可以即時掌握云數據中心中有哪些資源，資源的運行情況，以及資源之間的鏈接，資源分配給了哪個用戶、哪個業務系統，資源在哪，這個在哪既包括了虛擬資源的分布也包括了物理資源的位置。

可以這么說，云管理系統以服務租用的方式向最終用戶屏蔽了云數據中心內的資源情況，但是運維人員通過云管理系統能夠清清楚楚、明明白白的掌握資源情況，包括虛擬的資源，也包括傳統的資源。

4、目前，云數據中心管理的最大挑戰除了上面提到的流程化、自動化和虛擬化，同時還要實現異構資源的融合管理，在這方面云管理系統是如何滿足的？ 我們在談云數據中心變化時，曾經提到過，如果云數據中心同時存在多個虛擬化系統，由于提供商執行各自的廠家標準，要如何去運維。當時我們提到了“融合”，也就是通過一個統一的管理系統，去融合、去屏蔽多個虛擬化系統的差異。

需要融合的虛擬化系統有很多，有商業產品，也有開源系統，在這我們不一一說明。但這只是虛擬資源范疇的融合，在我們實際的云數據中心運維工程中，我們發現，現階段國內的很多云數據中心并沒有全盤的虛擬化，這種現象在企業云數據中心中尤其普遍。企業中一部分業務系統部署在虛擬環境中，另外一部分業務系統部署在物理環境中，還有一些業務系統，部署環境同時存在物理資源及虛擬資源。

基于這種情況，云管理系統進一步擴大了“融合”的范疇，管理的資源范圍不僅包括虛擬資源，還包括數據中心的物理資源、空間資源、動環資源，這樣就把云數據中心全面地管理起來，既有傳統的，也有虛擬的，而且傳統資源和虛擬資源結合起來管理，使得云數據中心的運維更加的智能。比如，我要分配一個虛擬服務器，如果有動環資源的信息，我不僅可以基于宿主機也就是物理服務器的使用情況做策略，還可以考慮服務器所在區域的電能、冷能信息。

云數據中心是傳統數據中心的升級，那么云數據中心的運維也應該是傳統數據中心的運維升級，不應該缺少原有的運維能力。

5、云數據中心解決了業務系統部署的煙囪問題，通過資源池化及資源自動調度實現了靈活統一的業務部署，但不同的業務系統有其固有的專業性，對網絡、計算、存儲的規格要求各不相同，各個業務系統的服務要求、監控要求、故障處理要求等也存在差異，要做到業務系統的統一部署，又要滿足特定需要，對于云數據中心“求同存異”的挑戰，云管理系統是如何克服的？

云管理系統以服務租用的方式對云服務用戶屏蔽了云數據中心的資源細節。以計算資源舉例，一般情況下，云服務用戶所看到的、分配給自己的服務器CPU配置都是虛擬的，也就是vCPU，他和物理CPU之間并沒有一個統一的對應關系，甲用戶和乙用戶同樣的虛擬服務器配置，可能由于宿主機品牌、型號、虛擬化方式、超配策略等，在計算能力上會有較大差異，當然，云服務提供的成本也會存在差異。這個差異再加上監控、維護等增值服務要求的差異，構成了不同等級的服務水平要求。

云管理系統在資源池劃分方式上支持這種服務水平的差異性管理。云管理系統支持幾種劃分資源池的方式，其中一種就是按資源池等級進行劃分并進行管理。可以定義不同等級的資源池，如金牌、銀牌、銅牌，把物理資源及虛擬資源調度到不同等級的資源池中，用戶、業務系統具有相應等級資源池的配額，在配額內可以申請、使用資源。其實，關于資源劃分等級的做法在傳統數據中心就有，在云數據中心中只是加入了虛擬資源而已。

6、對于數據中心而言，能效的問題為大家所關注，綠色數據中心的話題也一直再提，云管理系統是否能有效幫助云數據中心降低能耗？

虛擬化技術帶來的一個好處就是降低能耗，這是基于虛擬機遷移技術實現的。前提是業務量在某一時間段內下降，物理機資源在這段時間內存在一定比例的空閑。最好是空閑的比例和時間是能夠預見的，一般來講，這個時間是夜晚。在這個相對空閑的周期內，通過遷移虛擬機到值班物理服務器的方式，實現部分物理服務器關機休息，達到省電的目的。

云管理系統同樣采用這種方式，通過一段時間的監控，分析物理機資源空閑情況，包括每臺物理機資源的空閑比例和空閑時間，每臺物理機上運行虛擬機的配置情況，分析最優的虛擬機遷移目的地，最優的值班物理機“人選”，做到既省電，又不會因為部分服務器“休息”影響業務的性能。

第五篇：大型網站運維探討和心得分享

大型網站運維探討和心得分享

看到一篇不錯的心得體會；相信我們做技術的都會有或多或少的擔憂自己的未來職業發展，下面和大家一起來探討一下。

一、什么是大型網站運維?

首先明確一下，全文所講的”運維“是指：大型網站運維，與其它運維的區別還是蠻大的；然后我們再對大型網站與小型網站進行范圍定義，此定義主要從運維復雜性角度考慮，如網站規范、知名度、服務器量級、pv量等考慮，其它因素不是重點；因此，我們先定義服務器規模大于1000臺，pv每天至少上億（至少國內排名前10），如sina、baidu、QQ，51.com等等；其它小型網站可能沒有真正意義上的運維工程師，這與網站規范不夠和成本因素有關，更多的是集合網絡、系統、開發工作于一身的“復合性人才”，就如有些公司把一些合同采購都納入了運維職責范圍，還有如IDC網絡規劃也納入運維職責。所以，非常重要一定需要明白：運維對其它關聯工種必須非常了解熟悉：網絡、系統、系統開發、存儲，安全,DB等；我在這里所講的運維工程師就是指專職運維工程師。我們再來說說一般產品的“出生”流程：

1、首先公司管理層給出指導思想，PM定位市場需求（或copy成熟應用）進行調研、分析、最終給出詳細設計。

2、架構師根據產品設計的需求，如pv大小預估、服務器規模、應用架構等因素完成網絡規劃,架構設計等（基本上對網絡變動不大，除非大項目）

3、開發工程師將設計code實現出來、測試工程師對應用進行測試。

4、好，到運維工程師出馬了，首先明確一點不是說前三步就與運維工作無關了，恰恰相反，前三步與運維關系很大：應用的前期架構設計、軟/硬件資源評估申請采購、應用設計性能隱患及評估、IDC、服務性能安全調優、服務器系統級優化（與特定應用有關）等都需運維全程參與，并主導整個應用上線項目；運維工程師負責產品服務器上架準備工作，服務器系統安裝、網絡、IP、通用工具集安裝。運維工程師還需要對上線的應用系統架構是否合理、是否具備可擴展性、及安全隱患等因素負責，并負責最后將產品（程序）、網絡、系統三者進行拼接并最優化的組合在一起，最終完成產品上線提供用戶使用，并周而復使：需求->開發（升級）->測試->上線（性能、安全問題等之前預估外的問題隨之慢慢就全出來了）在這里提一點：網站開發模式與傳統軟件開發完全不一樣，網站一天開發上線1~5個升級版本是家常便飯，用戶體驗為王嘛，如果某個線上問題像M$需要1年解決，用戶早跑光了；應用上線后，運維工作才剛開始，具體工作可能包括：升級版本上線工作、服務監控、應用狀態統計、日常服務狀態巡檢、突發故障處理、服務日常變更調整、集群管理、服務性能評估優化、數據庫管理優化、隨著應用PV增減進行應用架構的伸縮、安全、運維開發工作： a、盡量將日常機械性手工工作通過工具實現（如服務監控、應用狀態統計、服務上線等等），提高效率。

b、解決現實中服務存在的問題，如高可靠性、可擴展性問題等。

c、大規模集群管理工具的開發，如1萬臺機器如何在1分鐘內完成密碼修改、或運行指定任務？2000臺服務器如何快速安裝操作系統？各分布式IDC、存儲集群中數PT級的數據如何快速的存儲、共享、分析？等一系列挑戰都需運維工程師的努力。在此說明一下其它配合工種情況，在整個項目中，前端應用對于網絡/系統工程師來說是黑匣子，同時開發工程師職責只是負責完成應用的功能性開發，并對應用本身性能、安全性等應用本身負責，它不負責或關心網絡/系統架構方面事宜，當然軟/硬件采購人員等事業部其它同事也不會關心這些問題，各司其職，但項目的核心是運維工程師~！所有其它部門的橋梁。

上面說了很多，我想大家應該對運維有一些概念了，在此打個比方吧，如果我們是一輛高速行駛在高速公路上的汽車，那運維工程師就是司機兼維修工，這個司機不簡單，有時需要在高速行駛過程中換輪胎、并根據道路情況換檔位、當汽車速度越來越快，汽車本身不能滿足高速度時對汽車性能調優或零件升級、高速行進中解決汽車故障及性能問題、時刻關注前方安全問題，并先知先覺的采取規避手段。這就是運維工作~！

最后說一下運維工程師的職責：”確保線上穩定“，看似簡單，但實屬不容易，運維工程師必須在諸多不利因素中進行權衡：新產品模式對現有架構及技術的沖擊、產品高頻度的升級帶來的線上BUG隱患、運維自動化管理承度不高導致的人為失誤、IT行業追求的高效率導致流程執行上的缺失、用戶增漲帶來的性能及架構上的壓力、IT行業寬松的技術管理文化、創新風險、互聯網安全性問題等因素，都會是網站穩定的大敵，運維工程師必須把控好這最后一關，需具體高度的責任感、原則性及協調能力，如果能做到各因素的最佳平衡，那就是一名優秀的運維工程師了。

另外在此聊點題外話，我在這里看到有很多人要sina、QQ、baidu,51.com等聊自已的運維方面的經驗，其實這對于它們有點免為其難：

a、各公司自已網絡架構、規模、或多或少還算是公司的核心秘密，要保密，另外，對于大家所熟知的通用軟件、架構，由于很多公司會根據自已實際業務需要，同時因為原版性能、安全性、已知bug、功能等原因，進行過二次開發（如apache,php,mysql），操作系統內核也會根據不同業務類型進行定制的，如某些應用屬于運算型、某些是高IO型、或大存儲大內存型。根據這些特點進行內核優化定制，如sina就在memcache上進行過二次開發，搞出了一個MemcacheDB，具體做得如何我們不談，但開源了，是值得稱贊的，國內公司對于開源基本上是索取，沒有貢獻；另外，服務器也不是大家所熟知的型號，根據業務特點，大部份都是找DELL/HP/ibm進行過定制；另外，在分布式儲存方面都有自已解決方案，要不就是使用現成開源hadoop等解決方案，或自已開發。但90%都是借鑒googleGFS的思想:分布式存儲、計算、大表。

b、各公司業務方向不一樣，會導致運維模式或方法都不一樣，如51.com和baidu運維肯定區別很大，因為他們業務模式決定了其架構、服務器量級、IDC分布、網絡結構、通用技術都會不一樣，主打新聞門戶的sina與主打sns的51.com運維模式差異就非常大,甚至職責都不大一樣；但有一點，通用技術及大致架構上都大同小異，大家不要太神化，更多的公司只是玩壘積木的游戲罷了，沒什么技術含量。

c、如上面所講，目前大型網站運維還處于幼年時期理念和經驗都比較零散，沒有成熟的知識體系，可能具體什么是運維，大家都要先思索一番，或壓根沒想過，真正討論也只是運維工作的冰山一角，局限于具體技術細節，或某某著名網站大的框架，真正運維體系化東西沒有，這也許是目前網上運維相關資料比較少的原故吧。或者也是國內運維人員比較難招，比較牛的運維工程師比較少見的原因之一吧。

二、運維工作師需要什么樣的技能及素質

做為一名運維工程師需要什么樣的技能及素質呢，首先說說技能吧，如大家上面所看到，運維是一個集多IT工種技能與一身的崗位，對系統->網絡->存儲->協議->需求->開發->測試->安全等各環節都需要了解一些，但對于某些環節需熟悉甚至精通，如系統(基本操作系統的熟悉使用,*nix,windows..)、協議、系統開發(日常很重要的工作是自動運維化相關開發、大規模集群工具開發、管理）、通用應用（如lvs、ha、webserver、db、中間件、存儲等）、網絡,IDC拓樸架構； 技能方面總結以下幾點：

1、開發能力，這點非常重要，因為運維工具都需要自已開發，開發語言：c/c++（必備其中之一）、perl、python、php（其中之一）、shell（awk,sed,expect….等），需要有過實際開發經驗，否則工作會非常痛苦。

2、通用應用方面需要了解：操作系統（目前國內主要是linux、bsd）、webserver相關(nginx,apahe,php,lighttpd,java。。)、數據庫(mysql,oralce)、其它雜七八拉的東東。。系統優化，高可靠性。。這些只是加分項，不需必備，可以邊工作邊慢慢學，這些東西都不難。當然在運維中，有些是有分工偏重點不一樣。

3、系統、網絡、安全，存儲，CDN，DB等需要相當了解，知道其相關原理。個人素質方面：

1、溝通能力、團隊協作：運維工作跨部門、跨工種工作很多，需善于溝通、并且團隊協作能力要強；這應該是現代企業的基本素質要求了，不多說。

2、工作中需膽大心細：膽大才能創新、不走尋常路，特別對于運維這種新的工種，更需創新才能促進發展；心細，運維工程師是網站admin,最高線上權限者，一不小心就會遺憾終生或打入十八層地獄。

3、主動性、執行力、精力旺盛、抗壓能力強：由于IT行業的特性，變化快；往往計劃趕不上變化，運維工作就更突出了，比如國內各大公司服務器往往是全國各地，哪里便宜性價比高，就那往搬，進行大規模服務遷移（牽扯的服務器成百上千臺），這是一個非常頭痛的問題；往往時間非常緊迫，如限1周內完成，這種情況下，運維工程師的主動性及執行力就有很高的要求了：計劃、方案、服務無縫遷移、機器搬遷上架、環境準備、安全評估、性能評估、基建、各關聯部門扯皮,7X24小緊急事故響應等。

4、其它就是一些基本素質了：頭腦要靈光、邏輯思維能力強、為人謙虛穩重、親和力、樂于助人、有大局觀。

5、最后一點，做網站運維需要有探索創新精神，通過創新型思維解決現實中的問題，因為這是一個處于幼年的職業（國外也一樣，但比國內起步早點），沒有成熟體系或方法論可以借鑒，只能靠大家自已摸索努力。

三、怎樣才算是一個合格的運維工程師

1、保證服務達到要求的線上標準，如99.9%；保證線上穩定，這是運維工程師的基本責職所在。

2、不斷的提升應用的可靠性與健壯性、性能優化、安全提升；這方面非常考驗主動性、和創新思維。

3、網站各層面監控、統計的覆蓋度，軟件、硬件、運行狀態，能監控的都需要監控統計，避免監控死角、并能實時了解應用的運轉情況。

4、通過創新思維解決運維效率問題；目前各公司大部份運維主要工作還是依賴人工操作干預，需要盡可能的解放雙手。

5、運維知識的積累與沉淀、文檔的完備性，運維是一個經驗性非常強的崗位，好的經驗與陷阱都需積累下來，避免重復性范錯。

6、計劃性和執行力；工作有計劃，計劃后想法設法達到目標，不找借口。

7、自動化運維；能對日常機械化工作進行提煉、設計并開發成工具、系統，能讓系統自動完成的盡量依靠系統；讓大家更多的時間用于思考、創新思維、做自已喜歡的事情。以上只是技術上的一些層面，當然個人意識也是很重要的。

四、運維職業的迷惘、現狀與發展前景

運維崗位不像其它崗位，如研發工程師、測試工程師等，有非常明確的職責定位及職業規劃，比較有職業認同感與成就感；而運維工作可能給人的感覺是哪方面都了解一些，但又都比上專職工程師更精通、感覺平時被關注度比較低（除非線上出現故障），慢慢的大家就會迷惘，對職業發展產生困惑,為什么會有這種現象呢？除了職業本身特點外，主要還是因為對運維了解不深入、做得不深入導致；其實這個問題其它崗位也會出現，但我發現運維更典型，更容易出現這個問題；

針對這個問題我談一下網站運維的現狀及發展前景（也在思考中，可能不太深入全面，也請大家斧正補充）運維現狀：

1、處于剛起步的初級階段，各大公司有此專職，但重視或重要承度不高，可替代性強；小公司更多是由其它崗位來兼顧做這一塊工作，沒有專職，也不可能做得深入

2、技術層次比較低；主要處于技術探索、積累階段，沒有型成體系化的理念、技術。

3、體力勞動偏大；這個問題主要與第二點有關系，很多事情還是依靠人力進行，沒有完成好的提練，對于大規模集群沒有成熟的自動化管理方法，在此說明一下，大規模集群與運維工作是息息相關的如果只是百十來臺機器，那就沒有運維太大的生存空間了。

4、優秀運維人才的極度缺乏；目前各大公司基本上都靠自已培養，這個現狀導致行業內運維人才的流動性非常低，非常多好的技術都局限在各大公司內部，如google50萬臺機器科學的管理,或者國內互聯公司top10的一些運維經驗，這些經驗是非常有價值的東西并決定了一個公司的核心競爭力；這些問題進而導致業內先進運維技術的流通、貫通、與借簽，并最終將限制了運維發展。

5、很多優秀的運維經驗都掌握在大公司手中；這不在于公司的技術實力，而在于大公司的技術規模、海量PV、硬件規模足夠大，如baidu可怕的流量、51.com海量數據~~~~這些因素決定了他們遇到的問題都是其它中/小公司還沒有遇到的，或即將遇到。但大公司可能已有很好的解決方案或系統。發展前景：

1、從行業角度來看，隨著中國互聯網的高速發展（目前中國網民已躍升為全球第一）、網站規模越來越來大、架構越來越復雜；對專職網站運維工程師、網站架構師的要求會越來越急迫,特別是對有經驗的優秀運維人才需求量大，而且是越老越值錢；目前國內基本上都是選擇畢業生培養（限于大公司），培養成本高，而且沒有經驗人才加入會導致公司技術更新緩慢、影響公司的技術發展；當然，畢業生也有好處：白紙一張，可塑性強，比較認同并容易融入企業文化。

2、從個人角度，運維工程師技術含量及要求會越來越高，同時也是對公司應用、架構最了解最熟悉的人、越來越得到重視。

3、網站運維將成為一個融合多學科（網絡、系統、開發、安全、應用架構、存儲等）的綜合性技術崗位，給大家提供一個很好的個人能力與技術廣度的發展空間。

4、運維工作的相關經驗將會變得非常重要，而且也將成為個人的核心競爭力，具備很好的各層面問題的解決能力及方案提供、全局思考能力等。

5、特長發控和興趣的培養；由于運維崗位所接觸的知識面非常廣闊，更容易培養或發揮出個人某些方面的特長或愛好，如內核、網絡、開發、數據庫等方面，可以做得非常深入精通、成為這方面的專家。

6、如果真要以后不想做運維了，轉到其它崗位也比較容易，不會有太大的局限性。當然了，你得真正用心去做。

7、技術發展方向、網站/系統架構師。

五、運維關鍵技術點解剖

1、大規模集群管理問題

首先我們先要明確集群的概念，集群不是泛指各功能服務器的總合，而是指為了達到某一目的或功能的服務器、硬盤資源的整合（機器數大于兩臺），對于應用來說它就是一個整體，目前常規集群可分為：高可用性集群（HA），負載均衡集群（如lvs），分布式儲、計算存儲集群（DFS，如googlegfs,yahoohadoop），特定應用集群（某一特定功能服務器組合、如db、cache層等），目前互聯網行業主要基于這四種類型；對于前兩種類似，如果業務簡單、應用上post操作比較少，可以簡單的采用四層交換機解決（如f5），達到服務高可用/負責均衡的作用，對于資源緊張的公司也有一些開源解決辦法如lvs+ha,非常靈活；對于后兩種，那就考驗公司技術實力及應用特點了，第三種DFS主要應用于海量數據應用上，如郵件、搜索等應用，特別是搜索要求就更高了，除了簡單海量存儲，還包括數據挖掘、用戶行為分析；如google、yahoo就能保存分析近一年的用戶記錄數據，而baidu應該少于30天、soguo就更少了。。這些對于搜索準備性、及用戶體驗是至關重要的。接下來，我們再談談如何科學的管理集群，有以下關鍵幾點： I、監控

主要包括故障監控和性能、流量、負載等狀態監控，這些監控關系到集群的健康運行，及潛在問題的及時發現與干預；

a、服務故障、狀態監控：主要是對服務器自身、上層應用、關聯服務數據交互監控；例如針對前端webserver，我們就可以有很多種類型的監控，包括應用端口狀態監控，便于及時發現服務器或應用本身是否crash、通過icmp包探測服務器健康狀態，更上層可能還包括應用各頻道業務的監控，常用方法是采用面業特征碼進行判斷，或對重點頁面進行簽名，以網站被黑篡改（報警、并自動恢復被篡改數據）等等，這些只是一部份，還有N多監控方式，依應用特點而定，還有一些問題需解決，如集群過大，如何高性能的進行監控也是一個現實問題。

b、其它就是集群狀態類的監控或統計，為我們合理管理調優集群提供數據參考、包括服務瓶頸、性能問題、異常流量、攻擊等問題。II、故障管理 a、硬件故障問題；對于成百上千或上萬機器的N多集群，服務器死機、硬件故障概率是非常大的，幾乎每時每刻都有服務硬件問題，死機、硬盤損壞、電源、內存、交換機。針對這種情況，我們在設計網站架構時需要充分考慮到這些問題，并將其視為常態；更多的依靠應用的冗余機制來規避這種風險，但給系統工程師足夠寬裕的處理時間。（如google不是號稱同時死800臺機器，服務不會受到任何影響嗎）；這就是考驗運維工程師及網站架構師功能的地方了，好的設計能達到google所描述自恢復能力，如gfs，糟糕的設計那就是一臺服務器的死機可能會造成大面積服務的連鎖故障反映，直接對用戶拒絕響應。

b、應用故障問題；可能是某一bug被觸發、或某一性能閥值被超越、攻擊等情況不一而定，但重要的一點，是要有對這些問題的預防性措施，不能想當然，它不會出問題，如真出問題了，如何應對?這需要運維工程師平時做足功夫，包括應急響應速度、故障處理的科學性、備用方案的有效等。III、自動化

自動化：簡而言之，就是將我們日常手動進行的一些工作通過工具，系統自動來完成，解放我們的雙手及枯燥的重復性勞動，例如：沒有工具前，我們安裝系統需要一臺一臺裸機安裝，如2000臺，可能需要10人/10天，搞爛N張光盤，人力成本更大。。而現在通過自動化工具，只需幾個簡單命令就能搞定、還有如機器人類程序，自動完成以往每天人工干預的工作，使其自動完成、匯報結果，并具備一定的專家系統能力，能做一些簡單的是/非判斷、優化選擇等。。這些好處非常明顯不再多說。。應該說，自動化運維是運維工程師職業化的一個追求，利已利公，雖然這是一個異常艱巨的任務：不斷變更的業務、不規范化的應用設計、開發模式、網絡架構變更、IDC變更、規范變動等因素，都可能會對現有自動化系統產生影響，所以需要模塊化、接口化、變因參數化等因此，自動化相關工作，是運維工程師的核心重點工作之一，也是價值的體現。

2、運維中關鍵技術點解剖（比較實際，現實中的案例，今天先想出這幾條，如大家有其它感覺興趣的，可以提出，一起交流～）

1、大量高并發網站的設計方案

2、高可靠、高可伸縮性網絡架構設計

3、網站安全問題，如何避免被黑？

4、南北互聯問題,動態CDN解決方案

5、海量數據存儲架構