Panduan ini memberikan 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 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 titik, 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 memberikan respons dengan cepat dan efisien. Jika kasus dukungan Anda tidak memiliki detail penting, kami perlu meminta informasi lebih lanjut, yang akan memerlukan waktu tambahan.
Ciri kasus dukungan yang baik adalah mendetail dan spesifik. Mereka memberi tahu kami apa yang terjadi dan apa yang Anda harapkan terjadi. Saat Anda menjelaskan masalah 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 dapat 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 tersebut berlangsung.
Contoh:
- Mulai pukul 15.13.06+00.00 pada 08-09-2017 dan berakhir 5 menit kemudian, kami mengamati...
- Diamati secara berkala, dimulai paling awal pada 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 Customer Care yang menyelesaikan masalah kemungkinan besar tidak berada di zona waktu Anda, sehingga pernyataan relatif seperti berikut membuat masalah lebih sulit didiagnosis:
- "Ini mulai terjadi kemarin..." (Memaksa kita menyimpulkan tanggal yang tersirat.)
- "Kami melihat masalah ini pada 8/9..." (Tidak jelas, karena beberapa orang 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 tertentu (atau screenshot). Google Cloud Untuk API, Anda dapat menautkan ke halaman dokumentasi, yang berisi nama produk di URL.
Selain itu, beri tahu kami mekanisme yang Anda gunakan untuk memulai permintaan (misalnya, REST API, Google Cloud CLI, Google Cloud konsol, atau mungkin alat seperti Cloud Deployment Manager. Jika ada beberapa produk yang terlibat, sebutkan setiap nama produk secara spesifik.
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 tempat yang harus diperiksa 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, jadi kami tidak dapat menjalankannya sendiri untuk mereproduksi error tersebut. Selain itu, kami tidak tahu error mana yang sebenarnya Anda lihat.)
Lokasi
Kami perlu mengetahui region dan zona pusat data Anda karena kami sering men-deploy 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 tidak kompatibel di versi tertentu software kami memengaruhi sistem Anda.
Contoh:
- "In us-east1-b ..." (Di us-east1-b ...)
- "Saya mencoba region us-east1 dan us-central1..."
Pengenal
ID tertentu membantu kami mengidentifikasi project Cloud Anda yang mengalami masalah. Kita selalu perlu mengetahui project alfanumerik atau ID aplikasi. Nama project tidak membantu. Jika masalah ini 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 BigQuery atau nama tabel.
- 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. Selain itu, beri tahu kami jika alamat IP tidak terkait dengan sistem Google (misalnya, jika alamat IP tersebut untuk internet rumah Anda, endpoint VPN, atau sistem pemantauan eksternal).
Contoh:
- "Di project robot-name-165473 atau my-project-id..."
- "Across multiple projects (including my-project-id)..."
- "Menghubungkan ke Google Cloud IP eksternal 218.239.8.9 dari gateway perusahaan 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
Dengan memberikan artefak yang terkait dengan masalah tersebut, pemecahan masalah akan lebih cepat karena kami dapat melihat persis apa yang Anda lihat.
Contoh:
- Gunakan screenshot untuk menunjukkan persis apa yang Anda lihat.
- Untuk antarmuka berbasis web, berikan informasi rekaman aktivitas browser yang relevan.
- Lampirkan output tcpdump, cuplikan log, contoh stack trace.
Jenis masalah
Sesekali: Masalah sesekali terjadi secara acak tanpa pola kegagalan yang teratur. Masalah yang terjadi sesekali sulit dipecahkan karena ketidakteraturannya menyulitkan pengumpulan data selama kegagalan. Dalam hal ini, Anda harus mencoba mengidentifikasi hambatan dalam arsitektur dan memeriksa apakah penggunaan resource Anda mencapai batas maksimumnya. Anda juga dapat menjalankan pemeriksaan rutin dalam tugas terjadwal menggunakan otomatisasi, dan jika pemeriksaan gagal, kumpulkan informasi debug selama kegagalan. Contoh jenis kegagalan ini adalah kegagalan resolusi DNS dan kehilangan paket.
Sementara: Masalah sementara bersifat sesaat atau hanya terjadi dalam jangka waktu 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 agar toleran terhadap kegagalan sementara. Contoh kegagalan jenis ini adalah lonjakan latensi jaringan yang hanya terjadi selama beberapa mikrodetik, dan kehilangan paket kecil yang menyebabkan timeout. Transmission Control Protocol (TCP) dirancang untuk menangani 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 berfungsi. 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 berikut memberikan deskripsi mendetail untuk kasus dukungan.
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 kecepatan 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 kesalahan yang signifikan yang dihadapi pengguna. Dampak bisnis sangat penting (kehilangan pendapatan, potensi masalah integritas data, dll.). |
| P2: Berdampak Tinggi—Penggunaan Layanan Sangat Terganggu | Infrastruktur mengalami penurunan kualitas dalam produksi, dengan tingkat error yang terlihat jelas atau kesulitan dalam menyiapkan sistem produksi baru. Dampak bisnis sedang (bahaya kehilangan pendapatan, penurunan produktivitas, dll.). |
| P3: Dampak Sedang—Sebagian Layanan Terganggu | Masalah ini terbatas dalam cakupan dan/atau tingkat keparahannya. 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 | Dampak bisnis atau teknis kecil atau tidak ada. Direkomendasikan untuk tiket konsultasi yang memerlukan analisis mendalam, pemecahan masalah, atau konsultasi, bukan komunikasi yang lebih sering. |
Kapan harus menetapkan prioritas tertinggi
Jika Anda mengalami masalah yang memengaruhi layanan penting bisnis dan memerlukan perhatian segera dari Google, pilih "P1" sebagai prioritas. Jelaskan kepada kami secara mendetail alasan Anda memilih P1. Sertakan deskripsi singkat dampak masalah ini terhadap bisnis Anda. Misalnya, Anda dapat menganggap masalah pada versi pengembangan sebagai P1, meskipun tidak ada pengguna akhir yang terpengaruh secara langsung, jika masalah tersebut memblokir perbaikan keamanan yang penting.
Saat 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 tersebut.
Kami menghargai komentar mendetail yang mendukung tingkat prioritas yang dipilih karena hal itu 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.
- Secara default, casing "mengikuti matahari". Artinya, pakar dukungan berinteraksi 24 jam sehari hingga kasusnya diselesaikan atau tidak diprioritaskan. Jika mitigasi kasus lebih baik dilakukan di wilayah tertentu, kasus tersebut dapat dikunci ke zona waktu tertentu. Anda dapat memberi tahu kami preferensi Anda untuk efek ini.
Peningkatan prioritas P1
- Jika masalah telah mulai memengaruhi lingkungan produksi Anda, atau akan memengaruhi, Anda dapat meningkatkan prioritas kasus P2 - P4 yang ada menjadi P1.
- Saat Anda meningkatkan prioritas kasus yang ada ke 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, 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 yang telah ditentukan sebelumnya yang ditetapkan 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 mengikuti matahari. Kasus ini ditetapkan ulang beberapa kali sehari kepada spesialis Customer Care yang aktif. Saat kami memecahkan masalah kasus P1 Anda, sebaiknya Anda tetap aktif menjawab pertanyaan hingga masalah ini diselesaikan untuk memfasilitasi komunikasi yang efisien. Jika Anda tidak merespons selama lebih dari 3 jam, kami dapat menurunkan prioritas kasus menjadi P2 hingga Anda kembali berinteraksi.
Meningkatkan
Saat situasi berubah, Anda mungkin perlu meningkatkan masalah. Alasan yang valid 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 terbaik adalah menetapkan prioritas kasus yang sesuai selama jangka waktu yang memadai, bukan melakukan eskalasi. Eskalasi tidak selalu menyelesaikan kasus lebih cepat dan eskalasi segera setelah perubahan prioritas bahkan dapat menyebabkan penyelesaian kasus menjadi lebih lambat. Anda dapat menemukan penjelasan yang lebih mendetail dalam video Kapan Anda harus melakukan eskalasi.
Untuk mengetahui informasi selengkapnya, lihat Mengeskalasikan kasus.
Merutekan kasus ke zona waktu yang diperlukan
Karena faktor-faktor yang mendasari ketersediaan Layanan Pelanggan, kasus dukungan Anda mungkin ditetapkan kepada spesialis Layanan Pelanggan yang bekerja di luar jam operasional Anda. Anda juga dapat memilih untuk berinteraksi dengan Customer Care pada hari kerja di zona waktu tertentu. Dalam
kasus tersebut, sebaiknya Anda meminta Customer Care untuk mengarahkan kasus dukungan Anda ke zona waktu yang sesuai untuk kasus Anda. Anda dapat menambahkan permintaan ini dalam deskripsi atau respons kasus Anda. Contoh, Please route this
case to the Pacific time zone (GMT-8). Kasus P1 diserahkan kepada Layanan Pelanggan wilayah berikutnya karena mengikuti matahari, sementara kasus lain akan tetap ditangani oleh pemilik kasus saat ini untuk melanjutkan penanganan kasus pada hari berikutnya.
Memberikan masukan dengan survei CES
Setelah kasus diselesaikan, survei Skor Upaya Pelanggan (CES) mengenai pendapat Anda tentang proses tersebut akan dikirim melalui email. Kami akan sangat menghargai jika Anda dapat meluangkan waktu beberapa menit untuk mengisinya, sehingga kami dapat mengetahui apa yang sudah kami lakukan dengan baik dan apa saja tantangannya untuk meningkatkan aspek-aspek ini.
Setiap formulir masukan ditinjau secara manual oleh tim Customer Experience dan menghasilkan tindakan yang sesuai untuk meningkatkan pengalaman Anda di masa mendatang. Skornya adalah dari 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 mengetahui informasi selengkapnya, tonton video Cara Mengirimkan Masukan Layanan dengan CES. Google Cloud
Masalah yang sudah lama terjadi atau sulit diselesaikan
Masalah yang memerlukan waktu lama untuk diselesaikan dapat menjadi membingungkan dan tidak relevan. Cara terbaik untuk mencegah hal ini adalah mengumpulkan informasi menggunakan template Masalah yang berjalan lama kami dengan ringkasan status terbaru 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 Customer Care tertentu.
Dokumen ini mencakup:
- Ringkasan status saat ini yang diringkas di bagian atas.
- Daftar hipotesis yang berpotensi benar.
- Pengujian atau alat yang ingin Anda gunakan untuk menguji setiap hipotesis.
Usahakan agar setiap kasus berfokus pada satu masalah, dan hindari membuka kembali kasus untuk mengajukan masalah baru.
Melaporkan penonaktifan produksi
Jika masalah tersebut menyebabkan aplikasi Anda berhenti menayangkan traffic kepada pengguna, atau memiliki dampak penting bagi bisnis yang serupa, hal ini mungkin merupakan gangguan produksi. Kami ingin mengetahuinya sesegera mungkin. Masalah yang memblokir sejumlah kecil developer, sebaliknya, tidak dianggap sebagai gangguan produksi.
Saat kami menerima laporan gangguan produksi, kami akan segera memilah situasi tersebut dengan:
- Segera periksa masalah umum yang memengaruhi infrastruktur Google Cloud .
- Mengonfirmasi sifat masalah.
- Membangun saluran komunikasi.
Anda akan menerima respons dengan pesan singkat, yang berisi:
- Masalah umum terkait yang memengaruhi beberapa pelanggan.
- Konfirmasi bahwa kami dapat mengamati masalah yang Anda laporkan, atau permintaan detail lebih lanjut.
- Cara kami berkomunikasi.
Oleh karena itu, penting untuk segera membuat kasus yang mencakup waktu, produk, ID, dan lokasi, lalu mulai pemecahan masalah yang lebih mendalam. Organisasi Anda mungkin memiliki proses pengelolaan insiden yang telah ditentukan dan langkah ini harus dilakukan di awal proses tersebut.
Proses pengelolaan insiden Google menentukan peran utama: komandan insiden. Orang ini melibatkan orang yang tepat, terus 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 menyelidiki beberapa hipotesis secara paralel. Sebaiknya Anda membuat proses serupa dalam organisasi Anda. Orang yang membuka kasus biasanya merupakan pilihan terbaik untuk menjadi komandan insiden karena ia memiliki konteks paling banyak.
Melaporkan masalah jaringan
Ukuran dan kompleksitas jaringan Google dapat menyulitkan identifikasi tim yang bertanggung jawab atas masalah tersebut. 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 yang mendetail untuk mempersempit kemungkinan hipotesis.
Diagram alur paket memberikan struktur yang sangat baik untuk laporan masalah. Diagram ini menjelaskan lompatan penting yang dilakukan paket di sepanjang jalur dari sumber ke tujuan, beserta transformasi signifikan yang terjadi di sepanjang jalur tersebut.
Mulai dengan mengidentifikasi endpoint jaringan yang terpengaruh berdasarkan alamat IP Internet atau berdasarkan alamat pribadi RFC 1918 ditambah ID untuk jaringan. Misalnya, 2.3.4.5 atau 10.2.3.4 di jaringan default project Compute Engine.
Catat hal-hal penting tentang endpoint, seperti:
- Siapa yang mengontrolnya.
- Apakah terkait dengan nama host DNS.
- Enkapsulasi atau pengalihan perantara, atau keduanya seperti tunneling VPN, proxy, dan gateway NAT.
- Pemfilteran perantara, seperti firewall atau CDN atau WAF.
Banyak masalah yang muncul sebagai latensi tinggi atau kehilangan paket terputus-putus akan memerlukan analisis jalur atau penangkapan 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 memiliki kemampuan diagnostik yang lebih baik. Sebaiknya Anda memahami cara menggunakan alat ini.
- Perekaman paket (juga dikenal sebagai "pcap", dari nama library "libpcap") adalah pengamatan traffic jaringan yang sebenarnya. Penting untuk mengambil rekaman paket untuk kedua endpoint, secara bersamaan, yang bisa jadi rumit. Sebaiknya berlatih menggunakan alat yang diperlukan (misalnya, tcpdump atau Wireshark) dan pastikan alat tersebut sudah diinstal sebelum Anda membutuhkannya.
Melaporkan masalah konsol Google Cloud
Saat melaporkan masalah terkait konsol berbasis web Google Cloud , selain panduan di atas, berikan informasi berikut untuk membantu kami mempersempit kemungkinan penyebab masalah:
- URL halaman konsol yang terpengaruh
- ID project yang terpengaruh
- Jumlah pengguna yang terpengaruh
- Apakah masalah terjadi di berbagai komputer
- Browser yang terpengaruh
- Ekstensi browser atau sistem firewall yang sedang digunakan
Selain itu, menyertakan informasi rekaman aktivitas browser yang relevan akan membantu kami memahami dan menyelidiki masalah Anda.