CI/CD 自動化

🎯 核心問題

程式碼在本機跑得好好的，怎麼讓全世界的人都能存取？

1. 為什麼要「服務上線」？

想像一下，你在自己家裡做了一桌好菜，非常好吃。但問題是，只有自家人能吃到，鄰居、管理員、陌生人都嚐不到。

怎麼辦？你需要把菜端到餐廳裡。這就是「服務上線」要做的事——把你寫的程式碼，從個人電腦，搬到了一台 7×24 小時永遠開著的「公用電腦」上。這樣任何人只要能上網，就能存取你的網站。

服务上线全流程从代码到用户眼中的网页

开发阶段

Git

代码版本控制

→

CI/CD

自动化流水线

构建阶段

Test

自动化测试

→

Build

编译打包

→

Artifact

构建产物存储

部署阶段

Server

服务器环境

→

Deploy

部署应用

→

Nginx

反向代理

网络配置

HTTPS

SSL证书

→

CDN

内容分发加速

→

DNS

域名解析

运维阶段

Monitor

监控状态

→

Log

日志收集

→

Alert

告警通知

核心原则：小步快跑 → 先上线MVP → 逐步完善

服務上線涉及很多環節。就像開餐廳不僅僅是端菜出去，你還需要租店面、裝修、辦執照、僱服務員等。開發網站也是同理。從程式碼到使用者能存取的網站，中間隔著很多步驟。需要一步步完成建置、部署、設定網路、保證安全等工作。

下面我會把整個流程拆開來講。每個環節都掰碎、揉細。保證連完全沒基礎的小白也能看懂。

2. 建置：把程式碼變成「可攜帶的包裹」

2.1 為什麼要建置？

新手常問：程式碼寫好了，為什麼不能直接放到伺服器上讓使用者存取？

要回答這個問題，先搞清楚你寫的程式碼是什麼格式。你可能用 Vue、React、Express、Koa 等框架。這些框架有一個共同特點：它們不是給瀏覽器或伺服器直接用的。

舉個例子。你寫 Vue 程式碼時，是不是用過 <template>、<script setup> 這種標籤？這種語法只有 Vue 認識。瀏覽器根本看不懂。瀏覽器只認識三種語言：HTML（網頁結構）、CSS（網頁樣式）、JavaScript（網頁邏輯）。Vue 元件語法對瀏覽器來說就像天書，完全無法理解。

所以在把程式碼放到伺服器之前，必須做一件重要的事：把它翻譯成瀏覽器能看懂的語言。這個翻譯過程叫做「建置」（Build）。

2.2 建置具體做什麼？

建置不只是翻譯。它還會做很多最佳化。讓網站跑起來更快、更省資源。詳細說說它具體都做了哪些事：

第一步：解析相依性

寫程式碼時，會用到各種第三方函式庫。比如 Vue、Vue Router、Axios、Vite 等。這些函式庫不可能每次都讓使用者從 npm 下載。那樣太慢了。建置工具會分析程式碼，把所有相依性找出來。然後把它們「打包」到一起。

第二步：編譯轉換

這是最核心的一步。把 Vue 元件編譯成 HTML 和 JavaScript。把 SASS/LESS 編譯成 CSS。把 ES6+ 新語法轉換成相容性更好的 ES5 程式碼。這步完成後，程式碼就從「開發者能看懂的格式」變成「機器能執行的格式」。

第三步：壓縮混淆

壓縮就是把所有空格、換行、註解刪掉。把變數名稱從英文單字改成單個字母。比如 userName 變成 a，calculateTotalPrice 變成 b。這樣檔案大小大幅減小。使用者下載起來就快多了。混淆後的程式碼人類基本看不懂。也能起到一點「保護程式碼」的作用。

第四步：程式碼分割

可能寫了 10 個頁面。每個頁面有自己的程式碼。但使用者可能只存取其中一個頁面。為什麼要下載其他 9 個頁面的程式碼？建置工具會把程式碼分割成多個小塊。使用者存取哪個頁面就下載哪個頁面的程式碼。這就是「按需載入」。能大幅提升首次存取的速度。

第五步：產生雜湊值

這是非常重要的一步。但很多人會忽略。建置完成後，檔案名稱會變成類似 app.abc123.js、vendor.def456.css 這樣的格式。後面那串字母數字混合的字串叫「雜湊值」。

雜湊值的作用是：當程式碼有任何改動時，雜湊值就會變化。瀏覽器就知道「這個檔案變了，需要重新下載」。沒變的檔案，瀏覽器繼續使用快取。不用重複下載。這樣既能保證使用者看到最新程式碼，又能充分利用快取提升速度。

