台積電仍然沒有一個組織專職負責 DevOps 或 SRE 工作，軟體開發人員與系統管理人員仍然分屬不同部門，平日交流的機會仍然非常少，甚至還有些對立，系統維護人員會覺得 AP 測試的不嚴謹，軟體開發人員會覺得系統維護人員在刁難。
目前公司管理層越來越會把 Automation 跟 DevOps 掛在嘴邊，且推動著所有人開始轉型，目標是好的，但是成效仍然需要評估。
錯誤的 DevOps
DevOps 仍然是一個 軟體開發 + 系統維護 雙軌並進的概念，軟體開發人員與系統管理人員需要共同合作才能做到持續整合 CI 與持續部屬 CD，因此雙方合作變得至關重要。
以下 A 團隊是軟體開發，B 團隊是系統維護
- 自動化
目前還有非常多的系統是手動上 config，系統管理人員需要花費 80% 的工作時間來做系統設定，如果沒有辦法自動化，連 DevOps 的邊都會沾不上 - 持續性開發與維護
IT 服務公司，因此很多的開發都是專案導向，專案開始之後進行開發，專案結束之後進行維護。因此沒有甚麼持續開發的可能性，專案開始是 A 團隊負責，專案結束是 B 團隊負責，結果 B 團隊覺得 A 團隊事後不理，A 團隊覺得 B 團隊不願意協助結束專案。
因此當 A、B 團隊之間有衝突的時候就會造成 DevOps 概念無法持續，無限符號也永遠無法完成。 - OpenShift 導入
其實不是說這套軟體不好，是這討軟體在公司內部使用下，造成 A、B 團隊完全脫鉤，B 團隊只要負責 OpenShift 維護，A 團隊只要負責 Container 與 Pod 可以順利被送進 OpenShift 且 AP 有順利被開起來。一切看似美好，實質上卻失去 A、B 團隊合作的契機。 - 過度在乎 R&R
公司仍然是以工廠 Pipeline 的管理模式在經營 IT，因此一手交一手仍然是管理的主流方式，因此會非常在意這是不是我要接管的，或是不是我的守備範圍。但是在 DevOps 的世界裡，這個界限是相對模糊的，B 團隊應該在開發 AP 的時候就與 A 團隊一同規劃架構與需求，A 團隊也應該在維護模式的時候與 B 團隊合作提升可靠性。
過度的在乎 R&R 是完全不利於 DevOps 的管理方式。
持續精進
只能說公司有太多包袱，而當公司要因應時代向前邁進時就很容易跛腳。
我仍然認為當前公司邁向自動化與持續部屬是可能的，但是從管理思惟到工程師接受程度都應該要有所改變。當思維需要改變的時候就需要花費非常多時間去調整，至少這年自動化成為最主要的工作項目，先讓一批願意接受 DevOps 的人開始針對幾個專案進行調整，等這些項目成功後，就可以向外推廣到其他專案上，並讓大家都能了解 DevOps 帶來的好處以及成效。
結果又把文章寫成抱怨聞了 (傻眼