第一篇：linux服務器故障之運維經驗總結

服務器故障之運維經驗總結

作為一個運維人員，遇到服務器故障是在所難免的，要是再趕上修復時間緊、奇葩的技術平臺、缺少信息和文檔，基本上這過程都會慘痛到讓我們留下深刻的記憶。當出現此類問題時，應該如何處理？本文給大家詳盡的分析了一下，一起來看看。

我們團隊為上一家公司承擔運維、優化和擴展工作的時候，我們碰到了各種不同規模的性能很差的系統和基礎設備（大型系統居多，比如CNN或者世界銀行的系 統）。要是再趕上修復時間緊、奇葩的技術平臺、缺少信息和文檔，基本上這過程都會慘痛到讓我們留下深刻的記憶。

遇到服務器故障，問題出現的原因很少可以一下就想到。我們基本上都會從以下步驟入手：

一、盡可能搞清楚問題的前因后果

不要一下子就扎到服務器前面，你需要先搞明白對這臺服務器有多少已知的情況，還有故障的具體情況。不然你很可能就是在無的放矢。

必須搞清楚的問題有：

? ? ? ? ? ? ? ? ? 故障的表現是什么？無響應？報錯？ 故障是什么時候發現的？ 故障是否可重現？

有沒有出現的規律（比如每小時出現一次）

最后一次對整個平臺進行更新的內容是什么（代碼、服務器等）？

故障影響的特定用戶群是什么樣的(已登錄的, 退出的, 某個地域的…)? 基礎架構（物理的、邏輯的）的文檔是否能找到?

是否有監控平臺可用?（比如Munin、Zabbix、Nagios、New Relic… 什么都可以）

是否有日志可以查看?.（比如Loggly、Airbrake、Graylog…）

最后兩個是最方便的信息來源，不過別抱太大希望，基本上它們都不會有。只能再繼續摸索了。

二、有誰在? $ w$ last 用這兩個命令看看都有誰在線，有哪些用戶訪問過。這不是什么關鍵步驟，不過最好別在其他用戶正干活的時候來調試系統。有道是一山不容二虎嘛。（ne cook in the kitchen is enough.）

三、之前發生了什么? $ history

查看一下之前服務器上執行過的命令。看一下總是沒錯的，加上前面看的誰登錄過的信息，應該有點用。另外作為admin要注意，不要利用自己的權限去侵犯別人的隱私哦。到這里先提醒一下，等會你可能會需要更新 HISTTIMEFORMAT 環境變量來顯示這些命令被執行的時間。對要不然光看到一堆不知道啥時候執行的命令，同樣會令人抓狂的。

四、現在在運行的進程是啥? $ pstree-a$ ps aux

這都是查看現有進程的。ps aux 的結果比較雜亂，pstree-a 的結果比較簡單明了，可以看到正在運行的進程及相關用戶。

五、監聽的網絡服務

$ netstat-ntlp$ netstat-nulp$ netstat-nxlp

我一般都分開運行這三個命令，不想一下子看到列出一大堆所有的服務。netstat-nalp倒也可以。不過我絕不會用 numeric 選項（鄙人一點淺薄的看法：IP 地址看起來更方便）。找到所有正在運行的服務，檢查它們是否應該運行。查看各個監聽端口。在netstat顯示的服務列表中的PID 和 ps aux 進程列表中的是一樣的。

如果服務器上有好幾個Java或者Erlang什么的進程在同時運行，能夠按PID分別找到每個進程就很重要了。

通常我們建議每臺服務器上運行的服務少一點，必要時可以增加服務器。如果你看到一臺服務器上有三四十個監聽端口開著，那還是做個記錄，回頭有空的時候清理一下，重新組織一下服務器。

六、CPU 和內存

$ free-m$ uptime$ top$ htop 注意以下問題:

? ? 還有空余的內存嗎? 服務器是否正在內存和硬盤之間進行swap?

還有剩余的CPU嗎? 服務器是幾核的? 是否有某些CPU核負載過多了? ? 服務器最大的負載來自什么地方?平均負載是多少?

七、硬件

$ lspci$ dmidecode$ ethtool

有很多服務器還是裸機狀態，可以看一下：

? ? 找到RAID 卡(是否帶BBU備用電池?)、CPU、空余的內存插槽。根據這些情況可以大致了解硬件問題的來源和性能改進的辦法。

網卡是否設置好? 是否正運行在半雙工狀態? 速度是10MBps? 有沒有 TX/RX 報錯?

八、IO 性能

$ iostat-kx 2$ vmstat 2 10$ mpstat 2 10$ dstat--top-io--top-bio 這些命令對于調試后端性能非常有用。

? ? ? ? 檢查磁盤使用量：服務器硬盤是否已滿? 是否開啟了swap交換模式(si/so)?

CPU被誰占用：系統進程? 用戶進程? 虛擬機?

dstat 是我的最愛。用它可以看到誰在進行 IO： 是不是MySQL吃掉了所有的系統資源? 還是你的PHP進程?

九、掛載點 和 文件系統

$ mount$ cat /etc/fstab$ vgs$ pvs$ lvs$ df-h$ lsof +D / /* beware not to kill your box */

? ? ? ? ? ? 一共掛載了多少文件系統?

有沒有某個服務專用的文件系統?(比如MySQL?)

文件系統的掛載選項是什么： noatime? default? 有沒有文件系統被重新掛載為只讀模式了？

磁盤空間是否還有剩余?

是否有大文件被刪除但沒有清空?

如果磁盤空間有問題，你是否還有空間來擴展一個分區？

十、內核、中斷和網絡

$ sysctl-a | grep...$ cat /proc/interrupts$ cat /proc/net/ip_conntrack /* may take some time on busy servers */$ netstat$ ss-s

? 你的中斷請求是否是均衡地分配給CPU處理，還是會有某個CPU的核因為大量的網絡中斷請求或者RAID請求而過載了？ ?

? ? ? SWAP交換的設置是什么？對于工作站來說swappinness 設為 60 就很好, 不過對于服務器就太糟了：你最好永遠不要讓服務器做SWAP交換，不然對磁盤的讀寫會鎖死SWAP進程。

conntrack_max 是否設的足夠大，能應付你服務器的流量? 在不同狀態下(TIME_WAIT, …)TCP連接時間的設置是怎樣的？ 如果要顯示所有存在的連接，netstat 會比較慢，你可以先用 ss 看一下總體情況。

