Praktik terbaik untuk bekerja sama dengan Layanan Pelanggan

Panduan ini memberikan praktik terbaik untuk menulis kasus dukungan yang efektif. Mengikuti praktik terbaik ini akan membantu kami menyelesaikan kasus dukungan teknis Anda dengan lebih cepat.

Membuat kasus dukungan

Sebelum membuat kasus dukungan, tinjau masalah umum untuk melihat apakah kasus sudah pernah diajukan atau belum.

Untuk menghindari kebingungan dan agar kami dapat melacak permintaan Anda di satu tempat, buat satu kasus dukungan per masalah. Semua kasus duplikat yang dibuat akan ditutup.

Menjelaskan masalah Anda

Menuliskan kasus dukungan yang mendetail dapat mempermudah tim Layanan Pelanggan untuk merespons Anda dengan cepat dan efisien. Jika kasus dukungan Anda tidak memiliki detail penting, kami perlu meminta informasi lebih lanjut, yang memerlukan waktu tambahan.

Kasus dukungan yang baik adalah mendetail dan spesifik. Informasi ini memberi tahu kami apa yang terjadi dan apa yang Anda harapkan. Saat menjelaskan masalah Anda dalam kasus dukungan, sertakan detail berikut:

  • Waktu: Stempel waktu spesifik kapan masalah mulai terjadi.
  • Produk: Produk dan fitur yang terkait dengan masalah.
  • Lokasi: Zona tempat Anda melihat masalah.
  • ID: Project ID atau ID aplikasi dan ID konkret lainnya yang membantu kami menyelidiki masalah.
  • Artefak yang berguna: Detail apa pun yang dapat Anda berikan untuk membantu kami mendiagnosis masalah.
  • Jenis masalah: Apakah masalah muncul sesekali, selama sementara waktu, atau terus-menerus.

Bagian berikut menjelaskan konsep ini secara lebih mendetail.

Waktu

Dengan menggunakan format ISO 8601 untuk tanggal dan stempel waktu, beri tahu kami kapan Anda pertama kali melihat masalah ini dan berapa lama masalah ini berlangsung.

Contoh:

  • Mulai 08-09-2017T15:13:06+00:00 dan berakhir 5 menit kemudian, kami mengamati...
  • Diamati secara intermiten, dimulai paling cepat 10-09-2017 dan diamati 2-5 kali...
  • Sedang berlangsung sejak 2017-09-08T15:13:06+00:00...
  • Dari 2017-09-08T15:13:06+00:00 hingga 2017-09-08T15:18:16+00:00...

Spesialis Layanan Pelanggan yang menyelesaikan masalah kemungkinan besar tidak berada di zona waktu Anda, sehingga pernyataan relatif seperti berikut akan mempersulit diagnosis masalah:

  • "Ini dimulai kemarin..." (Memaksa kita untuk menyimpulkan tanggal yang tersirat.)
  • "Kami melihat masalah ini pada 8/9..." (Ambigu, karena beberapa orang mungkin menafsirkan tanggal ini sebagai 8 September, dan orang lain mungkin menafsirkannya sebagai 9 Agustus.)

Produk

Meskipun formulir kasus dasar meminta Anda untuk menentukan nama produk, kami memerlukan informasi spesifik tentang fitur mana dalam produk tersebut yang mengalami masalah. Idealnya, laporan Anda akan merujuk ke API tertentu atau URL konsol Google Cloud (atau screenshot). Untuk API, Anda dapat menautkan ke halaman dokumentasi, yang berisi nama produk di URL.

