第一篇：IT運維工作心得總結

運維工作心得總結

運維工作直接關系到應用系統運行的正常穩定，但運維工作紛繁復雜，正規化、系統化相對比較弱，如何改變這種現狀？從眾多的運維工作者的成功失敗中進行經驗總結，并提升為運維規則，是提高運維水平，保障應用系統正常穩定運行的有效途徑。

筆者通過自己的多年運維經驗，總結出以下必須遵守的基本運維規則，可以大大減少缺乏經驗的運維人員因為自身失誤導致系統出故障的可能性。

一、系統變更、升級應先在同樣的環境測試通過，執行前應有經過驗證的回退預案

運維是一門經驗的學科、是一門試錯的學科。沒有做過的東西、總是會給你出意想不到的難題，因此變更前，一定要在相同或者相似運行環境下進行測試，通過后才能在正式環境下執行變更。同時應準備好變更失敗的回退預案，比如，做好系統備份、數據庫備份、配置備份，固化變更前的運行現場，讓變更有回頭的機會。

二、對破壞性的操作要先確認符合預定方案，然后謹慎執行

什么是破壞性的操作？ 比如：

對MSSQLServer，執行update操作，因為不需要commit，所以特別容易忽視也特別危險，還有delete、drop等操作更不用說。

對 Oracle 而言：truncate table_name、delete table_name、drop table_name，這些語句執行起來輕松簡單也愜意極了、但記住！即便數據可被回滾、代價也是非常大！

對 Linux 而言，rm-r 所有當前及其子目錄的所有數據都將被刪除。經歷過這種故障的人、大多會給 rm 上個別名 A liasrm='rm-i' 同理、cp 和 mv 也可以有同樣的選項：

aliascp='cp-i' alias mv='mv-i' 對window而言，shift+del文件或者目錄 對任何系統而言，無備份直接修改文件等

三、備份并驗證備份的有效性

不管是硬件還是軟件總有意外崩潰的時候，怎么辦？備份！！備份的學問很大、按照不同的維度可以分：冷備和熱備、實時和非實時、物理和邏輯、全備增量備。

備份有了、可以高忱無憂了嗎？不行！尚須驗證備份的有效性。一個總有那么幾次、備份無法保證 100% 恢復，簡單的驗證就是找個空庫恢復出來。

四、對生產環境永保敬畏之心

這是避免應用系統發生故障的一條鐵規，也是被開發、運維人員容易忽視的地方。要堅決杜絕直接在生產環境做開發、測試和bug修復，這些操作只能在開發和測試環境做，否則一旦出事，將欲哭無淚。

五、交接和休假最容易出故障

接手別人的工作要一而再，再而三的確認變更方案，請教人并不見得就是能力不行的表現；

? 休假前最好各種可以做好的事情，最好能夠準備一份文檔，指明在什么情況下怎么做和聯系哪些人；

? 在別人放假的時候接手工作，“能拖則拖”，實在需要執行：必須不厭其煩的跟原系統管理人員確認各個操作細節。? 六、一定要有監控手段和報警措施

運維人員賴于生存的工具就是報警和監控。

報警可以讓你及時知道系統出現了什么異常、以便及時跟進、把故障扼殺于搖籃；

? 監控可以讓你了解系統的歷史性能信息、以歷為鑒、可以知興替、早做優化。?

報警和監控是衣寬帶水的好兄弟、相鋪相成、互相促進。

七、使用自動切換技術需謹慎

為了保障數據庫安全，往往會使用HA或者RAC之類的技術，但是這類技術能否真正在關鍵時刻起作用，則是需要經過反復驗證和確認的。并不是按照文檔要求做好了就夠的，很多意外因素或者系統因素會導致自動切換技術并不能如期發揮作用。如果到事后才發現這一點，將悔之晚矣。

八、要有偏執狂的精神，方案要檢查，檢查，再檢查

有這么一個人： ① 他在做一個變更的時候，會先提前一兩周發送郵件并電話手機通知相關人

