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