產品運維怎麼搞

A. 如何做好第三方運維管理

不管是企事業單位自己聘請第三方來做運維管理，還是IT公司自己承接的第三方運維管理，如何做好作為第三方角色的運維管理呢？建議如下幾個方面來考量：

1、重中之重，先上一個IT服務管理平台，引入服務台概念，將需求方和服務方有效連接，提供提交問題工單的入口和問題解決流程的透明化，讓發出問題需求的人和解決問題的部門，都能對每一個問題的解決過程清晰、明了。當然，這里需要一個簡便、周到的IT服務流程平台，個人推薦豪越的運維服務產品。

2、打好基礎建設工作。信息化基礎工作要是沒做好，那永遠是一團亂麻、問題不斷、網路不暢通、問題頻發。信息化基礎工作很多，也不是一朝一夕就能搭建好，可以根據需求，分批次逐步落實，逐步建設。
3、引入運維管理平台。以網路性能數據採集和故障監控為主要功能點的運維管理平台，是現今各行各業信息化管理工作的必備工具。有個趁手的管理工具，相信運維工作效率、工作成果，都會和以前截然不同。
4、做好運維管理制度和運維工作流程建設。有據可依、有章可循，制度是每一個管理工作的基石。基於制度建設，再深化運維工作流程，梳理職責和分工，相信第三方運維工作也一樣井井有條，起到很好的推進促進作用。

B. 運維項目管理流程

運維項目管理流程

導語：沒有任何一個項目能輕而易舉的成功。但是你卻可以努力去爭取更大的成功率，靠的便是精心設計、並且行之有效的流程管理。下面我為你整理的運維項目管理流程，希望對你有所幫助！

1、生命周期與方法論

這是項目的紀律，為項目開展劃出了清晰的界限，以保證項目進程。生命周期主要是協調相關項目，而方法論為項目進程提供了持續穩定的方式方法。

生命周期通常由項目的階段組成（包括：開始、規劃、執行/控制、完成），或由工作的重復周期構成。項目生命周期的細節一般都會隨具體業務、項目、客戶要求而改變。因此即使在同一個項目中，周期也會有多種可能的變化。對工作細致度、文件管理、項目交付、項目溝通的要求體現在生命周期標准和考核的方方面面。大項目的階段一般更多更長，而小項目的階段少，考核點也少。

與生命周期類似，項目方法也因項目而易，細節關注程度高。產品開發項目的方法經常涉及使用何種工具或系統，以及如何使用。信息技術項目的方法包括版本控制標准、技術文檔管理、系統開發的各個方面。

項目方法往往不是由項目團隊自行確定，而由公司為所有項目設定。採用與否，其實項目團隊沒有太多選擇。公司管理層設定的方法本身代表權威，也是你作為項目領導獲得項目控制權的一個途徑。考慮項目方法某方面的作用時，始終要把握其對項目人員管理的效率，即在可能出現問題的地方爭取正面效應。

2、項目定義

清晰的項目描述決定了你的項目控制能力，因為接下來所有工作都在描述范疇之內。不管你如何並為何要進行描述，你要對你的項目進行書面定義，讓項目各方和項目組隨時參考。

項目定義的形式和名稱各式各樣，包括：項目章程、提案、項目數據表、工作報告書、項目細則。這些名稱的共同點在於，項目主管方和其他相關各方面從上而下地傳達了他們對項目的期待。清晰的項目定義還包括以下方面：

項目目標陳述 （一小段文字，對項目交付成果、工期、預期成本或人力進行高層次的描述）

項目回報（包括商業案例或投資分析的回報）

使用中的信息或客戶需求

對項目范圍進行定義，列出所有預期的項目成果

成本和時間預算目標

重大困難和假設

描述該項目對其他項目的依賴

高風險、所需的新技術、項目中的重大問題

努力將盡可能多的具體信息，囊括在項目描述或章程中，並使其在項目主管方和相關方面獲得認可，進而生效。

3、合同與采購管理

不管你在你的組織內有多大的影響力和權力，你對受雇於其他公司的項目成員的影響會比較小。雖然不一定普遍適用，但你可以盡量不將項目工作外包，這是提高項目控制力的一個技巧。

在考慮啟用合同商或外部顧問之前，對整體采購流程進行重檢。尋找有服務合同起草經驗並可以幫助你的人。