② 在測試機上寫好腳本，召集大家 review 操作步驟和腳本 ③ 測試完成以后拷貝到生產環境

④ 登錄對應機器，“打開，關閉，打開，關閉”該腳本

⑤ 跟相關人員再次確認執行的操作，順序，時間點，可能的影響和回滾是否都準備好了

⑥ 執行前還要退出這個機器，然后再登錄進去，“打開，關閉”腳本 ⑦ 最后才在后臺運行腳本，同時在另外一個窗口登錄著，隨時ps和查看結果輸出

期間姿勢端正，呼吸急促而均勻，眼神凝重。操作的人不覺得累，倒是一邊觀摩的人很累。

九、簡單即是美

我們總是面臨各種誘惑：新的系統架構，新的更智能的命令和工具，最新的硬件平臺，功能更全的HA軟件...你可以在線下安裝，測試，怎么做都行。但是如果想要在生產環境下使用起來、請三思！

能夠使用系統內置命令的話，就不用考慮其他要專門下載安裝的軟件了 ? 腳本本身就能完成的功能，就沒有必要專門找一個功能豐富的軟件來做 ? Linux本身自帶的字符界面比那些復雜的圖形界面要簡潔方便 ?

如果能做到堅持這九條鐵規，你的應用系統就能長久穩定運行了。

第二篇：IT運維心得分享范文

360公司運維心得分享

在很多“外人”的眼中，運維工程師的工作不過是搬機器、調網絡、裝軟件、處理故障、7×24小時值班，簡單而又枯燥至極。但事實并非如此，運維工作涵蓋很多技術領域，運維工程師要掌握硬件、軟件、操作系統、開發等多方面的知識，核心目標是為億萬用戶使用的產品保駕護航。

當今互聯網行業的發展日新月異，新技術層出不窮。為了適應發展趨勢，運維工程師只有提升技術能力才能更好地完成艱巨的運維任務，必須要對傳統運維發出自我挑戰。

在360，運維團隊由基礎運維團隊、網絡運維團隊和應用運維團隊三部分組成。我們將運維從技術支持領域升級，進行產品化改進，核心目標是為了降低運維成本、縮短研發周期、讓產品試錯更廉價。理想很豐滿，現實很骨感，從最初服務少量項目、幾十臺服務器，發展到大量具有數億用戶的項目，我們也在不斷摸索，在試錯中成長。在這個過程中，我們經歷了兩次重要的升級。第一次升級：運維工具化

運維工作中有很多瑣碎的、重復的事情，初期我們只有兩個IDC，服務器數量有限，項目數量也較少，靠純手工勞作還可以應付。但隨著時間的推移，項目暴增，隨之IDC和服務器的數量也成倍增長，同時360各項目都是小團隊在做，開發風格不同、習慣各異，但極致要求響應速度，如果運維工作按照之前方式進行，很難滿足需求。大勢所趨，我們必須進行工具化升級，將重復的事情自動化。

在工具化過程中，我們秉著低成本、拿來即用的原則，借鑒業界成型的方案，同時將精力用在對開源軟件的研究中，有開源工具就絕不自己憑空創造。初期，我們只圍繞開源軟件做周邊腳本開發，不動核心代碼，在實踐中總結經驗。例如，在最基礎的部署軟件環境中，我們基于YUM搭建了自己的包管理系統，將常用軟件打包，同時根據項目做成模板，這樣無論是初始安裝還是擴容都能在分分鐘完成。配置文件管理利用Puppet完成，服務器批量操控依賴SaltStack。就這樣 我們的運維兵器譜在不斷地豐富。

另外，運維工作離不開監控報警，這是一件讓無數運維人苦不堪言的事情。而會休息才會工作，監控體系必須優化。

我們的監控大概分為系統級、應用級、項目邏輯和用戶體驗四部分。系統級主要監控硬件和網絡等；應用級主要監控常用軟件的健康狀況；項目邏輯監控主要模擬用戶行為探測項目功能點是否運行正常；用戶體驗監控主要聯動博睿和基調等第三方監控一起優化用戶體驗。我們用過的工具很多，開源工具有Nagios、Cacti、Ganglia、Zabbix等，同時自己也開發了一些針對項目場景的監控工具，但萬變不離其宗，都是圍繞上述幾個維度進行監控，然后再進行分級預警和報警。

