DevOps 開始到崩壞?

即將迎來一年一度的DevOps Days，回顧起自我從2017年開始涉足DevOps主題的旅程，首次探索這一議題是在北京的一場高峰會。隨後，多年來我持續深入探討，從團隊協作到塑造企業文化，再到工具運用與自動化等各種議題。然而，更早的關注焦點則放在Scrum與Agile方法論上，而正是這兩者驅動著DevOps的核心動力。

然而，歷經十餘年，Scrum和Agile方法論真正在企業中實現了多少呢？坦率地說，能夠實際落地的企業屈指可數，真正付諸實踐的案例甚是罕見，而其中一些僅僅是表面的皮毛。如果說Scrum和Agile都難以實現，那麼我們不禁要問，DevOps又是否更加具有挑戰性呢？否則，Scrum和Agile早就蛻變為另一個新的名詞了。

從早期大家關注的「資料探勘」，到如今的「大數據」與「數據湖」，事實上，核心原理並未有太大的差異，僅僅是名詞的變化帶來市場的熱度。同樣的邏輯也適用於如今極為熱門的人工智慧領域。沒有大數據作為基礎，AI又如何有所作為呢？因此，在引入AI的同時，事實上我們仍然在討論著大數據的議題和資料清理。

DevOps 本質

DevOps的本質實際上涵蓋了文化、流程和工具的整合。這三個要素相信許多人都耳熟能詳。然而，在這三者之中，工具似乎是最受矚目的。市場上充斥著各種選擇，挑選最適合的工具有時確實令人頭疼。你選擇了A公司的工具，隔天B公司可能就推出更為優越的選項。然而，我們必須明白，工具僅是DevOps過程的一環，不能僅憑此判斷優劣。我認為，工具就像裝備，擁有良好的工具當然能事半功倍，但最終效果還取決於使用方式。

流程和文化則是更為關鍵的部分，同時也是較為複雜的方面。當我們開始實施DevOps時，每位成員都必須在團隊中協調一致，從需求到運維都需要建立流暢的流程和協同作業模式。然而，要在企業中建立這樣的模式並非短時間內可達成的目標。在這個過程中，我們將不斷面對挫折和挑戰，只有持續努力和克服，才能繼續前進。然而，正因為如此，成員們積累的經驗和知識會逐漸增長，即使新加入的成員也能在這樣的環境中快速適應，無需擔心跟不上的問題。當然，前提是需要找尋適合的夥伴。

在網路上有許多指導如何建立健全文化和流程的資源，這些都是可供參考的寶貴資訊。然而，人是複雜的生物，改變並不容易，尤其是當多人協同工作時。因此，我認為時間是至關重要的因素。如果不給予足夠的時間，要實現轉型和成長將變得相當困難。

你開始DevOps，別人呢?

當團隊踏入DevOps的領域，我們需要開始觀察周遭的團隊是否也在實行DevOps，或者他們是否具有相同水準的知識來討論DevOps。而在這個時候，我們也可能陷入「這份工作是我的職責」或「這是我的績效指標」的思維模式中，尤其是在大型企業中，這樣的情況十分普遍。

早期，我們注重的是責任的明確分工，並認為分工愈細愈好。這樣做自然會導致開發者僅專注於編寫程式，佈署專業人員只負責佈署，運維人員只關心運維，資安團隊專注於保障資安等。有些公司甚至分工更細，例如建立AD（Active Directory）與管理AD的工作被分派給不同的人，而這些人的操作權限又受到限制，雙方互相無法介入對方的工作。

這種模式的好處在於，責任分工明確，每個人的工作相對輕鬆，只需專注於特定領域。然而，隨著技術和工具的進步，我們需要重新思考是否仍然需要如此細緻的分工。

另一個分工帶來的問題是，每個團隊就像是功能性團隊，只需關心自己的工作，對其他團隊（部門）的事情不感興趣。這可能與DevOps的本意不符。DevOps的核心並不僅僅是將開發和運維整合為一個團隊，更重要的是要在心態上實現兩者的平衡和協作。早期我們總是希望每個環節都能最優化，但在整合開發和運維這兩個環節時，兩者各自的最優化未必能帶來整體的最優化。這在很多案例中都被證實，最終可能兩方都無法達到最佳狀態。唯有雙方願意讓步，整合才能實現最優化，這正是限制理論所強調的。

然而，讓步這件事情常常相當困難，尤其是在跨國或跨文化的情況下，可能需要從領導層面來引導。正如之前的研討會所提及的，DevOps需要的不僅僅是自下而上的實踐，同樣需要自上而下的推動。在很多情況下，缺乏上層的支援和決策，將增加實現的難度。