建立成功的外包關系需要時間和精力，這些工作要及早著手。為了不誤項目工期，你要及時做到所有細節到位，所有合同及時簽訂。你打算外包哪部分項目交付成果，對這部分工作的細化就是你實施項目控制的著手點。記錄這些細化內容、評估和接收標准、所有相關要求、必要時間規劃。項目定義信息一定要包括在合同之內，相關責任及早確定。和所有你考慮到的供應商討論這些要求，這樣你的項目期望才會在各方之間明晰。

4、項目規劃、執行、跟蹤

作為項目領導，通過制定有力的規劃、跟蹤、執行流程，你可以建立項目控制的基礎。爭取各方面的.支持，進而在項目內全面推廣。

讓項目組成員參與規劃和跟蹤活動，這可以爭取大家的支持並提高積極性。睿智的項目領導往往大范圍地鼓勵參與，並通過流程匯聚大家的力量。當大家看到自己的努力以及對項目的貢獻被肯定的時候，項目很快就從「他們的項目」變成「我們的項目」。當項目成員視項目工作為己任的時候，項目控制就會簡單得多。較之於漠不關心的團隊，此時的項目管理成功幾率更大。運用項目管理流程也會鼓勵項目成員的合作，這也讓你的項目控制工作更加輕松。

5、變化管理

技術性項目中問題最集中的方面就是缺少對具體變化的管理控制。要解決這個問題，需要在項目的各方面啟用有效的變化管理流程。

解決方法可以很簡單，例如被項目團隊、項目主辦方、相關方認可的流程圖。這提醒了項目人員，變化在被接受之前會進行細致地考察，並且提高了變化提案的門檻。

審查變化提案的時候，要注意該提案是否對變化有清晰到位的描述。如果變化提案的動因描述得不清不楚，該提案就要打回去，並且要求對變化所帶來的益處進行定量評估。對於那些僅局限於技術解決方案的變化提案，要多打幾個問號，因為提案人也許不能全面地判斷問題。如果變化提案過多地關注問題的解決，而不注重實際問題，打回去並要求關注具體的業務形勢。

最後，如果不接受某變化提案，一定要做到有理有據。而且，對項目時間、成本、精力等其他相關因素所受的影響，進行合理的估計。

6、風險管理

風險管理的流程能讓你制定出全面的規劃，找出潛在的麻煩，就風險問題的解決方法達成一致，根除嚴重的問題。

風險管理要做到事半功倍，就要與項目規劃同時進行。進行項目工作分解安排時，注意對項目活動的不恰當理解；分配項目任務和開展評估時，尋找風險；資源匱乏或項目資源不足，或項目工作依賴於某一個人時，要知道風險的存在。分析項目工作將遇到的困難，鼓勵所有參與規劃的人在規劃過程中，設想最壞的情況和潛在困難。

7、質量管理

質量管理提供了另一套搭建項目結構的流程，保證項目領導提出的工作要求一個不落地執行到位。項目質量的標准分兩類：行業內實行的全球質量標准，公司或項目獨有的質量標准。

如果你的公司實行或接受了質量標准，要注意該標准對你和你的團隊有何要求。具體而言，這些標准會包括ISO 9000標准或六西格瑪。進而確定質檢清單、質控流程及相關要求，並將其與你的項目規劃進行整合。項目必須遵守的書面步驟、報告、評估，對團隊成員是強有力的推動，讓大家步調一致。標准比你的臨時要求更有效。

質量管理流程還能將項目要求與客戶心聲聯系起來。不管你說什麼，只要是在傳遞客戶或用戶的要求，你都要加以強調。市場調查、標桿分析、客戶訪談都是評估和記錄用戶需求並確定項目要求價值的好工具。

8、問題管理

項目開展過程中問題的出現不可避免。在項目初期，在資源、工期、優先事項等其他方面為項目的問題管理確定流程。爭取讓團隊支持及時發現、跟蹤、解決問題的流程規定。建立跟蹤流程，記錄當前問題。問題記錄信息包括：問題描述、問題特徵或表現（用於溝通）、開始時間、責任人、目前狀態、預計結束時間。

處理待解決問題的流程很簡單，包括列出新問題的流程、定期復查待解決的問題、處理老問題的方法。對於沒有太多組織管理權的項目領導而言，問題跟蹤流程的力量在於讓其把握了問題狀態和進度的實時信息。一旦問題責任人承諾了問題解決的時限，你可以任意公布問題解決過程中的變數。不管問題責任人是本項目成員，還是其他項目或部門的成員，誰都不樂意隨時將自己的大名置於人們質疑的目光中。問題清單的公開使得掌握該清單的人獲得一定的影響力和控制力。

