運維成長中的那些“囧”與“惑”
有人說技術圈也是一個江湖，技術中的高手就是大俠，彈指如飛氣定神閒間化問題於虛無；而初入江湖的菜鳥，手足無措望問題而怯步。
在行走江湖的過程中，我們不斷積累功力，從菜鳥到技術牛人，經歷了若干囧與惑，曾經讓我們大惑不解的問題或許在現在看來很可笑，但正是這些問題成為我們成長中難以忘記的印記。
一、記憶體之爭
1. 真的需要加記憶體？
曾在一家電商公司工作時，有一段時間開發部和運維部爭執記憶體的使用率問題，最後運維部大獲全勝。
事情起因:
開發部任務很緊，需要在六個月內上線一套新系統。
連續每月週末加班，加之程式碼測試工作沒跟上，系統的BUG很多，到快上線的一個月，總感覺系統和前臺執行慢，然後到處找原因。
- 運維部連續幾天監控和分析，發現是程式碼方面的問題，但還沒上報技術總監。
- 一日，一開發工程師似乎發現了問題的癥結，向上面報告說是“系統記憶體佔用率高，需要增加伺服器記憶體”，並截圖為證。
記憶體使用率為：14873/16062=92.6% ,所以導致系統執行慢。
- 開發部領導向技術總監彙報，說明情況並申請購買50根16G記憶體加到之前的伺服器上。
由於新購50根伺服器記憶體，需要增加一筆費用，上面批覆的流程又比較長，上線的時間又快近了，技術總監有點猶豫，問運維部怎麼看這個問題。
- 運維部拿出了幾天來的分析結果，論證了是程式碼方面的問題，並就記憶體使用率向技術總監做了解釋。
2. LINUX的可用記憶體到底怎樣計算？
LINUX是儘可能使用記憶體的原則，核心會把剩餘的記憶體申請為cache，而cache不屬於free範疇。
當系統執行時間較久，會發現cached很大，對於有頻繁檔案讀寫操作的系統，這種現象會更加明顯。
直觀的看，此時free的記憶體比較小，但並不代表可用的記憶體小，當一個程式需要申請較大的記憶體時，如果free的記憶體不夠，核心會把部分cache的記憶體回收，回收的記憶體再分配給應用程式。
所以對於linux系統，可用於分配的記憶體不只是free的記憶體，還包括cache的記憶體（其實還包括buffers）。
- 第一行是從OS的角度來看，因為對於OS，buffers/cached 都是屬於被使用，所以他的可用記憶體是1188MB;
- 第二行是從應用程式角度來看，對於應用程式來說，buffers/cached 是等於可用的。
因為buffer/cached是為了提高檔案讀取的效能，當應用程式需要用到記憶體的時候，buffer/cached會很快地被回收。
所以從應用程式的角度來說，可用記憶體=系統free memory+buffers+cached。
由此看來LINUX的記憶體使用率實際為 :
1-(11289/16062)=30%
這樣一分析，完全沒有必要增加記憶體，主要還是要提升程式碼的質量和改善應用程式。
小結：
這次記憶體之爭，用公司同事的話說“運維部很拉風，開發部很傷神”（以前開發部的人都很神氣，領導都是表揚）。
經過開發部調整程式碼後，系統和前臺執行都比以前快些和穩定了，運維部在公司一時人氣大旺。
二、掩碼之“惑”
從事網路運維的朋友，對掩碼是再熟悉不過了，這個看似簡單的問題曾讓很多人都困惑過。
記得剛從事網路運維工作的時候，在一家系統整合公司，給甲方做專案。
工作中經常會需要提交一些網路策略，網路策略的模板都是固定的，一般是寫好後先發郵件給甲方的網路主管，審批後由甲方的網路工程師進行開通。
一次提交網路策略的時候，對方的網路主管說你“這個掩碼有問題，請細化”。
我忙開啟郵件，仔細看了看網路策略，沒看出有什麼問題。
打電話與對方溝通，才明白對方認為這個源地址的掩碼128太大，這樣開策略會一下放行很多主機，所以需要細化縮小範圍。
暈！子網掩碼是用來表明一個IP地址的哪些“位”標識的是主機所在的子網，以及哪些“位”標識的是主機。
一個子網根據不同的劃分可容納的主機數是不同的，而且子網掩碼不能單獨存在，它必須結合IP地址一起使用。
在這裡對方顯然是誤解了掩碼的含義：
我們申請的策略只是開通 :
255.255.255.128 這個掩碼所代表的子網段的 10.4.21.33 到 255.255.255.248 這個掩碼所代表的子網段的 10.4.119.17 的TCP協議的 22 埠的訪問許可權。
很細化也很明確。
並不是他理解的開通這個 255.255.255.128 掩碼段內的所容納的126臺主機的所有訪問許可權。
隨即打電話再次溝通解釋這個問題，對方終於有點明白了，策略順利開通，此事告一段落。
當然，為避免誤解，單機策略後來都統一成單一IP地址不再標註掩碼。
在工作當中，發現網路不通是一種經常的現象。
遇到這種現象，相信許多人都會將精力集中在網路線纜、網絡卡驅動、網路裝置、網絡卡引數方面;
而在檢查網絡卡引數時，他們或許又將眼光聚焦在IP地址、閘道器地址、DNS伺服器或DHCP伺服器等重點引數上。
事實上，還有一個網路引數——子網掩碼，同樣也是非常重要的，如果我們忽略了它的設定或將它設定錯誤，同樣也會帶來網路不通的故障。
比如：
- 一臺工作站的IP地址為 10.192.0.1，對應的子網掩碼地址為 255.255.255.0 ;
- 另外一臺工作站的IP地址為 10.192.1.1，對應的子網掩碼地址為255.255.255.0 ;
- 那麼他們就不處於相同的子網中，不能直接連通。
因為通過子網掩碼地址我們可以看出前一臺工作站所處的子網網路號為 10.192.0.0，後一臺工作站所處的子網網路號為 10.192.1.0 。
再比方說 :
- 一臺工作站的IP地址為 10.192.0.1，對應的子網掩碼地址為 255.255.0.0;
- 另外一臺工作站的IP地址為 10.192.1.1，對應的子網掩碼地址為 255.255.0.0;
- 那麼他們就處於相同的子網中。
因為通過子網掩碼地址我們可以看出前一臺工作站所處的子網網路號為 10.192.0.0，後一臺工作站所處的子網網路號也為 10.192.0.0。
還有防火牆的策略還牽涉到正掩碼和反掩碼 :
- 如果是正掩碼，比如：10.4.21.0/255.255.255.128 代表的是10.4.21.1~127這麼多個地址;
- 如果想要標識單個主機的話 10.4.21.33/255.255.255.255 （大部分防火牆配置策略用的正掩碼）；
- 如果是反掩碼，前面的0表示嚴格匹配，後面的1表示不匹配。
比如 :
10.4.21.33 0.0.0.127，代表的是 10.4.21.0~127 這麼多個地址。
這種正常的寫法應該是：
10.4.21.0 0.0.0.127 (路由器的ACL大部分用反掩碼）
子網掩碼引數平時不被人重視，一旦由該引數引起網路不通故障，那麼該故障的排除往往很容易讓人多走彎路!
子網掩碼是網路中的一個重要的知識點，在工作中你還會接觸到正掩碼、反掩碼、可變長子網掩碼、超網、字首表示法、子網聚合等，我們對子網掩碼的認識和理解也是不斷加深的，學無涯而知也無涯。
三、TELNET的“囧”
telnet是大家很熟悉的一個程式，它是TCP/IP協議族中的一員，是Internet遠端登陸服務的標準協議和主要方式。
工作中，我們在終端電腦上使用telnet程式，可以很方便的連線到遠端伺服器執行操作，也可以用它來測試遠端伺服器埠的開放。
09年的時候，我在一家上市公司做系統運維。
當時一個專案需要分公司的系統管理員能用XMANAGER遠端登入到總公司的一臺伺服器上用LINUX的遠端圖形化安裝一個商業軟體。
我已在總公司的伺服器上配置好了XMANAGER並在防火牆上放行了XMANAGER的UDP埠177。
對端分公司的系統管理員只要測一下UDP埠 177是否通，連上就可以了。
尼瑪，結果分公司的管理員測了一下午都報XMANAGER埠不通。
我納悶了，怎麼會呢？
配置一點問題都沒有，他到底是怎麼測的？
我問他你用什麼工具測的埠，他說是TELNET，併發來截圖。
囧！TELNET只能測TCP埠，怎麼能測UDP埠呢？
UDP埠是否開放，可以用NC、埠掃描工具等來測試。
NC來測試
[[email protected] ~]# nc -vuz 10.4.29.35 177
Connection to 10.4.29.35 177 port succeeded!
結果證明UDP 177埠正常監聽，可連通。（注：NC測有時不準確）
或者nmap -sU -p 177 10.4.29.35來測，更準確。
或者直接用XMANAGER連上測一下
小的問題，小的細節，不容忽視，細節決定成敗，做技術的一定要嚴謹和深入。
後續：
技術離不開理論，但更需在實踐中去分析和論證。
每個問題，都有它的特點，或簡單或複雜，同時我們對問題的思考是不斷深入的，畢竟理性也是有一定侷限性的。
從菜鳥到技術大牛，我們成長的路上都會遇到這樣那樣的“囧”與“惑”，WINDOWS有WINDOWS的玄妙，LINUX有LINUX的精深，程式語言亦是如此。
仰望星空，仍需腳踏實地。
唯有深入思考和歷練，我們才能不斷跨越“囧”與“惑”，走向真正的技術大牛！
原文出處：高效運維
文/孫杰