應用環境搭建到底要做哪些事？一臺新 Linux 伺服器的標準動作

不少老闆都經歷過這樣的場景：新伺服器到貨，找個人裝裝系統、裝個軟體，當天業務就跑起來了。看起來省事，往後一兩年裡卻接連冒出怪事——某天重啟之後服務起不來，誰也說不清這臺機器上到底裝過什麼；資料庫公網能連上，弱口令撐了半年沒出事純屬運氣；證書過期了沒人發現，客戶開啟頁面一片紅叉。

這些都不是"軟體沒裝好"，是環境沒搭好。

環境搭建這件事，做得糙的版本和做得細的版本，交付時看上去幾乎一樣——業務都跑著。差別要在出事那天、續證那天、換人接手那天才顯現出來。這篇把我們摩傑斯在日常交付裡反覆驗證過的一套標準動作按順序過一遍，把一臺新伺服器從裸機帶到"能扛事"，既是給想自己動手的廠裡技術當清單，也是給老闆一個驗收別人幹活的尺子。

一、先想清楚這臺機器要跑什麼

拿到伺服器別急著裝系統，先在紙上把"這臺機器上跑什麼"列清楚。

一臺典型的業務伺服器，通常是三類東西的組合：應用本身（一個 Web 應用、一套進銷存、一個官網）；它依賴的執行環境（某種語言執行時、一個資料庫、一個 Web 服務入口）；圍繞它們的輔助件（定時任務、日誌、備份任務）。

列清單這個動作有兩個用處。一是決定裝什麼、不裝什麼——環境搭建最重要的原則是"少裝"：機器上每一個多餘的軟體，都是一個未來的漏洞來源和排障干擾項。二是決定安全邊界：只跑一個內部應用、不對公網開放的機器，和掛著官網加資料庫的機器，防火牆和暴露面完全是兩套打法。

清單別停在腦子裡，落成一張表更管用。一臺業務伺服器的規劃表，五列就夠：

列	填什麼	後面誰會用
跑什麼	應用名稱與用途	服務清單、開機自啟
依賴什麼	執行時、資料庫、快取之類	版本清單、補丁跟蹤
佔哪個埠	埠號、對外還是僅內網	防火牆清單、反向代理配置
資料放哪	資料目錄、日誌目錄	磁碟分割槽、備份範圍
怎麼起	手工命令、系統服務還是容器編排	開機自啟、重啟演練

這張表在裝系統之前是計劃，做完之後就是交付文件的骨架——埠列直接變成防火牆清單，資料目錄列直接決定磁碟怎麼分，起法列決定開機自啟怎麼配。一份表貫穿到底，比事後回憶"當時怎麼弄的"可靠得多。

清單列完，最好再回答一個問題：這臺機器壞了，業務停得起多久？這個數決定了後面要配到什麼程度——如果是官網停一天無所謂，標準流程就夠；如果是生產系統，環境從第一天起就該配上備份和恢復預案，這屬於環境搭建的一部分，不是"以後再說"的事。

二、系統層：裝完系統先做這幾件事

作業系統選型這裡不展開，只重複一句結論：別用已經停止維護的老版本系統。新裝機型的選擇上，我們偏向簡潔的發行版：RHEL 系的 Rocky Linux、AlmaLinux，Debian 系的 Ubuntu LTS Server 版，都是成熟穩妥的選擇；有條件的團隊，我們甚至用 Arch Linux——滾動更新、預設裝出來就是最小系統，天然貼合"按需安裝"的路數。

安裝方式上，我們的原則從來只有一條：最小化安裝。 裝出來的系統越簡化越好——只保留讓系統跑起來的必需件，其餘一律不裝，業務需要什麼再按需補什麼。圖省事勾"全量安裝"，等於給機器預裝了一堆這輩子用不上的軟體包，這些多餘的東西每一個都是雙重的負擔：平時佔磁碟佔記憶體，出事時多一片攻擊面，打補丁時多一批要跟的更新。系統簡化還有一個常被低估的好處：機器上東西少，排障就快。服務列表一屏能看完，哪個程序該在、哪個不該在一眼分明；塞滿雜物的機器，光是分清"哪些是自己裝的"就要半天。

按需安裝不等於隨手安裝。每裝一樣東西，記兩筆：為什麼裝（對應哪個業務）、裝的什麼版本。這兩筆就是後面"環境即文件"的原料。

