維百家講壇，透過訪談和約稿的方式，請維運領域老砲輸出深刻洞見，共同碰撞，以期形成一些先進的共識，推動產業更好得前進。
這一期我們邀請到的是王明松，王老闆針對雲原生應用實踐，提出“王四條”，在業內廣受認可。從19年開始，王老闆所在公司的所有IDC業務就全部搬到了雲端上，體積還不小，SRE團隊卻很小，有點NetFlix的味道。這一講，我們一起了解資深雲上運維到底是怎麼玩的。
這裡是接地氣、有高度的《運維百家講壇》第 7 期，開講！
開始之前，先請王老闆做個自我介紹。聊聊工作履歷，尤其是用雲端的經歷，給大家輸入一些背景資訊。
大概2005年前後，在學校搞過BBS的運維，算是入門。畢業後入職現在已經略微沒落的某網路大廠（編按：是指百度），跨行從P1級的運維開始做。 2010年跑路去了一家行動網路創業公司，當時基本上系統網路佈線機房IT啥都做，伺服器的採購週期就算小公司也會略長，所以當時就開始考慮用雲了。
2011年開始，曾經用過一段時間曙光雲，基於vmware的，體驗就很差，從我個人的角度來看可用性和經濟性都沒有，唯一就是可能上機器比idc快吧。然後網路也是怪怪的，造成了很多困擾。同時期也花了一段時間盛大雲，這個體驗比中科曙光強一些，但其實也是vps的水準吧。感覺vpc那層都沒做。沒敢放上去太重要的資源，後來屢次拉跨就沒再用了（可能是我用的方式不對加上也不好監控）。
2013年開始用ucloud，這也主要是用虛擬機，別的用的不多。但是vpc產品當時應該有了，會把一些重要業務往上放了。
2014年因為開始做出海，所以開始用aws。 2019年把所有IDC業務全部遷移到了雲端。
初識王老闆，是因為微信群組裡的一次討論，王老闆提出了四條雲原生應用實踐，認為只要做到了這四條，應用程式基本上就是雲原生的了，群友們深表認同，並且命名為“王四條”，可否請王老闆給SRETalk 的讀者再分享一下“王四條”中的精粹？
雲原生王四條詳細版的內容我放到瑞典馬工的repo（ https://github.com/lipingtababa/cloud-native-best-practices ）裡了，歡迎大家提issue，我也會不定期的更新雲原生王四條
#簡要版的內容是：
這四條的出發點其實基本上是圍繞著應用的無狀態和數據的安全來做，同時會兼顧成本，效能和可靠性，適應範圍其實不限於雲端運算，傳統IDC也可以參考來實施。
編按：這個簡版內容看起來不多，實際內有乾坤，建議大家讀一下，雲原生王四條這個連結如果點擊不了，就移步到上面的repo，從中找雲原生王四條.md 即可。
「王四條」中羅列了一些最佳實踐，需要研發一起配合，在公司內部落地的時候，不知道是否會遇到阻礙？您又是如何擺平的呢？
我幾乎沒有遇到任何阻礙，但是這是因為我們有自己的情況。
一方面是我們當時除了上雲別無選擇，而且成本管控是硬指標，沒有其他可以綏靖的路線可以選。
我們是團隊分拆出來的新公司，所以只給了一年的時間做過渡，管理層給的目標就是把現有幾千台機器上跑著的還挺賺錢的業務無縫的遷移出來。因為我們當時只做海外，所以壓根沒考慮非雲端的方案，但是管理階層依然要求雲端成本相較於之前用IDC要更省。
如果直接把原來的架構直接搬到雲端上去，那麼管理層給的成本目標是肯定無法達成的（這個pigsty的馮老闆已經寫了很多類似的文章來佐證傳統IDC對雲的成本優勢了），所以當時的選擇只有一條：就是對現有的架構進行改造，使之適應雲，從而使之遷移後即可達到成本，性能，穩定性的目標。
另一方面，讓研發在選型和成本優化上充分參與進來，大家形成共識。
我大概提前花一年時間開始對公有雲做選型，並且專門參加培訓來學習如何更好的使用雲，也逐步形成了自己的方法論。在遷移前也帶領研發的主幹成員去參加相關的培訓，透過培訓後他們也能理解我的許多做法是對的，而且實際遷移中，AWS也提供了比較專業的方案設計。所以「王四條」的內容落地是比較容易的，例如：
1，資料存EBS非常貴，那麼存S3就是非常經濟的選擇，透過訓練和各種方案對比，研發非常明確這個情況，所以會有比較大的意願去做程序的修改。
2，Role這個是安全要求，因為AWS的sdk支援的非常好，剛上手的時候使用Role還是ak sk沒有任何難度區別，從一開始就把控好，對於研發而言沒問題。
3，託管服務這個，其實研發並不關心是運維去做還是用現有的服務。這個只要我們運維放得下執念就可以。
4，資料不要存在伺服器上。其實我們是經歷了一次比較大的磨合。
我們這次遷移是從一個有完備的平台支援的IDC環境遷移到AWS，在AWS的partner的幫助下，新架構按照AWS的最佳實踐設計，並且滿足了先前的使用習慣和要求。
但是因為做了重構，使用上還是有差異的。因為使用了ASG，所以在縮容或故障遷移時，伺服器是直接幹掉的，上面如果要存持久化資料的話就沒了，所以這次之後，研發基本能接受線上業務資料不存在伺服器上了。
而且因為這個設計，我們對於伺服器儲存的要求就可以能多小就多小，超過100G的都需要我審核。節省了大量的EBS成本
後續，研發在做K8S的部署的時候，對於這個的理解就更加深刻了，畢竟容器裡的資料都是會遺失的。
最近有些文章講述他們綜合衡量ROI 覺得下雲比較划算，像是RoR 之父的文章，像是維運百家講壇上一期途遊遊戲鄒總，看起來您更傾向於深度用雲，能否給大家分享一下您的思考？
我其實一直在鼓吹“最佳實踐”，但是我也跟大家交流過“最佳實踐是投資人或管理層的帝王之術”，使用最佳實踐很可能就是要砸自己和很多人的飯碗才能達到最優，如果以不砸飯碗的前提下實現最優，選擇就會更多樣化。
下雲還是上雲，得看利益出發點，也得看管理層支持的力度，還得看歷史包袱。如果我在鄒總或DHH的位子上，也未必會堅持我現在的觀點。我能堅持在雲端：
一方面是管理層的認可，管理層都吃過資產閒置的虧，我做了很久的閒置IDC資源的優化的工作，所以加上出海自建機房也不是特別容易，上雲基本上就是管理階層支持的唯一方案。
另一方面也是如上面所說機緣巧合，我們架構改造的很徹底，而且改造成本是管理階層支持的，可以充分利用雲端的優勢。
最後一點，我們的業務形態到現在還沒有一個長期穩定的高負載而且無狀態的業務。這種業務比較適合傳統IDC。
我相信鄒總或DHH現在去改造他們現有系統的架構，付出的成本太高了，即使說可以因此削減運維部門的人力成本，可能很難得到支持，因為這還涉及到其他部門的利益。
但是如果是新公司新項目，我相信沒有比雲端更合適的場景了，選一家合適的雲端廠商，採用雲原生的架構來實現業務，使整個業務從性能和成本上都是彈性的。
很多朋友吐槽雲殺豬，鎖定之類的。但從投資人或管理階層的角度看，一切要素都是為了達成業務的獲利，人/雲端/IDC等都是實現業務的要素，投資人想實現業務，不僅要為這些要素支付成本，還要能及時取得到符合需求的要素（這更重要）。雲端這個要素的取得再簡單不過了，相對而言非常標準的產品品質和價格，點幾下就可以付款使用了，可以按需可以包週期，但是隨時都可以停止使用。但是人呢？人的取得很難，品質也很難明確，也不是標準化的，會有價格的波動（加薪），不能隨便裁，離職也不會幫你頂替一個絕對一摸一樣的。人可以是很有創造力的，但是在標準化和機械枯燥的事情方面，人永遠不是機器的對手，更不是SaaS服務的。
對於鄒總的情況，如果他們業務團隊不願意改造程式架構的話，他現在的選擇就是最佳實踐了：穩定高負載的業務選用成本有優勢的IDC，並且租賃機器而不是購買；彈性業務的上雲。
對於37signals 的Basecamp，從產品的定價模式設定上就決定了他們上雲有點麻煩。現在大多數SaaS服務都是按用量或使用人數付費的，但Basecamp主要賣無限制套餐，一個月只有199刀。這個定價模式就導致他們無法充分利用雲端的彈性來獲利，而只能走低價資源的超賣。不改變這個定價模式，無論怎麼優化架構恐怕也不太適合雲端。
最近有個文章《維運的未來是平台工程》，您認可這個觀點麼？在平台工程方面您的團隊承擔了一個什麼角色和邊界？您是怎麼規劃所謂的平台工程的呢（尤其是在多雲環境下）？
是阮一峰寫的還是Charity Majors 寫的？不過這兩篇我之前沒看過，剛簡要的看了一下。我不完全認可這個，而且我個人也不會去嘗試做內部的平台工程。
先說一下不認同的地方吧：就是那篇文章對於概念有些誤解。
首先，DevOps不是一個職位，我曾經試著理解了很久，最終的感覺就是這是一種開發模式。但這個開發模式的核心是研發，所有的要素都要圍繞著高效率的研發迭代服務。那篇文章前面認為DevOps是個職位，後面又認為這個職位是開發業務的，我覺得都是不妥當的理解。
其次，維運對未來的探索是很豐富的。轉型不是新話題，大家很早就明白維運這個產業是夕陽產業了，過去這十多年，有很多維運都在嘗試轉型，找下一步的出路，有試圖搞CI/CD的，有嘗試做監控研發的，有嘗試做自動化維運平台研發的，有嘗試搞新領域（例如K8s，大數據，AI，雲端運算之類的），也有嘗試轉向其他子項的（例如DBA，網路安全）。
可以看出來這些轉型很多都是服務DevOps這個開發模式的。
平台工程或許是一種實現模式，但是以運維群體的產品力和研發水平，自己搞平台工程恐怕只能自娛自樂，甚至連穩定性都無法保證，徒增背鍋可能。但是如果引入更專業的產研團隊去做，一方面是不務正業跟主營業務收入無關很難得到支持，另外一方面只是自用的平台，拉這麼多人做一個沒有收入的產品並不經濟，更何況這種做法對於現有的維運而言沒有參與感，不算轉型。
所以，我認為正確的做法是自己用成熟的平台和工具（開源/付費自建，使用SaaS均可），可以基於這些平台做一些定制和二開，但是不要造輪子。
最後，我對那篇文章中平台的理解也不一樣。
一方面，平臺本身就可以是SaaS的形式去提供，不需要二開整合，現在主要是國內SaaS環境不佳，以及軟體服務也不重視相互集成兼容，而更喜歡做大而全。我們把目光放到海外就會發現海外有很多細分領域的SaaS或者軟體，做的很好而且可以跟其他軟體集成，生態很好所以集成很容易配置，沒有太多二開的工作量。
另一方面，平台的使用者應該是研發，研發應該可以直接使用，而不需要維運去轉達，審核。
所以未來的確需要用平台，是專業的產研團隊做的平台，而不是自己做的玩具；是產研團隊來直接使用的平台，而不是維運攔在中間做傳話筒。
所以對於平台工程，我選擇積極的使用成熟的軟體或SaaS服務，並且盡可能提供給產研團隊直接使用。
維運只基於成本和安全做一些必要的卡口，透過策略，權限，審計來控制，保證產研團隊可以正確的使用。
王老闆這樣的工作模式下，感覺只需要非常資深的人，新鮮血液太嫩，沒法承擔研發教練的角色，但是沒有新鮮血液，也沒辦法長期維計，能否分享一下您是如何建造您的梯隊的？
這個問題很好，因為我的確也沒解決。這不是這種工作模式的問題。
對於資深人才的需求，很多公司，很多工種都是有的，一樣面臨我現在的問題。什麼工種才不需要資深人才呢？我認為是工作內容已經非常標準化，公司要求不高，隨便一個人都能根據需求就能明確指示做好。連機器就能做好。
鄒總有個說法是傳統運作類似保潔，工作內容重要但是價值不高。我比較認同這個說法，這就是我們現在維運面臨的困境。那麼清潔團隊他們自研清潔工具還是去採購？
因為採用了大量成熟的產品和外部服務，我如同清潔使用各種自動半自動的清掃工具一樣，可以比較穩定的輸出清掃任務。但不需要擔心某個清潔能力欠缺導致拖地不乾淨，不夠敬業導致簡單掃一遍就交差。固然要操作好這些工具，保潔需要學習的比傳統工具要多一點難一點，但是整體的SOP要比原來要少，因為成熟的工具屏蔽了細節。
所以，我們不要在低價值的工作內容上浪費時間，這類工作用專業的軟體或SaaS來完成，它們有規模效應，功能好還有SLA。我們應該把工作重點放在業務，管理階層，投資人更關心的領域。
我們知道，王老闆一直是「維運自我革命」的鼓吹手，這是「反人性」的，能談談這背後的思考嗎？
我們現在看到的事實就是維運並不是一個蓬勃發展的行業，絕大多數企業並不會有一個龐大的維運部來支撐企業的系統運轉，甚至可能只需要一個人，這個人還會兼任IT，網管，安全之類的工作。我們沒有上升空間了，維運總監極少，維運經理基本上就是極限了，以我現在管理的人數，叫我維運主管都可以。
現在業界也是這樣的狀態，大量訓練班速成的運維，夠用而且價廉。中高端運維很少，維運不像是網工或DBA，我們技術棧非常雜，沒有權威的認證標註我們的能力，這一方面不利於我們規劃職業路線，也不利於形成一個良性的人才市場。所以市場對於我們維運的定位其實就是打雜了，「不寫業務程式碼的那個技術」可能是我們最精確的定位。
根據DevOps的理念，我們應該是加速業務的交付，做好服務，而不是添亂給產研使絆子。但維運的意義和工作不只在於DevOps，這也是我跟很多人觀點不一樣的地方。
一方面，維運是公司數位資產的“看門狗”，從這個角度上看，維運代表管理層和投資人的利益，對公司的數位資產進行妥善的保管，保證其能正確的使用，滿足各種監管要求，參與各種內部審計。是管理階層對於產研團隊的製衡。這其實就是最初運維的意義。
另外一方面，國家賞飯吃。監管要求日益嚴格，無論是網路安全，資料安全或個人資訊保護，都需要有專人負責相關工作。對於小規模的企業而言，這些工作必然是維來兼任，特別是資料安全，直接掌管數位資產的運維肯定要參與的。這是新時代對維運的要求。
所以如果想明白這些，你就會發現什麼Devops，什麼平台，都是維運工作的一小部分，我們應該把自己從這些糾結裡解放出來，給自己解綁，也給產研團隊解綁，做好我們管理和監管視角的工作。
以上是自我革命的「王四條」是怎麼練成的的詳細內容。更多資訊請關注PHP中文網其他相關文章！
