宋茜

在數(shù)字化轉(zhuǎn)型開始的時(shí)候，需要編寫代碼進(jìn)行構(gòu)建，開發(fā)人員應(yīng)對(duì)其進(jìn)行負(fù)責(zé)維護(hù)。他們精心設(shè)計(jì)了邏輯，然后使其在服務(wù)器上運(yùn)行。隨著團(tuán)隊(duì)的擴(kuò)大和人員的差異化，這種情況發(fā)生了變化，一些團(tuán)隊(duì)成員維護(hù)代碼（Dev），而另一些團(tuán)隊(duì)成員則負(fù)責(zé)維護(hù)機(jī)器。

如今，由于云計(jì)算和微服務(wù)的興起，采用軟件將由數(shù)十個(gè)甚至數(shù)千個(gè)運(yùn)行在不同計(jì)算機(jī)上的組件組合在一起。每臺(tái)機(jī)器在技術(shù)上都是獨(dú)立的，但所有這些機(jī)器都必須協(xié)同工作。確保它們的執(zhí)行最后通過自動(dòng)化腳本來完成。

DevOps團(tuán)隊(duì)的主要任務(wù)是提供這些面向應(yīng)用程序的所有高級(jí)流程。它們可能無法處理軟件體系結(jié)構(gòu)的深層次問題，但它們可以保持部分平穩(wěn)運(yùn)行。

盡管如此，DevOps專業(yè)人員這一角色仍然相對(duì)較新，其職責(zé)尚未明確界定或分配，其技能仍在不斷發(fā)展（DevOps專業(yè)人員是跨職位、執(zhí)行編程和運(yùn)營的混合），但是許多團(tuán)隊(duì)發(fā)現(xiàn)保持服務(wù)器平穩(wěn)運(yùn)行就足夠了。在編程團(tuán)隊(duì)更改代碼以及更改代碼運(yùn)行方式的過程中，配置它們需要對(duì)細(xì)節(jié)進(jìn)行精心規(guī)劃。

越來越多的組織尋求DevOps專業(yè)人員支持其數(shù)字化轉(zhuǎn)型，重要的是要有清晰的看法，對(duì)于DevOps的新興領(lǐng)域，以下是一些隱藏的事實(shí)和人們普遍存在的誤解。

1. DevOps不是編程人員

許多管理人員認(rèn)為DevOps專業(yè)人員并不是編程人員，他們的想法是正確的。但DevOps專業(yè)人員的工作職責(zé)已經(jīng)發(fā)生了變化，一些處理字節(jié)和數(shù)據(jù)結(jié)構(gòu)的許多混亂工作都分配給了不同的編程人員。從策略上講，使程序人員擺脫保持一切正常運(yùn)轉(zhuǎn)的責(zé)任是有道理的，因?yàn)樗麄兛赡艹撩杂诂F(xiàn)代堆棧中。

但是DevOps專業(yè)人員仍然必須編寫一些代碼。他們?nèi)匀恍枰橄蟮乜紤]隱藏的數(shù)據(jù)結(jié)構(gòu)。僅使所有內(nèi)容保持運(yùn)行需要無休止的命令行調(diào)用，這些調(diào)用通?？梢允占⒑?jiǎn)化為shell腳本。盡管一些編程人員可能不會(huì)將這樣的高級(jí)工作歸類為編程，即使它包括函數(shù)調(diào)用、參數(shù)和變量，但現(xiàn)實(shí)情況是，DevOps人員具有與程序員相同的技能類型。

2.管理程序員是主要工作

即使DevOps專業(yè)人員不編寫代碼，他們最終還是要管理程序人員，而這通常要開展很多工作。每個(gè)開發(fā)人員都在創(chuàng)造新穎而美麗的事物，他們編寫的代碼是一種藝術(shù)，每個(gè)人都希望立即將其容器投入生產(chǎn)。他們通常這樣想，代碼運(yùn)行順利嗎？一切都會(huì)崩潰嗎？確保編碼人員不會(huì)把事情搞砸是DevOps專業(yè)人員的重任。

3. DevOps正在慢慢接管

當(dāng)軟件應(yīng)用程序比較簡(jiǎn)單的時(shí)候，程序員擁有所有的控制權(quán)?，F(xiàn)在應(yīng)用程序通常被分成幾十個(gè)甚至幾百個(gè)微服務(wù)，DevOps專業(yè)人員負(fù)責(zé)它們的運(yùn)行情況，并且仍然有架構(gòu)師和程序員在決定如何將服務(wù)連接在一起，但是DevOps專業(yè)人員負(fù)責(zé)如何將它們連接在一起，這是一個(gè)越來越重要的難題。

4. DevOps不用管理成本

當(dāng)云計(jì)算提供商以每小時(shí)幾美分的價(jià)格為使用其云服務(wù)定價(jià)時(shí)，他們很聰明。但是隨著云計(jì)算實(shí)例數(shù)量的運(yùn)行和時(shí)間的推移，這些費(fèi)用就會(huì)累加起來。在30天為一個(gè)月的時(shí)間中有720個(gè)小時(shí)，因此一臺(tái)每小時(shí)僅花費(fèi)1美元的機(jī)器一年的費(fèi)用為8 760美元。這時(shí)，用戶可能感覺到自己采購和運(yùn)行服務(wù)器可能更便宜。