1解析依赖

→

2编译转换

→

3打包压缩

→

4完成

2.3 怎麼執行建置？

大多數現代前端專案都已經配好建置工具。只需要記住一個指令：

bash

# 如果用 npm
npm run build

# 如果用 yarn
yarn build

# 如果用 pnpm
pnpm build

執行完後，去專案根目錄找一個叫 dist 的資料夾（有時也叫 build 或 .output）。裡面就是建置好的所有檔案。這些檔案就是最終要上傳到伺服器的東西。不需要再做任何修改。直接拖到伺服器上就行。

2.4 建置產物裡有什麼？

打開 dist 資料夾，會看到裡面主要是三類檔案：

HTML 檔案：通常叫 index.html。這是入口檔案。瀏覽器首先載入的就是它。
JS 檔案：所有 JavaScript 程式碼。可能是 1 個也可能是好幾個。
CSS 檔案：所有樣式程式碼。可能內嵌在 HTML 裡，也可能是單獨的 CSS 檔案。

如果是比較複雜的後端專案（比如 Node.js），建置產物可能是一個可執行檔，或者一個 Docker 映像檔。但原理是一樣的：把程式碼變成伺服器能直接執行的形式。

3. 伺服器：找一台永遠不關門的「房子」

3.1 伺服器到底是什麼？

很多人第一次聽到「伺服器」，覺得是什麼高大上的神秘裝置。其實沒那麼複雜。伺服器就是一台電腦。一台永遠不關機、一直插著網路線的電腦。

可能有人問：我自己家裡不是有電腦嗎？為什麼要額外花錢租伺服器？

這個問題問得好。幫你分析一下：

首先，你家的電腦不可能 24 小時開著。你要出門、要睡覺、偶爾還會當機重啟。但伺服器不一樣。它專門用來做這個。可以 365 天全年無休地執行。網站隨時都能存取。

其次，你家的網路也不行。家用寬頻的上傳速度通常很慢。而且家用寬頻的 IP 是動態變化的。今天是這個 IP，明天可能就變成另外一個了。根本沒法用來做網站伺服器。伺服器用的是資料中心的高速網路。IP 固定，網速飛快。

第三，你家的電腦沒有「公網 IP」。什麼叫公網 IP？就是全世界獨一無二的地址。只有有這個地址，別人才能在網際網路上找到你的電腦。你家電腦的 IP 通常只能在你家區域網路裡用。外面的人根本找不到你。伺服器就不同了。它有一個固定的公網 IP。全世界的人都能透過這個 IP 找到它。

个人博客1核 1G¥50/月

小型电商2核 4G¥300/月

中型应用4核 8G¥1000/月

3.2 怎麼選伺服器？

選伺服器主要看三個指標：CPU 核心數、記憶體大小、硬碟空間。這三個指標越高，伺服器效能越好，價格也越貴。

對於剛入門的新手，完全沒必要買特別貴的配置。記住一個簡單的選法：

個人專案、學習練手：1 核心 2G 記憶體，足夠了。一個月大概幾十塊錢。
小型商業專案：2 核心 4G 記憶體。能承載每天幾千到幾萬存取量。
中型專案：4 核心 8G 或更高。需要專業團隊來維運了。

還有一個要考慮的點：地域。如果使用者主要在台灣/中國大陸，就買國內的伺服器（阿里雲、騰訊雲），存取速度快。如果使用者主要在海外，就買國外的伺服器（AWS、Google Cloud、DigitalOcean），或者買香港的伺服器。速度快而且不用備案。

3.3 國內還是國外？

這是個很重要的問題。很多人剛開始沒想清楚。後期會遇到麻煩。

買國內伺服器的好處是速度快、延遲低。缺點是需要備案（提交網站資訊給國家相關部門審核）。通常要等一週到一個月。而且國內伺服器價格相對貴一些。

買國外伺服器的好處是不用備案。買了就能用。價格也可能更便宜。缺點是中國大陸使用者存取速度可能慢一些。如果是香港或新加坡機房會好很多。

建議是：如果是個人專案、學習展示用的網站，買香港或海外的伺服器。省去備案的麻煩。如果是做正規商業專案，需要長期營運，就買國內伺服器。老老實實備案，後期會省很多麻煩。

3.4 主流雲廠商對比

