[工作日誌] #6 技術債，迫切開發，實驗

說明

有些問題的類型歸類，實在難以釐清。

可以比較確定的方向是大概就兩點

1. 這問題責任是算在開發部門

2. 基本上，我要講的內容，這也算是極端問題的ㄧ種分支

如果開發階段或者測試階段就很常發生，又無法解決問題，我相信大家也不會用。

案例

系統流程大約是這樣

1.php收到request
--> 2. php 將資料A寫入redis，hset
--> 3. php 將資料B寫入redis，rpush
--> 4. golang 將資料B讀出redis，lpop
--> 5. golang 將資料A讀取redis，hget

結果在運行每個月上千萬筆以上的作業，據我聽到的傳言平均每個月會有一兩筆有問題。

一個A理論上對應一個B，有問題的是有時候會發生只有1個B卻有2個A，或者1個B卻沒有A的狀況。

1 ~ 5 步驟到底哪裡有鬼，我也不知道個所以然，也沒有切確方向。

但問題範圍在1~3的部分比較有可能，因為golang 做lpop和rpush在系統其他方面的資料處理量也很可觀，還沒有聽過有問題。

所以我判斷應該是php 那邊做rpush有問題吧，fuel php 的framework也確實好幾年沒更新了。

在那個php專案裡面也從沒寫過rpush的操作。

事至如此，我覺得我也有錯，因為當下接到問題處理的人不是我，我就提出我的意見後，繼續去做我的事情了。

算不算親手製造一個悲劇？該死的風氣

然後後續就有點債留子孫的感覺

問題發生原因是什麼，發生的機率又低的很可怕，以目前資源和環境你想重現，又沒辦法。

後來問題重複出現，半年過去，出現過幾次，以這麼大量的分母，這個分子根本九牛一毛。

為什麼會容許重複出現呢？

我想是實在問題出現機率太低了，我們有更重要的東西要優先處理，又或者所做的修正是頭痛醫頭，腳痛醫腳，所以當然弄不好。

這點我也沒辦法，當我不知道問題切確問題點，也許給出的分析或處理方案也是頭痛醫頭，腳痛醫腳，這是沒有辦法的事情。

優先處理已安排好的專案需求，優先處理被客訴的問題，優先處理明確明顯的問題。

對這是我們的現實沒錯，但探究困難問題的原因，我認為不該被推到第四象限，不緊急不重要的部分，然後改天就被默默遺忘了。

好像只是要個交代？

事情後來，我覺得有點誇張的是，部門的人後來都堅信了，「那個php專案內redis的套件有問題」。

我沒有一言九鼎好嗎？我也只是說個範圍或方向而已，就沒有人要質疑或驗證一下嗎？

雖然到目前我的方向還是「那個php專案內redis的套件有問題」，可能性比較大。

提供假設很簡單的，但設計怎麼求證，很辛苦，很困難，尤其是這麼模糊的狀況。

人家接手到的問題，我到底要插手多深？我覺得要放手給別人去想，去犯錯，去自己學習。

這也是有人給我的建議，不想覺得自己總是比別人厲害，別人的能力總有我不知道的部分。

有些經驗只有在犯錯後深刻體會到，我不應該事必躬親，剝奪別人成長的機會‧

所以你問個顧問，顧問可以提供方向和假設，不過你要自己去印證或調整吧.......我是這麼想的。

小小掙扎

but 想法上有落差吧。

後來我想想可不可以抽出一些時間，彌補這個問題黑洞，golang的部分我用golang的rpush到本機redis，在用golang的lpop出來，

檢查會不會有塞一筆卻pop出兩筆的詭異狀況，作了2億次結果沒問題。

實驗前，我找人請問意見的時候，人家也是說預期php那邊可能有狀況啦，我要做golang的實驗......大概會看到結果再正常不過了。

再來php那邊就困難了，曾經我有向接手問題的某個人員提出，那部分若要做實驗的話，要怎麼做，需要向上頭要什麼資源，做什麼準備。

結果過沒兩下意見就被丟在一邊，媽的，死菜鳥一個。

這個問題始終沒有結果，預期耗費的實驗成本也有點龐大與麻煩，甚至最後只能保證問題不是出在某些範圍。

我放棄，到底要我怎麼辦？

看待實驗這件事

well ......

我覺得以技術部門來講，付出的成本比起最後的拿到收益，成本遠小於收益，拿到的結果都是一種難以在外可遇見參考的技術底蘊。

無形財產，果然難有共識，東西有需求就有價值，沒有需求給你黃金萬萬兩可能也是垃圾。

我覺得有點可惜，公司規模這麼大，方向卻是不斷開發新產品和新功能，而非精進原本東西，強化或者專注做得更好。

人手騰不出來，如果能夠撥出1~2人，成立專業實驗團隊，公司也願意給機器，幫忙架環境，也請相關部門配合。

其他人開發上，或者維護上有疑慮或想要的實驗項目，就開出清單，實驗團隊跟這些需求人員確認情況，開始設計實驗方式與執行。

然後實驗結果和數據，還有實驗設計方式，能夠開放給部門所有人都可以容易查到，一種library的概念。

有實驗，有數據，有掌控，就不會像這現在這樣，有心無力放著不可思議的問題一直在，各種上限和資源使用率不知道。

不小心碰處各種設計上的誤區或禁忌，如果不想承擔新做法的風險，

就老是有一堆人只想用舊的寫法，用舊的東西妄想能做出更厲害的系統設計。

稍微舉個例子，有一卡車的人看到redis的機器tcp連線超過監控上限，就哇哇大叫，連線監控數才設2000？2000？

不覺得丟臉，我耳朵都想摀起來了。

你問我說多少是危險？我也不知道，但我知道的相關知識，知道遠不是這個數。

這個不知道，查不到，就要實驗，架實驗環境，設計實驗方式做實驗，要不然怎麼辦？直接申請更多redis新機器嗎？

滿滿滿滿無奈，心苦誰人知。

而且實驗設計，是需要長期訓練和練習的好嗎？有效的實驗才是實驗，正確的前提才是實驗，不是找個阿貓阿狗誰都能做的好嗎？

這個我們也沒有，我看不到這裡什麼可以強盛的理由。