使用 Customer Care 的最佳做法

本指南將介紹一些最佳做法，說明如何撰寫有效的客服案件。遵循這些最佳做法有助於更快解決技術支援客服案件。

建立客服案件

建立客服案件前，請先查看已知問題，確認是否已經有人提交過相同案件。

為了避免混淆，並方便我們集中追蹤您的要求，請一個問題建立一個客服案件。系統會關閉所有重複建立的案件。

說明問題

記錄詳細的客服案件可協助 Customer Care 團隊迅速又有效率地回覆。如果客服案件缺少重要細節，我們會需要花費額外的時間詢問相關資訊。

建議提交詳細且具體的客服案件。內容應清楚說明發生了什麼事，以及預期的結果。在客服案件中說明問題時，請納入下列詳細資訊：

  • 時間：問題發生時的確切時間戳記。
  • 產品：與問題有關的產品和功能。
  • 位置：發現問題的可用區。
  • ID：專案 ID 或應用程式 ID，以及其他對調查問題有幫助的具體 ID。
  • 有用的資料：任何對問題診斷有幫助的詳細資料。
  • 問題類型：屬於間歇性、暫時性，還是持續性問題。

下列各節會進一步說明這些概念。

時間

使用 ISO 8601 格式的日期和時間戳記，說明首次發現問題的時間，以及問題持續了多久。

例如：

  • 問題於 2017-09-08T15:13:06+00:00 發生，並於 5 分鐘後結束，我們發現…
  • 問題間歇發生，開始時間不會早於 2017-09-10，且已經發生過 2 到 5 次…
  • 問題從 2017-09-08T15:13:06+00:00 開始一直持續發生…
  • 問題於 2017-09-08T15:13:06+00:00 發生，並於 2017-09-08T15:18:16+00:00 結束…

負責解決問題的 Customer Care 專員很可能不在您的時區，因此類似下列的敘述會使問題難以診斷：

  • 「問題從昨天某個時候開始發生…」(這使得我們必須自行推敲日期)。
  • 「我們於 9/8 發現問題…」(時間模棱兩可，有些人會認為 9/8 是 9 月 8 日，而另一些人會認為是 8 月 9 日)。

產品

雖然基本的客服案件表單只要求指明產品名稱，但我們需要確切知道是產品的哪個「功能」出現了問題。理想情況下，您的報告應該會提供確切的 API 或 Google Cloud 控制台網址 (或螢幕截圖)。如果是 API 產品問題，可以連結到 API 說明文件頁面，從包含產品名稱的頁面網址中找到產品名稱。

另外，也請說明提出要求時所使用的機制，例如 REST API、Google Cloud CLI、 Google Cloud Console 或像是 Cloud Deployment Manager 的工具。如果涉及多個產品，請具體列出每個產品的名稱。

例如：

  • 「Google Compute Engine REST API 傳回下列錯誤…」
  • 「console.cloud.google.com 中的 BigQuery 查詢介面停滯不動…」

下列敘述不夠具體，我們無法確定該從何處開始診斷問題：

  • 「無法建立執行個體…」(我們需要知道您建立執行個體時所使用的方法)。
  • 「gcloud compute create instances 指令出錯…」(指令語法不正確，我們無法執行該指令來重現錯誤，也不知道您實際上遇到的是哪種錯誤)。

位置

通常一次只能對一個區域或可用區部署變更，因此需要知道資料中心區域和可用區。區域和可用區是基礎軟體版本號碼的 Proxy。這項資訊可讓我們瞭解特定軟體版本的破壞性變更是否會影響您的系統。

例如：

  • 「在 us-east1-b…」
  • 「我試過區域 us-east1 和 us-central1…」

ID

具體的 ID 有助於確認是哪一個 Cloud 專案遇到問題。請提供專案或應用程式 ID (由英數字元組成)。只提供專案名稱沒有幫助。如果問題對多項專案造成影響，請提供每個受影響專案的 ID。

除了專案或應用程式 ID，還有其他 ID 也能幫助我們診斷您的客服案件：

  • 執行個體 ID。
  • BigQuery 工作 ID 或資料表名稱。
  • IP 位址。

指定 IP 位址時，也請說明 IP 位址的使用情境。例如，請說明該 IP 是否連線至運算執行個體、負載平衡器、自訂路徑或 API 端點。另外，也請說明 IP 位址是否與 Google 系統無關 (例如，IP 位址是否用於家中網路、VPN 端點或外部監控系統)。

