沒有事故的一天

上午可能先看 Dashboard，檢查 Error Rate、Latency、CPU、Memory、Database、Queue、Traffic，確認服務狀態。

接著處理 Deployment：Review Pipeline、Approve Release、Check Rollout、Verify Application。部署之外，也會做 Terraform、Kubernetes、CI/CD、Monitoring、Automation、Cloud 相關的工程項目。

下午可能和 RD 討論「這個 API 部署之後，為什麼一直 Crash？」；跟 QA 釐清「測試環境跟 Production 為什麼行為不一樣？」；或和 Security 一起看「這個 Container Image 為什麼有漏洞？」

出現 Incident，就得先處理事故

原本排好的事情可能需要暫停，先走事故處理流程：

Detect → Triage → Mitigate → Recover → Root Cause → Postmortem → Action Items

從發現問題、判斷狀況、緩解影響到恢復服務，後面還有原因分析、事故檢討與改善項目要追。

維護 Server、寫 YAML 都可能是其中一部分，但日常還需要把 Software、Infrastructure、Operations 和 Reliability Engineering 一起考慮。

這篇文章 DevOps / SRE 平常都在做什麼？ 最早出現於 泰克哪裡去。

沒有 Incident 的日子，DevOps / SRE 仍有很多工作要做：Automation、Capacity Planning、Monitoring Improvement、Cost Optimization、Security、Disaster Recovery、Architecture、Performance、Deployment Improvement、Developer Platform、Documentation 和 Postmortem。

有些工作，平常不容易被注意到

自動備份、自動 Rollback、Health Check、Auto Scaling、Alerting、Deployment Automation，做好之後可能減少需要人工處理的狀況。旁人看到服務穩定運行，未必看得到背後做了哪些事。

這些都是 Reliability Engineering 的工作。Google SRE 對 toil 的定義，就是把那些與服務運行直接相關、重複、手動、可被自動化的工作視為應該逐步消除的負擔，並希望 SRE 把大量時間投入工程專案。

工程時間不能全被日常維運吃掉

SRE 不需要一整天坐著等 Pager。Google 的 SRE 模型明確限制 Operational Work 的比例，強調至少有一半時間應投入 Engineering Work。

沒有 Incident 時，正好可以處理那些會減少下次人工救火的工程工作。

這篇文章 DevOps / SRE 是不是沒出事時就很閒？ 最早出現於 泰克哪裡去。

產品類型、系統複雜度、部署頻率、監管要求、Production 重要程度、自動化程度與雲端成熟度，都會影響需要多少人。

不同規模，可能有不同分工

小型產品團隊可能是 8 RD、1 QA、1 DevOps / Platform，也可能由其中一位 RD 兼任 DevOps。

中型團隊可能有 20 RD、3～5 QA，以及 2～4 Platform / DevOps / SRE。

到了 100+ RD 的大型平台，QA / QE 可能分散在各產品團隊，Platform Engineering 與 SRE 則成為獨立組織。這時一個 Platform Team 支援很多 RD Team，用 1:10 來看未必合適。

上面都是可能的配置，不是照著人數就能套用的標準。

同樣人數，人工操作量可能差很多

如果 CI/CD 全靠人工，就需要更多 Operations 人力。Infrastructure as Code、Automatic Testing、Deployment Automation、Self-service Platform 與 Observability 比較成熟時，同樣規模的團隊可能減少不少人工操作。

要估人力，除了數 RD 幾個人，也得看還有多少工作需要人手動做。

這篇文章 RD、QA、DevOps / SRE 的人數配比關係？ 最早出現於 泰克哪裡去。

只看職稱，很難下這個結論。薪資還受到年資、產業、公司規模、地區、英文能力、技術深度、管理職、雲端能力和 Domain Knowledge 影響。

同樣叫 DevOps，工作可能差很多

2026 年台灣市場仍有 DevOps / SRE 相關職缺。104 上有些 DevOps 職缺偏 Azure / CI/CD，有些偏 AWS + Kubernetes + Terraform，也有把 Monitoring、Infrastructure、Security 放進同一份 JD 的。

104 的職缺樣本包括：

• DevOps：月薪 45,000～60,000 元。
• DevOps：月薪 68,000～70,000 元。
• SRE / Cloud Engineer：月薪 60,000～100,000 元。
• DevOps 工程師：月薪 80,000 元以上。

這些只是「目前職缺樣本」，不能當成市場中位數。比較待遇前，要先看工作範圍是否相近。

