DevOps已經(jīng)蓬勃發(fā)展起來，DevOps無處不在，現(xiàn)在一切都跟DevOps息息相關(guān)。但是我發(fā)現(xiàn)關(guān)于Deveops的一個(gè)新的趨勢(shì)是大家都未注意到的。

最近，我讀了很多人做的關(guān)于2021年DevOps的發(fā)展趨勢(shì)時(shí)，DevOps欣欣向榮。 DevOps就是一切，如今一切都是DevOps。

以下是如今爆炸性增長的DevOps趨勢(shì)的部分列表：

• 混合部署 (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)

這樣的例子不勝枚舉…

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

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

讓我們從零開始，當(dāng)我們想要調(diào)試生產(chǎn)環(huán)境的問題時(shí)

我們最常用的方式就是 - 查看日志文件。這個(gè)痛苦的，重復(fù)的過程就像下面這樣：

1. 令人討厭的錯(cuò)誤
2. 該死，我沒有足夠的數(shù)據(jù)。
3. 讓我在日志中添加幾行
4. 構(gòu)建
5. 部署
6. 復(fù)現(xiàn)錯(cuò)誤步驟
7. 看一下日志
8. 找到問題了么?

• 沒有 - 回到步驟2
• 找到了(在幾次耗時(shí)很久嘗試以后)- 終于結(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)的狀況(以便您解決錯(cuò)誤)。

但是，在修復(fù)生產(chǎn)環(huán)境中的錯(cuò)誤時(shí)，這些工具往往不能提供足夠的數(shù)據(jù)。通常它們能獲得的最詳盡的信息是顯示拋出異常的位置，以及堆棧追蹤(stack trace)以及有關(guān)錯(cuò)誤情況的一些常規(guī)元數(shù)據(jù)，例如瀏覽器或操作系統(tǒng)的信息。

通常這些信息并不足以找到錯(cuò)誤。微服務(wù)和無服務(wù)器等現(xiàn)代軟件體系結(jié)構(gòu)使事情變得更加困難。想象一下，跟蹤一個(gè)使Kubernetes集群中的節(jié)點(diǎn)崩潰的錯(cuò)誤，而Kubernetes只會(huì)啟動(dòng)一個(gè)新實(shí)例?；驘o服務(wù)器方法(serverless function)中的邏輯錯(cuò)誤。當(dāng)您調(diào)試這些問題時(shí)，證據(jù)已隨著銷毀的實(shí)例而不復(fù)存在。

非侵入式生產(chǎn)環(huán)境調(diào)試使可觀察性更進(jìn)一步，即便對(duì)于微服務(wù)和無服務(wù)器(serverless)代碼，也能在代碼級(jí)別逐行顯示了應(yīng)用程序的行為。這就是我們所說的代碼級(jí)可觀察性，它彌補(bǔ)了DevOps從APM(應(yīng)用程序性能監(jiān)視工具)無法獲得的可觀察性。

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

您應(yīng)該猜到為什么我如此著迷于非侵入式生產(chǎn)環(huán)境調(diào)試。因?yàn)檫@就是我公司的基礎(chǔ)，我們的感受在與潛在客戶和客戶的會(huì)議中有了明顯的轉(zhuǎn)變。

一年前，主持會(huì)議的同行是開發(fā)人員，盡管是高級(jí)開發(fā)人員或開發(fā)經(jīng)理，但仍然是開發(fā)人員。 DevOps工程師可能在會(huì)議室里，但是他們?cè)陂_會(huì)過程中只是在后排坐著，只有在我們開始討論軟件如何影響或不影響生產(chǎn)系統(tǒng)，以及關(guān)于安全性，性能，部署等還有很多問題時(shí)參與討論。但Devops工程師對(duì)于我們的生產(chǎn)環(huán)境調(diào)試器的使用方式或?qū)λ鼈兊挠猛緟s沒有太多的了解，至少不是由DevOps員工提供的。他們只是將其視為開發(fā)人員需要他們?cè)谏a(chǎn)環(huán)境中維護(hù)的另一種工具。