例如：

  • 「在專案 robot-name-165473 或 my-project-id 中…」
  • 「跨多項專案 (包括 my-project-id)…」
  • 「從公司的閘道 56.56.56.56 連接到 Google Cloud 外部 IP 218.239.8.9…」

類似下列的敘述過於籠統，無法幫助我們診斷問題：

  • 「我們的一個執行個體無法連上…」
  • 「我們無法透過網際網路進行連線…」

有用的資料

提供與問題有關的資料可幫助我們確切瞭解您遇到的問題，以加速疑難排解。

例如：

  • 提供螢幕截圖，確切顯示看到的內容。
  • 如果是網頁式介面問題，請提供任何相關的瀏覽器追蹤記錄資訊。
  • 附上 tcpdump 輸出內容、記錄片段、堆疊追蹤範例。

問題類型

  • 間歇性：間歇性問題會隨機發生，沒有固定的失敗模式。間歇性問題的不規律性導致難以在失敗期間收集資料，因此較難進行疑難排解。在這種情況下，建議嘗試找出架構中的瓶頸，並檢查資源是否已達到最高用量門檻。此外，也可以使用自動化功能，在已排定的工作中經常執行檢查，若無法進行檢查，則在失敗期間收集偵錯資訊。這類失敗的例子包括 DNS 解析失敗和封包遺失。

  • 暫時性：暫時性問題是短暫的，或只會發生一小段時間。如果問題只持續一秒或幾微秒，請檢查流量的微爆發情形或資源尖峰使用率。在大多數情況下，如果暫時性問題不常發生，且服務設計可容許短暫失敗，則可忽略這類問題。這類失敗的例子包括僅持續幾微秒的網路延遲時間遽增，以及造成逾時的小型封包遺失。傳輸控制通訊協定 (TCP) 旨在因應小型封包遺失和延遲時間遽增等失敗情形，並有效處理這些問題，除非應用程式較容易受到延遲影響，否則不建議採用。

  • 持續性：持續性問題是指完全失敗的情形，例如網站停止運作。持續性問題可以重現，相對比較容易進行疑難排解。在這種情況下，請提供重現問題的步驟，以便 Customer Care 專員複製環境排解問題。

範例說明

以下範例提供客服案件的詳細說明。

範例一

JobName:

A_ATL_BIG1toBQ_big_04)201704202

00045_491

Source:

S3_avl-transfer

Destination:

CloudStorage: avl-transfer

Start time (ISO 8601 format): 2017-04-20 20:14:43 PDT

End time (ISO 8601 format): 2017-04-21 at 10:03:44 PDT

I started a file transfer at 2017-04-20 at 20:14:43 PDT using the transfer API.
This job normally takes 10 minutes to complete, but in this case the job was
still running when I canceled it the next day (2017-04-21 at 10:03:44 PDT). This
is not an isolated event; several other jobs involving the transfer API had
intermittent, significant delays.

Please investigate the cause of the delays and advise of any best practices that
we can implement to prevent these issues in the future.

範例二

Start time (ISO 8601 format): 2017-05-12 at 11:03:43

End time (ISO 8601 format): The issue is still happening as of the time of this
report.

Issue summary:

`/cron/payments-service/sync-v2-batch` cron using the App Engine Task Queue API
has stopped running since 2017-05-12 at 11:03:43. We rely on this job to handle
payments correctly.

We saw datastore and queue errors and then the cron stopped running. We
attempted unsuccessfully to fix the issue by re-uploading cron.xml. Here is the
error trace:

`[error trace]`

Please advise if the issue is with the API or our implementation and let us
know next steps.

設定和提高優先順序

優先順序有助於瞭解問題對於業務的影響程度，並決定我們回覆及解決問題的速度。下表列出優先順序的定義。詳情請參閱「客服案件優先順序」。

優先順序定義 情況示例
P1：重大影響 - 無法在正式環境中使用服務 應用程式或基礎架構無法在正式環境中使用，且在使用者端的錯誤率極高。對業務造成重大影響 (導致收益損失、潛在資料完整性等問題)。
P2：高度影響 - 服務功能嚴重受損 基礎架構在正式環境中效能降低，使用者端的錯誤率明顯上升，或難以啟動新的正式環境系統。對業務造成中度影響 (導致收益損失、生產力下降等問題)。
P3：中度影響 - 服務功能部分受損 問題的影響範圍和/或嚴重性有限。問題造成的影響使用者不易察覺。對業務的影響甚低 (例如，造成不便或次要業務流程受影響)。
P4：低度影響 - 服務完全可正常使用 對業務或技術方面幾乎或沒有任何影響。若諮詢支援單較適合以深入分析、疑難排解或諮詢服務處理，而非透過頻繁溝通的方式，則建議使用此優先順序。