你還可以看一下 Linux TCP tuning 了解網絡性能調優的一些要點。

十一、系統日志和內核消息

$ dmesg$ less /var/log/messages$ less /var/log/secure$ less /var/log/auth

? ? ? 查看錯誤和警告消息，比如看看是不是很多關于連接數過多導致？ 看看是否有硬件錯誤或文件系統錯誤?

分析是否能將這些錯誤事件和前面發現的疑點進行時間上的比對。

十二、定時任務

$ ls /etc/cron* + cat$ for user in $(cat /etc/passwd | cut-f1-d:);do crontab-l-u $user;done

? ? ? 是否有某個定時任務運行過于頻繁? 是否有些用戶提交了隱藏的定時任務?

在出現故障的時候，是否正好有某個備份任務在執行？

十三、應用系統日志

這里邊可分析的東西就多了, 不過恐怕你作為運維人員是沒功夫去仔細研究它的。關注那些明顯的問題，比如在一個典型的LAMP（Linux+Apache+Mysql+Perl）應用環境里:

? ? ? ? ? Apache & Nginx;查找訪問和錯誤日志, 直接找 5xx 錯誤, 再看看是否有 limit_zone 錯誤。

MySQL;在mysql.log找錯誤消息，看看有沒有結構損壞的表，是否有innodb修復進程在運行，是否有disk/index/query 問題.PHP-FPM;如果設定了 php-slow 日志, 直接找錯誤信息(php, mysql, memcache, …)，如果沒設定，趕緊設定。

Varnish;在varnishlog 和 varnishstat 里, 檢查 hit/miss比.看看配置信息里是否遺漏了什么規則，使最終用戶可以直接攻擊你的后端？

HA-Proxy;后端的狀況如何？健康狀況檢查是否成功？是前端還是后端的隊列大小達到最大值了？ ?

結論

經過這5分鐘之后，你應該對如下情況比較清楚了：

? ? ? 在服務器上運行的都是些啥？

這個故障看起來是和 IO/硬件/網絡 或者 系統配置(有問題的代碼、系統內核調優, …)相關。

這個故障是否有你熟悉的一些特征？比如對數據庫索引使用不當，或者太多的apache后臺進程。

你甚至有可能找到真正的故障源頭。就算還沒有找到，搞清楚了上面這些情況之后，你現在也具備了深挖下去的條件。當然還可以借助ITIL工具對CMDB資產的關聯進行深入分析。繼續努力吧！

第二篇：服務器運維工作計劃

運維部下半年工作計劃

為了使運維工作順利進行，運營部下半年工作計劃如下：

1、進一步推進服務器的規劃部署、搭建，以及對服務器構架、網絡進行優化和調整。

2、利用監控平臺nagios實時監控服務器、網絡設備及業務系統的運行狀態、性能。根據監控和處理結果，及時記錄相關信息，定期匯總運營信息。

3、優化公司網絡、郵件服務器、語音系統以及解決常見的操作系統、網絡和應用故障。

4、負責突發性事件的快速響應和處理，解決服務器和網絡故障。

5、與開發人員配合溝通，解決運行過程中的相關問題。

6、對日常運營數據的整理分析，然后對服務器狀態監測，游戲出現問題的解決。

7、配合商務及市場部做好相關工作。篇二：運維部2013年終工作總結及2014年工作計劃[1] 古交分公司運維部

2013年工作總結及2014年工作計劃 2013年運維部在分公司直接領導下及全體部門員工的勤奮努力下，順利完成網絡維護、網絡建設、網絡安全等任務，有力的保證了古交數字電視及互動業務發展，全年來的工作總結和2014年計劃如下：

一、網絡維護及建設 1，城農網維護建設 1）、在分公司的正確領導及相關部門的大力支持下，運維部全體人員的勤奮工作。城農網維護截止12月份，運維部共處理用戶故障電話報修 次，安裝普通用戶 戶，搬遷用戶 戶，開通副機用戶 戶，安裝互動用戶 戶，以舊換新 戶，互動副機 戶，提高了網絡覆蓋量，更有力的提升了市場競爭力。2）,完成網絡新建工程立項 項，實施 項等幾個光節點網絡覆蓋面積，促進了業務發展和業務收入的增加。2，網絡優化建設

在分公司領導親自帶領下，全年對全市所轄網絡進行了數字互動電視整體轉換前的規劃與設計。為2014年全面開展互動業務打下一個堅實的基礎。對已開通互動業務的小區，加大了維修力度，并對局部不符合條件的小區進行了小范圍的局部改造，使其具備開通互動業務的技術條件。通過走訪互動用戶，普遍反映收視效果良好。

二、機房維護及消防安全工作

1、在分公司分管領導的指導下制定了《機房值班制度》及《機房維護及消防制度》，根據制度明確了機房值班人員，建立和完善各項維護制度和加強機房資料及文檔的管理，機房設備檢修清掃，做好“三防”工作，確保設備正常運行，保證信號安全傳輸。

2、積極配合總公司和機房對纖、跳線等工作。對機房進行不定期檢查，遇到安全隱患及時排除并上報，遇到節假日和重要傳輸時期，都做好了安全上報等工作。

3、不定期對機房的消防工作進行安全檢查，就一些存在的問題進行了及時整改，消除了存在的安全隱患。

三、加強技術培訓，提高隊伍素質

運維部承擔分公司運維和工程建設的主要隊伍，面對工程建設、網絡安全等重要任務，要在短時間內保質保量完成，無論是組織工作，還是技術工作都存在較多的難題。為此運維部把開展技術培訓作為一項確保工程質量、進度的重要措施來抓，采取走出去請進來的方式，不但多次派員工參加總公司的培訓學習，經常利用部門開會時間組織運維人員進行集中學習培訓，還和西山分部的運維人員進行面對面經驗和技術的交流，提高了維護人員的技能。

四、安全工作方面

1、城農網網絡安全

根據城農網網絡安全特性制定，明確片區運維人員為城農網網絡安全巡查維護人員。片

區運維人員對轄區內的光、電纜進行巡查并作好日志，對存在隱患的地方及時上報。

3、維護人員人生安全

注重安全生產，全年人員無重大傷亡事故發生。運維部多次開展安全學習來加強員工安全生產意識，提高自我保護的能力。

4、車輛安全

