軟體工程師，工作中常見縮寫 (一文搞懂 RFC、SEV、SLA 等名詞是什麼)

軟體開發團隊每天都在縮寫堆裡打滾，幾個字母就代表一段流程、一項原則或一份承諾。這份速查懶人包依情境分區整理，幫你在開會、寫文件或處理事故時能快速確認大家的語意一致；若想進一步延伸，也能透過文中的連結跳到更完整的解說。

在開發時常會聽到的縮寫

PR (Pull Request 拉取請求） PR 拉取請求，是指開發者把變更推到遠端，請別人拉下來看的請求。有些團隊或工具（例如 GitLab）會改稱 MR (Merge Request 合併請求），概念相同。在現代軟體開發，通常推到遠端後，會直接在 GitHub 這類工具中討論、給回饋 (俗稱 code review)，確認品質沒問後才會合併到主要分支。平常可能會聽到「我剛剛發了 PR，有空時幫我看一下」。關於如何做好 code review，可以參考《如何寫出更好的 Code Review 指南》。

CL (Change List 變更清單） CL 變更清單，是另一種描述程式碼變更集合的說法，常見於 Google 等公司。概念上與 PR 類似，工程師提交 CL，請其他人針對每個更動給回饋。另外，有些工具會用 MR (Merge Request 合併請求)，來描述同一件事。所以看到 PR、CL、MR，基本上都是講同個概念，只是用詞些微不同。

WIP (Work In Progress 開發中） WIP 開發中，通常會寫在分支或 PR 標題開頭，提醒大家「還沒完成，先別 review」，就像實體生活會看到工地入口掛著「施工中」的警示牌一樣。平常可能在 Slack 聽到「這個 PR 我先標 WIP，補完文件後再 review」。

TDD (Test-Driven Development 測試驅動開發） TDD 測試驅動開發是一種開發方式，具體來說會先寫測試，再寫最小量程式碼讓測試通過，最後重構並確保測試維持通過。想更了解 TDD 流程細節可以參考《測試驅動開發是什麼？》。

CI/CD (Continuous Integration / Continuous Deployment 持續整合 / 持續部署） CI/CD 持續整合 / 持續部署，是把整合、測試、部署串成自動化的形式。程式碼合併後，系統會自動編譯、跑測試、打包並部署到對應環境，讓團隊一天可以多次部署。這不僅降低人為失誤，也讓每次上線的變更範圍變小，詳細可參考《CI / CD 是什麼？》。平常可能會聽到「你這個 PR 的 CI 沒跑過，要不要檢查一下哪邊出問題了」。

OSS (Open Source Software 開源軟體） OSS 開源軟體指原始碼公開、人人都能使用與貢獻的軟體；想看開源如何改變公司思維，可以參考《TypeScript 紀錄片心得 — 開創微軟的開源之路》。平常可能會聽到「這個功能要不要看有沒有 OSS 套件可以用，不用自己造輪子」。

出事故時會聽到的縮寫

SEV 1 / SEV 2 / SEV 3 (Severity Level 嚴重性等級） SEV 代表 Severity（嚴重程度），數字越小表示越嚴重。SEV 1 通常是全服務停擺、金流失敗這種必須立刻動員的狀況；SEV 2 可能是影響大量使用者但仍有替代方案的錯誤；SEV 3 則屬於局部問題瑕疵。清楚分級能幫助 on-call 團隊在壓力下迅速判斷應對策略。當班工程師會喊：「這起事故是 SEV-1，大家趕快進 war room」。

P0 / P1 / P2 (Priority 優先順序） P 是 Priority 的縮寫，代表任務優先度。一般來說 P0 是最重要的項目，團隊會把資源集中在這裡；有些公司還會加上一層 P00，保留給突發的、必須中斷所有事情立即處理的緊急任務。P1、P2、P3 則依序往下，處理時間可以依照計畫排程。想了解事故分級與輪值實務，可以參考《軟體工程師該如何做好監控》。同步會議上會聽到「這個 bug 先列 P0，解掉之前其他需求暫緩開發」。

ETA (Estimated Time of Arrival 預計完成時間） ETA 就是工程師常被問的「這東西什麼時候會好？」。假如出 bug 時，持續更新 ETA 能讓客服、營運與產品掌握進度，也能降低猜測與焦慮。即便需要調整，只要說明最新判斷依據，大家仍然感受得到團隊在掌控狀況。常見回覆會是「目前 ETA 暫定下午三點，有變動的話會再更新」。

MTTR (Mean Time To Recovery 平均修復時間） MTTR 用來衡量系統出問題後平均要花多久才恢復正常。要縮短 MTTR，需要好的事故流程，我們在《觀測性為什麼重要》裡整理了常用的指標與工具，協助團隊找出瓶頸。事故檢討時會說：「這季事故的 MTTR 控在 25 分鐘內，但還有一些空間能再縮短」。

MTBF (Mean Time Between Failures 平均故障間隔時間） MTBF 則是站在另一個角度，觀察系統多久會再次出問題。數字越大表示越穩定，可能是程式品質提升、監控更全面或架構更有彈性。把 MTBF 與 MTTR 搭配觀察，可以看出團隊是忙著救火，還是真正降低事故發生率。技術回顧會討論可能會聽到「新架構順利讓 MTBF 拉到六個月，感謝大家辛苦的付出」。

談服務品質時會用的縮寫

SLA (Service Level Agreement 服務等級協議） SLA 是對外的正式承諾，寫在合約裡，通常涵蓋可用率、回應時間與賠償條款。當你說服務提供 99.9% 的 uptime，就等於服務在一年停機不能超過 8 小時 45 分鐘。通常如果沒達到 SLA 規定的，就會需要做出相對應的賠償。SLA 可說是公司與客戶建立信任的地基，因此可能常會聽到客服問「依照 SLA，我們需要在 30 分鐘內回覆，請讓我知道要怎麼回」。

SLO (Service Level Objective 服務等級目標） SLO 是團隊內部設定的目標，通常會比對外宣稱的 SLA 更嚴格，留下一點緩衝。例如對外保證 99.9%，但內部自我要求 99.95%，即便偶發事件讓指標掉了一點，也不至於馬上違約。因此可能會聽到工程經理說「這季 SLO 設 99.95%，大家多留意一下，不能再出事故了」。

SLI (Service Level Indicator 服務水準指標） SLI 是具體的量測數據，例如 API 成功率、95 百分位延遲或報表生成時間。沒有明確且能量測的 SLI，SLA 和 SLO 就成了空談。因此可靠性工程師會把 SLI 與監控儀表板串起來，指標偏離時能即時收到警訊。值班訊息裡可能會看到「目前登入的 SLI 掉到 98%，警報響了，請立刻查看」。

團隊文化與溝通常用縮寫

RFC (Request For Comments 意見徵求文件） RFC 用來提出新設計或重大變更，寫 RFC 的人會在文件裡說明背景、問題與提議，然後邀請團隊回饋。透過書面或口頭討論，決策過程會在這份文件中留下紀錄，避免造成重要決策資訊在未來找不到。因此，可能會看到有人說「我為這次的改版技術設計寫了一份 RFC，請大家在週五前給回饋」。

ADR (Architecture Decision Record 架構決策紀錄） ADR 用來紀錄重要技術決策的背景與理由。如果沒紀錄，很常會出現過幾個月後有人問「為什麼當初選 XXX 而不是 XXX？」，結果沒人能回答。ADR 也能用來幫助新成員快速補齊脈絡，避免團隊在同樣的討論上反覆打轉。

TL;DR (Too Long; Didn’t Read 太長不想看） TL;DR 是訊息太長時會用的重點摘要，讓忙碌的同事先掌握結論，再決定要不要深入細節。常見訊息會寫「TL;DR：我們決定延後發布一週」，再接著把細節展開。

FYI (For Your Information 僅供參考） FYI 會用來補充某個資訊，表示訊息不一定需要回覆或行動，但對方應該要掌握這個資訊。分享第三方公告、提醒即將到來的維運通知或同步決策結果時都很常見，例如「FYI，今晚 11 點會有系統維護」。

IMO / IMHO (In My Opinion / In My Humble Opinion 我的觀點是...） IMO 與 IMHO 都是表達個人觀點的開場白，IMHO 加上 humble，所以講起來比較有謙虛的感覺。這個開頭能讓討論保持友善，讓其他人知道這只是個人觀點，歡迎提問或反駁。

LGTM (Looks Good To Me 看起來沒問題） LGTM 是當看完別人提交的內容，不論是技術設計文件，或者是 PR 當中的程式碼，如果覺得沒問題，就會留下 LGTM。不過這個詞得小心使用，避免出現這個影片的狀況 XDDD