DevOps／SRE 工程師的英文履歷怎麼寫
更新於 2026-09-02
DevOps 與 SRE 的履歷，證據只有一種：什麼東西因為你而不再壞。部署頻率升了多少、MTTR 降了多少、on-call 一週從被叫醒 [N] 次變成 [N] 次，這就是這個職位的成績單。工具鏈只是背景。看履歷的人想知道：系統交到你手上之後，曲線往哪個方向走。
這個職位的履歷最常死在兩個地方：用認證清單冒充經歷，以及「managed AWS」這種沒有爆炸半徑的句子。幾個帳號、幾個 region、多少預算、你出錯誰遭殃？寫不出這些，「管理」只證明你登入過 console。本頁所有範例皆為英文，因為外商履歷的成品語言是英文。數字一律留 [N]，因為那些數字要由你自己在面試裡守住，尤其是被要求「把你最嚴重的事故一分鐘一分鐘講一遍」的時候。
以下依序是版面結構、三個層級的 summary、依職能分組的 bullet、改寫前後對照、技能區取捨、ATS 關鍵字、常見錯誤，以及每句主張會招來的追問。
這個職位的英文履歷，完成後長這樣
下面是一份虛構人物的完整範例，由產品的排版引擎渲染成真正的頁面，分數由同一套規則引擎現算——不是我們打上去的。缺的數字一律留 [N]，所以分數停在上限以下；那不是範例的缺陷，是產品的規則在示範。
Aisha Bello
Education
- Founded the campus Linux user group and ran [N] hands-on workshops a semester, keeping the department’s teaching cluster patched between terms
- Delivered a final-year project on automated failover for that cluster, publishing its Ansible roles, which the next lab administrator kept in use
Experience
- Increased deployment frequency from [N] a week to [N] a day by moving [N] services onto GitOps
- Cut mean time to recovery from [N] minutes to [N] minutes with runbook automation triggered by alerts
- Saved [N] million naira a year in cloud spend through rightsizing and spot-instance policies, verified against the finance team’s monthly bill
- Migrated [N] customer workloads from hand-built VMs to Terraform-managed Kubernetes, losing no data
- Built one logging and metrics stack in place of [N] tools, handling [N] billion log lines a month
- Halved provisioning time for a customer environment by codifying its [N]-step checklist as one pipeline
- Resolved [N] thousand first-line faults on a rotating night shift, closing [N]% of them straight from the runbook without waking a senior engineer
- Deployed monitoring checks across [N] thousand subscriber links, giving the operations centre its first per-region view of packet loss
- Automated nightly backup checks on [N] edge routers, returning [N] hours a week to the night shift
Projects
- Developed an open-source per-namespace cost report for Kubernetes used by [N] organisations
- Created a bot that reconstructs an incident timeline from alert and chat history, cutting the on-call lead’s write-up from [N] hours to [N] minutes
Additional Information
版面結構與順序
單欄、標準標題、純文字。你天天跟 parser 打交道，別讓自己的履歷敗在被 ATS 讀不懂。雙欄版面會把不相干的兩行併成一句，圖示與技能條在解析器眼裡是空白。
排序原則：可靠性的證據優先。Experience 是主體，Certifications 壓縮到頁尾一行。認證幫你通過關鍵字篩選，但撐不過任何一輪面試。
- 1Summary
三句話：層級、平台規模、你最敢被追問的一條可靠性數字。看的人用這段決定要不要往下讀。
- 2Experience
倒序。每段三到五條 bullet，動詞開頭、有爆炸半徑、有 [N] 的趨勢變化。事故與自動化的證據都放在這裡。
- 3Skills
按平台、交付、可觀測性分組的關鍵字表。只列出過事時你實際上場處理過的工具。
- 4Certifications
一行，只留最高與最相關的一張。它的功能是通過篩選，僅此而已。
- 5Education
有工作經歷後放最後、一到兩行。新鮮人可前移，附相關專題。
三個層級的 Summary 範例
Summary 是你可靠性紀錄的預告。三個層級各一例，數字留 [N] 由你自己填。
Site reliability engineer with internship experience operating Kubernetes workloads and writing Terraform for a [N]-service platform. Turned a manual release checklist into a pipeline stage and wrote the timelines for [N] production incidents as a shadow on-call. Looking for a rotation where on-call comes with real ownership and blameless postmortems.
新鮮人不必假裝救過火。跟班 on-call、把 checklist 自動化成 pipeline stage，這些是真實可查的起點，比「熟悉 DevOps 文化」有力得多。
DevOps engineer with [N] years running CI/CD, Kubernetes, and AWS for product teams shipping [N] times a day. Rebuilt alerting around SLOs, cutting pages per week from [N] to [N], and keeps [N]% of infrastructure in Terraform. The first person engineers call when production misbehaves.
中生代的訊號是被信任的程度：工程師出事先找你，代表你是事實上的維運中樞。三個數字各自可被追問，比堆滿工具名稱可信。
Senior SRE setting reliability standards for [N] services across [N] engineering teams. Commanded the company’s largest incidents, moved error budgets into quarterly planning, and cut [$N] a year in cloud spend without a reliability regression. Treats recurring toil as a defect and closes it with automation.
資深的證據是制度性的：error budget 進了規劃流程、事故指揮是你、省成本沒有犧牲可靠性。整段沒有一個自我評價的形容詞。
依職能分組的 bullet 範例
這個職位的 bullet 要能回答同一個問題：交給你之後，哪條曲線動了。骨架不變：動詞、範圍、方法、[N] 的變化。
事故處理與復原
· Ran incident command for a [N]-hour multi-region outage, coordinating [N] teams and shipping a postmortem with [N] action items, all closed within one quarter.
· Cut mean time to recovery from [N] minutes to [N] minutes by wiring rollback to error-budget burn alerts instead of waiting for human diagnosis.
· Rewrote runbooks for the [N] most-paged services after failure drills, so a first-shift engineer resolved the next SEV-2 without paging a senior.
部署管線與發布安全
· Moved [N] services from ticket-driven releases to GitOps, raising deploy frequency from weekly to [N] per day with rollback on failed health checks.
· Cut CI pipeline time from [N] minutes to [N] minutes by caching dependencies and sharding the test suite across [N] parallel runners.
· Introduced staged rollouts gated on error rate, so a bad release now reaches [N]% of traffic instead of every user at once.
基礎設施即程式碼
· Codified [N] hand-built environments into Terraform modules, putting [N]% of infrastructure behind code review with nightly drift detection.
· Replaced [N] per-team Kubernetes configurations with one paved-path Helm chart, cutting new-service setup from [N] days to [N] minutes.
· Rebuilt disaster recovery as code and ran quarterly restore drills, cutting tested database recovery time from [N] hours to [N] minutes.
可觀測性與告警品質
· Deleted [N] noisy alerts and rebuilt the rest on SLO burn rates, cutting pages per on-call week from [N] to [N] with no missed SEV-1.
· Instrumented [N] services with distributed tracing, cutting the time to locate a failing dependency during incidents from [N] minutes to [N] minutes.
苦工自動化與成本
· Automated certificate rotation, database credential issuance, and log archival, returning [N] hours per week of manual work to a [N]-engineer platform team.
· Cut the monthly cloud bill by [$N] by moving batch workloads to spot instances and scaling on live traffic instead of provisioned peak.
· Built a self-service tool that lets product engineers create and destroy staging stacks without filing tickets, absorbing [N] requests per month.
改寫前後對照
同一段維運經歷的弱寫法與強寫法。記住 why 裡指出的缺陷，比背改寫更有用。
Managed AWS infrastructure for the company.
Ran the AWS estate for a [N]-service platform ([N] accounts across [N] regions), owning IAM boundaries, network topology, and a [$N] monthly budget.
差在哪 · 「Managed AWS」沒有爆炸半徑：幾個帳號、你動錯什麼會壞、誰受影響，全部看不見。改寫給出範圍、邊界與預算，每一項都可被追問。
Responsible for monitoring and alerting across all services.
Rebuilt alerting for [N] services on SLO burn rates, cutting pages per on-call week from [N] to [N] while catching every SEV-1 that quarter.
差在哪 · 監控是活動，不算結果。告警系統的成績單只有兩個數字：一週被叫幾次、漏掉幾次真事故。改寫把兩個都給了。
Handled deployments and maintained CI/CD pipelines.
Rebuilt the release path so any engineer ships through one pipeline: [N] deploys a day, median rollback in [N] minutes, change failure rate under [N]%.
差在哪 · 「Handled」是看門人的語言，看不出系統因你而變快或變安全。改寫攤開交付系統的吞吐量、回滾速度與失敗率。三個數字一起動，故事才完整。
Used Docker, Kubernetes, Terraform, Ansible, Prometheus, and Grafana in daily work.
Codified [N] hand-managed servers with Terraform and Ansible, moved the workloads onto Kubernetes, and handed each team Prometheus alerts they own.
差在哪 · 工具清單沒有敘事。改寫把同一批工具串成一次遷移：程式碼化、搬遷、告警交還團隊。工具因為故事才有意義。
Improved system stability and reduced downtime.
Raised availability of the checkout path from [N] to [N] nines by adding multi-AZ failover and load shedding at the API gateway.
差在哪 · 「用改善穩定性來減少停機」是循環論證，什麼都沒說。改寫指名路徑、給出前後的 9、講出機制，可以驗證，也可以追問。
技能區怎麼取捨
篩選原則：出過事、你有份處理的才算會。只看過文件的工具寫上去，等於預約一題答不出來的面試題。
值得佔版面的
AWS · GCP · Kubernetes · Docker
Terraform · Helm · Argo CD · GitHub Actions
Prometheus · Grafana · OpenTelemetry · PagerDuty · incident command
Python · Go · Bash
可以刪掉的
- 一整排認證（AWS SAA、CKA、CKAD⋯） · 認證只通得過關鍵字篩選，通不過面試。留最高、最相關的一張，一行帶過，版面還給事故與自動化的證據。
- Linux · 這個職位的 Linux 是前提，單獨列出像工程師列「會打字」。要證明深度，用一條核心參數調校或除錯的 bullet。
- 看過儀表板的每套監控工具（Datadog、New Relic、Zabbix、Nagios⋯） · 面試官會挑一套問你怎麼設計告警。留你實際建過告警的那套，其餘刪掉。
- 「DevOps culture」或「cross-team communication」 · 文化不是技能欄位的詞條。你推動過 blameless postmortem，就寫成一條有 [N] 的 bullet。
ATS 關鍵字
Parser 先比對字串，人才讀故事。以下是這個職位的 JD 最常出現、也最常被比對的詞，按類別分組。
只放你的經歷撐得起的詞：被追問時答不出來，比空白更傷。堆關鍵字不會讓 parser 多給分，在人眼裡只是雜訊。
認證編號，與看不見的基礎設施
這個職位的證據分兩種。一種可以查：認證有編號，編號會查到一筆有等級、有日期的紀錄。另一種在 VPN 後面，永遠不會有連結，你也被合約綁著不能給。兩種都要在履歷上有一行，寫法完全不同。
- 認證寫編號，不只寫名字
CKA、CKS、AWS Certified DevOps Engineer – Professional、HashiCorp Terraform Associate，每一張都會發一組可查的編號，多數還附一個 Credly badge 的網址。履歷上就寫完整：「Certified Kubernetes Administrator — Linux Foundation, ID [N], expires [Month YYYY]」。只寫名字是主張，補上編號才是紀錄，而且對方查證只是貼上去的動作。
- 到期日自己寫，別讓對方去發現
Kubernetes 與 AWS 的認證都會失效。一張去年就過期、卻寫得像現在有效的證書，是整份文件裡最容易被抓到的一項——查證頁面會直接印出 expired。還在考的寫「CKA — exam booked for [Month YYYY]」，不要掛著「in progress」掛兩年。過期又不打算重考，就整行刪掉；沒有人會問一張從來沒出現過的證書。
- 名字對不上，查證就等於查無此人
發證單位存的是你報名時填的那個英文姓名。履歷上如果換了拼法、或用了後來改的名字，招募人員貼上編號會查到空白，而空白在他眼裡跟造假沒有分別。送出前自己查一次：查證頁面顯示的姓名、等級、到期日，要跟履歷那一行逐字相同。最常出錯的是等級——把 Associate 寫成 Professional，一次點擊就穿幫。
- 這個職位的 GitHub，看的不是綠色方格
對方打開的順序通常是：先貼認證編號查一次，再點 GitHub，最後才讀你的 bullet。到了 GitHub 他不是在數 commit。他看你 pin 了什麼：一個 Terraform module、一張 Helm chart、一支 exporter、一個 operator，以及 README 有沒有講清楚它在哪種情況下會壞。更強的一種是上游的 merged PR——你天天維運的那個 ingress controller、那個 Terraform provider，你送的修正被合併，連結永久存在，還附著整串 review 紀錄。
- 沒東西可看的時候，連結不要放
一個最新動態是兩年前 fork 的 profile，比沒有 profile 更傷：對方本來只是不知道，現在他知道了。要放就放一個真的在跑的東西——你家裡那台機器上的叢集設定 repo，README 直接寫成 runbook：開機順序、憑證怎麼輪替、跳電之後怎麼還原。規模小不要緊，這個職位看的是紀律，不是流量。
- NDA 底下的基礎設施，指向形狀而不是內容
你維運過的東西大多在 VPN 後面，不會有網址，這很正常，履歷不必為此道歉。還是有三樣東西可以帶出公司：把 postmortem 去掉公司名、產品名與所有數字之後，重寫成一篇談失敗模式的文章；把架構重畫成通用版本；把內部工具可公開的那一層抽出來開源。履歷上那一行只寫真實範圍，公司用產業描述代替——「Ran the Kubernetes estate for a [N]-cluster payments platform」——細節留到面試裡一分鐘一分鐘講。
- 講過的那一場，是一個有日期的連結
你把一次事故或一次遷移講給人聽過——公司內部的技術分享、在地的 Kubernetes meetup、或 SREcon 這類研討會——就會留下投影片或錄影，附著主辦單位與年份。它證明的是你那套敘事在跑同一套 stack 的同行面前站得住。放在該段經歷底下一行就好：講題、場合、年份、連結，不必為它另開一個章節。
DevOps／SRE 履歷的常見錯誤
- 1把認證清單當成經歷
認證證明你讀過書，事故證明你上過場，面試考的是後者。認證留一行，版面讓給你救回來的系統。
- 2「Managed AWS」沒有爆炸半徑
看不出幾個帳號、多少預算、你出錯誰遭殃。範圍寫不出來，「管理」就只是登入過 console。
- 3整份履歷只有工具鏈，沒有變好的曲線
這個職位的成績單是趨勢：部署頻率升、MTTR 降、page 變少。工具只是手段，寫滿工具而沒有一條曲線在動，等於沒有成績。
- 4把告警數量當成就
「建立 [N] 條告警」是成本，不算成果。告警系統的指標是誤報率與漏報數：一週被叫醒幾次、漏了幾次真事故。
- 5事故經歷完全留白
沒有任何事故痕跡的維運履歷，讀起來像你沒被信任過 on-call。指揮過的事故是這個職位最強的材料。寫復原與預防，別寫戰犯。
- 6可用性數字與架構對不上
寫 [N] 個 9 之前先換算：那代表一年只能停 [N] 分鐘。單區單機的架構配上五個 9，面試官做一次除法就能戳破。
每句主張會招來的追問
可靠性數字是最容易被驗算的主張。寫上去之前先想：對方拿著計算機追問三層，你守得住嗎。
Reduced MTTR from [N] minutes to [N] minutes.
計時從哪一刻開始：告警觸發、有人認領，還是使用者開始受影響？你算的是平均還是中位數？
講得出定義與資料來源。一次超長的事故就能拉爆平均值；若你用中位數，先說明為什麼，並準備好原始的事故清單。
Led incident response for the platform’s largest outage.
把那次事故從第一個告警開始，一分鐘一分鐘講一遍。你在哪個時間點走錯了方向？
這是這個職位的招牌考題。時間軸要能背出來：第一個訊號、錯誤假設、改判的依據、對外溝通、事後改了什麼。沒有走錯方向的版本不會被相信。
Achieved [N] nines of availability.
[N] 個 9 等於一年只能停 [N] 分鐘。這是從哪裡量的？合成監測還是真實流量？維護視窗算不算停機？
面試前自己先做完換算，再確認量測點與排除條款。答不出那一年的 error budget 花在哪裡，數字就會被當成行銷。
Managed infrastructure as code with Terraform.
State 存在哪裡？兩個人同時 apply 會發生什麼？上一次發現 drift 是什麼時候、怎麼發現的？
這三題分開「寫過 HCL」與「營運過 IaC」。要能講出 state 後端、鎖機制與 drift 偵測的實際配置，外加一次真實的 drift 事件。
Raised deploy frequency from weekly to [N] per day.
頻率上升之後，change failure rate 跟著怎麼動？rollback 是誰有權限按、多久生效？
交付指標要一起看。頻率升而失敗率不明，故事只講了一半。準備同期的失敗率、回滾時間，以及一次真實發生的 rollback。
常見問題
我是從 MIS／系統管理員轉 DevOps 的，經歷要怎麼寫？
轉職的證據是自動化：你把哪個手動流程變成程式碼、每週省回 [N] 小時。維運背景是資產。你看過系統怎麼壞，寫出來的自動化才有防禦性。
把「日常維護伺服器」改寫成基礎設施即程式碼的語言：codified、automated、versioned。同一段經歷換掉敘事框架，讀起來就是另一個職位。
事故可以寫進履歷嗎？會不會讓人覺得系統是我弄壞的？
可以，而且是最強的材料。寫法決定觀感：主詞是你做的復原與事後預防，例如 cut recovery to [N] minutes、eliminated the failure class。災難本身只是背景。
完全沒有事故痕跡反而可疑，像是你沒被信任過 on-call。指揮過的事故，是中生代與資深的分水嶺。
AWS、CKA 這些認證要放嗎？
放最高、最相關的一張，一行帶過，位置在頁尾。認證能通過關鍵字篩選，但面試考的是事故與設計。沒有一張證書撐得過「講一遍你最嚴重的事故」。
DevOps 與 SRE 的職缺我都投，需要準備兩份履歷嗎？
證據同一批，重心不同。投 SRE 把 SLO、error budget、事故指揮往前放；投 DevOps／platform 把管線、IaC、自助工具往前放。調整 summary 與關鍵字層，不改事實。
我只維運過內部系統，沒有大流量經驗，會不會直接輸？
規模是相對的，紀律是絕對的。IaC 覆蓋率、還原演練、告警品質這些實務，在 [N] 人的內部系統上一樣成立，而且可以誠實地寫。
用 [N] 寫出真實範圍，比含糊暗示大規模安全：面試第一題就是「多大的量」，守不住的數字會反噬整份履歷。
把你救回來的系統，變成面試官想深問的證據
用中文照實描述你維運過的系統、事故與自動化，AI 以 Tech 視角改寫成這一頁等級的英文 bullet。四項分數由規則引擎計算，同一份稿重測數字不變。缺的數字一律留黃色 [N] 空格由你自己填，因為面試時要一分鐘一分鐘講那次事故的人是你。
免費生成 2 次