磁碟分割槽要在裝系統那一步就分對。 這一步比很多人以為的重要，因為裝完再改要停機、要搬遷資料，成本高得多。幾條硬經驗：

- 系統盤和資料盤分開。 有條件就掛兩塊盤：系統、執行時、程式放系統盤，資料庫與業務資料放資料盤。將來重灌系統、換機器、擴容，資料盤摘下來就還在；混在一塊，重灌系統就等於連資料一起賭命。 - /var 單獨成區。 日誌、資料庫預設目錄、容器映象都在 /var 底下。它獨立成區，日誌寫爆了頂多這一區滿，不會把根分割槽拖死——根分割槽滿了，機器連正常登入都困難。 - 按三年後算餘量，不是按現在。 長得最快的三樣是圖片附件、日誌、資料庫備份檔案。按"現在夠用"分割槽，一年後就得動刀。 - 能用 LVM 就用。 邏輯卷的價值是後期加盤擴容不停機，虛擬機器、雲主機上尤其省事。 - swap 按記憶體配。 十六 G 記憶體配四到八 G 的 swap，屬於"平時用不上、急時能救命"的保險。完全不配，記憶體打滿時程序是被直接殺掉的，不是被換出去的，表現就是服務莫名消失。

分割槽這一步做對，後面"資料在哪、備份備什麼、擴容怎麼擴"全都有了明確答案；做錯，這三件事每件都要臨時找答案。

系統裝完，第一波標準動作按順序做：

時區與時間同步。 把時區改成東八區，開 NTP 時間同步。這一步三十秒的事，但不做的話，日後日誌時間對不上、證書校驗莫名失敗、定時任務在奇怪的小時觸發，都是它埋的雷。資料庫主從、分散式應用對時間的要求更苛刻。

更新源與系統補丁。 裝完先更新一遍。國內機器把源換成近的映象站，速度差十倍。之後保持"安全更新及時打、大版本升級看清楚再動"的節奏。

普通使用者加 sudo。 建一個日常用的普通賬號，需要管理員許可權時用 sudo 提權，別拿 root 當日常賬號。這不是姿勢問題：root 直接操作，一條手誤就是不可挽回的，sudo 至少留了一層"要確認"的緩衝，而且每條提權命令都留了痕。

口令策略：機器生成的隨機密碼，不用人編的。 這臺機器上的每一個口令——root、sudo 賬號、資料庫、應用後臺、後續各類服務——統一用隨機密碼生成器生成，長度十二位起步，大寫字母、小寫字母、數字、特殊字元四類至少各含一種。人編的密碼再自以為冷門，套路都在爆破字典裡；機器生成的才真正無規律。生成之後立即歸位：進密碼管理器或列印進密碼信封，絕不出現在聊天記錄、表格和便籤裡。多臺機器各用各的，不圖省事複用——一臺洩露，不能連坐全部。這套口令紀律是我們摩傑斯每接手一臺機器都要重申的底線，看著繁瑣，出事時就是它把損失鎖在了一臺機器上。

主機名與說明。 給機器起個能認出來的主機名，順手在說明檔案裡寫一句這臺機器是幹嘛的。機器多了以後，"這是哪臺、跑的什麼"靠猜是災難。

裝完做一次減法自查。 最小化安裝之後，仍然會有一批用不上的服務預設在跑（列印、藍芽、本地郵件傳輸代理之類）。裝完順手列一遍當前跑著的服務，把與業務無關的停掉、禁用開機自啟。判斷標準就一句話：這個服務停了，業務會受影響嗎？ 不會，就關。十分鐘的活，換回來的是更短的服務清單和更小的攻擊面——而且清單越短，下次出事時排查越快。

幾條基礎引數順手確認。 檔案控制代碼上限這類預設值"夠用但不理想"：業務併發一上來，服務就報"開啟的檔案太多"，重啟能好一會兒，然後復發。環境階段把它在系統層和執行使用者層都確認一遍，比出事時再翻配置省事。至於核心網路引數、記憶體回收策略這些，業務量不大時不必深調，動著容易，調回去難。

還有一條要單獨講：伺服器上不裝圖形介面。 桌面環境動輒多裝幾百個包，吃記憶體、常駐程序、漏洞面擴大，而伺服器管理真正需要的東西——命令列、檔案傳輸、遠端執行——SSH 一條通道全覆蓋。裝機時選最小編不帶任何桌面，管理全程走終端。極個別場合業務確實要求圖形服務（某些特定軟體只給圖形配置介面），也只裝 XFCE4 這類輕量桌面應應付付，絕不上完整的 GNOME 或 KDE——那屬於把辦公電腦的配置錯誤地搬到了伺服器上。

