因應全面上雲後的開發挑戰，第一資本平臺工程五次大改造

美國財金百大之一的第一資本在2020年，關掉最後一個地端資料中心，成了一家純雲端金融公司，2024年，兩千套部署在公雲上的應用，超過三分之一改用無伺服器架構。為了支援上萬名技術團隊的龐大開發需求，他們早在2018年，就開始打造一套共用的內部開發者平臺。

成立於1994年的第一資本，全美現在擁有1億多名顧客、5萬多名員工，是美國第三大發卡銀行。他們從不認為自己是一家金融公司，而自詡為一家從事金融業務的科技公司。

從2013年就導入敏捷開發，2014年推動IT現代化，改用RESTful API和微服務架構來打造金融系統，開始整併8座資料中心，2015年更實行開源優先策略。2016年時，第一資本啟動了上雲之旅，發下豪語，要成為全美第一家100%上雲的金融業者。第一資本所用的地端資料中心，原本在2014年有8座，2016年整併到5座，接著開始積極上雲，2018年剩下3座，2020年關閉了最後1座資料中心，成為一家全雲端企業。

全面上雲不只更有韌性，也讓第一資本的交易錯誤量減少了五成，而災難復原時間則加快了七成，還加速了他們創新的速度，建置開發環境的平均時間，從過去地端資料中心時期的3個月，縮短到只需要幾分鐘，開發團隊可以運用的先進機器學習工具和熱門AI服務也比過去更多了。

第一資本將原本只有4千多人的技術團隊，也在上雲過程中，擴編到了1萬1千人的規模，85%是軟體工程師，其他還有產品經理、設計師、資料科學家等角色，全都採取敏捷開發和DevOps流程。

為了支援日後龐大技術團隊的敏捷開發需求，早在2018年，第一資本展開了平臺工程計畫，開始打造了第一版的開發者平臺Dragon，來支援新一代雲原生應用的各種開發需求。

第一資本平臺工程部門技術產品負責人Jake Walden和傑出工程師Bradley Whitfield在2025年KubeCon大會上，分享了這個萬人開發者共用的Dragon開發者平臺的五次大改版歷程。

第一代平臺：以最小可行性版本盡快上線

2017年，第一資本的目標是盡快提供一個容器化的微服務開發平臺，方便工程師利用公雲業者提供的種種服務，快速開發自己的微服務。第一版的Dragon平臺是一個最小可行性版本（MVP）的開發者平臺，先部署在AWS的ECS和EC2上，也方便工程師運用公雲業者的各種服務。

一開始，平臺工程部門還不熟悉各個技術團隊需要什麼樣的開發工具和流程，為了避免工程師分心，一開始先開放部分可用的功能，而不是什麼都開放或允許工程師自己安裝新工具，另一方面，因為平臺團隊還不熟悉技術團隊的作業流程，第一版平臺先延後非必要的自動化機制的開發，也避免撰寫太詳細的文件。平臺團隊先花力氣把第一版平臺的功能做出來，趁機觀察和搜集不同技術團隊的慣用工具和作業習慣。

當時雲原生應用的開發實踐很少，例如12因子App開發原則還不普及，平臺團隊同時也要肩負教育技術團隊的任務，像是建立SRE的相關知識。

不過，第一版平臺的AP配置做法相對簡略，對一項業務服務的功能和網域，就配置獨立的應用程式負載平衡器，很快就遇到API連線速率的限制，公雲負載平衡器的規則數量限制等問題。

第二代平臺：從公雲轉移到自建K8s，擁抱SRE強化維運能力

第一版開發者平臺只是階段性的平臺，很快他們轉移到K8s環境，這就是第二代的Dragon開發者平臺。第一版平臺獲得技術團隊好評，越來越多技術團隊想要用，但是第一版平臺的不足，成了第二代平臺改版的外部壓力。

因為第一版平臺的自動化機制不多，導致許多維運和設定作業，需要平臺團隊手動處理，也因為文件不夠詳細，甚至很多功能沒有相關文件，平臺團隊花了大量時間解釋，也消耗了平臺團隊的工作時間。

不只如此，第一版的技術債也開始產生影響，例如針對每個功能和網域設定負載平衡的做法，越來越難維護而且成本昂貴，隨著服務越來越多，API存取效率也越來越差。

所以，第二版Dragon開發者平臺除了轉移底層架構之外，還要強化維運能力。一方面，平臺團隊將Dragon平臺從公雲轉移到自家的K8s，為了避免出錯，當部署一個新的微服務時，會同時部署到舊版ECS環境和新版K8s環境，確定可正常運作後，再移除ECS的版本。

另外，第二版平臺開始導入SRE實踐，例如SLI、SLO、SLA等，來提高開發者平臺的可用性，並且向所有開發團隊公開這些指標，讓他們知道不同功能或服務的可用狀態如何。

