使用 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 連接到外部 IP 218.239.8.9...」 Google Cloud

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

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

有用的資料

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

例如：

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

問題類型

  • 間歇性：間歇性問題會隨機發生，且沒有固定的失敗模式。間歇性問題很難排解，因為它們不規則的特性，使得在故障期間收集資料變得困難。在這種情況下，您應嘗試找出架構中的瓶頸，並檢查資源是否達到使用量上限。您也可以使用自動化功能，在排程工作中執行頻繁檢查，並在檢查失敗時收集偵錯資訊。這類失敗的例子包括 DNS 解析失敗和封包遺失。

  • 暫時性：暫時性問題是指短暫出現或僅存在於短時間內的問題。如果問題只發生一秒或幾微秒，您可以檢查流量或資源峰值用量的微型突發情形。在大多數情況下，如果暫時性問題不會經常發生，且服務設計可容許暫時性失敗，則可忽略這些問題。這類失敗的例子包括網路延遲時間尖峰 (只發生幾微秒)，以及導致逾時的封包損失。傳輸控制通訊協定 (TCP) 是為了處理小型封包遺失和延遲時間尖峰等失敗情況而設計，除非您的應用程式對延遲時間十分敏感，否則這項通訊協定可以有效處理這些問題。

  • 持續性：持續性問題是指完全失敗的問題，例如網站無法運作。一致的問題比較容易排解，因為可以重現問題。在這種情況下，請告訴我們重現問題的步驟，以便我們的客戶服務專家複製環境，為您排除問題。

說明範例

以下範例提供支援案件的詳細說明。

示例一

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：重大影響 - 無法在實際工作環境中使用服務 應用程式或基礎架構在實際工作環境中無法使用，且在使用者端的錯誤率極高。對業務造成重大影響 (獲利損失、潛在資料完整性問題等)。
嚴重性 2：高度影響 - 服務功能嚴重受損 基礎架構的效能在實際工作環境中降低，且在使用者端的錯誤率十分明顯，或難以啟用新的工作系統。對業務造成中度影響 (可能面臨獲利損失、生產力下降等問題)。
P3：中度影響 - 服務功能部分受損 問題影響的範圍和/或嚴重性有限。這項問題不會對使用者造成可見的影響。對業務的影響甚低 (例如，造成不便、次要業務流程受影響等)。
P4：低度影響 - 服務完全可用 對業務或技術方面幾乎或沒有任何影響。建議使用此優先順序處理諮詢性票證，因為這類票證較適合以深入分析、疑難排解或諮詢服務處理，而非透過頻繁溝通處理。

最高優先順序的設定時機

如果您遇到了會影響關鍵業務服務的問題，並需要 Google 立即處理，請選擇「P1」做為優先順序。請向我們詳細說明您選擇 P1 的原因，並簡短敘述該問題對您業務的影響。舉例來說，如果 Dev 開發版本問題對重大安全性修正造成阻礙，那麼即使沒有使用者受到直接影響，您仍可以將該問題的優先順序列為 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
  • 受影響使用者人數
  • 問題是否會發生在不同機器上
  • 受影響的瀏覽器
  • 任何正在使用的瀏覽器擴充功能或防火牆系統

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