小浣熊是一隻貓

開發時期的整合測試 請認真想想，如果製作一個拿來驗證開發成果的整合測試系統，與上篇提到的自動化整合測試與驗證系統，他們的差別在哪裡？ 後者其實就是前者的延續，甚至開發者製作了測試開發用的整合系統，後續的自動化驗證系統，也可交由非原開發者去製做。 前者應該已經要把有什麼對象，有什麼流程，有什麼料都寫好了。 後者只要拿來應用，組裝，加上一些驗證的程序即可。 但無論無何，這個部分一定要是原開發者製作，因為他最懂，因為他是作者，細節怎麼搞？為什麼那樣搞？ 考量是原作者考量出的方案，當然要怎麼驗證要他去想。 不然維運人員何其無辜，就真的不懂呀。 我們的不足 這部分獲得開發者的保證，開發與維護應該就可以切開了。 當然非常可能有漏考慮的部分，有時候還是得回過來靠原開發者補足，一定還是有開發與維護人員一起討論的情況。 其實也是我們部門沒有自動化測試人員。 我知道外面有的是把這類的人員，有的是編在開發人員上，有的是算再維運人員身上，但我們就是沒有。 送測部門，只能做人為操作測試，呵呵呵.......... 當然模擬使用者操作也是非常非常重要，送測部門也很熟練怎麼去擬訂人為操作的案例或SOP。 但有些東西，尤其是扯到大資料，大量處理，沒有自動化測試，沒有環境沒有條件，沒有拼死都要做mock銜接現實環境的限制然後作整合測試。 令人非常擔心，好幾萬的資料，好幾萬的request同時過來會不會錯，人工是無法測的。 上線 = 另一種送測，有爆掉的可能，多少心理可以有所準備。 當然自己上線前有時間就人工的code review，工作時間外常常也在思考會不會哪邊有意外，用自己本機有限的條件做片面或有限的測試等，努力了，也是非常不希望上線出問題。 這樣也好累，沒有令人心安的保證。 人類有人類的優點，機器有機器的，互相難取代。 所以，事發後......公司方面的反應，有的沒心理準備的感覺，在下面的我也是覺得非常無言。 要馬兒好，要又馬兒不吃草。

自動化快速驗證系統 - 中央集成 不論是誰來反應問題，維運人員收到問題回報或者詢問，一定想要用最快的速度確認到問題原因，或者是不是真有問題還是誤會一場。 確認追求越快越好，問題處理完善追求越快越好，速度代表的是績效，是專業，是品牌，是價值。 問題一： 公司想不想追求這一點，部門想不想追求這一點，是的話，願意付出多少代價？ 沒做好心理準備，沒願意犧牲、付出成本，一切都是空談。 什麼狀況都一樣，只願意給香蕉，只能請到猴子，猴子的作業，應該要有心裡預期可能會面對到時遇到什麼不良結果。 問題二： 該怎麼做？ 製作自動化整合測試系統，而且是自己客製化的驗證系統。 是系統，不是單一工具。是整合驗證與測試，不是單元測試。 先分析現況和確認情報。 1. 面對有問題的資料，我們不敢輕舉妄動。 這很好理解吧？你很想把它的資料丟到程式重跑一遍，看看發生什麼事？ 但是你敢嗎？後果可能錢會亂給，或者亂扣，或者寫入錯誤資料，寫入資料的地方說不定還有可能是別的部門的， 客人可能覺得你亂動它的資料，到頭來就會面臨四面八方的怒火。 更何況你怎麼快速的拿到有問題的相關資料？ 即便你有能力把它丟進系統重跑，但就能知道它在系統每個環節的作為，有如你的預期嗎？ 所以需要什麼淺而易見了吧。 1-1. 自動取得關鍵資料。譬如說輸入了使用者ID，程式自動挖出這個系統業務相關的參數給你。 1-2. 不要真的寫進資料到系統。該寫的沒寫，問題點好找，但若是中間的計算或處理有問題該怎麼判斷？ 如果真的為了重新執行一遍，把資料寫進去了，你不是完蛋？ 客人下單買了一件貨，被你查問題重跑兩次，它不就買了3件？但客人的問題是付款了系統確說沒收到。 所以驗證程式要自動避開真的寫資料的部分，中間需要假的資料作串接，拼死也要弄個假的出來，讓整個流程可以完整跑過，確認問題狀況。 1-3. 透明觀察箱。別於存在記憶體的程式，看不見在幹嘛，別於可憐巴巴地找程式每個階段，有沒有錯誤或異常的log。 這個系統要主動回報每個關鍵步驟，關鍵單元的執行結果或狀況， 好比我的專案，系統作業完整流程，DB有5個操作，redis有4個讀取，3個寫入， 有抓取七個部門的API來源，系統中間有6種關鍵計算處理， 每個部分都要回報，取到的資料是什麼，寫入有沒有

