為操作可見性建置儀表板

人人都會在筆記型電腦、平板電腦和智慧型手機上執行應用程式。我們很容易就能看出裝置是否啟動，或是 Wi-Fi 網路連線是否上線。我們知道螢幕上會顯示一切關鍵通知，例如可用磁碟空間過小的警告。事實上，使用者界面 (UI) 的概略速度和反應能力算是良好的指標，能藉以判斷裝置是否有足夠的資源 (例如記憶體或 CPU) 以便執行應用程式。

凡是曾為家人提供過遠端技術支援的人都能證實，在無法看見、不能直接與裝置互動的情形下，偵測與診斷問題會稍微困難一些。因此，談到執行雲端服務，我們面臨著類似的挑戰：該如何監控遠端服務，又如何知道客戶是否滿意？

若要觀察單主機服務，可以登入該主機、執行各種執行階段監控工具，並檢查日誌，以判斷主機發生情形的根本原因。然而，單主機解決方案僅對最簡單的非關鍵服務可行。相對極端的例子包括多層、分散式微型服務，在成千上百的伺服器、容器或無伺服器環境內執行。

Amazon 究竟如何看出，在全球許多區域的眾多可用區域內執行的所有雲端服務，實際的行為表現？ 自動監控、自動修復工作流程 (例如，流量轉移) 及自動部署系統，對於偵測及解決此規模的絕大多數問題而言是為關鍵。然而，因為許多理由，我們仍然需要在任何時刻都能看出這些服務、工作流程和部署的運作狀況。

我們以儀表板作為一種機制，達成這項保持在雲端服務活動之上的挑戰。儀表板面向真人、提供對於我們系統的檢視，顯示簡明的摘要，展現時間序列性質的指標、日誌、追蹤和警示資料，以表示系統的行為。

在 Amazon，我們將這類儀表板的建立、使用和後續維護稱為儀表板作業。儀表板作業已演進成為一流活動，因為這是我們作為其他日常軟體遞送和操作服務，例如設計、編碼、建置、測試、部署和擴展服務的服務成功關鍵。

當然，我們不期望操作人員始終在監控儀表板。這些儀表板大多時候是無人觀看的情形。事實上，我們發現，凡是要求人工審閱儀表板的操作程序都會由於人為錯誤而失敗，無論審閱儀表板的頻率有多高。為解除此項風險，我們建立了自動化警示以持續評估系統所發出最重要的監控資料。一般而言，這類指標是指出系統趨近某個限值 (造成影響之前的主動偵測)，或系統已意外受損 (受影響後的反應式偵測)。

這類警示能執行自動修復工作流程，也能通知操作人員有問題存在。通知會將操作人員導向確切的儀表板和需要使用的 Runbook。我在待命時，若有警示通知提醒我出現問題，我能迅速使用相關儀表板將客戶所受的影響量化、驗證根本原因或加以分類、減輕，和縮短復原時間。即使警示已啟動自動修復工作流程，我仍需要觀察自動工作流程運作得如何、對系統有何效應，在例外情況下並為關鍵的安全步驟提供人工確認，將工作流程移至前方。

有事件進行中時，Amazon 通常會派出多位待命的操作人員。操作人員因為各逐步進行一系列的任務，所以使用的儀表板可能不同。這些任務通常包括將客戶所受的影響量化、分類、遍及多重服務追蹤至事件的根本原因、觀察自動修復工作流程，及執行並驗證 Runbook 式減輕步驟。同時在事件發生期間，同等團隊與商業利害關係人也在使用儀表板監控後續影響。各路的這些參與者能以事件管理工具、聊天室 (使用例如 AWS Chatbot 的機器人) 和電話會議進行通訊。利害關係人分別對於從儀表板所見的資料自抱持著不同的視角。

每一週，Amazon 團隊與更廣大的組織也會舉行操作審閱會議，有資深領導人、經理和許多工程師參加。在這些會議上，我們使用幸運輪盤選擇高階稽核儀表板。利害關係人會審閱我們客戶得到的體驗與主要的服務層級目標，例如可用性和延遲。這些利害關係人所使用的稽核儀表板通常能顯示來自所有可用區域和區域的操作資料。

