比威而鋼還威的 TCP BBR

前一陣子從 iThome 看到了 Google 要把 TCP BBR 應用在 Google Cloud Platform 的新聞, 才發現原來這東西這麼神,2700 倍的傳輸率,佇列延遲減少 25 倍,隨手翻了下網路上的部落格,沒想到有那麼浮誇的說法證明:下載從 84K/s 變成 3.9M/s,這立刻引起我的好奇心,找到了 Google 自己的部落格說明,原來是長久以來使用的 TCP 壅塞控制演算法有點笨,遇到有 packet loss 的狀況時,就會以比較保守的方式來傳遞接下來的封包,而新的 TCP BBR 則用了比較聰明的方法來處理 packet loss 的問題,整個示意圖就如下所示:


* Source

文中也特別拿了幾個國家為例子,說明在應用了 TCP BBR 之後,YouTube 的表現情形,不看還好,一看之下,沒想到 Google 也這麼浮誇寫實,YouTube 到 ID 的 Max Round-Trip time 竟然可以改善到 50% 以上,這讓我突然想到以前公司在進行某個網路直播專案時,那個爛 4G 網路讓我們驗收時吃了很多苦頭,所以我也來做個浮誇的測試好了。不過因為一來我很懶,二來也沒那個預算搭建回當初專案的原始架構,所以以下浮誇的測試只在我的本機上實驗。

  • 實驗環境 (都在同一台機器裡):
NB: OBS Studio 19.0.3 --> NB: clumsy-0.2 --> VM: SRS 2.0.242 + CentOS 6.9 --> NB: flv.js in Chrome
  • 實驗方法:
  1. 先以 Kernel 2.6.32-696.6.3 直接測試,擷取螢幕看直播視訊延遲
  2. 以 clumsy 加上 inbound & outbound 各 50ms 的延遲,並隨機 drop 10% 的封包
  3. 等個幾秒,擷取螢幕看直播視訊延遲
  4. 停止 clumsy,等個幾秒,擷取螢幕看直播視訊延遲
  5. 升級 Kernel 為 4.13.0-0.rc1,重複步驟 1~4
    * 我拿了一個 Firefox 開時鐘來讓 OBS 擷取螢幕畫面,所以測試畫面中會看到 Firefox
  • 實驗結果:
  1. 沒 TCP BBR,不啟用 clumsy,延遲大概 3 秒
    Without BBR - normal network
  2. 沒 TCP BBR,啟用 clumsy,稍等一下,延遲變為 13 秒,實測時這個延遲會迅速擴大,最差的狀況是影像會停掉
    Without BBR - bad network
  3. 沒 TCP BBR,把 clumsy 關掉,稍等一下,延遲回到 5 秒左右
    Without BBR - normal network again
  4. 有 TCP BBR ,不啟用 clumsy,延遲大概 2-3 秒,其實和沒 BBR 時差不多,這畫面看起來延遲只有 2 秒應該只是個測試誤差
    With BBR - normal network
  5. 有 TCP BBR,啟用 clumsy,稍等一下,延遲變為 4 秒
    With BBR - bad network
  6. 不信邪,再等一等,有 TCP BBR,啟用 clumsy,延遲還是維持 4 秒左右
    With BBR - bad network-2
  7. 恢復原狀,有 TCP BBR,不啟用 clumsy,延遲還是維持 4 秒不動
    With BBR - normal network again

總結來看,這個 TCP BBR 還真的神,在高延遲且掉包的網路上,在我的測試環境 1 個 client 對 1 個 server 的情境下就能有這麼好的表現,安裝的方法我就不特別提了,網路上隨便 google 都一堆,不過還是要提醒大家一下,再好的東西還是得先測試才能上正式環境,免得哪個不小心你就踩了坑了都不知道。

BBR Summary

玩一下 Google Compute Engine 要花很多錢嗎?

