原文作者：KRISTINE PINEDO

譯者：白樂航

歡迎訪問網易雲社區，了解更多網易技術產品運營經驗。

作為軟件開發者，您只需要為客戶編寫和交付出色的產品和功能。 但您也知道軟件開發並不總是那麽容易，因為進行叠代時候可能會引入bug。 畢竟，“如果調試是刪除軟件bug的過程，那麽編程肯定就是將bug放入去的過程”，正如Edsger Dijkstra（譯者註：著名荷蘭計算機科學家，我們熟知有向圖最短路徑算法--迪傑斯特拉算法就是他的），所說。

因為這些問題將會影響你的客戶，所以你可能會感到修復應用程序中的每個bug的強大動力。

但這是一個壞主意。

應用程序穩定性和零bug

不存在零bug的應用程序，因此制定有效處理策略是至關重要。這就是為什麽應用程序穩定性指標對於敏捷團隊如此重要。穩定性可以定義為給定版本的應用程序交互中每個功能正常的百分比。它是通過跟蹤應用程序用戶遇到的崩潰(未處理的bug)的百分比來計算的。

考慮可用性對於了解穩定性指標是有幫助的。 你可能已經熟悉“五個九”的可用性（譯者註：即99.999%高可用性），並且你也已經知道不要設目標為100%，即使它看起來像是一個合乎情理可能完成的目標。 超過某一程度時，你將會遇到回報遞減，因為高可用性目標是昂貴的而且不總是能夠帶來實實在在的好處。 Sean Hull談到了為什麽高可用性的評價過高了。

事實上，以五個九的標準維持高可用性會花費很多錢。

關於穩定性的還有個類似的情況 —— 在某種情況下，由於構建新功能的機會成本很高，所以修復bug成本很高。所以你制定目標時要考慮可行性，它不應該是100％。

這就是原因。

敏捷統治世界

敏捷開發現在主導著軟件開發過程，並且已經超過瀑布模型，成為構建和部署軟件的實際上的方法。在VersionOne發布的2018年敏捷狀態報告中，97%的受訪者表示他們在他們的組織中實踐過敏捷開發。敏捷團隊正在以前所未有的速度構建和交付軟件。許多開發者實行持續部署，這使他們能夠在每周、通常是每天的基礎上快速叠代他們的工作。快速的發布周期使得在發布後修復問題變得很容易，因此在發布前修復每個bug不再是絕對重要的。然而，在敏捷開發中，傳統的QA和測試的可用時間也更少，這增加了引入bug的風險。

那麽，如何平衡快節奏的開發和bug呢?應用程序的穩定性需要一個反饋循環，可以使用穩定性監視工具進行跟蹤。

用戶可以選擇

客戶可以選擇使用他們使用的應用程序，因此，如果您想讓客戶隨時隨地提供可靠，高質量的應用體驗至關重要。 這是一個常見的例子，但我們都經歷過。你需要參加會議，就打開騎行應用程序中的一個。 令人討厭的是，優步(Uber )不適合你並且看起來還崩潰了，但你仍然需要參加你的會議，所以你打開Lyft來使自己按時到達。 因為這可以很容易地發生，你可能會覺得有必要修復每一個突然出現的bug。 但關於這些bug Jeff Atwood’s 提出了很重要的問題，

“你如何區分用戶可能遇到的bug，以及用戶可能永遠不會看到的bug？”

這是一個需要考慮的重要問題，你可以打賭你的競爭對手也會試圖自己解決這個問題，這樣他們就可以通過快速發布新功能來繼續改進他們的產品。

客戶端的西部蠻荒

並不是所有的bug都是一樣的，在客戶端應用程序中尤其如此。

JavaScript比以往任何時候都流行，超過69%的開發人員使用JavaScript，使其成為最常用的編程語言。JavaScript的一個難點是，一旦部署到瀏覽器中，應用程序運行的條件可能會有很大的不同。考慮到大量的不同的瀏覽器、版本、擴展和其他可能影響應用程序穩定性的因素，幾乎不可能考慮所有可能的場景。而且由於存在如此多的差異，大量的穩定性問題將成為不會影響大多數用戶的邊緣問題。例如，由於非常低的使用率和奇怪的怪癖，調查Internet Explorer 6（譯者註：非常老的瀏覽器，2001發布2014微軟停止維護）引起的bug可能毫無意義。

移動應用程序為開發人員帶來了類似的挑戰。Android設備中的設備種類是非常多的。你知道2015年市場上有超過24000種不同的安卓設備嗎?

部署到移動設備可能更加不可預測，因為設備和設置可能會有很大的不同，並在與應用程序交互時導致問題。像JavaScript一樣，很多突然出現的bug都是邊緣情況，只會影響少數罕見的手機。

花幾個小時修復一個只影響少數用戶的bug是不值得的。

特性或bug?選擇一個。

正如Eric Sink所寫的，“關於軟件質量的決策可能是艱難而微妙的，當我們做出這些決策需要非常明智。有時一個“bug”不應該被修復。那麽，有什麽更好的方法來看待bug呢?

將穩定性轉化為團隊的KPI。

選擇一個可以實現的，有意義的目標，你的團隊可以為此負責。穩定性指標可以幫助你決策關於工程資源的數據驅動。當你計劃短期加速進度時，你應該分配時間來解決問題，還是應該在產品路線圖上全速前進?應用程序穩定性幫助你做出決定。

值得重新檢查你的警報堆積，以確保你有必要的反饋循環，或者是否有改進策略的空間。我留給你們幾個重要的問題要考慮:

-你的團隊是否考慮過應用程序的穩定性?

-你目前如何選擇修復bug和構建新特性?

-你的團隊如何跟蹤和優先處理bug修復?

原文：https://blog.bugsnag.com/application-stability-monitoring/

免費領取驗證碼、內容安全、短信發送、直播點播體驗包及雲服務器等套餐

更多網易技術、產品、運營經驗分享請點擊。

相關文章：
【推薦】 2018中國雲原生用戶大會：網易雲爆料完整微服務的研發過程

【譯文】不是所有的 bug 都值得修復的