2021年你不能錯過的DevOps趨勢

來源：分布式實(shí)驗(yàn)室?
DevOps已經(jīng)蓬勃發(fā)展起來，DevOps無處不在，現(xiàn)在一切都跟DevOps息息相關(guān)。但是我發(fā)現(xiàn)關(guān)于Deveops的一個新的趨勢是大家都未注意到的。最近，我讀很多人做的關(guān)于2021年DevOps的發(fā)展趨勢時，DevOps欣欣向榮。DevOps就是一切，如今一切都是DevOps。
以下是如今爆炸性增長的DevOps趨勢的部分列表：

• 混合部署（Hybrid Deployments）

• 數(shù)據(jù)運(yùn)維（DataOps）

• 彈性測試

• 生產(chǎn)測試

• GitOps

• 微服務(wù)（當(dāng)然）

• 無服務(wù)器（Serverless）

• 以云服務(wù)為中心的基礎(chǔ)架構(gòu)

• 邊緣計(jì)算

• 基礎(chǔ)架構(gòu)即代碼

• 開發(fā)安全（DevSecOps）

• 應(yīng)用程序性能監(jiān)視（APM）工具

• 混合計(jì)算（Hybrid Computing）

• Kubernetes

• 功能開關(guān)（Feature Toggles）

這樣的例子不勝枚舉……
但是，在閱讀了所有這些文章后，令我震驚的是，沒有一個人將“非侵入式生產(chǎn)環(huán)境調(diào)試”視為DevOps工具鏈的標(biāo)準(zhǔn)組件。而這就是我所看到的DevOps趨勢。

那么什么是“非侵入式生產(chǎn)環(huán)境調(diào)試”

讓我們從零開始，當(dāng)我們想要調(diào)試生產(chǎn)環(huán)境的問題時我們最常用的方式就是——查看日志文件。這個痛苦的、重復(fù)的過程就像下面這樣：

1. 令人討厭的錯誤

2. 該死，我沒有足夠的數(shù)據(jù)

3. 讓我在日志中添加幾行

4. 構(gòu)建

5. 部署

6. 復(fù)現(xiàn)錯誤步驟

7. 看一下日志

8. 找到問題了么

1. 沒有 - 回到步驟2

2. 找到了（在幾次耗時很久嘗試以后）- 終于結(jié)束了

就像下面這個圖展示一樣：

你還可以選擇將遠(yuǎn)程調(diào)試器直接連接到生產(chǎn)環(huán)境，但是通常情況下，運(yùn)維團(tuán)隊(duì)不允許這樣做。出于安全考慮，你并不想在斷點(diǎn)處暫停執(zhí)行而中斷服務(wù)。
非侵入式生產(chǎn)環(huán)境調(diào)試遵循可觀察性工具的概念。這些是APM（應(yīng)用程序性能監(jiān)視工具），用于展示，分片和分塊日志，指標(biāo)和追蹤（trace）。這就是可觀察性。在不中斷或干擾系統(tǒng)運(yùn)行的情況下，了解系統(tǒng)的狀況（以便您解決錯誤）。
但是，在修復(fù)生產(chǎn)環(huán)境中的錯誤時，這些工具往往不能提供足夠的數(shù)據(jù)。通常它們能獲得的最詳盡的信息是顯示拋出異常的位置，以及堆棧追蹤（stack trace）以及有關(guān)錯誤情況的一些常規(guī)元數(shù)據(jù)，例如瀏覽器或操作系統(tǒng)的信息。
通常這些信息并不足以找到錯誤。微服務(wù)和無服務(wù)器等現(xiàn)代軟件體系結(jié)構(gòu)使事情變得更加困難。想象一下，跟蹤一個使Kubernetes集群中的節(jié)點(diǎn)崩潰的錯誤，而Kubernetes只會啟動一個新實(shí)例?；驘o服務(wù)器方法（serverless function）中的邏輯錯誤。當(dāng)您調(diào)試這些問題時，證據(jù)已隨著銷毀的實(shí)例而不復(fù)存在。
非侵入式生產(chǎn)環(huán)境調(diào)試使可觀察性更進(jìn)一步，即便對于微服務(wù)和無服務(wù)器（serverless）代碼，也能在代碼級別逐行顯示了應(yīng)用程序的行為。這就是我們所說的代碼級可觀察性，它彌補(bǔ)了DevOps從APM（應(yīng)用程序性能監(jiān)視工具）無法獲得的可觀察性。

為什么我認(rèn)為這是一個很重要的趨勢？

