【原創】見微知著看技術誤解?--從裸光纖和NTPD談起

03-05

第一. 裸光纖的故事

前幾天和朋友聊天，談到一根裸光纖可以分波分多大的問題。

幾個業內好友都明確說一根裸光纖最多跑10G帶寬，而於老闆明確表示裸光纖任何一個波分（或者不做波分）都可以跑100G以上。

後來我和於老闆深究原因，不可能幾個朋友都騙我或者都蠢，很可能前些年光纖波分機自己只能甩出10G口，或運營商租光纖套餐里只有10G規格，給大家造成了裸光纖只能跑10G帶寬的印象。同樣固有的印象是光纖必須從運營商那裡租，而且價格很貴還必須買波分設備等等；其實現在企業專線的市場競爭很充分，拉同城裸纖一公里也就小几百塊錢，而且短距離裸纖也不值得上波分設備，直接對接模塊即可。

第二. NTD是試金石

我對裸光纖是門外漢，但同樣的技術誤解讓我想到了NTP，我一直拿ntpd和ntpdate當做初中級系統工程師的試金石，分不清就月薪五千，分得清就八千以上（2014年市價）。但很多貨真價實的IT專家也在此事上跌倒，我也希望通過聊清楚一層誤會，說明高級工程師該少迷信多思考。

NTP是網路時間協議，它是多項傳輸、計算、加密技術的核心參數。

假設我認為TCP連接超時斷開鏈接了，你怎麼給我傳輸數據；
玩各種定時給獎勵收益的花園經營類遊戲，我經常通過修改時間快速刷分；
你的系統時間不對網銀都會拒絕登陸，因為加密程序算不出雙方認可的Token。

第三.正確的時間是向量

Linux環境下有兩個常用工具，NTPD和ntpdate。NTPD是一個時間同步服務，ntpdate是個時間同步命令。很多工程師都會採用Crond+ntpdate的方式同步時間，究其原因是「NTPD不太好用」。

而我不喜歡用ntpdate同步時間的工程師，NTPD是一個體系化的服務，而ntpdate只是一個動作，大部分人沒做好為ntpdate這個動作負責。

正常的時間是個持續增長的向量，即老時間t1肯定小於新時間t2，新時間t2也小於最新的時間t3，而且t1必定會漸進增長到t2和t3。除了少數商業資料庫服務自帶時鐘源以外，大部分業務服務對系統時間是盲目信任，不相信t1會越過t2直接達到t3（即斷檔躍變），而t2減去t1會得到負數或者0（即時鐘停滯和回逆）。

第四. NTPD的優勢

如果我們用ntpdate同步時間，可能會帶來時間的斷檔躍變或者停滯和回逆。時間不穩會威脅到的程序健壯性和業務安全性，甚至部分程序崩潰的稀里糊塗。

ntpdate只是個命令不是服務，它對遠端時鐘源是盲目信任；假設一個根NTP服務不穩定，所有的伺服器獲得了錯誤的時間，雖然現在業務層可以包容異常，不會出現算出負利息或倒扣費的情況，但業務混亂是免不了的。我們就說聯機調試分散式日誌，幾個節點的時間有錯可能日誌就看不懂了。

NTPD服務做時間調整會有效減少這類情形，它不是簡單的龜速調整時間，而是有柔性時間調整策略，讓時間線的躍變和調整盡量少影響業務（詳情見附錄實驗）；也不會盲目信任遠端時鐘源，甚至固執的拒絕同步時間。NTPD服務相信本機時刻有可能不對，但不會忽快忽慢甚至停滯，NTPD通過多次收發包選擇權威穩定的時間源，算出雙方間的網路延遲，然後才會採信新的時刻進行時鐘同步。

第五.誤解的根源和影響

因為NTPD不盲從其他時間源，讓老一輩IT人會留下NTPD不好用、不靠譜的誤會。2005年個人測試用虛擬機的時間經常走慢，到2010年虛擬機還要防範時間停滯的Bug。即使你用物理機投入生產，網路延遲仍然不確定，且要觀測NTPD同步效果需要時間。我們很難成功調試NTPD服務，會裝NTPD又沒有會裝LAMP可以拿去吹牛，時間長了NTPD服務就背上黑鍋了。