三、安全基線：環境搭建裡不能省的部分

系統層收拾乾淨，接下來是安全基線。詳細的安全加固在《Linux 伺服器安全加固與入侵應急》裡專門展開過，這裡只說環境搭建階段就必須做的四件：

SSH 收口。 真正的門禁是兩條：禁用 root 密碼登入、改用金鑰，再裝上防爆破工具（fail2ban 這類）連續輸錯自動拉黑。公網上的機器，SSH 埠每天被掃的次數超乎想象，弱口令加密碼登入等於把門鑰匙放在門口墊子下面。至於"把埠從預設的 22 挪開"，基本沒有作用——我們做應急處理時見過埠早就改掉的機器照樣被掃出來——現在的埠掃描工具幾秒鐘就能把全部 65535 個埠跑完，藏埠藏不住；它頂多讓日誌裡的掃描噪音少一點，別把安全指望放在這上面。

防火牆從"全關"起步，再按需開。 這是硬規矩：新機器的防火牆預設狀態是全部埠關閉，一個口都不開，然後業務要哪個埠，再開哪個——而不是反過來"預設全開再逐個堵"。方向反了，堵漏永遠追不上暴露面。每開一個口，都在埠清單上記三筆：開的什麼口、給哪個服務用、能不能限源。開放埠執行最小化原則：能不開的堅決不開；只對本機用的服務絕不對外開；只對內網用的服務就只對內網網段開，能限定來源 IP 的就不全網放行。特別強調一條：資料庫埠絕不對公網開放。資料庫被拖庫的案例裡，相當一部分根本不是被"黑"進去的，是資料庫埠直接裸在公網上、密碼還弱。

日誌能留、能查。 確認系統日誌和服務日誌都在正常落盤，配上輪轉（logrotate），別讓一個日誌檔案把磁碟寫滿。日誌是出事後唯一能還原現場的東西。

賬號分賬，別用一個賬號串接關。 環境裡至少有三層賬號：系統層（普通使用者加 sudo）、資料庫層（業務專用賬號、許可權最小）、應用層（管理員與操作員分開）。用一個萬能賬號貫穿三層最省事，也最經不起事故——操作員被釣魚騙走密碼，等於把應用、資料庫、系統一起交了出去。分賬的代價是多記幾個口令，而這件事正好被上一條解決：口令交給生成器，人不負責記。順帶一句：賬號該禁用就禁用，別留"方便以後用"的殭屍賬號，離職、換人、臨時外包留下的賬號，是審計裡最先被點名的東西。

留下能查的痕跡。 環境搭建階段不要求上完整審計體系，但兩樣東西必須有：命令歷史帶時間戳（否則事後翻歷史只有命令、沒有時間，等於沒有），sudo 操作有日誌。真出事時，"誰在什麼時候動過什麼"是唯一能重建過程的東西。

裝完就加固，不是"跑起來再說"。 很多環境是"先用起來，安全以後補"，這個"以後"通常永遠不會來。加固不必一次做滿，但上面這幾條是底線，屬於環境搭建當日的工作量。

四、執行環境：按清單裝，別順手裝

到了裝應用執行環境的環節，核心紀律還是清單化：需要 PHP 就裝 PHP，需要資料庫就裝資料庫，每裝一樣都在清單上記一筆版本號。將來排查"裝了個新版本跑不起來"的問題，這份版本清單能省一半時間。

幾條實踐上的要點：

先定目錄約定，再往裡裝東西。 建議統一成一套固定結構：應用放在 /opt 下一個獨立目錄，裡面分幾樣固定的東西——編排檔案、環境變數檔案、資料目錄、備份目錄、運維指令碼目錄。整齊只是附帶的好處，真正值錢的是三件事：備份指令碼知道該備哪幾個目錄，遷移時知道該拷什麼，半年後接手的人開啟目錄就知道東西在哪。反過來，壓縮包解壓在哪算哪、檔案隨手扔在家目錄、備份和資料混在一起，是後面所有混亂的源頭。

Web 服務統一入口。 用 Nginx 之類做統一入口，把不同應用掛在不同埠或路徑後面，證書也集中在這裡配。所有服務各自裸奔在不同埠上的做法，早晚會亂。