比較薪資時，也看職缺要求哪一段能力

初階常見 Linux、Git、Basic CI/CD、Basic Cloud、Shell；

中階會碰 Docker、Kubernetes、Terraform、Observability、Cloud Architecture、Automation；

高階則更偏 Platform、Reliability、Architecture、Security、Cost、Leadership。

Robert Walters 的 2026 台灣市場調查指出，科技人才對轉職仍有相當高的意願，而企業端招募則較審慎；具備高需求技能與實務經驗的人才，轉職時仍可能取得較明顯的薪資成長。

看薪資時，把自己能處理的工作和 JD 一起對照，比單問 DevOps 月薪多少更有用。至於 RD 和 DevOps / SRE 哪種職缺多，這些薪資樣本還不足以回答。

這篇文章 RD、DevOps / SRE，哪種職缺多？待遇差多少？ 最早出現於 泰克哪裡去。

看得到整個系統，也容易被當成什麼都管

Cloud、Network、Linux、Database、Application、Container、Security、Monitoring、Automation、Architecture，都可能出現在工作裡。接觸這些環節，有助於建立 System Thinking。

但責任沒分清楚時，一句「這個你們 DevOps/SRE 處理一下。」，就可能把 Network、Database、Deploy、Monitoring，甚至 Server 爆掉，全都交到你手上。

接近 Production，也得面對 On-call

你要關心的會從「Code 可以跑。」延伸到「Code 在 5 萬個 Request 下會怎樣？」

這能累積實際運行系統的經驗，也伴隨 On-call 責任。尤其是 24/7 Production、全球服務、金融、電商和高流量服務，如果沒有成熟制度，SRE 可能只剩下「半夜收 Pager。」

發展方向多，學習範圍也很大

DevOps / SRE 的經驗，可以延伸到 Platform Engineer、Cloud Architect、Infrastructure Engineer、SRE Lead、DevSecOps、Cloud Security、Architect 等方向。

相對地，技術很容易越碰越多：Docker、Kubernetes、Istio，還有 AI Agent。想在這個領域繼續做，持續學習是工作的一部分。

這篇文章 DevOps / SRE 工程師的優勢與劣勢 最早出現於 泰克哪裡去。

2025 Stack Overflow Developer Survey 顯示，84% 的受訪者正在使用或計畫使用 AI 工具，51% 的專業開發者每天使用 AI；但對 AI 輸出的正確性，46% 的開發者表示不信任，高於表示信任的 33%。

整理資訊、準備草稿

Log Summarization、Incident Timeline、Error Analysis、Runbook Search，都需要處理分散的資訊，可以讓 AI 先協助整理。

YAML Generation、Terraform Draft、Shell Script、Documentation、Configuration Review、Query Generation、Alert Classification，也適合拿來輔助日常工作。

AI Agent 還能串起更多步驟：讀 Log、找 Metrics、查 Deployment、分析最近變更，接著建立 Incident Summary、提出可能原因與 Remediation Plan。

Production 決策仍然需要人負責

不要直接讓 AI 自己在 Production 做高風險決策。Stack Overflow 的調查也顯示，開發者對高責任工作，例如 Deployment 與 Monitoring，仍然比一般 Coding 任務保守。

比起只問 AI 會不會取代 SRE，也可以看它能否減少整理資訊的時間，讓一個 SRE 管理更多系統。這仍是值得觀察的問題。

DORA 2025 的研究也指出，AI 更像是一個 amplifier：它會放大組織既有的優勢與問題，而不是自動把混亂的工程流程變好。

缺少 Observability，AI 就少了判讀 Monitoring 的依據；沒有 Runbook，也缺乏可靠的操作知識。流程還沒標準化就大量產生設定，可能只是更快累積混亂。

碎碎念(經驗談)

這裡我不說該怎麼用AI，或把AI拿來做什麼。

這裡我必須說，在你考慮使用AI在你的工作上，或是你手邊可以取得的 資料、環境、權限等，你必須先思考「安全性」！

或許這樣說你會想到最上面提到的AI正確性的信任度，但我指的不是 正確性，那是你需要思考和重證的，更多時候是否正確是可以嘗試的。

但！「安全性」不是！

不管你是DevOps工程師、SRE工程師，你所可以接觸到的東西都會有 機敏性 與 權限 等問題，尤其是Git Repository裡面可能有各環境的連線帳密等，在決定使用AI之前，先想好哪些地方可以使用，該如何保護這些 機敏性 與 權限 的內容，千萬不要因為AI很方便，可以替你做很多事/省下很多時間，就一股惱的運用AI。