為了減少報警騷擾，我們分級處理，將報警分為郵件預警、短信報警和瘋狂短信報警。以磁盤空間監控為例：每天下午6點，統計 磁盤使用率超過80%的機器，發出郵件預警，下班前解決；在預警的基礎上，超過85%觸發短信報警；超過90%就要持續報警，避免事故的發生。此外，隨著 服務器數量的增多，硬件故障在所難免，架構設計需要考慮高可用方案，冗余范圍內的服務器故障會以郵件預警的方式發出，避免對運維工程師的騷擾。

有了監控工具和分級機制，還需要有好的制度。為了大部分人可以安心休息，我們每天有專人負責處理常規報警，遇到無法解決的問題才要求他人協助。第二天的負責 人要針對第一天的報警找出根本原因，并盡力解決，因為如果無法根治，困擾將持續發生。所謂線上無小事，實際工作中復雜場景引發的問題數不勝數，所以可以寬 容第一次錯誤，但不能接受同樣問題發生第二次，要不斷地總結和完善。

工具化是運維的必經之路，是向更高層發展的基礎，面對運維這樣復雜的學科，這樣一個極其磨煉人意志的工種，運維工程師需要用聰明的方式解決復雜的問題，節省時間，去做更有意義的事情。

第二次升級：運維產品化

我剛提出運維產品化時，有朋友開玩笑說，你做后端運維吃苦受罪這么多年，看著產品經理吃香的喝辣的，羨慕嫉妒也想轉行做產品吧。也有人說，你是在偷換概念，不就是做自動化運維平臺嘛。其實提出這個概念，一方面是源于有了足夠的工具化積累；另一方面是想換一種思路做運維，培養產品觀，站在用戶的角度思考問題，讓處于后端的運維工程師主動挖掘需求，圍繞運維做更多的探索，提升團隊技術能力，解決海量用戶帶來的問題。有了這個想法，就需要將無形的技術轉變為有形的產品形態，同時要賦予它好的寓意。我們的產品取名為HULK——綠巨人，意在讓小伙伴們借助巨人的肩膀成長，輕點鼠標，運籌帷幄。

想到做這個平臺，源于對實際工作需求的觀察。產品經理有了創新點之后，開發工程師就想以最快的速度上線，但又會很痛苦，因為產品就好比寶塔明珠，塔基需要一 層層地蓋。而開發工程師是與運維工程師合作最緊密的兄弟，“兄弟有難得拔刀相助”，因此我們明確了開發工程師就是運維平臺的用戶，運維工程師在平臺的建設 中扮演了多重角色，是建設者也是使用者，但目標是為用戶解決問題，讓我們的用戶有極致的用戶體驗。基于這些想法，我們勾畫出了宏偉藍圖，提供一個塔基，第一層提供核心基礎服務，如Web、RDB、NoSQL等；第二層提供通用基礎服務，構造一個完美的平臺，讓開發工程師受益。但勾畫的平臺功 能大而全，需求都是我們替用戶假想的，這樣做的后果就是進展緩慢，但做出的功能沒人用。我們在失敗中反思，意識到需求還得從日常工作中去挖掘，平臺上每個功能模塊都必須解決用戶的痛點。互聯網精神唯快不破，要圍繞“快”找痛點。早期開發和運維的合作中，更多的是郵件、IM及當面溝通，跨團隊的溝通成本是第 一個痛點。初期平臺建設中，我們從加速流程開始進行摸索，以“需求任務流”為核心，將通用需求規范流程，統一需求提交頁面，同時盡量為用戶提供選項，而不是隨意填寫，盡量減少溝通成本，同時為完全自動化打好基礎。由于完整的自動化流程開發成本比較高，初期我們還“投機取巧”，用戶提交需求以后，只是把格式 化的郵件發送給運維工程師。運維工程師使用半自動化工具干活，完成后再通過平臺任務流告知用戶結果，手工操作的部分是隱藏在平臺后面的，用戶不得而知。就 用這種方式，我們的平臺積累了不少用戶和口碑。之后我們將日常需求分層、分類：主機類包括主機申請、賬號授權、軟件部署等；Web類包括配置文件管理、域名管理等；DB類包括建庫、建表、SQL審核、授權等。再攻克技術難點將一個個需求實現完全自動化，點點鼠標解決問題。

