一名Infrastructure Engineer需要掌握哪些技術？

在Product/Infrastructure結構的開發團隊，一名合格的Infrastructure Engineer需要掌握哪些技術？

或者說成為一名優秀的Infrastructure Engineer需要怎樣的學習路線。

不需要具體到每種技術，只要說明是哪一類知識即可。

最好能標註出哪些是必須的，哪些是加分的，哪些需要深入學習，哪些需要大致了解。

知道哪些需求是目前實現不了的（難度太大、代價太高、周期太長），在項目論證階段就打回去，讓業務部門考慮其他方案。

infra最需要的技能就是寫文檔和甩鍋呀

至於說infra需要很強的代碼技巧，那不存在的，哪個公司的infra部門敢全盤推倒自己重新開發啊。

我是大四北美計算機系學生，今年暑假在灣區的IT公司實習，正好被分到一個infrastructure組。我覺得基礎中的基礎是計算機結構、操作系統。其次是資料庫，還有對編程語言底層的熟悉。加分項大概是分散式系統、network。

Infra 組的一個難點是在開始新項目的時候預估將要承受的流量/通量，然後根據流量來提出解決方案，並且盡量讓系統容易維護和拓展。

如果流量不大的話一個伺服器一個線程是不是可以解決，大概需要多少內存多少disk space，如果這一個機器壞掉會對整個系統有多大影響，是不是需要有backup sever來接手。怎麼判斷伺服器達到 maximum capacity, 怎麼在大流量情況下保護伺服器不輕易被overwhelmed.

流量比較大而且要求處理速度快的情況下可能需要多伺服器多線程。如果是這樣那就會涉及分散式系統裡面的 load balancing 和 fault tolerant 的問題。開源的解決方案很多，然而每個方案針對的流量和優化的點又各有不同。如何選擇最佳的開源解決方案，需不需要因地制宜有所修改。

這些都是開發一個infra項目動手之前需要考慮的。沒有紮實的操作系統和計算機結構基礎很難做好上述系統設計。這些問題都需要對所解決的問題有深入的了解，對所用的工具深入了解，否則實現之後的產品可能完全用不了。

產品上線之後的維護也不輕鬆。系統掛了以後要根據 back log 和各種有記錄的系統數據來找 bug 出在哪裡。比較困難的一些bug 可能涉及 race condition，cache invalidation，甚至資料庫replication lag導致返回錯誤的數值 ... 要優化項目的時候更要考慮系統涉及的各個層面裡面哪些是痛點，這就更要求對系統所有涉及方面的深入了解。

以上是我實習的一些經歷和感受。個人感覺就是基礎要足夠紮實，看代碼看得快而且細緻。有時候debug還需要一些想像力和抽象思維能力。

第一，做選擇，權衡利弊的能力。

比如說你要做一個petabyte scale database，你是想要注重於update throughput，還是query performance，或者是strong global consistency? 在谷歌里這三種需求分別對應了完全不同的系統設計。沒有可以解決所有需求的銀彈。

設計系統的過程其實就是不斷地選擇權衡的過程。為什麼選了輪子A，不選輪子B？我們想要達到什麼，而犧牲了什麼？

一個好的infra engineer並不需要「精通「或者「掌握」某些技術，而是需要知道儘可能多的輪子和解決方案，以及他們互相之間的差異和tradeoff。也就是說，對各種技術的了解，廣度比深度更重要。

第二，軟技能 (soft skills)

做infra engineer，軟技能其實比純技術能力更重要。在純product組裡，因為有PM承擔各種非技術的事情，工程師可以專註於代碼實現。而在infra組裡，因為下游用戶都是工程師，infra engineer需要更多的承擔和用戶（其他工程師）談判，溝通的責任。

一個infra項目能不能成功，能有多大的impact，三分之一取決於技術能力，而其他三分之二取決於能否說服別人用你的東西，能否和上游下游部門順利溝通，等等這些非技術的東西。

雖然說是軟技能，但是並不是純粹的比賽吹牛拍馬屁裝逼。而是如何向別人展示出你的想法和技術。有點類似於狼人殺裡面通過展現出你的邏輯分析來讓人相信你是好人，並說服場上其他玩家。

相對做業務，inf engineer需要更強的技術判斷力，這裡說一個我自己也在刻意提升的小點：

量化能力，即：一切都有數據證明，盡量都用數字說話，沒有顯然得證。

當然如果判斷不準，就得培養另一項技能：甩鍋能力了。。。