此外，Amazon 進行長期容量規劃和預測時，會用儀表板將系統經過較長時間間隔所釋出的最高階商業、用量和容量指標加以視覺化。

人們使用儀表板以手動監控服務，但同一種不盡然適合所有使用案例。針對大多數的系統，我們使用多種儀表板，各自提供系統的不同檢視。這些不同的檢視能讓不同的使用者從不同的視角和採取不同的時間間隔，了解系統的行為表現。

各種對象所想檢視的資料，在各儀表板之間可能有明顯的差異。我們已學會在設計儀表板時以適用的對象為焦點。我們根據儀表板的使用者，及其使用儀表板的原因，決定各儀表板所含的資料。您或許已經聽說，我們 Amazon 採取自客戶逆向操作的方式。其中儀表板的建立正是很好的例子。我們根據預計使用者的需要及其特定要求來建置儀表板。

下圖說明各種儀表板如何整體地提供系統的不同檢視：

在 Amazon，我們最重要、使用也最廣的儀表板，是客戶體驗儀表板。這類儀表板是為廣大的一群使用者所設計，包括服務操作人員和許多其他利害關係人。能夠高效地就整體服務運作狀態和忠於目標提出指標。所顯示的監控資料源自服務本身，也出自用戶端儀表、持續測試工具 (如 Amazon CloudWatch Synthetics Canary) 和自動修復系統。這些儀表板也含有資料，能夠協助使用者回答關於影響深廣程度的問題。其中一些問題例如「受影響的客戶有多少？」或是「受影響最大的是哪些客戶？」

我們 Web 服務的進入點通常是 UI 和 API 端點，因此專用的系統層級儀表板所含的資料必須足供操作人員看出系統及其面向客戶的端點行為表現。這類儀表板主要是顯示界面層級的監控資料。這類儀表板能為各 API 顯示三類監控資料：

• 輸入方面的監控資料。可包括收到的請求或從佇列/串流輪詢的工作計數、請求位元組大小百分位數，及身分驗證/授權失敗計數。
• 處理方面的監控資料。可包括多重模式的商業邏輯路徑/分支執行計數、後端微型服務請求計數/失敗/延遲百分位數、故障與錯誤日誌輸出，及請求追蹤資料。
• 輸出方面的監控資料。可包括回應類型計數 (附有依照客戶的錯誤/故障回應細分的資料)、回應大小，和寫入時間首次回應位元組和寫入時間完成回應的百分位數。

一般而言，我們旨在將這些客戶體驗和系統層級儀表板儘可能保持高階狀態。我們刻意避開誘惑，不在這些儀表板中加入過多指標，因為資訊過載能引開注意力，導致忽略這些儀表板所需傳達的核心訊息。

我們建置部分儀表板，是為了達成快速又周全地評估在單一服務執行個體 (分區或儲存格) 中的客戶體驗。採取如此狹窄的檢視，能確保處理單一服務執行個體的操作人員不致於由於出自其他服務執行個體的無關資料而負荷過重。

我們也建置客戶體驗儀表板，以刻意顯示遍及所有可用區域和區域，服務之所有執行個體的資料。這類服務稽核儀表板是供操作人員用以遍及所有服務執行個體，稽核自動警示。這類警示也能在前文提及的每週操作會議上接受審閱。

對於較為長期的使用案例，我們也就容量規劃與預測建置儀表板，協助我們將服務的成長視覺化。

Amazon API 通常是以橫跨後端微型服務，協調請求所實作而成。這些微型服務能為不同團隊所擁有，分別負責處理請求的某個特定面向。例如，部分微型服務專門處理請求的身份驗證和授權、強制調節/限制、使用計量、建立/更新/刪除資源、自資料存放區擷取資源，及啟動非同步工作流程。團隊通常建置至少一個專用微型服務的特定儀表板，其顯示各 API 的指標，或者如果服務以非同步方式處理資料，則顯示工作單元。

微型服務的儀表板通常顯示的是實作項目特定的監控資料，要求對服務具備深入的知識。這類儀表板主要由擁有服務的團隊使用。然而，由於我們的服務有大量的儀表，因此必須以不致於造成操作人員負擔過重的方式呈現儀表的資料。所以這類儀表板通常是以彙總形式顯示一些資料。當操作人員識別彙總資料有所異常時，通常會使用各種其他工具以更加深入了解、就基礎監控資料執行臨機查詢以取消資料彙總、追蹤請求，及顯露相關或交互關聯的資料。