關于需求任務流，還有個小插曲，標準的任務流由提交、審核、駁回/通過組成。但這個流程太死板，例如用戶提交的一個需求，在審核的過程中有待商榷，運維工程師會和開發工程師 溝通，最終達成一致意見即可，而如果按標準流程需要駁回再提交。為了讓用戶少一次操作，我們增加了管理員可編譯功能。有些同事反對這樣做，覺得不符合常 理。不過有時候常理是需要結合實際場景打破的，就為了讓用戶使用更簡單。

近期為了進一步提升項目試錯階段的速度，我們在平臺上推出了一個新功能：“項目孵化器”。以典型的Web業務為例，以往，申請Web Server、賬號、數據庫實例、負載均衡等是提給運維最基本的需求，每一步都是時間成本。使用“項目孵化器”可以最大限度解決這個痛點，只需在平臺上進 行兩個步驟：第一步填寫業務名稱，預估峰值QPS；第二步選用MySQL、MongoDB、Redis等相關數據庫資源。兩步之后，Web Server、數據庫實例等所需資源會瞬間展示在用戶面前，同時包管理、配置文件管理、代碼發布系統、監控系統等配套輔助功能隨之開通。

與之前的模式相比，效率和規范化都有明顯提高。說起來很神奇，但實現理念很簡單，我們提煉日常項目中的通用方案，構建資源池，在項目發展初期最小量匹配資源。在孵化器的設計階段，我們聽到了很多不同的聲音。例如，讓用戶填信息不夠全面，架構太簡單不滿足全部需求，諸如此類問題，讓人頭痛欲裂。經過過往項目 分析及用戶調研，發現項目尚處于試錯階段，快速試錯是首要需求。至于項目發展中衍生出來的需求，可以再用平臺擴展功能去解決。當利用孵化器建立一個試錯項目之后，用戶進入平臺想看見什么？展現形式如何？還能做什么？這些問題隨之而來。

眾所周知，項目中的關聯關系是個復雜的問題，解決不好，就像一盤散沙無法聯動。為了解決此問題，首先我們確定平臺各功能模塊以項目名為主鍵，將項目的域名、負載均衡、Web Server、數據庫、通用基礎服務等相關聯。項目后期各功能模塊的擴容可以借助關聯關系自動化完成。例如增加一臺Web Server，即可自動部署軟件環境，完成相關節點授權、上傳代碼、測試上線。

展現形式上我們借鑒社交網站的實現方案，以“我的項目”為中心，用戶進入平臺以后默認頁展示項目在平臺中用到的各功能模塊信息，例如域名、主機數量、數據庫實例和監控指標等。做到信息清晰可見，操控簡單易用。

在平臺建設中，我們一直遵循兩個準則：第一，把事情由復雜變簡單；第二，給用戶極致的用戶體驗。所謂極致，就是要超出用戶的預期，但只有挖掘用戶潛在的需求，才能做出超出預期的功能。傳統的運維模式，大多是開發工程師提需求，運維工程師滿足需求，運維工程師主動推進的意識不夠。360的文化中有很重要的一點是Ownership，一個項目的成功與失敗，運維工程師是有責任的，因此需要在日常工作中時刻提醒自己“這個項目是我的，為了讓項目變得更好，我們需要主動思考，為開發工程師提供更多的增值服務”。例如一個項目上線前，會默認部署日志收集模塊，收集匯總后進行訪問日志自動化分析，以時間維度展示訪問量走勢，同時輔以IP地址分析模塊展示地域及運營商分布。同時基于訪問日志狀態碼做進一步的頁面分析，然后以日、周、月維度生成一份體檢報告，以及應對方案推送給開發工程師。這些增值服務是超出預期的，拉近了開發工程師和我們的距離，一起去探討、改進，做出更多有利于項目發展的功能。結束語

