對于開發(fā)者來說，可觀測性意味著不同的東西，因?yàn)樗麄兿Ｍ榭磻?yīng)用程序的遙測數(shù)據(jù)，以幫助他們解決與代碼相關(guān)的問題。

翻譯自 Why Developers Need Their Own Observability 。

來自 Shutterstock 的圖片

“為什么會這樣做呢？”

這是軟件開發(fā)人員頻繁提出的問題。他們正在開發(fā)的應(yīng)用程序出現(xiàn)了問題。是他們引入了一個(gè)錯(cuò)誤嗎？是同事做了什么改變嗎？還是在前端和后端之間出現(xiàn)了某種基礎(chǔ)設(shè)施問題？

在不好的、過去的瀑布模型時(shí)代，開發(fā)人員各自獨(dú)立工作。不僅開發(fā)、測試和運(yùn)維完全分離，就連開發(fā)部門內(nèi)部，前端和后端團(tuán)隊(duì)也大部分獨(dú)立工作。

但現(xiàn)在不同了。在今天的分布式、云原生世界中，每個(gè)軟件組件都與許多其他組件交織在復(fù)雜的依賴關(guān)系網(wǎng)絡(luò)中，工作在這些組件上的團(tuán)隊(duì)也是如此。

在這個(gè)快速變化、相互連接的環(huán)境中，開發(fā)人員需要答案，不僅要知道為什么他們的應(yīng)用程序性能可能不佳，還要知道如何修復(fù)它。而為了獲得這些答案，他們需要可觀測性。

并非你所想的可觀測性

在運(yùn)維領(lǐng)域，可觀測性正在風(fēng)靡一時(shí)。裝備所有軟件以生成遙測數(shù)據(jù)流，然后使用數(shù)十種應(yīng)用性能管理（APM）、基礎(chǔ)設(shè)施管理或 IT 運(yùn)維管理（ITOM）工具來理解所有這些數(shù)據(jù)。

運(yùn)維人員和網(wǎng)站可靠性工程師的可觀測性工作目標(biāo)很明確：匯總?cè)罩竞推渌b測數(shù)據(jù)，檢測威脅，監(jiān)控應(yīng)用程序和基礎(chǔ)設(shè)施性能，檢測行為異常，優(yōu)先處理這些異常，確定其根本原因，并將發(fā)現(xiàn)的問題指向其底層負(fù)責(zé)人。

基本上，運(yùn)維人員希望保持一切運(yùn)行正?！@是一個(gè)重要的目標(biāo)，但不一定是開發(fā)人員所關(guān)心的。

開發(fā)人員同樣需要可觀測性，但出于不同的原因。如今的開發(fā)人員對部署的代碼成功負(fù)有責(zé)任。因此，他們需要持續(xù)了解他們正在開發(fā)的代碼在生產(chǎn)環(huán)境中的表現(xiàn)。

與以運(yùn)維為重點(diǎn)的可觀測性工具不同，以開發(fā)為重點(diǎn)的可觀測性專注于開發(fā)人員關(guān)心的問題，比如文檔對象模型（DOM）事件、API 行為、檢測糟糕的代碼模式和代碼異味、識別有問題的代碼行和測試覆蓋率。

因此，對于開發(fā)人員來說，可觀測性的含義與運(yùn)維人員不同，因?yàn)殚_發(fā)人員希望以不同的方式查看應(yīng)用程序遙測數(shù)據(jù)，以幫助他們解決與代碼相關(guān)的問題。

開發(fā)人員需要為他們的需求而構(gòu)建的可觀測性

由于今天的開發(fā)人員在復(fù)雜的分布式應(yīng)用程序上工作，他們需要能洞察這類應(yīng)用程序行為的可觀測性。特別是，開發(fā)人員需要：

• 端到端的追蹤能力：開發(fā)人員必須能夠追蹤用戶交互或其他事件從前端到后端的過程。

