已經過了鐵人賽的三分之二了，也是花了近三分之一的篇幅跟大家分享，從故事中舉例可以做哪些優化。而這些痛點在改善之後，下一個發生問題的點又出現，然後又再一次次地發現問題、修正問題，然後優化之。

在今天的篇幅當中，給大家一個參考的範本可以如何紀錄在優化過程中當中，在 Job 微調之後的差異性。

• 用途：該 Job 在做些什麼事
• 有無 Jenkisfile：該 Job 有腳本，需要找到對應的腳本在哪裡才能進行優化，若沒有代表，該 Job 有自行執行的指令或是自己的流程，從 Jenkins 的介面即可執行。
• 有無封存檔案：在執行 Job 之後，是否有包留一些檔案，供 Job 顯示結果，或是其他需保留的檔案。
• 觸發條件：遠端的分支、git tag 或是綁定外部的 webhook 觸發之
• 執行頻率：執行該 Job 的頻率
• 痛點：現下最的問題
• 優化方向：依痛點可以怎麼進行，會列出多個執行方向
• 調整方向：優化之後，前後異動紀錄，以偶改善的項目有哪些

紀錄這麼多細節有什麼幫助嗎？首先是在 Jenkins 在微調內容，並沒有像 git 可以去追蹤前後改了什麼。如果是修改 Jenkinsfile 可以從中觀察到前後，但大都數的狀況下只能用用列下異動的方式去觀察前後的差異，在不斷 try and error 會找到對的方向。列出這些細節，也能觀察各 Job 之間是不是有重疊使用的地方。舉例來說，當時我在檢視目前所有的 Job 時，發現有些執行的效率太低落，而且要做的事情也跟其他 Job 有所重疊。像這樣列出來一目了然，也可以馬上做出些決定去做增減。