真有TOP10的互聯網公司和上億國家級項目里用ntpdate+crond，上一代架構師為什麼有這個誤會無人深究，下一代人將誤會固化為偏見，新一代人將偏見神化為迷信。

但無論誤會、偏見還是迷信，時間躍變、回退和停滯對應用健壯性和業務安全性的威脅始終存在，時間不僅僅是我玩遊戲時用的魔法，忽視問題並不能掩埋問題。

第六.見微知著和防微杜漸

我講NTPD和裸纖並不是為賣弄知識，也不是為做偏門科普，而是希望進階工程師們多考慮一下如何規避這類誤會？我們在做技術工作時，是不是只關注客戶和同事能提出的需求？客戶永遠不知道裸纖的物理特性，同事也不會知道時間也能錯誤和波動，他們能說清楚業務邏輯就不錯了。

把所有的精力都用到做業務邏輯，你只是個編程語言翻譯機而已；自己主動觀測技術環境依賴，有資格有能力做出技術選型決策，才是給Coder群集做技術校準的人。即使你不想做技術決策人和管理者，多懷疑和觀察環境，也能少些溝通成本，少走一些冤枉路，多一份自信和自尊。

------附錄，NTPD時間躍變不遺漏Crond的實驗------

1. 當前系統時間是 23點35分。

[root@instance-6ot6pwji ~]# date

Wed Nov 8 23:35:02 CST 2017

2. 我故意把系統時間調整到 23點32分；注意這個時間不能和真實時間差太久，差太久了ntpd認為網路時鐘源不權威，很久都不會進行時間同步。

[root@instance-6ot6pwji ~]# date-s 23:32:00

Wed Nov 8 23:32:00 CST 2017

3.做好日誌列印的crond，設置每分鐘列印一次時間，到第35分鐘時列印一次時間：

注意不能時間太近，因為crond服務可能還沒來得及載入新配置，ntpd服務也沒完成時間校準，這些字我必須搶在2分鐘內打完。

[root@instance-6ot6pwji ~]#crontab -l

*/1 * * * * echo"current" `date` >> /tmp/clock.log

### 上文是一個檢證時間戳

35 * * * * echo "Hit time!!!" `date` >>/tmp/clock.log

### 這是一個命中測試時間戳。

4. 用watch ntpq -p 查看ntpd對時鐘源的校準狀態。

5. 如果在35分之前時鐘校準完成，比如說現在時間是23點37分，則，/tmp/clock.log 里有個23點37分的時間戳。

[root@instance-6ot6pwji ~]# cat/tmp/clock.log

current Wed Nov 8 23:37:14 CST 2017

Hit time!!! Wed Nov 8 23:37:14 CST 2017

current Wed Nov 8 23:37:14 CST 2017

6. 如果到了本地第34分（實際第38分）ntpd還沒完成時間同步，因為馬上和crontab里的35分打日誌撞車了，可以快速修改crontab -e ，把列印hit日誌的時間改為37分。中間隨著時間的推遲可能多次修改hit的時間點，但不影響測試結果。

這次實驗好玩的地方在於：

我定個35分的任務計劃，結果ntpd將時間躍變越過了第35分直接到了37分，但該任務計劃仍然執行了。而從執行輸出結果是37分來看，這不是小步快跑的踩過35分，而是第35分被越過了不存在。

這個實驗里坑很多，個人要和時間賽跑才能完成實驗，我做了8次實驗成功了3次，每次都等了10分鐘以上。這個實驗也不夠嚴謹，我只是拿crond做實驗，我在夢裡記得其他有歷史守規矩的程序也能和ntpd聯動，但我沒時間做實驗了，也希望有朋友能幫我答疑解惑。

----附錄2，網上能找到一個寫NTPD和ntpdate的水文和本文內容有些類似，那個是我多年以前寫的，不是借鑒和抄襲，嚴肅臉。

----附錄3，於總的公司叫聯雲易通，就是做雲交換和混合雲的，落地產品就是能統管多個公有雲、私有雲的多雲管理軟體，以及往一個個機房拉專線。算個小廣告小尾巴，有業務需求的我可以幫轉。。