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

回想今年一直拖到最後一刻才決定報名參加，隔天就是必須發表第一篇文章的最後期限，當時都還沒有想好這30天的文章內容要如何安排，只能且戰且走的方式先報名出去，接著花了幾天的時間邊寫文章邊思考一下以今年報名的題目有哪些內容可以寫，先列出了大概的文章標題，每天再按照已經列出來的文章標題目錄去著手。就這樣，一天接著一天過去了，最終來到了最後一天…

今年和去年都是以Azure DevOps為主題來寫文章，而這兩年所寫的內容也都是我實際在工作上使用到的東西，只是文章中將工作相關的內容去除掉了，每篇文章的內容和截圖幾乎都是完全重新再做一遍，有些地方太複雜還要想辦法簡化一下，不然每天要寫一篇文章實在是有點困難…(這是稱之為「挑戰」的原因吧！)

其實走向DevOps的領域最困難也最具挑戰性的應該就是需要面對與熟悉很多不同的系統與工具，各家的DevOps系統搭配上每間公司的產品、政策與流程，就像是玩積木一般，每個人都有他的創意，組合出來的東西和樣子都長得不一樣。同樣類似的需求，在設計上也有許多的不同之處，如同烹飪一般，大家都是做同一道菜，但是選用的材料也有差異，這就像今年其中一篇文章「使用Task與CLI的抉擇」所提到的概念一樣，同樣的需求可以透過很多不同的方式達成，可以用內建的Task也可以用Script來完成，各自的色、香、味又是如何，真正品嚐的人才會知道了。

回頭想想，參加鐵人賽的時期總是我個人的部落格產出文章最多的時期，平常下班回家沒事大概只想耍廢，上班又不可能拿來寫文章，所以總是很佩服固定有內容產出的大大們。

這兩年以Azure DevOps為主題所寫的文章內容，同樣有發佈在我的部落格，2013年的鐵人賽雖然也有發佈在部落格，不過搬家沒有回復資料，所以就看不到了。也因為那時候是從部落格貼上內容到鐵人賽，圖片的連結也是取自部落格放圖片的位置，現在從當年的鐵人賽文章內容也會發現破圖的現象，所以這兩年寫在鐵人賽文章中的圖片都是獨立另外上傳在iThome的系統中，這樣就不會再發生部落格掛掉卻在鐵人賽文章中破圖的情況了。

如果各位對於部落格的文章有興趣，或是想在鐵人賽結束之後看看有沒有「第31天」之後的內容，也歡迎過段時間來到部落格逛逛。

對了，因為DevOps牽涉到的面向很廣，公司在轉型的過程中也要列出明確的Roadmap，近期也開了一個新的職缺，想要找人來和我一起在公司推動相關的工作，如果您有興趣，也可以私訊給我聊聊進一步的資訊。

最後，祝大家工作都順利、愉快！

終於完結啦~

這篇文章 【2022鐵人賽】2022 iThome鐵人賽結尾 最早出現於 泰克哪裡去。

先來看看成果的範例吧！

訊息的格式或排版是可以自己定義調整的，至於欄位的部份就是看當初表單是怎麼設計的囉！

首先，我們進入Power Automate的頁面，登入帳號進入到管理介面之後，在左邊的選單選擇「範本」，然後在搜尋框裡面輸入「teams」，就可以找到和Microsoft Teams相關的範本可以拿來修改使用。

從篩選出來的Teams範本中，選擇「在提交新回應時通知小組」，也就是在上圖中右下角的那個項目，可以稍微看一下它的小icon是不是Microsoft Forms和Microsoft Teams的圖樣。點擊進入之後會如下圖，系統會在兩個系統中使用你的帳號進行作業，點擊「繼續」按鈕授權之後就可以進入到設計畫面了。

下面這張圖就是設計的頁面，都是簡單的挑選幾個選項就可以完成的事情，主要重點就是選擇要將內容發送到Teams的哪一個頻道，然後在最下面要傳送到Teams中的訊息呈現樣式，可以把它弄得很整齊漂亮，不過我個人是覺得資料有呈現出來就可以了。