以資安團隊為例，如果只關注自身領域，追求個人的績效目標，而忽略其他團隊的模式和情境，將不僅限制了發展，還可能破壞原本團隊的工作模式。從技術角度來看，缺乏透過其他情境學習解決問題的經驗，也將限制個人的技術視野，認為只有單一種解決方案。這種情況對整個公司並不利。

所以，當你的團隊實行DevOps時，與你合作的其他團隊是否也在實踐呢？如果是，恭喜你，你們可以朝著Scrum中的LeSS（Large Scale Scrum）概念邁進，實現大規模的DevOps協同合作，進一步提升整體效益。

每當看到像是biz + Dev + Ops + … 這樣一系列組合時，我都會思考這些組合是為了宣傳，還是真的可行。如果可行，像是bizDevOps是否只是在擴大DevOps的核心概念？畢竟，DevOps中已經涉及到了業務（biz）方面的討論。

開始到崩壞

實際上，成功和失敗都是相對的概念，其界定取決於我們設定的目標和期望。如果我們沒有確定的成功標準，就難以談論失敗。然而，崩壞概念則指的是在一段成長過程中，由於某些因素，我們開始經歷逆轉，甚至回到原點。這種情況可以用股市行情圖來說明。當談到崩壞概念時，這可能意味著一家公司或一個項目正在經歷相對成功的時期，但由於某些不利因素，開始出現倒退的趨勢，甚至處於危機中。這種情況可能使我們回到了之前的起點，失去了之前所獲得的進展。

在我看來，最容易出現的問題之一是嚴重的”穀倉效應”以及過度”執著”於控制的Function Team。在DevOps的核心理念中，協助團隊人員將功能交付給客戶，或協助實現其他業務目標。然而，若Function Team無法認識到實現業務目標的重要性（大多數Function Team並未涉足業務層面，無法理解重要性），他們可能為了自身目標而忽視其他因素。人們通常會追求達成自己設定的目標，以獲得更好的薪酬。當Function Team忽略其他因素時，只認為自己目標才是正確的，這可能導致協同合作的困難。

DevOps有人曾說是建立統一的多技能團隊，這將有助於更好地溝通、協作和整合，這是實踐DevOps在任何開發和交付環境中的關鍵。建立多技能團隊可以帶來巨大效益，因為團隊成員可以互相支持，並使團隊運作更快、更有效，最終提升客戶滿意度。然而，這需要突破傳統組織的框架，因為在某些組織中，權力和Function Team的職責緊密相連。換句話說，如果你不在特定的團隊內，即使你擁有出色的技能和豐富的經驗，也可能無法發揮作用，因為你沒有相應的權力，必須依賴（受控於）其他人。甚至，還會被人挖坑。這強調了Top-Down（自上而下）的重要性，缺乏Top-Down支援時，這些問題可能會不斷浮現。

實現這種結構和文化的轉變是一個漫長的過程，但打破這種結構和文化則相對容易。只要Function Team的權力超越其他團隊，且雙方未能站在相同的知識水平上應對商業需求，這可能是組織崩壞的徵兆。

總之，穀倉效應和Function Team的執著可能威脅到DevOps實踐的成功。建立跨功能的多技能團隊，以及強調組織的Top-Down支援，都是克服這些障礙的關鍵。所以，集中化的權責劃分勢必將要轉型，這也將衝擊到原有組織內的工作型態

感想

當前，DevOps在台灣已經逐漸深入到許多企業，儘管大部分仍處於工具導入階段。然而，企業的轉型並不簡單，特別是對於傳統製造業或硬體產業，轉變變得更加艱困。關鍵挑戰不在技術方面，而是在人的因素上。人的行為是難以完全控制的，這也是為何製造業傾向於降低人員介入，追求自動化或無人工廠。這除了降低人力成本外，也有利於提升生產品質，因為人為因素的干擾將會減少。甚至，當上層主管的異動，也會讓原本成果，瞬間崩壞

值得注意的是，這一觀點與製造業中的自動化趨勢相呼應。降低人員介入能減少人力成本，同時增加產品品質和一致性。這也是為什麼不少企業在追求自動化和無人工廠的原因之一。這些措施的目的是減少無法控制的人為因素，以提升生產效率和產品品質。

另外，如何察覺可能的轉型問題，也是一個重要的議題。目前先寫到這，有空再寫寫，如何嗅到崩壞的味道....