沒技術系列 — 如何成為一個好的 SRE 工具人

smalltown
Starbugs Weekly 星巴哥技術專欄
8 min readJan 18, 2022

Background

SRE 這個角色,相較於其他的職務來說,通常會涉略比較多的領域,接觸的業務範圍會比較廣泛一些,原因在於其必須對線上服務運行時的大大小小相關事務都需要了解,也必須要做到這一點才有辦法確保服務的正常運行,不然真的要救火時是要怎麼救 😂

而在面對眾多的需求與問題之下,不可能所有的解決方案都靠自己去實作出來,人類文明的進步也有賴於各個階段重要工具的發明與使用,當站在巨人的肩膀上時,很輕鬆地就能看得更高與更遠,在軟體工程領域也一再強調不要重造輪子,因此身為 SRE 雖然日常工作也是需要寫程式,但怎麼去選擇與整合工具來解決問題,也是一門很重要的課題 💪

Software Types Matters?

剛進入軟體產業時,在自己狹隘的認知之下,覺得解決方案就只有分成兩類,免費的跟要錢的,免費的叫做 Open Source,要錢的叫做 Commercial,不過經過在軟體圈子打滾一段時間之後,加上後來整個軟體生態圈的演進之下,事情並非這麼地非黑即白,Open Source 與 Commercial 之間變成相輔相成的存在,因為不管理想有多偉大,人活著還是需要賺錢養家吃飯 (想想最近 NPM 發生 colors 跟 faker 套件被刪除的事件)

🛠️ Open Source Software

一般來說,將軟體公開讓人可以任意取用的電腦軟體就會稱為開源軟體,不過在使用上需要遵守每個開源軟體所定義的授權規定,這個部分可以參考 Yuren 大大所撰寫的 “開放源碼授權概觀 (上)” 與 “開放源碼授權概觀(下)” ← 看看有多複雜,需要分成兩篇完整文章介紹 😂

🛠️ Commercial Software

一般人聽到商業軟體應該直覺就會覺得跟開源軟體站在對立面,例如程式碼是完全看不到的專有軟體,要花錢才能買來用…等,但其實不是這樣劃分的,所謂的商業軟體是指可以拿來銷售的軟體,所以它也可以是開源軟體,尤其是最近這幾年,越來越多的公司也都開始將軟體部分或是全部開源出來

🤔 How to Make Money?

要是大家都把軟體開源了,那要如何賺錢呢?

👉 以開源軟體來說,並不是公開的程式碼就可以任意的免費使用,必須要根據不同的授權方式來決定使用時是否需要付費

👉 再來則是商業公司並不一定會將所有的程式碼完全開源,可能會有部分的功能必須要付費才能使用到,例如像是 Authorization & Authentication 這種付得起錢的公司特別需要的功能就不會開源出來

👉 最後則是技術支援的部分,程式碼可以讓你免費拿去使用,但運行遇到問題時該如何解決呢?使用的解決方案出問題導致半夜線上服務倒站該怎麼辦?公司內當然可以聘雇相關專業人士來負責,不過直接購買官方的技術支援也是一種解決方案

How to Choose Solution?

因此自己最近在選擇解決方案時,有沒有開源這件事情越來越不用去拘泥了,因為在整個 SRE 生態圈尤其是 Cloud Native 相關的產業裡,開源也算是家常便飯了,既然大家都開源了,當然就不需要在意嘍 😂

🛠️ Competitive Analysis

而要選擇解決方案之前,最重要的當然就是必須要先做好問題分析,自己通常都會透過 Google 搜尋這個領域的第一把交椅 ,例如今天要導入 Infrastructure as Code,就一定馬上會找到 Terraform

接著可以搜尋 Terraform Alternatives,就可以找到更多相關的解決方案,例如 Pulumi, CDK…等,這時候就可以再透過這些解決方案的關鍵字搜尋到比較文,或是在各大部落格,以及 Reddit 裡面找到鄉民的使用經驗分享 (自己這兩三年很常花時間去看 Reddit 鄉民的論戰),到這個階段應該就把資訊收集的差不多了,可以把 Pros and Cons 給清清楚楚的條列出來

🛠️ Proof of Concept

不管心中已經有決定好的解決方案,或是剩下兩個在糾結究竟要選擇哪一個,這時就是要開始做實驗的時候了,也就是進行 PoC,相信很多 Pre-Sales 跟乙方單位聽到這三個字都會有一些不好的回憶存在,不過在正常狀況下, PoC 對於雙方彼此來說,都是相當重要的一環,

而因為 PoC 其實需要耗費的資源比想像的還要來得大,所以自己會建議一次或是一段時間一個就好,不要一次 PoC 很多的解決方案;因為自己實作 Lab 時需要耗費不少的時間,尤其假如是需要跟其他商業公司合作時,跟對方公司窗口來回溝通也會花掉不少時間,更何況以 SRE 來說的話,線上服務的日常維運工作還是在的