運維部嚴格按照《車輛安全管理辦法》來管理車輛，禁止無證駕車，嚴禁公車私用，嚴禁酒后駕車，嚴禁開英雄車等。對分公司運維車輛進行不同程度的修理維護，杜絕帶病車輛上路有效加大車輛安全程度。

五、存在問題及不足

1、目前運維部整體須加強思想認識、提高工作效率、提升服務水平。

2、特別注重安全生產,搞好網絡干線巡檢工作。

3、運維部目前缺乏新技術、新業務的尖端人才，針對下一步的數字雙向網絡、數據等新業務，加強能承擔新的維護任務技術的培訓及業務學習。

4、加強運維文檔的管理，提高維護質量。做好每月必須及時認真上報的各類報表。

5、隨著城區、農村網絡的進一步擴大，運維人員不夠的問題制約著運維部的快速反應機制。

6、進一步提高運維部人員的福利待遇，提高工作積極性。六、2014年工作計劃

1、繼續抓好網絡維護質量管理和科技維護水平，提高網絡運行質量。

2、繼續抓好、抓實干線巡查工作。

3、積極配合做好城農網、城區管道網絡建設服務等工作的準備開工建設及其他工作任務。

4、按計劃搞好網絡新建、小區新建的立項及建設和竣工及驗收工作。

5、落實運維部的各項管理制度，明確目標管理，理順工作流程，提高工作效率、提升服務水平。

6、完善安全生產制度，搞好安全生產工作。

古交分公司運維部

程永亮 2014年1月7日篇三：2009運維服務能力管理計劃 2009運維服務能力管理工作計劃

根據公司本的工作計劃，運維部結合本部門的工作實際，及相關的it運維服務工作的改進需求，特制定本工作計劃，內容共分為四部分，包括：

1、運維管理組織結構

2、運維服務流程

3、應急服務響應措施

4、服務管理制度規范?，F具體闡述如下：

一、運維管理組織結構

本運維項目的運維管理結構位三層模式，具體如下圖所示。由項目負責人與甲方進行業務范圍接洽，并將溝通結果向下傳遞。項目經理負責項目的整體運維工作，包括各種制度的制定和實施。運維工程師則在項目經理的指導下開展維護工作。1．項目負責人

職責：負責項目商務、整體協調事宜。

職位描述： 1）、整體負責建設單位運維項目服務計劃的制定，領導項目經理并安排項目工作，指導項目經理完成具體維護工作，每周聽取項目經理的工作匯報，負責考核項目經理工作完成情況。2）、協助建設單位完成新增項目的調研、方案設計并指導項目經理進行具體實施。2．項目經理

職責：規劃、執行、完善信息化項目的運維工作，指導網絡、數據庫維護工程師開展工作。

職位描述： 1）根據公司戰略目標，指導下屬工程師開展客戶服務工作，確保運維工作能夠滿足客戶的實際需要； 2）建立和持續完善運維管理體系，優化運維流程流程，解決運維服務中出現的特殊問題； 3）規劃并提升運維工程師專業服務能力，在整體上提高客戶滿意度； 4）制定和持續完善績效考核體系； 5）制定整理運維項目的應急預案系統，并指導運維工程師實施； 6）提高自身專業技能，在業務方面給予網絡管理員和數據庫管理員指導。3．技術主管

職責：應用、數據庫管理，oracle性能調優，實現應用負載均衡。職位描述： 1）技術主管非項目常駐人員，根據項目需要進行專業方面

指導；

2）負責數據庫性能分析與調優，數據庫運行狀態監控，及

時發現異常并快速處理。

2）熟練掌握oracle10g的rac技術，能夠實現部署及調優。3）掌握was、weblogic、tomcat、websphere等中間件的工

作原理，能夠實現部署調優及故障解決。4）熟練掌握red-flag、redhat等linux操作系統，部署 證oracle數據庫冗災、數據保護、故障恢復。5）負責應用負載均衡的部署和調試。6）負責指導數據庫工程師管理員開展工作。4．服務臺

職責：故障電話受理，文檔管理。

職位描述

1)負責it業務的救助電話的受理工作； 2)故障處理的發起人，同時進行維護工程師指派，跟蹤事件處理狀態； 3)進行維護故障統計、用戶滿意度統計、工作報表輸出等工作； 4)協助項目經理，進行文檔整理、歸類、保存等工作。5．網絡管理員

職責：維護建設單位網絡系統正常，解決網絡相關故障。

職位描述：

1)對現有服務器、局域網絡及機房、配線間的日常管理維護； 2)對信息安全建設提出相關建議，確保網絡的安全； 3)保證外網光纖線路正常，保證局域網運行正常； 4)對網絡系統和網絡設備的運行狀態進行監控； 5)熟練掌握域策略設置、dhcp、dns、ftp服務器、ntfs權限設置等； 6)編寫網絡部分的應用處理預案并實施。7)工作認真、細致，積極主動有條理性，具有良好的溝通能力及團隊合作精神.6.應用、數據庫管理員

職責：維護建設單位業務系統運行正常，解決應用和數據庫故障。職位描述： 1)監測業務系統運行狀況，應用、數據庫性能監視及優化，作必要調整； 2)規劃不同數據的生命周期，制訂備份、恢復、遷移和災備策略，根據業務的需要執行數據轉換及遷移等操作；

3)保證應用和數據庫系統的安全性、完整性和運行效率。4)負責數據庫平臺的整體架構及解決方案的制定和實施； 5)工作認真、細致，積極主動有條理性，具有良好的溝通能力及團隊合作精神.7.終端管理員

職責：維護建設單位桌面系統運行正常，解決終端、外設故障。職位描述: 1)各部門電腦、打印機、傳真機的維護； 2)對各部門職員進行電腦相關的技術支持及培訓工作； 3)精通windows xp及office的使用，能夠熟練使用excel2003、excel2007及以上版本，能夠制作相應教程對其他部門員工進行培訓

二、運維服務流程 it運維服務管理流程涉及服務臺、事件管理、問題管理、配置管理、變更管理、發布管理、服務級別管理、財務管理、能力管理、可用性管理、服務持續性管理、知識管理及供應商管理等，隨著運維活動的不斷深入和持續改進，其他流程可能會逐步獨立并規范。

三、應急服務響應措施

運維項目組制定了詳盡的應急處理預案，整個流程嚴謹而有序。但在服務維護過程中，意外情況將難以完全避免。我們將對項目實施的突發風險進行詳細分析，并且針對各類突發事件，設計了相應的預防與解決措施，同時提供了完整的應急處理流程。1.應急預案實施基本流程篇四：運維服務管理計劃 2013服務管理計劃