你應(yīng)該猜到為什么我如此著迷于非侵入式生產(chǎn)環(huán)境調(diào)試。因?yàn)檫@就是我公司的基礎(chǔ)，我們的感受在與潛在客戶和客戶的會議中有了明顯的轉(zhuǎn)變。
一年前，主持會議的同行是開發(fā)人員，盡管是高級開發(fā)人員或開發(fā)經(jīng)理，但仍然是開發(fā)人員。DevOps工程師可能在會議室里，但是他們在開會過程中只是在后排坐著，只有在我們開始討論軟件如何影響或不影響生產(chǎn)系統(tǒng)，以及關(guān)于安全性，性能，部署等還有很多問題時參與討論。但Devops工程師對于我們的生產(chǎn)環(huán)境調(diào)試器的使用方式或?qū)λ鼈兊挠猛緟s沒有太多的了解，至少不是由DevOps員工提供的。他們只是將其視為開發(fā)人員需要他們在生產(chǎn)環(huán)境中維護(hù)的另一種工具。
在過去的一年中，重點(diǎn)已經(jīng)明顯轉(zhuǎn)移。坐在會議室的DevOps工程師坐在前排，提出了更多問題，并且開始意識到有效的生產(chǎn)調(diào)試可以如何顯式的影響DevOps KPI，即便實(shí)際上是開發(fā)團(tuán)隊(duì)中的工程師在進(jìn)行根本原因（root cause）分析并提出建議或者提交代碼。DevOps團(tuán)隊(duì)開始更加關(guān)注 生產(chǎn)調(diào)試。

為什么DevOps工程師開始對生產(chǎn)環(huán)境調(diào)試感興趣？

這種情況的部分原因是生產(chǎn)調(diào)試器也可以在預(yù)生產(chǎn)環(huán)境（例如QA和Staging）中運(yùn)行。DevOps工程師知道，在QA或Staging以及生產(chǎn)環(huán)境中，如果能調(diào)試并更快地修復(fù)bug，這意味著可以幫助提升的DevOps KPI：

• Staging環(huán)境會過濾掉更多的bug（更低的變更失敗率，較低的缺陷遺失率，以及更高的平均無故障時間（MTBF））

• 能夠自動捕獲和顯示異常的生產(chǎn)環(huán)境調(diào)試器不僅會在發(fā)生錯誤時立即通知你，而且會記錄完整的錯誤執(zhí)行流，使你能夠非?？焖俚亓私饽闶且幚碚嬲腻e誤還是無關(guān)緊要的錯誤，以及錯誤的嚴(yán)重性及其影響（降低平均探測時間 （MTTD））。

• 生產(chǎn)環(huán)境調(diào)試器極大地減少了識別，分析和修復(fù)生產(chǎn)錯誤所需的時間（即平均恢復(fù)時間（MTTR））。當(dāng)我們開始討論此KPI時，坐在房間里的所有DevOps工程師都會坐起來，因?yàn)檫@反映了當(dāng)生產(chǎn)中出現(xiàn)問題時服務(wù)將不可用多長時間。我們知道這種事一定會發(fā)生，只需查看這個記錄網(wǎng)站不可用的探測網(wǎng)站downdetector.com，你就會明白我的意思。

DevOps工程師和SRE意識到，生產(chǎn)環(huán)境調(diào)試器不僅僅是作為開發(fā)人員工具，更像是監(jiān)控以及代碼可觀察性。它還非常符合DevOps的反饋和協(xié)作原則，彌合了DevOps與開發(fā)人員之間仍然存在的鴻溝（這在許多組織中仍然存在）。通過生產(chǎn)環(huán)境調(diào)試器，開發(fā)人員可以直接從生產(chǎn)系統(tǒng)中獲取所需的數(shù)據(jù)，用來解決錯誤。使用生產(chǎn)環(huán)節(jié)調(diào)試器，DevOps和開發(fā)人員可以直接合作以解決生產(chǎn)環(huán)境中的錯誤，這是修復(fù)bug和快速解決生產(chǎn)事故的催化劑。

那么生產(chǎn)環(huán)境調(diào)試器是如何工作的呢？

