假設(shè)您在過去15年左右的時間里一直在關(guān)注，無服務(wù)器只是正在進(jìn)行的Ops從戰(zhàn)術(shù)向戰(zhàn)略轉(zhuǎn)變的最新動向。在本文中談到了無服務(wù)器對Ops的真正威脅，無服務(wù)器計算的潛在弊端等等。

無服務(wù)器計算，就像它繼承自云計算主題的其他變體一樣，可以歸結(jié)為“這是別人的計算機(jī)”。在無服務(wù)器的情況下，它要復(fù)雜得多。這是對傳統(tǒng)IT模式的膚淺熟悉的最后遺跡終于消失了，迫使任何仍將云計算視為同一個舊事物的人都要面對事實。

人們可以并且確實仍然像對待VM一樣對待AMI，這反過來又以與他們始終管理其物理計算基礎(chǔ)架構(gòu)相同的方式進(jìn)行管理。當(dāng)然，這幾乎完全錯過了虛擬化和云計算的要點，但并沒有立即失敗。這些問題只有隨著時間的推移變得明顯，在容量和利用率預(yù)測的改善，從虛擬化神秘未能實現(xiàn)。更糟糕的是，運行中的僵尸VM消耗了很大一部分可用容量，沒有人能夠解釋或證明它們是合理的，但是每個人都害怕關(guān)閉，以防它們變得很重要。

發(fā)生這種情況的原因是–令人驚訝！–行動很難。無服務(wù)器計算的想法是擺脫日常的事務(wù)性O(shè)ps任務(wù)，讓Dev更快地推出代碼，并讓基礎(chǔ)架構(gòu)主要由自己來管理。與其試圖通過讓Ops Morlocks大軍在幕后努力支持Dev Eloi來“做DevOps”，沒有服務(wù)器的幕后沒有巫師。那里確實是自動化機(jī)械，這使開發(fā)人員有空去進(jìn)行他們正在建造的任何東西。

開發(fā)團(tuán)隊大多熱情地接受了變化。消除部署過程麻煩的任何方法都是好的，如果不需要開發(fā)人員選擇隱喻的尋呼機(jī)，那就更好了。當(dāng)然，這并不是說無服務(wù)器沒有問題；畢竟，在我們生活的這個墮落的世界中，這沒有任何機(jī)會。畢竟，如果云是其他人的計算機(jī)，那么無服務(wù)器意味著您的代碼現(xiàn)在依賴于在其他人的計算機(jī)上運行的其他人的代碼。這種事情在工作時會很好，但是這種不可靠的遠(yuǎn)程服務(wù)的假設(shè)尚未完全內(nèi)部化。

有關(guān)引入的各種依賴關(guān)系的示例，請看一下2016年的左鍵盤崩潰。如果您設(shè)法擦除了相關(guān)的內(nèi)存，則左鍵盤是NPM中的11行模塊，實現(xiàn)了基本字符串填充。無論出于何種原因，成千上萬的項目都將此作為依賴項，并且當(dāng)開發(fā)人員撤出其所有模塊（包括左鍵盤）時，隨之而來的是混亂。

無服務(wù)器與Ops有何關(guān)系？

對于無服務(wù)器的開發(fā)人員來說，太多了–但我是一個真正的Ops家伙；我曾經(jīng)是一名系統(tǒng)管理員，盡管我在Moogsoft擔(dān)任戰(zhàn)略架構(gòu)職務(wù)已經(jīng)走了很長一段路，但我仍然大多以這種方式思考，而且我在Ops的人們中度過了很多時間。事情是這樣的：許多Ops員工會錯過無服務(wù)器的意義，因為應(yīng)用程序的使用模型是相同的，并且它們在熟悉的基礎(chǔ)架構(gòu)之上運行–那么，這到底是什么意思呢？當(dāng)然，開發(fā)人員都非常興奮，但這與Ops有什么關(guān)系？

某些操作人員甚至感到受到威脅：“我的工作是照顧服務(wù)器，現(xiàn)在您正在談?wù)摂[脫它們！” 這是相同的類別錯誤，這是由于先將物理服務(wù)器叉入VMware，然后再轉(zhuǎn)移到云中，而又沒有改變您的想法的緣故。如果您將工作定義為在有人想完成涉及IT的任何事情時把手放在鍵盤上（如今這意味著幾乎所有事情），那么是的，這項工作正在消失。無服務(wù)器可能不是棺材的最后釘子，但蓋子已經(jīng)牢牢地固定住了。

假設(shè)您在過去15年左右的時間里一直在關(guān)注，無服務(wù)器只是正在進(jìn)行的Ops從戰(zhàn)術(shù)向戰(zhàn)略轉(zhuǎn)變的最新動向。Ops并沒有積極參與交付每個請求，而是定義了可用基礎(chǔ)結(jié)構(gòu)的功能和參數(shù)，然后將交付和日常運行移交給自動化。

這聽起來像是NoOps，但是我寧愿回到操作員（基本上是磁帶騎師）與實際系統(tǒng)管理員之間的舊區(qū)別，而不是踢那個螞蟻山。如果您涉及日常事務(wù)，則表示您不是系統(tǒng)管理員。適當(dāng)?shù)南到y(tǒng)管理員會小睡一會，將腳撐在已停用的服務(wù)器上，并確保一切正常，以確保安全–因為否則，某些事情已經(jīng)告訴他們了。