版權信息

本文件涉及之信息，屬xxxx有限公司所有。

未經xxxx通信技術有限公司允許，文件中的任何部分都不能以任何形式向第三方散發。xxx技術有限公司 模板編號：r.qly.103b xxx有限公司 模板編號：r.mat.103b 1.總體介紹 1.1 計劃總則 2013服務管理計劃用于指導公司服務團隊在本內按照服務級別協議（下簡稱“sla“）以及服務目錄，實施服務管理與服務運營活動。實施服務管理計劃的目的是達成公司既定的服務質量目標、規劃并合理使用資源、保證業務連續性和it服務連續性、不斷改進服務過程。為客戶提供穩定、安全、高效運行的業務系統。為建立符合國際/國內服務標準的運維服務體系進行嘗試。1.2 適用范圍

用于服務管理的全生命周期過程，計劃內容在實際執行過程中若有變更，則將適時修改計劃內容，并由總經理批準后發布。2.總體概述 2.1 組織架構 xxxx公司運維服務體系組織架構圖

具體職能參見《xxxx運維服務體系組織結構圖及職責》。2.2 服務目標 xxx有限公司 模板編號：r.mat.103b 3.服務質量管理計劃 3.1 服務質量管理活動

為達成服務質量目標，檢查運維體系的實施情況，2013計劃執行的服務質量管理活動有： 3.1.1 運維服務能力內審

審核運維服務活動及其結果是否符合策劃的安排，確保運維服務體系的有效性。

運維服務能力內審由質量部負責組織實施。3.1.2 運維服務能力管理評審

管理評審目的是對公司運維服務管理體系進行系統評審，識別并確定各種改進的機會和需要，確保運維服務管理體系持續的適宜性、充分性和有效性。xxx有限公司 模板編號：r.mat.103b 運維服務能力管理評審由管理者代表負責組織實施，質量部協助。3.1.3 運維服務體系過程改進

日常工作中，通過對運維服務項目過程的監督檢查，收集服務提供過程中存在的問題，確定運維服務改進的需求。

定期收集和分析運維服務指標完成情況，發現并確定運維服務改進需求。各相關指標，每季進行收集和分析。

對客戶反饋意見進行收集和分析（包括滿意度調查結果和客戶投訴意見），了解客戶意見和需求，為改進提供依據。客戶滿意度調查每季開展一次。

完成2012未關閉的過程改進事項，詳見《運維服務能力管理改進建議與跟蹤表》。3.1.4 服務過程質量監督

質量部通過對運維服務項目進行過程監督檢查，及時發現問題并督促問題及時解決和改進，以確保運維服務按服務規范實施并按約交付服務。服務質量監督檢查由質量專員制定《項目質量保證計劃》，按計劃實施并報告。3.2 運維服務質量管理計劃 xxx有限公司 模板編號：r.mat.103b篇五：2015年運維部工作計劃.修改 2015年工作計劃

結合公司今年運營發展的思路,我部門今年將重點提升網絡服務質量,提高運維人員綜合業務素質。

一 運維部基本情況: 運維部主要維護十二師轄區和烏魯木齊市區兩部分,其中十二師轄區內有五大團場片區,共有用戶44126(穿線用戶)實際使用用戶為35525 ,三網用戶2237戶，現有維護員13人。

市區維護26個小區,共有用戶22570, 現有維護員2 人.二 2014年運維部維修故障分析 2013年全年故障發生共10657起,占總用戶數的2.5% ,故障率為,主要分為:馬賽克，裝修改線，公用電停電，用戶光纖損壞，拆遷，機頂盒壞等。1小區共用電停電造成的故障占運維故障的50%,主要原因是:不能及時補電，交納電費受小區物業的控制.2 用戶光纖損壞（人為和自然、工程）占10%,加強日常線路維護。3老機頂盒損壞5%,主要原因,大部分用戶是2009年左右的用戶,使用壽命已到,造成故障.4 用戶裝修改線15%造成線路不通，和用戶光纖的損壞造成二次熔接。5 拆遷用戶的維修10%.6 其他原因占10%.三 2014年機房維護情況說明

現有機房10個,計劃新增機房1個,存在的問題，分機房停電不能及時供電第一時間到現場解決故障，存在很大的安全隱患。

四2015年的工作計劃

1、重點解快因用電造成的故障,與小區物業部協商取得供電支持,計劃在今年年初對轄區內的共用電改造工作。

2、搶修組已做到責任制到片區及時處理光纖故障，做好對用戶禁止裝修改線的宣傳工作。

3、為了提高機房安全運行傳輸質量，加快建設網路機房監控設施，預計建設現有分機房11個。

4、維護人員的綜合業務素質 ,加強培訓,年初針對運維網絡技術和公司考核管理的培訓計劃一周一次上半年，下半年兩周一次和對新進員工的資質培訓,月度考試與工資掛鉤,提升運維人員的服務統一標準，5、完善安全生產制度，搞好安全生產工作。(1)每月定期對機房進行尋查、巡檢工作。(2)對運維人員不定期抽檢技術性工作流程。

6、加強運維人員的市場營銷意識,新業務推介與提成.7、今年需建設好主干線的環路（列如：師機房至104團，104團至西山等）和網管系統，做好網絡運行質量.。

8、今年運維部計劃分5個大片區其中城區26個小區，用戶22570戶其中現有三網用戶1509戶，3人一輛車維護，西山、104團三網用 戶6211戶，3個人維護，頭屯河農場三網用戶7421戶2人維護，三平農場三網用戶11360戶2人維護，五一農場三網用戶7090戶，2人維護，搶修組4人一輛車負責5個大片區光纜用戶光纖、主干光纜的維修維護，9、今年工程部改造老校區的光纖到戶的同時改造維修量較大的老有線電視小區。（列如：五一農場詒心園小區一期，樓蘭酒廠，光華學校等）。

10、由于公司的網路不只是傳輸有線電視還傳輸了數據業務而且用戶不斷增加，光纜全部是寄掛或借用在別人的管道和木桿搶修查找斷點耽誤時間，不能及時修復，由其晚上對運行維修帶來很大困難，今年計劃建設好主干線的環路（列如：師機房至104團，104團至西山等）和網管系統，做好網絡運行質量。

