[淺談]DevOps 開始到崩壞?(續)

很朋友都說自己都還沒走在這路上根本就沒開始啊，根本沒感覺到會崩壞，只是感覺前方阻礙有如群山一般很難跨越。確實如此，DevOps這個文化到2024年，已經執行快8年，即使跨過萬重山，但每年又會多出更多的山來阻礙前進的道路。從工程角度來看，不外乎外面的世界變化越來越快，要面對挑戰更多，從人的角度來看之前要打破是Developer和Operation兩個角色(部門)的隔閡或是工作模式，現在變成要打破Business、Network或是Security團隊。

此外，早期多數人提到DevOps團隊在環境中除了我們要克服組織差異外，如果你的團隊外的協同合作夥伴又有跨國的模式，這樣不僅僅是組織差異，還有更多來自文化差異，這將導致跨團隊合作、一致性和標準化等挑戰，畢竟你的一致性和標準化對它們來說可能是例外或是特殊。尤其，在領域不同團隊上可能還會發生你的Concept不等於我的Concept，這時候怎麼辦，往往就只能比誰的拳頭大了(誰在乎你的軟體交付的效率和品質)，只要在我自己負責的領域不出事就好，這種壞味道其實是很難被消滅，為什麼一開始會嗅不到?我只能說擴張領域還不夠廣，當擴張的協同合作越廣，這種味道就會越來越多。

每次談到DevOps，就會被問到「Agile」& 「DevOps」是要選哪一個?要哪個先開始?我們先來回顧一下大家認知的「DevOps」好處

• DevOps 的定義和好處：DevOps 是一種軟體交付和協同合作的模式或是文化，它強調團隊合作、自動化和持續反饋，以實現更快、更可靠、更安全的軟體交付。
• CI/CD 的實踐和最佳做法：CI/CD 是 DevOps 的實踐工程之一，它將軟體從開發到部署的每個步驟自動化和流暢化。CI/CD 的最佳做法包括版本控制、自動化建置、全面的自動化測試、模擬生產環境、快速和安全的回滾和持續監控。
• DevOps 中的測試策略：DevOps 中的測試是一種實踐，它整合到軟體開發和部署的每個階段。DevOps 中的持續測試確保每次對代碼庫的更改都被自動測試，減少錯誤並提高質量。這種方法有助於保持穩定的交付節奏，同時保護軟體的可靠性和穩定性。這些策略包括自動化測試、並行測試執行、左移測試、將測試納入建置過程、維護測試資料管理和定期檢查和更新測試套件。
• DevOps 的技術：有一些技術可以幫助 DevOps 團隊克服的挑戰，例如混沌工程、應用程式相依性繪製、IaC和無程式碼測試自動化等，這些技術可以節省時間、提高穩定性、增強可見性和簡化流程。
• DevOps 的未來：隨著技術的快速發展， 團隊需要不斷地更新的工具和方法，以優化流程。

回到「Agile」& 「DevOps」怎樣選擇?我認為「DevOps」中沒有「Agile」的核心理念或是文化流程，是很難支撐「DevOps」走下去。從我來看，「DevOps」最終極目的在於如何讓商業需求如何能快速交付到用戶或是提高用戶對產品(服務)的滿意度(系統出問題時候，用戶需要等待超過一天以上才能使用，這樣滿意度是不會提高)，「變」是現今環境唯一不變的現象，而「Agile」(Scrum)卻是可以讓我們去面對這樣的現象，讓我們做出的服務與現實差異是縮短甚至是符合需求的。從DevOps上述的一些好處中，可以發現一件事情，就是「變」。無論是技術或是流程，都會隨著時間和市場不斷變化，團隊無法面對這樣的環境是無法持續產出。有了「Agile」不是讓原本原本需要三天的工作時程，可以縮短到一天就可以完成，而是面對各種迎來的變化與挑戰，都可以消化或是有一種合作或協同模式應付這樣情境。所以，如果只是單純仰賴「DevOps」的技術，人的心態沒有轉型，到最後依舊很容易壓垮「DevOps」的火苗。因此，「Agile」的導入是提升團隊能面對「變」有了應變能力;「DevOps」的導入是提升使用者(客戶)對團隊服務(能力)的滿意度(信賴)。這兩者是相輔相成。

