重寫之前，我們瀕臨崩潰

我們是一個六人團隊。作為后端工程師，我們疲于奔命地應付著微服務、流水線、運維補丁以及讀起來像心理治療筆記的事故報告。

我們的技術棧對于一個快速發展的初創公司來說很典型：

? Node.js 微服務

? Redis 隊列

? AWS Lambdas

? 幾乎一切都用 MongoDB

我們并非能力不足，只是不夠快。服務功能是有的，但很脆弱。

有些早晨，我們會一起盯著 Datadog 儀表盤，看著隊列積壓的消息數超過一萬條，等待垃圾回收趕上進度。

我們每天都在“救火”。

然后，我們中最沉默寡言的 Kabir 說：

“我覺得我可以用 Rust 重寫這個圖像處理流水線?！?/p>

接下來發生的事情本應顯而易見

我們都聳聳肩。重構項目從來都活不下來。

但 Kabir 沒有尋求幫助。他沒有預訂設計會議，也沒有要求估算時間。他只是默默地開始了。

在我們給 API 的分頁功能打補丁時，他正在用 image-rs 庫對比測試我們的 Node 腳本。

我們甚至沒有注意到——直到他做了演示。

讓我們過時的數據

Kabir 在下一次迭代評審會上演示了新的 Rust 服務。我們笑了。我們鼓掌了。

我們當時沒有意識到，我們是在為自己被取代而鼓掌。

他展示的數據如下：

Kabir 不僅僅是提升了性能。
他降低了 AWS 賬單。
他消除了那些不穩定的依賴項。
他讓值班輪換變得幾乎無聊。

我們當時沒說，但我們都感覺到了：
這不僅是一個更好的服務，更體現了一個更優秀的工程師。

我們其他人迅速落后了

Kabir 成了負責性能的人。

當我們還在修復損壞的 Mongoose 模式、爭論 GraphQL 和 REST 時，他已經在撰寫關于零成本抽象（zero-cost abstractions）以及 epoll 與 kqueue 的 RFC（征求意見稿）了。

他并不傲慢。但他也沒有等我們。

我們開始問這樣的問題：

? “為什么這個處理程序在空負載時會崩潰（panic）？”

? “Pin<Box<T>> 到底是什么來著？”

? “我需要安裝 nightly 版本才能運行這個嗎？”

差距迅速擴大。

前一周，他還在用 Axum 框架構建我們的健康檢查。
下一周，他已經用原子計數器（atomic counters）和 parking_lot 庫做出了一個生產就緒的速率限制器。

我們停止評審他的 PR（Pull Request）了。我們跟不上了。

組織悄然轉變，然后劇烈變動

Kabir 不僅僅是在構建更快的服務。他正在改變所有權的歸屬。

產品經理（PM）開始把功能請求直接分配給他。
站點可靠性工程師（SRE）請他協助修改 Terraform 配置。
領導層開始在全員會議（all-hands）上展示他的儀表盤。
他成了“那個后端專家”——即使我們還有五個人在崗。

那天我們并沒有失業。

但我們不再是那個團隊了。

然后裁員來了

他們沒有稱之為裁員。他們從來不會這么說。

他們說公司要“重新聚焦”。說是在“優化交付層”。

我們一個接一個地收到了來自人力資源部（HR）的日歷邀請。

沒有績效改進計劃（PIP）。沒有警告。只有“感謝您這段時間的付出”。

他們留下了 Kabir。

他們當然會留下他。

他現在負責了一半的基礎設施。而且做得比我們整個團隊過去做的還要好。

重構并非邪惡——它是合乎邏輯的

需要澄清的是：Kabir 并沒有陷害我們。他沒有游說反對任何人。他也沒有要求組織縮減規模。

他只是讓自己變得不可或缺，無法被裁掉。

在一家衡量每次部署投資回報率（ROI）的初創公司里，你不會裁掉那個能以 10 倍速度交付、成本卻只有 1/5 的人。

我們被解雇不是因為我們差勁。
我們被解雇是因為他讓我們看起來可有可無。

以下是一段取代了我們的代碼示例

use axum::{Router, routing::get, Json};
use serde::Serialize;
use std::{sync::Arc, time::SystemTime};

#[derive(Serialize)]
struct Health {
    status: &'static str,
    uptime_seconds: u64,
}

async fn health_check(start_time: Arc<SystemTime>) -> Json<Health> {
    let uptime = SystemTime::now()
        .duration_since(*start_time)
        .unwrap_or_default()
        .as_secs();

    Json(Health {
        status: "ok",
        uptime_seconds: uptime,
    })
}

#[tokio::main]
async fn main() {
    let start_time = Arc::new(SystemTime::now());

    let app = Router::new().route(
        "/health",
        get({
            let start_time = start_time.clone();
            move || health_check(start_time.clone())
        }),
    );

    axum::Server::bind(&"0.0.0.0:3000".parse().unwrap())
        .serve(app.into_make_service())
        .await
        .unwrap();
}

是的，它很簡潔。是的，它很快。

但這不是一個 Node.js 工程師可以輕松上手的。

學習曲線是陡峭的（vertical），而公司里沒有其他人爬了上去。

我們的反思報告

回顧過去，問題出在這里——而且沒有一條是關于 Rust 本身的：

1. 我們忽視了這次重構： 我們把 Kabir 的重構當作一個個人項目。我們沒有和他結對編程。我們沒有閱讀早期的提交記錄。等我們意識到它已成為核心基礎設施時，它已經上線運行了。

2. 我們假設團隊 > 人才： 我們以為文化、協作和流程最重要。但當預算吃緊時，公司不會問誰人好相處。他們問的是誰能毫無阻礙地交付成果。

3. 我們沒有學習新工具： 我們本有機會學習 Rust —— 或者至少足夠理解它以便提供幫助。但我們留在了舒適區。這付出的代價比我們想象的要大得多。

最后一點思考

解雇我們的不是 Rust。

但一場沒有團隊共識的 Rust 重構，卻可以改變團隊本身的構成。

如果一個人在重構一切，而其他人還在寫 Jira 工單，那么他們不僅僅是在提升吞吐量——他們是在重構組織結構圖。

如果你正目睹這一切發生？

不要只是旁觀。