運維工作在一家公司中至關重要，但傳統的運維模式一定程度上限制了運維工程師的技術發展，更抑制了創新思維，我們需要利用運維“寬泛技術”定位的優勢開拓思路。例如運維工作需要和很多開發團隊合作，協助架構設計，在這個過程中會接觸到很多開發團隊的技術積累，可以把各家之所長進行聚合，將一些基礎服務進行平臺化改造，資源共享。也可以根據項目的需要，主動做技術研究，將基礎服務做成一個個小產品，提供給開發團隊使用，幫助項目縮短研發周期，穩定發展。在當今技術背景下，運維工程師應該在紅海中尋找藍海的思維模式，培養產品觀，由外至內地思考，突破傳統運維的壁壘，開拓創新。

第三篇：運維主要工作

運維主要工作：

（1）運維人員每天至少上午，下午現場巡視檢查設備運行狀態。

（2）每天值班的運維人員負責接聽電話，負責每小時抄寫各種記錄表格一次。

（3）執行倆票三制制度。

（4）配合廠家完成檢修任務。

（5）上級領導安排的其他工作。

（6）夜間值班，需要睡在主控室，所有設備報警聲必須打開。

（7）配合站長進行應急處理。

（8）清理光伏區組件，避免因遮擋問題而導致發電量損失，表面因產生熱斑而導致組件損壞與異常發熱。

（9）每月最少一次在負荷最高時用熱成像儀檢查組件是否有熱斑，每周檢查一次電氣設備是否存在溫度異常升高的現場。

（10）惡劣天氣后進行特殊巡檢。站長的主要職責：

（1）是電站安全運行的第一責任人，對電站的安全運行負責。

（2）負責審查各種報表，負責檢查兩票。

（3）負責監督運維人員執行各項措施。

（4）負責對運維人員進行考核。

（5）負責對運維人員提供技術培訓及技術支持。

（6）負責安排運維人員的工作任務。

（7）完成上級領導安排的其他工作。

（8）負責與電網方面進行聯系，業務處理。維持電站與電網之間的關系。

（9）負責擔任工作票簽發人，工作負責人。

（10）重大操作時擔任監護人。需要配置的物品與設備

錄音電話一臺，并將錄音接入電腦，用于同調度聯系。OMS電腦一臺，用于同接收發送調度郵件。普通辦公電腦一臺（向電網咨詢，如不需安裝則不用安裝OMS電腦）。滅火器若干，不能放置于開關柜室，干變室，二次繼保室中，需單獨配置滅火器箱。二次繼保室必須使用二氧化碳滅火器。接地電阻測試儀一臺。熱成像儀一臺。蓄電池充放電設備一臺。各設備技術協議，圖紙需全部配齊，不能缺少。組件配品配件若干，匯流箱內空開備品備件若干，浪涌保護器若干。變壓器各種備品備件若干。工具包兩個，內配置工具。電筆若干，萬能表兩個，鉗形表兩個，10KV驗電器兩個，并按照相關國家規定定期進行送檢。10KV絕緣手套兩副，絕緣鞋兩雙，并根據國家有關規定進行送檢。滅火器也需根據國家規定定期進行送檢，灌裝。工具一套，包括各種型號的扳手，內六角扳手整套，呆扳手整套，梅花扳手整套，螺絲刀一字與十字若干，型號配全。接地線至少兩組，并根據國家有關規定進行定期送檢。絕緣梯兩個。逆變器內各種小開關至少每臺配置一個各種逆變器需要用到的型號。A4打印紙，A3打印紙。找廠家專門定制表格一份，用于填寫記錄表。軟毛刷若干，可伸縮桿若干。塑料水桶數個。打印機一臺，可打A3與A4紙。安全規程人手一本，縣調度規程一本。公車一輛，必須可以拉貨。五防鑰匙需多要一臺備品備件。緊急解鎖鑰匙三把，可折疊單人床一張或兩張，人員要求附加原因解釋。每個光伏區進口都需安裝鐵門，光伏區周圍加裝安全護欄，如公司感覺無需加裝則可以不加裝鐵門與遮攔。安全標識牌若干，包括“高壓危險”標識牌數個，“高壓危險，禁止靠近”標識牌數個，“禁止合閘，線路有人工作”數個，“禁止合閘”標識牌數個，工程負責人與我進行交接相關工程圖紙等交接。其他物品等商榷以后進行補充。強光可充電式手電數個。其他物品需根據運維實際情況進行補充。人員要求

