前經與一位 SRE 的前輩聊天的時候，問他 SRE 到底要做的工作應該算是什麼？他半開玩笑地回答：「SRE 做的工作就是人生的工作吧？」現在想想，他也許真的在開玩笑，但也許他說的也是一種發自內心的感想也說不定。
無論如何，如果讀者看到這裡，對於 SRE 這份工作開始有些興趣，在這篇文章中，筆者將從技術面與心態面兩個角度切入，嘗試分享一些也許能夠協助到各位的觀點。
上圖中所呈現的，就是筆者在這一年中，感受到做為 SRE 會需要知道的相關知識，越上層越重要。這裡也可以參考由其他人所整理的DevOps Roadmap: Learn to become a DevOps Engineer or SRE。
第一層中所展示的，主要是雲端服務、作業系統與容器化技術、網路相關的知識。
其中，雲端服務包含三大公有雲業者，分別是 AWS、GCP、Azure。筆者認為先摸熟其中一種，再跟據後續的需求來學習其它即可，沒有必要特別三種都專精，因為一般的業務需要也比較少會需要三者一起精通的狀況，再加上理解一種後，要理解另外一種公有雲並非什麼特別困難的事情。
在學習雲端的過程裡，筆者非常推薦可以透過準備證照的方式來強化自身的能力。準備證照一來可以有比較明確的目標，二來也會有比較完整和有規劃的學習計劃。
筆者過去主要準備的都是 AWS 證照，目前手上擁有的是 Solutions Architect Associate、SysOps Administrator Associate、Developer Associate 以及 Solutions Architect Professional，接下來則希望朝 Advanced Networking Specialty 嘗試看看。在這些證照中，筆者最推荐的證照則是 Solutions Architect Associate ，如果覺得這張太過吃力則可以從 Cloud Practitioner 開始，而考過的讀者則可以嘗試 SysOps Administrator Associate 或更進階的 Solutions Architect Professional。
證照考試本身當然會與實際工作有一些落差，但就筆者從雲端小白到目前工作一年的感受是，準備證照能夠讓自己對雲端的相關服務有一定程度的理解，等到獲得相關需求的時候，大致上可以知道能夠應用的服務，至於細節的部分雖然還不清楚怎麼處理，但只要到時候再透過文件去處理即可。
這邊有非常多相關的學習資源都可以在 Udemy 這個平台上找到，筆者當時所使用的課程是 Ultimate AWS Certified Solutions Architect Associate (SAA) | Udemy。
額外可以補充一點， 筆者認為準備符合自己程度的證照是相當重要的。雖然有幸能考取 Solutions Architect Professional ，但實際上筆者不只準備得非常痛苦，實際最後也不是真的有非常多應用場景讓筆者使用到，只是拿到證照後放著忘記而已，因此在這件事情上面讀者也可以再自行斟酌。
有關 AWS 的證照，可以參考這篇：AWS Certification - Validate AWS Cloud Skills - Get AWS Certified (amazon.com)。
除了雲端之外，做為現在非常重要的容器化技術，特別是 Kubernetes ，幾乎可以說是各家 SRE 的標準配備了。這部分同樣也有相關的證照可以讓讀者參考，名字則是 CKAD 與 CKA 。但一般在還沒有接觸過容器化的讀者，則也可以從 Docker 開始入手。相關的學習資源，推荐 Udemy 上的 Mumshad Mannambeth 老師(Mumshad Mannambeth | Best Selling Instructor | Teaches Kubernetes | Udemy)，或是 Youtube 上的 TechWorld with Nana 頻道(TechWorld with Nana - YouTube)。
最後，同樣不可或缺的網路知識，但這部分筆者暫時還沒有找到比較適合的管道。最主要還是在於說，筆者也是近期才開始真正意識到這一塊的重要性。在第一個重大 P0 事件簿中，也就是因為客戶修改了 Name Server 而導致的那個事件中，筆者第一次意識到對這一塊知識的匱乏，而在重要事件系列中提到 CDN Migration ，讓筆者進一步開始想要對這一塊進行比較完整的補強。這間接促使了筆者想要準備 Advanced Networking Specialty 的想法，但目前也還不太確定這個方向是否適合現在的需求。但無論如何，關於這一塊的知識絕對是必要且沒有妥協空間的。
第二層也相當重要，最主要出現的是各種監控與分析工具。
在監控工具上，除了 Prometheus 或是筆者在最一開始的〈前言 & 基本監控系統〉所介紹的 CloudWatch 之外(如果是其它雲端供應商就會是其它服務)，與其它監控工具的串接，比如敝公司有使用的 Pingdom 或 Pagerduty 都一樣相當重要。分析工具包含日誌與資料視覺化工具，最常見的可能就會是 Grafana 以及 ELK (Elasticsearch、Logstash、Kibana)工具等等。
而這部分，因為筆者真正接觸過的只有 CloudWatch 、 Pingdom 以及 Pagerduty，而且後兩者其實在進來公司前就已經被前輩給完成串接了。因此只有透過在 AWS 證照考試的時候來加強對 CloudWatch 的理解而已。 在此可能沒有辦法提供讀者比較明確的學習資源，但做為參考，讀者還是可以往這個方向嘗試學習看看。
第三層包含的是各類部署和架構工具、以及程式語言。
雖然在敝公司裡面分工比較細，因此維運與部署被切分成兩個不同團隊，所以 SRE 的團隊相對而言比較少接觸包含 Terraform、CloudFormation、Gitlab CI 之類的工具，但也有許多公司應該會以同一個團隊來包辦這裡所有的事情。因此部署和架構工具也是一個相對需要的知識，而從之前的文章中應該也可以看得出來，事實上我們 SRE 團隊也常常需要接觸到部署流水線的工作。
程式語言則可以分兩個面向來分享。首先，我們所大量使用的自動化工具，特別是為了某些特殊狀況而開發的，都仰賴我們的開發能力。在這個過程中最常被使用的可能會是 Python；但 Golang 做為 Kubernetes 以及 Terraform 的底層語言，也同樣是一個可以儘可能瞭解的語言；而 JavaScript 做為另一個不需要編譯(compile)而且方便輸寫的語言，也同樣值得一學。另一方面，筆者的主管也曾經分享過，因為容器化與雲端技術日新月異的關係，未來維運的工作可能只會越來越少(比如 ECS Fargate 相較於 EC2，在維運上所需要的人力就少上非常多)，因此系統出狀況時，SRE 跳進程式裡協助開發工程師 debug 的狀況也越來越有可能發生，因此至少有讀懂程式的能力就變得相當重要。
就程式這一塊而言，因為學了之後要轉戰後端工程師也完全可以，因此從某個角度來看，也可以說是一門穩賺不賠的生意。
在最近一次遇到 P0 事件的時候，筆者邀請了旁邊吃爆米花看戲的 HR 講笑話給正在處理的我們聽。
「大家知道為什麼暖暖包永遠不會過氣嗎？因為它有很多鐵粉。」
好，謝謝。
在最一開始接手 SRE 這份工作的時候，最害怕的果然還是值班時隨時可能會響起來的 P0 警報了吧，這也許也是所有剛入門 SRE 的人最擔心的事情。筆者雖然希望能夠提供一些建議，但平心而論，還是必須要實際經歷過幾次之後，才會慢慢習慣這件事情。
不過，筆者認為在這個過程中所歷輕的心態轉變，是第一個可以先分享給讀者的東西。首先，如同上圖中的第一個引言所述(再加上筆者的超譯)：「系統出問題並不一定會是壞事，因為偶爾故障的系統才能向老闆彰顯出 SRE 的價值。」
這邊筆者想強調的，主要還是說，系統出問題不一定是 SRE 的責任。不如先深呼吸一口氣，用更悠閒的態度來面對每次 P0 事件吧。
當然，SRE 的主要任務之一，還是會需要儘可能地讓系統能夠穩定運作。而從這個角度出發的話，筆者認為 SRE 與其它開發工程師最大的不同，就會在於切入系統的維度不同。SRE 更傾向於從更宏觀的角度來看待系統，對於單一功能如何最佳化而言可能不像開發工程師這麼專業，但不同功能組成起來後可能會出現的維運問題，就會是 SRE 更關心的。
從這個角度來看，應該也不難理解 SRE 為什麼會是一個需要大量溝通能力的工作。也許兩個最後要串接起來的功能剛好是由兩個不同的工程師或團隊來開發，而雖然他們可能各自都使用了最佳化的方式來開發，但整合起來時卻不一定是那麼一回事，這時 SRE 就應該要有能力在一開始的討論中看出這個可能性，透過不斷反覆溝通來避免最後整合時遇到的問題，特別是從系統維運角度來看。
當然了，也有可能會出現最後決策並非是以技術角度出發的狀況，比如在日常維運系列中的〈棒球賽〉就有提過，最後要啟用的伺服器數量其實是以再次獲取客戶信任為前提而設立的。
另一方面，即使系統沒有遇到重大問題，筆者認為不斷精進和改善各種維運上所遇到的問題，也會是一種良好的 SRE 心態。無論是之前在日常維運系列中提到的〈定期盤點工作的自動化〉，還是下一篇的〈自動化工具的最佳化〉，這種不斷持續變好的心態，都能讓系統最後能夠更穩定執行。換個角度來說，一個優秀的 SRE 也許可以是一個很閒的工程師，因為所有日常事務都已經透過自動化工具處理完畢。
但是，SRE 也許也應該要有另一個心態，就是系統實在太大太過複雜，無論如何改善，都有可能會遇到遺漏或不夠好的地方。正如同上圖中的第二個引文：「軟體開發與教堂建立沒有差很多，我們先把它蓋好，然後我們開始祈禱。」換句話來說，這個世界上沒有任何一個人能夠保證系統不會真的出事，SRE 的工作也不是保證系統不會出事，因此也不需要太過刻追求百分之百的完美。
提個外話，SRE 也許仍然是一個要抱持虔誠態度的職業吧。筆者日前跑到彰化八卦山看大佛，在大佛面前跳了一下僵屍舞(?)後不久發生 P0 警報了，最後導致的 P0 事件一直到當天晚上筆者回到台北後才結束。
所以說，在此還是與讀者分享一下，做為一個 SRE 也許還是要虔誠，不要不信邪吧？
「人生就像一盒巧克力，你永遠不知道你會吃到什麼口味。」
「SRE 就像一盒巧克力，你永遠不知道你翻開系統，會發現……呃，什麼問題？」
說實話，筆者作為一個只有一年經驗的菜鳥，在很多技術與經驗的方面都還有待磨練。不過前輩那句「SRE 就是人生」仍然讓筆者印象深刻。人生中所遇到的各種難題，似乎都在 SRE 的工作中可以想像到。
大量的溝通，大量的妥協，大量預期之外的情緒勞動。所有混亂在同一時間湧入，筆者有時候甚至感覺自己似乎不是在做工程師，但到底在做什麼好像也說不上來。此外，SRE 也是一個需要隨時停下來省視目前的狀況，並以中長程時間來重新規劃系統目標的工作，這似乎與規劃自己人生又有點不謀而合？
最後，同樣是追求持續改善與進步，但筆者在自己的人生中也早已放棄追求百分之百的完美。也許是因為這是一件做不到的事情，也可能是因為我們就是必須與生命中的這些小小缺憾一起共同成長。但無論如何，筆者認為獲得百分之百完美的同時，也代表著宣告放棄進步的可能性。我們不可能放棄改善與進步，但這也意謂著我們不可能達到百分之百的完美。在追求完美的同時認知到不可能真的完美，在這種矛盾又痛苦的心態中持續往前邁進，無論是做為 SRE 還是一個人，都是無法迴避的一種自我辯證的過程吧？
在筆者一開始接觸軟體工程師領域的時候，主要是先從程式開發面著手，雖然一開始主要學習的是後端開發的領域，卻在學習的過程中意外發現自己對於系統維運方面的熱沈，最後面試的時候則誤打誤撞之下進入了 SRE 的工作。
其實一直到現在，筆者都感覺 SRE 要知道的東西到底為什麼會這麼多。不只每個領域都要摸過，還不能都只是摸過，需要有一定程度的瞭解才可以算是實際有幫助。
但也正因如此，筆者才打從心理感謝所有在公司協助過自己的同事與主管(無論是工程師還是產品經理)。最一開始雖然遇到了意外觸發 P0 而導致一陣的亂流，但逐漸穩定下來後，可以真實感受到團隊其他成員的友善與技術能力的高超之處。筆者在這個鐵人賽裡多次提到資深前輩的協助，其實就是因為，真的是受到過太多不同人的幫助了。如果沒有他們，也許有很多問題到現在，筆者都還沒有非常清楚要怎麼處理才行。
而在此也想要特別感謝在剛踏入這個領域遇到的指導老師。筆者會參加這個鐵人賽也是由他推荐才報名的，他不只在筆者學習的路上給予了非常多的幫助，筆者也從他的身上感受到所謂工程師對技術的熱情可能可以是怎麼一回事。無是現在還是未來，他都會是筆者努力學習錄看齊的對象。
最後的最後，也是發自內心真誠地感謝願意讀到這裡的所有讀者。當初筆者會寫這系列文章，當然主要還是希望透過這一系列的鐵人賽文章，讓所有對這個行業有興趣的讀者，能夠在一窺 SRE 生活的同時，進一步理解自己是否適合這份工作，在思考這件事情的時候對各位有所幫助。
但筆者也藉著這一系列的文章裡重新回顧自己過去一年中所完成的任務。回顧起來才會發現，實際上筆者所完成的任務遠比自己想像中的還要多上許多，也同時更意識到自己目前所在的位置，以及未來可以進步的方向。這些都是當初所沒有預期到的。
很感謝各位讀者，如果有任何意見和想法都歡迎再分享。筆者自認在書寫的過程中收獲良多，也希望讀者能夠有所收穫。
iThome鐵人賽
看影片追技術