metadataJson
articleBody 背景與問題 InfoQ 在 2026 年 9 月 24 日刊出 Ben Linders 的報導，整理 Marcy Paramonova 與 Stéphane Cusin 在 KubeCon & CloudNativeCon Europe 的演講「Building Cloud Native Culture in a Bank」。這場分享的重點不是某個雲端工具，而是一家銀行推動雲原生平台時，如何把文化問題當成工程問題處理。Paramonova 與 Cusin 的經驗指出，平台團隊與產品團隊彼此依賴，開發者與產品團隊依賴平台團隊，平台團隊也依賴應用團隊；要讓雙方一起前進，就必須有共同標準。若組織只把平台看成基礎設施，很容易忽略平台其實是一個協作系統，大量溝通、決策與回饋都在其中流動。
核心：平台是協作系統 Paramonova 強調，雲原生不只是技術轉變，也是文化轉變。平台不是一組機器或服務的集合，而是團隊之間協作的媒介。這個觀點會改變平台團隊的設計方式：平台團隊不能只被動等待支援單，也不能讓每個需求都必須經過人工介入。Cusin 指出，如果每個動作都要開支援單、等待平台工程師手動處理，組織會在無意間創造依賴文化，讓團隊習慣等待平台團隊，而不是學會獨立操作與解決問題。因此，他們從第一天就建立一個原則：平台能力不應依賴人工介入。團隊透過宣告式設定與自動化工作流程和平台互動，例如在 Git 中做一個簡單設定變更，再由 GitOps 流程自動套用。這裡的宣告式設定是指使用者描述想要的狀態，而不是逐步下指令；GitOps 則是以 Git 作為變更來源與紀錄，讓自動化流程把期望狀態帶進環境。好處是自助體驗、可追溯性與平台採用情況的可見性都能同時提升。
運作方式：Genius Bar、獎項與共同標準 在文化落地方面，平台團隊沒有只靠口號，而是設計固定節奏。他們開設開放支援時段，也就是所謂的 Genius Bar，每週兩次、每次兩小時。開發者可以帶著問題來，不論是平台用法、元件如何組合，或某個行為不符預期，都不需要先開支援單，也不必等待某個人有空。這種做法縮短回饋循環，也讓平台團隊很快聽到哪裡令人困惑、哪裡造成痛苦。除了支援，他們也舉辦使用者洞察會議，分享優先順序、已完成工作與可見成果，並且和使用者一起決定優先順序，而不是替使用者決定。他們也做展示，說明已交付內容、路線圖，以及平台在日常工作中實際怎麼用。另一個做法是建立 super user awards，也就是超級使用者獎，表揚積極貢獻平台改進的開發者。Paramonova 坦言，這些回饋有時很難聽、甚至有點痛，但正因如此，平台才能做得更好，團隊也對此保持感謝。
文化如何被結構化 Cusin 反覆強調一個原則：文化跟著結構走。你不能等待文化自己出現，也不能用命令讓文化誕生，必須設計系統，讓某些行為變成自然選擇。若團隊抱怨總是被打斷，不應先責怪其他團隊，而要反問自己：是否定義了讓人們找到你的結構？平台團隊內部的規劃會議、跨團隊的使用者洞察、公開展示與固定支援時段，都是這種結構。它們單獨看並不革命，但把這些節奏疊在一起，想要的文化就會從結構中長出來。這不是魔法，但也不是偶然。Cusin 也說，平台決策要盡量可見。平台能力透過版本化產物、可重複使用的部署模式和文件化介面交付，而不是靠團隊之間一對一的私下協議。這能帶來一致性與共同理解。每個平台功能還應該有生命週期，平台團隊要知道誰在用、怎麼用、是否仍有價值，才能在需要時安全退場不再使用的功能，並把團隊遷移到較新的平台能力，而不是讓複雜度不斷累積。
影響與限制 這種轉變的實務意義，在於平台成為強化行為的機制：自助優於支援單驅動，標準化優於客製化，透明優於部落知識，共同擁有優於依賴少數專家。當這些原則被嵌進平台本身，理想文化就會變成工作者最容易採用的方式。Paramonova 也指出，使用開放原始碼與開放標準時，技能更容易轉移，因為學習不是從零重新開始，而是建立在跨開放技術共享的基礎上。她認為工程思維最重要，重點不是今天會什麼，而是能否接納新技術、學習、執行與維運；工程師的本質是解決問題、對解決問題有熱情，並分享這份熱情。Cusin 最後以 Kubernetes 為例，指出 Kubernetes 改變的不只是平台，也改變組織建構軟體的方式。限制也在此：這些做法需要持續投入與真實決策，若只複製活動形式，卻沒有讓平台具備自助、可追溯、可見與生命週期治理，文化不會自動跟上。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。