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

• 混合部署（Hybrid Deployments）

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

• 彈性測(cè)試

• 生產(chǎn)測(cè)試

• GitOps

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

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

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

• 邊緣計(jì)算

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

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

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

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

• Kubernetes

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

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

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

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

1. 令人討厭的錯(cuò)誤

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

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

4. 構(gòu)建

5. 部署

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

7. 看一下日志

8. 找到問(wèn)題了么

1. 沒(méi)有 - 回到步驟2

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

就像下面這個(gè)圖展示一樣：

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

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

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

為什么DevOps工程師開(kāi)始對(duì)生產(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)境會(huì)過(guò)濾掉更多的bug（更低的變更失敗率，較低的缺陷遺失率，以及更高的平均無(wú)故障時(shí)間（MTBF））

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

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

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

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

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

加入檢測(cè)后，可能看起來(lái)像這樣：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)試檢測(cè)代碼同樣有挑戰(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è)置。以及如何處理第三方代碼？一些工具通過(guò)反編譯正在調(diào)試的生產(chǎn)代碼來(lái)解決此問(wèn)題。這使工作變得更加輕松，因?yàn)樗似ヅ湓次募囊?，并且將第三方代碼與舊代碼一起反編譯。

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

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

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

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

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

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

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

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

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

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

• 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)一些時(shí)間。APM已經(jīng)存在，并且任何在軟件方面值得關(guān)注的企業(yè)都使用這些工具來(lái)管理，監(jiān)視其生產(chǎn)系統(tǒng)并對(duì)其進(jìn)行故障排除。但是，DevOps專業(yè)人員現(xiàn)在意識(shí)到，在調(diào)試生產(chǎn)環(huán)境問(wèn)題時(shí)，需要逐行挖掘代碼，APM不能提供足夠的數(shù)據(jù)進(jìn)行調(diào)試。非侵入式生產(chǎn)環(huán)境調(diào)試器已證明，當(dāng)你提供代碼級(jí)可觀察性，動(dòng)態(tài)日志和跟蹤以及時(shí)間旅行調(diào)試時(shí)，可以將生產(chǎn)調(diào)試時(shí)間最多減少80％。而且，當(dāng)停機(jī)成本高達(dá)每分鐘5600美元時(shí)，DevOps專業(yè)人員將無(wú)法忽略這筆實(shí)際的企業(yè)成本。
APM是今天確定需要的技術(shù)。不久之后，非侵入式生產(chǎn)環(huán)境調(diào)試器的價(jià)值也會(huì)成為企業(yè)必不可少的技術(shù)之一。DevOps革命使運(yùn)維人員更接近開(kāi)發(fā)人員?，F(xiàn)在是時(shí)候讓這種合作邁出下一步，進(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)師動(dòng)向！" data-from="0">