最高優先順序的設定時機

如果遇到了會影響關鍵業務服務的問題，並需要 Google 立即處理，請選擇「P1」做為優先順序。請詳細說明選擇 P1 的原因，並簡短敘述該問題對業務的影響。舉例來說，如果開發版本問題對重大安全性修正造成阻礙，即使沒有使用者受到直接影響，仍可將該問題的優先順序列為 P1。

將案件優先順序設為 P1 後，專家會立即收到通知，專門處理該問題。您很快就會收到初步回覆，受邀透過 Google Meet 加入即時疑難排解通話。如果組織無法使用 Google Meet，請附上所選視訊會議軟體的連結，以便專家加入。之後，您會定期收到案件的最新消息。

感謝您對所選優先順序層級加上詳細的註解，因為這些說明能協助我們做出適當的回應。

P1 案件支援服務的內容

  • 新 P1 案件

    • 支援專家會透過 Google Meet 或所提供的任何其他橋接方式與您互動。請在 15 到 30 分鐘內加入通話。如果基於任何原因無法加入通話，請告知支援專家。
    • 根據預設，P1 案件為「全球支援服務」。也就是說，支援專家會 24 小時全天候投入案件處理，直到問題獲得緩解或優先順序降低為止。如果案件問題在特定區域能有效獲得緩解，則可將案件鎖定在特定時區。請提供偏好的區域以利妥善安排。

  • 提高優先順序為 P1

    • 如果問題已開始或即將影響正式環境，可以將現有 P2 至 P4 案件的優先順序提高為 P1。
    • 現有案件的優先順序提高為 P1 後，系統可能會將客服案件重新指派給有空的支援專家，以立即處理。

  • 非正式環境影響

    為確保適當分配資源，支援團隊可能會與您聯絡，重新評估標示為 P1 但不會影響正式環境或對業務造成高度影響的案件。

回應時間

在 Google Cloud Platform 技術支援服務指南中，對於問題影響程度的優先順序有預先定義回應時間。如需指定回應的時間，請在報告中說明。若需要全天候處理 P1 問題，可以「要求全球支援服務」，我們會每天將這些案件多次重新指派給值班的 Customer Care 專員。建議在排解 P1 案件問題期間隨時回答問題，以促進有效溝通，直到問題解決為止。如果超過 3 小時未回覆，我們可能會將案件優先順序降為 P2，直到您重新參與討論為止。

提高問題層級

情況改變時，可能會需要提高問題層級。提高問題層級的恰當理由包括：

  • 對業務的影響增加。
  • 問題解決程序中斷。舉例來說，您在約定時間內未收到最新消息，或在多次訊息交流後，問題仍「未獲改善」。

如果遇到影響程度較高的問題，最佳解決方案是將案件設為適當的優先順序，並維持足夠的一段時間，而不是提高問題層級。提高問題層級不一定能加快案件解決速度，且在變更優先順序後立即提高層級，甚至可能導致案件解決速度變慢。如需更詳細的說明，請觀看「提高問題層級的時機」影片。

詳情請參閱「提報客服案件」一文。

將案件轉送至所需時區

Customer Care 專員的服務時間取決於多項因素，因此客服案件可能會指派給工作時間與您不同的 Customer Care 專員。您也可能會想要在特定時區的工作天與 Customer Care 團隊聯絡。在這種情況下，建議要求 Customer Care 團隊將客服案件轉送至您方便的時區。您可以在案件說明或回覆中加入這項要求。例如，Please route this case to the Pacific time zone (GMT-8)。P1 案件為「全球支援服務」，因此請移交給下一個區域的 Customer Care 專員，而其他案件則由目前的案件負責人於次日繼續處理。

透過 CES 問卷調查提供意見回饋

案件問題解決後，我們會透過電子郵件傳送客戶努力度評分 (CES) 問卷調查，請您提供對於案件處理過程的意見。非常感謝您能抽出幾分鐘的時間填寫問卷，協助我們瞭解哪些方面做得好，以及面臨的挑戰是什麼，從而進行改善。

客戶體驗團隊會手動審查每份意見回饋表單，並採取相應措施，以提升日後的服務品質。評估分數的滿分為 5 分。3 分以下表示客戶認為互動難度較高。如果是 4 分以上，則表示客戶認為互動過程其實不難，且體驗良好。