9、決策

項目管理時時有決策，快速得當的決策對於項目控制至關重要。即使項目領導掌握了控制權，完善的集體決策流程仍然裨益頗多，因為共同決策能獲得更多內部支持，效果自然會更好。

項目工作中的決策絕非易事，項目組內紛繁復雜的觀點讓決策更加困難。項目各方認同的問題解決流程可以簡化決策的過程，照顧各方要求。

盡早和你的項目組一起設立決策流程，或採用現有流程，或對現有流程做適當的修改。好的決策流程能為你的項目控制提供強有力的支持。該流程應該包括以下步驟：

清楚地陳述必須解決的問題。

吸納所有需要參與決策或將會受該決策影響的成員參與決策過程，這樣可以爭取團隊支持。

與項目組一道重審項目陳述，必要時進行修正，讓每位成員獲得一致認識。

針對決策標准（如：成本、時間、有效性、完整性、可行性），開展頭腦風暴或討論。選擇那些與計劃目標關聯的、可執行、可供項目各方參考供決策之用的標准。

與項目組一道確定各標準的權重（所有標準的權重總和為100個百分點）。

設定決策的時限，規定用於調查、分析、討論、最終決策的時間。

開展頭腦風暴，在規定時間內盡可能多地產生決策想法。多方發展整個項目組都能接受的想法。

通過集體投票的方法進行篩選，至多確定六個考慮項進行具體分析。分析其與決策標準的契合度。

理性對待討論中出現的異議。有必要的話，可增加決策標准。

根據評估和權重標准，將這些選項進行排序。

考慮採用首位選項的結果。如果沒有異議，則結束討論並開始實施決策。

將決策寫入文件，並與團隊成員及項目相關方面溝通決策結果。

10、信息管理

這項是非常關鍵的資源，如何管理值得仔細思考。有的項目使用網站和網路伺服器，或信息管理系統，進行項目重要信息的存儲。有的項目則使用群件來維護項目文件，並提供電子郵件等服務。

不管你用何種方式存儲項目數據，要保證所有項目成員能隨時獲得所需信息。將最新的項目文件存儲在方便查找的位置，進行清楚地標記，及時刪除過時信息。

C. 什麼是運維運維工作具體要做什麼

運維（Operation and maintenance）一般是指對大型組織已經建立好的網路軟硬體的維護，其中傳統的運維是指信息技術運維（IT運維）。
所謂IT運維管理，是指單位 IT 部門採用相關的方法、手段、技術、制度、流程和文檔 等，對IT 運行環境（如軟硬體環境、網路環境等）、IT 業務系統和 IT 運維人員進行的綜合管理。
隨著信息化進程的推進，運維管理將覆蓋對整個組織運行，進行支持的管理信息系統涵蓋的所有內容，除了傳統的IT運維，還拓展了業務運維和日常管理運維。
其參與的對象也從IT部門和人員，拓展到組織的管理層和各部門，及其相關的業務骨幹。運維的最終結果是對軟體運行中各種性能的維護。
運維工程師從工作方式上分為幾大類：
1，運維工程師/運維開發工程師：
負責具體的產品線運維工作，同時也需要掌握開發的能力，深入業務，最了解業務的痛點和問題，同時研發/優化針對產品業務需求的平台、工具和手段，能夠接觸到各類優秀的系統架構並有能力做出優劣對比，同時對業務的掌控決定了相應運維工程師在業務發展中的作用。長遠發展是成為大型系統的架構師。
2，運維平台研發工程師：
專門研發運維相關通用平台和技術，需要有一定的產品線運維經驗或從產品線中拿到運維需求。對研發能力有較高的要求，對系統的設計有較嚴格的標准，並且能夠理解用戶需求，做出適合服務運維和滿足運維工程師使用體驗的運維產品，長遠的發展是成為各個技術縱向領域的技術專家。
3，資料庫研發工程師/資料庫工程師：
資料庫方向是運維技術中較為特殊的一個方向，由於業務的重要性通常需要專設崗位，業界在該方向也有深厚的研究和積累。主要方向有資料庫內核、雲資料庫等，長遠發展是資料庫領域的技術專家，資料庫架構師。
4，運維經理：
運維同學做事情的過程中通常需要協調多個RD和QA同學，對協調和推進能力要求比較高，對一些技術深度還不錯，協調和推進能力比較高的同學非常適合轉型管理職位，長遠的發展和技術部門的管理職位一樣目標是CTO、CEO。