資料庫裝完第一件事是收口。 改掉預設或空口令；只監聽本機或內網地址，不監聽公網；業務賬號按最小許可權給——查詢的賬號不給刪表許可權。這幾步做完，資料庫層面的基本盤就穩了。

執行環境，我們非常推薦用 Docker 打包，特別是 Docker Compose。 這件事的收益比太高：一份 compose 檔案把應用、依賴、埠、資料卷、環境變數全部寫清楚，起服務一條命令；換機器遷移，本質上是"拷走 compose 檔案和資料卷、在新機器上重新拉起來"；升級、回退、重建環境，都是分鐘級、可重複的動作。更妙的是，"環境即文件"這件事在 compose 裡是自動實現的——檔案本身就是這臺機器跑著什麼的完整答案，不用另寫。幾條使用紀律：映象版本寫死具體 tag、別用 latest（否則半年後重建出來的環境已經不是當初那個）；資料一律落在宿主機卷或目錄上，容器隨時可扔、資料不能陪葬；compose 檔案和普通配置一樣進備份、進交付文件。唯一的提醒是別混用：一旦決定用容器，就不要在宿主機上再散裝另一套服務，兩種體系混在一臺機器上，最後誰也說不清誰管什麼。

環境即文件。 把安裝步驟寫成指令碼或至少寫成筆記。第二次照著搭一臺一樣的機器時（遷移、災備、擴容都用得上），你會感謝這份文件。手上的動作留不下來，環境就永遠只存在這一臺機器上，它壞了就是真的壞了。

埠和訪問路徑一起規劃。 一臺機器上裝到第三個應用，埠幾乎必然撞車。裝之前把埠分配寫進開頭那張規劃表：誰佔哪個口、對外還是僅內網、經不經反向代理。推薦的結構是對外只暴露 80 和 443，其餘全部收在內網或本機——證書只在一處配，防護只在一處做，加一個應用只是加一段轉發規則，不用再開一個新埠。反過來，每個應用各開一個公網埠的做法，埠清單會越來越長，防火牆規則會越來越難講清楚。

一套典型應用的落地順序。 以"一個 Web 應用配一個資料庫"為例，按依賴順序裝，比想到哪做到哪省事得多：系統與網路（時區、源、主機名）→ 資料盤掛載與目錄建好 → 資料庫（建庫、建專用賬號、確認只監聽本機）→ 應用執行環境（版本寫死）→ 應用本身（先手工跑通）→ 反向代理與證書（對外這一步最後做）→ 開機自啟與重啟驗證。順序背後是一條簡單的邏輯：被依賴的先裝，對外的最後開。照著這個順序走，任何一步出問題，排查範圍永遠在剛動過的那一層；順序亂了，問題出在哪一層都說不清。

五、域名、證書與上線前檢查

對有 Web 業務的機器，域名和證書是環境的一部分，也要按規矩來：

證書免費付費按需選擇，關鍵是自動續期加結果通知。 HTTPS 證書可以用 acme 系列工具（如 certbot）申請免費證書，也可以買商業證書——免費還是付費，按業務需要選就行，這不是重點。重點是別用手動申請然後"到期再說"：部署時直接把自動更新指令碼配好，並讓指令碼把每次執行的結果郵件傳送到指定郵箱——續沒續成、什麼時候續的，郵件見分曉。這一步郵件通知的價值在於消滅靜默失敗：續期指令碼悄悄壞了三個月，沒有郵件通知就沒人知道，直到證書過期業務打不開；有了結果郵件，第一次失敗當天就有人看見。配完之後手動觸發一次，驗證流程和郵件都真能跑通。證書過期導致業務打不開，是運維事故里最冤的一種，純屬流程問題。

上線前的檢查單過一遍。 環境搭完不等於能上線，用外部視角驗一遍：從公網掃描一下開放的埠，和清單對得上嗎？所有服務配了開機自啟嗎？日誌在正常滾動嗎？定時任務列出來看過一遍嗎？最有分量的一項：把機器重啟一次。 重啟能起來的環境才是真正的環境——不少"執行了兩年"的機器，重啟之後一堆服務起不來，因為某次手改的配置沒落盤、某個服務從來不是自啟的。重啟演練放在上線前，代價最小。

這條檢查單源自我們摩傑斯環境搭建專案的交付驗收單，建議列印出來逐項打勾，別憑印象過：