在過去的一年中，重點(diǎn)已經(jīng)明顯轉(zhuǎn)移。坐在會(huì)議室的DevOps工程師坐在前排，提出了更多問題，并且開始意識(shí)到有效的生產(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工程師開始對(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ì)過濾掉更多的bug(更低的變更失敗率，較低的缺陷遺失率，以及更高的平均無故障時(shí)間(MTBF))
• 能夠自動(dòng)捕獲和顯示異常的生產(chǎn)環(huán)境調(diào)試器不僅會(huì)在發(fā)生錯(cuò)誤時(shí)立即通知您，而且會(huì)記錄完整的錯(cuò)誤執(zhí)行流，使您能夠非?？焖俚亓私饽且幚碚嬲腻e(cuò)誤還是無關(guān)緊要的錯(cuò)誤，以及錯(cuò)誤的嚴(yán)重性及其影響(降低平均探測時(shí)間 (MTTD))。
• 生產(chǎn)環(huán)境調(diào)試器極大地減少了識(shí)別，分析和修復(fù)生產(chǎn)錯(cuò)誤所需的時(shí)間(即平均恢復(fù)時(shí)間(MTTR))。當(dāng)我們開始討論此KPI時(shí)，坐在房間里的所有DevOps工程師都會(huì)坐起來，因?yàn)檫@反映了當(dāng)生產(chǎn)中出現(xiàn)問題時(shí)服務(wù)將不可用多長時(shí)間。我們知道這種事一定會(huì)發(fā)生，只需查看這個(gè)記錄網(wǎng)站不可用的探測網(wǎng)站 downdetector.com，您就會(huì)明白我的意思。

DevOps工程師和SRE意識(shí)到，生產(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ù)，用來解決錯(cuò)誤。 使用生產(chǎn)環(huán)節(jié)調(diào)試器，DevOps和開發(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ù)該過程并重復(fù)。盡管這是獲取生產(chǎn)數(shù)據(jù)的簡便方法，但它具有侵入性，并且會(huì)對(duì)性能產(chǎn)生重大影響，因此現(xiàn)在并未得到廣泛使用。

快照調(diào)試

另一種方式是快照調(diào)試，調(diào)試器將會(huì)fork進(jìn)程一份進(jìn)程的副本(使用寫時(shí)復(fù)制copy-on-write技術(shù))，然后通過檢查副本來進(jìn)行調(diào)試。盡管此方法讓您可以檢查調(diào)試過程的整個(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é)碼中，例如測量性能，捕獲應(yīng)用程序狀態(tài)，捕獲異常等。這是APM多年來一直在做的事情。生產(chǎn)環(huán)境調(diào)試器將其進(jìn)一步擴(kuò)展。它和APM使用相同的技術(shù)，目標(biāo)是解決報(bào)錯(cuò)和邏輯錯(cuò)誤，而不是解決生產(chǎn)和預(yù)生產(chǎn)環(huán)境中的性能問題。

由于人類看不懂字節(jié)碼，因此讓我們看看如果在源代碼中添加檢測功能，字節(jié)碼會(huì)是什么樣子。

代碼如下： 

public async Task<BasketModel> 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<BasketModel> 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í)時(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)試器通過其使用的侵入式寫時(shí)復(fù)制技術(shù)對(duì)運(yùn)行中的系統(tǒng)造成的內(nè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)試器插裝來獲取數(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)。
• 集成：您可以在無需中斷的斷點(diǎn)/跟蹤點(diǎn)的情況下，將測量的任何內(nèi)容通過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)來完成的工作外，某些生產(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è)過程中導(dǎo)致異常的完整錯(cuò)誤執(zhí)行流以及應(yīng)用程序數(shù)據(jù)。這樣就可以逐行調(diào)試異常，這與開發(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í)可觀察性。由于我本人來自O(shè)zcode，因此在描述市場上主要的現(xiàn)代生產(chǎn)調(diào)試工具時(shí)，我不想冒存在偏見的風(fēng)險(xiǎn)，因此，請(qǐng)您自行瀏覽下面的網(wǎng)站并做出評(pí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)一些時(shí)間。 APM已經(jīng)存在，并且任何在軟件方面值得關(guān)注的企業(yè)都使用這些工具來管理，監(jiān)視其生產(chǎn)系統(tǒng)并對(duì)其進(jìn)行故障排除。但是，DevOps專業(yè)人員現(xiàn)在意識(shí)到，在調(diào)試生產(chǎn)環(huá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è)人員將無法忽略這筆實(shí)際的企業(yè)成本。

APM是今天確定需要的技術(shù)。不久之后，非侵入式生產(chǎn)環(huán)境調(diào)試器的價(jià)值也會(huì)成為企業(yè)必不可少的技術(shù)之一。 DevOps革命使運(yùn)維人員更接近開發(fā)人員。現(xiàn)在是時(shí)候讓這種合作邁出下一步，進(jìn)入調(diào)試領(lǐng)域了。