有的職務以 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 工程師嗎？ 最早出現於 泰克哪裡去。

開發工程師類

• 軟體工程師（Software Engineer）
• 前端工程師（Frontend Engineer）
• 後端工程師（Backend Engineer）
• 全端工程師（Full-stack Engineer）
• Android／iOS 工程師（Mobile App Engineer）

系統與平台工程師類

• 雲端工程師（Cloud Engineer）
• DevOps 工程師（DevOps Engineer）
• SRE（Site Reliability Engineer）
• 平台工程師（Platform Engineer）
• 還有許多其他職稱……

問題是：這麼多職稱，到底哪一個適合自己？而 DevOps／SRE 又是一個很容易讓人誤會的領域。

有人認為它就是維運，有人認為它就是雲端；有人認為只要會 Docker、Kubernetes 就可以，也有人覺得：「DevOps 是不是就是幫 RD 部署程式？」其實都只講到一部分。

DevOps 的核心比較接近讓軟體交付與運行變得更可靠、更快速、更可重複；SRE 則更強調以工程方法處理正式環境（Production）的可靠性與營運問題。Google 對 SRE 的經典描述，就是讓 Software Engineer 用工程方法來設計 Operations。

第一個問題：我適不適合 DevOps／SRE？

可以先從幾個問題思考：

• 你是不是喜歡研究「系統為什麼這樣運作」？
• 遇到問題時，你是先重開服務，還是會想知道根本原因（Root Cause）？
• 你會不會對作業系統（Linux／Windows）、網路（Network）、資料庫（Database）、雲端（Cloud）、容器（Container）、自動化（Automation）產生興趣？
• 你是不是喜歡把原本需要人工做的事情自動化？

如果答案大多是「會」，DevOps／SRE 就值得放進你的職涯考量。

第二個問題：轉 DevOps 一定要先當 RD／會寫程式嗎？

不一定。但完全沒有開發概念，通常會讓學習曲線比較陡。

因為 DevOps／SRE 工作經常需要理解：

• 程式碼（Code）怎麼編譯（Build）。
• 應用程式（Application）怎麼啟動。
• 服務（Service）怎麼互相呼叫。
• 資料庫（Database）怎麼連線。
• 容器（Container）怎麼運作。
• 系統部署（Deployment）怎麼發生。

所以 DevOps／SRE 不見得要求你成為專業 Application Developer（應用程式／軟體開發者），但理解軟體生命週期非常重要。

第三個問題：DevOps 是不是比 RD 好？

不應該用「哪一個比較好」來看，它們解決的是不同問題。

RD 偏向：「怎麼把產品功能做出來？」

DevOps／SRE 偏向：「怎麼讓這個產品可靠地被 Build、Deploy、Operate、Observe？」

真正值得思考的是：你的興趣比較偏向「做功能」，還是「讓整個系統運作得更好」？

因此，DevOps／SRE 不應該被當成「寫程式寫不下去之後的備案」；它本身就是一條完整的工程職涯。

如果你正在轉職 IT，DevOps／SRE 值得研究，但更重要的是先了解：你究竟喜不喜歡這種工作。

碎碎念（經驗談）

在這個 AI 寫程式愈來愈快、愈來愈好的時代，初階工程師面對 AI 的競爭壓力不小，資深工程師也都在使用 AI 寫 Code。如果想轉職開發類工程師，我個人感覺現在並不是一條很好走的路。

但是在全民 AI 寫 Code 的時代，許多人會利用 AI 產生系統，卻不見得熟悉後續的流程：編譯、測試、部署、上線等。

尤其企業關鍵的系統，在正式環境中通常不可能不經把關就把所有流程完全交給 AI。因此我個人認為，DevOps／SRE 在未來可能會是更受重視的角色。不過，實際職缺需求仍然會隨企業、地區和市場而不同。

當然，如果你本身就不是開發工程師，但是會使用 AI 來開發系統，也希望 AI 開發完成的系統可以上線給許多人使用，那麼就更應該了解 DevOps／SRE 這個領域了。

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

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

這篇文章 想轉職資訊領域？除了軟體工程師，你還可以考慮 DevOps / SRE！ 最早出現於 泰克哪裡去。