我們的服務是在通常會發出指標的 AWS 基礎設施之上執行，因此我們也有專用的基礎設施儀表板。這類儀表板主要專注在執行系統所在運算資源所發出的指標，例如 Amazon Elastic Compute Cloud (EC2) 執行個體、Amazon Elastic Container Service (ECS)/Amazon Elastic Kubernetes Service (EKS) 容器，及 AWS Lambda 函式。諸如 CPU 利用率、網路流量、磁碟 IO 及空間利用率等指標在這些儀表板中共通使用，並連同與這些運算資源有關的任何相關叢集、Auto Scaling 及配額指標。

除了運算資源之外，許多情況下微型服務依存於其他微型服務。即使擁有這些相依性的團隊本身已有儀表板，各微型服務擁有者通常會建立專用的相依性儀表板，以依其服務所測量，提供上游相依性 (例如，代理和負載平衡器) 與下游相依性 (例如，資料存放區、佇列及串流) 兩者行為的檢視。這些儀表板也能用來追蹤其他關鍵指標，例如安全憑證的有效期限和其他相依性配額用量。

在 Amazon，我們將資料呈現的一致性視為儀表板的建立成功與否之關鍵。為能發揮效率，必須在各儀表板、同時遍及所有儀表板達到一致性。多年以來，我們已識別、改編並提升一套共同的設計慣用語和慣例，相信能讓儀表板可供最廣泛的對象使用，最終提高對本組織的價值。我們甚至逐漸發現測量及提升這些設計慣例的細微方式。例如，如果新進操作人員能迅速了解儀表板中呈現的資料，並用以得知服務運作情形，即表示儀表板以正確的方式呈現適當的資訊。

設計儀表板時十分常見有一種趨勢：對於目標使用者的領域知識有所高估或者低估。要建置出對建立者而言全然合理的儀表板，這相當容易。然而，該儀表板卻可能對使用者無甚價值。我們運用自客戶 (此情形下為儀表板使用者) 逆向操作的技巧，以去除此一風險。

我們已採行設計慣例，將儀表板中資料的配置標準化。儀表板由上往下呈現，使用者易於將最先呈現的圖形 (儀表板載入時可見) 解讀為最重要。因此，我們的設計慣例建議將最重要的資料置於儀表板頂端。我們發現，對 Web 服務而言最重要的儀表板，通常是彙總/摘要可用性的圖形與端對端延遲百分位數的圖形。

以下是假設之 Foo Service 儀表板頂端的螢幕擷取畫面：

如果圖形中有許多指標，我們會確保圖形的圖例不致於水平或垂直地擠壓可見的圖形資料。若我們在圖形中使用搜尋查詢，會務必允許得到比標準更大的指標結果集。

如此可避免迫使使用者水平捲動。對凌晨 3 點使用筆記型電腦待命的操作人員來說，若無明顯視覺提示指出右方還有圖形，恐怕不會注意到水平捲軸。

對於顯示日期與時間資料的儀表板，我們會務使在儀表板中可看見相關時區。對於身在不同時區的操作人員並行使用的儀表板，我們會預設為所有使用者都能關聯到的時區 (UTC)。如此一來，使用者能以同一個時區相互通訊，省去腦中進行過多時區換算的時間與精力。

我們預設為與最常見使用案例相關的時間間隔與資料點期。我們會確保儀表板上所有的圖形之中最初顯示的資料為統一的時間範圍和解析度。我們發現在儀表板同區內的所有圖形，若採取相同的水平大小，可帶來益處。如此可便於在圖形之間建立時間的相互關聯。

我們也避免在圖形中繪製過多資料點，否則會拖慢儀表板的載入時間。此外，我們也觀察出，對使用者顯示過多資料點，實際上會使可見性降為異常程度。例如，一個間隔三小時，資料點為一分鐘解析度，每個指標只有 180 個值的圖形，即使在小型儀表板小工具上也能清晰呈現。這種數量的資料點也能為負責為後續操作事件進行分類的操作人員提供足夠的背景資料。