廠商	適合人群	特點	新使用者價格
阿里雲	國內業務	市場佔有率第一，生態完善	首年幾十到一百多
騰訊雲	小程式、遊戲	小程式雲端開發支援好	首年優惠力度大
華為雲	企業使用者	政府、政務專案首選	價格偏高
DigitalOcean	開發者	簡單好用，價格透明	$4/月起
Vercel	前端專案	零配置，直接推送就上線	免費額度夠用

新手最推薦 阿里雲 或 騰訊雲 的學生機/新使用者優惠。通常一年只需要幾十塊錢。性價比極高。如果做的是純前端專案，想省事，也可以直接用 Vercel 或 Netlify。連伺服器都不用買。把程式碼推送上去就自動部署好了。

3.5 拿到伺服器後該做什麼？

買完伺服器後，會收到一封郵件。裡面包含幾個重要資訊：

IP 位址：一串類似 123.45.67.89 的數字。這是伺服器在網際網路上的門牌號。
登入使用者名稱：通常是 root（管理員帳號）。
登入密碼：初始密碼，或者是讓你設定密碼的連結。

有了這些資訊，就可以用 SSH（Secure Shell） 遠端登入到伺服器上。對它進行各種設定。SSH 就像是給伺服器發的一條加密的遠端控制指令。讓自己電腦上就能操作遠在天邊的伺服器。

登入指令是這樣的：

bash

ssh root@123.45.67.89
# 按Enter後會讓你輸入密碼。輸入正確的密碼後就登入成功了。

登入成功後，就進入了伺服器的命令列介面。看起來和在自己電腦上開了一個終端機視窗差不多。可以在這裡安裝軟體、建立資料夾、修改設定。一切操作都和本機電腦一樣。

4. 部署：把程式碼搬進「房子」

4.1 部署是什麼？

部署就是租好了伺服器（房子）之後，把程式碼（行李家具）搬進去。然後開門開始營業的過程。

具體來說，部署包括以下幾個步驟：

把程式碼上傳到伺服器：把建置產物從本機電腦傳到伺服器上。
安裝相依性：伺服器上可能沒有專案需要的各種套件。需要安裝。
設定環境變數：比如資料庫密碼、API 金鑰等敏感資訊。
啟動服務：讓應用程式跑起來。開始監聽使用者的請求。

這四個步驟聽起來挺複雜。但其實做起來沒那麼難。下面會詳細介紹每一步怎麼做。

个人博客1核 1G¥50/月

小型电商2核 4G¥300/月

中型应用4核 8G¥1000/月

4.2 怎麼把程式碼上傳到伺服器？

方法一：FTP/SFTP 上傳

這是最直觀的方式。就像用網路硬碟一樣。把檔案拖到伺服器上。可以在自己電腦上下載一個叫 FileZilla 的免費軟體。填入伺服器的 IP、使用者名稱、密碼。就能像管理本機檔案一樣管理伺服器上的檔案了。

方法二：Git 拉取

這是更推薦的方式。先在 GitHub、GitLab 或 Gitee 上建立一個程式碼儲存庫。把程式碼推送到雲端。然後在伺服器上用 git clone 指令把程式碼拉下來。

這樣好處是：後續更新程式碼只需要在伺服器上執行 git pull 指令就行。不用每次都手動上傳。而且程式碼存雲端也安全。伺服器重裝了也不怕。

方法三：CI/CD 自動部署

這是最專業的方式。也是強烈推薦的方式。透過設定 CI/CD（持續整合/持續部署），只需要把程式碼推送到 GitHub。CI/CD 系統就會自動幫你完成：拉取程式碼 → 安裝相依性 → 建置 → 部署的全過程。甚至不需要登入伺服器。一切都是自動完成的。

4.3 部署的具體步驟

假設用最簡單的方式——Git 手動部署。一步步示範整個過程：

第一步：連線到伺服器

bash

ssh root@123.45.67.89

第二步：安裝必要的軟體

如果是 Node.js 專案，需要先安裝 Node.js：

bash

# 以 Ubuntu 系統為例
curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -
sudo apt install -y nodejs

第三步：拉取程式碼

bash

# 建立放網站的目錄
mkdir -p /var/www/my-website
cd /var/www/my-website

# 複製程式碼儲存庫（需要先在 GitHub 上建立好儲存庫）
git clone https://github.com/你的使用者名稱/你的儲存庫名稱.git .

第四步：安裝相依性並建置

bash

# 安裝專案相依性
npm install

# 建置專案（產生 dist 目錄）
npm run build

第五步：用 PM2 啟動服務

