隨著這些年參與社群活動，與各方高手交流，一直以來都很想以「DevOps」本身為題，留下些文字。
但總是以最近很忙、沒時間沈澱內容為藉口，一再拖延。
今年依然是忙到炸了，於是在頭被門夾到般神智不清的狀況下，決定就讓它更忙吧！
上面是我在今年參加「iThome 鐵人賽(2022)」時，於第一篇文章 Day 0 留下的文字，就如這段文字所述，一直以來都想要以「DevOps」為題，寫一些長篇系列文或科普文，但總是以「忙碌」為藉口，最終沒能有所產出。
這麼多年過去，今年終於忍不住了，我一定要寫，讓我寫，就算是用亂聊的方式，我也一定要寫些什麼，於是就誕生了這次的鐵人 30 篇文章。
這次參賽的主題為「重新認識 devops」，在系列文標題上，我故意使用小寫的「devops」，而不是當今常見的「DevOps」，不知道是否有人知道我的用意為何？這裡就先賣個關子，如果有人知道答案，可以私下與我聯繫，如果有答對正確答案，就讓我贈送你一本《和艦長一起 30 天玩轉 GitLab》（第二版）吧！（正確答案就讓我留到公布今年鐵人賽得獎名單的那天，再更新於本文吧！）
更新：鐵人賽得獎名單已經公佈了，所以我也來公佈我為何會使用小寫的「devops」，而不是當今常見的「DevOps」。其實原因很簡單，算是想要區別 2009 年
devops這個詞剛出現沒多久，在那一個年代還很單純的devops，以及經過多年直到現在已經被添加了各種多方意見，甚至是大幅偏向談論技術與工具的DevOps。不知道你是否也覺得不同年代談到 DevOps 其實談論的內容也是大不同呢？總之，故意使用 devops 與 DevOps 算是我自己一點小小的「表態」，因此你會看到在今年的鐵人賽文章中，有些地方我會故意使用devops，但有些則特意使用DevOps，不曉得大家是否有注意到這項差異呢？今年的鐵人賽，因為是走一個拉迪賽的路線，並沒有談到太多深入的內容，如果未來有機會及餘力，希望可以重新再來一次「重新認識 devops」，將更多想寫的內容都一一落成文字。
目前文章依然留存於「iT 邦幫忙」網站上，一樣就暫時不搬回這裡，僅以超連結的方式連結各篇文章：
系列文「重新認識 devops」的內容大致上可以分成幾個主軸。（但因為是走想到哪寫到哪的路線，所以你也可以按著 Day0 ~ Day30 的順序讀下去。）
一、這次花了很多篇幅在講古。
- Day 0：起心動念
- Day 1：DevOps 只是個 hashtag
- Day3：2009 至 2022 DevOps 議題發展趨勢（一）
- Day4：2009 至 2022 DevOps 議題發展趨勢（二）
- Day6：DevOps 講古（一）
- Day7：DevOps 講古（二）
- Day8：DevOps 講古（三）
- Day13：從歷史看 CI/CD Pipeline（一）
- Day14：從歷史看 CI/CD Pipeline（二）
- Day15：從歷史看 CI/CD Pipeline（三）
- Day16：從歷史看 CI/CD Pipeline（四）
- Day17：從歷史看 CI/CD Pipeline（五）
- Day18：從歷史看 CI/CD Pipeline（小結）
二、也談了一些 DevOps 常見的老議題
- Day 2：DevOps 失敗了
- Day9：DevOps 定義大亂鬥！
- Day12：DevOps 不只是 CI/CD
- Day19：DevOps 是不是一種職缺？（一）
- Day20：DevOps 是不是一種職缺？（二）
- Day21：你需要一張 DevOps 認證？
- Day24：如何評量 DevOps 的進展與成效？（一）
- Day25：如何評量 DevOps 的進展與成效？（二）
三、反覆聊了一些筆者目前對於 DevOps 的幾個核心想法
- Day5：形成一條能夠幫助團隊的路徑
- Day10：廣義與狹義的 DevOps
- Day11：DevOps 全是廢話
- Day22：DevOps 工程師為何搞不定 DevOps Pipeline？（一）
- Day23：DevOps 工程師為何搞不定 DevOps Pipeline？（二）
- Day26：也許你不一定需要 GitOps 或 Platform engineering？（一）
- Day27：也許你不一定需要 GitOps 或 Platform engineering？（二）
- Day28：也許你不一定需要 GitOps 或 Platform engineering？（三）
- Day29：BizDevOps
- Day30：你會走上 DevOps 的持續改善之旅嗎？