以下都是很主觀的個人經驗 大約在退伍後，剛進入職場當做工程師一年左右，被指派主持開發一個蠻重要的案子。 有次被調列的問題有點多，老大忍不住有點火大地過來，要來對每個問題。 那時候我也情緒不是很好，有事先稍微看一下清單內容，於是當場我跟老大的解釋是對方又雞蛋裡挑骨頭。 老大不爽的問我說，你真的都看過了嗎，每個都有去理解嗎？ 就算上次對方雞蛋裡挑骨頭好了，這次呢？真的是這樣嗎？你有好好去看了問題嗎？ 我稍微愣住，但是還是回答有看過。 老大又問我是怎麼看的，方法是怎麼做？ 於是我們當場挑了幾個問題，重新看過，跑一次怎麼分析問題和做處理。 一輪下來，我記得有兩三個問題真的是誤解了，問題雖然跟之前的很像，但原因是不一樣。 有個問題上次是真的挑骨頭，這次卻是真的有部分我們沒處理好。 老大留下一句話，「假設完了，就好好求證，求證後再說出來」，後續就交給我。 這事件是讓我非常非常印象，意識到我真的做錯事情，我的過往經驗和莫名的自信，害了該有的處置。 人無完人，莫名自信爆棚而幹的錯事，也還是在發生。 但想到就提醒自己一下，可以的話，就停下來多想一下，多求證一下。 工作上事情交給你，徵詢你的意見，是願意相信你，別辜負了。 後來換了工作，碰到的人比較多了，發現竟然有的人不會放下矜持做假設，不敢假設， 人家說什麼他聽什麼，跟他問什麼講不出什麼意見來，那也沒關係。 所以後來，能夠提出假設的人，在我心目中都給予至少某種程度上的肯定， 能夠試著去設想問題，已經是不簡單的事情。 但更多人止步於此吧。 要求證到什麼地步，要推論到哪個層面和範圍，的確真的很看個人的經驗，和自由心證。 我看到的是很多人已經很習慣的嘗試假設問題，卻疏於去求證，放棄邏輯推理的練習。 握有什麼的情報和證據，可以做到什麼地步的結論和推理，這是一直需要練習的， 這是人類的心理活動，而非如程式有固定公式，有什麼input就可預期有什麼output， 有時候也不是若P則Q，或非P則非Q這麼簡單，首先你要知道你的P和Q有沒有抓對是吧？ 有時候沒痛過也學不得教訓吧？ 若以前我沒那種經驗，也許我與很多人也沒什麼不同，掛著專業的頭銜，夸夸其談，實質內容卻可能有些問題。 大膽求證，能假設多廣就多廣，我是做系統的，但小心求證！

說明 有些問題的類型歸類，實在難以釐清。 可以比較確定的方向是大概就兩點 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的操作。 事至如此，我覺得我也有錯，因為當下接到問題處理的人不是我，我就提出我的意見後，繼續去做我的事情了。 算不算親手製造一個悲劇？該死的風氣 然後後續就有點債留子孫的感覺 問題發生原因是什麼，發生的機率又低的很可怕，以目前資源和環境你想重現，又沒辦法。 後來問題重複出現，半年過去，出現過幾次，以這麼大量的分母，這個分子根本九牛一毛。 為什麼會容許重複出現呢？ 我想是實在問題出現機率太低了，我們有更重要的東西要優先處理，又或者所做的修正是頭痛醫頭，腳痛醫腳，所以當然弄不好。 這點我也沒辦法，當我不知道問題切確問題點，也許給出的分析或處理方案也是頭痛醫頭，腳痛醫腳，這是沒有辦法的事情。 優先處理已安排好的專案需求，優先處理被客訴的問題，優先處理明確明顯的問題。 對這是我們的現實沒錯，但探究困難問題的原因，我認為不該被推到第四象限，不緊急不重要的部分，然後改天就被默默遺忘了。 好像只是要個交