最初期，Developer和Operater兩群人面對都還是屬於Business，當然後期又加入的Biz，但是整體面向都還是跟市場或是需求有關。縱使大家可能都不對盤，但還是可以有一絲絲的共通語言。不過，後續又加入Secutrity，這又是一種天崩地裂的情況。這並非說Secutrity不需要去理會或是重要，反而Secutrity放入DevOps是非常好的一件事情。我們先來說說所謂的DevSevOps的理念:

• DevOps安全：一種將安全實踐整合到DevOps流程中的理念，也稱為DevSecOps。DevOps安全涉及創建一種「安全即代碼」的文化，並在發佈工程師和安全團隊之間進行持續、靈活的協作。
• DevOps安全的目標：打破孤島，促進團隊之間的開放協作。讓每個人都對安全負責，最終目的是提高代碼發佈的質量和速度。DevOps安全的採用需要組織文化的轉變。它要求將安全整合到開發和運營的每個環節中。
• DevOps安全的策略：這些安全威脅令人擔憂，但有一些有效的策略和技術可以用來減輕它們。例如，使用電子郵件安全工具和安全意識培訓來對抗釣魚攻擊，使用輸入驗證和清理來防止代碼注入，使用HTTPS和SSL/TLS加密來保護數據傳輸，定期掃描容器以發現漏洞，實施速率限制和網路過濾來緩解DDoS攻擊。
• DevSecOps 的意義和最佳做法：DevSecOps 是將安全性整合到 DevOps 生命週期中的方法，它要求在開發過程的早期和頻繁地嵌入安全工具和實踐。DevSecOps 的最佳做法包括自動化安全流程、使用基礎設施即代碼、保持合規性、進行威脅建模和風險評估和持續監測和回應。

主要是讓資安意識放入到團隊每個人心中，讓每個人從端到端都因為有資安意識，所以從開發到佈署或是維運都可以關心到資安議題。

這幾年因為外部攻擊增加，每個企業都開始有了資安團隊(或是Infra團隊轉型)，通常遇到的案例，就是這些成員的Concept與軟體開發流程的Concept差異更大。通常在大企業中這些成員與business距離就更遙遠，且本身Domain的技術變化，與軟體或是應用系統來比，相對是緩慢且變異低。當這兩者結合衝擊，是非常可怕的。感覺是那種新舊思維的強大衝撞，產生出的火花。兩邊誰對誰錯?我認為都有各自認為對的理由，畢竟兩邊專業都不同。既然都有對錯，為什麼還這麼難合作呢?主要還是在於人的思維是否改變，我遇到大多數的資安團隊(或是Infra團隊轉型)，過於保守在於自己領域或是不願面對IT領域的新知識吸收或是學習。反而用傳統或是過往領域知識面對新的技術發展，有些還是排斥。排斥往往主要原因是不想要面對變化，畢竟過多變化，在工作或是管理模式就要改變，這反而是他們不願意面對。

因此，當DevOps邁入Secutrity要素，如果大家無法對齊在一條線去面對這件事情，將會讓原本成熟或是高效率的DevOps瞬間被瓦解(尤其是資安團隊又能拿著雞毛當令箭時候)，那到底要齊那一條線呢?

企業需要保持敏捷並利用技術推動業務成長，同時保持安全性。每個人任務就是在保持敏捷性前提下，同時確保業務能夠專注於最擅長的事情，而不是被安全策略而受到干擾，降低敏捷和彈性

因此，當資安不了解軟體開發就無法提供有效建議，DevOps團隊不懂資安也無法將資安要素納入開發流程中。作為DevOps專業人員，必須意識到可能危害系統、應用和資料的潛在威脅，例如: 釣魚攻擊、代碼注入、中間人攻擊、容器漏洞和分佈式拒絕服務攻擊等

另外，企業組織推動DevOps時候，還遇到資源權力的問題，甚麼叫做資源權力，我們常常講到DevOps時候，會希望DevOps團隊能定義好雲端使用策略或是彈性雲端資源協助業務成長，例如:

