運維百家講壇，通過采訪和約稿的方式，請運維領域老炮輸出深刻洞見，共同碰撞，以期形成一些先進的共識，推動行業更好得前進。
這一期我們邀請到的是王明松，王老板針對云原生應用實踐，提出“王四條”，在業內廣受認可。從19年開始，王老板所在公司的所有IDC業務就全部搬到了云上，體量還不小，SRE團隊卻很小，有點NetFlix的味道。這一講，我們一起了解一下資深云上運維到底是怎么玩的。
這里是接地氣、有高度的《運維百家講壇》第 7 期，開講！
問題預覽
- 初識王老板，是因為微信群里的一次討論，王老板提出了四條云原生應用實踐，認為只要做到了這四條，應用基本就是云原生的了，群友們深表認同，并且命名為“王四條”，可否請王老板給 SRETalk 的讀者再分享一下“王四條”中的精粹？
- “王四條”中羅列了一些最佳實踐，需要研發一起配合，在公司內部落地的時候，不知道是否會遇到阻礙？您又是如何擺平的呢？
- 最近有些文章講述他們綜合衡量 ROI 覺得下云更劃算，比如 RoR 之父的文章，比如運維百家講壇上一期途游游戲鄒總，看起來您更傾向于深度用云，能否給大家分享一下您的思考？
- 最近有個文章《運維的未來是平臺工程》，您認可這個觀點么？在平臺工程方面您的團隊承擔了一個什么角色和邊界？您是怎么規劃所謂的平臺工程的呢（尤其是在多云環境下）？
- 王老板這樣的工作模式下，感覺只需要非常資深的人，新鮮血液太嫩，沒法承擔研發教練的角色，但是沒有新鮮血液，也沒法長期維計，能否分享一下您是如何建設您的梯隊的？
- 我們知道，明松你一直是“運維自我革命”的鼓吹手，這是“反人性”的，能談談這背后的思考嗎？
嘉賓介紹
開始之前，先請王老板做個自我介紹吧。聊聊工作履歷，尤其是用云的經歷，給大家輸入一些背景信息。
大概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，我也會不定期的更新云原生王四條
簡要版的內容是：
- 用對象存儲靜態文件
- 用role不能用ak sk
- 盡量用托管服務
- 數據不要存在服務器上
這四條的出發點其實基本上是圍繞著應用的無狀態和數據的安全來做，同時會兼顧成本，性能和可靠性，適應范圍其實也不局限于云計算，傳統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，什么平臺，都是運維工作的一小部分，我們應該把自己從這些糾結里解放出來，給自己解綁，也給產研團隊解綁，做好我們管理和監管視角的工作。
擴展閱讀
- ??運維百家講壇第6期：途游鄒軼 – 中小公司的運維怎么做？??
- ??運維百家講壇第5期：度小滿陳存利 – 20年老“司令”聊運維、績效、成長??
- ??運維百家講壇第4期：又拍云邵海楊 – 25年linux老兵聊DevOps八榮八恥??
- ??運維百家講壇第3期：來煒 – 如何把運維的飯碗端穩??
- ??運維百家講壇第2期：作業幫聶安 – 運維如何轉型，聽聽作業幫的OPaS思路??
- ??運維百家講壇第1期：井源 – 運維幾何??
