宕機(jī)的阿里云們正在殺死運(yùn)維行業(yè)嗎？
發(fā)布時(shí)間：2021-05-11
文章簡(jiǎn)介：
1.云計(jì)算正在殺死運(yùn)維嗎？
近年來，“去運(yùn)維”的相關(guān)討論甚囂塵上，但似乎沒有引起程序員的過多關(guān)注或者大范圍討論。近日，程序員論壇 V2EX 上出現(xiàn)一個(gè)熱議話題“阿里云正在緩慢而穩(wěn)步地殺死運(yùn)維行業(yè)”，這似乎表明運(yùn)維人員最終還是感受到了來自云計(jì)算發(fā)展帶來的巨大壓力。發(fā)帖者認(rèn)為，“當(dāng)容器服務(wù)集群、跨地域監(jiān)控與容災(zāi) / ?；?、DBA、代碼托管與 CI/CD 都能全部依托阿里云產(chǎn)品時(shí)，運(yùn)維已經(jīng)被踢出 IT 行業(yè)”。
一石激起千層浪，有人認(rèn)為這只是杞人憂天，并反問“阿里云自己都剛宕機(jī)，還想說不需要運(yùn)維嗎？”，有人則認(rèn)為英雄所見略同，還有人進(jìn)一步將未來的運(yùn)維闡述成“云維”。
技術(shù)的發(fā)展不能缺少埋頭苦干的人，但也少不了抬頭看路的人。針對(duì)這個(gè)問題，我們想跟大家聊聊，究竟云計(jì)算的發(fā)展，是否會(huì)造成運(yùn)維崗位的消亡？
2.沒有運(yùn)維的 Netflix 和運(yùn)維轉(zhuǎn)研發(fā)的阿里巴巴Netflix 的運(yùn)維模式
Netflix 從一開始就強(qiáng)調(diào)開發(fā)人員進(jìn)行自助化運(yùn)維，他們的理念是：誰(shuí)構(gòu)建，誰(shuí)運(yùn)維。其運(yùn)維工作全部由開發(fā)人員完成，只保留極少的 Core SRE 角色專門響應(yīng)和處理嚴(yán)重等級(jí)的故障。
類似的還有亞馬遜，無論是電商業(yè)務(wù)還是 AWS 公有云業(yè)務(wù)，都由開發(fā)負(fù)責(zé)。
在 Netflix 看來，建立起獨(dú)立運(yùn)維團(tuán)隊(duì)的主要助益，在于當(dāng)一切進(jìn)展順利時(shí)，開發(fā)人員不致因運(yùn)維任務(wù)的介入而分神。然而，當(dāng)工作進(jìn)展遭遇阻礙時(shí)，成本就會(huì)快速疊加起來。開發(fā)人員與 SRE 之間的溝通與知識(shí)轉(zhuǎn)移往往存在嚴(yán)重?fù)p耗，且需要額外的往來以實(shí)現(xiàn)問題調(diào)試或解答合作伙伴的疑問。
由于運(yùn)維團(tuán)隊(duì)對(duì)需要部署的變更本身缺少直接了解，因此問題部署通過會(huì)帶來更長(zhǎng)的檢測(cè)與解決周期。當(dāng)時(shí)在代碼完成到部署之間的時(shí)間斷檔要遠(yuǎn)遠(yuǎn)長(zhǎng)于當(dāng)前，發(fā)布時(shí)長(zhǎng)往往需要數(shù)周而非數(shù)天。這方面反饋主要來源運(yùn)維人員，他們大多親身經(jīng)歷過諸如警報(bào) / 監(jiān)控缺失或者性能問題以及延遲增加等挑戰(zhàn)，而這些問題最終又會(huì)被轉(zhuǎn)移至開發(fā)人員手中。
為此，Netflix 從 DevOps 運(yùn)動(dòng)的基本原則中汲取靈感，提出了“誰(shuí)構(gòu)建，誰(shuí)運(yùn)維”這一理念，旨在鼓勵(lì)系統(tǒng)開發(fā)團(tuán)隊(duì)同時(shí)負(fù)責(zé)系統(tǒng)的運(yùn)維與支持工作，從而真正將 DevOps 引入實(shí)踐。
阿里巴巴的運(yùn)維模式
阿里技術(shù)團(tuán)隊(duì)在 2016 年左右開始了一次大的組織架構(gòu)調(diào)整，即把日常的運(yùn)維工作交給研發(fā)做。原來的 PE（Production Engineer）要么轉(zhuǎn)崗去做工具平臺(tái)開發(fā)，要么作為運(yùn)維專家做產(chǎn)品規(guī)劃和設(shè)計(jì)，還有一部分無法適應(yīng)的只能黯然離開。
這是阿里運(yùn)維從工具化到自動(dòng)化最重要的一個(gè)過程。集團(tuán)性公司支撐的 BU 一般非常多，導(dǎo)致運(yùn)維團(tuán)隊(duì)基本都是在干臟活、雜活。從組織層面上做出這樣的調(diào)整后，運(yùn)維團(tuán)隊(duì)的大多數(shù)人更多的時(shí)間是投入在研發(fā)工作上，而不是投入在日常的雜事上。這是 DevOps 真正意義上被徹底執(zhí)行。
隨著公司規(guī)模的逐漸擴(kuò)大，從人肉運(yùn)維到工具化運(yùn)維再到自動(dòng)化運(yùn)維乃至 AI 時(shí)代的智能化運(yùn)維，對(duì)于運(yùn)維能力的要求是越來越高，對(duì)于運(yùn)維人手的要求卻越來越小。無怪乎有人發(fā)出這種論斷：云計(jì)算（AI）正在殺死運(yùn)維！
3.所以，運(yùn)維如何逃過這場(chǎng)“追殺”？
隨著自動(dòng)化的逐步完善，單個(gè) PE 能夠支持的業(yè)務(wù)變得越來越多，很多事情似乎都可以通過自助完成，很多公司可能在潛移默化中就降低了對(duì)應(yīng)用運(yùn)維崗位的需求，逐漸以一種類似阿里的發(fā)展方式運(yùn)行，似乎用不了多久，運(yùn)維崗位就會(huì)被普遍“殺死”，運(yùn)維人員應(yīng)該如何做好轉(zhuǎn)型和過渡呢？
運(yùn)維人員如何做好轉(zhuǎn)型？
根據(jù)科技發(fā)展的歷史，每次技術(shù)革新都會(huì)丟掉一部分舊工作，并帶來更多更有價(jià)值的新職位，某位圈內(nèi)云計(jì)算專家在接受 InfoQ 采訪時(shí)表示：
云廠商確實(shí)在運(yùn)維層面做了很多工作，但這部分工作并不是運(yùn)維最看重的。換句話說，這些工作都不能體現(xiàn)運(yùn)維人員的核心競(jìng)爭(zhēng)力。過去，運(yùn)維相當(dāng)于黃包車車夫，累死累活半天可能也就繞著二環(huán)跑了兩圈；現(xiàn)在，云平臺(tái)可以免押金租給他們一輛汽車，輕松一天往返五次機(jī)場(chǎng)，你覺得哪種司機(jī)掙得多呢？
在云時(shí)代，運(yùn)維人員并不是沒有價(jià)值，而是會(huì)變得更加重要。云計(jì)算承諾高彈性、高可用、高性能、智能化，但公有云的 SLA 真不是目前的 AIOps 和運(yùn)維自動(dòng)化工具可以獨(dú)立承擔(dān)的。
專家認(rèn)為，運(yùn)維團(tuán)隊(duì)的實(shí)力也是云計(jì)算服務(wù)商的核心競(jìng)爭(zhēng)力，云計(jì)算要求更高的運(yùn)維能力，能夠保障大規(guī)?；A(chǔ)設(shè)施和業(yè)務(wù)穩(wěn)定運(yùn)行。對(duì)于企業(yè)用戶而言，底層基礎(chǔ)設(shè)施的運(yùn)維工作確實(shí)可以甩給第三方公有云服務(wù)商統(tǒng)一負(fù)責(zé)，但上層應(yīng)用的運(yùn)維工作還需要企業(yè)自己來承擔(dān)，比如環(huán)境配置，不過更多的是 DevOps。
因此，運(yùn)維人員必須學(xué)會(huì)適當(dāng)?shù)慕巧D(zhuǎn)變。今后，運(yùn)維領(lǐng)域的發(fā)展傾向于具備開發(fā)能力，尤其是產(chǎn)品能力，足以設(shè)計(jì)好的運(yùn)維工具和平臺(tái)的技術(shù)人才，這種觀點(diǎn)也基本得到運(yùn)維領(lǐng)域技術(shù)專家的認(rèn)可。
采訪中，某一線互聯(lián)網(wǎng)公司運(yùn)維負(fù)責(zé)人表示：
未來，運(yùn)維崗位不會(huì)被淡化，相反會(huì)發(fā)展的越來越好。現(xiàn)在，之所以會(huì)有很多人擔(dān)憂運(yùn)維的未來，是因?yàn)槿缃翊蠖鄶?shù)公司的運(yùn)維其實(shí)就是打雜的，這主要?dú)w因于基礎(chǔ)設(shè)施不夠完善，需要運(yùn)維手工補(bǔ)齊短板，所以運(yùn)維需要承擔(dān)很多臟活、累活。當(dāng)基礎(chǔ)設(shè)施短板補(bǔ)齊，運(yùn)維可以在上面做更多業(yè)務(wù)側(cè)的工作。從大公司和公有云角度來看，他們確實(shí)不需要這么多運(yùn)維，但是市場(chǎng)體量將會(huì)變大，運(yùn)維人員的需求也會(huì)隨之增加。
當(dāng)企業(yè)逐漸云化，運(yùn)維崗位可能會(huì)適當(dāng)精簡(jiǎn)，但是不會(huì)被完全取代，企業(yè)仍然需要人員負(fù)責(zé)資源管理、應(yīng)用部署升級(jí)、監(jiān)控和故障處理。按照 DevOps 理論來說，可能所有這些都可以由開發(fā)人員完成。當(dāng)然，最理想的情況可能就是運(yùn)維團(tuán)隊(duì)開發(fā)工具和平臺(tái)，開發(fā)人員自己運(yùn)維。
無論如何，應(yīng)用運(yùn)維可能都需要適當(dāng)轉(zhuǎn)型，極客時(shí)間《趙成的運(yùn)維體系管理課》的專欄作者趙成曾在文章中提及：
無論是做運(yùn)維轉(zhuǎn)型還是做其他技術(shù)轉(zhuǎn)型，具備代碼開發(fā)能力都已經(jīng)成為一項(xiàng)必備技能。
他建議：
如果對(duì)開發(fā)工作缺乏自信，可以先從 Python、PHP 和 Go 這些上手比較簡(jiǎn)單的語(yǔ)言開始，這不是指寫腳本，而是一定要能夠?qū)崿F(xiàn)完整的業(yè)務(wù)功能或流程；
其次，需要提升產(chǎn)品意識(shí)，這并不是要求所有運(yùn)維同事都成為優(yōu)秀的產(chǎn)品經(jīng)理，或者具備很強(qiáng)的產(chǎn)品設(shè)計(jì)能力，而是一定 要有產(chǎn)品意識(shí)，這一點(diǎn)小轉(zhuǎn)變就可能帶來很大不同；
最后，提升技術(shù)運(yùn)營(yíng)意識(shí)，簡(jiǎn)單來說就是可以根據(jù)需求把承載標(biāo)準(zhǔn)化和規(guī)范體系的工具平臺(tái)真正落地應(yīng)用。在這個(gè)過程中，通過問題收集和一定數(shù)據(jù)分析，再回到產(chǎn)品設(shè)計(jì)和需求流程中進(jìn)行改進(jìn)，從而形成良性閉環(huán)。
留給運(yùn)維人員的時(shí)間還有多少？
好在，目前這項(xiàng)進(jìn)程的轉(zhuǎn)變步伐不算很快。一位與傳統(tǒng)大型企業(yè)打了十多年交道的技術(shù)專家認(rèn)為:
雖然云計(jì)算以及人工智能吸引了很多企業(yè)嘗鮮，但目前并沒有看到這些新服務(wù)真正落地并為傳統(tǒng)企業(yè)帶來很大價(jià)值，大部分應(yīng)用還停留在表層，這項(xiàng)技術(shù)所能帶來的潛力還沒有被最大化挖掘。就實(shí)際應(yīng)用而言，目前市場(chǎng)上的公有云服務(wù)成本依舊普遍偏高，易用性也不足以達(dá)到單憑傳統(tǒng)企業(yè)的技術(shù)能力就可以短時(shí)間內(nèi)學(xué)會(huì)的程度。
因此，雖然云計(jì)算和人工智能是未來的重要發(fā)展趨勢(shì)，但短期內(nèi)還存在很多問題需要解決，企業(yè)需要具備專業(yè)的技術(shù)團(tuán)隊(duì)來更好得將云服務(wù)落地，并保證服務(wù)的可用性和可靠性。目前，很多企業(yè)尚處于混合云階段，數(shù)據(jù)的流轉(zhuǎn)、計(jì)算等環(huán)節(jié)都需要技術(shù)和運(yùn)維人員的存在。短期內(nèi)，運(yùn)維人員仍然在公司中具有重要地位。
另一方面，我們必須承認(rèn)云計(jì)算和人工智能所帶來的挑戰(zhàn)。如今，企業(yè)已經(jīng)從單純選用 IaaS 服務(wù)向 PaaS 和 SaaS 層過渡，這些產(chǎn)品基本都在公有云平臺(tái)內(nèi)部經(jīng)歷了長(zhǎng)時(shí)間的磨練和運(yùn)行，這讓不少新興企業(yè)只需要專注業(yè)務(wù)邏輯，而無需自研純技術(shù)產(chǎn)品。這種情況下，企業(yè)非但不需要應(yīng)用運(yùn)維這些基礎(chǔ)崗位，就連門檻較高的分布式中間件研發(fā)崗位可能也會(huì)大量縮減。
面對(duì)這些改變，運(yùn)維人員唯一的辦法就是不斷學(xué)習(xí)和提升自己的技能，保持自身的與時(shí)俱進(jìn)，及時(shí)做出相應(yīng)調(diào)整和改變，這才是應(yīng)萬(wàn)變的根本之道。
有動(dòng)力環(huán)境監(jiān)控系統(tǒng)項(xiàng)目，需要?jiǎng)迎h(huán)？找斯必得科技就對(duì)了，我們有案例，幫助您更加輕松運(yùn)作項(xiàng)目。請(qǐng)致電：4006-020-248 或在線咨詢！我們免費(fèi)為你提供動(dòng)環(huán)監(jiān)控系統(tǒng)方案與產(chǎn)品報(bào)價(jià)。
189-0300-8674（林經(jīng)理）