雖然身為一個 IT 人,也知道這一行要與時俱進不然就被淘汰的道理,但是我個人對於「在雲端上花錢」這件事情的態度算是偏向保守的那一派,像是 LINE Pay 已經出來半年了,我是為了貪那繳稅的回饋金才去辦卡且綁定了我的 LINE 帳號,Google Play 上就算有需要綁定過信用卡,也是用完之後就移掉,不然我自己會想像被他亂收錢。

這次之所以會想要在 GCE 上花錢,是因為看了某個對岸網友的文章,發現 Google 竟然直接在他的 GCE 上提供 Anycast IP + Global Load Balancer + CDN 的服務,因為這實在是太狂了,所以我忍不住就打破了自己的的風險規則,跑去把我的信用卡放上去。

我測試的東西也就是 Anycast IP –> With CDN –> Load Balancer –> 一台台灣 VM + 一台新加坡 VM 這樣子的架構,測試之前先在我自己電腦上的 VM 跑了一次,並且把安裝與設定步驟記錄了下來,所以去 Google 上開機器時,除了幾個 Google 自己的設定需要實驗多花了點時間之外,大致上可以說是沒幾個小時就做完相關的設定工作,然後就開始測試了。之後就放那邊放了兩天,端午節之前把 Anycast IP, CDN, Load Balancer 及新加坡機器關掉,只留下台灣這台 VM 給同事測試用 (對,我實際上的需求並沒有一定得要用 Anycast IP,只是拿來試試看功能而已),這樣子我一共花了多少錢呢? 才 US$1.96

1

而且 Google 也提供了一個預算管制的功能,當所花的錢超過你設定的預算時,就會發警示信出來。因為我拿來玩 GCE 的帳號就是我平常在用的 Google 帳號,也綁了我的 Android 手機,所以這功能讓我很安心的繼續用下去。

2

前一陣子不知道是哪位臉書上的心得,說是微軟 Azure 要和 Amazon AWS 或 Google GCE 對打還是走得很辛苦的。對照一下這幾年來看到 Google 在做的事情:Google 自建海纜、GCE、Anycast IP on GCE、Google CDN (如果 Google 要把他們在世界各個 ISP 放的 Google Global Cache 也拿來做 CDN 加速的話,那就更恐怖了),可以看到 Google 要做而且已經快做到的是「世界」的 IT Infrastructure – 全世界的中華電信、全世界的 Hinet,這意思是什麼呢?如果你今天只想做台灣的網站也就算了,如果你是想搞跨國的網路應用(電子商務、遊戲、社群、直播…),以後你也不用多想了,就直接放 Google 上就好了,如同幾年前的台灣一樣,大家想搞網路、搞遊戲,機房鐵定要選中華電信、專線一定得拉 Hinet,因為全台灣的使用者幾乎都是用 Hinet,想不接 Hinet 線路就是要讓使用者 lag 爆。這種事情以後就會反過來,大家要在全球佈局的話首選就會是 Google,因為最簡單速度又最快。

所以,學學這些 Public Cloud 的使用經驗看來就是未來 IT 人的必備技能,而且搞不好還比去學什麼 Server 安裝或 Cisco 設備操作要來得基本且必要,要練習這些東西很花錢嗎?你要練 Server 安裝、系統管理之類的可能要去買台機器或借個環境才能操作,想練網路我看很多人會花個幾千塊去網路上買二手設備來練習,但是想練 Google Public Cloud? 以我這次的例子來說,只要 1.96 鎂就好,可能比很多人一天的通勤費用還便宜些,好東西,不買嗎?

在 Windows 上使用支援 edns client subnet 的工具 – dig 9.11

之前提到了說 BIND 會從 9.11 開始支援 EDNS client-subnet,所以若你的 BIND 已經開始使用 GeoDNS 的功能,恰好你的 end user 用的 DNS server 也支援 EDNS client-subnet 的話 (eg. Google DNS 就支援),那恭喜你,你的 GeoDNS 的效果應該會變得更加顯著。

但實際把功能丟上去之後,你就會發現有事沒事的你會遇到使用者抱怨他連你的網站速度太慢,原因是因為你的 GeoDNS 回給他的結果和你預期的不同,原本你想要 GeoDNS 丟個離日本最近的 IP 給他,但他拿到的卻是個英國的 IP。這時候我們就需要個可以快速驗證 GeoDNS 設定是否正確的工具了。