聚焦維運的第二版開發者平臺，透明度是獲得所有人信賴的關鍵，可以讓技術團隊更信賴這個開發者平臺提供的工具和可用服務。平臺團隊同時也開始依據K8s環境的特性，來優化流程和補充大量文件說明，並且用Go語言，建立了許多自動部署範本，來減少手動作業。

第一資本平臺團隊將Dragon平臺搬遷到自家K8s環境後，不用再受限業者提供的功能，更容易額外安裝自己想要的底層功能，也可以自己開發各種新的K8s元件等，例如他們自己新增了秘密管理，服務發現機制等。

隨著越來越多技術團隊和應用系統，改用Dragon平臺來開發，如何提高資源利用率成了新的壓力，許多過去是特例的用法，越來越多團隊使用，變成了常態。

第三代平臺：多租戶架構和共享責任管理

Dragon也展開了第三代版本的升級，主要是建立了多租戶架構，來提供更好的系統隔離和權限管理，提供更細緻的RBAC角色權限控管，來確保不同用戶間CI/CD流程的獨立性，不會互相干擾，或有人不小心部署了其他人的任務。

在多租戶架構的階段，不同團隊需要的技術支援請求，越來越多，因此，Dragon第三版也新增了一套自助式的支援服務。

在第三版Dragon平臺中，第一資本平臺團隊還建立了「共享責任管理」（shared responsibility model）制度和事故管理機制，來區分平臺團隊和技術團隊的責任分工介面。他們到了第三版本的階段，也開始和資安團隊、審計團隊、IAM團隊、內部雲端基礎架構團隊有更多合作。

這個共享責任管理制度，明定了平臺和使用者之間的關鍵權責和風險歸屬，主要針對PaaS和SaaS兩種平臺類型，明確界定出平臺方與租戶方各自的權責，包括了開發與測試、內部委外、部署與發布管理、基礎設施管理、可觀測性、彈性、網路安全、風險管理與合規性、變更和事件管理等面向的權責。

在Dragon平臺功能的開發上，仍採取較保守的做法，選擇性的增加新功能，而不是漫天發展各種新功能，尤其要避免偏離核心基礎功能太遠的需求。

第四代平臺：重新改寫，善用CRD加強維運自動化

經過三次改版，平臺團隊已經累積了夠多的K8s專業知識，對技術團隊需要的K8s控制流程，有更清楚的了解，也知道如何發展出一整套的流程自動化做法。因此，他們決定展開第四次的改版，這次是幾乎重寫的大改版，主要透過K8s的CRD客製化資源定義功能，打造出各種維運任務的自動化操作，從資源分配、命名空間建立、網路政策套用、角色權限綁定等。

第一資本平臺工程部門技術產品負責人Jake Walden用平臺金字塔架構，來形容第四代Dragon開發者平臺，和其他內部平臺的關係。最底層是雲端供應商管理的K8s服務，例如AWS的EKS，再上層是第一資本自建的K8s平臺，稱為Enterprise OneKube，以及相關合規調度工具（嚴格套用金融法遵要求），再上一層就是Dragon基礎平臺，這是一套共用的開發工作環境和工具，上面還有各部門自己的專屬平臺，例如各自的規則平臺，調度平臺，最上面就是工程團隊。

第一資本的平臺金字塔架構，Dragon開發者平臺是開發團隊與底層基礎架構的中介層，讓開發人員不用直接管理複雜的底層環境。(圖片來源：第一資本)

對工程團隊來說，下面一層一層就是他們可以使用的平臺工具，除了不同業務部門各自的工具平臺之外，Dragon開發者平臺提供了一個抽象層，讓工程團隊不用直接面對更底層的企業內部K8s和外部公雲的K8s服務。第一資本也開始導入Argo CD來管理更複雜、更進階的API應用方式。

第五代平臺：因應大規模K8s叢集管理

到了2025年下半年，採用Dragon平臺的工程團隊快速增加，在上面開發的專案也越來越多，所需要的K8s叢集數量，一年暴增了6倍之多。Dragon平臺成了工程團隊管理其他底層平臺最重要的平臺，可說是平臺上的平臺。Dragon平臺團隊也遇到了大規模叢集的管理挑戰，需要更多進階的自動化工具，也導入了服務網格（Service Mesh）架構，可以在不中斷服務的情況下，將單一微服務從A叢集搬遷到B叢集。

Dragon平臺第五次大改變重點，要因應大規模K8s叢集的管理。(圖片來源：第一資本)

未來發展：叢集管理架構再一次抽象化

下一步，Dragon平臺準備將應用程式的管理做法，套用到叢集管理上，將叢集管理架構進一步抽象化，拆分出一般管理平面、網路管理控制平面、應用系統層管理平臺等不同的抽象層，並改用軸幅架構（Hub and Spoke）來運作大量叢集，來減少單一應用發生事故的影響範圍，也能增加每一個抽象層的水平擴充能力。

第一資本平臺工程的下一步要將叢集管理架構進一步抽象化。(圖片來源：第一資本)