Beri tahu kami juga tentang mekanisme yang Anda gunakan untuk memulai permintaan (misalnya, REST API, Google Cloud CLI, konsol Google Cloud, atau mungkin alat seperti Cloud Deployment Manager. Jika ada beberapa produk yang terlibat, berikan nama masing-masing produk secara khusus.

Contoh:

  • "Compute Engine REST API menampilkan error berikut..."
  • "Antarmuka kueri BigQuery di console.cloud.google.com macet..."

Pernyataan berikut tidak cukup spesifik untuk mengetahui tempat yang harus dicari saat mendiagnosis masalah:

  • "Tidak dapat membuat instance..." (Kami perlu mengetahui metode yang Anda gunakan untuk membuat instance.)
  • "Perintah gcloud compute create instances menampilkan error..."(Sintaksis perintah salah, sehingga kita tidak dapat menjalankannya sendiri untuk mereproduksi error. Selain itu, kami tidak tahu error mana yang sebenarnya Anda lihat.)

Lokasi

Kami perlu mengetahui region dan zona data center Anda karena kami sering meluncurkan perubahan ke satu region atau zona dalam satu waktu. Region dan zona adalah proxy untuk nomor versi software yang mendasarinya. Informasi ini membantu kami mengetahui apakah perubahan yang menyebabkan error dalam versi software tertentu memengaruhi sistem Anda.

Contoh:

  • "Di us-east1-b ..."
  • "Saya mencoba region us-east1 dan us-central1..."

Pengenal

ID tertentu membantu kami mengidentifikasi project Cloud mana yang mengalami masalah. Kita selalu perlu mengetahui project alfanumerik atau ID aplikasi. Nama project tidak membantu. Jika masalah memengaruhi beberapa project, sertakan setiap ID yang terpengaruh.

Selain project ID atau application ID, beberapa ID lainnya membantu kami mendiagnosis kasus Anda:

  • ID instance.
  • ID tugas atau nama tabel BigQuery.
  • menggunakan alamat IP internalnya.

Saat menentukan alamat IP, beri tahu kami juga konteks penggunaannya. Misalnya, tentukan apakah IP terhubung ke instance Compute, load balancer, rute kustom, atau endpoint API. Beri tahu kami juga jika alamat IP tidak terkait dengan sistem Google (misalnya, jika alamat IP ditujukan untuk internet rumah Anda, endpoint VPN, atau sistem pemantauan eksternal).

Contoh:

  • "Di project robot-name-165473 atau my-project-id..."
  • "Di beberapa project (termasuk my-project-id)..."
  • "Menghubungkan ke IP eksternal Google Cloud 218.239.8.9 dari gateway perusahaan kami 56.56.56.56..."

Pernyataan umum seperti berikut terlalu umum untuk membantu mendiagnosis masalah:

  • "Salah satu instance kami tidak dapat dijangkau..."
  • "Kami tidak dapat terhubung dari internet..."

Artefak yang berguna

Memberikan artefak yang terkait dengan masalah tersebut akan mempercepat pemecahan masalah dengan membantu kami melihat persis apa yang Anda lihat.

Contoh:

  • Gunakan screenshot untuk menunjukkan dengan tepat apa yang Anda lihat.
  • Untuk Antarmuka berbasis Web, berikan file .HAR (Http ARchive). Penganalisis HAR memiliki petunjuk untuk tiga browser utama.
  • Lampirkan output tcpdump, cuplikan log, contoh pelacakan tumpukan.

Jenis masalah

  • Berjeda: Masalah berjeda terjadi secara acak tanpa pola kegagalan reguler. Masalah yang terjadi secara intermiten sulit dipecahkan karena ketidakteraturannya menyulitkan pengumpulan data selama kegagalan. Dalam hal ini, Anda harus mencoba mengidentifikasi bottleneck dalam arsitektur dan memeriksa apakah resource Anda mencapai penggunaan nilai minimum maksimumnya. Anda juga dapat menjalankan pemeriksaan yang sering dilakukan dalam tugas terjadwal menggunakan otomatisasi, dan jika pemeriksaan gagal, kumpulkan informasi debug selama kegagalan. Contoh jenis kegagalan ini adalah kegagalan resolusi DNS dan hilangnya paket.

  • Sementara: Masalah sementara bersifat sesaat atau hanya ada selama jangka waktu yang singkat. Jika Anda mengalami masalah yang hanya terjadi selama satu detik atau beberapa mikrodetik, Anda dapat memeriksa lonjakan mikro traffic atau penggunaan puncak resource. Dalam sebagian besar kasus, masalah sementara dapat diabaikan jika tidak sering terjadi dan jika layanan Anda dirancang untuk toleran terhadap kegagalan sementara. Contoh jenis kegagalan ini adalah lonjakan latensi jaringan yang hanya terjadi selama beberapa mikrodetik, dan kehilangan paket kecil yang menyebabkan waktu tunggu habis. Transmission Control Protocol (TCP) dirancang untuk kegagalan seperti kehilangan paket kecil dan lonjakan latensi, dan dapat menangani masalah ini secara efektif, kecuali jika aplikasi Anda sensitif terhadap latensi.

  • Konsisten: Masalah konsisten adalah masalah yang gagal sepenuhnya, seperti saat situs Anda tidak dapat diakses. Masalah yang konsisten relatif mudah dipecahkan karena dapat direkonstruksi. Dalam hal ini, beri tahu kami langkah-langkah untuk merekonstruksi masalah sehingga pakar Layanan Pelanggan kami dapat mereplikasi lingkungan dan memecahkan masalah untuk Anda.

Contoh deskripsi

Contoh satu

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.

Contoh kedua

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.

Menetapkan prioritas dan mengeskalasikan

Prioritas membantu kami memahami dampak masalah ini terhadap bisnis Anda, dan memengaruhi seberapa cepat kami merespons untuk menyelesaikan masalah tersebut. Prioritas ditentukan dalam tabel berikut. Anda dapat menemukan informasi selengkapnya di Prioritas kasus dukungan.

Definisi Prioritas Contoh Situasi
P1: Dampak Serius—Layanan Tidak Dapat Digunakan dalam Produksi Aplikasi atau infrastruktur tidak dapat digunakan dalam produksi, dengan tingkat error yang signifikan bagi pengguna. Dampak terhadap bisnis sangat penting (kehilangan pendapatan, potensi masalah integritas data, dll.).
P2: Berdampak Tinggi—Penggunaan Layanan Sangat Terganggu Infrastruktur mengalami degradasi dalam produksi, dengan rasio error yang signifikan atau kesulitan yang dihadapi pengguna dalam meluncurkan sistem produksi baru. Dampak terhadap bisnis sedang (bahaya kehilangan pendapatan, menurunnya produktivitas, dll.).
P3: Dampak Sedang—Sebagian Layanan Terganggu Cakupan dan/atau tingkat keparahan masalah ini terbatas. Masalah ini tidak memiliki dampak yang terlihat oleh pengguna. Dampak bisnis rendah (misalnya, ketidaknyamanan, atau proses bisnis kecil yang terpengaruh).
P4: Dampak Rendah—Layanan Dapat Digunakan Sepenuhnya Pengaruh bisnis atau teknis sedikit atau tidak ada. Direkomendasikan untuk tiket konsultasi jika analisis mendalam, pemecahan masalah, atau konsultan lebih disukai daripada komunikasi yang lebih sering.

Kapan harus menetapkan prioritas tertinggi

Jika Anda mengalami masalah yang memengaruhi layanan penting bagi bisnis dan memerlukan perhatian langsung dari Google, pilih "P1" sebagai prioritas. Jelaskan kepada kami secara mendetail alasan Anda memilih P1. Sertakan deskripsi singkat tentang dampak masalah ini terhadap bisnis Anda. Misalnya, Anda dapat menganggap masalah pada versi developer sebagai P1, meskipun tidak ada pengguna akhir yang terpengaruh secara langsung, jika masalah tersebut memblokir perbaikan keamanan yang penting.

Jika kasus ditetapkan sebagai P1, pakar akan segera diberi tahu untuk menangani masalah tersebut secara eksklusif. Anda akan menerima respons awal yang cepat untuk bergabung ke panggilan pemecahan masalah langsung melalui Google Meet. Jika organisasi Anda tidak dapat menggunakan Google Meet, sertakan link ke software konferensi video pilihan Anda agar pakar dapat bergabung. Setelah itu, Anda akan menerima info terbaru secara berkala melalui kasus.

Kami menghargai komentar mendetail yang mendukung tingkat prioritas yang dipilih karena hal ini membantu kami merespons dengan tepat.

Yang akan Anda dapatkan dari dukungan untuk kasus P1

  • Kasus P1 baru

    • Pakar dukungan akan menghubungi Anda melalui Google Meet atau jembatan lain yang Anda berikan. Kami berharap Anda bergabung dalam panggilan dalam waktu 15-30 menit. Beri tahu pakar dukungan jika Anda tidak dapat bergabung ke panggilan karena alasan apa pun.
    • Kasus "mengikuti matahari" secara default. Artinya, pakar dukungan akan berinteraksi 24 jam sehari hingga kasus dimitigasi atau tidak diprioritaskan lagi. Jika mitigasi kasus dilakukan dengan baik di wilayah tertentu, kasus tersebut dapat dikunci ke zona waktu tertentu. Anda dapat memberi tahu kami preferensi Anda terkait efek ini.

  • Kenaikan prioritas P1

    • Jika masalah tersebut telah mulai memengaruhi lingkungan produksi, atau akan memengaruhinya, Anda dapat meningkatkan prioritas kasus P2 - P4 yang ada menjadi P1.
    • Saat Anda meningkatkan prioritas kasus yang ada menjadi P1, kasus dukungan dapat ditetapkan ulang agar pakar dukungan yang tersedia dapat memberikan perhatian segera.

  • Dampak non-produksi

    Untuk memastikan bahwa resource yang sesuai dialokasikan jika diperlukan, tim dukungan dapat menghubungi Anda untuk mengevaluasi ulang kasus yang ditandai sebagai P1 yang tidak memengaruhi produksi atau menyebabkan dampak bisnis yang tinggi.

Waktu respons

Tingkat prioritas masalah memiliki waktu respons standar yang ditentukan dalam Panduan Layanan Dukungan Teknis Google Cloud Platform. Jika Anda memerlukan respons pada waktu tertentu, beri tahu kami dalam deskripsi laporan Anda. Jika masalah P1 perlu ditangani sepanjang waktu, Anda dapat meminta layanan "ikuti matahari". Kasus ini ditetapkan ulang beberapa kali per hari kepada spesialis Layanan Pelanggan yang aktif. Saat kami memecahkan masalah kasus P1 Anda, sebaiknya Anda tetap aktif menjawab pertanyaan hingga masalah tersebut terselesaikan untuk memfasilitasi komunikasi yang efisien. Jika Anda tidak merespons selama lebih dari 3 jam, kami dapat menurunkan prioritas kasus menjadi P2 hingga Anda berinteraksi kembali.

Eskalasi

Jika situasi berubah, Anda mungkin perlu mengeskalasikan masalah. Alasan yang baik untuk eskalasi adalah:

  • Peningkatan dampak bisnis.
  • Perincian proses penyelesaian. Misalnya, Anda belum menerima info terbaru dalam jangka waktu yang disepakati atau masalah Anda "macet" tanpa kemajuan setelah bertukar beberapa pesan.

Jika Anda mengalami masalah yang berdampak tinggi, solusi terbaiknya adalah menetapkan kasus ke prioritas yang sesuai selama jangka waktu yang memadai, bukan melakukan eskalasi. Mengeskalasikan kasus tidak selalu menyelesaikan kasus lebih cepat dan mengeskalasikan kasus segera setelah perubahan prioritas bahkan dapat menyebabkan penyelesaian kasus menjadi lebih lambat. Anda dapat menemukan penjelasan yang lebih mendetail dalam video Kapan Anda harus mengeskalasikan.

Untuk informasi tentang cara mengeskalasi kasus, lihat Mengeskalasikan kasus.

Merutekan kasus ke zona waktu yang diperlukan

Karena faktor-faktor yang menjadi dasar ketersediaan Layanan Pelanggan, kasus dukungan Anda mungkin akan ditugaskan kepada spesialis Layanan Pelanggan yang bekerja di luar jam buka Anda. Anda juga dapat menghubungi Customer Care selama hari kerja di zona waktu tertentu. Dalam kasus tersebut, sebaiknya Anda meminta Layanan Pelanggan untuk merutekan kasus dukungan Anda ke zona waktu yang sesuai untuk kasus Anda. Anda dapat menambahkan permintaan ini dalam deskripsi atau respons kasus. Contoh, Please route this case to the Pacific time zone (GMT-8). Kasus P1 akan diteruskan ke Layanan Pelanggan wilayah berikutnya karena mengikuti matahari sedangkan kasus lainnya akan tetap ditangani oleh pemilik kasus saat ini untuk terus menangani kasus tersebut pada hari berikutnya.

Memberikan masukan dengan survei CES

Setelah kasus terselesaikan, survei Skor Upaya Pelanggan (CES) terkait pendapat Anda tentang prosesnya akan dikirim melalui email. Kami sangat berterima kasih jika Anda dapat meluangkan waktu beberapa menit untuk mengisinya, sehingga kami tahu apa yang kami lakukan dengan baik dan apa saja tantangannya untuk meningkatkan aspek ini.

Setiap formulir masukan ditinjau secara manual oleh tim Pengalaman Pelanggan dan akan menghasilkan tindakan yang sesuai untuk meningkatkan pengalaman Anda di masa mendatang. Skor akan diberikan dari skala 5. Skor 3 atau lebih rendah akan dianggap sulit dari sisi pelanggan. Di sisi lain, skor 4 atau lebih berarti interaksi tidak sulit bagi pelanggan dan dianggap sebagai pengalaman positif.

Untuk informasi selengkapnya, tonton video Cara Mengirim Masukan Layanan Google Cloud dengan CES.

Masalah yang berjalan lama atau sulit

Masalah yang memerlukan waktu lama untuk diselesaikan dapat menjadi membingungkan dan usang. Cara terbaik untuk mencegah hal ini adalah dengan mengumpulkan informasi menggunakan Template masalah yang berjalan lama dengan status terbaru yang diringkas di bagian atas.

Untuk menggunakan template, buka link sebelumnya dan buat salinan. Sertakan link ke semua kasus yang relevan dan bug pelacakan internal. Bagikan dokumen ini kepada grup tim akun Anda dan minta mereka untuk membagikannya kepada spesialis Layanan Pelanggan tertentu.

Dokumen ini mencakup:

  • Ringkasan status saat ini diringkas di bagian atas.
  • Daftar hipotesis yang berpotensi benar.
  • Pengujian atau alat yang ingin Anda gunakan untuk menguji setiap hipotesis.

Usahakan agar setiap kasus tetap berfokus pada satu masalah, dan hindari membuka kembali kasus untuk mengemukakan masalah baru.

Melaporkan pemadaman produksi

Jika masalah tersebut telah menyebabkan aplikasi Anda berhenti menayangkan traffic kepada pengguna, atau memiliki dampak penting bagi bisnis yang serupa, hal ini mungkin merupakan pemadaman produksi. Kami ingin mengetahuinya sesegera mungkin. Sebaliknya, masalah yang memblokir sejumlah kecil developer bukanlah yang kami anggap sebagai pemadaman produksi.

Saat kami menerima laporan tentang gangguan produksi, kami akan segera melakukan triage situasi dengan:

  • Segera memeriksa masalah umum yang memengaruhi infrastruktur Google Cloud.
  • Mengonfirmasi sifat masalah.
  • Menetapkan saluran komunikasi.

Anda akan menerima balasan dengan pesan singkat, yang berisi:

  • Masalah umum terkait yang memengaruhi beberapa pelanggan.
  • Konfirmasi bahwa kami dapat mengamati masalah yang Anda laporkan, atau permintaan untuk mengetahui detail selengkapnya.
  • Cara kita ingin berkomunikasi.

Oleh karena itu, penting untuk membuat kasus dengan cepat, termasuk waktu, produk, ID, dan lokasi, lalu memulai pemecahan masalah yang lebih mendalam. Organisasi Anda mungkin memiliki proses pengelolaan insiden yang ditentukan dan langkah ini harus dijalankan sangat dekat dengan awal proses tersebut.

Proses pengelolaan insiden Google menentukan peran utama: komandan insiden. Orang ini melibatkan orang yang tepat, terus mengumpulkan status terbaru, dan meringkas status masalah secara berkala. Mereka mendelegasikan kepada orang lain untuk memecahkan masalah dan menerapkan perubahan. Delegasi ini memungkinkan kita menyelidiki beberapa hipotesis secara paralel. Sebaiknya Anda menetapkan proses serupa dalam organisasi Anda. Orang yang membuka kasus biasanya merupakan pilihan terbaik untuk menjadi komandan insiden karena mereka memiliki konteks terbanyak.

Melaporkan masalah jaringan

Ukuran dan kompleksitas jaringan Google dapat menyulitkan identifikasi tim yang memiliki masalah. Untuk mendiagnosis masalah jaringan, kita perlu mengidentifikasi penyebab utama yang sangat spesifik. Karena pesan error jaringan sering kali bersifat umum (seperti, "Tidak dapat terhubung ke server"), kita perlu mengumpulkan informasi diagnostik mendetail untuk mempersempit kemungkinan hipotesis.

Diagram alur paket memberikan struktur yang sangat baik untuk laporan masalah. Diagram ini menjelaskan hop penting yang diambil paket di sepanjang jalur dari sumber ke tujuan, beserta transformasi signifikan di sepanjang jalan.

Mulailah dengan mengidentifikasi endpoint jaringan yang terpengaruh berdasarkan alamat IP Internet atau alamat pribadi RFC 1918 ditambah ID untuk jaringan. Misalnya, 2.3.4.5 atau 10.2.3.4 di jaringan default project Compute Engine.

Perhatikan hal-hal yang bermakna tentang endpoint, seperti:

  • Siapa yang mengontrolnya.
  • Apakah nama tersebut dikaitkan dengan nama host DNS.
  • Enkapsulasi atau inderek menengah, atau keduanya seperti tunneling VPN, proxy, dan gateway NAT.
  • Pemfilteran perantara apa pun, seperti firewall atau CDN atau WAF.

Banyak masalah yang muncul sebagai latensi tinggi atau hilangnya paket secara intermiten akan memerlukan analisis jalur atau penangkapan paket, atau keduanya untuk diagnosis.

  • Analisis jalur adalah daftar semua hop yang dilalui paket dan dikenal sebagai "traceroute". Kita sering menggunakan MTR atau tcptraceroute, atau keduanya karena memiliki kemampuan diagnostik yang lebih baik. Sebaiknya Anda memahami alat ini.
  • Penangkapan paket (juga dikenal sebagai "pcap", dari nama library "libpcap") adalah pengamatan traffic jaringan yang sebenarnya. Penting untuk mengambil rekaman aktivitas paket untuk kedua endpoint, secara bersamaan, yang bisa jadi rumit. Sebaiknya berlatih dengan alat yang diperlukan (misalnya, tcpdump atau Wireshark) dan pastikan alat tersebut diinstal sebelum Anda membutuhkannya.