檢查項	透過標準
埠暴露	公網掃描結果與埠清單完全一致，沒有一個多餘埠
開機自啟	業務服務全部設為自啟，重啟後自動恢復
完整重啟	整機重啟一次，業務可用、日誌正常、無報錯刷屏
資料落盤	資料庫與業務資料在資料盤，重啟後資料完好
時間同步	系統時間準確，同步服務在正常執行
證書	自動續期配好，手動觸發驗證過，結果郵件能收到
備份	備份任務至少成功跑過一次，恢復步驟驗證過
告警	磁碟水位、關鍵程序有最低限度告警，且真能送到人
文件	一頁環境說明寫完，埠清單與口令存放位置齊全

這張表的價值，是把"我覺得搭好了"換成"逐條驗過了"。自己搭的環境最缺的恰恰是這個外部視角——因為搭的人知道每一步的意圖，所以會下意識地跳過那些"顯然沒問題"的項，而事故往往就藏在顯然裡。

最低限度的監控與告警。 不要求上監控平臺，但磁碟水位、記憶體佔用、關鍵程序存活這三樣得有最低限度的看護——哪怕先是一條定時指令碼，磁碟超過八成、關鍵程序不在了，能發條通知到人。磁碟寫滿拖垮資料庫、程序靜默掛掉沒人發現，是事後回看最"不值得"的兩類事故：發現它們的門檻很低，前提是有人被叫到了。

備份計劃跟環境一起搭。 這一步經常被歸為"以後最佳化"，其實它屬於環境搭建的收尾：環境搭好那天，備份任務、備份去向、恢復步驟就該一併就位。備份體系怎麼做，之前那篇《伺服器備份到底該怎麼做？從"備了"到"能恢復"差多遠》專門展開過，照著配就行。

六、交付與交接：讓機器"可以被接手"

環境搭建的最後一步，經常被跳過，但它決定這套環境是真資產還是黑盒：交付一份一頁紙的環境說明。

內容不復雜：這臺機器跑著哪些服務、各自什麼版本、配置檔案在哪；root、資料庫、應用後臺這些口令是機器生成的十二位以上隨機密碼，統一放在哪裡（密碼信封或密碼管理器，不是聊天記錄）；服務怎麼重啟、常見問題找哪個日誌；防火牆開了哪些埠、各自給什麼服務用、為什麼。半夜出事的時候，接手的人靠這一頁紙就能幹活，而不是從"先搞清楚這臺機器上有什麼"開始。

順帶說個判斷標準：一臺說不清"上面有什麼"的伺服器，無論跑著多重要的業務，都是風險敞口。 環境說明不是給外人看的文件，是給自己留的退路——半年後連當初搭環境的人自己都忘了細節，這頁紙就是唯一可靠的記憶。

我們交接一臺機器時，要交的是四樣東西，不是一句"裝好了"。 一是那頁環境說明；二是口令的存放位置（信封在哪、密碼管理器誰有許可權），注意是位置而不是口令本身；三是編排檔案或安裝指令碼這類能重建環境的東西；四是埠清單和變更記錄。這四樣在手上，換誰來接手都能幹活；只有一句"裝好了"，接手的人第一件事就是從零摸底。

再補一條容易被忽略的：留一份變更記錄。 不用複雜，一個文字檔案就夠——哪天、改了什麼、為什麼改、改之前是什麼樣。環境出問題，九成和最近某次改動有關；有這份記錄，排查從"翻遍所有配置檔案"變成"先看最後一次動的是哪"。同理，改任何配置前把原件複製一份帶日期的備份，是最低成本的後悔藥。

七、三種常見場景，重點完全不一樣

同一套標準動作，落到不同機器上，側重其實不同。按廠裡最常見的三類說：

場景	典型配置	搭建重點	可以省的地方
內網小工具	一臺機器、一個應用、一個資料庫，只對內網開放	資料落盤、備份、重啟驗證	證書可以緩一步（內網先走 HTTP），對外防護可簡化
官網或內容站	一臺機器，Web 入口加資料庫，對公網開放	證書自動續期、埠最小化、防爆破、靜態資源快取	資料庫只監聽本機即可，不必對外
內網生產系統	一臺或兩臺，業務停不得	備份與恢復演練、監控告警、快速重建預案	花哨的效能最佳化一樣都不要

