說完了幾個小故事，以及一些想法觀念，我想接下來就來聊聊，未來，我與團隊們可能會怎麼在我們的工作流程中，加入 DevOps 的精神。

我想第一個會做的是把所有的 API 功能呈現出來，跟為什麼要用爬的？！(1/2)這篇小故事說得有點相關，首先是把所有 GET 取得資料的 API 都列出，方便自己也方便我們的維運同仁做介接，其他 POST、PUT、PATCH、DELETE 等會異動到資料的 API ，安全性要做好，限制權限讓特定的人才可以使用。

我自己跟朋友私下在做的專案，就有使用 swagger 這個工具，不僅是可以當作是 API 文件，更可以直接從頁面上直接測試使用 API，我還有聽說有些團隊把程式碼跟文件做結合，當你寫好文件提交到 Git 時，程式碼的 function 也會同時幫產生，當修改了文件後，亦會自動調整 function 的寫法，聽了有沒有很心動呀！！

除了製作 API Demo 頁面以外，我覺得有些功能在製作時，可能不見得會有 API ，但是當排除問題時，有發現某些特定資料是每次都需要資料庫取得，有或者是需要比對多支 API 資料時，那也就應該要被寫成程式，加入 Demo 頁面中，方便之後檢查時使用。

我自己就常遇到的狀況就是，跟使用者相關的資料可能跨過很多個資料表，也有很多支 API ，有遇到程式有臭蟲時，在新增某些使用者時，缺少了某些資料，造成部分功能出問題，但我們又不能肯定到底是哪些資料有缺少，我們可能必須要逐一查看可能的 API，像這樣的情況，就會建議要製作一支專門用來檢查使用者資料的 API，當然如果可行的話，再做一支方便修補資料的話更佳。

當兩支 API 都有的話，更進一步，把兩支 API 串起來自動化檢查，並把缺少的資料補足，那就更便利了。但這邊我還想建議一件事，架設團隊真的很厲害，已經做到系統會自動檢查，而且也可以自動補足資料，就可以置之不理了嗎？我的答案是『不是！』，當檢查有問題時，也應該要傳送告警讓開發人員知道，並且安排時間找出會缺少資料的根本原因，修正問題才是根本解。