[工作日誌] #8 自動化整合測試與驗證系統，全面掌握問題的希望
自動化快速驗證系統 - 中央集成
不論是誰來反應問題，維運人員收到問題回報或者詢問，一定想要用最快的速度確認到問題原因，或者是不是真有問題還是誤會一場。
確認追求越快越好，問題處理完善追求越快越好，速度代表的是績效，是專業，是品牌，是價值。
問題一：
公司想不想追求這一點，部門想不想追求這一點，是的話，願意付出多少代價？沒做好心理準備，沒願意犧牲、付出成本，一切都是空談。
什麼狀況都一樣，只願意給香蕉，只能請到猴子，猴子的作業，應該要有心裡預期可能會面對到時遇到什麼不良結果。
問題二：
該怎麼做？製作自動化整合測試系統，而且是自己客製化的驗證系統。
是系統，不是單一工具。是整合驗證與測試，不是單元測試。
先分析現況和確認情報。
1. 面對有問題的資料，我們不敢輕舉妄動。
這很好理解吧？你很想把它的資料丟到程式重跑一遍，看看發生什麼事？
但是你敢嗎？後果可能錢會亂給，或者亂扣，或者寫入錯誤資料，寫入資料的地方說不定還有可能是別的部門的，
客人可能覺得你亂動它的資料，到頭來就會面臨四面八方的怒火。
更何況你怎麼快速的拿到有問題的相關資料？
即便你有能力把它丟進系統重跑，但就能知道它在系統每個環節的作為，有如你的預期嗎？
所以需要什麼淺而易見了吧。
1-1.
自動取得關鍵資料。譬如說輸入了使用者ID，程式自動挖出這個系統業務相關的參數給你。1-2.
不要真的寫進資料到系統。該寫的沒寫，問題點好找，但若是中間的計算或處理有問題該怎麼判斷？如果真的為了重新執行一遍，把資料寫進去了，你不是完蛋？
客人下單買了一件貨，被你查問題重跑兩次，它不就買了3件？但客人的問題是付款了系統確說沒收到。
所以驗證程式要自動避開真的寫資料的部分，中間需要假的資料作串接，拼死也要弄個假的出來，讓整個流程可以完整跑過，確認問題狀況。
1-3.
透明觀察箱。別於存在記憶體的程式，看不見在幹嘛，別於可憐巴巴地找程式每個階段，有沒有錯誤或異常的log。這個系統要主動回報每個關鍵步驟，關鍵單元的執行結果或狀況，
好比我的專案，系統作業完整流程，DB有5個操作，redis有4個讀取，3個寫入，
有抓取七個部門的API來源，系統中間有6種關鍵計算處理，
每個部分都要回報，取到的資料是什麼，寫入有沒有確實，每個部分的計算結果和數值是什麼，全部通通列出來！
甚至每個部分花了多久，若中有保證順序，有A就一定有B，那系統看到執行下去沒有B，甚至可以作自動判斷回報，後續也別做了。
2. 個體受害，還是群體災難的迅速判斷需要。
被問題反應後，到底要花久才能知道這件事？因為群體災難發生，可能要先將功能掛維護，
個體異常急迫性就沒那麼高，而且可以推測系統是沒問題的，這個個體可能是在系統外就出了狀況。
2-1.
承1-1，也許被回報的只有一個人，但他的相關參數拿到後，就可以以這參數觸及相關資料對象，自動化先跑那些人的資料。有群體資料可以比對，你才知道是不是有多人受災，若一群人的結果有好有壞，是不是可以藉此來判斷共同點？
2-2.
這是傷害範圍控制的概念，風險控制的概念，越快能確立，受害的減少越多，人工絕對比不上，自動化系統是唯一指望，但是做系統昂貴呀。2-3.
承2-1.降低部分人為誤判，回報者也許認為個案，你用人工判斷或許也有可能覺得個案，但是系統自動化跑過，個案不個案可信度更高。因為你人工抽查，可能抽個10個了不起就累死了，自動化系統輕輕鬆鬆做幾百幾千個。
3. 高度仰賴人員戰鬥素質與外在指引
機器是穩定重複，而人類隨時都在變化
3-1.
要人工查問題，首先它要知道要查什麼部分，或知道哪些是關鍵，如果不是開發者，我們目前狀況往往非常仰賴外在指引。指引要從哪裡找，有些甚至很模糊，系統功能實在太多了，甚至開發者，久了理所當然會遺忘某些關鍵部分。
自動化系統對於這個專案，要查哪些關鍵部分，早就寫進程式裡面。
甚至這個系統可視化完整時，可以將指引寫在畫面上，輔助解說自動化系統執行完之後的結果報告，幫助不熟悉的人員知道如何進行下一步。
3-2.
人員往往需要對系統的結構與業務邏輯，了解到某一個程度，如此一來要處理問題他才能知道下一步是什麼？這個教育成本無形的高昂，而且效果不彰，你要人員在短時間，要不給你一整天8小時，即使兢兢業業的研讀，到底能夠了解到什麼地步？
我覺得我自己是做不到，很難過的是，我也不認為其他人有好到哪裡去，系統已經夠多了，原本的開發工作，應該才是全心全意投入的對象才對。
4. 單元測試從來不能代表整合測試
數學以外，很多東西不是1+1會等於2。
A、B、C各自沒問題，不代表合起來會沒問題。
4-1.
我們手上的確有些工具，但此有相當的謬思。單元測試的確可以拿來驗證，某些單元是否發生異常，譬如說對於某個部門的資料取得是否有異常。
額外問題是，人員要知道有哪些相關的工具或單元測試可以使用。
再者，這些工具不是自動化系列執行，人工就是慢，慢就是失去某種價值。
專屬於某系統業務處理的單元工具，放在整個部門所有系統共通的工具系統，數量一多，改天也是衍生新問題。
4-2.
只有中央一個的單元測試工具真的準嗎？golang和php送出去的request內容，對底層來說是完全相同嗎？
理論上應該不管底層，參數一樣，結果應該要一樣。但我們提供API資料的部門，呵呵.......
假設環境繁多，自己機房，GCP，AWS的環境，單一一個環境的測試，無法保證到百分百的測試一致性。
這個部分就要可能要靠寄生型的自動化驗證程式判斷。
5. 如果可以，想不想搶在被客訴前、被反應問題前，先知道已發生問題
快的價值，能夠建立信任。
客服或維運人員想不想在接到電話或通知時，大大方方的告知對方我們已經知道問題，正在處理中，請耐心稍後？
5-1.
自動定時跑整合測試，有異常報告自動通知，部門某個功能已經有類似的東西了。該功能非常重要，誇張一點也可說是公司業務的立命之身之一，所以願意花成本製作那個工具。
已經做到了整合測試，但我認為還不算系統階段，半工具半系統的存在。
我認為每個功能在開發結束階段，開始製作屬於這系統的自動化驗正功能，應該要是一種文化，而不是有性命之危的時候再想到要抱佛腳。
5-2.
Daily Build我覺得這個概念很不錯，我們可以將之變形，改造成適合我們的處置。
重新規劃與調整目前的發佈機制，要重上佈署的程式，先在次一線環境建置，建置完畢後自動執行我們的自動化驗正程式。
先跑過某個數量級的驗證，檢查報告沒問題之後，再推到正式環境。
寄生型
很遺憾的規模大，機器數量多，專業不在我們這邊，容易什麼鬼都容易碰上。
遇上個體有差異化的情形，只有寄生型的快速自動化驗證程式，可以幫助我們做驗證或判斷。
假設機器有三台，三台的環境都一樣，結果程式執行下去，一台成功，兩台失敗。
所以驗證系統放在某一台中央環境，是沒有辦法cover到這種情形的發生。
所以需要中央，也需要地方寄生，地方寄生型可以跟中央的做橋梁，設計互相溝通方式。
可以更快的啟動寄生型的程式幫忙做檢測，或者中央可以藉此定時收到地方回報。
地方寄生型可以定時做自動檢測，然後判斷檢測結果，回報給中央報告是否有異常。
地方寄生型沒有按時間做回報，中央是不是就可以跳警報了？
看是要寫更強大的機制，系統自動去確認失聯的孩子發生什麼事情，還是通知人員，採取人工檢查或判斷？
擴展
有了問題精準判斷，系統是不是可以再加入自動修正處理的部分
這個部分，可以由大家再去想，並沒有局限
所以我說是個系統，要的是系統
留言
張貼留言