這篇文章 DevOps / SRE 可以怎麼用 AI？ 最早出現於 泰克哪裡去。

有的職務以 Script 和自動化為主，有的則會開發內部工具或平台。

從日常自動化開始

至少建議學 Shell Script、Python，或其他一門程式語言。

工作裡會遇到 API、File Processing、JSON、Log Parsing、Automation、CLI、CI/CD，需要能用程式把這些事情接起來。

再往下做，就會需要 Modular Code、Testing、Error Handling，以及 API、SDK、Git、Package Management 等能力。

程式要能維護，不能只求這次跑得動。

高階 SRE 也可能大量開發 Internal Tools、Automation Platform、Operators、Controllers、Deployment Systems 和 Monitoring Systems。

Google 的 SRE 定義本身就很強調 Software Engineering；Google 甚至把 SRE 的 operational work 設下 50% 上限，要求大量時間投入工程專案與自動化。

和 RD 寫的東西差在哪？

SRE 需要程式能力，但不代表「你必須像 RD 一樣每天寫商業邏輯。」

RD 的 Coding Focus 常放在 Feature、Business Logic、API、Domain Model；SRE 則更常用在 Automation、Tooling、Infrastructure、Reliability、Observability、Deployment 與 Platform。

如果剛開始學，不必先去刷 500 題演算法。可以從 Shell、Python、HTTP API、JSON / YAML、Git、Testing、Debugging 練起，先讓自己能處理工作中的自動化與除錯需求。

碎碎念(經驗談)

程式能力這一塊，其實有下面幾個面向：
– DevOps/SRE職務需求的Script必須看得懂。
– 公司RD開發使用的程式語言，必須理解它的編譯、啟動方式等。
– 容器化的映像檔構建與運作方式能夠理解、規劃。

因為現在這個AI時代大多都請AI協助產生程式碼，但是不代表能夠「無腦」的把AI產生的東西用上，所以「看得懂」是首要重點！

也就是說，不以語言的限制所需要會的程式基礎能力是最少必須具備的，再來是「非程式碼」面向的一些概念也需要理解。

本文為個人職涯觀察與經驗分享，不代表所有企業的招聘標準或未來市場一定如此。

前一篇：DevOps / SRE 需要會什麼？

後一篇：DevOps / SRE 可以怎麼用 AI？

歡迎持續追蹤系列文：DevOps / SRE 學習指南：從職涯探索到實戰技能

這篇文章 DevOps / SRE 需不需要會寫程式？ 最早出現於 泰克哪裡去。

可以先把要做的事分清楚，再看工具放在哪裡。

Computer Fundamentals：理解系統

從 Linux 開始，弄懂 Process、File System、Memory、CPU、I/O 和 Permission。這些是理解系統行為的基礎。

Networking：理解連線

TCP/IP、DNS、HTTP/HTTPS、Load Balancer、Firewall、Routing 都會碰到。

Programming：能讀、能改，也能除錯

Python、Go、C#、JavaScript 等語言，至少學一種。比起把重點放在 LeetCode，更需要練習讀 Code、Debug，以及把工作自動化。

Software Delivery：把程式交付出去

Git、Build、Test、CI/CD、Artifact、Release，是從程式碼到發布會接觸的環節。

Infrastructure：準備運行環境

Cloud、VM、Container、Kubernetes、IaC，都屬於這個範圍。

Reliability：知道服務出了什麼事

Monitoring、Logging、Tracing、Alerting、SLO、Incident Response，處理的是觀察服務狀態與回應問題。

Architecture：考慮整體設計

High Availability、Scalability、Disaster Recovery、Security 和 Cost，也需要放進系統設計裡考量。

下次看到一個沒用過的工具，可以先看它在解決上面哪一類問題，再決定要補哪一段能力。

碎碎念(經驗談)

概念(或基礎)和工具不能混為一談，甚至不同公司、不同環境(測試/正式)使用不同的雲端方案都有不小的差異(熟悉度與適合度)。

如果是已經有DevOps/SRE團隊(多人)或部門的公司，或許會有個範圍，也可能接受加入了之後再擴大了解。

如果是一個人負責DevOps/SRE的公司，要看公司在哪個階段當下要解決的問題缺少什麼樣的人才。