11、積極配合工程部做好城郊主干網、本地傳輸網、及弱點管道和各團場分機房建設，竣工驗收工作及維護等其他工作任務。

12、落實運維部的各項管理制度，明確目標管理，理順工作流程，為了更好地為用戶服務，從而提高用戶滿意度建立良好的天娛傳媒口碑。

第三篇：逃離故障的十條運維工作經驗總結

逃離故障的十條運維工作經驗總結

故障、于 DBA、于 運維人員 都是 心中永遠的痛、而避免故障的原則卻是殊途同歸

現列如下、與君共勉

㈠

佛說：每次創傷、都是一次成熟、這便是運維人員的真實寫照從某種意義上講、運維是一門經驗的學科、是一門試錯的學科

沒有做過的東西、總是會給你不期而遇的痛擊

請保護現場、讓 變更 有回頭的機會

㈡ 對破壞性的操作謹慎小心

什么是破壞性的操作哩？

比如：

對 Oracle 而言：truncate table_name、delete table_name、drop table_name

這些語句執行起來輕松簡單也愜意極了、但記住！即便數據可被回滾、代價也是非常大！

對 Linux 而言：rm-r 所有當前及其子目錄的所有數據都將被變更要能回滾、先在同樣的環境測試過

刪除

經歷過這種故障的人、大多會給 rm 上個別名

alias rm='rm-i'

同理、cp 和 mv 也可以有同樣的選項：

alias cp='cp-i'

alias mv='mv-i'

㈢

在操作之前、先理清你所在的是主庫、備庫？當前目錄？哪個 schema？session？時間？

比如：

對 Oracle 來講：

[plain] view plaincopyprint?

1.idle> set sqlprompt 'RAC-node1-primary@10g>>'

2.RAC-node1-primary@10g>>

設置好命令提示

當然、你也可以在 glogin.sql 里面設置

對于 Linux 而言、bash 環境的提醒可設置 PS1 來知道當前目錄、登陸用戶名和主機信息等

對 PS1 更多理解、請見：man PS

1㈣ 備份并驗證備份的有效性

人非圣賢、豈能無過？是機器總有計劃內或計劃外崩潰的一天怎么辦？備份！！

備份的學問很大、按照不同的維度可以分：冷備和熱備；實時和非實時；物理和邏輯

OLTP 7*24 在線業務、DB 就需要有實時熱備

這樣就可以了嗎？

如果開發人員的一個不帶任何條件的 delete 誤刪所有數據所以、此時你除了實時、還需要有非實時的備份、把 DB 從邏輯錯誤中恢復出來

備份有了、可以高忱無憂了嗎？

不行！尚須驗證備份的有效性

一個總有那么幾次、備份無法保證 100% 恢復

簡單的驗證就是找個空庫、恢復出來

㈤ 對生產環境永保敬畏之心

會計人員在從業之前、都有個職業操守的訓練

同理、這也應該是運維人員進入行業首先需要具備的素養比如：

于 Oracle 而言、你可以跑一個 RDA 巡檢 DB 的健康狀況于 Linux 而言、是否有 password aging、隔離外網等

㈥ 交接和休假最容易出故障、變更請謹慎

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

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

在別人放假的時候接手工作，“能拖則拖”，實在需要執行：必須不厭其煩的跟原運維者確認各個操作細節

㈦ 搭建報警、及時獲取出錯信息；搭建性能監控、預測趨勢

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

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

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

報警和優化是衣寬帶水的好兄弟、相鋪相成、互相促進

㈧ 自動卻換需謹慎

比如、Oracle 存儲級的HA方案：Data Guard

主庫提交了一筆訂單、結果發生了 switchover、這筆訂單沒有同步到備庫

那么、賣家損失了一個銷售單、對客戶、對公司都是損失

㈨ 仔細一點，偏執一點，檢查，檢查，再檢查

有這么一個人：

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

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

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

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

⑥ 執行前還要退出這個機器，然后再登錄進去，“打開，關閉”腳本

⑦ 最后才在后臺運行腳本，同時在另外一個窗口登錄著，隨時ps和查看結果輸出

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

㈩ 簡單即是美

這有點禪的意境、和 GNU/Linux 的思想不謀而合我們總是面臨各種誘惑：

新的系統架構，新的更智能的命令和工具，最新的硬件平臺，功能更全的HA軟件...等

你可以在線下安裝，測試，怎么搞都行。但是如果想要在生產環境下使用起來、請三思！

能夠使用系統內置命令的話，就不用考慮其他要專門下載安裝的軟件了

腳本本身就能完成的功能，就沒有必要專門找一個功能豐富的軟件來做

linux本身自帶的字符界面比那些復雜的圖形界面要簡潔方便............

第四篇：Linux運維經驗總結

Linux運維經驗總結

一、線上操作規范

1、測試使用

當初學習Linux的使用，從基礎到服務到集群，都是在虛擬機做的，雖然老師告訴我們跟真機沒有什么差別，可是對真實環境的渴望日漸上升，不過虛擬機的各種快照卻讓我們養成了各種手賤的習慣，以致于拿到服務器操作權限時候，就迫不及待的想去試試，記得上班第一天，老大把root密碼交給我，由于只能使用putty，我就想使用xshell，于是悄悄登錄服務器嘗試改為xshell+密鑰登錄，因為沒有測試，也沒有留一個ssh連接，所有重啟sshd服務器之后，自己就被擋在服務器之外了，幸好當時我備份sshd_config文件，后來讓機房人員cp過去就可以了，幸虧這是一家小公司，不然直接就被干了……慶幸當年運氣比較好。

第二個例子是關于文件同步的，大家都知道rsync同步很快，可是他刪除文件的速度大大超過了rm-rf,在rsync中有一個命令是，以某目錄為準同步某文件（如果第一個目錄是空的，那么結果可想而知），源目錄（有數據的）就會被刪除，當初我就是因為誤操作，以及缺乏測試，就目錄寫反了，關鍵是沒有備份……生產環境數據被刪了沒備份，大家自己想后果吧，其重要性不言而喻。/ 8

2、Enter前再三確認

關于rm-rf / var 這種錯誤，我相信手快的人，或者網速比較慢的時候，出現的幾率相當大，當你發現執行完之后，你的心至少是涼了半截。

大家可能會說，我按了這么多次都沒出過錯，不用怕，我只想說當出現一次你就明白了，不要以為那些運維事故都是在別人身上，如果你不注意，下一個就是你。