運維工作的正常開展不算我需要四個人，盡量全是男的，從事過電工工作最好，是否是高壓電工都行，普通人員也可，入職前進行體檢，確保無傳染病，在站內吃飯，最好是住在站內，如條件不允許可以就近安排住處，如附近無住宿條件，夜間值班便需兩個人，輪流夜間值班可以睡主控室。是不是當地的都行，最好是有一個工程人員轉運維人員。

個人要求

月薪6500，五險一金，可以按照國家最低標準交，但必須有，享受法定節假日三倍工資，每月休班7天，時間自己安排，有年終獎，工資每年調整增加一次，具體金額公司視發電量與電站安全運行情況決定，如不需我同電網進行關系維持則月薪6000，如再提供食宿月薪則5500，單獨提供住宿月薪5700。同時公司可安排我外出參加各種相關培訓，出差費用公司報銷。有本電站運維人員的任免權與考核權。正值工作任務

擔任工作負責人，工作許可人，工作班成員，專職監護人，負責填寫工作票，并履行相關手續。審查副職填寫的操作票并送與站長審查，填寫工作票并送與站長審查執行巡視檢查制度，監盤并按規定填寫各項表格，站長不在時行駛站長權利，接聽調度電話，重大操作時擔任操作人，非重大操作時擔任監護人。打掃全站衛生，上級領導安排的其他工作。副值班員工作任務

擔任工作班成員，擔任專職監護人，負責填寫操作票送與正值審查。監盤并按相關規定進行填寫各種表格，執行巡視檢查制度，接聽調度電話，在站長或正值的監護下進行倒閘操作。

其他事宜根據運維實際情況進行調整。

第四篇：變電站運維工作個人總結

變電站運維工作個人總結

回顧過去的一年，在市縣公司工區領導指導下取得的一些成績，但也有一些不足。現就運行工作總結如下：

一、努力學習新知識，掌握新設備，提高業務技能。

我所工作的單位是一所建設剛2年的變電站，有著配套齊全的辦公設施和生活用具，有著慕煞旁人的生活和學習的條件。自從2011年4月進入110kV變電站工作以來，在市縣工區領導關懷指導下努力改變以往工作模式與方法。從一個干好自己工作為己任，無關他人的自我態度，通過不斷的學習和鍛煉，逐步轉變為互相幫助，共同完成與提高的協同辦公新模式。記得建站投運之始，依然是每天跟班日出而作，日落而棲學習設備的理論和操作方法。終是初步接觸110千伏變電站設備，在市工區領導平時工作擔心憂郁的語氣中，我常感無形的工作壓力，正吞噬著我；而這，也正深深的激勵著我，更加以自覺學習業務知識。

直到去年的某天，在一派新設備無故障的思想中，幾乎把尚存腦海的業務知識遺忘殆盡的時，突然接到地調110kV624線路配合停電檢修的操作指令，在市工區領導仍然有些擔心的口吻中，我以正確的事故處理方法及操作步驟面對，在默認處理措施后，在長長的電話線那邊，似乎看見領導在稍稍放松的神情里，正用贊許的眼光望著我。。

二、立足本崗位，發揮黨員模范帶頭作用。