在收到一些成本高昂的賬單后，一些團(tuán)隊(duì)可能會(huì)開始配備DevOps審核人員，其唯一職責(zé)是在混亂的機(jī)器中尋找節(jié)省資金的方法。他們檢查了業(yè)務(wù)生產(chǎn)細(xì)節(jié)，然后開始說“不”，他們將會(huì)計(jì)較每一分錢，因?yàn)樗麄冎肋@樣可能節(jié)省預(yù)算。

5.只有少數(shù)幾種方法可以提高性能

管理云計(jì)算的工作變得更加困難，因?yàn)镈evOps專業(yè)人員通常只有幾個(gè)工具和方法可以利用。一旦程序員提交代碼并構(gòu)建容器，DevOps專業(yè)人員的工作就是讓它們運(yùn)行。如果它們看起來很慢，可以嘗試添加更多的虛擬CPU或RAM。如果速度仍然很慢，可以在機(jī)房中增加更多的機(jī)器來分散負(fù)載。

6.完成拆除工作

最深層的問題之一是計(jì)算機(jī)總是在記錄錯(cuò)誤。例如一些容器每隔幾個(gè)小時(shí)就會(huì)崩潰?？赡苁菙?shù)據(jù)庫連接失敗，也可能是參數(shù)配置錯(cuò)誤。答案可能在日志文件中，但是從未發(fā)現(xiàn)。Kubernetes非常友善，可以啟動(dòng)另一個(gè)實(shí)例，然后回答查詢并完成其工作。這是故障安全體系結(jié)構(gòu)的一個(gè)示例，即使其內(nèi)部混亂不堪。

只要用戶和客戶都能完成工作，通常每個(gè)人都可以更輕松地?fù)Q個(gè)角度來看問題，而忽略所有虛擬的拆除工作。

7.數(shù)據(jù)庫支配一切

人們可能會(huì)為所有的本地代碼而感到煩惱，而把AJAX this或CSS弄亂了，但是最后，所有數(shù)據(jù)都在數(shù)據(jù)庫中找到了家，經(jīng)典數(shù)據(jù)庫仍然是代碼的核心，這是真理的唯一來源。如果團(tuán)隊(duì)能夠保持運(yùn)行并回答問題，那幾乎就是全部工作，用戶可以容忍未對(duì)齊的DIV或奇怪的新布局，但不能容忍數(shù)據(jù)庫損壞。行業(yè)專家曾經(jīng)為一個(gè)使用最新、最出色的Node.js軟件包的團(tuán)隊(duì)審核過代碼，不斷地更新其堆棧以保持最前沿，但是該數(shù)據(jù)庫已有10多年的歷史了，沒有人想對(duì)其進(jìn)行改動(dòng)。

8.對(duì)代碼的運(yùn)行方式知之甚少

如今儀器的性能可能是驚人的，人們可以通過各種軟件運(yùn)行來感受到數(shù)據(jù)激增，就像水手感覺到風(fēng)浪一樣。隨著機(jī)房負(fù)載量的波動(dòng)，人們知道工作負(fù)載事情何時(shí)正常運(yùn)行以及何時(shí)不堪重負(fù)。如果負(fù)責(zé)電子商務(wù)網(wǎng)絡(luò)應(yīng)用程序，那么DevOps專業(yè)人員將是第一個(gè)知道折扣何時(shí)生效的人，因?yàn)槠鋺?yīng)用程序的負(fù)載將會(huì)激增。

這些數(shù)字總結(jié)了組件的平均應(yīng)變和響應(yīng)時(shí)間，但無法告訴原因。而了解程序員可以知道組件內(nèi)部發(fā)生了什么事情，他們可以隔離錯(cuò)誤并找到解決方案。

一些商業(yè)人士可能希望擁有無所不能、無所不知的技術(shù)人員，并且能夠自下而上地理解整個(gè)堆棧。但對(duì)許多公司來說，這工作量太大，代碼行太多，最好為DevOps專業(yè)人員和程序員找到一種簡(jiǎn)單的協(xié)作方式。

9.一切都有些神秘

計(jì)算機(jī)可能完全是邏輯機(jī)器，其中代碼以可預(yù)測(cè)的確定性方式演化，出現(xiàn)每個(gè)錯(cuò)誤都是有原因的。工作人員可以采用調(diào)試器，查看日志文件，仔細(xì)檢查代碼，但是誰有時(shí)間呢？

就像通過重新啟動(dòng)設(shè)備可以解決90 %的技術(shù)問題一樣，DevOps專業(yè)人員需要做同樣的事情?？梢钥隙ǎ谑褂弥T如“容器”和“實(shí)例”之類的詞，并且采用大量?jī)x表跟蹤正在發(fā)生的事情，但是最后，繼續(xù)前行通常更快捷、更簡(jiǎn)單。