詳情請觀看「如何透過 CES 提出 Google Cloud 服務意見回饋」影片。

長期存在或難以解決的問題

長期無法解決的問題最後可能會變成一筆爛帳。為防止這種情況發生，建議使用長期問題範本收集資訊，並將最新情況摘要於範本頂端。

如要使用範本，請開啟上述連結並建立副本。請在文件中附上所有相關客服案件和內部追蹤錯誤的連結。將這份文件分享給帳戶團隊，並請對方提供給特定的 Customer Care 專員。

本文件內容包含：

  • 列於文件頂端的現況摘要。
  • 可能屬實的假設列表。
  • 您打算用來驗證每個假設的測試或工具。

每個客服案件最好陳述一個問題，避免用同個案件提出新的問題。

回報正式環境服務中斷問題

如果問題導致應用程式停止為使用者提供流量，或對業務造成類似的重大影響，這可能就是正式環境服務中斷問題。發生這種情況時，請立即通知我們。只會對少數開發人員造成阻礙的問題並不屬於我們認定的作業中斷問題。

我們在收到正式環境服務中斷報告後，會採取下列措施快速分析情況：

  • 立即檢查影響 Google Cloud 基礎架構的已知問題。
  • 確定問題的性質。
  • 建立溝通管道。

您會收到簡短的訊息回覆，內容包括：

  • 影響多個客戶的任何相關已知問題。
  • 確認我們能夠找到您回報的問題，或要求提供更多詳細資料。
  • 我們打算使用的通訊方式。

因此，迅速建立包含時間、產品、ID 和位置等資訊的客服案件是重要的第一步，有了這個客服案件，我們才能著手進行深入的疑難排解。貴組織可能已訂有明確的事件管理流程，此步驟應該在流程的一開始時進行。

Google 的事件管理流程設有一個關鍵的角色：事件指揮官。事件指揮官須負責尋找合適的問題處理人員、持續收集問題最新狀態，並定期匯報問題狀態。也必須指派其他人員負責疑難排解及套用變更作業。這種任務指派方式讓我們能夠同時驗證多個假設。我們建議您在貴機構內部也建立類似的流程。開啟客服案件的人通常就是最佳的事件指揮官人選，因為他們最瞭解事情的前因後果。

回報網路問題

Google 網路的規模和複雜性常使我們很難斷定問題的歸屬。為能正確診斷網路問題，我們需要知道造成問題的最根本原因。由於網路錯誤訊息通常過於籠統 (例如，「無法連線至伺服器」)，因此我們需要收集詳細的診斷資訊，以縮小可能的問題假設範圍。

封包傳輸流程圖為問題報告提供了理想的結構資訊。這些流程圖會顯示封包從來源到目的地所經過的重要躍點，以及過程中的任何重要轉換。

先從網路 IP 位址或 RFC 1918 私人位址及網路 ID 判別受影響的網路端點。例如，Compute Engine 專案預設網路上的 2.3.4.5 或 10.2.3.4。

留意任何與端點有關的實用資訊，例如：

  • 端點由誰控管。
  • 端點是否與 DNS 主機名稱相關聯。
  • 是否有任何中繼封裝及/或間接層，如 VPN 通道、Proxy 和 NAT 閘道。
  • 是否有任何中繼篩選機制，如防火牆、CDN 或網路應用程式防火牆。

許多導致高延遲或間歇封包遺失狀況的問題，都需要進行路徑分析及/或封包擷取診斷。

  • 路徑分析會列出封包周遊的所有躍點，功能類似「traceroute」。我們通常會使用 MTR 及/或 tcptraceroute。這些工具的診斷效能較為強大，因此建議熟悉這些工具的使用方式。
  • 封包擷取 (又稱「封包擷取 (PCAP)」，名稱取自「libpcap」程式庫) 可用於觀察即時的網路流量。請務必同時對兩個端點都進行封包擷取，雖然這有些難度。建議練習使用一些必要的工具 (例如 tcpdump 或 Wireshark)，並事先安裝好這些工具。

回報 Google Cloud 控制台問題

回報網頁式 Google Cloud 控制台的問題時，除了上述指引，請提供下列資訊以協助縮小潛在問題原因的範圍：

  • 受影響的控制台頁面網址
  • 受影響專案的 ID
  • 受影響的使用者人數
  • 問題是否會發生在不同裝置上
  • 受影響的瀏覽器
  • 使用的任何瀏覽器擴充功能或防火牆系統

此外，請附上任何相關的瀏覽器追蹤資訊，協助瞭解及調查問題。