软件工程师，工作中常见缩写 (一文搞懂 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