流暢交付（fast flow）是一種軟體交付風格:IT 持續交付一連串小型變更,並從使用者與生產環境快速取得回饋。當代企業必須具備高度敏捷性,既要快速回應市場變化,也要不斷實驗;而支撐這種敏捷的力量,正是軟體。因此,IT 必須拋棄低頻、大批次的釋出方式,改為高頻、小批次地交付變更。
軟體交付的回饋迴圈#
軟體開發的核心是一個回饋迴圈(feedback loop):
- 開發階段:推測使用者需要什麼功能,實作並做出大量設計決策,接著釋出到生產環境。
- 回饋階段:從使用者得到「功能是否真的解決問題」的訊號,從生產環境得到「設計決策是否正確」的訊號。
- 下一輪迭代:依據回饋繼續開發、釋出、再得到回饋。
回饋迴圈的速度,決定了組織學習與驗證技術決策的頻率。迴圈越快,越能即時辨認出哪些做法有效、哪些無效。
Figure 1.1: The feedback loop at the heart of software development
傳統交付的迴圈太慢#
許多組織的交付頻率與這項需求嚴重脫節:
- 應用程式現代化專案常需要一年以上才釋出第一個版本。
- 較成熟的組織約一個月釋出一次。
- 《State of DevOps 2024》指出,約 80% 受訪者的釋出頻率低於每天一次。
除少數對安全要求極高的領域外,典型企業應用一旦把回饋週期拉長到天或週,就已經太慢。
為何現代開發需要快速回饋#
- 市場是 VUCA 的:今日商業環境充滿波動性(volatile)、不確定性(uncertain)、複雜性(complex)、模糊性(ambiguous),用戶實際需要什麼難以一次猜對。微軟(Microsoft)的研究指出:只有 1/3 的功能改善了產品,1/3 沒有效果,1/3 反而讓產品變糟——這意味著「持續實驗」是必要手段。
- 技術環境也在快速演化:面對新且不熟悉的技術(例如第一次導入微服務架構),如果不持續釋出與驗證,就無法及時修正錯誤的設計決策,容易讓多個錯誤層層堆疊成「紙牌屋」。
流暢交付:持續變更與回饋#
實踐流暢交付的組織會以極高頻率交付變更,理想情況下每天多次。回饋以同樣的速度反向流動,組織因此持續學習用戶需求與技術現實,並能透過頻繁實驗找出可行解法。
用 DORA 指標量化流暢交付#
DORA(DevOps Research and Assessment)研究團隊在《Accelerate》(Nicole Forsgren、Jez Humble、Gene Kim,2018)中提出四項衡量交付效能的關鍵指標:
- 前置時間(Lead Time):從程式碼提交到於生產環境執行所花的時間。
- 部署頻率(Deployment Frequency):多久部署一次變更到生產環境。
- 變更失敗率(Change Failure Rate):有多少比例的變更在生產環境出狀況。
- 失敗復原時間(Failed Deployment Recovery Time):服務出錯後恢復需要多久。
依《State of DevOps 2024》,菁英(elite)組織每年的部署次數可達低效能組織的 182 倍。
Figure 1.2: The four clusters of software delivery performance (reproduced from the State of DevOps 2024)
快但不脆:可靠性反而提高#
「速度」與「品質」並非對立。
統計顯示,菁英組織的變更失敗率比低效能組織低 8 倍。把變更切小、頻繁釋出,可靠性會跟著上升,而不是下降。
流暢交付帶來更快樂的開發者#
- 部署因為頻繁而變得平淡無奇,半夜緊急修復的場景大幅減少。
- 工程師花更多時間在新功能,而非「救火」。
- 過勞(burnout)情況顯著降低。
對組織績效的正面影響#
《Accelerate》與 McKinsey 的「Developer Velocity」報告皆指出,高軟體交付效能與企業在獲利能力、市佔率、生產力上的成功有強烈相關。
流暢交付成功三角#
要達成流暢交付,單靠任何一項措施都不夠,需要三項要素同時到位,作者稱之為「流暢交付成功三角」(fast flow success triangle):
- 流程(Process):DevOps
- 組織(Organization):Team Topologies
- 架構(Architecture):能支援上述兩者的軟體架構(本書聚焦於此)
Figure 1.3: Fast flow requires a combination of three elements: DevOps, Team Topologies, and Architecture
流程:DevOps#
依《DevOps Handbook, 2nd Edition》(Gene Kim、Jez Humble、Patrick Debois、John Willis、Nicole Forsgren,2021),DevOps 不是某個職稱或團隊,而是整個工程組織必須採取的工作方式。它有三條基本原則,稱為 The Three Ways:
- 第一條(First Way):變更從開發快速流向生產。
- 第二條(Second Way):回饋從生產快速流回開發。
- 第三條(Third Way):持續實驗與學習的文化。
兩個與流暢交付直接相關的原則:
- 縮小批次(reduce batch sizes):工作項目越小,流經各步驟越快。開發者必須實踐持續交付(continuous delivery),理想情況每天多次提交、推送、自動測試與部署。
- 減少團隊之間的交接(reduce hand-offs):每次交接都會引入延遲與知識遺失,可透過自動化、平台、工具與 Team Topologies 來消除。
組織:Team Topologies#
依《Team Topologies》(Matthew Skelton、Manuel Pais,2019),組織應由小型(5–9 人)、長期穩定的團隊組成,以降低溝通成本、培養信任與心理安全感。Team Topologies 定義了四種團隊類型與三種互動模式:
團隊類型:
- Stream-aligned team(價值流團隊):擁有從需求到生產的完整端到端職責,是承擔絕大多數工作的主力。
- Platform team(平台團隊):提供工具、基礎設施、函式庫等平台,讓 stream-aligned team 工作更輕鬆。
- Enabling team(賦能團隊):協助 stream-aligned team 學習新能力、跨越障礙。
- Complicated subsystem team(複雜子系統團隊):處理需要深度數學或技術專業的模組。
互動模式:
- X-aaS(以服務形式消費):一個團隊直接消費另一團隊提供的 API 或工具,如同使用外部服務。
- Collaboration(協作):兩個團隊一起探索新事物。
- Facilitating(促進):一個團隊幫助另一個團隊改進工作方式。
Figure 1.4: The four types of Team Topologies teams and the three ways that they interact
大多時候,團隊間應以 X-aaS 互動,確保彼此能獨立工作;collaboration 與 facilitating 是短期、有目的的搭配,不是常態。
架構:enabling DevOps 與 Team Topologies#
第三項要素就是本書的主軸——能讓 DevOps 與 Team Topologies 真正運作的軟體架構。架構若耦合過緊或難以測試與部署,前兩項要素再好也走不快;反之,鬆耦合、高可測試性、高可部署性的架構,才能讓變更與回饋快速流動。下一節將正式探討「流暢交付的架構需求」。