微軟自己對無服務(wù)器的主張是：“如果您將所有時間都花在構(gòu)建和部署出色的應(yīng)用程序上，而又沒有時間管理服務(wù)器該怎么辦？” 這并不意味著不對服務(wù)器進(jìn)行管理，只是不對它們進(jìn)行手工管理。沒有開發(fā)人員或用戶知道或關(guān)注基礎(chǔ)結(jié)構(gòu)的詳細(xì)信息，這是應(yīng)有的。效用計算意味著計算基礎(chǔ)設(shè)施與外部人的電網(wǎng)一樣有趣。當(dāng)然，這很重要，如果它破裂了，我們所有人都會度過糟糕的一天，但是除非維護(hù)它是您的實際工作，否則您只需插上電源，不要再想一想-維護(hù)它的人當(dāng)然不會花錢他們的日子在鄉(xiāng)下開車，手工布線變壓器是因為。

到目前為止，一切都很好–但是無服務(wù)器計算的潛在弊端是什么？

首先，因為它與（某些）Ops團(tuán)隊如何看待自己及其在世界上的地位相悖，所以很有可能將它作為IT預(yù)算之外不斷增加的IT支出比例的一部分來進(jìn)行。是的，那就是臭名昭著的影子IT再來一次。我在Ops團(tuán)隊中度過了很多時間，如果您向他們詢問有關(guān)無服務(wù)器的問題，通常他們會嘲笑并暗示盡管實驗室中的某人可能正在玩這種服務(wù)器，但沒有發(fā)生任何嚴(yán)重的事情。然后在下周的第二天，您將看到一份新聞稿，其中介紹了同一家公司如何在AWS Lambda或其他產(chǎn)品上推出巨大的新的關(guān)鍵業(yè)務(wù)服務(wù)。這種事情不會一次發(fā)生，而是反復(fù)發(fā)生。無服務(wù)器對Ops的真正危險不是因為它使它們不相關(guān)，而是通過忽略它們使自身不相關(guān)。

Ops可以通過幫助制定策略來安全地采用這些新方法，從而做出真正的貢獻(xiàn)。畢竟，Dev和Ops的無服務(wù)器體系結(jié)構(gòu)在概念上都有大量開銷。

首先，在您的產(chǎn)品投入生產(chǎn)之前，最好先對其進(jìn)行測試。（暫停一下，歇斯底里的笑聲消失了。）（停頓了更長的時間。）（好吧，我認(rèn)為我們現(xiàn)在很好。）即使您自己的代碼具有良好的測試覆蓋率，您如何處理類似左手的代碼？墊？或說Google以通常的難懂程度來貶低您所依賴的東西。您如何在測試中說明這一點？

價格如何？Google談到要“從原型到生產(chǎn)再到星球規(guī)?！?。這對開發(fā)人員在開始構(gòu)建新事物時非常有用，因為您可以花很多錢就可以開展一個項目。但是，如果你被鞭炮割怎么辦？（是的，在那兒顯示我的年齡。）一旦在現(xiàn)實世界中碰到，設(shè)計決定可能會在白板上進(jìn)行，可能會對業(yè)務(wù)產(chǎn)生重大影響。如果容量可以從零增加到無限，那么您的支出也可以。一個不再運行重新映像服務(wù)器的優(yōu)秀Ops團(tuán)隊?wèi)?yīng)該考慮這種事情。

不過，僅僅因為他們不必重新安裝操作系統(tǒng)，并不意味著Ops團(tuán)隊處于閑置狀態(tài)。系統(tǒng)管理員只有在確定自己所護(hù)理的系統(tǒng)沒有發(fā)生任何不良情況的情況下，才能進(jìn)行恢復(fù)性小睡。這曾經(jīng)意味著在服務(wù)器上運行著監(jiān)視代理程序，并且已經(jīng)預(yù)先仔細(xì)定義了故障條件：IF this_happens和that_happens然后wake_up_sysadmin。

如今，平臺是自給自足的，并且在很大程度上是自推式的。訣竅是弄清楚了解和反應(yīng)的重要內(nèi)容以及可以安全忽略的內(nèi)容?，F(xiàn)代IT的復(fù)雜性越過了那種確定性方法在不久前就不再有用的門檻，但是無服務(wù)器確實可以解決這個問題。隨著服務(wù)幾乎完全與基礎(chǔ)架構(gòu)的特定部分脫離，舊的跟蹤方法不再起作用。

如果Ops不與Dev團(tuán)隊互動-記住，他們已經(jīng)在無處不在，以某種方式進(jìn)行Opserver的工作，無論Ops怎么想-這樣做的結(jié)果就是Dev將Dev解釋為損害并繞過它。然后，當(dāng)不可避免地發(fā)生故障時，運維團(tuán)隊的傳呼機(jī)仍然會打斷并打擾他們的睡眠。