Serverless基礎架構下，運維人員將何去何從？
正如serverless一詞會讓人感到困惑，運維一詞也是如此。當談話中出現這個術語時，人們會想到不同的東西，這會讓談話變得混亂。
什麼是serverless？serverless是一種架構理念，最新的定義這樣描述它：“serverless架構是基於網際網路的系統，其中應用開發不使用常規的服務程序。相反，它們僅依賴於第三方服務，客戶端邏輯和服務託管遠端過程呼叫的組合。”
運維有著很廣泛的定義。通常，人們會在談話中提到一個不存在運維的場景，但實際上，他們建議作為替代品的東西在我看來仍然是運維。當我們甚至無法就所談論的內容達成一致時，我們該如何討論serverless對運維所帶來的影響呢？
在我們對所談論的內容有了共同的理解之後，讓我們來看看運維人員在serverless中應該屬於處於什麼樣的位置。我認為運維團隊在serverless環境中沒有多大意義。但是，運維人員其實是有價值的。那麼他們應該處在什麼樣的位置上？
什麼是運維？
人們對運維的理解通常是不一樣的，但通常都是正確的。選擇什麼樣的定義取決於一個人的經驗、需求和優先事項，以及他們看問題的角度。然而，這些不同的定義往往會導致人們的交談相互脫節。
從最高層面看，運維是一種實踐，讓支撐業務的技術保持運作 。但如果你深挖一下，運維一詞可以以用在許多方面。因為這些含義緊密耦合了很長時間，人們往往會把它們混為一談。
什麼是運維？運維是：
- 一個團隊
- 一種角色
- 一種責任
- 一組任務
通常，這個角色由運維團隊的運維工程師承擔，他們負責執行與運維相關的任務。近年來，DevOps的出現極大改變了這種局面。曾經有關所有這些定義的死板結構被拆解，由此，定義本身也就分崩離析。
在DevOps頻譜的一端，運維團隊和個體角色基本保持不變。開發人員和運維人員都是獨立的團隊，只是開發團隊開始承擔一部分的運維職責，運維團隊和開發團隊之間的溝通比之前上升了一個層次。當我們聽到有人說“開發人員先收到警報”或開發人員不能再讓程式碼“翻牆”時，我們知道，運維職責發生了變化。
在DevOps頻譜的另一端沒有了運維團隊和個體角色。有些企業將具備運維和軟體開發技能的工程師組合在一起，建立了跨職能團隊。這些企業沒有運維團隊，也沒有計劃組建一個。
在DevOps頻譜的中間，運維角色各不相同。在一些企業中，除了增加了自動化技能（例如Puppet、Ansible和Chef）之外，其他幾乎沒有變化。其他團隊已經將自動化視為強化運維職責的手段。在某些情況下，運維工程師更接近於開發人員——掌握了配置管理和其他工具的開發人員。
那麼serverless對於這些運維定義有什麼影響？
serverless之下的運維會變成什麼？
以下是我對serverless運維的未來的看法：
- 運維團隊將會消失。
- 運維工程師將被開發團隊吸收。
- 運維工程師將負責應用程式棧的深層需求。
serverless運維並不是NoOps，也不是反DevOps。如果傳統的運維團隊被解散，原先的運維工程師需要新的去處。他們的去處將是各個開發團隊，而這些團隊會是產品團隊或職能團隊。
這樣，能夠處理開發和運維的跨職能團隊將會迅速崛起。最後，很多運維工程師會發現自己的優勢將比過去更多地被應用到應用程式中。
為什麼要解散運維團隊？
在DevOps出現之前，我們看到的是兩個孤島：一個是開發，一個是運維，他們之間隔著一堵牆，開發人員將工程設計扔給毫無戒心的運維團隊 是日常 。DevOps出現了之後，中間那堵牆被拆掉了，兩個團隊之間的協作變得更加緊密。
但實際上，“拆掉中間那堵牆”對於不同的組織而言也有不同的含義。在某些情況下，它只是意味著更多的會議。現在，有人在向運維“扔東西”之前會先告知他們。
但是，你仍然需要獨立團隊，讓他們共同努力交付解決方案。實際上，這可能涉及兩個以上的團隊。
還有誰？
- 需要一個專案或產品經理負責監督交付過程，確保交付的東西能夠滿足公司的需求。如果你是在一家產品或SaaS公司，可能還需要UX和設計師確保產品的可用性和外觀。
- 可能涉及多個開發團隊，前端和後端開發可能由不同的團隊負責。所有這些獨立的團隊需要共同努力來提供解決方案。
特別是產品和SaaS公司意識到整個過程效率低下。因此，組織開始重新調整團隊，從職能團隊轉向產品、功能或問題領域。這些功能團隊、產品團隊或其他任何跨職能的團隊都在解決特定領域的問題。
這些團隊現在看起來是怎樣的？在我看來，它們通常類似這樣：
- 產品或專案經理
- 工程主管
- 前端開發人員
- 後端開發人員
- 產品設計師和/或使用者體驗研究員（通常是同一個人）
產品或專案經理（PM）是業務需求的所有者和代表。PM的工作是將業務需求轉化為明確的目標，同時引導團隊提出促進成功的想法。產品設計師或UX研究人員與PM合作，收集使用者資料並將想法轉化為設計和原型。技術負責人負責領導工程任務，估算所涉及的技術工作，並適當地為前端和後端工程師提供指導。
你最終得到的是一支具備多種能力的團隊，他們都朝著同一個方向前進，從始至終都是這個過程的一部分。這些跨職能的技能讓團隊變得更加強大，從而提供更好的解決方案和服務。
然而，運維往往被排除在重新調整之外（雖然有時候運維會組建屬於自己的跨職能團隊，併為其他團隊提供服務）。團隊中的個人通常難以承擔基礎設施的運維需求。因此，當組織的其他部分進行重新調整時，運維仍然是一個獨立的團隊。
這已經很好地運作了很長一段時間。對於很多團隊來說，基礎設施並不簡單，他們無法在不影響主要問題領域的情況下進行可靠的交付和運維。
但serverless顛覆了這種關係。現在，開發人員可以輕鬆地交付自己的雲基礎設施。事實上，他們需要這麼做，因為serverless將基礎設施配置和應用程式程式碼結合在一起。
開發團隊不需要運維團隊的幫助來交付解決方案。單獨的運維團隊無法在不迴歸到守門人角色的情況下將自己插入到服務流程中。但多年來，守門人角色已經在很多組織中消失了。
運維團隊的改變不是由serverless技術驅動的，而是由serverless對組織及其員工的運作方式和履行職責的影響驅動的。
當開發人員不再需要基礎設施時，運維團隊在很大程度上將變得可有可無。當他們遇到小問題時不會再來找你，他們可以自己解決這些問題。
運維團隊不再是服務交付流程的一部分，這是遲早的事。到最後，有人會問為什麼這些團隊依然存在。當人們質疑你的工作為什麼還會存在時，你的處境將變得很尷尬。
但從職責和任務方面來看，運維仍然很重要。構建serverless系統仍然需要這些功能。運維團隊的作用在減弱，但對他們的技能仍然有需求，因此需要重新思考運維人員應該被放在什麼位置上。這就是為什麼說是時候解散運維團隊並讓成員加入產品團隊和功能團隊。
產品團隊中的運維角色
作為產品團隊成員的運維工程師將扮演怎樣的角色？他們的主要職責是負責團隊服務和系統的健康 。這並不意味著他們每次都是第一個收到警報的人，他們應該是這些領域的專家。
軟體開發人員仍然專注於各個元件，而運維工程師專注於整個系統。他們將採取整體方法確保整個系統正常可靠地執行。開發人員就可以花更少的時間在運維上，就會有更多的時間用於功能開發。
運維工程師還可以為團隊提供幫助。雖然他們的主要職責是確保團隊服務的可靠性，但在必要的時候，也可以承擔其他角色的職責。
對於DevOps這個術語，有很多定義和實現，但對於我來說，DevOps團隊的形成才是這個術語最有力的表現。DevOps是實現成果和價值的人、流程和工具。
我們很早就意識到協作和跨職能團隊在促進成功方面的價值。對於我來說，解散運維團隊並讓成員加入到跨職能團隊中是交付價值的最有效手段。
與將人們放在單獨的團隊中相比，你會讓合作變得有多緊密？Serverless將幫助我們實現許多人多年來一直試圖實現的目標。
英文原文：ofollow,noindex" target="_blank">https://www.serverlessops.io/blog/serverless-devops-where-does-ops-belong
感謝張嬋對本文的審校。