自我革命的“王四條”是怎樣練成的
原創(chuàng)
運(yùn)維百家講壇，通過采訪和約稿的方式，請運(yùn)維領(lǐng)域老炮輸出深刻洞見，共同碰撞，以期形成一些先進(jìn)的共識，推動行業(yè)更好得前進(jìn)。
這一期我們邀請到的是王明松，王老板針對云原生應(yīng)用實(shí)踐，提出“王四條”，在業(yè)內(nèi)廣受認(rèn)可。從19年開始，王老板所在公司的所有IDC業(yè)務(wù)就全部搬到了云上，體量還不小，SRE團(tuán)隊(duì)卻很小，有點(diǎn)NetFlix的味道。這一講，我們一起了解一下資深云上運(yùn)維到底是怎么玩的。
這里是接地氣、有高度的《運(yùn)維百家講壇》第 7 期，開講！
問題預(yù)覽
- 初識王老板，是因?yàn)槲⑿湃豪锏囊淮斡懻?，王老板提出了四條云原生應(yīng)用實(shí)踐，認(rèn)為只要做到了這四條，應(yīng)用基本就是云原生的了，群友們深表認(rèn)同，并且命名為“王四條”，可否請王老板給 SRETalk 的讀者再分享一下“王四條”中的精粹？
- “王四條”中羅列了一些最佳實(shí)踐，需要研發(fā)一起配合，在公司內(nèi)部落地的時候，不知道是否會遇到阻礙？您又是如何擺平的呢？
- 最近有些文章講述他們綜合衡量 ROI 覺得下云更劃算，比如 RoR 之父的文章，比如運(yùn)維百家講壇上一期途游游戲鄒總，看起來您更傾向于深度用云，能否給大家分享一下您的思考？
- 最近有個文章《運(yùn)維的未來是平臺工程》，您認(rèn)可這個觀點(diǎn)么？在平臺工程方面您的團(tuán)隊(duì)承擔(dān)了一個什么角色和邊界？您是怎么規(guī)劃所謂的平臺工程的呢（尤其是在多云環(huán)境下）？
- 王老板這樣的工作模式下，感覺只需要非常資深的人，新鮮血液太嫩，沒法承擔(dān)研發(fā)教練的角色，但是沒有新鮮血液，也沒法長期維計，能否分享一下您是如何建設(shè)您的梯隊(duì)的？
- 我們知道，明松你一直是“運(yùn)維自我革命”的鼓吹手，這是“反人性”的，能談?wù)勥@背后的思考嗎？
嘉賓介紹
開始之前，先請王老板做個自我介紹吧。聊聊工作履歷，尤其是用云的經(jīng)歷，給大家輸入一些背景信息。
大概2005年前后，在學(xué)校里搞過BBS的運(yùn)維，算是入門。畢業(yè)后入職現(xiàn)在已經(jīng)略微沒落的某互聯(lián)網(wǎng)大廠（編者注：是指百度），跨行從P1級的運(yùn)維開始做。2010年跑路去了一家移動互聯(lián)網(wǎng)創(chuàng)業(yè)公司，當(dāng)時基本上系統(tǒng)網(wǎng)絡(luò)布線機(jī)房IT啥都做，服務(wù)器的采購周期就算小公司也會略長，所以當(dāng)時就開始考慮用云了。
2011年開始，曾經(jīng)用過一段時間曙光云，基于vmware的，體驗(yàn)就很差，從我個人的角度來看可用性和經(jīng)濟(jì)性都沒有，唯一就是可能上機(jī)器比idc快吧。然后網(wǎng)絡(luò)也是怪怪的，造成了很多困擾。同時期也用了一段時間盛大云，這個體驗(yàn)比中科曙光強(qiáng)一些，但是其實(shí)也是vps的水準(zhǔn)吧。感覺vpc那層都沒有做。沒敢放上去太重要的資源，后來屢次拉跨就沒再用了（可能是我用的方式不對加上也不好監(jiān)控）。
2013年開始用ucloud，這個也主要是用虛擬機(jī)，別的用的不多。但是vpc產(chǎn)品當(dāng)時應(yīng)該有了，會把一些重要業(yè)務(wù)往上放了。
2014年因?yàn)殚_始做出海，所以開始用aws。2019年把所有IDC業(yè)務(wù)全部遷移到了云上。
采訪問題
初識王老板，是因?yàn)槲⑿湃豪锏囊淮斡懻摚趵习逄岢隽怂臈l云原生應(yīng)用實(shí)踐，認(rèn)為只要做到了這四條，應(yīng)用基本就是云原生的了，群友們深表認(rèn)同，并且命名為“王四條”，可否請王老板給 SRETalk 的讀者再分享一下“王四條”中的精粹？
云原生王四條詳細(xì)版的內(nèi)容我放到瑞典馬工的repo（ https://github.com/lipingtababa/cloud-native-best-practices ）里了 ，歡迎大家提issue，我也會不定期的更新云原生王四條
簡要版的內(nèi)容是：
- 用對象存儲靜態(tài)文件
- 用role不能用ak sk
- 盡量用托管服務(wù)
- 數(shù)據(jù)不要存在服務(wù)器上
這四條的出發(fā)點(diǎn)其實(shí)基本上是圍繞著應(yīng)用的無狀態(tài)和數(shù)據(jù)的安全來做，同時會兼顧成本，性能和可靠性，適應(yīng)范圍其實(shí)也不局限于云計算，傳統(tǒng)IDC也可以參考來實(shí)施。
編者注：這個簡版內(nèi)容看起來不多，實(shí)際內(nèi)有乾坤，建議大家讀一下，云原生王四條這個鏈接如果點(diǎn)擊不了，就移步到上面的 repo，從中找 云原生王四條.md 即可。
“王四條”中羅列了一些最佳實(shí)踐，需要研發(fā)一起配合，在公司內(nèi)部落地的時候，不知道是否會遇到阻礙？您又是如何擺平的呢？
我?guī)缀鯖]有遇到任何阻礙，但是這是因?yàn)槲覀冇凶约旱那闆r。
一方面是我們當(dāng)時除了上云別無選擇，而且成本管控是硬指標(biāo)，沒有其他可以綏靖的路線可以選。
我們是團(tuán)隊(duì)分拆出來的一個新公司，所以只給了一年的時間做過渡，管理層給的目標(biāo)就是把現(xiàn)有幾千臺機(jī)器上跑著的還挺賺錢的業(yè)務(wù)無縫的遷移出來。因?yàn)槲覀儺?dāng)時只做海外，所以壓根沒考慮非云的方案，但是管理層依然要求云上成本相較于之前用IDC要更省。
如果直接把原來的架構(gòu)直接搬到云上去，那么管理層給的成本目標(biāo)是肯定無法達(dá)成的（這個pigsty的馮老板已經(jīng)寫了很多類似的文章來佐證傳統(tǒng)IDC對云的成本優(yōu)勢了），所以當(dāng)時的選擇只有一條：就是對現(xiàn)有的架構(gòu)進(jìn)行改造，使之適應(yīng)云，從而使之遷移后即可達(dá)到成本，性能，穩(wěn)定性的目標(biāo)。
另外一方面，讓研發(fā)在選型和成本優(yōu)化上充分參與進(jìn)來，大家形成共識。
我大概提前花一年時間開始對公有云做選型，并且專門參加培訓(xùn)來學(xué)習(xí)如何更好的使用云，也逐步形成了自己的方法論。遷移前也帶領(lǐng)研發(fā)的主干成員去參加相關(guān)的培訓(xùn)，通過培訓(xùn)后他們也能理解我的很多做法是對的，而且實(shí)際遷移中，AWS也提供了比較專業(yè)的方案設(shè)計。所以“王四條”的內(nèi)容落地是比較容易的，比如：
1，數(shù)據(jù)存EBS非常貴，那么存S3就是非常經(jīng)濟(jì)的選擇，通過培訓(xùn)和各種方案對比，研發(fā)非常明確這個情況，所以會有比較大的意愿去做程序的修改。
2，Role這個是安全要求，因?yàn)锳WS的sdk支持的非常好，剛上手的時候使用Role還是ak sk沒有任何難度區(qū)別，從一開始就把控好，對于研發(fā)而言沒問題。
3，托管服務(wù)這個，其實(shí)研發(fā)并不關(guān)心是運(yùn)維去做還是用現(xiàn)有的服務(wù)。這個只要我們運(yùn)維放得下執(zhí)念就可以。
4，數(shù)據(jù)不要存在服務(wù)器上。其實(shí)我們是經(jīng)歷了一次比較大的磨合。
我們這次遷移是從一個有完備的平臺支持的IDC環(huán)境遷移到AWS，在AWS的partner的幫助下，新架構(gòu)按照AWS的最佳實(shí)踐設(shè)計，并且滿足了之前的使用習(xí)慣和要求。
但是因?yàn)樽隽酥貥?gòu)，使用上還是有差異的。因?yàn)槭褂昧薃SG，所以在縮容或者故障遷移時，服務(wù)器是直接干掉的，上面如果要存持久化數(shù)據(jù)的話就沒了，所以這次之后，研發(fā)基本能接受在線業(yè)務(wù)數(shù)據(jù)不存在服務(wù)器上了。
而且因?yàn)檫@個設(shè)計，我們對于服務(wù)器存儲的要求就可以能多小就多小，超過100G的都需要我審批。節(jié)省了大量的EBS成本
后續(xù)，研發(fā)在做K8S的部署的時候，對于這個的理解就更加深刻了，畢竟容器里的數(shù)據(jù)都是會丟的。
最近有些文章講述他們綜合衡量 ROI 覺得下云更劃算，比如 RoR 之父的文章，比如運(yùn)維百家講壇上一期途游游戲鄒總，看起來您更傾向于深度用云，能否給大家分享一下您的思考？
我其實(shí)一直在鼓吹“最佳實(shí)踐”，但是我也跟大家交流過“最佳實(shí)踐是投資人或者管理層的帝王之術(shù)”，使用最佳實(shí)踐很可能就是要砸自己和很多人的飯碗才能達(dá)到最優(yōu)，如果以不砸飯碗的前提下實(shí)現(xiàn)最優(yōu)，選擇就會更多樣。
下云還是上云，得看利益出發(fā)點(diǎn)，也得看管理層支持的力度，還得看歷史包袱。如果我在鄒總或者DHH的位子上，也未必會堅(jiān)持我現(xiàn)在的觀點(diǎn)。我能堅(jiān)持在云上：
一方面是管理層的認(rèn)可，管理層都吃過資產(chǎn)閑置的虧，我做了很久的閑置IDC資源的優(yōu)化的工作，所以加上出海自建機(jī)房也不是特別容易，上云基本上就是管理層支持的唯一方案。
另外一方面也是如上面所說機(jī)緣巧合，我們架構(gòu)改造的很徹底，而且改造成本是管理層支持的，可以充分利用云的優(yōu)勢。
最后一點(diǎn)，我們的業(yè)務(wù)形態(tài)到現(xiàn)在還沒有一個長期穩(wěn)定的高負(fù)載而且無狀態(tài)的業(yè)務(wù)。這種業(yè)務(wù)比較適合傳統(tǒng)IDC。
我相信鄒總或者DHH現(xiàn)在去改造他們現(xiàn)有系統(tǒng)的架構(gòu)，付出的成本太高了，即使說可以因此削減運(yùn)維部門的人力成本，可能很難得到支持，因?yàn)檫@還涉及到其他部門的利益。
但是如果是新公司新項(xiàng)目，我相信沒有比云更合適的場景了，選一家合適的云廠商，采用云原生的架構(gòu)來實(shí)現(xiàn)業(yè)務(wù)，使整個業(yè)務(wù)從性能和成本上都是彈性的。
很多朋友吐槽云殺豬，鎖定之類的。但是從投資人或者管理層的角度看，一切要素都是為了達(dá)成業(yè)務(wù)的盈利，人/云/IDC等 都是實(shí)現(xiàn)業(yè)務(wù)的要素，投資人想實(shí)現(xiàn)業(yè)務(wù)，不僅要為這些要素支付成本，還要能及時獲取到符合需求的要素（這個更重要）。云這個要素的獲取再簡單不過了，相對而言非常標(biāo)準(zhǔn)的產(chǎn)品質(zhì)量和價格，點(diǎn)幾下就可以付款使用了，可以按需可以包周期，但是隨時都可以停止使用。但是人呢？人的獲取很難，質(zhì)量也很難明確，也不是標(biāo)準(zhǔn)化的，會有價格的波動（加薪），不能隨便裁，離崗也不會幫你頂替一個絕對一摸一樣的。人可以是很有創(chuàng)造力的，但是在標(biāo)準(zhǔn)化和機(jī)械枯燥的事情方面，人永遠(yuǎn)不是機(jī)器的對手，更不是SaaS服務(wù)的。
對于鄒總的情況，如果他們業(yè)務(wù)團(tuán)隊(duì)不愿意改造程序架構(gòu)的話，他現(xiàn)在的選擇就是最佳實(shí)踐了：穩(wěn)定高負(fù)載的業(yè)務(wù)選用成本有優(yōu)勢的IDC，并且租賃機(jī)器而不是購買；彈性業(yè)務(wù)的上云。
對于37signals 的Basecamp，從產(chǎn)品的定價模型設(shè)定上就決定了他們上云有點(diǎn)麻煩。現(xiàn)在大多數(shù)SaaS服務(wù)都是按用量或者使用人數(shù)付費(fèi)的，但是Basecamp主要賣無限制套餐，一個月只有199刀。這個定價模型就導(dǎo)致他們無法充分利用云的彈性來盈利，而只能走低價資源的超售。不改變這個定價模式，無論怎么優(yōu)化架構(gòu)恐怕也不太適合云。
最近有個文章《運(yùn)維的未來是平臺工程》，您認(rèn)可這個觀點(diǎn)么？在平臺工程方面您的團(tuán)隊(duì)承擔(dān)了一個什么角色和邊界？您是怎么規(guī)劃所謂的平臺工程的呢（尤其是在多云環(huán)境下）？
是阮一峰寫的還是Charity Majors 寫的？不過這兩篇我之前沒看過，剛簡要的看了一下。我不完全認(rèn)可這個，而且我個人也不會去嘗試做內(nèi)部的平臺工程。
首先說一下不認(rèn)可的地方吧：就是那篇文章對于概念有一些誤解。
首先，DevOps不是一個崗位，我曾經(jīng)試圖理解了很久，最終的感覺就是這是一種開發(fā)模式。但是這個開發(fā)模式的核心是研發(fā)，所有的要素都要圍繞高效的研發(fā)迭代服務(wù)。那篇文章前面認(rèn)為DevOps是一個崗位，后面又認(rèn)為這個崗位是開發(fā)業(yè)務(wù)的，我覺得都是不妥當(dāng)?shù)睦斫狻?/p>
其次，運(yùn)維對未來的探索是很豐富的。轉(zhuǎn)型不是一個新話題，大家很早就明白運(yùn)維這個行業(yè)是夕陽行業(yè)了，過去這十多年，有很多運(yùn)維都在嘗試轉(zhuǎn)型，找下一步的出路，有試圖搞CI/CD的，有嘗試做監(jiān)控研發(fā)的，有嘗試做自動化運(yùn)維平臺研發(fā)的，有嘗試搞新領(lǐng)域（比如K8s，大數(shù)據(jù)，AI，云計算之類的），也有嘗試轉(zhuǎn)向其他子項(xiàng)的（比如DBA，網(wǎng)絡(luò)安全）。
可以看出來這些轉(zhuǎn)型很多都是服務(wù)于DevOps這個開發(fā)模式的。
平臺工程或許是一種實(shí)現(xiàn)模式，但是以運(yùn)維群體的產(chǎn)品力和研發(fā)水平，自己搞平臺工程恐怕只能自娛自樂，甚至連穩(wěn)定性都無法保證，徒增背鍋可能。但是如果引入更加專業(yè)的產(chǎn)研團(tuán)隊(duì)去做，一方面是不務(wù)正業(yè)跟主營業(yè)務(wù)收入無關(guān)很難得到支持，另外一方面只是自用的平臺，拉這么多人做一個沒有收入的產(chǎn)品并不經(jīng)濟(jì)，更何況這種做法對于現(xiàn)有的運(yùn)維而言沒有參與感，算不上轉(zhuǎn)型。
所以，我認(rèn)為正確的做法是自己用成熟的平臺和工具（開源/付費(fèi)自建，使用SaaS均可），可以基于這些平臺做一些定制和二開，但是不要造輪子。
最后，我對那篇文章中平臺的理解也不一樣。
一方面，平臺本身就可以是SaaS的形式去提供，不需要二開整合，現(xiàn)在主要是國內(nèi)SaaS環(huán)境不佳，以及軟件服務(wù)也不重視相互集成兼容，而更喜歡做大而全。我們把目光放到海外就會發(fā)現(xiàn)海外有很多細(xì)分領(lǐng)域的SaaS或者軟件，做的很好而且可以跟其他軟件集成，生態(tài)很好所以集成很容易配置，沒有太多二開的工作量。
另外一方面，平臺的用戶應(yīng)該是研發(fā)，研發(fā)應(yīng)該可以直接使用，而不需要運(yùn)維去轉(zhuǎn)達(dá)，審批。
所以未來的確需要用平臺，是專業(yè)的產(chǎn)研團(tuán)隊(duì)做的平臺，而不是自己做的玩具；是產(chǎn)研團(tuán)隊(duì)來直接使用的平臺，而不是運(yùn)維攔在中間做傳話筒。
所以對于平臺工程，我選擇積極的使用成熟的軟件或者SaaS服務(wù)，并且盡可能提供給產(chǎn)研團(tuán)隊(duì)直接使用。
運(yùn)維只基于成本和安全做一些必要的卡口，通過策略，權(quán)限，審計來控制，保證產(chǎn)研團(tuán)隊(duì)可以正確的使用。
王老板這樣的工作模式下，感覺只需要非常資深的人，新鮮血液太嫩，沒法承擔(dān)研發(fā)教練的角色，但是沒有新鮮血液，也沒法長期維計，能否分享一下您是如何建設(shè)您的梯隊(duì)的？
這個問題很好，因?yàn)槲业拇_也沒解決。這不是這種工作模式的問題。
對于資深人才的需求，很多公司，很多工種都是有的，一樣面臨我現(xiàn)在的問題。什么工種才不需要資深人才呢？我認(rèn)為是工作內(nèi)容已經(jīng)非常標(biāo)準(zhǔn)化，公司要求不高，隨便一個人都能根據(jù)需求就能明確指示做好。甚至機(jī)器就能做好。
鄒總有個說法是傳統(tǒng)運(yùn)維類似保潔，工作內(nèi)容重要但是價值不高。我比較認(rèn)可這個說法，這就是我們現(xiàn)在運(yùn)維面臨的困境。那么保潔團(tuán)隊(duì)他們自研清潔工具還是去采購？
因?yàn)椴捎昧舜罅砍墒斓漠a(chǎn)品和外部服務(wù)，我如同保潔使用各種自動半自動的清掃工具一樣，可以比較穩(wěn)定的輸出清掃任務(wù)。但是不需要擔(dān)心某個保潔能力欠缺導(dǎo)致拖地不干凈，不夠敬業(yè)導(dǎo)致簡單掃一遍就交差。固然要操作好這些工具，保潔需要學(xué)習(xí)的比傳統(tǒng)工具要多一點(diǎn)難一點(diǎn)，但是總體的SOP要比原來要少，因?yàn)槌墒斓墓ぞ咂帘瘟思?xì)節(jié)。
所以，我們不要在低價值的工作內(nèi)容上浪費(fèi)時間，這類工作用專業(yè)的軟件或者SaaS來完成，它們有規(guī)模效應(yīng)，功能好還有SLA。我們應(yīng)該把工作重心放在業(yè)務(wù)，管理層，投資人更關(guān)心的領(lǐng)域。
我們知道，王老板一直是“運(yùn)維自我革命”的鼓吹手，這是“反人性”的，能談?wù)勥@背后的思考嗎？
我們現(xiàn)在看到的事實(shí)就是運(yùn)維并不是一個蓬勃發(fā)展的行業(yè)，絕大多數(shù)企業(yè)并不會有一個龐大的運(yùn)維部來支撐企業(yè)的系統(tǒng)運(yùn)轉(zhuǎn)，甚至可能只需要一個人，這個人還會兼任IT，網(wǎng)管，安全之類的工作。我們沒有上升空間了，運(yùn)維總監(jiān)極少，運(yùn)維經(jīng)理基本上就是極限了，以我現(xiàn)在管理的人數(shù)，叫我運(yùn)維主管都可以。
現(xiàn)在業(yè)界也是這樣的狀態(tài)，大量培訓(xùn)班速成的運(yùn)維，夠用而且價廉。中高端運(yùn)維很少，運(yùn)維不像是網(wǎng)工或者DBA，我們技術(shù)棧非常雜，沒有權(quán)威的認(rèn)證標(biāo)注我們的能力，這一方面不利于我們規(guī)劃職業(yè)路線，也不利于形成一個良性的人才市場。所以市場對于我們運(yùn)維的定位其實(shí)就是打雜了，“不寫業(yè)務(wù)代碼的那個技術(shù)”可能是我們最準(zhǔn)確的定位。
根據(jù)DevOps的理念，我們應(yīng)該是加速業(yè)務(wù)的交付，做好服務(wù)，而不是添亂給產(chǎn)研使絆子。但是運(yùn)維的意義和工作不僅僅在于DevOps，這也是我跟很多人觀點(diǎn)不一樣的地方。
一方面，運(yùn)維是公司數(shù)字資產(chǎn)的“看門狗”，從這個角度上看，運(yùn)維代表管理層和投資人的利益，對公司的數(shù)字資產(chǎn)進(jìn)行妥善的保管，保證其能正確的使用，滿足各種監(jiān)管要求，參與各種內(nèi)部審計。是管理層對于產(chǎn)研團(tuán)隊(duì)的制衡。這其實(shí)就是最初運(yùn)維的意義。
另外一方面，國家賞飯吃。監(jiān)管要求日益嚴(yán)格，無論是網(wǎng)絡(luò)安全，數(shù)據(jù)安全還是個人信息保護(hù)，都需要有專人負(fù)責(zé)相關(guān)工作。對于小規(guī)模的企業(yè)而言，這些工作必然是運(yùn)維來兼任，特別是數(shù)據(jù)安全，直接掌管數(shù)字資產(chǎn)的運(yùn)維肯定要參與的。這是新時代對運(yùn)維的要求。
所以如果想明白這些，你就會發(fā)現(xiàn)什么Devops，什么平臺，都是運(yùn)維工作的一小部分，我們應(yīng)該把自己從這些糾結(jié)里解放出來，給自己解綁，也給產(chǎn)研團(tuán)隊(duì)解綁，做好我們管理和監(jiān)管視角的工作。