• 無伺服器運算：一種雲端運算的執行模式，由雲端供應商動態管理機器資源的分配。開發者不需要考慮伺服器，只需專注於程式碼。函數是程式碼的單位，可以由各種事件觸發。
• 對 DevOps 團隊的影響：無伺服器運算減少了操作上的負擔，但也需要改變思維和方法。DevOps 團隊必須適應更細粒度、事件驅動的架構，並深入了解雲端環境和服務。
• 無伺服器運算的挑戰：無伺服器運算在安全性、監控、成本管理等方面帶來了新的挑戰。DevOps 團隊需要開發新的策略並採用專門的工具來解決這些問題。
• 雲服務在 DevOps 中的作用和最佳做法：雲服務提供了按需的資源，可以快速配置和擴展，以滿足任何開發項目的需求。雲服務與 DevOps 的整合提供了可擴展、靈活和高效的資源，與現代軟體開發的快速和迭代的特性相符。雲服務在 DevOps 中的最佳做法包括堅固的基礎設施、配置管理、安全和合規性、成本管理和優化、持續監測和改進、災難恢復和高可用性和性能調整

以上不外乎可以看到雲服務降低了基礎建設的門檻，且面相在開發者居多，這時候，企業早期管理基礎建設的團隊來說，勢必讓這些資源脫離他們掌控了，簡單說可能有某些權力消失，導致不安或是覺得不被它們控制。導致，想要傳統方式管理這些雲資源，進而喪失DevOps團隊的彈性與自主性。當然，在交付上反而使用雲資源是讓進度更為緩慢，維運產生更多不確定因素與複雜性

世界在變，前幾年推廣(實作)DevOps在文化與組織協同合作已經不容易，如今又要擴展更多領域(部門)，複雜性與難度就更難。對於還沒有開始的人，可能門檻更高，對於開始的人可能遇到不是進步而是被打退回原狀。後續，DevOps除了資安，我相信又有更多的議題會被納入DevOps領域

• AI的發展與挑戰：開放式AI和ChatGPT等生成式AI將在2024年面臨高期待和低實現的困境。
• 開發者體驗的重視：為了提高開發者的效率和滿意度，技術組織將投資更多的工具和平台來優化開發流程和環境。
• 成本壓力的增加：受到疫情後的財務緊縮政策影響，組織將審視所有的支出來源，並尋求減少雲端、SaaS和人力等成本的方案。
• 數據驅動的責任：組織將不僅要測量一些指標，還要利用數據來證明的價值。意味著要提高預測性，並在開發的每個階段能有所識別和處理風險。
• 安全性的強化：在一些重大的攻擊事件暴露了軟體的漏洞後，組織將加強安全性的考量，並將其融入產品規劃、開發和運營的全過程，同時需要更多的資源來監測和確保合規性。

DevOps在未來趨勢和挑戰，只會更多不會更少，這也就是我前面提到如果本身沒有敏捷的心態與概念，將無法面對這些挑戰。

• 軟體交付過程中變得更加根深蒂固，人工智慧和機器學習的進步可能引入前所未有的自動化和預測分析的能量。
• 隨著技術的演進，將 DevOps 實踐整合到當前的商業模式中將是至關重要的。
• 對於許多組織來說，尋求專業的 DevOps 諮詢，以應對現代軟體交付的複雜性，並將這些實踐定制到他們獨特的挑戰和目標。
• 隨著 DevOps 的演進，它將繼續為更快、更可靠、更安全的軟體交付鋪平道路，以跟上不斷變化的數位化的需求。

最後，用下面這張圖來詮釋現在大家提到的DevOps、SRE和平台工程的關係與差異。

DevOps、SRE和平臺工程都是相關聯，但它們的重點和責任各有不同：

• DevOps 的目標是提高軟體交付的速度和可靠性。
• SRE 專注於確保軟體系統的可靠性和效能。
• 平臺工程重點在於設計和實現底層軟體平臺。

這三者都是可以支撐DevOps的工程技術