這工具其實也很簡單,因為就是隨著 BIND 9.11 一起更新的 dig 命令,只是以前我笨笨的,以為 BIND 只有出 source code,自己又沒種花時間去 Windows 下建立編譯的環境,所以都是去抓別人編譯好的執行檔,自己都覺得有點不是挺安全的,不過剛剛仔細一瞧,原來 ISC 自己的官方網站上就放了 BIND 的 Windows 版,只要下載之後安裝也就可以用了…

01

安裝的時候只要選擇「Tools Only」就好,我想大家也不想在自己的電腦裡裝個用不著的 BIND Server

02

裝好之後,如果你像我一樣對自己用的系統有一點潔癖的話,可以把目錄下的這些檔案(除 BINDInstall之外)拷貝到你喜歡的目錄,剩下的東西則可以全部移除。

03

dig + EDNS client-subnet 的使用方法也很簡單,就是

dig [domain name you want to query] @[DNS Server] +subnet=[addr]

http://www.google.com 為例,如果我是個位於美國的使用者,IP 是 128.32.203.137 (我隨便抓了個柏克萊大學的 IP 來測試),解析出來的會是 172.217.5.100

04

那如果我是個台大的學生,IP 是 140.112.8.116 的話,解析出來的會是 163.28.18.30 (左右…)

05

我自己現在用的是遠傳的網路,從 ping 的結果看來,Google 應該也是有應用 GeoDNS 來加快網站的速度(當然也用了 BGP anycast,但不在此文討論範圍)

06

最後,更笨的是,如果你什麼都不想裝,就用別人放在雲端上的服務就好了…

https://tools.keycdn.com/dig

 

OpenStack – Failed to connect to server (code: 1006) issue

最近在OpenStack的lab遇到了無法使用console的問題

情況如下,當環境中只架設一台controller node時,console 可以正常使用

不過當controller node增加到2台以上時,console就會無法使用

以下為錯誤畫面

Failed to connect to server (code: 1006)

2016-11-01_001459

後來問過Google大神才知道,當架設多台controller node時會因為每台controller node對instance的token都不同造成驗證失敗,使得console無法使用

解決的方法就是在nova.conf中設定memcache servers來存放token

設定如下:

[cache]

backend = oslo_cache.memcache_pool

enabled = true

memcache_servers = controller1IP:11211,controller2IP:11211,controller3IP:11211

3台controller node都設定完並重啟nova-consoleauth service,就可以正常使用console了

RAID Scrubbing / Data Scrubbing

最近因為追某個錯誤,追到了辦公室的 Synology NAS 上,才發現這個名詞:「RAID Scrubbing」,標準的叫法應該是「Data Scrubbing」,查了幾份文件 (1)(2) 之後,都說這是使用 RAID 時的必要的定期維護工作,還提到而家用硬碟建議每週都做一次,而資料中心用的 RAID 建議每月都做一次,不然可能會有資料遺失的風險?!

乍看之下我嚇了一跳,因為印象中我們從來沒做過這個動作,當時我立刻覺得公司的資料正陷入極高度的風險中,不過稍微看了一下 Wiki 上的介紹之後,發現 Dell 的 RAID card 本身就支援所謂的 patrol read 功能,效用等同於 Data Scrubbing,頓時讓我鬆了一口氣,但身為一個工程師, 就是要追根究底一下,不然還真不能百分百的放心,而且還可以藉此練一下肖喂:

  1. 關於 Dell 的 RAID card 部分:
    • 根據 Wiki 下方的註解,Dell PERC 6 或 PERC 6i 有個叫做 Patrol Read 的功能,效用相等於 Data Scrubbing
    • Dell 網站上也提到這功能預設是開啟的,而且每七天會跑一次
    • 對照一下正在使用的 Dell R720 (使用 PERC H710 RAID Card),在 BIOS 當中的確有這個選項,且預設值是 Auto,所以這裡算是可以安心了
      1
  2. 關於 Synology,還的確得要做 RAID Scrubbing,但是,這個動作要花費的時間真的非常久(不知道和 Soft RAID 有沒有直接關係),像我花了三天時間對一個 22TB 的 RAID 6 做,目前的進度也才 45.3%
    2

