正如 serverless 一詞會讓人感到困惑，運維一詞也是如此。當談話中出現這個術語時，人們會想到不同的東西，這會讓談話變得混亂。

什么是 serverless?serverless 是一種架構理念，最新的定義這樣描述它：“serverless 架構是基于互聯網的系統(tǒng)，其中應用開發(fā)不使用常規(guī)的服務進程。相反，它們僅依賴于第三方服務，客戶端邏輯和服務托管遠程過程調用的組合。”

運維有著很廣泛的定義。通常，人們會在談話中提到一個不存在運維的場景，但實際上，他們建議作為替代品的東西在我看來仍然是運維。當我們甚至無法就所談論的內容達成一致時，我們該如何討論 serverless 對運維所帶來的影響呢?
 

在我們對所談論的內容有了共同的理解之后，讓我們來看看運維人員在 serverless 中應該屬于處于什么樣的位置。我認為運維團隊在 serverless 環(huán)境中沒有多大意義。但是，運維人員其實是有價值的。那么他們應該處在什么樣的位置上?
 

什么是運維?人們對運維的理解通常是不一樣的，但通常都是正確的。選擇什么樣的定義取決于一個人的經驗、需求和優(yōu)先事項，以及他們看問題的角度。然而，這些不同的定義往往會導致人們的交談相互脫節(jié)。
 

從最高層面看，運維是一種實踐，讓支撐業(yè)務的技術保持運作。但如果你深挖一下，運維一詞可以以用在許多方面。因為這些含義緊密耦合了很長時間，人們往往會把它們混為一談。
 

什么是運維?
 

運維是：
 

•  一個團隊

•  一種角色

•  一種責任

•  一組任務
 

通常，這個角色由運維團隊的運維工程師承擔，他們負責執(zhí)行與運維相關的任務。近年來，DevOps 的出現極大改變了這種局面。曾經有關所有這些定義的死板結構被拆解，由此，定義本身也就分崩離析。
 

在 DevOps 頻譜的一端，運維團隊和個體角色基本保持不變。開發(fā)人員和運維人員都是獨立的團隊，只是開發(fā)團隊開始承擔一部分的運維職責，運維團隊和開發(fā)團隊之間的溝通比之前上升了一個層次。當我們聽到有人說“開發(fā)人員先收到警報”或開發(fā)人員不能再讓代碼“翻墻”時，我們知道，運維職責發(fā)生了變化。
 

在 DevOps 頻譜的另一端沒有了運維團隊和個體角色。有些企業(yè)將具備運維和軟件開發(fā)技能的工程師組合在一起，創(chuàng)建了跨職能團隊。這些企業(yè)沒有運維團隊，也沒有計劃組建一個。
 

在 DevOps 頻譜的中間，運維角色各不相同。在一些企業(yè)中，除了增加了自動化技能(例如 Puppet、Ansible 和 Chef)之外，其他幾乎沒有變化。其他團隊已經將自動化視為強化運維職責的手段。在某些情況下，運維工程師更接近于開發(fā)人員——掌握了配置管理和其他工具的開發(fā)人員。
 

那么 serverless 對于這些運維定義有什么影響?
 

serverless 之下的運維會變成什么?
 

以下是我對 serverless 運維的未來的看法：
 

•  運維團隊將會消失。

•  運維工程師將被開發(fā)團隊吸收。

•  運維工程師將負責應用程序棧的深層需求。
 

serverless 運維并不是 NoOps，也不是反 DevOps。如果傳統(tǒng)的運維團隊被解散，原先的運維工程師需要新的去處。他們的去處將是各個開發(fā)團隊，而這些團隊會是產品團隊或職能團隊。
 

這樣，能夠處理開發(fā)和運維的跨職能團隊將會迅速崛起。最后，很多運維工程師會發(fā)現自己的優(yōu)勢將比過去更多地被應用到應用程序中。
 

為什么要解散運維團隊?
 

在 DevOps 出現之前，我們看到的是兩個孤島：一個是開發(fā)，一個是運維，他們之間隔著一堵墻，開發(fā)人員將工程設計扔給毫無戒心的運維團隊是日常。DevOps 出現了之后，中間那堵墻被拆掉了，兩個團隊之間的協(xié)作變得更加緊密。
 

但實際上，“拆掉中間那堵墻”對于不同的組織而言也有不同的含義。在某些情況下，它只是意味著更多的會議。現在，有人在向運維“扔東西”之前會先告知他們。
 

但是，你仍然需要獨立團隊，讓他們共同努力交付解決方案。實際上，這可能涉及兩個以上的團隊。
 

還有誰?

•  需要一個項目或產品經理負責監(jiān)督交付過程，確保交付的東西能夠滿足公司的需求。如果你是在一家產品或 SaaS 公司，可能還需要 UX 和設計師確保產品的可用性和外觀。