訊息呈現的樣式和內容搞定之後，選擇下面或右上角的儲存就搞定了，這時候就可以回到表單去填寫一筆資料看看，如果有在設定的頻道中收到訊息的話，那就是成功了。

透過這樣的方式就可以讓申請者直接進入表單填寫的頁面，當他們填寫完畢之後直接就會在Teams上面通知，若是有流程上需要配合的人員，例如某些步驟需要別的同事協助作業，完成之後再繼續其它的動作，這時候也可以直接在機器人發送的訊息下面使用回覆訊息的功能，然後@ 那位同事，整個搞定之後也可以回覆該訊息串記錄一下那張申請表已經完成了。

這篇文章 【2022鐵人賽】Power Automate整合Microsoft Forms：Teams通知 最早出現於 泰克哪裡去。

從這個簡單的想法為出發點，其實也很容易找到一些現成的服務，Google的表單也是一個不錯的選項，不過如果公司的員工帳號是儲存在AD(Active Directory)，那麼選用微軟的Forms應該會是一個更好的選擇，所以這邊就以Microsoft Forms為例子(雖然還有另一個主要原因，不過下一篇再說)。

首先，搜尋Microsoft Forms進入Microsoft Forms官網頁面之後，登入公司的帳號(如果有在使用Office365)，選擇新增表單。

接著會是下面的設計畫面，透過幾個基本的元件組合就可以設計出一個簡易的表單(設計組合的部份就不一個個截圖了)。

大概設計出下面這樣的表單內容：

如果有人填寫了資料，就可以在「回應」的頁籤中看到填寫的內容，不過因為並不是要做問卷統計，所以下面的圖表結果不是我們關心的重點，直接選擇「在Excel中開啟」就可以把結果的資料下載到本機中透過Excel打開，這樣就可以看到有哪些人填寫了哪些資料了。

透過這樣簡單的設計就可以有一個申請表單的機制，可以省下一些流程與麻煩事，也方便保存這些歷程資料。

這篇文章 【2022鐵人賽】Microsoft Forms：建立Azure DevOps專案申請表 最早出現於 泰克哪裡去。

前面提到過將Pipeline範本化設計就是為了建立多個Azure DevOps專案的時候可以快速方便的把基本的架構弄起來，而每一個新建立的專案都有可能是給不同的開發團隊使用的，這些夥伴可能甚至沒有使用過Azure DevOps、對我們規劃的流程沒那麼熟悉等等。

這時候當我們將新的DevOps專案建立好之後，要把相關資訊移轉給他們時，若是有個地方可以將一些資訊集中放在那裡提供團隊成員參考，我想應該是一個滿不錯的方式。而這個地方，我覺得最適合的就是每個Azure DevOps專案內的Summary頁面與Wiki，就像下面這張範例圖。

一個新專案剛建立的時候應該是長得像下面這個樣子，Summary的頁面並沒有什麼內容，如果我們可以利用這個版面，就可以讓團隊成員一開始進入專案首頁的時候就可以看到我們希望傳遞給他們的資訊。

要達到這個目的，我們只需要透過Markdown格式來寫一些內容就可以達成，而存放Markdown檔案的空間就是Project的Wiki。

從Wiki的選項進入之後，你可以看到有兩個按鈕選項，分別是Create project wiki、Publish code as wiki，兩個差別在於前者會建立一個隱藏的wiki Git Repository，也就是這篇文章的主題，後者則是使用你已經建立好的Git Repository。在這邊我們選擇Create project wiki。

系統建麼了wiki Git Repository之後就會帶到上面的這個編輯文件的畫面，而這個文件保存的格式就是不折不扣的Markdown文件(.md)，利用Markdown格式寫完之後按下Save按鈕之後，在它的左邊就會自動出現Close按鈕，按下之後你就會看到下面的這個總覽畫面：