Dell 對於 Patrol Read 的說明上有個補充項目,意思是這功能不會對 SSD 執行,我猜想是 SSD 本身的控制器就已經自帶 error detection / error correction 的功能,所以就不用靠 Data scrubbing 這個動作來預防可能有硬碟壞軌或 RAID 寫入不完全的錯誤。

企業級 SSD 這幾年來又有長進

由於最近又到了公司汰舊換新的時間點,這次我好奇了看了幾份廠商的報價單,意外的發現某張報價單上出了 SSD 的型號

1

最後面出現了 PX04SH 的字樣,再次好奇餵估狗看看,沒想到這規格還真是嚇人,4K random read 可以到 270K IOPS,對照一下之前從 RAMSAN 轉換到 SSD 的心得文,那時候使用 DDR2 的 RAMSAN 也才號稱 600K IOPS,沒想到過沒幾年,這樣子的一棵Toshiba SSD 也可以有 270K IOPS 的表現了,這意思豈不是說如果我拿 6 顆 PX04SH 做個 RAID 5 (RAID 5 不安全,這裡只是舉例),讀寫佔 70%  的話,計算出來就會超越過去的 RAMSAN 了?!

再繼續發揮我的估狗力,找了這幾年來我們可能用過的企業級 SSD 型號 (怎麼都是 Toshiba 的?!),發現這些還都有人測試過

型號 帳面速度 (4K IOPS) 實測報告 (4K IOPS) 實測報告 (8K IOPS) 參考
MKx001GRZB
(SLC)
讀: 90K
寫: 16K
讀: 95K
寫: 16.8K
26.3K 參考
PX02SM
(eMLC)
讀: 120K
寫: 30K
讀: 112.4K
寫: 28.4K
讀: 41.1K
寫: 28.4K
參考
PX04S
(eMLC)
讀: 270K
寫: 125K
讀: 306.8K
寫: 99.3K
讀: 211.8K
寫: 52.4K
參考
(9W mode)
  • 老實說, 8K 的測試方式我不是很懂,只看得出來用的方法不太一樣,請自行參照表格後的連結

Wow,比我們第一代用的 SSD 的 4K 讀寫都快了 3 倍以上,其中可能有些是來自於 SSD 本身速度的長進,絕大多數應該也是拜 SAS 12Gbps 所賜 (MKX001GRZB 時代只有 SAS 6Gbps)。只不過看到這個數據之後,突然想到我們之前還拿著兩種不同的 SSD 版本來混插,實在是一種把 LBJ 叫來和我們職籃一起打球的概念了,以後應該要針對這幾種不同的 SSD 版本做個明確標示,不然有了 NBA 球員卻只打國內籃球,多划不來。

  • SQL Server 預設應該是一次做 8k 的讀寫,而且不能自己修改,所以用 SQL Server 的人理論上要重視 8k 的讀寫 IOPS
  • Oracle 看起來可以自己調整,所以要請教一下你的 DBA 看你們通常是設定成多少

其實這幾年來,網路上一直有人在抱怨 SSD 的壽命越來越短,從可以 10 萬次讀寫的 SLC 變成最多 1 萬次存取的 MLC,現在又從 MLC 變成只有千次存取的 TLC,還有很多人跳出來證明說自己之前 SLC 用了多久都沒事,現在換 MLC 或 TLC 就人品爆發云云的,所以我本來也是一直對這一點很感冒,所以當廠商從去年提到現在已經不生產企業用的 SLC SSD 時,我們也是緊張了老半天,生怕這些 eMLC SSD 哪天不乖乖,我們就 GG 了。只不過後來拿了廠商的工具去看,卻發現這些三年前的 SLC SSD 個個都是 100% health:

