Panduan ini memberi Anda praktik terbaik untuk menulis kasus dukungan yang efektif. Mengikuti praktik terbaik ini akan membantu kami menyelesaikan kasus dukungan teknis Anda lebih cepat.
Membuat kasus dukungan
Sebelum Anda membuat kasus dukungan, tinjau masalah umum untuk melihat apakah kasus telah diajukan atau belum.
Untuk menghindari kebingungan dan agar kami dapat melacak permintaan Anda pada satu titik, buat satu kasus dukungan per masalah. Kasus duplikat apa pun yang dibuat akan ditutup.
Mendeskripsikan masalah Anda
Menulis kasus dukungan yang mendetail akan memudahkan 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 membutuhkan waktu tambahan.
Kasus dukungan terbaik bersifat mendetail dan spesifik. Mereka memberi tahu kita apa yang terjadi dan apa yang Anda harapkan akan terjadi. Saat menjelaskan masalah dalam kasus dukungan, sertakan detail berikut:
- Waktu: Stempel waktu tertentu saat masalah dimulai.
- Produk: Produk dan fitur yang terkait dengan masalah.
- Lokasi: Zona tempat Anda melihat masalah.
- Identifiers: Project ID atau ID aplikasi dan ID konkret lainnya yang membantu kami meneliti masalah tersebut.
- Artefak yang berguna: Detail apa pun yang dapat Anda berikan untuk membantu kami mendiagnosis masalah.
- Jenis masalah: Apakah masalah tersebut hanya sesekali, sementara, 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 mengalami 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 sesekali, mulai dari 10-09-2017 dan diamati 2-5 kali...
- 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...
Pakar Layanan Pelanggan yang menyelesaikan masalah ini kemungkinan besar tidak berada di zona waktu Anda, sehingga pernyataan relatif seperti berikut membuat masalah menjadi lebih sulit untuk didiagnosis:
- "Hal ini dimulai kemarin..." (Memaksa kita untuk menyimpulkan tanggal tersirat.)
- "Kami mengetahui masalah ini pada tanggal 8/9..." (Bingung, karena beberapa mungkin menafsirkan tanggal ini sebagai 8 September, dan yang 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 atau URL Konsol Google Cloud tertentu (atau screenshot). Untuk API, Anda dapat menyediakan link ke halaman dokumentasi, yang berisi nama produk di URL.
Beri tahu kami juga 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, beri kami nama secara khusus.
Contoh:
- "Compute Engine REST API menampilkan error berikut..."
- "Antarmuka kueri BigQuery di console.cloud.google.com mengalami error..."
Pernyataan berikut tidak cukup spesifik untuk mengetahui ke mana harus mencarinya saat mendiagnosis masalah:
- "Tidak dapat membuat instance..." (Kami perlu mengetahui metode yang Anda gunakan untuk membuat instance.)
- "Perintah
gcloud compute create instancesmemberikan error..."(Sintaksis perintah salah, sehingga kami tidak dapat menjalankannya sendiri untuk mereproduksi error. Selain itu, kami tidak tahu error mana yang sebenarnya Anda lihat.)
Location
Kami perlu mengetahui region dan zona pusat data Anda karena kami sering meluncurkan perubahan ke satu region atau zona pada satu waktu. Region dan zona adalah proxy untuk nomor versi software yang mendasarinya. Informasi ini membantu kami mengetahui apakah perubahan yang dapat menyebabkan gangguan pada versi software tertentu memengaruhi sistem Anda.
Contoh:
- "Di us-east1-a ..."
- "Saya mencoba region us-east1 dan us-central1..."
Pengenal
ID khusus membantu kami mengidentifikasi project Cloud yang mengalami masalah. Kita harus selalu mengetahui project alfanumerik atau ID aplikasi. Nama project tidak membantu. Jika masalah tersebut memengaruhi beberapa project, sertakan setiap ID yang terpengaruh.
Selain ID project atau aplikasi, beberapa ID lain membantu kami mendiagnosis kasus Anda:
- ID instance.
- ID tugas atau nama tabel BigQuery.
- alamat IP tertentu.
Saat menentukan alamat IP, beri tahu juga kami konteks penggunaannya. Misalnya, tentukan apakah IP terhubung ke instance Compute, load balancer, rute kustom, atau endpoint API. Beri tahu kami juga jika alamat IP tersebut tidak terkait dengan sistem Google (misalnya, jika alamat IP adalah untuk internet rumah, endpoint VPN, atau sistem pemantauan eksternal).
Contoh:
- "Di project-name-165473 atau my-project-id..."
- "Di beberapa project (termasuk my-project-id)..."
- "Terhubung ke IP eksternal Google Cloud 218.239.8.9 dari gateway perusahaan 56.56.56.56 kami..."
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 akan mempercepat pemecahan masalah dengan membantu kami mengetahui apa yang Anda lihat.
Contoh:
- Gunakan screenshot untuk menunjukkan apa yang Anda lihat secara persis.
- Untuk Antarmuka berbasis Web, sediakan file .HAR (Http ARchive). HAR analyzer memiliki petunjuk untuk tiga browser utama.
- Melampirkan output tcpdump, cuplikan log, contoh stack trace.
Jenis masalah
Berselang-seling: Masalah intermiten terjadi secara acak dan tidak memiliki pola kegagalan yang biasa. Masalah yang berselang-seling 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 batas penggunaan maksimumnya. Anda juga dapat menjalankan pemeriksaan rutin dalam tugas terjadwal menggunakan otomatisasi, dan jika pemeriksaan gagal, kumpulkan informasi debug selama kegagalan. Contoh kegagalan ini adalah kegagalan resolusi DNS dan kehilangan paket.
Sementara: Masalah sementara bersifat sementara atau hanya ada untuk jangka waktu yang singkat. Jika mengalami masalah yang hanya terjadi selama satu detik atau beberapa mikrodetik, Anda dapat memeriksa burst mikro traffic atau pemanfaatan puncak resource. Pada umumnya, masalah sementara dapat diabaikan jika tidak sering berulang dan jika layanan Anda dirancang agar toleran terhadap kegagalan sementara. Contoh kegagalan jenis ini adalah lonjakan latensi jaringan yang hanya terjadi selama beberapa mikrodetik, dan kehilangan paket dalam jumlah kecil yang menyebabkan waktu tunggu. Transmission Control Protocol (TCP) dirancang untuk kegagalan seperti kehilangan paket dan lonjakan latensi yang kecil, dan dapat menangani masalah ini secara efektif, kecuali jika aplikasi sensitif terhadap latensi.
Konsisten: Masalah yang konsisten adalah masalah yang gagal sepenuhnya, seperti saat situs Anda tidak aktif. Masalah yang konsisten relatif mudah dipecahkan karena dapat direproduksi. Dalam hal ini, beri tahu kami langkah-langkah untuk mereproduksi masalah sehingga spesialis 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 dua
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 melakukan eskalasi
Prioritas membantu kami memahami dampak masalah ini terhadap bisnis Anda, dan memengaruhi seberapa cepat kami merespons masalah tersebut. Prioritas didefinisikan 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, karena memiliki tingkat error yang signifikan yang dihadapi pengguna. Dampak bisnis sangat penting (kehilangan pendapatan, potensi masalah integritas data, dll.). |
| P2: Dampak Tinggi—Penggunaan Layanan Sangat Terganggu | Infrastruktur mengalami penurunan performa dalam produksi, dengan tingkat error yang tinggi yang dialami pengguna atau kesulitan dalam menjalankan sistem produksi yang baru. Dampak terhadap bisnis termasuk sedang (bahaya kehilangan pendapatan, penurunan produktivitas, dll.). |
| P3: Dampak Sedang—Sebagian Penggunaan Layanan Terganggu | Cakupan masalah dan/atau tingkat keparahannya terbatas. Masalah ini tidak memiliki dampak yang terlihat oleh pengguna. Dampak terhadap bisnis rendah (misalnya, ketidaknyamanan atau proses bisnis kecil yang terpengaruh). |
| P4: Dampak Rendah—Layanan Dapat Digunakan Sepenuhnya | Sedikit atau tidak ada dampak bisnis atau teknis. Direkomendasikan untuk tiket konsultatif yang lebih memilih analisis mendalam, pemecahan masalah, atau konsultasi daripada komunikasi yang lebih sering. |
Kapan harus menetapkan prioritas tertinggi
Jika Anda mengalami masalah yang memengaruhi layanan yang penting bagi bisnis dan memerlukan perhatian segera dari Google, pilih "P1" sebagai prioritas. Jelaskan kepada kami secara detail mengapa Anda memilih P1. Sertakan deskripsi singkat tentang dampak masalah ini terhadap bisnis Anda. Misalnya, masalah pada versi pengembangan dapat dianggap sebagai P1, meskipun tidak ada pengguna akhir yang terkena dampak langsung, jika versi tersebut memblokir perbaikan keamanan penting.
Jika kasus ditetapkan sebagai P1, anggota tim Dukungan yang bertugas akan segera diberi tahu untuk mencari pakar yang tepat untuk menangani masalah tersebut secara eksklusif. Anda akan menerima tanggapan awal yang cepat. Setelah itu, Anda akan menerima pembaruan secara rutin.
Kami menghargai komentar mendetail yang mendukung tingkat prioritas yang dipilih karena membantu kami merespons dengan tepat.
Waktu respons
Tingkat prioritas masalah memiliki waktu respons yang telah ditentukan sebelumnya 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 "follow the sun". Kasus-kasus ini ditugaskan kembali beberapa kali per hari kepada spesialis Layanan Pelanggan yang aktif.
Melakukan eskalasi
Ketika keadaan berubah, Anda mungkin perlu mengeskalasi masalah. Alasan bagus untuk eskalasi adalah:
- Peningkatan dampak bisnis.
- Pembagian proses resolusi. Misalnya, Anda belum menerima update dalam jangka waktu yang telah disepakati, atau masalah Anda "terhenti" tanpa progres setelah bertukar beberapa pesan.
Saat Anda mengalami masalah berdampak tinggi, solusi terbaik adalah menetapkan kasus ke prioritas yang sesuai dengan durasi yang memadai, bukan mengeskalasikan. Melakukan eskalasi tidak selalu menyelesaikan kasus lebih cepat dan melakukan eskalasi segera setelah perubahan prioritas bahkan dapat menyebabkan penyelesaian kasus menjadi lebih lambat. Anda dapat menemukan penjelasan yang lebih mendetail di video Kapan sebaiknya Anda melakukan eskalasi.
Untuk mengetahui informasi tentang cara mengeskalasi kasus, lihat Mengeskalasikan kasus.
Merutekan kasus ke zona waktu yang diperlukan
Karena faktor yang menentukan ketersediaan Layanan Pelanggan, kasus dukungan Anda mungkin akan ditugaskan kepada spesialis Layanan Pelanggan yang bekerja di luar jam operasional Anda. Anda juga dapat berinteraksi dengan
Layanan Pelanggan selama hari kerja di zona waktu tertentu. Dalam
kasus tersebut, sebaiknya Anda meminta Layanan Pelanggan untuk mengarahkan
kasus dukungan 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 diteruskan ke Layanan Pelanggan region berikutnya karena mengikuti matahari, sementara kasus lain akan tetap ditangani oleh pemilik kasus saat ini untuk melanjutkan kasus tersebut keesokan harinya.
Memberikan masukan dengan survei CES
Saat kasus terselesaikan, survei Skor Upaya Pelanggan (CES) terkait pendapat Anda tentang cara kerja proses tersebut akan dikirim melalui email. Kami akan sangat apresiasi jika Anda dapat meluangkan waktu beberapa menit untuk mengisinya sehingga kami tahu apa yang kami lakukan dengan baik dan apa tantangan untuk meningkatkan aspek ini.
Setiap formulir masukan ditinjau secara manual oleh tim Pengalaman Pelanggan dan menghasilkan tindakan yang sesuai untuk meningkatkan pengalaman Anda pada masa mendatang. Skornya akan bernilai 5. Skor 3 atau lebih rendah akan dianggap sulit dari sisi pelanggan, dan kami akan menindaklanjuti dengan Anda. Di sisi lain, skor 4 atau lebih berarti bahwa interaksi tidak menyulitkan pelanggan dan dianggap sebagai pengalaman positif.
Untuk mengetahui informasi selengkapnya, tonton video Cara Mengirim Masukan Layanan Google Cloud dengan CES.
Masalah yang sulit atau berjalan lama
Masalah yang memerlukan waktu lama untuk diselesaikan dapat menjadi membingungkan dan tidak relevan. Cara terbaik untuk mencegah hal ini adalah dengan mengumpulkan informasi menggunakan Template masalah jangka panjang dengan status terbaru yang dirangkum di bagian atas.
Untuk menggunakan {i>template<i}, buka tautan sebelumnya dan buat salinannya. Menyertakan link ke semua kasus yang relevan dan bug pelacakan internal. Bagikan dokumen ini dengan grup tim akun Anda dan minta mereka untuk membagikannya kepada spesialis Layanan Pelanggan tertentu.
Dokumen ini berisi:
- Ringkasan status saat ini dirangkum di bagian atas.
- Daftar hipotesis yang mungkin benar.
- Pengujian atau alat yang ingin Anda gunakan untuk menguji setiap hipotesis.
Cobalah untuk membuat setiap kasus tetap fokus pada satu masalah, dan hindari membuka kembali kasus untuk menimbulkan masalah baru.
Melaporkan pemadaman layanan produksi
Jika masalah tersebut menyebabkan aplikasi Anda berhenti menayangkan traffic kepada pengguna, atau memiliki dampak bisnis yang penting, hal ini mungkin adalah penonaktifan produksi. Kami ingin mengetahuinya sesegera mungkin. Secara kontras, masalah yang memblokir sejumlah kecil developer bukanlah yang kami anggap sebagai gangguan produksi.
Saat kami mendapatkan laporan tentang pemadaman layanan produksi, kami akan segera menentukan prioritas situasi tersebut dengan:
- Segera memeriksa masalah umum yang memengaruhi infrastruktur Google Cloud.
- Mengonfirmasi sifat masalah.
- Membangun 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 detail selengkapnya.
- Bagaimana 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 manajemen insiden yang ditetapkan dan langkah ini harus dijalankan hampir sejak awal.
Proses manajemen insiden Google mendefinisikan peran penting: komandan insiden. Orang ini melibatkan orang yang tepat, terus-menerus mengumpulkan status terbaru, dan secara berkala merangkum status masalah. Mereka mendelegasikan tugas kepada orang lain untuk memecahkan masalah dan menerapkan perubahan. Delegasi ini memungkinkan kita untuk menyelidiki beberapa hipotesis secara paralel. Sebaiknya lakukan proses serupa dalam organisasi Anda. Orang yang membuka kasus ini biasanya merupakan pilihan terbaik untuk menjadi komandan insiden karena ia memiliki konteks yang paling banyak.
Melaporkan masalah jaringan
Ukuran dan kompleksitas jaringan Google dapat menyulitkan identifikasi tim mana yang memiliki masalah. Untuk mendiagnosis masalah jaringan, kita perlu mengidentifikasi akar penyebab yang sangat spesifik. Karena pesan error jaringan sering kali bersifat umum (seperti, "Tidak dapat terhubung ke server"), kami perlu mengumpulkan informasi diagnostik mendetail untuk mempersempit hipotesis yang mungkin.
Diagram alur paket memberikan struktur yang sangat baik untuk laporan masalah. Diagram ini menjelaskan hop penting yang dibawa sebuah paket di sepanjang jalur dari sumber ke tujuan, beserta setiap transformasi signifikan selama proses tersebut.
Mulailah dengan mengidentifikasi endpoint jaringan yang terpengaruh menurut alamat IP Internet atau berdasarkan alamat pribadi RFC 1918 serta ID untuk jaringan tersebut. Misalnya, 2.3.4.5 atau 10.2.3.4 di jaringan default project Compute Engine.
Perhatikan hal-hal yang penting tentang endpoint, seperti:
- Siapa yang mengontrol mereka.
- Apakah nama tersebut terkait dengan nama host DNS.
- Enkapsulasi atau pengalihan perantara apa pun, atau keduanya seperti tunneling VPN, proxy, dan gateway NAT.
- Filter perantara apa pun, seperti {i>firewall<i} atau CDN atau WAF.
Banyak masalah yang termanifestasi sebagai latensi tinggi atau kehilangan paket yang terputus-putus akan memerlukan analisis jalur atau pengambilan paket, atau keduanya untuk diagnosis.
- Analisis jalur adalah daftar semua hop yang dilalui paket dan dikenal sebagai "traceroute". Kami sering menggunakan MTR atau tcptraceroute, atau keduanya karena keduanya memiliki kemampuan diagnostik yang lebih baik. Sebaiknya Anda memahami alat-alat ini.
- Penangkapan paket (juga dikenal sebagai "pcap", dari nama library "libpcap") adalah pengamatan traffic jaringan yang sebenarnya. Penting untuk mengambil pengambilan paket untuk kedua endpoint secara bersamaan, dan ini bisa menjadi hal yang rumit. Sebaiknya Anda berlatih dengan alat yang diperlukan (misalnya, tcpdump atau Wireshark) dan pastikan alat tersebut telah diinstal sebelum Anda membutuhkannya.