D. 運維是做什麼的

運維，一般專指互聯網運維，是互聯網企業的技術部門之一；對網路、伺服器、服務的生命周期各個階段進行運營和維護，使公司在成本、穩定性、效率上達到一定的平衡狀態。

互聯網運維工作，以服務為中心，以穩定、安全、高效為三個基本點，確保公司的互聯網業務能夠 7×24 小時為用戶提供高質量的服務。運維人員對公司互聯網業務所依賴的基礎設施、基礎服務、線上業務進行穩定性加強，進行日常巡檢發現服務可能存在的隱患，對整體架構進行優化以屏蔽常見的運行故障，多數據中接入提高業務的容災能力。通過監控、日誌分析等技術手段，及時發現和響應服務故障，減少服務中斷的時間，使公司的互聯網業務符合預期的可用性要求，持續穩定地為用戶提供服務。在安全方面，運維人員需要關注業務運行所涉及的各個層面，確保用戶能夠安全、完整地訪問在線業務。

想了解更多有關運維的詳情，推薦選擇【達內教育】。該機構具有豐厚的師資力量，優秀的教學體系，教學質量突出，實戰講師，經驗豐富，理論知識+學習思維+實戰操作，打造完整學習閉環。該機構獨創TTS8.0教學系統，並設有企業雙選會。達內的OMO教學模式，全新升級，線上線下交互學習，直播學，隨時學，隨時問，反復學，學習安排更便捷。→感興趣的話點擊此處，免費學習一下

E. 做運維都幹些什麼

運維的核心工作其實就是為了維護IT設備和系統的穩定，甭管硬體、網路、安全什麼的，無論黑貓白貓抓到老鼠就是好貓。

雲計算時代下的運維和傳統運維在工作內容還是有差距的，從過去的機房、交換機、存儲、帶寬等實體設施，到雲服務上的虛擬產品，從實到虛的變化，更多的工作其實在操作端，雲主機資源的模板化，為不同業務團隊配置性能合適的主機模板。

簡介

以及主機資源申請、創建、交付、運維以及最終的釋放銷毀的全生命周期管理，還有應用程序和支持軟體的安裝部署／交付和升級，集群性能負載均衡調配、伺服器的批量腳本操作、資料庫維護、主機的監控、運維日常工作的審計等等，當然了，多雲情況下，各雲使用的費用情況也需要統計和分析。

而這其中，如何及時發現問題，並在問題造成事故之前就解決了才是最難的，這就需要我們擁有事前監控、事中處置的運維能力，當然了，好的運維工具就必不可少。

F. 運維是做什麼的

不同類型的運維，具體的工作也是不一樣的，例舉部分如下：

1、運維工程師/運維開發工程師：負責具體的產品線運維工作，同時也需要掌握開發的能力，深入業務，最了解業務的痛點和問題，同時研發/優化針對產品業務需求的平台、工具和手段，能夠接觸到各類優秀的系統架構並有能力做出優劣對比。

同時對業務的掌控決定了相應運維工程師在業務發展中的作用。長遠發展是成為大型系統的架構師。

2、運維平台研發工程師：專門研發運維相關通用平台和技術，需要有一定的產品線運維經驗或從產品線中拿到運維需求。對研發能力有較高的要求，對系統的設計有較嚴格的標准，並且能夠理解用戶需求。

做出適合服務運維和滿足運維工程師使用體驗的運維產品，長遠的發展是成為各個技術縱向領域的技術專家。

3、資料庫研發工程師/資料庫工程師：資料庫方向是運維技術中較為特殊的一個方向，由於業務的重要性通常需要專設崗位，業界在該方向也有深厚的研究和積累。主要方向有資料庫內核、雲資料庫等，長遠發展是資料庫領域的技術專家，資料庫架構師。

4、運維經理：運維同學做事情的過程中通常需要協調多個RD和QA同學，對協調和推進能力要求比較高，對一些技術深度還不錯，協調和推進能力比較高的同學非常適合轉型管理職位，長遠的發展和技術部門的管理職位一樣目標是CTO、CEO。

5、業務運維工程師：主要負責監控線上的服務質量，響應異常/處理突發故障，在線發布/升級產品。和相應產品線的研發和測試協調處理產品問題，基於工作中的問題和數據分析進行抽取，將運維經驗理念落地沉澱為方法論/工具/系統/平台。

