跟什麼相比？一個零售客戶、一劑 Kubernetes 處方，與一套 20 年的老系統
· 4 分鐘閱讀
一個零售客戶來找我的時候，答案早就定好了。
疫情重創了他們的生意，競爭者環伺，而前一家廠商已經給了一劑充滿自信的處方：把一切容器化、 上 Kubernetes，維運的痛就會消失。他們要的不是一場關於架構的討論，而是找個人來把這個計畫執行掉。
麻煩的是計畫底下那層東西。他們想用 Kubernetes 包起來的系統，已經有二十年歷史， 公司裡沒有一個人完全清楚它是怎麼運作的——用當時的原話說，「沒人知道裡面裝了什麼」。 你沒辦法靠容器化，來擺脫「根本不知道自己手上有什麼」這件事。
別急著替弱點做裝潢
面對一個很篤定的客戶，直覺反應不外乎兩種：跟他爭，或者照著做。跟他爭 Kubernetes， 只會讓全場築起防衛心；照著做，則是在一個沒人看得見的地基上，蓋一棟嶄新漂亮的房子—— 我把這叫做「替弱點做裝潢」。它看起來像進度，實際上只是把風險悄悄挪到你日後才會踩到的地方， 而且往往是在最不該出事的時間點。
所以我沒有去辯解法，而是反過來，往問題本身走回去。
問題背後的那個問題
我所知道最好用的一個問題，小得有點狡猾：跟什麼相比？
Kubernetes 會解決維運的痛——跟什麼相比？這些痛，今天到底讓你付出多少代價？ 上百萬名活躍會員、一檔動輒跑好幾個小時的促銷、前置期長達半年的硬體採購—— 一旦把這些數字攤在桌上，「就上 Kubernetes 吧」就不再是答案，而變回眾多選項裡的一個， 而且每個選項都有它的標價。
這個重新框問題的動作，不需要你在技術上站得住腳。它只要求你把客戶正在感受到的症狀， 和他們還沒能講清楚的病因，分開來看。
會議室裡的沉默
為了挖出病因，我找了決策者和各部門主管，開了一場 impact mapping。我立了一個目標—— 營收月月成長——然後問了一個理應很好回答的問題：這個目標，誰會支持？
全場安靜了下來。
不是他們不在乎，而是他們太多年來習慣了接指令，而不是為結果負責。那份沉默告訴我的， 比任何一張架構圖都多。問題從頭到尾都不真的是資料庫、也不是部署方式， 而是從來沒有人，把技術系統和它本該撐起的那門生意，接在一起。
接著一場為期兩天的 Event Storming——四、五十個人擠在一起，很多人是頭一次同桌—— 逼出了真正該下手的地方：商家管理。不是因為它最新潮、或最有趣， 而是因為那裡正好是領域、金流和痛點三者對齊的交會點。
我發現，我是個生意人
工作坊進行到一半，我冒出一個小小的、有點讓人措手不及的念頭： 原來我是個生意人，不是個技術人。 把行銷、庫存和物流串起來，不是架構工作的岔路， 它本身就是架構工作。
這正是我說「架構是一項社會技術活動」的意思。難的從來不是在 Kubernetes 和別的方案之間挑一個， 而是人與人之間的那片空間——他們用的語言、他們背負的誘因、誰為什麼負責—— 以及他們親手打造出來的系統。錯過了那片空間，就算給你全世界最好的技術， 它終究會落在一塊沒人看得懂的地基上。
帶走一件事就好
如果客戶上門時，答案已經攥在手裡，那不是一個該繞開的障礙，而是你能拿到最重要的一個訊號。 慢下來，慢到剛好夠你問一句跟什麼相比？，把對的人請進同一個房間，然後讓領域自己告訴你，該從哪裡開始。
先把問題搞懂，幾乎永遠是解決它最快的那條路。
本文源自一場在 Virtual DDD 上的對談， 與談者為 Andrea Magnorsky、Andrew Harmel-Law 與 Kenny Baas-Schwegler。