但是更多的是想要了解過往在哪些部份有過什麼樣的實務經驗。

所以，到底需要會什麼，其實很難說得準。

本文為個人職涯觀察與經驗分享，不代表所有企業的招聘標準或未來市場一定如此。

前一篇：DevOps 和 SRE 有什麼不同？

後一篇：DevOps / SRE 需不需要會寫程式？

歡迎持續追蹤系列文：DevOps / SRE 學習指南：從職涯探索到實戰技能

這篇文章 DevOps / SRE 需要會什麼？ 最早出現於 泰克哪裡去。

DevOps 和 SRE 的工作常常重疊，但兩個詞的側重不同。

DevOps：開發與維運怎麼合作

DevOps 比較偏向方法與文化，關心 Development 和 Operations 如何一起把軟體交付做好。常見的工作包含 Automation、CI/CD、Infrastructure as Code、Monitoring，也強調 Shared Ownership 與 Continuous Improvement。

Google Cloud 對 DevOps 的描述，也把它定位為一種組織與文化取向，用來提升軟體交付速度、服務可靠性與共同責任。

SRE：用工程方法處理可靠性

SRE 更接近一種工程職能，集中處理 Reliability、Availability、Latency、Capacity、Incident Response、Observability、Error Budget 與 Automation。

Google 對 SRE 的核心思想，就是用 Software Engineering 的方法來解決 Operations 問題。

簡單分，DevOps 偏重 Software Delivery 怎麼做得更順，SRE 偏重 Production Service 怎麼運行得更可靠。

找工作時，兩邊可能是同一份 JD

有些公司的 DevOps 主要做 Cloud 和 CI/CD，有些還涵蓋 Infra、Platform。SRE 也可能偏 Production Operations，或同時負責 Platform Engineering 與 Reliability。

因此，職稱只能先幫你找方向。判斷工作適不適合自己，還是得看 Job Description 寫了哪些責任。

碎碎念(經驗談)

當然，有許多公司也會把這兩者混在一起，甚至把JD當作許願卡，在裡面塞了各式各樣的需求…

這類型的工作一體兩面有好有壞，好的地方是你什麼都有機會做(學習)，不好的地方是通常只有一個人，什麼事情都由一個人處理，經驗不足的話壓力會比較大。

如果要挑戰這種類型公司的工作，建議思路要很清楚，必須要了解問題並且知道可以怎麼做，同時要和公司對焦方向和順序，因為通常很多都還處於「初始化」階段。

這篇文章 DevOps 和 SRE 有什麼不同？ 最早出現於 泰克哪裡去。

這些背景不會讓你失去進入 DevOps / SRE 的機會，但轉職需要補的技術也不少。

DevOps / SRE 的工作橫跨 Software、Infrastructure、Networking、Automation 和 Operations。Programming 與 IT Operations 都會碰到，原本工作累積的能力也可能派得上用場。

原本的工作經驗，有哪些用得上？

工程背景常接觸問題拆解、Root Cause、流程、規格、測試與設備，這些經驗能用在 Infrastructure / SRE 的問題分析。

網路相關背景若已經碰過 TCP/IP、DNS、DHCP、Routing、Firewall，轉向 Cloud / DevOps 時，對網路的理解就是優勢。

機電、製造背景可能已經習慣監控告警、追蹤設備狀態、處理異常，以及把 SOP 自動化。這些工作和 SRE 要處理的問題，有不少相通之處。

技術要從哪裡補？

Programming、Git、Linux、Cloud、Container、CI/CD 都需要學。不過，一開始就同時碰 Kubernetes、Terraform、AWS、Docker，很容易學了操作，卻不知道工具在解決什麼問題。

可以先從 Linux 和 Network 開始，再學 Git 與一門程式語言，接著把 Build → Test → Deploy 串起來。有了這段經驗，再往 Cloud、Container、Kubernetes、IaC 走。

非資訊背景的人也能走這條路，但學工具時，要一起弄懂它背後的系統怎麼運作。

本文為個人職涯觀察與經驗分享，不代表所有企業的招聘標準或未來市場一定如此。

前一篇：想轉職資訊領域？除了軟體工程師，你還可以考慮 DevOps / SRE！

後一篇：DevOps 和 SRE 有什麼不同？

歡迎持續追蹤系列文：DevOps / SRE 學習指南：從職涯探索到實戰技能

這篇文章 非資訊背景，也能擔任 DevOps / SRE 工程師嗎？ 最早出現於 泰克哪裡去。