並制定相關的改進計劃，在各個技術方向上落地實現，最終反饋回運維工作中，提高運維本身的效率和產品的價值。

G. 如何接手一個新業務的運維工作

丑話說前頭

先跟研發leader溝通，灌輸運維理念，丑話說在前頭，我們不做保姆式運維，我們會致力於線上服務安全、穩定、低成本、快速迭代，從運維視角提高產品力。開發機、測試環境，研發自己搞，我們可以協助幫忙，做專業的咨詢服務，想讓我們直接操刀開發環境的變更，免談！

業務概要了解

了解業務相關的人，對應的研發同學、研發leader、測試同學、測試leader、產品經理分別是誰，聯系方式存下來，拉個群，出了問題可以找到對應的人。

了解服務是幹啥的，解決了什麼問題，業界有對標的開源產品嗎，方便我們快速認識這個產品。

了解服務的上下游，依賴哪些服務，哪些服務依賴我，對應的介面人是誰，這里先簡單了解一下即可。

了解服務部署情況，部署在哪些機房，用什麼語言編寫的，基礎網路、專線帶寬、機房出口是否靠譜，是否曾因基礎設施導致過問題，當前主要痛點是什麼。

業務串講

要求研發同學（或者上一任運維同學）准備PPT，做一個業務串講，講解一些研發同學希望傳達給運維同學的信息，講解一些運維同學希望從研發這得到的信息。比如：詳細部署拓撲、服務整體架構、數據流、提測變更流程、監控方式、部署到了哪些機器、機器登錄方式、每個機器上是什麼模塊、OS參數是否有調優，考量是什麼、用到了哪些第三方軟體，考量是什麼，比如為啥用了tomcat而不是resin、相關wiki、故障處理預案、常見故障、當前線上問題……等等

如果業務有單點，不接，讓研發改造。如果運維的老闆的老闆強制要求，丑話說前頭：因單點導致的問題，運維不背鍋。

資產梳理

正式准備接手，第一步，梳理資產。比如用到了哪些域名，這些域名對應哪些業務、哪些虛IP，分別是提供了什麼服務、哪些機器，分別部署了什麼模塊、業務在哪些機房、用了多少帶寬、總帶寬情況、是否有其他業務共用爭搶。

機器需要拿到更詳盡的信息，比如機器配置、機架位、IP、管理卡IP等等，公司應該有個CMDB供查詢。如果沒有，運維同學，需要你去構建這個CMDB。

後面要考慮機器是否需要有備機、備件，機型是否可以統一。

基礎監控

知道有哪些資產了，就可以對這些資產做監控了，比如域名連通性監控/延遲監控、虛IP的連通性監控/延遲監控、機器宕機監控、機器硬體監控、sshd/crond等系統進程監控、系統運行的進程總數監控、系統參數配置監控，可以參看我之前的文章《 完備的監控應覆蓋什麼 》

服務梳理

吃透之前串講時給的架構圖、數據流圖、部署拓撲圖。從運維層面，最好還要知道公司網路拓撲圖。

了解每個模塊的情況，部署在哪些機器上，部署在哪個目錄，用什麼賬號啟動的，日誌打到哪裡了，用什麼語言編寫的，怎麼上線的，主要吃CPU資源還是內存還是磁碟還是IO，需要預留多少資源，平時利用率是多少，應該配置多大的閾值做監控，是否需要watchdog自動拉起，日誌里出現哪些關鍵字需要報警，以及其他各種需要注意的問題。

業務監控

基本的進程、埠存活性監控，機器利用率監控、日誌關鍵字監控、日誌不滾動監控、關聯的服務的監控等等，後面會做API粒度的監控，來推動業務優化。

標准化改造

機器命名方式、操作系統發行版、OS版本、第三方軟體，比如jdk、tomcat、nginx，都要統一，做標准化方案。

服務擴容、變更、下線做一鍵化，每次升級只需要給個版本號即可，此時研發操作還是運維操作效果一樣，故而可以交給研發上線，釋放運維人力，許可權要控制好。

重復的常規操作也要固化成腳本，一鍵完成。

梳理故障自愈場景，看平時有哪些故障的處理方式是固定的，抽象為腳本，報警之後自動觸發，無人值守處理。

公司如果有一些基礎設施，比如名字服務、MQ、日誌平台，推動研發改造，將新服務接入。如果公司還沒有這些基礎設施，作為運維這個角色，可以著手搞起。