我們的儀表板提供為所有圖形的時間間隔與指標期兩者迅速進行調整的控制項。我們在儀表板中常用的其他間隔 x 解析度比率為：

• 1 小時 x 1 分鐘 (60 個資料點) – 縮小以觀察後續事件時格外好用
• 12 小時 x 1 分鐘 (720 個資料點)
• 1 天 x 5 分鐘 (288 個資料點) – 檢視每日趨勢格外好用
• 3 天 x 5 分鐘 (864 個資料點)
• 1 週 x 1 小時 (168 個資料點) – 檢視每週趨勢格外好用
• 1 個月 x 1 小時 (744 個資料點)
• 3 個月 x 1 天 (90 個資料點) – 檢視按季趨勢格外好用
• 9 個月 x 1 天 (270 個資料點)
• 15 個月 x 1 天 (450 個資料點) – 進行長期容量審閱時格外好用
  

我們為有相關自動警示的指標製作圖形時，如果警示閾值為靜態形式，就會以水平線標記圖形。如果警示閾值為動態型，亦即以使用人工智慧 (AI) 或機器學習 (ML) 所產生的預測或預估作為依據，我們會在同一個圖形中顯示實際與閾值指標兩者。如果圖形中顯示的指標是測量已知有所限制 (例如「最大測試」限制或硬式資源限制) 的服務層面，我們會用水平線標記圖形，指出已知或測試的限制所在。對於有目標的指標，我們會加入水平線，讓使用者對這些目標一目了然。

要是在這類圖形中加入水平線，使用者可能會覺得難以看出水平線是關於哪一個 Y 軸。為避免這樣的模糊，我們會將這類圖形分為僅使用一個水平軸的兩個圖形，並且僅將水平線加在適當的圖形中。

我們之所以避免此情形，是因為這會導致可見性降為一或多個指標的變異狀態。舉例而言，在同一個圖形上繪製 p0 (最小) 及 p100 (最大) 延遲，其中 p100 資料點的值可能為數量級大於 p0 資料點的規模。

對於 Y 軸範圍侷限在資料點值的圖形，乍看之下能使指標比實際上遠遠更加多變。

我們希望能確保在一個圖形中不致有過多統計或無關的指標。例如，就請求處理加入圖形時，我們通常會在儀表板中為下列項目建立分開的相鄰圖形：

• 可用性 % (故障/請求 * 100)
• p10，平均，延遲 p90
• p99.9 及最大 (p100) 延遲
  

這尤其適用於實作項目特定的指標。我們希望能在儀表板文字中提供充分的背景資料，例如在各個圖形旁邊或下方加上說明文字。操作人員閱讀此文字即可了解該指標的意義。於是操作人員就能解讀何謂「標準」，以及圖形不「標準」時可能代表的意義。 在此篇文字中，我們提供相關資源的連結，供操作人員用於判定根本原因。我們會提供的連結類型舉例如下：

• 通往 Runbook。對領域專家而言，儀表板可以是 Runbook。
• 通往相關的「深入了解」儀表板。
• 通往其他叢集或分區的等同儀表板。
• 通往部署管道。
• 通往相依性的聯絡資料。
  

取決於儀表板的使用案例，我們發現，顯示含有單一數字 (例如，指標的最新數值) 或警示狀態的小工具，有時候比起顯示出所有近期資料點的繁複時間序列圖形來得更為恰當。

稀疏指標僅在某些錯誤條件存在時才會發出。即使在必要時才讓服務發出這類指標會相當的有效率，儀表板使用者見到空白或幾乎空白的圖形可能會心生困惑。我們在設計儀表板的時候若遇到這類指標，通常會修改服務，在沒有錯誤條件存在時，持續發出指標的安全 (亦即，零) 值。於是操作人員就能輕易了解資料從缺時，代表服務未正確發出遙測資料。

我們這麼做的情形，是在為了彙整系統中多重模式行為的指標顯示圖形的時候。我們可能會這麼做的部分情況包括：

• 服務支援大小可變的請求時，我們可能會為請求的整體延遲建立圖形。此外，我們可能也會建立為小型、中型及大型請求顯示指標的圖形。
• 如果服務取決於輸入參數的數值 (或組合) 能以不同的方式執行請求，我們可能會就擷取各執行模式的指標增添圖形。