使用 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 結束…

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

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

產品

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

另外也請告訴我們您發出要求時所使用的機制，例如，REST API、Google Cloud CLI、 Google Cloud 控制台或像是 Cloud Deployment Manager 的工具。如果涉及多個產品，請完整列出每個產品的名稱。

範例：

  • 「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 連接的是 Compute 執行個體、負載平衡器、自訂路徑還是 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.

範例 2

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 優先級提高

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

  • 非正式環境影響

    為確保適當分配資源，支援團隊可能會與您聯絡，重新評估標示為 P1 的案件，這些案件不會影響生產環境或造成重大業務影響。

回應時間

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

提報

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

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

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

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

將案件轉送至所需時區

由於客戶服務專員的服務時間取決於多項因素，因此您的支援案件可能會指派給工作時間與您不同的客戶服務專員。您也可能希望在特定時區的營業時間與 Customer Care 聯絡。在這種情況下，建議您要求客戶服務團隊將支援案件轉送至適合您案件的時區。您可以在案件說明或回覆中加入這項要求。例如，Please route this case to the Pacific time zone (GMT-8)。P1 案件會移交給下一個地區的 Customer Care 團隊，因為這類案件會隨著太陽移動，而其他案件則會由目前的案件負責人繼續處理。

透過 CES 問卷調查提供意見

案件解決後，我們會透過電子郵件傳送客戶努力度評分 (CES) 問卷調查，請您填寫問卷，提供對案件處理過程的意見。請撥出幾分鐘填寫問卷，讓我們瞭解哪些地方做得好，以及有哪些挑戰，以便改進這些方面。

客戶體驗團隊會手動審查每份意見回饋表單，並採取相應行動，改善您日後的使用體驗。分數為 1 到 5 分。3 分以下表示客戶認為難度較高。另一方面，如果分數為 4 分以上，表示顧客認為互動過程不困難，且體驗良好。

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

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

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

如要使用範本，請開啟上述連結並建立副本。請在文件中附上所有相關客服案件和內部追蹤錯誤的連結。將這份文件提供給您的帳戶小組，並請他們提供給相關的客戶服務專家。

本文件包含：

  • 列於文件最上方的最新情況摘要。
  • 可能屬實的假設列表。
  • 您打算用來驗證每個假設的測試或工具。

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

回報作業中斷問題

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

當我們收到作業中斷問題報告時，我們會採取下列措施來快速分析情況：

  • 立即檢查影響 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
  • 受影響的使用者人數
  • 問題是否會發生在不同裝置上
  • 受影響的瀏覽器
  • 使用的任何瀏覽器擴充功能或防火牆系統

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