2021年你可能錯過的DevOps趨勢

作者：grace_shi 2021-05-15 08:30:40

運維系統運維

DevOps已經蓬勃發展起來，DevOps無處不在，現在一切都跟DevOps息息相關。但是我發現關于Deveops的一個新的趨勢是大家都未注意到的。

最近，我讀了很多人做的關于2021年DevOps的發展趨勢時，DevOps欣欣向榮。 DevOps就是一切，如今一切都是DevOps。

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

混合部署 (Hybrid Deployments)
數據運維(DataOps)
彈性測試
生產測試
GitOps
微服務(當然)
無服務器(Serverless)
以云服務為中心的基礎架構
邊緣計算
基礎架構即代碼
開發安全(DevSecOps)
應用程序性能監視(APM)工具
混合計算 (Hybrid Computing)
Kubernetes
功能開關 (Feature Toggles)

這樣的例子不勝枚舉…

但是，在閱讀了所有這些文章后，令我震驚的是，沒有一個人將"非侵入式生產環境調試"視為DevOps工具鏈的標準組件。而這就是我所看到的DevOps趨勢。

那么什么是“非侵入式生產環境調試”

讓我們從零開始，當我們想要調試生產環境的問題時

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

令人討厭的錯誤
該死，我沒有足夠的數據。
讓我在日志中添加幾行
構建
部署
復現錯誤步驟
看一下日志
找到問題了么?

沒有 - 回到步驟2
找到了(在幾次耗時很久嘗試以后)- 終于結束了

你還可以選擇將遠程調試器直接連接到生產環境，但是通常情況下，運維團隊不允許這樣做。出于安全考慮，你并不想在斷點處暫停執行而中斷服務。

非侵入式生產環境調試遵循可觀察性工具的概念。這些是APM(應用程序性能監視工具)，用于展示，分片和分塊日志，指標和追蹤(trace)。這就是可觀察性。在不中斷或干擾系統運行的情況下，了解系統的狀況(以便您解決錯誤)。

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

通常這些信息并不足以找到錯誤。微服務和無服務器等現代軟件體系結構使事情變得更加困難。想象一下，跟蹤一個使Kubernetes集群中的節點崩潰的錯誤，而Kubernetes只會啟動一個新實例。或無服務器方法(serverless function)中的邏輯錯誤。當您調試這些問題時，證據已隨著銷毀的實例而不復存在。

非侵入式生產環境調試使可觀察性更進一步，即便對于微服務和無服務器(serverless)代碼，也能在代碼級別逐行顯示了應用程序的行為。這就是我們所說的代碼級可觀察性，它彌補了DevOps從APM(應用程序性能監視工具)無法獲得的可觀察性。

為什么我認為這是一個很重要的趨勢?

您應該猜到為什么我如此著迷于非侵入式生產環境調試。因為這就是我公司的基礎，我們的感受在與潛在客戶和客戶的會議中有了明顯的轉變。

一年前，主持會議的同行是開發人員，盡管是高級開發人員或開發經理，但仍然是開發人員。 DevOps工程師可能在會議室里，但是他們在開會過程中只是在后排坐著，只有在我們開始討論軟件如何影響或不影響生產系統，以及關于安全性，性能，部署等還有很多問題時參與討論。但Devops工程師對于我們的生產環境調試器的使用方式或對它們的用途卻沒有太多的了解，至少不是由DevOps員工提供的。他們只是將其視為開發人員需要他們在生產環境中維護的另一種工具。

在過去的一年中，重點已經明顯轉移。坐在會議室的DevOps工程師坐在前排，提出了更多問題，并且開始意識到有效的生產調試可以如何顯式的影響DevOps KPI，即便實際上是開發團隊中的工程師在進行根本原因(root cause)分析并提出建議或者提交代碼。DevOps團隊開始更加關注生產調試。

為什么DevOps工程師開始對生產環境調試感興趣?

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

Staging 環境會過濾掉更多的bug(更低的變更失敗率，較低的缺陷遺失率，以及更高的平均無故障時間(MTBF))
能夠自動捕獲和顯示異常的生產環境調試器不僅會在發生錯誤時立即通知您，而且會記錄完整的錯誤執行流，使您能夠非常快速地了解您是要處理真正的錯誤還是無關緊要的錯誤，以及錯誤的嚴重性及其影響(降低平均探測時間 (MTTD))。
生產環境調試器極大地減少了識別，分析和修復生產錯誤所需的時間(即平均恢復時間(MTTR))。當我們開始討論此KPI時，坐在房間里的所有DevOps工程師都會坐起來，因為這反映了當生產中出現問題時服務將不可用多長時間。我們知道這種事一定會發生，只需查看這個記錄網站不可用的探測網站 downdetector.com，您就會明白我的意思。

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

那么生產環境調試器是如何工作的呢?

遠程調試器