極端狀況的認知 有時候狀況不可預期，無法預期就無法評估或控制。 極端狀況所造成的災難，很明顯與直接地造成公司或部門的損失。 災難範圍多有大，取決於看運氣，可能引發ㄧ點點小部分的錯誤或異常。 有可能引起一連串的反應，拉著一卡車的相關部份一起陪葬。 兩者我們都有遇過。 我所謂的極端狀況，指的是，超出系統架構設計上能承受的負荷。 系統設計和安排上，總有些前提，和預期的控制範圍，若失控崩潰絕對不會有好下場的。 危機、轉機，發現價值 這些處理和理解極端狀況的部分，撇開公司的受損另外討論，對技術單位根本是寶藏。 技術單位的技術儲藏、看家本領的技術底蘊，不是從這裡來，要不從哪來？ 自己的架構、設計、環境、業務處理邏輯，從外面哪能遇到的這麼貼切的類似情境， 外面哪裡有可參考的極端狀況，成因和處理可以學習？ 這種成因，分析方式，試驗手法，以後要避開的設計誤區，考量狀況重點，最應該寫成文件或範例，並且在部門交流內讓每位開發者深刻認識與學習。 不然災難過後所留下的ㄧ點好處，只有能夠理解的人獲得殘餘價值，然後在其他人面前大剌剌的漂過，然後呢？ 我的媽呀，同一個部門大家做的業務性質處理很相近，其他人改天再弄一次嗎？ 付出群體的代價，卻沒有群體的收益，倘若技術只綁在少數人，如果人走了呢？技術部門是不是某種程度上又打回原型。 比喻 接下來我就舉兩個例子，引發災難ㄧ小一大，兩份珍貴的收藏。 剛好都是與資料庫相關的case。 看不懂的人可能覺得沒價值，跟一般的小錯誤沒什麼兩樣，但是請聽我說來，這跟一般的小錯誤有什麼不同。 很多的小錯誤，業務或邏輯，或者粗心所製造的錯誤，有些方法可以防範，邏輯思考模式經過長期訓練，也可以趨於完善，可以檢討SOP，或用測試手法預防。 但這樣能解決的問題，還叫做遇到極端狀況嗎？ 想得到，測得到，預防的到就不叫極端狀況了，所以這種經驗你說可不可貴。 遇過了，之後可能就不一樣。 打個比方，你要防衛敵對國家的武力進犯，你的評估是對方武裝實力其實跟我們差不多‧ 你做了海上防禦部屬，陸上陣地部屬，空中預警部屬，甚至綜合打擊部屬，因為我們要打人家也差不多是這樣的方向。 結果開戰當下，敵人竟然使用太空打擊武器！ 如果僥倖活下來不死，是不是應該警惕地審慎思考過所有環節？首先

小系統，大系統 如果專案本身規模小，或處理量小，在程式架構設計沒有重大瑕庛的情況，測試程序完成上線後， 要遇到的問題或收到bug回報的機會本身就比較小，往往feedback的問題也比較無關痛癢，或者不會到需要系統功能掛維護，或者整個系統crash。 大規模的系統往往無法單憑人工檢查，就可以得知受災範圍，或者做資料修正，ㄧ旦有事，往往大事。 小規模系統出事的處理經驗，很難套用於大規模專案的處理。 越大的系統處理成本越高，應該是可以預期的，觀念上應該做好有這樣的心理準備。 各方面影響也都不同，沒人敢說成本可以控制成線性成長。 處理10萬資料的系統，要花10萬塊成本的話，有人敢說處理100萬資料的系統，只要花100萬嗎？不一定，很難講。 自然而然的事情 如果以一樣的設計基準點，每個小時處理上百個資料的業務計算，和每個小時處理上萬個資料業務計算，誰比較有可能出狀況不用明說。 拿個現實上的比喻。 為什麼現代人比起古代，更多的人口比例得癌症。 文明病是真的文明病，主要原因還是人類平均壽命拉長，活得越久本來就越有得癌症的風險。 細胞分裂越多次，身體機能越老化，分裂發生錯誤的機會當然跟著提高。 有些人成天依據自己的意見，或者次因怪東怪西，不如看看20歲以下的人口得到癌症的比例是多少。 看待事情若無法得知原理，起碼要相信真實的數據。 修問題如治病，先了解病因和病況，確認原因後再治療。 若是生大病，怎麼可能用小病的治療方式，讓身體恢復健康。 頭痛醫頭，腳痛醫腳，是無法治療內分泌失調。 遇到嚴重的新問題，會頭痛的困難點有兩個 1. 如何判斷是大病？ 大概有些特徵，譬如說過去經驗無得參考，成因複雜難以簡單分析出來，規模大才會發生的問題，極端狀況才會遇到的問題。 正向思考一下，對目前來講都是大病，當我們夠經驗了，經歷過了，在未來就是小病，也意味著我們可以作規模更大更精密的系統了。 假設某個設計方式可能存在缺陷，系統經過那個部分，發生錯誤的機率是萬分之ㄧ，系統規模小，每天只執行10次，運氣好可能好幾年都沒發現那個地方有缺陷。 承上，假設系統使用的頻率變高了，每天執行1000次，可能一個月就遇到了問題發生，能解決就是經驗，下次設計時避免掉，這個問題對我們來說就不是什麼大事，已