2

當然我也不清楚這是用的少的關係,還是廠商的工具有修修臉的功能,把健康度修美了(如果是這樣子的話我想我們就 GG 了),但如果我們實際上也用不少,廠商的工具也是正確的話,那這個 SSD 還真是太耐用了,比傳統硬碟都要耐用許多(第一次用是三年多以前,到現在全部都還在役,有少數 SSD 的健康度變為 96% 或 98%),也難怪廠商現在都要改推 eMLC 了,因為 SLC 根本就很難壞(企業級的 SSD 都會做所謂的 over provisioning 備用空間,這顆 200GB 的硬碟實際商應該是 256GB,不見的那一塊應該就是拿去做備用空間)。

不過也請大家別聽我在上面唬爛,以為企業用 SSD 真的就不容易壞,目前在沒有確實實證證據之下,還是請大家都能:

  1. 該更新 firmware 時就請安排測試並更新,消費級的 SSD 常聽說 firmware 寫不好導致壽命不佳的,我相信企業級的也該依此觀念做定期更新
  2. 自己訂一個健康度標準,並確實監控它,例如可以定 SSD 的健康度到了 80% 後,或使用滿 N 年之後,就移出關鍵應用(eg. DB) 之外

其實我在寫這篇文章之前,還真沒想到 SSD 在這幾年間還能有這麼大的進步,我一直以為儲存裝置下一次再有大規模的進展,會是在 Intel 和美光的 3D XPoint 市場普及化之後 (3D XPoint 據說年底或明年初上市,普及化不知道要多久),沒想到自己沒注意到 SAS 12Gbps 的出現,所以這顆去年就上市的 PX04S 一直到現在才被我看到,也說明了 SSD  在這幾年來都是高速的成長,不管是速度上還是價格上,如果你還在觀望是不是該採用 SSD 在關鍵應用上的話,看了我們用了三年以上的經驗後,是不是也應該要嘗試一下了?

註:企業級的 SSD 價格估計該是家用級的 10 倍以上,別跑去原價屋或 PCHome 上看到產品名稱上有個「企業級」三個字 就去買來用,到時候出狀況可別怪到這兒來啊

Elastix (Asterisk) 通話中偶發斷線的問題 – 工程師的心路歷程(慶祝工程師節)

今天是工程師節,為了紀念我上週六花了三個小時只改了一行設定,所以寫了很多廢話,如果只是想找解答的朋友,請直接翻到最後面就好

我們公司是個不愛用桌上型電話的公司,從最早開始我去新加坡上班時,就發現他們不是每個人都有一台電話,除了幾位必要的客服、或行政人員之外,其他人都是一個小區域裡共享一支到兩支桌上型電話,大家若要彼此聯絡時,首先用的是  Skype (以前是 MSN),再來就是直接打手機了,也許是公司業務特性,或者是新加坡的手機費率不貴的關係,才造成了這個景象。

所以當台北要設立辦公室時,我們就選擇了 IP-PBX 的方案,而且還不是用貴森森的 Cisco 或 Avaya 之類的,而是在拍賣上找了一台二萬出頭的 MyPBX ,沒想到剛過保一年他就壞了,剛好當時又聽說我們的某大客戶也是自己拿 PC 裝 Asterisk 來用,於是抱著輸人不輸陣的心態,去淘寶上買了些相容電話卡回來,開啟了我們 DIY 之旅。

老實說,這套 IP-PBX 的系統並不太受我們行政青睞,舉例來說,沒辦法像傳統交換機(我猜是小型的那種)可以一眼從話機上看到目前哪條外線正在佔線中,或要轉接他人時直接大喊:小林,你的電話在3 線,的這種「功能」,看起來整個就弱了很多。當然優點也是有,就是我們和新加坡互打時,由於是走網路過去,所以完全不用額外的費用,有時候我自己也會走這條路過去新加坡「下車」,省了不少國際電話錢。

SinoCard