建立完Summary.md的內容之後，再點回去專案的Summary頁面，接著按下Add Project Description按鈕，右邊彈出來的畫面上就可以選擇Wiki，它會自動認到剛剛上面新增的Summary.md內容。

儲存之後重新看到的畫面就會像下面這樣：

前面已經說過，這個Project wiki實際上就是一個Git Repository，但是…，如果你直接點進去Repos功能中想要去找它，會發現…它根本不存在？

甚至你跑到專案的設定裡面想要去找找看有沒有它的蹤跡卻也無功而返？

其實呢！直接從網址輸入它的名字就可以進去了喔！

很神奇對吧！也因為它就是和一般的Git Repository一樣，所以你可以把它Clone下來，透過你習慣的IDE來編輯Markdown檔案，完成之後再重新把它commit上來。畫面中的.order檔案則是用來設定Markdown在上面的Wiki總覽畫面顯示的順序。

透過這個方式，也可以將專案的Summary Markdown檔案弄一個範本，放在templates Git Repo或是另外建立一個Docs Git Repo，之後建立新的專案的時候就直接從這個地方複製過去就可以了，節省每一個專案要重新在介面上輸入同樣內容的時間。

這篇文章 【2022鐵人賽】Project Wiki：隱藏的Git Repository 最早出現於 泰克哪裡去。

為了之後建立多個Azure DevOps方便，所以調整完後也需要將它匯出成Json檔案當作後續建立的範本來匯入，這樣大部份的項目就會先建立好，我們只需要針對一些地方進行調整修改就可以了。

首先，先來調整原本的CD Pipeline，先增加templates的Repo來源，這部份在後續新的Azure DevOps專案應該不會更動，別名就使用PipelineTemplates吧！

接著我們需要修改Stage和Production的Agent job，要新增一個Bash task，就是針對環境變數檔案內容合併的部份，Script裡面的內容參照先前CI Pipeline寫的內容，只是路徑和變數需要調整一下，可以對照下圖的Script和YAML內的差異。

改完之後還需要調整一下Deploy CloudRun的Script，圖中的PipelineRepo和PipelineTemplates都是對應上面第一張圖所設的別名，應該沒忘吧？

Production的部份也是一樣新增Bash把合併環境變數檔案的Script加進去，可以直接複製Stage內的Script。同時也別忘了要修改Deploy CloudRun的Script。

Stage跟Production的Script都調整好了之後，就來到Variables頁籤來新增使用到的變數。這邊跟之前比較不一樣的地方在於綠框的內容，因為我們已經學習到了更多的東西，所以可以調整一下一些變數的設計，這樣之後在新的Azure DevOps專案匯入CD Pipeline的時候才不會有漏改的地方。(參考多專案命名規則與變數範本這篇文章)

都改完存檔之後，就可以回到外面一層，在CD Pipeline的部份叫出選單，把它匯出(Export)為Json檔案保存下來，之後在新建立Azure DevOps專案的時候方便匯入。

上圖就是匯入的選項位置，新專案可能因為沒有任何一個Release Pipeline而找不到這個選項，只要隨便建立一個空的Release Pipeline再來找這個匯入的功能就可以了。(建立的空Release Pipeline再刪掉就好)

選擇前面匯出的Json檔案按下Ok就會匯入成為一個新的CD Release Pipeline了。

匯入成為新的CD Release Pipeline之後，根據先前在基本版-建立CD Release Pipeline這篇文章建立的步驟檢查一下各項設定與變數內容(記得更改專案名稱)，然後有兩個地方特別要留意一下，第一個就是除了PipelineTemplates那個Artifacts來源之外，其它的都要刪掉重新加，因為專案不同。第二個就是在Production的Create Pull Request的部份要針對新的專案重新選擇，不然Git commit SHA會對不起來，無法建立PR也無法合併。

這篇文章 【2022鐵人賽】調整CD Release Pipeline與匯出Json檔案當作範本 最早出現於 泰克哪裡去。