🤔 Analyze Angle

怎麼去評估 PoC 完的結果呢?每一個領域的解決方案,在技術方面都有其特別需要注意的地方,而由於這篇是沒技術系列文,所以先不在技術上多作著墨,底下列一些可能會被大家忽略掉的要點:

👉 Community: 從開源軟體的社群可以看出活躍程度,例如 GitHub Issue 和 Pull Request 的回應與更新頻率,通常背後有商業公司的話,就會有資源投注在這一塊,假如背後沒有商業行為的話,就是靠各方熱心的工程師了,當然必須要選擇相對活躍的,因為有很多人使用,代表很多人幫忙當 QA 去使用與測試,也可以看出開源專案的維護方有沒有用心在開發需求與解決問題

👉 Self-Condition: 團隊內成員對於想要採用的解決方案有沒有人力資源協助維護?從一開始的安裝設定,後續日常維護,突然出問題…等,這些都需要人手去幫忙;假如沒有辦法安排資源去做這些事情,那就只能選擇有提供技術支援的商業解決方案,不過中間需要取捨的因素滿多的,例如:完全沒有人力只能這樣做,或是有人力,但不想投資在此解決方案上,有更重要的事情需要去完成…等

👉 Official: 以商業方案來說,遇到問題如何解決這件事情上還滿重要的,通常會分成 8*5 或是 24*7 的技術支援,所以對於官方所提供的技術支援需要考慮的要點,通常就是語言跟時區,因為有些領域的設定或是問題查找,很需要來來回回反覆溝通,這時候考慮本地端的廠商其實溝通上會比較有效率;而官方在本地端有沒有合作窗口,例如在台灣有哪一些代理商可供選擇合作,也一定要先問清楚

Procurement

透過 PoC 選擇好要使用的技術解決方案之後,假如是需要花錢購買的解決方案,就會有一些事情要先釐清楚

🤨 :蝦咪,買個東西這麼麻煩喔?!

😅 :對,超級麻煩XD

🛠️ W/O Agents

在跟官方 PoC 到後期時,假如有興趣購買的話,就會開始詢問其價格,然後有些網頁上會有價格表格可以參考,但是大部分在企業方案那一個欄位,都不會有任何的資訊,就算有資訊,也一定要先問問看對方在本地端有沒有代理商,假設回應沒有,那通常就是使用信用卡或是匯款的方式進行購買

🛠️ W/ Agents

但上面的方式會有什麼問題呢?就是你一買下去後,公司會需要繳交給台灣政府 20% 的境外電商扣繳稅額,但假如有代理商的話,他們協助開設有公司統編的發票,通常只會加 5% 的稅額,這中間就差了 15%

🤔 It’s Complicated…

👉 不過也不是有代理商就一定會選擇透過他們付款,因為代理商也有營運成本,有時候購買的金額不夠多時,透過代理商給的報價可能會超過 20% 也說不一定,這部分就要報價計算後比較才能知道要如何選擇比較好

👉 為了避免買貴了,或是有獨厚某間代理商,甚至是拿回扣的社會事件發生,通常會規定需要多間代理商進行報價,然後再去選擇價錢比較低的一家

👉 當交易的金額比較大一些時,為了保障交易雙方的權益,通常還會需要準備一份制式合約讓雙方法務都審查過,例如服務壞掉不能用怎麼辦,匯款的期限是在發票開立多久之後…等

Conclusion

後面扯的有點遠,跟 SRE 的本業沒什麼關係,可是既然是沒技術系列文,就讓我多講一些在採購技術解決方案時可能會遇到跟需要考量的事情;自己剛出社會當 Engineer 時,會覺得什麼都是自幹為王,我用 Open Source 完全不用錢架設出來的服務最厲害了!但後來得到了一些教訓,發現事情沒有我這個憨人想像的這麼簡單

🤔 建議可以先思考看看,解決這個問題是可以增加公司與團隊的核心競爭力的嗎?!

👉 答案是否定的,又沒有人力去做相關維護與開發,其實就會建議直接購買商業解決方案,不需要去浪費人力與時間

👉 答案是肯定的,但當下沒有人力去做,那還是建議直接購買商業解決方案,畢竟是公司對外服務所需要的核心功能;等到後續有人力規劃來解決該問題或是實作該功能時,再把商業解決方案給替代掉

👉 答案是肯定的,而且又有人力進行後續維護與功能開發,在這種情況下,就可以比較大膽的使用免費的開源軟體,甚至自己開發功能進去,或是整個解決方案由公司內部自己實作出來

--

--

smalltown
Starbugs Weekly 星巴哥技術專欄

原來只是一介草 QA,但開始研究自動化維運雲端服務後,便一頭栽進 DevOps 的世界裏,熱愛鑽研各種可以提升雲端服務品質及增進團隊開發效率的開源技術