為什麼要用 PM2？它是一個程序管理工具。可以讓網站在背景持續執行。就算伺服器重啟了也能自動啟動。

bash

# 全域安裝 PM2
sudo npm install -g pm2

# 啟動網站（假設入口檔案是 index.js）
pm2 start index.js

# 設定開機自啟
pm2 startup
pm2 save

第六步：設定 Nginx 反向代理

Node.js 應用通常跑在 3000 或 8080 這樣的連接埠上。但使用者存取的是 80 連接埠（HTTP 預設連接埠）。需要用 Nginx 把 80 連接埠的請求轉發到應用連接埠。

bash

# 安裝 Nginx
sudo apt install -y nginx

# 建立 Nginx 設定檔
sudo nano /etc/nginx/sites-available/my-website

在打開的編輯器裡寫入以下設定：

nginx

server {
    listen 80;
    server_name example.com www.example.com;

    # 靜態檔案（建置產物）直接回傳
    location / {
        root /var/www/my-website/dist;
        index index.html;
        try_files $uri $uri/ /index.html;
    }

    # API 請求轉發到 Node.js 後端
    location /api/ {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

儲存退出後，啟用這個設定：

bash

# 啟用設定
sudo ln -s /etc/nginx/sites-available/my-website /etc/nginx/sites-enabled/

# 測試設定是否有錯誤
sudo nginx -t

# 重啟 Nginx
sudo systemctl restart nginx

現在存取 http://example.com（記得先把域名解析到這個伺服器 IP），應該就能看到網站了！

5. 域名和 DNS：給網站起個好名字

5.1 為什麼要買域名？

有了伺服器 IP，為什麼還要買域名？

想想看。讓你記住一串數字 123.45.67.89 是不是很困難？是不是很容易打錯？但讓你記住 baidu.com、taobao.com 這樣的名字是不是就簡單多了？

域名就是網站的名字。好記、專業。還能體現品牌形象。想像一下。告訴別人「存取我做的網站，IP 是 123.45.67.89」，和「存取 woshishuaige.com」，哪個更像那麼回事？

💻用户输入域名

→

📋查询 DNS

→

✅返回 IP

示例：example.com → 192.168.1.1

5.2 DNS 是什麼？

好。現在買了一個域名。比如叫 my-awesome-website.com。但問題來了：電腦只認識 IP 位址。不認識 "my-awesome-website.com" 這種人類語言啊。

這就需要 DNS 出場了。DNS 的全稱是 "Domain Name System"。翻譯過來就是「域名系統」。可以把它理解成一本巨大的「電話簿」。專門負責把人類好記的域名翻譯成電腦能看懂的 IP 位址。

當在瀏覽器裡輸入 my-awesome-website.com 並按 Enter 時。背後發生了這些事情：

瀏覽器問 DNS：「嘿，my-awesome-website.com 的 IP 位址是多少？」
DNS 查了一下「電話簿」，告訴瀏覽器：「它的 IP 是 123.45.67.89」
瀏覽器根據這個 IP 位址，找到了伺服器，發出了請求

整個過程通常只需要幾十毫秒。使用者完全感知不到。

5.3 怎麼設定 DNS？

設定 DNS 通常有兩個地方可以操作：

方式一：在域名購買商那裡設定

在哪裡買的域名，就去哪裡設定 DNS 記錄。最常見的記錄類型是 A 記錄：

記錄類型：A
主機記錄：通常填 @（代表域名本身，如 my-awesome-website.com）或者 www（代表 www.my-awesome-website.com）
記錄值：伺服器 IP 位址，如 123.45.67.89

方式二：使用第三方 DNS 服務

很多專業玩家不用域名商自帶的 DNS。而是用 Cloudflare、阿里雲 DNSPod、騰訊雲 DNS 這些專業的 DNS 服務商。這些服務通常更穩定、解析速度更快。還自帶 CDN、DDoS 防護等加值功能。

5.4 DNS 生效要多久？

這是很多人關心的問題。答案是：不一定。通常幾分鐘到 24 小時。

DNS 修改後，全球所有的 DNS 伺服器需要同步這個變更。這就像往大海裡扔一顆石子。波浪需要時間才能傳到遠方。有些 DNS 伺服器更新快，幾分鐘就生效了。有些比較慢，可能需要等很久。

可以用以下指令檢查 DNS 是否生效：

bash

# Windows
ping 你的域名

# Mac/Linux
ping 你的域名

如果 ping 得通，顯示的是伺服器的 IP。說明 DNS 已經生效了。

6. HTTPS：給網站裝一把「鎖」

6.1 HTTP 和 HTTPS 的區別

可能注意到了。有些網站位址是 http:// 開頭的。有些是 https:// 開頭的。這個「s」很重要。它代表「安全」（Secure）。

HTTP（HyperText Transfer Protocol） 是用來傳輸網頁的協定。可以把它理解成運輸資料的卡車。但這輛卡車是透明的。裡面裝的東西所有人都能看見。在 HTTP 網站上輸入的密碼、填寫的個人資訊。在傳輸過程中可能被中間的任何人偷看到。

HTTPS（HTTP Secure） 是給這輛卡車加了一個密封的貨櫃。還配了一把鑰匙。只有傳送方和接收方有鑰匙。中間的人就算截獲了也看不懂裡面是什麼東西。這就是加密傳輸。

HTTP

❌ 明文传输

 HTTPS 
 ✅ 加密传输 

💡 推荐：Let's Encrypt 免费证书

6.2 為什麼要 HTTPS？

第一個原因：安全。沒有 HTTPS，使用者在網站上輸入的密碼是明文傳輸的。但凡有點技術的人都能截獲。這年頭，誰敢用沒有 HTTPS 的網站？

第二個原因：瀏覽器警告。現在 Chrome、Edge 這些主流瀏覽器都會對沒有 HTTPS 的網站顯示「不安全」的警告。使用者一看警告圖示。跑了都來不及。更別說註冊、儲值了。

第三個原因：SEO。Google、百度這些搜尋引擎都會優先收錄 HTTPS 的網站。SEO 效果會更好。

6.3 怎麼取得 HTTPS 憑證？

以前 HTTPS 憑證很貴。每年要花幾百甚至幾千塊錢。現在好了。出了一個叫 Let's Encrypt 的組織。提供完全免費的 SSL/TLS 憑證。而且社群有很多自動化工具幫你安裝和續期。

方式一：使用 Certbot（推薦）

Certbot 是一個自動申請和設定 Let's Encrypt 憑證的工具。非常簡單：

bash

# 安裝 Certbot
sudo apt install -y certbot python3-certbot-nginx

# 一鍵申請憑證並設定 Nginx
sudo certbot --nginx -d example.com -d www.example.com

執行過程中會問幾個問題。比如郵箱（用於憑證到期提醒）。回答完後憑證就自動設定好了。存取網站會發現網址列多了一個小鎖圖示。

憑證有效期是 90 天。但 Certbot 會幫你設定排程任務自動續期。基本不用管它。

方式二：使用 Cloudflare

如果使用了 Cloudflare 的 DNS 服務。那 HTTPS 憑證根本不用自己設定。Cloudflare 會自動為域名提供 HTTPS 支援。而且連 90 天續期的問題都幫你解決了。

6.4 設定 HTTPS 後發生了什麼變化？

設定好 HTTPS 後，使用者存取從原來的 http://example.com 變成了 https://example.com。這個變化帶來了一系列的安全保障：

加密傳輸：使用者和伺服器之間的所有通訊都是加密的。
身份驗證：憑證可以證明「我真的是這個網站」。防止釣魚網站。
資料完整性：能偵測到資料是否被竄改。

7. CI/CD：讓機器人幫你幹活

7.1 什麼是 CI/CD？

CI/CD 是兩個詞的縮寫：Continuous Integration（持續整合）和 Continuous Deployment（持續部署）。可以理解為一套幫你自動幹活的機器人系統。

在沒有 CI/CD 的時候。每次要發佈新功能。流程是這樣的：

打開電腦，登入 GitHub
拉取最新程式碼
執行測試，看看有沒有 bug
手動建置專案
登入伺服器
拉取最新程式碼
安裝相依性
建置專案
重啟服務

這 9 個步驟。每次發佈都要手動做一遍。煩不煩？而且很容易漏掉某一步。比如忘記執行測試、忘記重啟服務等。

有了 CI/CD 之後。流程變成了這樣：

把程式碼 push 到 GitHub
喝茶坐等 3.（機器人自動完成上面 9 個步驟）
網站自動更新了

1代码推送

→

2自动测试

→

3自动构建

→

4自动部署

手动部署

❌ 容易出错

 CI/CD 
 ✅ 快速可靠 

這就是 CI/CD 的魅力：只需要把程式碼推上去。剩下的全部自動完成。

7.2 CI/CD 的工作流程

一個典型的 CI/CD 流程是這樣的：

第一步：程式碼提交（Push）

完成了新功能的開發。把程式碼 push 到 GitHub。

第二步：CI（持續整合）觸發

GitHub 偵測到程式碼變動。通知 CI 系統（GitHub Actions、GitLab CI 等）開始工作。

第三步：安裝相依性和測試

CI 系統會啟動一台虛擬電腦。在上面：

安裝專案需要的各種相依性
執行測試程式碼，確保沒有 bug
建置專案，產生產物

如果測試失敗。CI 會發郵件通知。這次部署就停了。不會有問題的程式碼部署到正式環境。

第四步：CD（持續部署）執行

測試全部通過後。CI 系統會：

透過 SSH 連線到伺服器
拉取最新程式碼
安裝相依性
建置專案
重啟服務

整個過程可能只需要幾分鐘。全部自動完成。

7.3 怎麼設定 GitHub Actions？

GitHub Actions 是 GitHub 自帶的 CI/CD 功能。不需要額外付費（免費額度足夠個人專案用）。設定起來也非常簡單。

在專案根目錄下建立 .github/workflows/deploy.yml 檔案。寫入以下設定：

yaml

name: Deploy to Production

# 觸發條件：每當 main 分支有程式碼推送時
on:
  push:
    branches: [main]

# 任務清單
jobs:
  # 部署任務
  deploy:
    # 在什麼系統上執行
    runs-on: ubuntu-latest

    # 具體步驟
    steps:
      # 1. 檢出程式碼
      - name: Checkout code
        uses: actions/checkout@v3

      # 2. 安裝 Node.js 環境
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      # 3. 安裝相依性並建置
      - name: Install and Build
        run: |
          npm ci
          npm run build

      # 4. 部署到伺服器
      - name: Deploy to Server
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /var/www/my-website
            git pull origin main
            npm install
            npm run build
            pm2 restart all

這個設定檔告訴 GitHub Actions：

當 main 分支有新程式碼時觸發
在一台 Ubuntu 電腦上執行任務
先安裝 Node.js 18
然後安裝相依性並建置專案
最後透過 SSH 連線到伺服器，執行一系列部署指令

設定好之後。每次 git push origin main。GitHub 就會自動開始部署。非常方便。

8. 監控和日誌：做網站的「守夜人」

8.1 為什麼要監控？

網站上線後。理論上應該 7×24 小時不間斷執行。但現實世界沒有這麼美好。伺服器可能會當機。網路可能會抖動。程式碼可能會有 bug。在真實的正式環境中。各種意外情況都有可能發生。

如果沒有監控。就只能等使用者打電話告訴你「網站打不開了」。這時候往往已經晚了。使用者可能已經流失了。

有了監控之後。可以：

提前發現問題：CPU 使用率 90% 了。提前加伺服器。
快速定位問題：網站慢了。查監控看是哪裡瓶頸。
心裡有底：每天多少人存取、存取量什麼時候最高。

CPU 使用率45%

内存使用率62%

在线用户23

上次备份：

2024-01-15 14:30

8.2 監控哪些指標？

最重要的監控指標就這幾個：

指標	正常範圍	超過怎麼辦
CPU 使用率	< 70%	升級伺服器配置或最佳化程式碼
記憶體使用率	< 80%	檢查是否有記憶體洩漏
磁碟使用率	< 80%	清理日誌或無用檔案
網站可達性	100%	檢查服務是否正常執行
回應時間	< 2 秒	最佳化資料庫查詢或加快取
錯誤率	< 1%	查看錯誤日誌定位問題

8.3 怎麼設定監控？

最簡單的方案：Uptime Robot

註冊 uptimerobot.com。添加網站 URL。它會每 5 分鐘自動檢查一次網站是否正常。網站掛了會發郵件通知你。免費版本可以監控 50 個網站。對個人專案來說完全夠用。

進階方案：阿里雲/騰訊雲監控

如果伺服器是在阿里雲或騰訊雲買的。它們自帶監控功能。設定一下閾值警示就行。

專業方案：Prometheus + Grafana

這兩個是監控領域的「瑞士軍刀」。功能非常強大。可以監控任何能想到的指標。還能做出漂亮的視覺化圖表。不過設定起來比較複雜。適合有一定經驗的開發者。

8.4 日誌：出了問題怎麼查？

監控告訴你「網站出問題了」。但具體是什麼問題、為什麼出問題。需要靠日誌來定位。

日誌就是程式執行時的「日記本」。記錄了程式執行過程中的點點滴滴：

哪個使用者在什麼時候存取了什麼頁面
資料庫查詢花了多長時間
有沒有報錯，錯誤資訊是什麼

最基礎的日誌用法

在伺服器上查看應用日誌：

bash

# 查看 PM2 的日誌
pm2 logs

# 查看 Nginx 的存取日誌
tail -f /var/log/nginx/access.log

# 查看 Nginx 的錯誤日誌
tail -f /var/log/nginx/error.log

進階的日誌方案

如果專案比較複雜。推薦使用專業的日誌收集工具：

Loki：免費開源。和 Prometheus 一家的。
ELK（Elasticsearch + Logstash + Kibana）：功能強大。但設定複雜。
Sentry：專門用於收集應用錯誤的工具。能自動收集報錯資訊。

8.5 告警：出問題怎麼第一時間知道？

監控告訴你有問題。但如果沒有盯著監控面板看，怎麼辦？這就需要告警了。

告警就是當監控系統偵測到異常時。自動透過簡訊、微信、釘釘、郵件等方式通知你。可以設定不同的告警級別：

緊急（網站完全掛掉）：發簡訊+打電話。必須馬上知道。
嚴重（錯誤率飆升）：發釘釘/微信訊息。看到就處理。
一般（CPU 偏高）：發郵件彙總。一天看一次就行。

告警設定的核心原則是：分級告警，別把自己煩死。如果什麼雞毛蒜皮的小事都給你發簡訊。用不了多久你就會把告警關掉。

9. 常見問題速查表

問題現象	可能原因	解決方法
網站打不開	域名沒解析 / 伺服器掛了 / Nginx 沒啟動	`ping 域名` 看通不通；`pm2 list` 看服務狀態；`systemctl status nginx` 看 Nginx
打開是空白頁面	建置產物路徑不對 / 靜態檔案沒正確設定	檢查 Nginx 的 root 路徑是否指向 dist 目錄
404 頁面找不到	路由沒正確設定 / 路徑拼寫錯誤	Nginx 設定裡加上 `try_files $uri $uri/ /index.html`
502 Bad Gateway	後端服務掛了 / 連接埠沒開	`pm2 list` 看程序是否在執行；檢查連接埠是否正確
403 Forbidden	權限不對 / 索引目錄沒開	檢查檔案權限 `chmod -R 755`；Nginx 設定加上 `autoindex on`
HTTPS 憑證過期	憑證到期沒續期	`certbot renew` 手動續期；檢查自動續期排程任務
更新後看不到變化	瀏覽器快取 / CDN 快取	Ctrl+Shift+R 強制重新整理；去 CDN 控制台「重新整理快取」
網站打開很慢	頻寬不夠 / 沒開快取 / 沒設定 CDN	升級伺服器頻寬；設定 Redis 快取；接入 CDN
資料庫連不上	資料庫沒啟動 / 密碼錯了 / 權限問題	檢查資料庫服務狀態；核對設定裡的連線資訊

總結

服務上線是一個系統性的大工程。涉及從程式碼建置到伺服器部署、從網路設定到安全防護、從監控告警到日誌分析的方方面面。對於初學者來說。不需要一開始就追求完美。先把最小可用版本（MVP）跑起來。然後在此基礎上逐步完善。

整個流程的核心要點可以歸納為以下幾點：

核心流程

建置 → 用 npm run build 把程式碼變成瀏覽器能看懂的 HTML/CSS/JS
部署 → 把建置產物上傳到伺服器。用 Nginx 設定反向代理。
域名 → 購買域名並設定 DNS 解析到伺服器 IP
HTTPS → 用 Let's Encrypt 申請免費憑證。保護資料傳輸安全。
CI/CD → 設定自動化部署。程式碼 push 後自動上線。
監控 → 設定監控和告警。出問題第一時間知道。

學習路線建議

第 1 天：用 Vercel/Netlify 部署一個靜態網頁。體驗一下「程式碼變成網站」的感覺。
第 1 週：租一台雲端伺服器。手動部署一個 Node.js 專案。設定域名和 HTTPS。
第 2-4 週：設定完整的 CI/CD 流程。建立監控和告警體系。
持續學習：學習 Docker 容器化、學習 Kubernetes 叢集、學習微服務架構。

名詞速查表

名詞	英文	用白話解釋
建置	Build	把原始碼翻譯打包成瀏覽器能執行的格式
部署	Deploy	把程式碼放到伺服器上讓使用者能存取
伺服器	Server	7×24 小時不關機、聯網的電腦
域名	Domain	網站的好記名字（如 baidu.com）
DNS	Domain Name System	把域名翻譯成 IP 位址的「電話簿」
HTTP	HyperText Transfer Protocol	網頁傳輸協定（不安全，明文傳輸）
HTTPS	HTTP Secure	加密傳輸的網頁協定（安全）
Nginx	Engine X	高效能 Web 伺服器。做反向代理的。
反向代理	Reverse Proxy	站在門Global的服務員。把請求轉發給後端。
SSH	Secure Shell	遠端登入伺服器的加密工具
CDN	Content Delivery Network	全球分布的伺服器網路。加快存取速度。
CI/CD	Continuous Integration/Deployment	自動化流水線。程式碼 push 後自動測試部署。
SSL/TLS	Secure Sockets Layer / Transport Layer Security	加密協定。給 HTTPS 提供安全保障。
PM2	Process Manager 2	Node.js 程序管理器。讓應用持續執行。

CI/CD 自動化 ​

1. 為什麼要「服務上線」？ ​

2. 建置：把程式碼變成「可攜帶的包裹」 ​

2.1 為什麼要建置？ ​

2.2 建置具體做什麼？ ​

2.3 怎麼執行建置？ ​

2.4 建置產物裡有什麼？ ​

3. 伺服器：找一台永遠不關門的「房子」 ​

3.1 伺服器到底是什麼？ ​

3.2 怎麼選伺服器？ ​

3.3 國內還是國外？ ​

3.4 主流雲廠商對比 ​

3.5 拿到伺服器後該做什麼？ ​

4. 部署：把程式碼搬進「房子」 ​

4.1 部署是什麼？ ​

4.2 怎麼把程式碼上傳到伺服器？ ​

4.3 部署的具體步驟 ​

5. 域名和 DNS：給網站起個好名字 ​

5.1 為什麼要買域名？ ​

5.2 DNS 是什麼？ ​

5.3 怎麼設定 DNS？ ​

5.4 DNS 生效要多久？ ​

6. HTTPS：給網站裝一把「鎖」 ​

6.1 HTTP 和 HTTPS 的區別 ​

6.2 為什麼要 HTTPS？ ​

6.3 怎麼取得 HTTPS 憑證？ ​

6.4 設定 HTTPS 後發生了什麼變化？ ​

7. CI/CD：讓機器人幫你幹活 ​

7.1 什麼是 CI/CD？ ​

7.2 CI/CD 的工作流程 ​

7.3 怎麼設定 GitHub Actions？ ​

8. 監控和日誌：做網站的「守夜人」 ​

8.1 為什麼要監控？ ​

8.2 監控哪些指標？ ​

8.3 怎麼設定監控？ ​

8.4 日誌：出了問題怎麼查？ ​

8.5 告警：出問題怎麼第一時間知道？ ​

9. 常見問題速查表 ​

總結 ​

核心流程 ​

學習路線建議 ​

名詞速查表 ​

CI/CD 自動化

1. 為什麼要「服務上線」？

2. 建置：把程式碼變成「可攜帶的包裹」

2.1 為什麼要建置？

2.2 建置具體做什麼？

2.3 怎麼執行建置？

2.4 建置產物裡有什麼？

3. 伺服器：找一台永遠不關門的「房子」

3.1 伺服器到底是什麼？

3.2 怎麼選伺服器？

3.3 國內還是國外？

3.4 主流雲廠商對比

3.5 拿到伺服器後該做什麼？

4. 部署：把程式碼搬進「房子」

4.1 部署是什麼？

4.2 怎麼把程式碼上傳到伺服器？

4.3 部署的具體步驟

5. 域名和 DNS：給網站起個好名字

5.1 為什麼要買域名？

5.2 DNS 是什麼？

5.3 怎麼設定 DNS？

5.4 DNS 生效要多久？

6. HTTPS：給網站裝一把「鎖」

6.1 HTTP 和 HTTPS 的區別

6.2 為什麼要 HTTPS？

6.3 怎麼取得 HTTPS 憑證？

6.4 設定 HTTPS 後發生了什麼變化？

7. CI/CD：讓機器人幫你幹活

7.1 什麼是 CI/CD？

7.2 CI/CD 的工作流程

7.3 怎麼設定 GitHub Actions？

8. 監控和日誌：做網站的「守夜人」

8.1 為什麼要監控？

8.2 監控哪些指標？

8.3 怎麼設定監控？

8.4 日誌：出了問題怎麼查？

8.5 告警：出問題怎麼第一時間知道？

9. 常見問題速查表

總結

核心流程

學習路線建議

名詞速查表