從 Infra 角度看一個工具,要問哪些問題

學一個工具、和把它放進 Production,是兩種完全不同的問題。學的時候你問「這個 API 怎麼用、這個概念是什麼」;上 Production 時你問的是另一組問題——它會怎麼掛?怎麼長大?半夜壞了怎麼救?要幾台、多少記憶體?資料放哪、掉了能不能救回來? 這個系列,就是用同一套框架,把每個工具當成「一塊 infra」來體檢。這第一篇,先把框架立起來。

Infra 體檢表:看任何工具都問這 8 題

不管面對 Kafka、Spark 還是一個你沒看過的新東西,把它當 infra 看時,要問的其實是同一組問題:

這八題是這個系列的骨架,之後看每個工具都會一路對照。而其中第②題「狀態」是樞紐——它幾乎決定了其他七題的答案:一個工具有沒有狀態、狀態放哪,直接牽動它怎麼擴、怎麼做 HA、在 k8s 上怎麼跑、半夜掛了好不好救。所以看任何 infra,我第一個問的永遠是這題

一條軸決定一切:stateful ↔ stateless

為什麼「狀態」是樞紐?因為一個工具有狀態(stateful)還是無狀態(stateless),幾乎決定了它在 Production 的一切。這條軸是整個系列最重要的一把尺:

Stateful 的資料就長在它身上(Kafka 的 log、Redis 的記憶體、RabbitMQ 的 queue),所以難擴(要搬資料)、難搬(綁著磁碟/記憶體)、掛了可能丟——在 k8s 上得用 StatefulSet + PV 給它穩定的身分與儲存。Stateless 身上沒有不可取代的東西,只是幹活,所以好擴、可拋——跑 Deployment + autoscale 就好。而多數工具其實是混血:Airflow 的 worker 無狀態、但它的 metadata DB 有狀態且是命門——認出「哪一塊有狀態」,是看懂一個工具 infra 的第一步

這條軸的威力在於,它把一個看似複雜的問題收斂成一個問句:面對任何工具,先問「它哪一部分有狀態?」——答案幾乎自動推出後面所有 infra 決策。無狀態的部分,加機器、掛了就換,輕鬆;有狀態的部分,才是你要小心翼翼對待的地方——它的複製、備份、故障轉移、擴縮時的資料搬遷,才是真正的難題。也因此,這系列後面會先寫有狀態的重量級(Kafka、Redis、RabbitMQ),再寫無狀態的運算與連接器(Spark、Airflow worker、Kafka Connect)——因為狀態,才是 infra 的難度所在。

反思

Infra 視角,是從「怎麼用」升級到「怎麼養」

我職涯的一個轉捩點,是意識到「會用一個工具」和「能把它養在 Production」是兩種能力。前者靠讀文件、跑 tutorial 就會;後者要你回答一堆文件不太教的問題——它半夜三點會怎麼壞、擴容時會不會掉資料、監控該盯什麼才能提早發現。剛工作時我以為「學會用」就夠了,直到第一次被 on-call 叫醒、對著一個「明明教學都跑得好好的」系統束手無策,才懂那之間差了一整個維度。這個系列就是想補上那個維度:不是教你怎麼用這些工具,而是教你怎麼把它們當 infra 養活、養穩、養大。

「哪裡有狀態」是我看任何系統的第一個問題

做了幾年後端和資料,我越來越相信一句話:狀態是複雜度的根源。 無狀態的東西幾乎不會給你惹麻煩——它可以隨便複製、隨便重啟、隨便丟掉換一個;所有真正的難題,幾乎都圍繞著「狀態」打轉:資料一致性、故障轉移、擴縮容時怎麼搬、備份怎麼還原。所以我現在看任何系統(不只這些工具),第一個問的永遠是「狀態在哪、誰擁有它、掉了會怎樣」。把有狀態的那一小塊圈出來、小心對待,其餘的無狀態部分反而好辦。這個「先找狀態」的直覺,是我覺得最能遷移、最值錢的 infra 素養。

一套可遷移的框架,勝過十個工具的操作手冊

這系列刻意用「同一套體檢表」去看每個工具,不是偷懶,而是我真心相信框架比細節更值得學。工具會過時、指令會忘記,但「看一個 infra 該問哪 8 個問題」這套框架,是能跟著你一輩子的。有了它,哪天遇到一個沒人教過的新工具,你也能自己上手——照著體檢表問一遍拓撲、狀態、擴展、故障,答案就浮出來了。這也呼應了我在空降新公司那篇的心得:面對陌生的系統,你需要的不是背下所有細節,而是一套能套上去、逼出正確問題的框架。可遷移的思考方式,才是對抗「工具一直換」的唯一解。