2021年你不能錯過的DevOps趨勢

彈性工性是什麼意思

「來源： ｜架構師修行之路 ID：jiagoushixiuxing」

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 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；

}

除錯檢測程式碼同樣有挑戰性。大多數現代生產環境偵錯程式都需要先用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革命使運維人員更接近開發人員。現在是時候讓這種合作邁出下一步，進入除錯領域了。

原文連結：https：//dzone。com/articles/the-2021-devops-trend-everyone-is-missing

END

Redis最佳實踐：7個維度+43條使用規範，帶你徹底玩轉Redis | 附實踐清單

我為什麼離開國企，回到網際網路內卷？