遠(yuǎn)程調(diào)試器
生產(chǎn)環(huán)境調(diào)試并不是一個全新的概念。遠(yuǎn)程調(diào)試已經(jīng)存在了一段時間，你可以在運(yùn)行時注入斷點(diǎn)，在每次斷點(diǎn)命中時收集數(shù)據(jù)，然后立即繼續(xù)該過程并重復(fù)。盡管這是獲取生產(chǎn)數(shù)據(jù)的簡便方法，但它具有侵入性，并且會對性能產(chǎn)生重大影響，因此現(xiàn)在并未得到廣泛使用。
快照調(diào)試
另一種方式是快照調(diào)試，調(diào)試器將會fork進(jìn)程一份進(jìn)程的副本（使用寫時復(fù)制copy-on-write技術(shù)），然后通過檢查副本來進(jìn)行調(diào)試。盡管此方法讓您可以檢查調(diào)試過程的整個內(nèi)存占用量，但它也是侵入性的，給正在運(yùn)行的主機(jī)上增加了很大的內(nèi)存負(fù)載，因此進(jìn)行快照的dian數(shù)量是有限制。
插裝（instrumentation）
現(xiàn)代生產(chǎn)環(huán)境調(diào)試器使用第三種方法——字節(jié)碼插裝。它們將插裝添加到執(zhí)行不同功能的字節(jié)碼中，例如測量性能，捕獲應(yīng)用程序狀態(tài)，捕獲異常等。這是APM多年來一直在做的事情。生產(chǎn)環(huán)境調(diào)試器將其進(jìn)一步擴(kuò)展。它和APM使用相同的技術(shù)，目標(biāo)是解決報錯和邏輯錯誤，而不是解決生產(chǎn)和預(yù)生產(chǎn)環(huán)境中的性能問題。
由于人類看不懂字節(jié)碼，因此讓我們看看如果在源代碼中添加檢測功能，字節(jié)碼會是什么樣子。
代碼如下：public?async?Task?ApplyBundleCode(string?code)
{
???var?customer?=?await?ProfileService.FetchProfile(User);
???var?basket?=?await?BasketService.LoadBasketForCustomer(customer);
???var?bundle?=?await?BundlesService.FetchBundle(code);
???if?(bundle.IsCustomerEligible(customer))
???{
???????bundle.ApplyOn(basket);
???????await?BasketService.UpdateBasketForCustomer(customer,?basket);
??}
??return?basket;
}

加入檢測后，可能看起來像這樣：public?async?Task?ApplyBundleCode(string?code)
{
??Telemetry.startTimer(“ApplyBundleCode”);
??Telemetry.logVariable(“User.Id”,User?.Id);
??var?customer?=?await?ProfileService.FetchProfile(User);
??Telemetry.logVariable(“Customer.FullName”,customer?.FullName);
??Telemetry.logVariableAsJson(“Customer.Address”,customer?.Address);?
??
??var?basket?=?await?BasketService.LoadBasketForCustomer(customer);
??Telemetry.logVariableAsJson(“basket”,basket);
??Telemetry.logVariable(“code”,code);???????

??var?bundle?=?await?BundlesService.FetchBundle(code);
??Telemetry.logVariable(“code”,code);

?if?(bundle.IsCustomerEligible(customer))
?{
?????Telemery.log(“bundle?{0}?eligible?for?customer?{1}”,?code,?customer.FullName);
?????bundle.ApplyOn(basket);
?????Telemery.log(“about?to?update?basket”);
?????await?BasketService.UpdateBasketForCustomer(customer,?basket);
?}
?else?{
???Telemery.log(“bundle?{0}?not?eligible?for?customer?{1}”,?code,?customer.FullName);
?}

?Telemery.endTimer(“ApplyBundleCode”);
?return?basket;
}

調(diào)試檢測代碼同樣有挑戰(zhàn)性。大多數(shù)現(xiàn)代生產(chǎn)環(huán)境調(diào)試器都需要先用Git找到精確的生產(chǎn)環(huán)境使用的commit，從中構(gòu)建出和生產(chǎn)環(huán)境相同的二進(jìn)制文件以便調(diào)試。將所有正確的源文件與生產(chǎn)環(huán)境中當(dāng)前正在運(yùn)行的文件進(jìn)行匹配并不總是一件容易的事，并且您還需要匹配一組構(gòu)建和編譯設(shè)置。以及如何處理第三方代碼？一些工具通過反編譯正在調(diào)試的生產(chǎn)代碼來解決此問題。這使工作變得更加輕松，因?yàn)樗似ヅ湓次募囊螅⑶覍⒌谌酱a與舊代碼一起反編譯。

為什么非侵入式打敗侵入式

遠(yuǎn)程調(diào)試器具有很強(qiáng)的侵入性，因?yàn)樗鼈冞B接到主機(jī)應(yīng)用程序并將斷點(diǎn)放置在實(shí)時運(yùn)行的系統(tǒng)中。即使應(yīng)用程序只是短暫中斷了以供遠(yuǎn)程調(diào)試器收集數(shù)據(jù)，仍然存在許多生產(chǎn)系統(tǒng)所不能容忍的巨大穩(wěn)定性風(fēng)險。同樣，快照調(diào)試器通過其使用的侵入式寫時復(fù)制技術(shù)對運(yùn)行中的系統(tǒng)造成的內(nèi)存開銷也存在耗盡系統(tǒng)內(nèi)存的風(fēng)險。例如，Microsoft的Snapshot Debugger默認(rèn)為每分鐘最多五個快照，以避免拋出內(nèi)存不足的異常。

插裝（instrumentation）和生產(chǎn)調(diào)試器一起可以做什么？