3、切忌多人操作

我在的上一家公司，運維管理相當混亂，舉一個最典型的例子吧，離職好幾任的運維都有服務器root密碼。

通常我們運維接到任務，都會進行簡單查看如果無法解決，就請求他人幫忙，可是當問題焦頭爛額的時候，客服主管（懂點linux），網管，你上司一起調試一個服務器，當你各種百度,各種對照，完了發現，你的服務器配置文件，跟上次你修改不一樣了，然后再改回來，然后再谷歌，興沖沖發現問題，解決了，別人卻告訴你，他也解決了，修改的是不同的參數……這個，我就真不知道哪個是問題真正的原因了，當然這還是好的，問題解決了，皆大歡喜，可是你遇到過你剛修改的文件，測試無效，再去修改發現文件又被修改的時候呢？真的很惱火，切忌多人操作。

4、先備份后操作

養成一個習慣，要修改數據時，先備份，比如.conf的配置文件。另外，修改配置文件時，建議注釋原選項，然后再復制，修改 / 8

再者說，如果第一個例子中，有數據庫備份，那rsync的誤操作不久沒事了吧，所以說丟數據庫非一朝一夕，隨便備份一個就不用那么慘。

二、涉及數據

1、慎用rm-rf 網上的例子很多，各種rm-rf /，各種刪除主數據庫，各種運維事故……一點小失誤就會造成很大的損失。如果真需要刪除，一定要謹慎。

2、備份大于一切

本來上面都有各種關于備份，但是我想把它劃分在數據類再次強調，備份非常之重要哇，我記得我的老師說過一句話，涉及到數據何種的謹慎都不為過，我就職的公司有做第三方支付網站和網貸平臺的，第三方支付是每兩個小時完全備份一次，網貸平臺是每20分鐘備份一次，我不多說了，大家自己斟酌吧

3、穩定大于一切

其實不止是數據，在整個服務器環境，都是穩定大于一切，不求最快，但求最穩定，求可用性，所以未經測試，不要再服務器使用新的軟件，比如nginx+php-fpm，生產環境中php各種掛啊，重啟下就好了，或者換apache就好了。

4、保密大于一切

現在各種艷照門漫天飛，各種路由器后門，所以說，涉及到數據，不保密是不行的。/ 8

三、涉及安全

1、ssh 更改默認端口（當然如果專業要黑你，掃描下就出來了），禁止root登錄，使用普通用戶+key認證+sudo規則+ip地址+用戶限制，使用hostdeny類似的防爆里破解軟件（超過幾次嘗試直接拉黑），篩選/etc/passwd中login的用戶。

2、防火墻

防火墻生產環境一定要開，并且要遵循最小原則，drop所有，然后放行需要的服務端口。

3、精細權限和控制粒度

能使用普通用戶啟動的服務堅決不使用root，把各種服務權限控制到最低，控制粒度要精細。

4、入侵檢測和日志監控

使用第三方軟件，時刻檢測系統關鍵文件以及各種服務配置文件的改動，比如,/etc/passwd,/etc/my.cnf，/etc/httpd/con/httpd.con等；使用集中化的日志監控體系，監控/var/log/secure，/etc/log/message，ftp上傳下載文件等報警錯誤日志；另外針對端口掃描，也可以使用一些第三方軟件，發現被掃描就直接拉入host.deny。這些信息對于系統被入侵后排錯很有幫助。有人說過，一個公司在安全投入的成本跟他被安全攻擊損失的成本成正比，安全是一個很大的話題，也是一個很基礎的工作，把基礎做好了，就能相當的提高系統安全性，其他的就是安全高手做的了 / 8

四、日常監控

1、系統運行監控

好多人踏入運維都是從監控做起，大的公司一般都有專業24小時監控運維。系統運行監控一般包括硬件占用率常見的有，內存，硬盤，cpu，網卡，os包括登錄監控，系統關鍵文件監控定期的監控可以預測出硬件損壞的概率，并且給調優帶來很實用的功能

2、服務運行監控

服務監控一般就是各種應用，web，db，lvs等，這一般都是監控一些指標在系統出現性能瓶頸的時候就能很快發現并解決。

3、日志監控

這里的日志監控跟安全的日志監控類似，但這里一般都是硬件，os，應用程序的報錯和警報信息監控在系統穩定運行的時候確實沒啥用，但是一旦出現問題，你又沒做監控，就會很被動了

五、性能調優

1、深入了解運行機制

其實按一年多的運維經驗來說，談調優根本就是紙上談兵，但是我只是想簡單總結下，如果有更深入的了解，我會更新。在對軟件進行優化之前，比如要深入了解一個軟件的運行機制，比如nginx和apache，大家都說nginx快，那就必須知道nginx為什么快，利用什么原理，處理請求比apache，并且要能跟別人用淺顯易懂的話說出/ 8

來，必要的時候還要能看懂源代碼，否則一切以參數為調優對象的文檔都是瞎談。

2、調優框架以及先后

熟悉了底層運行機制，就要有調優的框架和先后順序，比如數據庫出現瓶頸，好多人直接就去更改數據庫的配置文件，我的建議是，先根據瓶頸去分析，查看日志，寫出來調優方向，然后再入手，并且數據庫服務器調優應該是最后一步，最先的應該是硬件和操作系統，現在的數據庫服務器都是在各種測試之后才會發布的 適用于所有操作系統，不應該先從他入手。

3、每次只調一個參數

每次只調一個參數，這個相比大家都了解，調的多了，你就自己就迷糊了。

4、基準測試

判斷調優是否有用，和測試一個新版本軟件的穩定性和性能等方面，就必須要基準測試了，測試要涉及很多因素，測試是否接近業務真實需求這要看測試人的經驗了，相關資料大家可以參考《高性能mysql》第三版相當的好，我的老師曾說過，沒有放之四海皆準的參數，任何參數更改任何調優都必須符合業務場景，所以不要再谷歌什么什么調優了，對你的提升和業務環境的改善沒有長久作用。/ 8

六、運維心態

1、控制心態

很多rm-rf /data都在下班的前幾分鐘，都在煩躁的高峰，那么你還不打算控制下你的心態么，有人說了，煩躁也要上班，可是你可以在煩躁的時候盡量避免處理關鍵數據環境越是有壓力，越要冷靜，不然會損失更多。