• 對 API 行為的可見性：API 是支撐現(xiàn)代軟件的粘合劑。因此，構(gòu)建 API 是開發(fā)人員的核心任務(wù)。API 的行為良好與否取決于暴露 API 的代碼以及使用 API 的軟件。開發(fā)人員需要同時(shí)了解這兩方面的情況。

• 事件追蹤，也稱為“面包屑”：解決問題可能像解謎一樣。通過跟蹤導(dǎo)致問題的事件，可以確定問題的原因并找到解決方法。

• 版本更改和責(zé)任方：在許多情況下，出現(xiàn)的問題是其他開發(fā)人員的工作結(jié)果。追蹤誰在做什么以及他們的更改如何影響軟件現(xiàn)狀是至關(guān)重要的。開發(fā)人員希望快速評估問題，并將其解決或指向負(fù)責(zé)人。

• 發(fā)布跟蹤：開發(fā)人員需要跟蹤每個(gè)發(fā)布的新問題和回歸。他們還必須跟蹤問題的解決情況并監(jiān)控應(yīng)用程序的健康狀況。

• 測試覆蓋率：開發(fā)人員還需要測試用例來確保他們的代碼是可靠的。此外，如果某些代碼片段從未運(yùn)行過，就無法進(jìn)行測試。這樣的代碼存在也會暴露出一些邏輯錯(cuò)誤，阻止代碼的運(yùn)行。

• 對預(yù)發(fā)布和發(fā)布后行為的可見性：開發(fā)人員通常在預(yù)發(fā)布環(huán)境中編碼和測試。他們需要預(yù)發(fā)布的可觀測性來確保應(yīng)用程序在此環(huán)境中正常工作。只有在這之后，他們才會將代碼推向生產(chǎn)環(huán)境。之后，他們?nèi)匀恍枰O(jiān)控和觀察應(yīng)用程序，以確保它在發(fā)布后能正常運(yùn)行，因?yàn)槠渌_發(fā)人員繼續(xù)推送可能影響他們自己的代碼的代碼。

顯然，開發(fā)人員的可觀測性需求與運(yùn)維人員的需求相當(dāng)不同。如果沒有以開發(fā)人員為重點(diǎn)的可觀測性帶來的好處，開發(fā)人員的工作效率將降低，整體代碼質(zhì)量也會較差。

最糟糕的是，如果沒有足夠的可觀測性，開發(fā)人員將像在黑暗中行走一樣遇到問題——這些問題將會絆倒他們，影響到開發(fā)人員需要良好工作的創(chuàng)造力流程。

##Intellyx 觀點(diǎn)

我們都遇到過加載緩慢的頁面和其他性能問題，以及可怕的 HTTP 500 內(nèi)部服務(wù)器錯(cuò)誤——一個(gè)指示出現(xiàn)了問題的空白網(wǎng)頁。

沒有人希望看到這樣的錯(cuò)誤——尤其是開發(fā)人員。他們?nèi)狈π畔ⅲo急修復(fù)的需求卻迫在眉睫。

如果沒有開發(fā)人員可觀測性工具提供的可見性，開發(fā)人員將處于黑暗中。這樣的工具應(yīng)該在每個(gè)開發(fā)團(tuán)隊(duì)的購物清單上。

不幸的是，購買一個(gè)以開發(fā)人員為重點(diǎn)的可觀測性工具可能會很棘手。APM 和 ITOM 是明確定義的類別，有著提供成熟產(chǎn)品的已建立供應(yīng)商。但對于以開發(fā)為重點(diǎn)的可觀測性，情況并非如此。

在這個(gè)領(lǐng)域，少數(shù)幾家供應(yīng)商正在開創(chuàng)先河，其中之一就是 Sentry ，但單一供應(yīng)商并不能構(gòu)成市場。然而，考慮到開發(fā)人員可觀測性的重要性，其他供應(yīng)商很快就會涌入這個(gè)重要的領(lǐng)域。