現(xiàn)代生產(chǎn)環(huán)境調(diào)試器所做的大部分工作都是基于不間斷的斷點(diǎn)（也稱為追蹤點(diǎn)）。在希望獲取數(shù)據(jù)的那一行打上斷點(diǎn)（即追蹤點(diǎn)）讓調(diào)試器插裝來獲取數(shù)據(jù)。你實(shí)際上可以做很多事情：

• 動態(tài)日志：記錄代碼中任何位置的數(shù)據(jù)，包括局部變量和方法參數(shù)的值。

• 動態(tài)指標(biāo)：就像是動態(tài)日志，從局部變量中您可以提取到應(yīng)用程序級別數(shù)據(jù)，從而衡量不同的指標(biāo)。

• 集成：您可以在無需中斷的斷點(diǎn)/跟蹤點(diǎn)的情況下，將測量的任何內(nèi)容通過API傳播到第三方應(yīng)用程序。因此，你可以創(chuàng)建Slack通知或?qū)討B(tài)日志和指標(biāo)數(shù)據(jù)傳遞到APM，在其中您可以進(jìn)一步對數(shù)據(jù)進(jìn)行分片和分塊，以精美的圖形和圖表查看數(shù)據(jù)，并且創(chuàng)建有意義的警報。

除了使用不中斷的斷點(diǎn)/跟蹤點(diǎn)來完成的工作外，某些生產(chǎn)環(huán)境調(diào)試器還可以執(zhí)行以下操作：

• 捕獲異常：這已經(jīng)是許多APM所做的事情，但是生產(chǎn)環(huán)境調(diào)試器將提供有關(guān)異常以及拋出異常的局部信息和變量值的更多信息。

• 時間旅行記錄：某些生產(chǎn)環(huán)境調(diào)試器不僅捕獲異常，而且捕獲整個過程中導(dǎo)致異常的完整錯誤執(zhí)行流以及應(yīng)用程序數(shù)據(jù)。這樣就可以逐行調(diào)試異常，這與開發(fā)環(huán)境的IDE中的調(diào)試體驗(yàn)非常相似。

那么哪些公司是主要參與者？

APM和可觀察性已經(jīng)存在大約十年了，出現(xiàn)了很多出色的企業(yè)級產(chǎn)品。而現(xiàn)代生產(chǎn)環(huán)境調(diào)試工具出現(xiàn)較晚，它提供了找出錯誤根源所需的代碼級可觀察性。由于我本人來自O(shè)zcode，因此在描述市場上主要的現(xiàn)代生產(chǎn)調(diào)試工具時，我不想冒存在偏見的風(fēng)險，因此，請自行瀏覽下面的網(wǎng)站并做出評測。

• https://www.rookout.com/

• https://lightrun.com/

• https://www.nerd.vision/

• https://oz-code.com/

• https://www.thundra.io/sidekick

非侵入式生產(chǎn)環(huán)境調(diào)試將成為DevOps工具鏈中不可或缺的一部分

任何新技術(shù)要成為企業(yè)的年度預(yù)算中的標(biāo)準(zhǔn)項(xiàng)目，都需要花費(fèi)一些時間。APM已經(jīng)存在，并且任何在軟件方面值得關(guān)注的企業(yè)都使用這些工具來管理，監(jiān)視其生產(chǎn)系統(tǒng)并對其進(jìn)行故障排除。但是，DevOps專業(yè)人員現(xiàn)在意識到，在調(diào)試生產(chǎn)環(huán)境問題時，需要逐行挖掘代碼，APM不能提供足夠的數(shù)據(jù)進(jìn)行調(diào)試。非侵入式生產(chǎn)環(huán)境調(diào)試器已證明，當(dāng)你提供代碼級可觀察性，動態(tài)日志和跟蹤以及時間旅行調(diào)試時，可以將生產(chǎn)調(diào)試時間最多減少80％。而且，當(dāng)停機(jī)成本高達(dá)每分鐘5600美元時，DevOps專業(yè)人員將無法忽略這筆實(shí)際的企業(yè)成本。
APM是今天確定需要的技術(shù)。不久之后，非侵入式生產(chǎn)環(huán)境調(diào)試器的價值也會成為企業(yè)必不可少的技術(shù)之一。DevOps革命使運(yùn)維人員更接近開發(fā)人員?，F(xiàn)在是時候讓這種合作邁出下一步，進(jìn)入調(diào)試領(lǐng)域了。
原文鏈接：https://dzone.com/articles/the-2021-devops-trend-everyone-is-missing

evabc" data-signature="架構(gòu)師社區(qū)，專注分享架構(gòu)師技術(shù)干貨，架構(gòu)師行業(yè)秘聞，匯集各類奇妙好玩的架構(gòu)師話題和流行的架構(gòu)師動向！" data-from="0">