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

[[284735]]

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

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

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

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

1. DevOps不是編程人員

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

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

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

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

3. DevOps正在慢慢接管

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

4. DevOps不用管理成本

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

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

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

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

6. 完成拆除工作

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

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

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

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

8. 對代碼的運行方式知之甚少

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

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

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

9. 一切都有些神秘

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

就像通過重新啟動設(shè)備可以解決90%的技術(shù)問題一樣，DevOps專業(yè)人員需要做同樣的事情。可以肯定，在使用諸如“容器”和“實例”之類的詞，并且采用大量儀表跟蹤正在發(fā)生的事情，但是最后，繼續(xù)前行通常更快捷、更簡單。