但是自從我們的台中辦公室成立以來,常被台中的行政妹妹抱怨說這個電話常常通話到一半莫名其妙斷線,一開始我們也是找不出頭緒,直到半年前的某一天,因為我要幫公司的永豐銀行信用卡開卡,所以打了開卡電話 02-2528-7776按812,沒想到打完信用卡號之後,開卡系統會附誦卡號一次,卻每一次念到第五個數字 ‘5’ 時,電話就會被掛斷,登登登,看來讓我無意中發現了這個 reproduce 的方法,後來我們又發現了只要在輸入卡號處按 16 個 5 ,就總是會在附誦第 5 個 5 的時候斷線,原本我們以為我們就快脫離這個苦海了,沒想到找出了線索,卻破不了案,從一開始以為是某個 dial tone 造成的問題,一直到懷疑是電信公司搞得鬼,但卻始終沒有解決,而且當台中同事說了這個事實之後,台北這邊也是齊聲附和,看來已經是忍了很久了。

直到三月時因為我剛好得ITGirl出個長時間的差,心血來潮的出了個作業給我們 MIS 妹妹,讓她去弄了個備用的 IP-PBX 出來,加上這個
月我們台中行政妹妹又再次的跑來抱怨電話斷線的問題,上禮拜六我就在端午節補上班那天(因為那天補上班還蠻閒的,心態上很悠閒,實際上也沒啥會議),下午 4:30 左右
再次開始了我的 debug 之旅。

這次我拿了四支電話來測試,竟然被我發現其中兩支完全不會有斷線問題(對照組),所以我的腦筋就先動到電話的 firmware 上,我們用的 GrandStream GXP-1405 電話的 firmware 升級並沒有這麼 user friendly,既使有 Web GUI 可以用,但只能指定要用 tftp, http 或 https 的方式來升級,而且升級檔的檔案名稱是預設在電話系統中的,從 GUI 中你也看不出來,一開始我還以為是任意的檔案名稱就可以了,所以在這裡卡關了很久,最後從 tftp 的 log 中看到有「預設檔案名稱」這回事,但 tftp 不知道為啥傳到一半就會斷掉,所以就改用 http ,再改用 https (因為我把更新檔放在 Elastix server 上,它預設會 http overwrite 成 https) 才升級成功,由於那個電話重開機也慢,每次做完一次試驗就要花上不少時間,所以這件事情搞了我兩個多小時吧,這時候就已經晚上 6 點多了。

星期六嘛,原本以為這就是 happy ending 了,沒想到 firmware 更新完之後,竟然不如我預期的打完收工,試打了一下永豐銀的電話之後發現還是會斷,這讓我覺得很不甘心,所以接著我就開始去比對對照組的那兩支沒問題電話的設定內容,電話設定比對完了,發現沒問題,再繼續去比對分機號碼的設定內容,這時候卻發現我找不到這兩支對照組的電話設定…. 啊,原來這兩支對照組的電話是接到我們 MIS 妹妹上次弄的新交換機,很快的我就找到新的交換機,也對了電話分機的設定,發現也是一模一樣,但這時候我已經發現的曙光,再去找了兩支實驗組的電話(使用原本的交換機),發現還是有問題,所以這時候已經有很大把握能確定問題是發生在交換機身上。

一開始我是先從 sip.conf 開始著手,由於我們原本的交換機上有啟用視訊通話的功能,而 MIS 妹妹架設的沒有啟用,所以我就陸續的把幾個視訊通話相關的設定拿掉來測試看看,也幸虧這天剛好是週六補班,晚上六點多時大家也幾乎都走光了,沒人要用電話,所以我就可以肆無忌憚的改設定->重開,改設定->重開 (ps. Elastix 改完設定之後,最好是去 command line 下 amportal restart,偶而這指令會卡住就要重新開機),試過幾次之後,大概也花掉了一個小時吧,還是一無所獲。

後來又找了一下,發現我們的 Wiki 文件裡頭對於這機器的設定有個註解(不知道是以前的 V 大還是 I 兄留下來的筆記),大意是說因為交換機曾經有咬線的情況(另一方掛斷電話時系統偵測不到,而導致該分機一直呈現佔線中的狀態),所以在 /etc/asterisk/chan_dahdi.conf 中有這樣子的設定:

