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 加上維運的工作。

#純靠北工程師472
----------
[請教前輩-我很迷茫，且徬徨]
小弟年25，碩畢後的第一份，是在園區的500多人的小公司當小IT，48K保14，早9晚7，目前剛滿一年。應徵時，我原以為我是來學做資安的，進來後，發現是infra team，但實際上，我不知道自己定位在哪，以及此份工作對未來職涯的傷害性，這一年來，我經歷的工作內容: AD維運(半手動式)、內部Portal網站維運、Vmware虛擬化維運、PBX電話交換機維運、80多台的Cisco L2 Switch ACL&Vlan 維運、網點建置 cabling發包與管控、全公司OA升級win10、以及help-desk win10疑難雜症、大姨媽式的各種內外ISO稽核、每月ISP全系列帳單報帳核銷、MVPN門號管控、CCTV監控建置與維運(目前548支IPCAM持續上升中..)，另外還有疫情期間視訊會議設備及VDI系統的導入、諸如此類等等..，我逐漸遺忘了以往的程設能力，整天在user與user之間徘徊social，在這個崗位上，我理解到技術或許不再是唯一，為了解決人的事情，先解決人的可能性與重要性，但細思極恐，我覺得這不該是我這資歷擁有的體悟，是否更應專精於某項技能，而不是學了一堆技能，但卻把技能點都平均散佈在上面，到了30卻不能轉職...希望板上前輩能給予一些未來建議，謝謝各位。
----------
🗳️ [群眾審核] https://kaobei.engineer/cards/review
👉 [GitHub Repo] https://github.com/init-engineer/init.engineer
📢 [匿名發文] https://kaobei.engineer/cards/create
🥙 [全平台留言] https://kaobei.engineer/cards/show/5438

美國科技公司的績效考評 (Performance review)

我在美國正職工作過 3 間科技公司， 一間是 20 人以下的新創、一間是員工總數 1 萬 5 千人的太陽能公司、 一間是員工人數大約 5 萬人的 FAANG 級別科技公司。我在每間公司都經歷至少 2 次的績效考評，今天就從我的經驗及我看到身旁朋友的經驗，來聊聊美國科技公司大概怎麼做績效考評 的。


一般來說，績效考評的頻率從 1 季 一次到 1 年一次都有， 我前 2 個正職經驗都是年底的年度考核， 目前則是半年一次的考評。 1 季一次考評優點是考評時間短， 評量的內容聚焦，缺點是頻率有點太高、有些專案需要的時間較長考評時就沒有辦法看出太大的成果， 而且每季一次讓管理階層要花許多時間審核及給評價，影響可以正常工作的時間。 年度考評好處是用一整年的時間評量， 許多比較需要長一點時間的專案也有比較合理的時間可以評估， 但缺點也是因為頻率較低， 讓員工壓力更大 (沒有拿到好的表現或升職就要再等 1 年)， 另外一年一次也讓在下半年或接近年底離職的員工無法拿到相對應的評價及獎金。 因此，半年一次的考評可能算是折衷及許多公司採用的頻率。


績效考評的內容組成，一般來說有 3 個部分， 一個是自我評量， 一個是同事的評量、一個是直屬老闆的評量。 自我評量就是自己寫在考評期間的貢獻，因為只有自己說的話不一定客觀， 還需要邀請和你共事的同事寫他們覺得你的貢獻，同事寫你的考核是可以選擇不分享給你看 (只有經理可以看到)， 所以你可能不知道同事寫你什麼， 另外就算你沒有邀請同事幫你寫，同事還是可以自己主動寫， 一般來說，同事考核都會蠻客觀公平的。 最後直屬老闆的考評則會參考你自己及同事的報告，來做最後的評量。


因為考評結果會直接影響獎金及是否能升遷， 大家都會很努力的寫自我的考評。於是大家都在笑話每次考評的時候就像是寫作文比賽，平時做很重要的工作很棒，但在考評的時候更重要的是要想辦法把自己超棒的一面展現出來！自我考評一般都會寫的比較多， 畢竟只有自己才最了解自己的貢獻。 有鑑于大家越寫越多， 可能都有人寫到 1 萬字的文章， 經理們都看不來 (假設經理平均管理 6 ～10 個人， 每個人有除了自己考評還有 4～6 個同事考評)， 目前也都建議大家自己的考評不要寫超過像 1,500 字或 2,000 字 (但我還是每次都稍微超標 XD 😅) 。


考評方向通常會分為幾大部分， 以工程師來說，會看 Impact, Engineering, Direction, and People。 不同職位可能就是第 2 個部分 Engineering 會注重不同的指標。 Impact 會依照你所做的專案而有不同的指標， 如果是產品組，可能是產品上線，累積了多少使用者，或是新的功能讓使用者使用產品時間更多、或是省更多時間，如果是在 Infra 組，可能會是產品幫助內部提升多少效率、節省多少資源等等，每個組的指標都不同， 所以觀察的 Impact 也就不一樣。


Engineering 是看你的工程方面的指標， 是否有產出高品質的 code， 產品程式設計是否合理、未來可以擴展、是否有幫助整體團隊的工程品質提升等等。


Direction 則是看是否在專案或團隊中有領導能力， 規劃、帶領專案方向、發現產品痛點、做新的嘗試及發想等等。 People 是看是否有幫忙面試招人、帶新人、專案協調溝通、做內部或外部的知識分享等等。


當然每家公司考核內容有些差異， 但大方向來說不會差太多， 而目前矽谷許多公司的考核， 好像大部分源自於微軟的考核制度 (這是從以前看過某一篇文章了解的， 現在一時找不到， 如果有人有知道歡迎留言指正)，因每間公司的需求而再做調整。


同事考核寫的方向和個人考核也都一樣，但字數上就會比自我的考核少的多 (畢竟就只能從合作的部分來做觀察及下筆)， 經理則從員工及同事的考核報告，再總結成經理最後的版本。


做考核就是希望要給大家一個評價， 這個評價結果會影響獎金及升職。 公司到了一定規模後， 如何公平的評比不同部門的員工也就是一個很重要及困難的課題。 通常的解決方式有: 1. 召集不同部門的經理一起做考評， 一個員工的考績會是需要與會的所有經理都有共識同意才可以決定。 2. 用一個獨立的考評委員會，確定沒有直接的利害關係的人士來做考績的評定。3. 考評的結果範圍差距很小，大部分人都是拿到正常符合期待的考績，只有很少部分人會拿到特別好及特別差。


不同等級的工程師， 對於以上提到的考評方向也會有不同的期望標準， 大致上來說，目前矽谷大部分的公司都會是屬於你要穩定的展現下一個等級的表現， 才會把你升職到下一個等級， 這樣的作法確保員工不會因為太早升級，到下一級後的考績達不到標準而痛苦。


沒有一個制度是十全十美的， 每種考評制度及頻率都有其優缺點， 為了要在每次考評結果出來時候自己不會覺得有意外結果， 平時和經理的 1:1 （定期一對一談話)就要常常確認自己的狀況， 如果有任何問題及需要幫忙， 早點提出來和經理一起努力！


以上是我觀察及了解的美國科技公司考評的方式，你的過往考評經驗如何呢？如果你是非工程師， 你的考評方向是什麼呢？ 如果你對以上的內容有什麼感覺及建議，都歡迎留言提出歐。 😁


部落格原文: https://brianhsublog.blogspot.com/2020/06/PerformanceReviewInUS.html