SOP梳理

故障預案是一個非常重要的事情，線上沒出故障之前，就應該提前去想，服務可能會出什麼故障，如果真出了，應該如何處理，把處理步驟提前記錄下來。畢竟，線上出故障的時候，人都比較緊張，直接看著預案處理，就踏實不少，不容易出錯。

故障演練

光有預案沒有演練，是不靠譜的，沒有經過驗證的預案是不可信任的。所以，搞個放火演習，把模塊搞掛試一把，把機器搞掛試一把，對線上穩定性絕對會有提升。

特別是研發說這個模塊掛掉，可用性肯定沒影響，OK，搞掛試試先。很可能會打他臉，-_-||

有些場景演練是會有損的。這種場景還要不要演練？這個需要case by case的看，大部分情況都是要做演練會更好，畢竟，人在這盯著的時候出問題，比晚上睡著了出了問題要強太多。當然， 大規模基礎網路故障這種演練，還是算了吧，通常的業務都是不具備機房級容災的，呵呵

上面做完了，基本工作就完成了。上面很多事情都是一次性的，那未來的大把時間運維做啥？

除了再花費部分時間做線上問題處理，我們應該把主要精力來提升業務產品力。做精細化運維，還記得運維九字真言么？「安全穩定高效低成本」，這就是我們的工作方向。下面舉幾個例子。

再談業務監控

上面談到過一次業務監控，主要是一些通用的監控指標。我們對產品了解足夠之後，應該做一些業務特有的監控，推動研發去做也可以，達到效果就好。

比如你運維了一個MQ，消息堆積量是需要監控滴；比如你運維了一個RPC服務，提供了三個介面，這三個介面的響應時長、成功率是需要監控滴；比如你運維了一個S3服務，每個桶的短期帶寬增量你是需要監控滴；有那麼點感覺了么？ :)

API成功率、延遲統計

在流量入口的nginx做所有業務線的所有API的成功率和延遲統計，是非常有必要的。把成功率比較低的TopN找出來，把延遲比較大的TopN找出來，讓業務去優化。老闆會喜歡這個的。

線上問題梳理

整理線上所有問題，挨個解決，運維可以搞定的運維搞定，運維搞不定的找研發要排期，每周解決了多少問題，還有多少問題待解決，用周報的方式體現出來。

成本優化

通過服務混部、或者統一的資源調度平台來節省機器資源，一台機器便宜的也好幾萬呢，這個事是比較容易有產出的。

容量規劃

容量規劃和成本優化實際是緊密相關的，容量規劃的重點是根據自然增量和運營需求，提前規劃准備相應的容量，容量可能包括帶寬、專線、網路設備、機器等等；當業務量下來的時候，可以騰挪相關資源支持其他業務線，讓這些硬體盡量滿負荷運轉，物有所值。

業務精細化運維可以想出各種事情來搞，除了做這事，另一個需要長期投入的是構建運維基礎平台，像什麼監控系統、部署系統、產品庫、資源利用率平台、域名管理、四七層接入配置平台、日誌平台、Trace系統等等等等，嗯，其實運維還是挺忙的。

關於溝通

最後說一點，接手一個新業務運維，勢必與研發有各種溝通，每次溝通都要寫會議紀要，發郵件出來，跟進人是誰，時間點是啥時候都要寫明白，郵件發送雙方團隊郵件組，cc各方老大。事後關鍵節點做check，如未完成，線下溝通，達成一致後追此郵件給結論，說明延期原因以及新的時間點。如果溝通不暢，讓老大去協調。

H. 運維，這東西具體怎麼做

運維一般是指對大型組織已經建立好的網路軟硬體的維護，其中傳統的運維是指信息技術運維（IT運維）。所謂IT運維管理，是指單位IT 部門採用相關的方法、手段、技術、制度、流程和文檔等，對IT運行環境（如軟硬體環境、網路環境等）、IT業務系統和IT運維人員進行的綜合管理。隨著信息化進程的推進，運維管理會覆蓋對整個組織運行，進行支持的管理信息系統涵蓋的所有內容，除了傳統的IT運維，還拓展了業務運維和日常管理運維。業務運維面向整個組織提供各業務系統的問題受理、響應、處理和轉交等方面的服務；日常管理運維面向整個組織提供針對各業務系統的運行狀態和需求變化和不同的記錄、跟蹤、保存、分析方面的管理