三條線的判斷依據還是那個問題：這臺機器停一天，損失有多大？ 內網小工具停一天，大家罵兩句就過去了；生產系統停一天，可能是一批貨交不出去、一個客戶丟掉了。搭建深度不一樣，錢也就不該花在同一個地方——給內網小工具配雙機熱備是浪費，給生產線上的系統只留一句"出問題找我"則是賭博。

八、裝完頭一個月常冒出來的幾個毛病

下面這幾件事不是理論推演，是我們接手的機器裡環境搭完頭一個月最常遇到的。提前知道，能省掉不少半夜翻日誌的時間：

重啟之後服務沒起來。 八成是兩種情況：服務壓根沒設開機自啟（當初是手工敲命令跑起來的）；或者配置檔案改完沒生效，重啟時載入的還是舊的。所以交付前必須真重啟一次——"我看它跑得好好的"永遠替代不了重啟。

磁碟莫名其妙滿了。 來源通常是三處：日誌沒配輪轉、資料庫備份檔案堆在同一塊盤、容器映象和舊層沒清理。先按目錄大小排一遍看誰在長，別急著刪檔案——刪之前先確認這個檔案是幹什麼用的，刪錯一次比磁碟滿更麻煩。

時間不對。 表現是日誌時間錯亂、證書校驗失敗、定時任務在古怪的時刻觸發。多數是時區沒設或時間同步服務沒起來，兩分鐘能修好；但發現得晚，日誌的因果順序就亂了，出事時連"先發生什麼"都排不出來。

埠衝突，新服務起不來。 一臺機器裝到第三個應用時幾乎必然遇到。規劃表裡記過埠就不會撞；真撞了先查是誰佔著，別順手把新服務的埠一改了事——改完可能和反向代理裡那段轉發規則對不上，表現出來就是"服務在跑但頁面打不開"。

證書續期悄悄失敗。 續期指令碼天天在跑，但失敗了沒人知道，直到某天頁面報證書過期。這正是要求"續期結果發郵件"的全部理由：把"到底續上沒有"變成每天能看見的一行字，而不是等到過期那天才被客戶告知。

九、幾個常見的搭建誤區

按踩坑頻率排一下：

誤區一：root 直接跑業務。 手誤沒有緩衝，程序被入侵即拿到最高許可權。建普通使用者、最小許可權，十分鐘的事。

誤區二：資料庫埠對公網開放。 前面說過，不再重複，這是致命項。

誤區三：證書手動申請、裝完不管。 續期必須自動化，且驗證過一次。

誤區四：所有東西擠一臺機器還不做隔離。 公司小、預算緊，一臺機器跑幾個應用可以理解，但至少把 Web 入口、應用、資料庫的許可權邊界劃開，一個應用被攻破不等於全家淪陷。

誤區五：裝完不記錄版本和步驟。 環境只存在於那臺機器和那個人的腦子裡，機器一壞、人一走，全部重來。

誤區六：環境搭完才想備份，或者根本不想。 備份是環境的組成部分，不是增值服務。

誤區七：一次改太多。 調整環境一次動一樣，改前記下現狀，壞了能退回去。"同時改了五處，不知道哪處弄壞的"是排障界最貴的懸案。

誤區八：裝個桌面圖省事。 以為有圖形介面更好管，實際是把辦公電腦的包袱搬到伺服器上：多幾百個包、多一片漏洞面、多一批要跟的更新，而管理效率並沒有提高——伺服器上的活，命令列始終更快更準。保持無桌面的精簡系統，才是真正省事的路線。

誤區九：資料和系統混在一處。 單盤不分割槽最省事，代價是系統出問題要重灌時，資料也跟著賭一把。至少把 /var 分出來、有條件再加一塊資料盤，成本幾乎為零，救的卻可能是全部業務資料。

誤區十：直接改線上配置，不留退路。 改之前複製一份帶日期的原件，改完不對能立刻換回去——三十秒的動作，能省掉一整晚"該回滾到哪一版"的糾結。線上直接編輯又沒備份，等於把每一次調整都做成不可逆的。

十、從裸機到交付的完整順序（清單版）

把前面各節的動作按順序串一遍，這就是一張可以直接照著執行的裝機清單：

