記週日一次故障意外
找了waf工程師問，並且我這裡也在同步測試，tcping 網域名稱沒返回，不得不「ctrl+c」 中斷退出
說解析異常，222這個位址不通，然後給我們明確回覆說 47.91.170.222不是waf的入口 ip，切別的ip是沒用的（因為解析異常之後，我是有叫他切到別的能用的waf ip上的），這個222的ip是阿里雲的ip，流量多半被解析到222的ip上了！（嚇壞我了，第一次遇到這種情況，難道被惡意劫持了？！）
只能聯絡網域名稱服務商協助排查，看下解析異常的原因
然後一連串悲劇來了，真是屋漏偏逢連夜雨！！！！
（1）遠端桌面連不上公司電腦——》因為公司電腦一直有登各種阿里雲賬號，不需要重新收驗證碼。telnet遠端桌面的埠是通的，應該是遠端桌面ngrok服務有問題啦，然後我忘記具體部署ngrok的伺服器在哪了，幸好最後人肉搜尋找到，命令重啟下，還是連不上
（2）家裡電腦翻不了牆——》 要從谷歌文件上拿下ngrok重啟的命令【上面（1）我是搜尋歷史命令重啟的，很難說自己有沒有記錯】
（3）登入阿里雲想提個工單問下情況，然後順帶**聯絡售後。因為那個管理網域名稱的阿里雲賬號在我家電腦已經沒有快取了，不得不重新收下驗證碼，收驗證碼的手機經常是我們經理帶著的。然後最坑爹的事也發生了，我們經理竟然沒把手機帶在身邊，說放在公司了，自己還在外面 = =（內心異常崩潰，估計要回公司一趟，本來17點是答應老闆還要接我手提回家的）
遠端桌面也好了，遠端桌面也用到這個根網域名稱，一開始連不上估計也是跟流量解析到阿里有關。
一些想法：
真的不出事，不知道潛在隱患 = =
（1）離線得儲存個線上伺服器相關的重要文件 ——》fq機器經常抽風，導致fq翻不了，然後文件看不到
（2）為啥監控網域名稱的指令碼沒發監控提醒了？！ ——》 太相信以前人寫的監控指令碼，不用說這指令碼肯定是有問題的，明天上班認認真真檢查下！
（3）網域名稱快過期，阿里應該是有提醒的（反正ecs，rds等是會有提醒的），肯定是經理帶的手機收到資訊，周一改到我手機好了，提醒我不是更好？（手機都不帶，真是害死本寶寶了，要不是阿里有個代充服務，早就要滾回公司，可憐兮兮孤孤單單，忍受著飢寒沒飯吃，聯絡老闆開大門進去處理，最終導致我那可憐的手提電腦等不到主人接它肥家 ，我也成了乙個失信之人，不是說好5點過來拿電腦的麼= =，處理完我真的是飛車過去了）
甚至如果處理不及時，被上層發現，輕則興師問罪，重則扣錢解雇。。。e$%^#……*@ 想想運維確實是個高危職業，週末別跑太遠了，出故障確實拿人命呢 = =
記一次manila故障
排查過程 1.檢視manila的日誌，api.log scheduler.log share.log,排程日誌最具參考性，但是顯示建立成功 實際狀態為creating 排到share時出現大量報錯 get all share usage failed 2.檢查後端儲存，節點均正常 排查過程 1.關閉...
記一次Postgres CPU爆滿故障
公司專案測試環境呼叫某些介面的時候，伺服器立即崩潰，並一定時間內無法提供服務。第一反應是伺服器需要公升配啦，花錢解決一切！畢竟測試伺服器配置確實不高，2cpu 4gib，能幹啥？不過問題是今天突然發生的，而且說崩就崩。憑著嚴謹的態度，還是要刨根問底地找下問題。記憶體占用並不大，忘記截圖了，反正看下來...
記一次緊急故障的維修
很抱歉，本來想寫一篇很有特點的文章給廣大午飯，當我完成1 2的時候才發現文件丟失了。於是還得重頭來過，寫一篇短文來給一些新技術人員提供乙份參考經驗吧。本文沒有什麼高深的技術內容，但是也是乙份經驗的分享。週六接到公司的緊急 公司伺服器出問題了。於是火速從家裡趕到公司。才發現是出了大事。公司機房的一台空...