SRE 空降一間『什麼都自建』的公司,前 90 天怎麼站穩

換工作最刺激的一種,是加入一間幾乎什麼都自建的公司:沒有現成的雲服務、連 Stack Overflow 都幫不上忙——因為這裡的基礎設施、部署工具,全世界只有這一家在用。你過去累積的「某某工具怎麼設定」大半失效,知識不在網路上,而是藏在程式碼、少數幾個人的腦子、以及過去的事故紀錄裡。

這種環境怎麼快速上手?我用三個角度去啃一套陌生系統——由外而內跟著一個請求走、由上而下用可觀測性看它活著的樣子、由零重建把所有隱藏依賴逼出來——最後用一套節奏收尾。核心心法濃縮成一句話:別急著證明自己,先把系統的地圖畫進腦子。

(順帶一提:自建公司通常不會連監控也從零造——很多會直接用開源的 Grafana LGTM 全家桶;就算他們真的自己造,LGTM 的心智模型也能套上去,所以下面我直接用它當範例。)

上手第一招:抓一個真實請求,跟著它走完全程

如果只能做一件事,就做這個。Wiki 上的架構圖是理想、而且通常過期的;真正逼你理解系統的,是挑一個真實的使用者請求,親手追蹤它從進來到回應,中間經過的每一跳:

這招的威力在於它同時幫你補齊三件事:系統長相(元件與拓撲)、可觀測性(監控與 log 在哪)、以及故障想像(每一跳壞掉的後果)。而且它是主動的——你不是被動聽人簡報,而是自己動手挖,挖過的東西才真的長在腦子裡。

看懂系統「活著的樣子」:Grafana LGTM 全家桶

「跟著請求走」時,那句「怎麼看它健康?」要有工具回答。現代可觀測性的答案是三種訊號(metrics、logs、traces),而 Grafana 家的 LGTM 全家桶剛好一種訊號配一個後端,再全部匯進 Grafana 這塊「玻璃」:

對剛上手的人,LGTM 的用法有個固定套路,對應到四個黃金訊號:先看 metrics 抓到「哪裡不對勁」(延遲飆高、錯誤率上升),再翻對應時間的 logs 看「細節是什麼」,最後用 traces 定位「到底是哪一跳、哪個服務拖慢了整條鏈」。metrics 告訴你有事、logs 告訴你什麼事、traces 告訴你在哪——三者缺一,你就會在半夜的事故裡瞎猜。所以我進新公司第一件想搞清楚的基礎設施,往往就是「我們的可觀測性長什麼樣、我要去哪一塊玻璃上看」。

上手的終極測試:你能不能把整個環境重建起來

前面兩招讓你「看懂」系統,但有一個更狠、也更誠實的測試能逼你「真懂」:試著從零把整個環境在本機或 sandbox 跑起來。讀文件你會不知不覺跳過看不懂的段落;但重建不會騙你——缺任何一層依賴,它就是起不來,逼著你把每一個隱藏的相依關係都挖出來:

實務上不必真的把 production 級的規模重建出來,重點是跑通那條依賴鏈:哪些服務要先起、誰依賴誰、設定從哪來、資料怎麼種。很多公司有 docker-compose 或一鍵起本機環境的腳本——如果有,先照著跑一遍、再故意弄壞一個環節看它怎麼壞;如果沒有,那幫他們把這個腳本補出來,本身就是你上手期最有價值的貢獻之一(下一節會提到)。

前 90 天的節奏:先理解,後動手

新人最容易犯的錯,是第一週就急著「做點什麼證明自己」——改設定、提重構、嫌東嫌西。在一間自建系統的公司,這幾乎注定踩雷,因為每個看似奇怪的設計背後,常有你還沒看到的血淚原因。我給自己排的節奏是這樣:

其中見習值班 + 讀過去的 postmortem,是我認為投報率最高的一段。過去的 postmortem 等於一份「這個系統真的會怎麼壞、在哪壞」的濃縮教材——比任何架構簡報都值錢,因為它講的是真實發生過的血案,而不是設計者的一廂情願。而在 Grafana 上看「正常長相」則是另一半:你得先知道系統健康時長什麼樣,出事時才分得出異常。至於在 sandbox 試著重建環境,我把它放在這一段而不是更後面,是因為它最好在你「還敢問笨問題」的蜜月期做——重建過程你一定會卡,而卡住正是逼你去把依賴鏈問清楚、讀懂的最好藉口。

