深入了解應用程式啟動操作
發布日期：2022/05/13
我們的客戶在高壓環境下待命並進行故障排除時，會使用 Splunk 的行動應用程式。Splunk 的客戶群包括財星百大企業中的 96 家，其中許多公司直接使用 Splunk 的行動應用程式來幫助他們解決營運中斷或大規模的效能問題。因此，我們的產品和服務必須操作起來非常可靠。
我和我的團隊開發了兩個 Splunk 行動應用程式：
1.Splunk On-call (iOS 和 Android)：用於接收和回應頁面的 App。
2.Splunk Observability (iOS 和 Android)：在移動中診斷或分類問題的 App。
當客戶使用這些行動 App 時，即使是應用程式啟動時最輕微的延遲，也會對他們的 MTTA (平均確認時間) 產生負面影響，也影響 MTTR (平均解決時間)。眾所周知，客戶在使用我們的網路和行動 App 來確認、分類和解決生產線的事件時，時間每增加一秒可能就會損失近 100 美元。
由於應用程式快速啟動是使用者操作的重要一環，我們使用在 iOS 和 Android 上執行的 Splunk Real User Monitoring (RUM) 來監控和測量關鍵的檢查點和情境。我們用三個測量值或服務等級指標 (SLI) 來確定在營運環境中應用程式啟動是否合乎期待：
1.應用程式啟動時間 (App Startup Time)
2.就緒時間 (Time to Ready)
3.登入失敗 (Login Failures)
應用程式啟動時間
我們使用 Android Vitals 建議的效能基準，並將其擴展到 iOS 上。啟動時間評量的是從應用程式啟動開始，第一張畫面出現在螢幕上所需的時間。我們使用 SplunkⓇ RUM 自動化儀表來測量我們應用程式中的冷起動 (cold startup)、溫起動 (warm startup) 和熱起動 (hot Startup)時間。
就緒時間
雖然作業系統 (OS) 回報的應用程式啟動很重要，但從使用者的角度來看，應用程式在他們看到資料載入之前並沒有完全啟動。應用程式需要額外的時間才能完全可互動或為使用者「就緒」。
為了評量應用程式的就緒時間，我們使用 Splunk RUM 新增了自訂事件和跨度 (span)，以捕捉應用程式完全可互動並能為使用者所用的真實時間。在程式碼中，我們將此事件稱為：“o11y_user_logged_in_and_ready”。
Android:
iOS:
我們使用 iOS 和 Android 的 Splunk 開放原始碼版本中的 OpenTelemetry Tracing API 來解決多個複雜的使用者路徑中的應用程式邏輯，並得出一個 “就緒時間” 指標。我們還將觀察關鍵檢查點，將其視為 “就緒時間” 序列的一部分，以快速識別瓶頸是什麼，並且不斷最佳化啟動過程。
多個使用者路徑，一個指標
P1 或路徑 1 (最常見的應用程式使用者路徑)：現有應用程式使用者的驗證權杖安全地快取在金鑰庫中。當應用程式打開時，“就緒時間” (或“o11y_user_logged_in_and_ready”) 自訂事件將啟動，以下步驟會被擷取為跨度：
a.當應用程式成功通過驗證時，我們會擷取“o11y_socket_connection_attempt” 跨度，完成我們的第一個檢查點。
b.接下來，應用程式會請求使用者帳戶、警示、儀表板和其他應用程式資料，這些資料會以多個回應訊息回傳並隨後進行處理。可以在 Splunk RUM 的“o11y_fetch_and_store_dashboards” 跨度中看到。
c.同時，應用程式應用其邏輯，將使用者路由到正確的畫面並在資料流入後開始顯示。載入畫面後，我們停止並擷取 “就緒時間” 自定事件。
P2 或路徑 2 (不常用的應用程式使用者路徑；<10% 的時間)：如果具有快取憑證的應用程式使用者嘗試進行驗證，但因權杖無效或過期而失敗，則應用程式會將使用者路由到登入畫面並停止回報 “就緒時間” (或“o11y_user_logged_in_and_ready”) 自訂事件。此外，該應用程式會停止其他跨度，例如“o11y_socket_connection_attempt”。當新使用者在登入流程中輸入無效憑證時，會套用相同的原則。
登入失敗
當使用者趕時間卻無法登入時，可能會沮喪並放棄應用程式。登入失敗的原因很多，Splunk RUM 會為以下情況的每種狀態擷取狀態代碼和訊息：
- 403:使用者名稱和密碼不正確
- 503:後端不接受驗證請求
- 302:設定錯誤的單一登入 (SSO)
代碼 503 是我們 SLI 的一部分，所以我們會密切關注它的發生率，並與後端團隊合作，在出現峰值時立即採取行動。
深度行動應用程式可觀察性
自從我們將 Splunk Real User Monitoring (真實使用者監控) 納入可觀察性 (Observability) 堆疊後，我們的行動工程團隊就可以清楚地了解使用者的操作，以及每次程式碼更改和新版本推出對他們產生的影響。
我們不斷測量、監控和最佳化各種真實使用者指標作為 SLI，包括我們上面分享的三個 SLI。請閱讀這一篇《使用 Splunk RUM 最佳化行動應用程式啟動》的部落格文章，了解我們如何識別前端和後端瓶頸並將應用程式的就緒時間縮短 30% 以上。
________________________________________
此部落格文章由 Splunk 資深產品經理 Seerut Sidhu 共同撰寫。
作者
Brian Gustafson
Brian Gustafson 是 Splunk 的首席軟體工程師。