變形的作業方式 開發人員不做開發文件，卻投入製作某種意義上的維運文件。 沒錯，有些know how開發者才知道，但維運者不知道就無法判斷問題或處理嗎？ 已經驗證過的input和output真的有需要懂理面在做什麼? 如果如此，那麼這個模式背後指出許多問題。 1. 開發與維護根本沒實質切開，仿佛高偶合的程式碼，切離開發那塊knowledge，是做不到的。 2. input和output無法控制範圍，無法信任系統會處理到什麼狀況，產出什麼結果。 3. 開發人員無法給維護人員保證，維護人員總需要開發人員協助。 分析 所以開發人員的產出結果能夠被保證，input和output範圍能夠控制，維運人員可以在有限的範圍搜索問題與釐清feedback。 能做到如此，我們就可以破除困境。 開發人員： 是大廚，食材原料是什麼，中間加了什麼調味料，做法工藝是什麼，煮出的東西大概會怎麼樣，雖然味道最終是客人品嘗。 但做菜的前後，當然是主事者最清楚，維護的人怎麼可能知道，所以有需要這方面的說明和了解當然找開發者。 開發者握有這部分的大權，訊息、情報最完整的資訊，call 什麼資料庫，call什麼API，資料怎麼加工，過過什麼驗證檢查，就開發者最清楚。 文件無法真實代表程式怎麼跑，這部分的knowledge又會隨著時間流逝，ㄧ點一滴的從開發者的腦袋中流逝。 開發者應該即時的花費精力付出這部分，但要怎麼做？ 維運人員： 是場控，是經理，是服務生，反正做菜以外全包了。 要做的事情大多是接收客人反應，確認狀況，假設客人抱怨點了牛排七分熟，卻拿到豬排還不熟，就開始找問題了。 首先確認客人真的是點牛排七分熟，再來確認點餐的訊息有傳到內場，內場真的是收到牛排七分熟的點餐。 假設這個廚房非常先進，收到點餐，有特殊機器自動抓把肉抓出來處理烹煮，烹煮之後自動傳到人員裝飾擺盤，就送到外場。 所以維護人員再找，是不是牛肉櫃裡面有人放了豬肉進去？烹肉的機器是不是故障？傳遞到擺盤人員的中間過程是不是有問題？ 送餐的人員是不是送錯，客人是不是真的拿到豬排還不熟？ 他不應該懷疑機器收到抓牛肉的指令，卻去抓了豬肉。 他不應該懷疑，擺盤人員故意惡搞。 這些應該是要被驗證和保證的部分。 可是今天如果內場他完全進不去，