生產環境調試并不是一個全新的概念。遠程調試已經存在了一段時間，您可以在運行時注入斷點，在每次斷點命中時收集數據，然后立即繼續該過程并重復。盡管這是獲取生產數據的簡便方法，但它具有侵入性，并且會對性能產生重大影響，因此現在并未得到廣泛使用。

快照調試

另一種方式是快照調試，調試器將會fork進程一份進程的副本(使用寫時復制copy-on-write技術)，然后通過檢查副本來進行調試。盡管此方法讓您可以檢查調試過程的整個內存占用量，但它也是侵入性的，給正在運行的主機上增加了很大的內存負載，因此進行快照的dian數量是有限制。

插裝(instrumentation)

現代生產環境調試器使用第三種方法-字節碼插裝。它們將插裝添加到執行不同功能的字節碼中，例如測量性能，捕獲應用程序狀態，捕獲異常等。這是APM多年來一直在做的事情。生產環境調試器將其進一步擴展。它和APM使用相同的技術，目標是解決報錯和邏輯錯誤，而不是解決生產和預生產環境中的性能問題。

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

代碼如下：

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; 
}

調試檢測代碼同樣有挑戰性。大多數現代生產環境調試器都需要先用git找到精確的生產環境使用的commit，從中構建出和生產環境相同的二進制文件以便調試。將所有正確的源文件與生產環境中當前正在運行的文件進行匹配并不總是一件容易的事，并且您還需要匹配一組構建和編譯設置。以及如何處理第三方代碼?一些工具通過反編譯正在調試的生產代碼來解決此問題。這使工作變得更加輕松，因為它消除了匹配源文件的要求，并且將第三方代碼與舊代碼一起反編譯。

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

遠程調試器具有很強的侵入性，因為它們連接到主機應用程序并將斷點放置在實時運行的系統中。即使應用程序只是短暫中斷了以供遠程調試器收集數據，仍然存在許多生產系統所不能容忍的巨大穩定性風險。同樣，快照調試器通過其使用的侵入式寫時復制技術對運行中的系統造成的內存開銷也存在耗盡系統內存的風險。例如，Microsoft的Snapshot Debugger默認為每分鐘最多五個快照，以避免拋出內存不足的異常。

插裝(instrumentation)和生產調試器一起可以做什么?

現代生產環境調試器所做的大部分工作都是基于不間斷的斷點(也稱為追蹤點)。在希望獲取數據的那一行打上斷點(即追蹤點)讓調試器插裝來獲取數據。您實際上可以做很多事情：

動態日志：記錄代碼中任何位置的數據，包括局部變量和方法參數的值。
動態指標：就像是動態日志，從局部變量中您可以提取到應用程序級別數據，從而衡量不同的指標。
集成：您可以在無需中斷的斷點/跟蹤點的情況下，將測量的任何內容通過API傳播到第三方應用程序。因此，您可以創建Slack通知或將動態日志和指標數據傳遞到APM，在其中您可以進一步對數據進行分片和分塊，以精美的圖形和圖表查看數據，并且創建有意義的警報。

除了使用不中斷的斷點/跟蹤點來完成的工作外，某些生產環境調試器還可以執行以下操作：

捕獲異常：這已經是許多APM所做的事情，但是生產環境調試器將提供有關異常以及拋出異常的局部信息和變量值的更多信息。
時間旅行記錄：某些生產環境調試器不僅捕獲異常，而且捕獲整個過程中導致異常的完整錯誤執行流以及應用程序數據。這樣就可以逐行調試異常，這與開發環境的IDE中的調試體驗非常相似。

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

APM和可觀察性已經存在大約十年了，出現了很多出色的企業級產品。而現代生產環境調試工具出現較晚，它提供了找出錯誤根源所需的代碼級可觀察性。由于我本人來自Ozcode，因此在描述市場上主要的現代生產調試工具時，我不想冒存在偏見的風險，因此，請您自行瀏覽下面的網站并做出評測。

https://www.rookout.com/
https://lightrun.com/
https://www.nerd.vision/
https://oz-code.com/
https://www.thundra.io/sidekick

非侵入式生產環境調試將成為DevOps工具鏈中不可或缺的一部分

任何新技術要成為企業的年度預算中的標準項目，都需要花費一些時間。 APM已經存在，并且任何在軟件方面值得關注的企業都使用這些工具來管理，監視其生產系統并對其進行故障排除。但是，DevOps專業人員現在意識到，在調試生產環境問題時，需要逐行挖掘代碼，APM不能提供足夠的數據進行調試。非侵入式生產環境調試器已證明，當您提供代碼級可觀察性，動態日志和跟蹤以及時間旅行調試時，可以將生產調試時間最多減少80%。而且，當停機成本高達每分鐘5600美元時，DevOps專業人員將無法忽略這筆實際的企業成本。

APM是今天確定需要的技術。不久之后，非侵入式生產環境調試器的價值也會成為企業必不可少的技術之一。 DevOps革命使運維人員更接近開發人員。現在是時候讓這種合作邁出下一步，進入調試領域了。

責任編輯：未麗燕來源： Dockone.io

DevOps 測試趨勢