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