大多人都有rm-rf /data/mysql的經歷，發現刪除之后，那種心情你可以想象一下，可是如果沒有備份，你急又有什么用，一般這種情況下，你就要冷靜想下最壞打算了，對于mysql來說，刪除了物理文件，一部分表還會存在內存中，所以斷開業務，但是不要關閉mysql數據庫，這對恢復很有幫助，并使用dd復制硬盤，然后你再進行恢復，當然了大多時候你就只能找數據恢復公司了。

試想一下，數據被刪了，你各種操作，關閉數據庫，然后修復，不但有可能覆蓋文件，還找不到內存中的表了。

2、對數據負責

生產環境不是兒戲，數據庫也不是兒戲，一定要對數據負責。不備份的后果是非常嚴重的。

3、追根究底

很多運維人員比較忙，遇到問題解決就不會再管了，記得去年一個客戶的網站老是打不開，經過php代碼報錯發現是session和whos_online損壞，前任運維是通過repair修復的，我就也這樣修復了，但是過了幾個小時，又出現了反復三四次之后，我就去谷歌數/ 8

據庫表莫名損壞原因：一是myisam的bug，二是mysqlbug，三是mysql在寫入過程中被kill，最后發現是內存不夠用，導致OOM kill了mysqld進程并且沒有swap分區，后臺監控內存是夠用的，最后升級物理內存解決。

4、測試和生產環境

在重要操作之前一定要看自己所在的機器，盡量避免多開窗口。/ 8

第五篇：運維故障處理思路

事件/故障處理應該要有什么思路 導讀：

在講解事件、故障處理思路前，我先講一個故障場景（以呼叫中心系統作為一例子）：

業務人員反映呼叫中心系統運行緩慢，部份電話在自助語言環節系統處理超時，話務轉人工座席，人工座席出現爆線情況。

運維人員開始忙活了，查資源使用情況、查服務是否正常、查日志是否報錯、查交易量還有沒有??時間不知不覺的在敲鍵盤、敲鍵盤、敲鍵盤中過去，但是原因還未定位。

經理過來了解情況：“系統恢復了嗎？”、“故障影響是什么？”、“交易中斷了嗎？”??

運維人員趕緊敲鍵盤，寫sql，看交易量；敲鍵盤，寫命令，看系統資源、情況??

最終，定位到問題原因是其中一個功能沒有控制返回數量，導致內存泄露。針對這個故障，業務希望運維能否更快的解決故障的恢復，經理希望制定優化呼叫中心故障處理流程，做了以下幾件事：

1.優先故障處理過程的時間——”能通過鼠標完成的工作，不要用鍵盤“ 2.提前發現故障，加強監控——“技術早于業務發現問題，監控不僅是報警，還要協助故障定位”

3.完善故障應急方案——“應急方案是最新的、準確的、簡單明了的” 4.長遠目標：故障自愈——”能固化的操作自動化，能機器做的讓機器做“ 下面將從故障常見的處理方法開始介紹，再從故障前的準備工作（完善監控、制定應急方案等方式）來解決經理提出的問題，并提出未來解決故障的想法。

1、常見的方法：

1）確定故障現象并初判問題影響

在處理故障前，運維人員首先要知道故障現象，故障現象直接決定故障應急方案的制定，這依賴于運維人員需要對應用系統的整體功能有一定的熟悉程度。確認了故障現象后，才能指導運維人員初判斷故障影響。2）應急恢復

運維最基本的指標就是系統可用性，應急恢復的時效性是系統可用性的關鍵指標。

有了上述故障現象與影響的判斷后，就可以制定故障應急操作，故障應急有很多，比如：

? ? ? ? ? ? ? 服務整體性能下降或異常，可以考慮重啟服務； 應用做過變更，可以考慮是否需要回切變更； 資源不足，可以考慮應急擴容；

應用性能問題，可以考慮調整應用參數、日志參數； 數據庫繁忙，可以考慮通過數據庫快照分析，優化SQL； 應用功能設計有誤，可以考慮緊急關閉功能菜單； 還有很多??

另外，需要補充的是，在故障應急前，在有條件的情況需要保存當前系統場景，比如在殺進程前，可以先抓個CORE文件或數據庫快照文件。

3）快速定位故障原因

? 是否為偶發性、是否可重現

故障現象是否可以重現，對于快速解決問題很重要，能重現說明總會有辦法或工具幫助我們定位到問題原因，而且能重現的故障往往可能是服務異常、變更等工作導致的問題。

但，如果故障是偶發性的，是有極小概率出現的，則比較難排查，這依賴于系統是否有足夠的故障期間的現場信息來決定是否可以定位到總是原因。

? 是否進行過相關變更

大部份故障是由于變更導致，確定故障現象后，如果有應的變更，有助于從變更角度出現分析是否是變更引起，進而快速定位故障并準備好回切等應急方案。

? 是否可縮小范圍

一方面應用系統提倡解耦，一支交易會流經不同的應用系統及模塊；另一方面，故障可能由于應用、系統軟件、硬件、網絡等環節的問題。在排查故障原因時應該避免全面性的排查，建議先把問題范圍縮小到一定程序后再開始協調關聯團隊排查。

? 關聯方配合分析問題 與第（3）點避免同時各關聯團隊同時無頭緒的排查的同時，對于牽頭方在縮小范圍后需要開放的態度去請求關聯方配合定位，而對于關聯方則需要有積極配合的工作態度。

? 是否有足夠的日志

定位故障原因，最常用的方法就是分析應用日志，對運維人員不僅需要知道業務功能對應哪個服務進程，還要知道這個服務進程對應的哪些應用日志，并具備一些簡單的應用日志異常錯誤的判斷能力。

? 是否有core或dump等文件

故障期間的系統現場很重要，這個在故障應急前建議在有條件的情況下留下系統現場的文件，比如COREDUMP，或TRACE采集信息等，備份好一些可能被覆蓋的日志等。

上述是一般性的故障常見的方法，在重大故障或多方處理的故障出現時，往往小范圍的排查不利于快速解決，需要啟動緊急處理的流程，建議可以考慮以下溝通：

? ? ? ? ? ? 召集相關人員 描述故障現狀

說明正常應用邏輯流程 陳述變更

排查進展，展示信息 領導決策

2、完善監控

1）從監控可視化上完善

