艾銻知識 |運維人員處理服務器故障的方法總結

2020-03-10 14:33 作者：艾銻無限 瀏覽量：

據不完全統計,中國有近5000萬家中小微企業,這個數據隨著互聯網的發展還在持續增長,但這些企業的存活率是非常低的,60%的初創企業活不過1年,30%的初創企業活不過3年,還有超過9%的企業只有5年左右的生

存期,剩下不到1%的企業活過5年以上,幸運的可以達到10年,甚至更長一些.

為什么中小微企業的存活率這么低呢?
透過成千上萬的失敗案例,我們總結了以下五大方面的原因:

第一,創業失敗創始人難辭其咎,我們在學校里是沒有一堂課是教如何創業,如何才能創業成功,即使現在有很多大學嘗試著在學校開辦一些創業的課程,也不系統,更不專業,因為創業是一件極其復雜的工作,是需要多項

技能的集合以及熟練的運用才有可能應對突如其來的變化,創業初期就像一艘孤獨的小船面對波濤洶涌的大海,但船長從來都沒有開過任何一艘船駛出過海港,風浪來的時候,只有慌張和恐懼,最后被海水吞沒.

第二,創業失敗是價值觀不統一,方向不一致,團隊不團結,風平浪靜,風和日麗,其實沒什么關系,大家都在享受陽光帶來的美好和快樂,只有遇到風浪,生死攸關或個人利益受到極大沖突時,人性的弱點才會突顯,當每個人

只盯著個人得失或眼光短淺時,如果這個時候創始人沒有力挽狂瀾,強大的信念和人格魅力來一統所有人的行動準則,在危機中遲疑,就等于在死神面前跳舞,當年阿里的“中國供應商”客戶涉嫌欺詐事件,如果不是馬云明

察秋毫,當即立斷,我相信也不會有今天阿里世界霸主的地位.

第三,創業失敗是固步自封,看不見高山,如果我們只能看見自己的山最高,沒有走出去,沒有學習的心態,沒有敬畏之心,很快時代就會把我們淘汰,當年的諾基亞,柯達就是最好的例子.無論企業多大,都要有一顆創業的心,

永遠相信還能做的更好,還可以再創新,還會想出其它的可能性.真正的對手不在外面,而在我們心中,心中無敵,才能無敵于天下.

第四,創業失敗是誤解了”客戶是上帝”,上帝并不是時時都知道自己要什么,我們不能只限于客戶表面的表達就決定了他們的需求,很多企業死就死在客戶的假需求中,看起來好像是客戶追求的產品,需要的服務,但實際

當產品生產出來,當服務送到客戶面前,并沒有真正吸引到客戶的注意,愿意為此而買單,核心本質就是我們曲解了”客戶是上帝”這句話,真正的上帝是不會當自己是至高無上的,也不會對品質無底限的追求,更不會對服

務沒有節制要求,其實客戶就是客戶,他們絕大部分人都是普通人,有著普通人的欲望,有著普通人的不滿足,有著普通人想要花更少的錢卻要得到更多的意識,他們的只忠誠于更便宜更高的品質,這一切都是企業需要認

知到的本質,不然你的”上帝”是不會為你持續付費的.

第五,創業失敗是講多了人情講少了制度,公司小,三五個人可以不需要任何制度,甚至也不需要任何系統,因為那時彼此聯結非常深,情感的能量可以喚醒每個人的斗志和決心 ,但當企業發展到幾十個人甚至幾百個人

時,那種深深的聯結感很難在感受到,人性的弱點就會被環境所喚醒,就會被利益所綁架,就會被自私所控制,但也不是有了制度就有了保障,制度是人的工具,制度最終是服務于人,只有促進發展的制度,可能激勵人性向

善的制度才能長久, 反之亦然.

如果你想想創立一家公司?

如果你是一家剛剛開始創業的公司?

如果你現在在創業的過程中遇到了挑戰?

結合上面的五大常見創業失敗,我們總結出來了五個可以讓你有更大成功機率的法則,可以讓你活的更久一些,但不保證你一定成功,因為事事變化,因緣和合,萬法無常,只能隨機而變.

第一法則:準備自己

創始人需要自我審視,首先要準備好自我犧牲的精神,要做好大海有風暴的思想準備,其次利用一切可以實踐的機會去鍛煉自己的綜合能力,不僅僅相信前輩和書本的聲音,更需要相信實戰后帶來的思考和反思.即要有