•  可能涉及多個開發(fā)團隊，前端和后端開發(fā)可能由不同的團隊負責。所有這些獨立的團隊需要共同努力來提供解決方案。
 

特別是產品和 SaaS 公司意識到整個過程效率低下。因此，組織開始重新調整團隊，從職能團隊轉向產品、功能或問題領域。這些功能團隊、產品團隊或其他任何跨職能的團隊都在解決特定領域的問題。
 

這些團隊現在看起來是怎樣的?在我看來，它們通常類似這樣：
 

•  產品或項目經理

•  工程主管

•  前端開發(fā)人員

•  后端開發(fā)人員

•  產品設計師和 / 或用戶體驗研究員(通常是同一個人)
 

產品或項目經理(PM)是業(yè)務需求的所有者和代表。PM 的工作是將業(yè)務需求轉化為明確的目標，同時引導團隊提出促進成功的想法。產品設計師或 UX 研究人員與 PM 合作，收集用戶數據并將想法轉化為設計和原型。技術負責人負責領導工程任務，估算所涉及的技術工作，并適當地為前端和后端工程師提供指導。
 

你最終得到的是一支具備多種能力的團隊，他們都朝著同一個方向前進，從始至終都是這個過程的一部分。這些跨職能的技能讓團隊變得更加強大，從而提供更好的解決方案和服務。
 

然而，運維往往被排除在重新調整之外(雖然有時候運維會組建屬于自己的跨職能團隊，并為其他團隊提供服務)。團隊中的個人通常難以承擔基礎設施的運維需求。因此，當組織的其他部分進行重新調整時，運維仍然是一個獨立的團隊。
 

這已經很好地運作了很長一段時間。對于很多團隊來說，基礎設施并不簡單，他們無法在不影響主要問題領域的情況下進行可靠的交付和運維。
 

但 serverless 顛覆了這種關系。現在，開發(fā)人員可以輕松地交付自己的云基礎設施。事實上，他們需要這么做，因為 serverless 將基礎設施配置和應用程序代碼結合在一起。
 

開發(fā)團隊不需要運維團隊的幫助來交付解決方案。單獨的運維團隊無法在不回歸到守門人角色的情況下將自己插入到服務流程中。但多年來，守門人角色已經在很多組織中消失了。
 

運維團隊的改變不是由 serverless 技術驅動的，而是由 serverless 對組織及其員工的運作方式和履行職責的影響驅動的。
 

當開發(fā)人員不再需要基礎設施時，運維團隊在很大程度上將變得可有可無。當他們遇到小問題時不會再來找你，他們可以自己解決這些問題。
 

運維團隊不再是服務交付流程的一部分，這是遲早的事。 到最后，有人會問為什么這些團隊依然存在。當人們質疑你的工作為什么還會存在時，你的處境將變得很尷尬。
 

但從職責和任務方面來看，運維仍然很重要。構建 serverless 系統(tǒng)仍然需要這些功能。運維團隊的作用在減弱，但對他們的技能仍然有需求，因此需要重新思考運維人員應該被放在什么位置上。這就是為什么說是時候解散運維團隊并讓成員加入產品團隊和功能團隊。
 

產品團隊中的運維角色作為產品團隊成員的運維工程師將扮演怎樣的角色?他們的主要職責是負責團隊服務和系統(tǒng)的健康。這并不意味著他們每次都是第一個收到警報的人，他們應該是這些領域的專家。
 

軟件開發(fā)人員仍然專注于各個組件，而運維工程師專注于整個系統(tǒng)。 他們將采取整體方法確保整個系統(tǒng)正�？煽康剡\行。開發(fā)人員就可以花更少的時間在運維上，就會有更多的時間用于功能開發(fā)。
 

運維工程師還可以為團隊提供幫助。雖然他們的主要職責是確保團隊服務的可靠性，但在必要的時候，也可以承擔其他角色的職責。
 

對于 DevOps 這個術語，有很多定義和實現，但對于我來說，DevOps 團隊的形成才是這個術語最有力的表現。DevOps 是實現成果和價值的人、流程和工具。
 

我們很早就意識到協(xié)作和跨職能團隊在促進成功方面的價值。對于我來說，解散運維團隊并讓成員加入到跨職能團隊中是交付價值的最有效手段。
 

與將人們放在單獨的團隊中相比，你會讓合作變得有多緊密?Serverless 將幫助我們實現許多人多年來一直試圖實現的目標。
 

原文：https://www.serverlessops.io/blog/serverless-devops-where-does-ops-belong

標簽： Serverless 

版權申明：本站文章部分自網絡，如有侵權，請聯系：west999com@outlook.com
特別注意：本站所有轉載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯系。