busydetect=yes
busycount=3

而這個設定是 MIS 妹妹的機器上沒有的(這時候不知道該怪她作業不確實還是該感謝她了),於是我拿掉了這個設定,重開機之後…. 賓果,再打永豐銀的開卡專線就再也沒問題了。

但是你以為這樣子就沒事了嗎?之前的筆記明明寫說這個設定是為了解決「咬線」問題,那到底是什麼情況下會造成「咬線」?這可是大栽問了,所以我開始拿起手機,打了打台北辦公室的電話,疑,初步來看並不會咬線,接著我就打打台中辦公室的,我心理想著,這時候也快晚上 8 點了,萬一也不會咬線的話,那我豈不是就有測不完的 testing case,要測試到找出「咬線」的 pattern 為止。

幸好這時候打了台中電話後,因為已經都下班了沒人接聽,所以響了三聲之後我就掛斷了,這時候發現台中的電話還真的會「咬線」,從 Elastix 的 Operator Panel 中可以清楚看到某條外線 + 下班時間會共振的四台分機一直顯示通話中,非得重開機才能解開。

這時候雖然問題還沒有解決,但是我已經拿到重要的關鍵字了:busydetect + busycount + disconnect or 斷線 or 講電話講到一半斷線,接著直接餵給 Google,果然也不用靠英文,就有幾篇中文文件有提到這檔事情,有人的設定檔中的 busycount 設定得比較大(10 ~ 15),我試驗了一下,busycount 設定的大些可以讓斷線時間延後一點,也就是永豐銀附誦信用卡號時不會再第五個字斷線,而會在第 10 或第 16 個字斷線,另外有個人的設定檔中多了 busypattern=250,250 500,500 這個設定,丟進去之後,哈哈,果然就一切正常了,永豐銀的信用卡附誦不再斷線,也沒有咬線的問題了。    (* 2017/07/07 搬了辦公室之後,發現咬線問題又出現了,這次再改回 busypattern=250,250 之後就正常了….. 看來這個數值是搬個家就會不一樣的,好慘)

最後我計算了一下,我大概花了三個小時左右,真正的產出是下面的第三行

busydetect=yes
busycount=3
busypattern=500,500

如果以寫程式的角度來看,在 source code 中只會看到我改了這一行吧,花了三個小時的這一行…

而且老實說,也許電話講一半斷線的問題有許多 pattern ,我只解決了其中一種剛好可以被永豐銀開卡系統 reproduce 的那一種,也許我加上的這一行設定會導致另外一種未知的咬線問題,但是我沒發覺,也許要找到真正的 root cause 應該是要去研究一下台灣電話的各種頻率和 Elastix 之間的匹配問題…

但正所謂一日之所需,百工斯為備,既使是 IT 這個 domain,要靠一個人去瞭解所有的從底層一直到操作面上的各種觀念和技術是不可能的,甚至於是你要把問題往廠商那邊丟,也未必能得到滿意的答案。但是身為一個工程師,其實只要能掌握 try & error 這個心法,加上實驗與比較的精神,一樣可以取得一個滿意的解決對策(workaround)。

我猜應該也會有網友有其他的看法,以下是我這三個小時心路歷程中,心中曾經有過的 OS:

  • 遇到問題無法解決時:你看吧,早就叫你買 Cisco 或 Avaya 了
  • 有供應商時:怎麼不把問題丟給廠商呢?
  • 有供應商而且老闆在問時:這個問題廠商也說沒見過,已經開 case 給原廠了
  • 花這麼多時間,值得嗎?這又不是我們的核心競爭力

很多事情沒有真正的對錯,單看你要從那個角度來看,但今天是工程師節,我還是得承認這個結果雖然讓身為工程師的自己覺得很爽啦,但也是自己爽而已,只希望自己花了這三個小時的時間所解出的那一行,能幫助到網路上其他有這個問題的朋友,那我這三小時就也算花得值得多了。