結論 文件能不能解決問題？ 某些目的和用途上能提供的幫助非常有限，在我全程主持的幾個專案，努力要求了，了解了某些事情，最終釋懷了些一直堅持的想法。 放下別人的要求，繼續堅持認為該做的事務。 以文件為主軸，在部門的環境內這個方法行不通，因為我們頭痛的問題與面臨的狀況，文件並沒有太有效與即時的助益。 文件在開發上的好 開發的過程中，文件可以很有邏輯條列規格，多人開發、前後端溝通上大幅地減少溝通落差，這點非常有幫助。 在文件幾乎齊備的情況下，就不太會發生以下情形 1. 多人開發上互相介接，介接上有嚴重錯誤或誤會。 2. 進乎成品後才發現團隊有功能漏做，以為有人會實現缺少的部分。 3. 需求不明確，送測或上線後才發現。 4. 上線後發現系統不穩定，因為未在設計階段做考量，後續難以補救。 文件不能有效地解決，目前往往遇到的瓶頸問題，不過帶來的好處某方面來說，依舊難以取代。 我認為文件是製作好專案一個必要的環節，所以都會做文件，也一直嘗試做出每個專案最適合的文件。 一直以來也不斷鍛鍊自己撰寫文件，畫各種說明圖的技巧，這部分在有限的成本與考量上能做的已經趨於極致。 需求文件，SA，SE，SD，DB規格，API規格，Redis規格，專案注意事項，有限的壓力測試說明與報告，流程圖，架構圖，河道圖，有序圖，FSM，看專案用什麼表達可以最清楚關鍵重點，持續以來的自我要求，好像達到某種程度或者說是自己的極限，以2/8法則來說，要再更精進，需要再花費80%的精力才有20%進步，何必呢？文件只是一種工具。 一路走來 目前本分是工程師，做著工程師的工作，理所當然對於寫文件也難相比設計程式上的幹勁，只不過是必須的部分，對此報以敬業的態度一直在努力。 自己好像太過一廂情願的往前跑，情境好比抵達里程碑後停下腳步環顧四周，才驚覺沒人跟上(不知道是不想跟我著我的方向走，還是跟不上)，除了自己的腳印只有荒煙漫草，不見他人人影。 不是我在的專案，文件不文件的，撰寫文件的推廣上，逐漸感到意興闌珊。 他們需要的不是文件。 也許大部分人很難理解文件內容描述背後的意義。 很多人未俱備契約精神，定好的規格，沒那麼嚴格考慮或遵守。 過往經驗，重視文件的起點 不知不覺，回過神來，我也沒想到現在的自己對於文件的理解上，在部門內

至少我做到了用更多的耐性靜觀其變，更好的隱藏自己的情緒，在其他人面前平靜的討論與提早離開。 不光是技術，或者概念，個人社交的能力或許這樣子......也算是進步，今天不知道為什麼還能試圖表現冷靜。 #前兆 事情是這樣的 差不多這兩個月以來，我主導與設計程式架構的專案，約略可以算三個，一直接連過幾天輪流就出狀況。 不是每個問題我都知道發生的詳細原因，左鄰右舍或座位前後左右的同仁在討論時，略有耳聞而得知有這樣的事情。 距離系統上線已經好一陣子，我離開專案開發和維護有段時間，頭一個專案完成甚至距今快要有半年之久。 做處理和維護的人不是我，但若有我知道的case，多少也會關心一下，畢竟是這幾個專案的首席。 自己的孩子長得怎麼樣，有心力還是會想關心的。 接連的出狀況，終於有個引爆點讓部門整個炸掉。 主管們的反應，可以隱約得知承受莫大的壓力。 #事發 前天引爆點的事故，除了當值的上面ㄧ級主管和值班同仁，自己也身受其害。 凌晨2點被電話吵醒，3點多才睡著，4點被叫起來支援直到天亮，到現在過兩天了生理時鐘還怪怪的，較年長的ㄧ級主管和連續上陣17小時的同仁可見更不好過。 問題的源頭是提供資料的資料庫部門資料有漏，ETL出問題，當日下午兩點的排程執行下去，30萬筆資料已經進入後續流程當然有問題，寫入有問題的資料。 資料庫部門修正了第一次還是有問題，重跑了資料，值班的同仁用工程師的方式修正資料，重跑排程，晚上又被客訴，再次確認是資料庫部門修正有問題。 他們再次重新修正資料，又重跑排程，又有不知名問題，所以臨時拉我支援。 後來證實這不明的問題，是因為設計上的限制所導致，(當時應客戶做奇怪的需求設計)，這種排程重跑遇到撞到那種設計考量，當然會出問題。 (詳細業務內容不方便說明) 這個重跑工具最初設計是為了發生事故沒按時啟動，過了時間點可手動啟動，而不是跑過有問題再重跑而製作的‧ 之前因應某些資料來源錯誤做處理，也有執行過這個工具兩三次，因為那時處理的比現在資料量少，剛好沒撞到那個設計限制，我自己也時間久了忘了這種情況。 我們需要接別的部門資料有7種來源，經過幾十道程序，做業務邏輯判斷後處理，資料庫部門提供資料有誤雖然之前也有前科，但不一定每次是他們。 總之這個事件曠日廢時的處理許久，最後又沒有一個完好的