作為變電站一名基層黨員，愛崗敬業、忠貞不渝，在保持黨的純潔性工作和意識形態中，唯有加強變電站平時安全運行意識的養成和既定制度管理的落實，服務好人民群眾，促進變電運維工

作的全面發展，才是愛黨、愛國家、愛公司應有的體現。我在過去的一年中主動學習黨的方針政策，加強黨性修養，進一步提高自己的政治覺悟和工作能力，在盡職履責中發揮模范帶頭作用。在公司基層變電站里營造和諧工作氛圍，勇于擔當，充分體現黨員的優秀價值。

新形勢下，多年的基層變電站工作，讓我深深的知道迎峰度夏的工作中，公司和電網發展所面臨的任務。我從本職崗位挑戰出發，時時處處以身作則，用實際行動充分體現黨員的執行力和實踐力。在過去一年的圍繞迎峰度夏保供電工作中，我明確時段、地段、人員和工作要求，落實測溫、特巡等工作，包括設備過熱、線路弧垂下降等原因引起的跳閘，全面開展變電設備狀態巡視和檢測工作。切實防止變電設備巡視維護不到位而引發的設備事件發生，通過努力，“迎峰度夏”保供電工作在兩級工區領導大力指導下，取得了圓滿成績和效

果。

三、繼往開來，把一腔工作熱情付諸于無限的為人民服務中去。

作為電力工作者，我們任何時候都應以黨和企業的事業為重；任何時候都應踐行“誠信、責任、創新、奉獻”的核心價值觀，高標準履行國家電網人的職責。在今年政治性用電“國慶”、“十八大”保電工作中，嚴格遵循各項規章制度，嚴防死守，密切配合電力調度，有力的保障了當地人民群眾廣播電視的正常收聽，收看。我來自于基層變電站一名普通的職工，任何時候都應服從整體利益，恪盡職守，在以后的本崗位上，我也將一如既往扎實干好自身工作，干凈干事，發揮黨員模范帶頭作用，努力為當地經濟的發展值好班、站好崗，向組織交上一份“組織放心，群眾滿意”的答卷。

第五篇：運維工作周報

運維工作周報模板

報告人：XXX 時間：2012-X-01 ~ 2012-X-07

一、常規工作

1.2.3.4.5.LVS項目推廣；

發布系統網絡調整配合； 快答系統上線；

制定Q2的5年服務器替換計劃； 系統運維等常規工作跟進；

二、項目跟進

1、IT運維平臺

機架資源功能因等待研發的進度，延遲到下周完成；

二期總結除bug；

運維平臺的使用推廣，并開始完善應用關聯關系的資料；

績效體系積分處理的實現是第三階段的重點，預計6月30日完成；

2、分布式文件系統測試

完成Mogilefs線上測試，并出具報告；

整理Mogilefs上線所需的資源和計劃，下周約開發談具體部署；

搭建Mogilefs的內部開發環境，配合圖片平臺的開發工作；

總結：經過4個月的內部和外部測試，Mogilefs的整體測試已經全部完成，從測試的結果看，無論從性能、穩定性、擴展性、容災性等各方面的指標，Mogilefs都可以符合目前的線上圖片存儲的需求，經過多資源的統計，僅需很小的投入即可完成改造，并能有效的利舊設備，整個部署預計7月中旬完成。

三、團隊管理

部門規劃與績效考核

l 規劃與IT運維平臺的整合計劃，預計6月30日完成；

其他管理工作

l 審核架構的搭建和完善；

l 主備冗余計劃，完成第一批的主備交接工作；

四、工作難點、問題與建議

五、下周計劃

1.2.3.4.5.6.7.8.9.常規工作繼續跟進；

繼續跟進IT運維平臺的開發和推廣工作； 重點跟進分布式文件系統的規劃和實施； 重點跟進審核架構的相關工作； 重點跟進設備采購及部署規劃工作；

繼續跟進整理運維中心的績效考核體系； 繼續跟進相關項目的研究工作； 繼續跟進運維相關項目的進度； 繼續跟進團隊建設相關工作；