完善的監控策略需要有統一的可視化操作界面，在制定完善的監控策略后，故障處理人員需要能夠快速的看到相應的運行數據，比如：能夠看到一段時間的趨勢、故障期間的數據表現、性能分析的情況等等數據，且這些數據可以提前制定好策略直接推出分析結果給故障處理人員，這樣就大大提高了故障的處理效率，以呼叫中心系統為例，需要提前配置好以下實時交易數據，以便故障定位：

-交易性能數據：平均交易耗時、系統內部模塊交易耗時（IVR交易耗時、接口總線交易耗時）、關聯系統交易耗時（核心交易耗時、工單系統交易耗時等）-重要交易指標數據：交易量、IVR交易量、話務量、座席通話率、核心交易筆數、工單等系統交易量

-交易異常情況數據：交易成功率、失敗率、錯誤碼最多交易-按服務器分析交易數據：按server統計各服務交易處理筆數，交易總耗時 有了以上交易數據，并通過監控按一定頻率統計，運維人員在出現故障時，通過鼠標即點擊即可看到故障什么時候開始，是系統內部有問題還是關聯系統有問題，最突出的交易是哪一支，各服務器交易量是否均衡等情況。

2）從監控面上完善

監控最基本的工作就是實現對負載均衡設備、網絡設備、服務器、存儲設備、安全設備、數據庫、中間件及應用軟件等IT資源的全面監控管理。在應用軟件類的監控工作中，不僅需要有服務進程、端口等監控，還需要有業務、交易層的監控。

全面性的應用監控可以讓故障提前預警，并保存了影響應用運行環境的數據，以縮短故障處理時間。

3）從監控告警上完善

完善的監控策略需要有清晰的監控告警提示，值班人員要以根據監控告警即可作出簡單的問題定位與應急處理方案。比如類似以下的監控短信：

22時，【理財應用系統】中【應用服務器LC_APPsvrA 10.2.111.111】的【前置應用模塊】出現【應用端口：9080】不存在，該端口作用【提供理財應用處理（負載均衡部署）】，原因可能為【SERVER1服務異常停止】，監控系統己進行以下應急處理【自動執行端口進程啟動】，該事件緊急程度【高】。管理員可以通過短信內容看到哪個系統、哪個應用、哪個模塊出了什么問題，可能是什么原因，對業務有什么影響，是否需要馬上處理（比如凌晨出現此預警是否可以延遲到次日處理）等信息。

4)從監控分析上完善

完善的監控策略不僅需要有實時的數據告警，也要有匯總數據的分析告警,實時數據分析的告警的重要性不用多說，對于匯總分析的數據則能發現潛在風險，同時也為分析疑難雜癥提供幫忙。

5)從監控主動性上完善

監控不僅僅是報警，它還可以做得更多，只要我們想辦法賦予它主動解決事件的規則，它便有為管理員處理故障的能力。

3、應急方案

提前制定好故障應急方案是很有必要的，但在日常工作過程中我們的應急方案遇到一些問題： 1）應急方案缺乏持續維護，缺乏演練，信息不及時、不準確； 2）應急方案過于追求大而全，導致不利于閱讀與使用； 3）應急方案形式大于實際使用效果，方案針對性不強； 4）只關注應急方案的內容，但沒有關注運維人員對方案的理解； 針對上述常見問題，我認為應急方案需要做到以下幾點：

1）內容精&簡

很多人可能會認為故障出現的形式各種各樣，所以應急方案需要涉及到方方面面。但實際的故障處理過程中，我們可以發現其實我們的應急措施往往重復使用幾個常用的步驟，所以我認為應急方案要有重點，如果一個應急方案可以應對平時故障處理80%的場景，那這個應急手冊應該是合格的。過于追求影響應用系統方方面面的內容，會導致這個方案可讀性變差，最終變更一個應付檢查的文檔。以下是我覺得應用系統應急方案應該有的內容：（1）系統級：

能知道當前應用系統在整個交易中的角色，當前系統出現問題或上下游出現問題時，可以知道如何配合上下游分析問題，比如：上下游系統如何通訊，通訊是否有唯一的關鍵字等。

另外，系統級里還涉及一些基本應急操作，比如擴容、系統及網絡參數調整等。（2）服務級：

能知道這個服務影響什么業務，服務涉及的日志、程序、配置文件在哪里，如何檢查服務是否正常，如何重啟服務，如何調整應用級參數等。（3）交易級：

能知道如何查到某支或某類交易出現了問題，是大面積、局部，還是偶發性問題，能用數據說明交易影響的情況，能定位到交易報錯的信息。這里最常用的方法就是數據庫查詢或工具的使用。

知道最重要的交易如何檢查是否正常，重要的定時任務的應急處理方案，比如開業、換日、對賬的時間要求及應急措施。（4）輔助工具的使用：

有時候，需要借助一些工具或自動化工具輔助分析并應急，這時需要有輔助工具如何使用的方法。（5）溝通方案：

溝通方案涉及通訊錄，包括上下游系統、第三方單位、業務部門等渠道。（6）其它：

上述5點內容如何都完備，相信這個應急手冊己可以解決80%的故障恢復工作。

2）應急方案是一項持續的工作

有了應急方案，如何讓運維人員持續去更新是難點。我認為要解決這個難點，需要先讓運維人員經常使用這個手冊。如果一個手冊沒有場景可以用，那就需要管理者為運維人員創造機會去使用這個手冊，比如應急演練。

3）關注運維人員對應用關鍵信息的認識

前兩點關注了手冊，最后一點我覺得有必要關注使用這個手冊的人。有些運維人員認為應用運維人員沒有能力去把應用系統本身的內容了解得很透徹，所以應用運維人員在故障處理過程中的地位很尷尬，運維人員掌握操作權，但卻不知道應該操作什么。

對此，我認同應用運維人員不需要掌握應用系統的業務功能，但我覺得就對應用系統本身來講應用運維人員需要具備以下最基本的能力：（1）知道應用系統這個是干什么的，基本的業務是什么；（2）知道應用架構部署、上下游系統邏輯關系；

（3）知道應用下的服務的作用、端口、服務級的應急處理，日志等數據信息如何找到并簡單定位。

（4）知道應用系統重要的時間點及任務，比如開業、停業、換日、定時任務的時間點以及如何判斷這些任務是否正確（5）知道最重要的幾支交易的流程；（6）知道常見數據庫表結構，并能使用。

4、智能化事件處理

處理方法如下圖（詳細的智能化涉及監控、規則引擎、配置工具、CMDB、應用配置庫等模塊協同工作，具體介紹后續分析）