ref: https://iximiuz.com/en/posts/devops-sre-and-platform-engineering/
本篇是一個由 Twitter 討論串引發的後續文章,作者想要聊聊 DevOps, SRE 以及 Platform Engineering 的差異。
文章中附有相關 Twitter 討論串的連結,對於原文有興趣的也可以去參閱一下 Twitter
註:就我個人觀察到的現象,台灣企業很少看到 Platform Engineer 的職位,有人知道有哪些公司有開這種職位可以留言分享一下
作者自述自己是個從事 SRE 工作但是內心卻是個軟體工程的技術專欄作家,因此就自己的過往經驗想分享一下對於這三者的看法,而這些討論就引起了一些回文
因此作者將這些概念整合下來寫下這篇文章來總結一下各方網友們的看法。
作者的軟體生涯中,從分工仔細的團隊到新創公司都經歷過,再還沒有認知到 DevOps/SRE 這類型名詞前就已經體驗過部署開發維運三合一的人生。
隨者愈來愈多人開始探討 DevOps 以及 SRE 這兩個詞,兩者之間的比較沒有停過,甚至還有專屬的兩個 awesome 系列 awesome-sre, awesome-devops 清單來列舉如何學習這兩個技術。
整個求職市場也因為這兩個名詞的出現而有變化,作者也因應這股潮流開始往下探索,因此最後就以自己自身的經驗來分享自己對於這些名詞的想法。
其中作者有提到一點也是我非常認同的,就是這些名詞代表什麼含義,這些職稱要做什麼都會隨者不同公司不同團隊而有變化,畢竟每個公司的產品跟商業走向都不同
期待能有一個一統天下的職稱跟工作內容反而才是不切實際的。所以接下來的探討就只是作者跟幾個網友們的討論,不要當作圭臬,也不要當作聖旨,自己有自己的想法比較重要。
# What is Development
1. 作者認為開發的概念非常簡單,就撰寫程式,唯一能夠為公司貢獻 $$$ 的職位,畢竟有人寫程式還有產品,沒人寫程式也沒什麼好部署的。
2. 推特網友表示: 只有 sales 才是幫公司賺錢的,剩下都是公司的支出
3. 作者從 2011 開始了軟體工程師生涯,過往作者都很期望自己可以去部署一下自己撰寫的程式,但是基本上都是團隊內的其他神秘人物會默默的部署這些程式到生產環境。
# What is DevOps
1. 作者不想探討何謂官方的正式定義,只想聊聊自己多年工作經驗的感想
2. 對作者來說, DevOps 是一個能夠讓開發者對於部署應用程式有更多機會與權力的文化,實作上沒有一定的準則
3. 作者還待過那些開發者都擁有 sudo 權限來部署應用的新創公司,不過現在這些流程都慢慢的被自動化 CI/CD 流程給取代。
4. DevOps 最初的想法應該是遠遠超過作者所描述的,不過作者就自己工作上的經驗,找工作的經驗,看職稱 JD 的經驗來看,DevOps 更像讓開發者打造的產物可以更有效率的被部署
5. DevOps 本身不應該去探討產品的商業邏輯,那是開發者要探討的。
# What is SRE
1. Google 推出了一系列的書來探討何謂 SRE,那系列書籍的想法偏向 SRE 是其中一種 DevOps 文化的實作方式。
2. 相對於 DevOps,作者更喜歡 SRE 帶來的職缺內容。
3. 作者對於提到 CI/CD pipeline 之類的職缺都感到無聊且沒興趣,而 DevOps 的工作職缺往往都充滿這些令人無聊的東西。
4. 相反的,作者更喜歡去專研系統問題,譬如探討為什麼會有 bug, memory leak, 效能不好...等
5. 作者認為 SRE 要負責去維護上線環境,確保使用上沒有問題。
6. Google 的 SRE 系列書籍還提到了關於 monitoring, alerting, SLO 等各種如何確保服務正常的機制。 Facebook 則是有非常著名的 Production Engineer 的職稱,其跟典型的 SRE 基本上沒太大的差別。
7. 推特網友表示: SRE 專注於生產環境, DevOps 專注於 CI/CD 與開發效率與流程
8. 另外一名推特網友表示(這也是我目前最喜歡的答案): DevOps 從開發角度為起點, SRE 從維護上線環境出發,兩職缺於某處產生交集。
# What is Platform Engineering
1. 作者想起當年還是一家新創的唯一一位工程師時,那時候還要去租借實體機器來架設環境,所以那時候也撰寫了不少腳本來安裝機器,也要確保機器之間的網路可以正常運作。
2. 加入一間比較有規模的公司後瞭解到看來 infra 相關的工作是一個很類似 SRE/DevOps 但是又有些許不同的領域
3. 作者認為 Platform Engineering 目標就是要打造一個可以讓 Dev, Ops, SRE 能夠使用的環境
4. 作者感覺 Platform Engineering 要負責維護 data-center 內上千台的機器,確保這群機器能夠正常運作,維護外也要包含升級,設定等。
# What's about titles?
1. 作者前述探討的都是基於負責領域,比較不去談這些職稱應該要做什麼
2. 根據作者經驗,當公司規模逐漸變大時,分工就會愈來愈細,這時候 Dev, Ops, SRE, PE 等職缺就會開始逐漸專項化。
3. 重點就是, YMMV (Your Mileage May Vary ),不同情況,不同答案,不要太專注於一個死板板的解釋。
個人想法: 公司要開什麼職缺名稱就不管他了,工作內容才是最重要的,有錢的任性老闆也可以開一個"開源軟體整合工程師"但是要你整合 CI/CD 加上維運的工作。
「ops工程師」的推薦目錄:
- 關於ops工程師 在 矽谷牛的耕田筆記 Facebook 的精選貼文
- 關於ops工程師 在 寫點科普 Facebook 的精選貼文
- 關於ops工程師 在 台灣物聯網實驗室 IOT Labs Facebook 的最佳解答
- 關於ops工程師 在 What is Ops? | Complete Think 的評價
- 關於ops工程師 在 DevOps Taiwan | 在座的各位都是風水工程師XD - Facebook 的評價
- 關於ops工程師 在 Ops 的轉職之路- Puppet 從入門就放棄 - GitHub 的評價
- 關於ops工程師 在 十五年來軟體開發最大的變革!DevOps 讓組織文化、團隊模式 的評價
ops工程師 在 寫點科普 Facebook 的精選貼文
新增:謝謝讀者們的留言鼓勵和熱情分享自己的經驗~ 本文目的是分享個人面試經驗,給大家之後在自己的面試準備上能有所參考如何應對類似情況或是考量不同類型的職場文化,不希望臆測特定公司。另外面試過程完全是公平公正的,對方公司透過模擬日常職場測試,審慎評估過後認為雙方不適合。僅希望這樣的分享能幫助到大家,我也還有很多地方待提升,未來也一起加油吧!
---
我前陣子被朋友內推,去面試了某間全球雲端龍頭廠商的業務類型缺,就說是OO公司好了。其中的面試環節為:
對方會先給一個Case Study,內容是某 XX 公司對雲端服務有興趣想要了解一下。看完該 Case Study之後會跟由面試官(都是 OO 公司的業務人員)假扮的 XX 公司 CTO 先約一通 15 分鐘的電話蒐集一下需求。
接著會給一週的時間完成一份PPT,再約個 1 小時的時間來做Presentation,模擬銷售雲端產品給 XX 公司,其中 CTO 會來參加(也是業務人員的面試官假扮的)。
以下是針對面試過程中企業文化不合的一些心得,也是我人生中面過最出乎意料的一次面試,想作為趣談跟讀者們分享。
花了蠻多時間準備好 PPT 之後,我剛開始講話就被對方不斷地打斷,最後一頁 PPT 都沒用到,全程一小時變成100%的Q&A。
同時這些問題當中,每一項問題都有標準答案,彷彿只是再考該雲端公司產品或服務知識的問答集。
舉例來說:OO產品彈性擴容的機制、帳號要怎麼開?我們怎麼從本地端移植過去?OO 在產品上手這塊能提供哪些資源?
雖然可以理解這是真實客戶會詢問或發生的情況,但這樣會覺得有點困惑,如果全程都是在問這些問題的話,為什麼還需要簡報Presentation環節呢?不用直接透過我的PPT呈現邏輯來做評價,只是用隨機抽考的方式測驗我夠不夠懂產品知識的話,直接用一個問答面試就能解決了。
另外,對方提出必須把搬移到雲端前後的成本換算比較列出來放進簡報當中。因此我也做了一份分析。
「…所以使用雲端之後您將能節省下這部分的人力成本。」我說。
「但我這三位Ops工程師我已經請了難道你要叫我解雇嗎?其中有一個還是我們共同創辦人欸。」對方質疑道。
「理解您的意思,我只是給您一個建議、在團隊節省了運維的人力之後,這些人力可以用於開發更多創新產品提高現有收入,或是學習雲端架構之後,來進一步協助團隊規劃您的整體系統架構。」
「但他就不會啊。他還要去花時間學習雲端嗎?如果說也要用到這些人的話你人力成本應該算回去吧。」
「我只是比較目前您營運的架構當中其實不需要高達三位運維人員,如果未來您用戶數成長到百萬人次在系統設計上還有很多需要人力的地方就不需要多請很多人了,用現有團隊就行。」
我補充道:「而且我了解到您先前提到目前最關注的問題就是高峰期間的流量會讓服務無法響應,才因此想要移植到雲端,這樣的話這幾位團隊同仁還不願意學習雲端的話,我不太理解這個情況?」
「你要這麼說的話你能給我一個說明看這些人員怎麼佈署嗎?不能的話你算成本給我幹嘛?」
「沒問題,我們後續可以再跟您討論這一塊。」我默默想結束這個話題。
---
接著又絲毫沒有喘息的問下一個問題,一樣沒有要進入簡報環節:
「我聽說 OO 公司的成本在所有雲端廠商當中價格最貴,你為什麼要把價格就放在第一部分講?」
「我相信 OO 的確產品價格更高一些,但相較於您目前自建在本地端成本而言,我也想要呈現給您看──同樣的架構,用我們產品的成本就可以節省到目前的1/14,已經遠遠比您目前的成本更低了。
但當然您可能會說『那其他雲端服務商說不定還能節省地更多』,所以我下一個環節就要跟您介紹我們的服務優勢,讓您了解到我們服務的強項、這也是其他家不能比的。」
「但我還是覺得你成本放第一頁跟我沒關係欸,我只是想要知道我現在痛點你怎麼解決。」
「好沒問題,讓我們來看這個系統架構怎麼優化跟提升,這個是團隊原本的架構…」我想趕快切入主題。(如附圖,面試文件中要求展示 XX 公司使用雲端架構之前、和用上雲端之後的架構對比)
「等等這是雲端吧,你用一個雲端架構圖跟我講要幹嘛,我又還沒有雲端。」對方質疑道。
「不是,這是本地端。你看這個只是VM,其他資料庫阿外部儲存阿也是你對應到你自己的資料中心。」我解釋道。
「我們本地端哪那麼複雜,我看不懂你在畫什麼,我們很簡單只有三層。你不能用傳統的三層架構直接來對比嗎。你這樣畫難怪每一項雲端產品都能夠直接做對應啊。」
「……」CTO會看不懂這張圖就已經包含在三層式架構裡面?
---
最後對方問我,如果重來一次會想怎麼優化這次的簡報。
「我本來認知中,對方之前在電話中提到希望透過這個會議能了解的資訊有三個層面:『不那麼了解雲端想要被科普』、『OO公司可以怎麼滿足XX公司目前提升系統效能跟可用性的要求』以及『XX公司未來新上的服務可以怎麼被支援』
所以我分別用『介紹什麼是雲、雲端你能省下的成本』、『OO產品系列對應到你現有服務、跟未來想加上的新服務的總架構圖』,這樣的思路去做這份Presentation。很抱歉我沒有第一頁就放出他們最關心的問題。」
我說:「我會更理解對方急迫的痛點,每天晚上九點鐘網站流量會爆掉是他第一優先關注的話,我會在第一頁就優先跟他討論該怎麼做遷移、該怎麼抓一個時間我們一起討論把雲端服務Run起來解決他現在營運的問題,進入討論這樣的細節。成本或是新服務上線,只會作為亮點補充,最後再跟他探討。」
我頓了頓:「同時在PPT呈現上,如果客戶只懂三層架構,那我就不會用這種比較複雜的架構圖,我會用三層架構再加上分別對應的元件….」
有一個女面試官突然開口打斷:「好了好了不要再講技術了好嗎,可以結束了吧?」隨後把會議結束掉。
我一臉錯愕地盯著乍然黑掉的螢幕。
-------
最後快40頁的 PPT 一頁也沒有用到,長達一小時只是不斷地拋出問題並在同一個問題上持續糾纏。然而對方問的問題,都是在如果進入公司之後經過產品培訓就能夠有一套標準回答的問題。似乎沒有要聽你簡報思維脈絡的意思。畢竟這仍號稱是一個PPT面試,還滿令人出乎意料的。
我思考了一下,可能對方需要的人才就是在各種高壓情況之下都能溫柔以對的標準回答吧。隨後也立即拿到了Rejection Letter,深感自己的確與對方企業文化不合,想想人生中也沒遇過更神奇的面試經歷(畢竟做好的PPT一頁也沒有用到有點匪夷所思),忍不住上來分享給大家輕鬆看看。
ops工程師 在 台灣物聯網實驗室 IOT Labs Facebook 的最佳解答
AI 時代的摩爾定律?黃氏定律靠的是自身技術力將 AI 性能年年加倍
作者 雷鋒網 | 發布日期 2020 年 12 月 16 日 8:45
1965 年,時任快捷半導體公司工程師,也是後來英特爾(Intel)的創始人之一的戈登·摩爾(Gordon Moore)提出了摩爾定律(Moore’s law),預測積體電路上可以容納的晶體管數目大約每經過 24 個月便會增加 1 倍。
後來廣為人知的每 18 個月晶片性能將提高 1 倍的說法是由 Intel CEO 大衛·豪斯(David House)提出。過去的半個多世紀,半導體行業按照摩爾定律發展,並驅動了一系列的科技創新。
有意思的是,在摩爾定律放緩的當下,以全球另一大晶片公司 NVIDIA 創始黃仁勳(Jensen Huang)名字命名的定律——「黃氏定律(Huang’s Law)」對 AI 性能的提升作出預測,預測 GPU 將推動 AI 性能實現逐年翻倍。
Intel 提出了摩爾定律,也是過去幾十年最成功的晶片公司之一。NVIDIA 作為當下最炙手可熱的 AI 晶片公司之一,提出黃氏定律是否也意味著其將引領未來幾十年晶片行業的發展?
AI 性能將逐年翻倍
受疫情影響,一年一度展示 NVIDIA 最新技術、產品和中國合作夥伴成果的 GTC China 改為線上舉行,黃仁勳缺席今年的主題演講,由 NVIDIA 首席科學家兼研究院副總裁 Bill Dally 進行分享。Bill Dally 是全球著名的電腦科學家,擁有 120 多項專利,在 2009 年加入 NVIDIA 之前,曾任史丹佛大學電腦科學系主任。加入 NVIDIA 之後,Dally 曾負責 NVIDIA 在 AI、光線追蹤和高速互連領域的相關研究。
在 GTC China 2020 演講中,Dally 稱:「如果我們真想提高電腦性能,黃氏定律就是一項重要指標,且在可預見的未來都將一直適用。」
Dally 用三個項目說明黃氏定律將如何得以實現。首先是為了實現超高能效加速器的 MAGNet 工具。NVIDIA 稱,MAGNet 生成的 AI 推理加速器在模擬測試中,能夠達到每瓦 100 tera ops 的推理能力,比目前的商用晶片高出一個數量級。
之所以能夠實現數量級的性能提升,主要是因為 MAGNet 採用了一系列新技術來協調並控制通過設備的訊息流,最大限度地減少數據傳輸。數據搬運是 AI 晶片最耗能的環節已經是當今業界的共識,這一研究模型以模組化實現能夠實現靈活擴展。
Dally 帶領的 200 人的研究團隊的另一個研究項目目標是以更快速的光鏈路取代現有系統內的電氣鏈路。Dally 說:「我們可以將連接 GPU 的 NVLink 速度提高一倍,也許還會再翻番,但電信號最終會消耗殆盡。」
這個項目是 NVIDIA 與哥倫比亞大學的研究團隊合作,探討如何利用電信供應商在其核心網絡中所採用的技術,通過一條光纖來傳輸數十路信號。據悉,這種名為「密集波分複用」的技術,有望在僅一毫米大小的晶片上實現 Tb/s 級數據的傳輸,是如今連網密度的 10 倍以上。
Dally 在演講中舉例展示了一個未來將搭載 160 多個 GPU 的 NVIDIA DGX 系統模型。這意味著,利用「密集波分複用」技術,不僅可以實現更大的吞吐量,光鏈路也有助於打造更為密集的系統。
想要發揮光鏈路的全部潛能,還需要相應的軟件,這也是 Dally 分享的第三個項目——全新程式語言系統原型 Legate。Legate 將一種新的編程速記融入了加速軟件庫和高級運行時環境 Legion,借助 Legate,開發者可在任何規模的系統上運行針對單一 GPU 編寫的程序——甚至適用於諸如 Selene 等搭載數千個 GPU 的巨型超級電腦。
Dally 稱 Legate 正在美國國家實驗室接受測試。
MAGNet、以光鏈路取代現有系統內的電氣鏈路以及 Legate 是成功實現黃氏定律的關鍵,但 GPU 的成功才是基礎。因此,GPU 當下的成功以及未來的演進都尤其重要。
GPU 是黃氏定律的基礎
今年 5 月,NVIDIA 發布了面積高達 826 平方毫米,整合了 540 億個晶體管的 7 奈米全新安培(Ampere)架構 GPU A100。相比 Volta 架構的 GPU 能夠實現 20 倍的性能提升,並可以同時滿足 AI 訓練和推理的需求。
憑藉更高精度的第三代 Tensor Core 核心,A100 GPU AI 性能相比上一代有明顯提升,此前報導,在 7 月的第三個版本 MLPerf Training v0.7 基準測試(Benchmark)結果中,NVIDIA 的 DGX SuperPOD 系統在性能上開創了 8 個全新里程碑,共打破 16 項紀錄。
另外,在 10 月出爐的 MLPerf Inference v0.7 結果中,A100 Tensor Core GPU 在雲端推理的基準測試性能是最先進 Intel CPU 的 237 倍。
更強大的 A100 GPU 迅速被多個大客戶採用,迄今為止,阿里雲、百度智能雲、滴滴雲、騰訊雲等眾多中國雲服務提供商推出搭載了 NVIDIA A100 的多款雲服務及 GPU 實例,包括圖像辨識、語音辨識,以及計算流體動力學、計算金融學、分子動力學等快速增長的高性能計算場景。
另外,新華三、浪潮、聯想、寧暢等系統製造商等也選擇了最新發布的 A100 PCIe 版本以及 NVIDIA A100 80GB GPU,為超大數據中心提供兼具超強性能與靈活的 AI 加速系統。
Dally 在演講中提到:「經過幾代人的努力,NVIDIA 的產品將通過基於物理渲染的路徑追蹤技術,即時生成令人驚豔的圖像,並能夠借助 AI 構建整個場景。」
與光鏈路取代現有系統內的電氣鏈路需要軟硬體的匹配一樣,NVIDIA GPU 軟硬體的結合才能應對更多 AI 應用場景苛刻的挑戰。
Dally 在此次的 GTC China上首次公開展示了 NVIDIA 對話式 AI 框架 Jarvis 與 GauGAN 的組合。GauGAN 利用生成式對抗網路,只需簡略構圖,就能創建美麗的風景圖。演示中,用戶可通過語音指令,即時生成像照片一樣栩栩如生的畫作。
GPU 是黃氏定律的基礎,而能否實現並延續黃氏定律,僅靠少數的大公司顯然不夠,還需要眾多的合作夥伴激發對 AI 算力的需求和更多創新。
黃氏定律能帶來什麼?
NVIDIA 已經在構建 AI 生態,並在 GTC China 上展示了 NVIDIA 初創加速計劃從 100 多家 AI 初創公司中脫穎而出的 12 家公司,這些公司涵蓋會話人工智慧、智慧醫療 / 零售、消費者網路 / 行業應用、深度學習應用 / 加速數據科學、自主機器 / IoT / 工業製造、自動駕駛汽車。
智慧語音正在改變我們的生活。會話人工智慧的深思維提供的是離線智慧語音解決方案,在佔有很少空間的前提下實現智慧交互,語音合成和語音辨識保證毫秒級響應。深聲科技基於 NVIDIA 的產品研發高質量中英文語音合成、聲音定制、聲音複製等語音 AI 技術。
對於行業應用而言,星雲 Clustar 利用 NVIDIA GPU 和 DGX 工作站,能夠大幅提升模型預測精確度以及解決方案處理性能,讓傳統行業的 AI 升級成本更低、效率更高。
摩爾定律的成功帶來了新的時代,黃氏定律能否成功仍需時間給我們答案。但這一定律的提出對 AI 性能的提升給出了明確的預測,並且 NVIDIA 正在通過硬體、軟體的提升和創新,努力實現黃氏定律,同時藉生態的打造想要更深遠的影響 AI 發展。
黃氏定律值得我們期待。
附圖:▲ NVIDIA GPU 助推 AI 推理性能每年提升 1 倍以上。(Source:影片截圖)
▲NVIDIA 首席科學家兼研究院副總裁 Bill Dally。
▲ 搭載 160 多個 GPU 的 NVIDIA DGX 系統模型。
資料來源:https://technews.tw/2020/12/16/huang-law-predicts-that-ai-performance-will-double-every-year/?fbclid=IwAR1vXHWAGt_b8nDRW6VUqzpAINX_n_DzJ0KwJvdBnl18s8Q1A3Thk7hgBoI
ops工程師 在 DevOps Taiwan | 在座的各位都是風水工程師XD - Facebook 的推薦與評價
其實DevOps 職缺很多種,撇開總是被大家笑說,只是Ops 或IT 或MIS 改名稱來騙人的DevOps Engineer ,還是有一些公司有DevOps Lead、DevOps Manager、DevOps coach 等 ... ... <看更多>
ops工程師 在 Ops 的轉職之路- Puppet 從入門就放棄 - GitHub 的推薦與評價
在這個DevOps 文化如此蓬勃的時代裡,Ops 不再是單純Ops,Dev 也不純了,每個工程師都要有能打十個的能力才能努力活下來,在大環境如此凶險的情況下,要如何讓自己擁有 ... ... <看更多>
ops工程師 在 What is Ops? | Complete Think 的推薦與評價
跟工程師談到 Ops 腦袋裡想的通常是 SysOps or DevOps ,前者偏向系統維運,通常會是Infra / System 等問題、後者則是開發維運,通常會是CI / CD 的 ... ... <看更多>