遠大的理想和抱負,又要有腳踏實地做好每一件事的決心.

第二法則:認識自我

創始人要極早的認識自我,想清楚為什么要創業比創業更重要,清晰明確的了解自己的價值是什么?什么是自己會堅持的,什么是自己抗拒的,混亂的價值觀就會吸引五花八門的人,企業內部的斗爭都是創始人自己思想

的斗爭,初創企業所呈現出來的一切現象都是創始人內在的顯化.當年阿里快速成長,內部也出現了一系列的問題,但極其智慧的馬云沒有去解決這些問題,反而把自己關在道觀中整整7天,最后終于想明白了三個問題:

我要什么,我有什么,我要放棄什么,當他想清晰這三個問題后,并向全公司傳遞出來,最后所有那些紛繁復雜的問題都不解自明.

第三法則:持續打開

創始人的天花板就是企業的天花板,企業無法突破,就是創始人沒有突破自己,突破其實不容易,因為固有的觀念就像萬里長城一樣,非一日之功,是多少個春夏秋冬,嚴寒酷暑的積累和沉淀,這些不是沒有價值,而是幫助

過我們創了價值,讓我們來到了今天這一步,但如果我們期望有一個更大的世界,就需要放下它們,放下我們曾經一直的堅持和執著,打開自己,讓自己接納一個全新的可能性,也許過不了多久,我們又會把這些新的東西奉

為圭臬但只要我們還想看到一個更大的可能性,就需要再次打開自己,重新建立認知,我們一生都是在打開和重建過程中,直到生命的終結,又一切回歸原點.

第四法則:回歸本質

創始人剛開始需要和團隊一起參與戰斗,甚至做具體細節工作,因為初創需要激情來點燃,而創始人是這個團隊最有激情的一個人,初創團隊需要有人帶動去點燃更大的燃料.當所有團隊和部門走向正軌時,創始人更大

的價值是深度的思考,有效的區分,精神的引領和正確的選擇.

企業越來越大,事情就會越來越多,如果沒有一個清醒的大腦保持深度的思考,就像讓企業很多人很忙,忙是一種現象,并不代表有價值,只有透過深度思考發現事物的本質,才知道忙什么才是最重要的,

懂得有效的區分是一個領導者必須掌握的能力, 《尼布爾的祈禱文》說:”上帝，請賜予我平靜，去接受我無法改變的。給予我勇氣，去改變我能改變的，賜我智慧，分辨這兩者的區別。”只有具備分辨的智慧,才不

會讓自己誤入歧途.

創始人要有強大的精神力量,讓所有員工感受到這股力量,因為所有的成功都離不開一個偉大的精神領袖,就像蘋果的喬布斯,微軟的比爾蓋茨和阿里的馬云.

選擇比努力更重要,這句話告訴我們順勢而為的選擇可以讓我們在同樣的努力情況下獲得不同的結果,如何才能具備這樣明智選擇的能力呢,強大的深度思考能力和有效的區分能力就可以幫到我們看見正確的選擇.

第五法則:創造系統

創始人是人,是人就會有七情六欲,就會有生老病死,就會有悲歡離合,這些人性的因素會讓我們很不穩定,但企業能持久有效的運轉一定是在穩定的能量下運行,所以不能始終靠人來推動,企業想要活的久一定是有內生

的系統,只有建立一個自動運轉的系統才能保持穩定健康的成長.
以上的分享像從管子里看豹，只看見豹身上的一塊花斑，看不到全豹,以此拋磚引玉,希望有更多人可以把自己創業的經歷和經驗分享出來,從而讓我們更全面的看見一家企業怎樣做才能活得久,活的好,活的更有價

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

一、盡可能搞清楚問題的前因后果
不要一下子就扎到服務器前面，你需要先搞明白對這臺服務器有多少已知的情況，還有故障的具體情況。不然你很可能就是在無的放矢。
必須搞清楚的問題有：
故障的表現是什么？無響應？報錯？
故障是什么時候發現的？
故障是否可重現？
有沒有出現的規律（比如每小時出現一次）
最后一次對整個平臺進行更新的內容是什么（代碼、服務器等）？
故障影響的特定用戶群是什么樣的(已登錄的, 退出的, 某個地域的…)?
基礎架構（物理的、邏輯的）的文檔是否能找到?
是否有監控平臺可用? （比如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; 后端的狀況如何？健康狀況檢查是否成功？是前端還是后端的隊列大小達到最大值了？