今天要來聊聊 DevOps 裡面的一些… 嗯，該說是小技巧嗎？我自己是覺得，它們更像是一種「工作習慣」的優化啦。老實說，你是不是也常常覺得，每天都在打一堆重複到不行的指令？什麼 `kubectl get pods`、`git status`、`docker-compose up`… 一天下來，光是敲這些字，手都快抽筋了。
然後你好不容易把事情做完，三個月後遇到一樣的問題，欸，結果完全忘記上次是怎麼解的。又要重頭再來一次。這些鳥事累積起來，真的超級浪費時間。所以今天想來分享幾個，我自己覺得投資報酬率超高的小撇步，真的，只要花你幾分鐘設定一下，每個禮拜省下來的時間絕對不止一兩個小時。
先說結論
簡單講，就是把所有「重複」而且「不用動腦」的工作，全部自動化或簡化。不管是打指令、設定環境，還是跑測試。目標就是把你的腦力跟時間，從這些雜事中解放出來，拿去做真正需要思考、有創造力的事情。這才是 DevOps 精神的核心啊，對吧？持續改善，不只改善系統，也改善你自己的工作流程。
怎麼做？這幾個小技巧你一定要試試
OK，我們一個一個來看。這些東西沒有順序之分，你看哪個最戳中你的痛點，就先從哪個開始。我自己是覺得，第一個 `alias` 絕對是必備款。
用指令別名 (Alias) 把長指令變魔術
這個… 我真的覺得沒用的人太可惜了。你知道嗎，像 `kubectl` 這麼長的指令，你每天要打幾十次？每次都要完整敲完 `k-u-b-e-c-t-l`，你不累嗎？
只要在你電腦的 shell 設定檔（通常是 `.bashrc` 或 `.zshrc`）裡面加一行字，事情就解決了。
# 打開你的 .bashrc 或 .zshrc 檔案，加上這幾行
alias k='kubectl'
alias g='git'
alias tf='terraform'
alias dc='docker-compose'加完之後，記得跑 `source ~/.bashrc` (或 `.zshrc`) 讓它生效。從此以後，你要查 Pods，就只要打 `k get pods`，結束。你要看 git 狀態，打 `g status` 就好。這真的… 省下來的時間跟力氣超乎你想像，投資報酬率破表。
用 SSH Config 管理你的遠端主機
如果你跟我一樣，常常要連到不同的伺服器，一下是 staging、一下是 production、一下又是某個客戶的機器… 那你一定懂那個痛苦。要記一堆 IP 位址、不同的使用者名稱，有時候還要指定特定的 key file。超煩。
其實 SSH 本身就有一個超好用的設定檔可以解決這個問題。你只要在 `~/.ssh/config` 這個檔案裡，把你的主機都定義好。
# 檔案位置在 ~/.ssh/config (如果沒有就自己建一個)
Host prod-web
HostName 203.0.113.10
User admin
IdentityFile ~/.ssh/prod_key
Host stage-db
HostName 198.51.100.20
User dbadmin
IdentityFile ~/.ssh/stage_key設定好之後，未來你要連線，就不用再打那一長串 `ssh admin@203.0.113.10 -i ~/.ssh/prod_key` 了，直接打 `ssh prod-web` 就搞定。腦袋可以空出來記更重要的事。
用 Shell Script 把一連串動作包起來
Alias 解決的是「單一指令」的簡化，但很多時候，我們的工作是一套「組合技」。比如說部署（deploy）一個專案，你可能要做：`git pull` 拉最新程式碼、`npm install` 裝套件、`npm run build` 編譯、最後再 `pm2 restart app` 重啟服務。每次都手動一步一步打，超容易漏掉或打錯。
這時候就該輪到 Shell Script 上場了。你可以在專案裡開個 `scripts` 資料夾，寫一個 `deploy.sh`：
#!/bin/bash
# deploy.sh - 一個簡單的部署腳本
echo "=== 開始部署程序 ==="
git pull
npm install
npm run build
pm2 restart app
echo "=== 部署完成！ ==="記得要給它執行的權限 `chmod +x scripts/deploy.sh`。之後，每次要部署，只要執行 `./scripts/deploy.sh` 這一行指令，它就會自動幫你把所有事情做完。這不只省事，更重要的是「標準化」，確保每次部署的流程都一模一樣。
用 Git Hooks 在 commit 前自動檢查
這個技巧稍微進階一點，但超級、超級實用。你有沒有過這種經驗：commit 程式碼之後，CI/CD pipeline 才跟你說測試沒過，或者是有個地方格式跑掉了，結果還要再修一次、再 commit 一次？
Git Hooks 就是用來防止這種蠢事的。它讓你在 `git commit` 這個動作發生「之前」，先自動幫你跑一些檢查。
最常見的就是 `pre-commit` hook。你可以在專案的 `.git/hooks/` 目錄下，建立一個叫做 `pre-commit` 的檔案，內容大概長這樣：
#!/bin/bash
echo "正在執行 commit 前的<a href="https://www.pineymountain.com/tw/article/227/automate-python-notion-sync" target="_blank" class="blogHightLight_css nobox">自動化測試</a>..."
npm test
# 檢查上一個指令 (npm test) 的回傳值
# 如果不是 0 (代表有錯誤)，就中斷 commit
if [ $? -ne 0 ]; then
echo "測試失敗！Commit 已被中斷。"
exit 1
fi同樣，要記得 `chmod +x .git/hooks/pre-commit`。這樣設定好之後，每次你 `git commit`，它就會先跑 `npm test`。如果測試失敗，commit 就會直接被擋下來，你連推上 remote 的機會都沒有。這可以確保進到版本庫裡面的程式碼，至少都有最基本的品質。
用 Docker 統一大家的開發環境
啊… 「在我電腦上可以跑啊！」這句話，大概是工程師協作的惡夢排名前三名。新同事來，光是搞定他電腦上的開發環境就要花掉半天甚至一天，一下是 Node.js 版本不對，一下是缺了某個系統套件…
Docker 基本上就是為了解決這個問題而生的。它把你整個應用程式需要的環境，包括作業系統、資料庫、各種服務，全部打包成一個標準化的「容器」。
你只要在專案裡寫好 `Dockerfile` 和 `docker-compose.yml`，團隊裡的每個人，不管他用 Mac 還是 Windows，只要電腦裡有裝 Docker，進到專案目錄，一行 `docker-compose up`，整個開發環境就跑起來了。完全一模一樣，再也不會有「在我電腦可以跑」的問題。
用 Makefile 當作專案的「公開說明書」
說真的，我一開始也覺得 Makefile 有點多此一舉，有 Shell Script 不就好了嗎？後來才慢慢體會到它的好處。
Makefile 有點像是一個專案的「標準指令集」或「公開說明書」。不管這個專案是用 Node.js、Python 還是 Go 寫的，啟動測試的指令可能是 `npm test`、`pytest` 或 `go test`。新人哪知道要用哪個？
但如果有了 Makefile，大家就有了共同語言：
# Makefile
.PHONY: setup test build deploy
setup: # 安裝專案需要的套件
npm install
test: # 跑所有自動化測試
npm test
build: # 編譯打包應用程式
npm run build
deploy: # 部署到正式環境
./scripts/deploy.sh任何人拿到這個專案，不用去看一堆文件，只要在終端機打 `make`，就會看到所有可用的指令。他想跑測試，就打 `make test`；想部署，就打 `make deploy`。他根本不需要知道底層是用 npm 還是別的什麼工具。這對團隊協作、降低新成員上手門檻來說，真的超重要。
這些技巧的影響，不只是省時間而已
講了這麼多，你可能會覺得這些都只是個人的小聰明。但其實，當整個團隊都開始用這些方法時，威力才會真正顯現出來。我整理了一個簡單的比較，你看完會更有感覺。
| 技巧 | 設定難度 / 時間 | 個人省時效果 | 對團隊的影響 |
|---|---|---|---|
| 指令別名 (Alias) | 超低，大概 1 分鐘 | 每天省下敲鍵盤的時間，爽度高 | 比較偏個人。但如果團隊分享好用的 alias，也能加速大家工作。 |
| Git Hooks | 中等，要會寫點 script | 避免掉 commit 後才發現的低級錯誤，省下修補的時間跟心力。 | 超重要！可以統一程式碼品質的底線，減少 code review 時花在檢查格式、語法這種小事上的時間。 |
| Makefile | 低，語法很簡單 | 不用再記每個專案的特定指令。 | 根本是團隊的福音。新人來，只要教他 `make` 就好。大家對專案的操作有了共同語言。 |
| Docker 環境 | 偏高，第一次設定會花點時間 | 一次設定好，之後換電腦、開新專案都超快。 | 徹底解決「在我電腦上可以跑」的問題。確保每個人的開發、測試環境都一致，大幅減少溝通成本。 |
| 知識庫 (Knowledge Base) | 看個人習慣，用 Obsidian 或 Notion 都很快 | 未來的你會感謝現在的你。解決過的 bug 不用再解第二次。 | 如果變成團隊共享的知識庫... 哇，那價值就更高了。等於是團隊的第二大腦。 |
風險與誤解釐清
不過呢，這些東西也不是萬靈丹，用過頭或用錯地方也是會有問題的。
比如說 `alias`，你設了一大堆奇奇怪怪的別名，結果一個月後你自己都忘記 `abc` 是代表哪個指令。或者更慘的，你把別名設成跟系統內建指令一樣，像是 `alias ls='ls -al'`，雖然很方便，但當你到一台沒有這樣設定的機器上時，你的肌肉記憶就會讓你很痛苦。所以，alias 最好只用在那些超長、超常用的指令上。
還有 `script`，原本是想簡化流程，結果你寫了一個上百行的超複雜腳本，裡面還有一堆判斷式跟邏輯。那這個腳本本身就變成另一個需要花心力去維護的「專案」了，有點本末倒置。
重點是要抓到那個平衡點：讓工具服務你，而不是讓你變成工具的奴隸。
不只國外，台灣團隊也能這樣玩
說到自動化跟標準化，很多很棒的觀念其實都可以從一些國際級的文件裡學到，像是 GitLab DevOps Handbook，裡面就把他們的企業文化跟工作流程寫得超詳細，根本是公開的武功秘笈。他們對於 CI/CD 流程 的要求跟想法，就很值得參考。
不過，工具的選擇上，就不一定要完全照抄。我自己觀察，在台灣，很多團隊的工作流程跟國外有點不一樣。例如，國外很多團隊的 CI/CD 通知會串到 Slack，但在台灣，我發現大家可能更習慣把通知接到 Telegram 或是 LINE Notify 上。這沒什麼對錯，重點是那個「即時回饋」的精神有做到就好。
又或者，在知識共享這塊，國外可能流行用 Confluence，但在台灣的開發者社群，我看到更多人用 Notion、HackMD，或是像我一樣用 Obsidian 做個人筆記。工具是其次，有沒有建立起「把經驗記錄下來」的習慣，那才是最重要的。很多時候，在 iThome 鐵人賽或是一些技術部落格上，反而能找到更貼近我們在地開發場景的解法。
所以我的建議是，觀念可以學國外的最佳實踐，但工具跟實作方法，一定要找最適合自己團隊的。不要為了用而用。
總之，今天分享的這些，都只是些開胃菜。DevOps 的世界還很大，但精神都是一樣的：不斷尋找可以更好的地方，然後動手去改善它。哪怕只是改一個小小的 script，或是設定一個 alias，長期下來，都會對你的工作效率和…嗯，工作心情，有很大的幫助。
好了，說了這麼多。你平常最常用哪個小技巧？或是有什麼我沒提到的私房秘技，是你的壓箱寶？在下面留言分享一下，大家交流交流吧！
