【正文】 性能下降或異常，可以考慮重啟服務(wù)； 應(yīng)用做過變更，可以考慮是否需要回切變更； 資源不足，可以考慮應(yīng)急擴(kuò)容；應(yīng)用性能問題，可以考慮調(diào)整應(yīng)用參數(shù)、日志參數(shù)； 數(shù)據(jù)庫繁忙，可以考慮通過數(shù)據(jù)庫快照分析，優(yōu)化SQL； 應(yīng)用功能設(shè)計(jì)有誤，可以考慮緊急關(guān)閉功能菜單； 還有很多??另外，需要補(bǔ)充的是，在故障應(yīng)急前，在有條件的情況需要保存當(dāng)前系統(tǒng)場景，比如在殺進(jìn)程前，可以先抓個CORE文件或數(shù)據(jù)庫快照文件。 2）應(yīng)急恢復(fù)運(yùn)維最基本的指標(biāo)就是系統(tǒng)可用性，應(yīng)急恢復(fù)的時效性是系統(tǒng)可用性的關(guān)鍵指標(biāo)。常見的方法：1）確定故障現(xiàn)象并初判問題影響在處理故障前，運(yùn)維人員首先要知道故障現(xiàn)象，故障現(xiàn)象直接決定故障應(yīng)急方案的制定，這依賴于運(yùn)維人員需要對應(yīng)用系統(tǒng)的整體功能有一定的熟悉程度。經(jīng)理過來了解情況：“系統(tǒng)恢復(fù)了嗎？”、“故障影響是什么？”、“交易中斷了嗎？”??運(yùn)維人員趕緊敲鍵盤，寫sql，看交易量；敲鍵盤，寫命令，看系統(tǒng)資源、情況??最終，定位到問題原因是其中一個功能沒有控制返回數(shù)量，導(dǎo)致內(nèi)存泄露。/ 8第四篇：運(yùn)維故障處理思路事件/故障處理應(yīng)該要有什么思路 導(dǎo)讀：在講解事件、故障處理思路前，我先講一個故障場景（以呼叫中心系統(tǒng)作為一例子）：業(yè)務(wù)人員反映呼叫中心系統(tǒng)運(yùn)行緩慢，部份電話在自助語言環(huán)節(jié)系統(tǒng)處理超時，話務(wù)轉(zhuǎn)人工座席，人工座席出現(xiàn)爆線情況。追根究底很多運(yùn)維人員比較忙，遇到問題解決就不會再管了，記得去年一個客戶的網(wǎng)站老是打不開，經(jīng)過php代碼報錯發(fā)現(xiàn)是session和whos_online損壞，前任運(yùn)維是通過repair修復(fù)的，我就也這樣修復(fù)了，但是過了幾個小時，又出現(xiàn)了反復(fù)三四次之后，我就去谷歌數(shù)/ 8據(jù)庫表莫名損壞原因：一是myisam的bug，二是mysqlbug，三是mysql在寫入過程中被kill，最后發(fā)現(xiàn)是內(nèi)存不夠用，導(dǎo)致OOM kill了mysqld進(jìn)程并且沒有swap分區(qū)，后臺監(jiān)控內(nèi)存是夠用的，最后升級物理內(nèi)存解決。對數(shù)據(jù)負(fù)責(zé)生產(chǎn)環(huán)境不是兒戲，數(shù)據(jù)庫也不是兒戲，一定要對數(shù)據(jù)負(fù)責(zé)。大多人都有rmrf /data/mysql的經(jīng)歷，發(fā)現(xiàn)刪除之后，那種心情你可以想象一下，可是如果沒有備份，你急又有什么用，一般這種情況下，你就要冷靜想下最壞打算了，對于mysql來說，刪除了物理文件，一部分表還會存在內(nèi)存中，所以斷開業(yè)務(wù)，但是不要關(guān)閉mysql數(shù)據(jù)庫，這對恢復(fù)很有幫助，并使用dd復(fù)制硬盤，然后你再進(jìn)行恢復(fù)，當(dāng)然了大多時候你就只能找數(shù)據(jù)恢復(fù)公司了?；鶞?zhǔn)測試判斷調(diào)優(yōu)是否有用，和測試一個新版本軟件的穩(wěn)定性和性能等方面，就必須要基準(zhǔn)測試了，測試要涉及很多因素，測試是否接近業(yè)務(wù)真實(shí)需求這要看測試人的經(jīng)驗(yàn)了，相關(guān)資料大家可以參考《高性能mysql》第三版相當(dāng)?shù)暮?，我的老師曾說過，沒有放之四海皆準(zhǔn)的參數(shù)，任何參數(shù)更改任何調(diào)優(yōu)都必須符合業(yè)務(wù)場景，所以不要再谷歌什么什么調(diào)優(yōu)了，對你的提升和業(yè)務(wù)環(huán)境的改善沒有長久作用。調(diào)優(yōu)框架以及先后熟悉了底層運(yùn)行機(jī)制，就要有調(diào)優(yōu)的框架和先后順序，比如數(shù)據(jù)庫出現(xiàn)瓶頸，好多人直接就去更改數(shù)據(jù)庫的配置文件，我的建議是，先根據(jù)瓶頸去分析，查看日志，寫出來調(diào)優(yōu)方向，然后再入手，并且數(shù)據(jù)庫服務(wù)器調(diào)優(yōu)應(yīng)該是最后一步，最先的應(yīng)該是硬件和操作系統(tǒng)，現(xiàn)在的數(shù)據(jù)庫服務(wù)器都是在各種測試之后才會發(fā)布的 適用于所有操作系統(tǒng)，不應(yīng)該先從他入手。日志監(jiān)控這里的日志監(jiān)控跟安全的日志監(jiān)控類似，但這里一般都是硬件，os，應(yīng)用程序的報錯和警報信息監(jiān)控在系統(tǒng)穩(wěn)定運(yùn)行的時候確實(shí)沒啥用，但是一旦出現(xiàn)問題，你又沒做監(jiān)控，就會很被動了五、性能調(diào)優(yōu)深入了解運(yùn)行機(jī)制其實(shí)按一年多的運(yùn)維經(jīng)驗(yàn)來說，談?wù){(diào)優(yōu)根本就是紙上談兵，但是我只是想簡單總結(jié)下，如果有更深入的了解，我會更新。有人說過，一個公司在安全投入的成本跟他被安全攻擊損失的成本成正比，安全是一個很大的話題，也是一個很基礎(chǔ)的工作，把基礎(chǔ)做好了，就能相當(dāng)?shù)奶岣呦到y(tǒng)安全性，其他的就是安全高手做的了 / 8四、日常監(jiān)控系統(tǒng)運(yùn)行監(jiān)控好多人踏入運(yùn)維都是從監(jiān)控做起，大的公司一般都有專業(yè)24小時監(jiān)控運(yùn)維。入侵檢測和日志監(jiān)控使用第三方軟件，時刻檢測系統(tǒng)關(guān)鍵文件以及各種服務(wù)配置文件的改動，比如,/etc/passwd,/etc/，/etc/d/con/；使用集中化的日志監(jiān)控體系，監(jiān)控/var/log/secure，/etc/log/message，ftp上傳下載文件等報警錯誤日志；另外針對端口掃描，也可以使用一些第三方軟件。防火墻防火墻生產(chǎn)環(huán)境一定要開，并且要遵循最小原則，drop所有，然后放行需要的服務(wù)端口。保密大于一切現(xiàn)在各種艷照門漫天飛，各種路由器后門，所以說，涉及到數(shù)據(jù)，不保密是不行的。如果真需要刪除，一定要謹(jǐn)慎。另外，修改配置文件時，建議注釋原選項(xiàng)，然后再復(fù)制，修改 / 8再者說，如果第一個例子中，有數(shù)據(jù)庫備份，那rsync的誤操作不久沒事了吧，所以說丟數(shù)據(jù)庫非一朝一夕，隨便備份一個就不用那么慘。通常我們運(yùn)維接到任務(wù)，都會進(jìn)行簡單查看如果無法解決，就請求他人幫忙，可是當(dāng)問題焦頭爛額的時候，客服主管（懂點(diǎn)linux），網(wǎng)管，你上司一起調(diào)試一個服務(wù)器，當(dāng)你各種百度,各種對照，完了發(fā)現(xiàn)，你的服務(wù)器配置文件，跟上次你修改不一樣了，然后再改回來，然后再谷歌，興沖沖發(fā)現(xiàn)問題，解決了，別人卻告訴你，他也解決了，修改的是不同的參數(shù)……這個，我就真不知道哪個是問題真正的原因了，當(dāng)然這還是好的，問題解決了，皆大歡喜，可是你遇到過你剛修改的文件，測試無效，再去修改發(fā)現(xiàn)文件又被修改的時候呢？真的很惱火，切忌多人操作。大家可能會說，我按了這么多次都沒出過錯，不用怕，我只想說當(dāng)出現(xiàn)一次你就明白了，不要以為那些運(yùn)維事故都是在別人身上，如果你不注意，下一個就是你。第二個例子是關(guān)于文件同步的，大家都知道rsync同步很快，可是他刪除文件的速度大大超過了rmrf,在rsync中有一個命令是，以某目錄為準(zhǔn)同步某文件（如果第一個目錄是空的，那么結(jié)果可想而知），源目錄（有數(shù)據(jù)的）就會被刪除，當(dāng)初我就是因?yàn)檎`操作，以及缺乏測試，就目錄寫反了，關(guān)鍵是沒有備份……生產(chǎn)環(huán)境數(shù)據(jù)被刪了沒備份，大家自己想后果吧，其重要性不言而喻。當(dāng)然還可以借助ITIL工具對CMDB資產(chǎn)的關(guān)聯(lián)進(jìn)行深入分析。你甚至有可能找到真正的故障源頭。 在服務(wù)器上運(yùn)行的都是些啥？這個故障看起來是和 IO/硬件/網(wǎng)絡(luò) 或者 系統(tǒng)配置(有問題的代碼、系統(tǒng)內(nèi)核調(diào)優(yōu), …)相關(guān)。 后端的狀況如何？健康狀況檢查是否成功？是前端還是后端的隊(duì)列大小達(dá)到最大值了？ Varnish。看看有沒有結(jié)構(gòu)損壞的表，是否有innodb修復(fù)進(jìn)程在運(yùn)行，是否有disk/index/query 。查找訪問和錯誤日志, 直接找 5xx 錯誤, 再看看是否有 limit_zone 錯誤。 Apache amp。 是否有某個定時任務(wù)運(yùn)行過于頻繁? 是否有些用戶提交了隱藏的定時任務(wù)?在出現(xiàn)故障的時候，是否正好有某個備份任務(wù)在執(zhí)行？十三、應(yīng)用系統(tǒng)日志這里邊可分析的東西就多了, 不過恐怕你作為運(yùn)維人員是沒功夫去仔細(xì)研究它的。 do crontablu $user。 查看錯誤和警告消息，比如看看是不是很多關(guān)于連接數(shù)過多導(dǎo)致？ 看看是否有硬件錯誤或文件系統(tǒng)錯誤?分析是否能將這些錯誤事件和前面發(fā)現(xiàn)的疑點(diǎn)進(jìn)行時間上的比對。 你還可以看一下 Linux TCP tuning 了解網(wǎng)絡(luò)性能調(diào)優(yōu)的一些要點(diǎn)。 SWAP交換的設(shè)置是什么？對于工作站來說swappinness 設(shè)為 60 就很好, 不過對于服務(wù)器就太糟了：你最好永遠(yuǎn)不要讓服務(wù)器做SWAP交換，不然對磁盤的讀寫會鎖死SWAP進(jìn)程。 你的中斷請求是否是均衡地分配給CPU處理，還是會有某個CPU的核因?yàn)榇罅康木W(wǎng)絡(luò)中斷請求或者RAID請求而過載了？ 檢查磁盤使用量：服務(wù)器硬盤是否已滿? 是否開啟了swap交換模式(si/so)?CPU被誰占用：系統(tǒng)進(jìn)程? 用戶進(jìn)程? 虛擬機(jī)?dstat 是我的最愛。 根據(jù)這些情況可以大致了解硬件問題的來源和性能改進(jìn)的辦法。 還有空余的內(nèi)存嗎? 服務(wù)器是否正在內(nèi)存和硬盤之間進(jìn)行swap?還有剩余