全自建公司的幾個特殊玩法

• 知識藏在三個地方:程式碼(最終真相)、過去的 postmortem(哪裡會爆)、那位「什麼都知道」的資深(問他,但別只依賴他——人會離職)。網路上查不到,就往這三處挖。
• 早點建一份黑話表:自建工具都有自己的內部命名、縮寫、術語。第一週就開始記,兩週後你會感謝自己。
• 把「code 都在手上」當紅利:用 SaaS 你只能對著黑箱猜,但自建系統的每一行都在你的 repo 裡——你能真的讀到底、也真的改得動。這是自建環境唯一比別人爽的地方,好好利用。
• 先問「為什麼自己造」再說換掉:別急著喊「這個用開源的 X 換掉就好」。他們當初沒用現成的,通常有你還沒踩到的理由——先搞懂,再評估。

反思

新人最大的資產是「不懂」,別急著浪費它

剛進公司的前幾週,你擁有一個再也拿不回來的東西:一雙「什麼都不覺得理所當然」的眼睛。你上手時每一個卡住的地方、每一個「這什麼?怎麼沒人寫」的瞬間,都精準地標記出文件的缺口——而這正是你第一個月最好的貢獻清單。我每次到新環境都會開一份「我卡住的地方」筆記,兩個月後它就變成我補的第一批 runbook。因為再過陣子你就『習慣』了,那些坑會變成你視而不見的日常,這個視角就永遠消失了。 不懂不是弱點,是有保鮮期的資產。

先理解再動手,不是慢,是對系統複雜度的尊重

我年輕時很想用「第一週就修好一個東西」來證明自己值得被錄取,結果常常是改了一個我以為多餘的設計,才發現它在擋一個我沒看到的邊界狀況。自建系統尤其如此——那些看起來很蠢的特例,很多是某次半夜事故留下的疤。所以我現在的紀律是:看到怪東西,先問「為什麼會變成這樣」,而不是「這也太爛了吧」。 這跟 排障的精神一樣——相信證據、別憑直覺猜;也跟 blameless 的底層假設一致:眼前這個設計不是因為前人蠢,是因為他們面對過你還沒面對的處境。理解在前,批判在後。

能不能親手重建,是「懂不懂」的照妖鏡

我對一套系統敢不敢說「我懂了」,標準只有一個:我能不能自己把它從零跑起來。 讀完文件、聽完簡報,你會有種「差不多懂了」的錯覺——但那個錯覺會在你真的動手重建時,一層一層被戳破:欸這個服務原來還依賴那個沒人提過的內部 API?這個環境變數哪來的?這份 secret 誰在管?每一個讓你卡住的地方,都是你剛才『以為懂了』其實沒懂的證據。 我很喜歡這個測試,因為它逼出的東西,剛好就是 SRE 最該掌握的:完整的依賴鏈、啟動順序、設定的來源——這些正是將來災難復原(DR)時,你得在半夜、在壓力下,徒手重建的同一批東西。上手期把環境重建一遍,等於預先演練了一次最壞情況;而把重建腳本(docker-compose、一鍵起環境)補好留給後人,更是把一次性的痛,變成整個團隊的資產。

讀 postmortem,是我看過最高效的入職教材

如果讓我只推薦一件事給空降的 SRE,那就是把過去半年到一年的 postmortem 全部讀一遍。一份好的事故報告,濃縮了系統最脆弱的關節、最容易被誤解的地方、以及真實壓力下人會怎麼反應——這些東西,新人訓練簡報永遠不會告訴你,因為它們太真實、太不光彩。我讀 postmortem 的一週,對系統的理解勝過前面聽簡報的一個月。這也讓我更確信 監控和 postmortem 文化的價值:一個願意誠實記錄自己怎麼壞掉的組織,等於幫每一個未來的新人,預先寫好了最珍貴的那本地圖。