1. 規劃：列清這臺機器要跑的應用、依賴與輔助件，落成五列規劃表（跑什麼、依賴什麼、佔哪個埠、資料放哪、怎麼起）；明確"停得起多久"，決定備份與恢復配置的深度。 2. 系統：選簡潔的發行版（RHEL 系 Rocky/Alma、Debian 系 Ubuntu Server，有條件可 Arch），最小化安裝，不帶桌面；磁碟按資料盤與 /var 分割槽、留足餘量；裝完改時區、開時間同步、換近源、更新一遍、做一次減法自查。 3. 賬號：建普通使用者加 sudo；全部口令用生成器出十二位以上四類字元隨機密碼，歸入密碼信封，各機器不復用；系統、資料庫、應用三層賬號分開，不留殭屍賬號。 4. 安全基線：SSH 金鑰登入禁 root 密碼、裝防爆破（改埠僅降噪不指望防身）；防火牆從全關起步，按需開、最小化開、記錄每個口；日誌確認落盤並配輪轉；命令歷史帶時間戳、sudo 留痕。 5. 執行環境：定好目錄約定（編排檔案、環境變數、資料、備份、指令碼各歸其位）；用 Docker Compose 打包（版本寫死、資料落宿主機卷、compose 入備份）；資料庫收口；Web 統一入口、對外只留 80 與 443。 6. 對外服務：域名解析、HTTPS 證書（免費或付費按需選）、自動續期指令碼配好執行結果郵件通知、手動觸發驗證一遍。 7. 上線檢查：公網埠掃描對清單、開機自啟全配、定時任務過目、磁碟記憶體程序有最低限度告警、完整重啟一次驗證。 8. 備份就位：備份任務、去向、恢復步驟隨環境當天交付，不留"以後再說"。 9. 交付：一頁環境說明落筆——服務清單、版本、配置位置、密碼存放、埠清單、重啟方法。

九個步驟走完，這臺機器才算從"能跑"變成了"能扛"。中途每一步多花的十分鐘，都是將來某個深夜少熬的一小時。

十一、交給專業的人，也有一頁驗收紙

環境搭建是可以自己動手的活，照著這篇的順序做，一臺普通業務伺服器一兩天能收拾利索。但如果機器上跑的是停不得的生產系統，或者廠裡實在沒人肯碰命令列，找專業的人一次性把環境搭好、把文件留下，是筆劃算的買賣——環境搭建是典型的一次性短期專案：今天搭好、文件交付、當場驗收，之後的日子機器怎麼維護是您自己的事。

什麼時候該找外面的人，判斷起來其實就三條：機器停了有實際的錢在損失；廠裡只有一個人會弄、而這個人還要休假；歷史環境已經亂到說不清上面有什麼，重建比整改更省。三條裡中一條就值得考慮，中兩條基本不用猶豫。

我們摩傑斯做 Linux 服務，環境搭建類專案的交付物通常包括：按清單裝好的執行環境、收口後的安全基線、能自動續期的證書、隨環境就位的備份任務，以及最重要的一頁環境說明。驗收也簡單：當場重啟一次、當場演練一次備份恢復、當場照著文件核一遍清單——三樣都過，這個環境才算真的交付了。

機器終歸是拿來跑業務的，但業務跑得穩不穩，一半的底子是在環境搭建那兩天打下的。新伺服器到手，別隻裝個軟體就完事——把該做的標準動作做全，往後每一次半夜的警報，機率都會小很多。

把一臺裸機變成一個"能扛事"的環境，攏共九步：想清楚要跑什麼、系統最小化收好底、賬號口令交給生成器、安全基線從全關起步、執行環境照清單、證書管續期、上線前重啟演練、備份隨環境就位、交付留下一頁紙。每一步都不難，難的是件件都做、事事留痕。

伺服器不會因為業務跑起來了就自動變安全，環境也不會隨著時間自動變規矩。系統裝得越簡、口令越是機器出的、埠開得越少，將來的深夜警報就越少——第一次就按標準來，是成本最低的時刻。

想補齊周邊的知識拼圖：為什麼生產系統值得建在 Linux 上，看《系統為什麼從第一天就跑在 Linux 上》；半夜宕機怎麼分鐘級拉起，看《產線系統半夜宕機怎麼分鐘級拉起》；環境之上的安全層怎麼加固，看《Linux 伺服器安全加固與入侵應急》；環境的保險怎麼配，看《伺服器備份到底該怎麼做？從"備了"到"能恢復"差多遠》。應用環境搭建這類一次性短期專案的服務範圍，見摩傑斯 Linux 伺服器服務介紹。

>