Best practice per collaborare con l'assistenza clienti

Questa guida illustra le best practice per scrivere una richiesta di assistenza efficace. Queste best practice ci aiutano a risolvere più rapidamente la tua richiesta di assistenza tecnica.

Creazione di una richiesta di assistenza

Prima di creare una richiesta di assistenza, esamina i problemi noti per verificare se è già stata presentata.

Per evitare confusione e consentirci di monitorare la tua richiesta in un unico punto, crea una richiesta di assistenza per problema. Eventuali richieste duplicate create vengono chiuse.

Descrizione del problema

La scrittura di una richiesta di assistenza dettagliata consente al team dell'assistenza clienti di risponderti più facilmente in modo rapido ed efficiente. Quando nella tua richiesta di assistenza mancano dettagli critici, dobbiamo chiedere maggiori informazioni, il che richiede più tempo.

Le migliori richieste di assistenza sono sia dettagliate che specifiche. Ci dicono cosa è successo e cosa ti aspettavi che sarebbe successo. Quando descrivi il problema nella richiesta di assistenza, includi i seguenti dettagli:

  • Ora:il timestamp specifico in cui si è verificato il problema.
  • Prodotto: i prodotti e le funzionalità associati al problema.
  • Posizione: le zone in cui si verifica il problema.
  • Identificatori: l'ID progetto o l'ID applicazione e altri identificatori concreti che ci aiutano a risolvere il problema.
  • Elementi utili: qualsiasi dettaglio che puoi fornire per aiutarci a diagnosticare il problema.
  • Tipo di problema:il problema è intermittente, temporaneo o costante.

Nelle sezioni seguenti vengono descritti questi concetti in modo più dettagliato.

Tempo

Utilizzando il formato ISO 8601 per la data e il timestamp, comunicaci quando hai notato per la prima volta il problema e per quanto tempo è durato.

Esempi:

  • A partire dal 08-09-2017T15:13:06+00:00 e fino a 5 minuti dopo, abbiamo osservato...
  • Osservata a intermittenza, a partire dal 10/09/2017 e osservata 2-5 volte...
  • In corso dal 2017-09-08T15:13:06+00:00...
  • Dal 08-09-2017T15:13:06+00:00 al 08-09-2017T15:18:16+00:00...

È molto probabile che l'esperto dell'assistenza clienti che risolva il problema non rientri nel tuo fuso orario, pertanto dichiarazioni relative come le seguenti rendono il problema più difficile da diagnosticare:

  • "È iniziato tutto ieri..." (Ci obbliga a dedurre la data implicita).
  • "Abbiamo notato il problema l'8/09..." È ambigua, come alcuni potrebbero interpretare questa data come l'8 settembre e altri come 9 agosto.

Prodotto

Anche se il modulo della richiesta di base ti chiede di specificare un nome di prodotto, abbiamo bisogno di informazioni specifiche riguardo alla funzionalità del prodotto che presenta il problema. Idealmente, il report farà riferimento ad API specifiche o URL della console Google Cloud (o screenshot). Per le API, puoi inserire un link alla pagina della documentazione, che contiene il nome del prodotto nell'URL.

Descrivi anche il meccanismo che stai utilizzando per avviare la richiesta (ad esempio, API REST, Google Cloud CLI, console Google Cloud o magari uno strumento come Cloud Deployment Manager). Se sono coinvolti più prodotti, indicaci un nome specifico.

Esempi:

  • "L'API REST di Compute Engine ha restituito i seguenti errori..."
  • "L'interfaccia di query BigQuery in console.cloud.google.com si sta bloccando..."

Le seguenti dichiarazioni non sono sufficientemente specifiche per sapere dove cercare quando diagnosi del problema:

  • "Impossibile creare le istanze..." (dobbiamo conoscere il metodo che stai utilizzando per creare le istanze).
  • "Il comando gcloud compute create instances restituisce un errore..."(La sintassi del comando è errata, quindi non possiamo eseguirlo autonomamente per riprodurre l'errore. Inoltre, non sappiamo quale errore hai effettivamente visualizzato.

Località

Dobbiamo conoscere la regione e la zona del tuo data center perché spesso implementiamo le modifiche a una regione o a una zona alla volta. La regione e la zona sono un proxy per il numero di versione del software sottostante. Queste informazioni ci aiutano a sapere se le modifiche che provocano errori in una determinata versione del nostro software interessano i tuoi sistemi.

Esempi:

  • "In us-east1-a ..."
  • "Ho provato le regioni us-east1 e us-central1..."

Identificatori

Gli identificatori specifici ci aiutano a identificare i tuoi progetti Cloud che stanno riscontrando il problema. Dobbiamo sempre conoscere l'ID progetto o applicazione alfanumerico. I nomi dei progetti non sono utili. Se il problema interessa più progetti, includi tutti gli ID interessati.

Oltre agli ID progetto o applicazione, molti altri identificatori ci aiutano a diagnosticare il tuo caso:

  • ID istanza.
  • ID job o nomi tabelle BigQuery.
  • indirizzi IP.

Quando specifichi un indirizzo IP, indica anche il contesto in cui viene utilizzato. Ad esempio, specifica se l'IP è connesso a un'istanza Compute, un bilanciatore del carico, una route personalizzata o un endpoint API. Facci anche sapere se l'indirizzo IP non è correlato ai sistemi di Google (ad esempio, se l'indirizzo IP è per la tua connessione a internet, un endpoint VPN o un sistema di monitoraggio esterno).

Esempi:

  • "Nel progetto robot-name-165473 o my-project-id..."
  • "In più progetti (incluso my-project-id)..."
  • "Connessione all'IP esterno 218.239.8.9 di Google Cloud dal nostro gateway aziendale 56.56.56.56..."

Affermazioni generali come le seguenti sono troppo generiche per poter diagnosticare il problema:

  • "Uno dei nostri casi non è raggiungibile..."
  • "Impossibile connettersi da internet..."

Artefatti utili

Se fornisci elementi relativi al problema, potrai velocizzare la risoluzione dei problemi aiutandoci a vedere esattamente ciò che stai visualizzando.

Ad esempio:

  • Usa uno screenshot per mostrare esattamente ciò che vedi.
  • Per le interfacce basate sul web, fornisci un file .HAR (Http ARchive). L'analizzatore HAR fornisce istruzioni per i tre browser principali.
  • Collega output tcpdump, snippet dei log, analisi dello stack di esempio.

Tipo di problema

  • Intermittente: i problemi intermittenti si verificano in modo casuale senza schemi di errore regolari. I problemi intermittenti sono difficili da risolvere perché la loro irregolarità rende difficile la raccolta di dati durante l'errore. In questo caso, dovresti provare a identificare i colli di bottiglia nell'architettura e verificare se le tue risorse stanno raggiungendo la soglia di utilizzo massima. Puoi anche eseguire controlli frequenti in un job pianificato utilizzando l'automazione e, se il controllo ha esito negativo, raccogliere informazioni di debug durante l'errore. Esempi di questo tipo di errore sono gli errori di risoluzione DNS e la perdita di pacchetti.

  • Temporaneo: i problemi temporanei sono temporanei o esistono solo per un breve periodo di tempo. Se si verificano problemi che si verificano solo per pochi secondi o pochi microsecondi, puoi verificare la presenza di micro burst di traffico o di utilizzi dei picchi di risorse. Nella maggior parte dei casi, i problemi temporanei possono essere ignorati se non si ripetono spesso e se il servizio è progettato per tollerare errori temporanei. Esempi di questo tipo di errore sono i picchi di latenza della rete che si verificano solo per pochi microsecondi e piccole perdite di pacchetti che causano timeout. Il protocollo Transmission Control Protocol (TCP) è progettato per errori come piccola perdita di pacchetti e picchi di latenza ed è in grado di gestire questi problemi in modo efficace, a meno che la tua applicazione non sia sensibile alla latenza.

  • Coerente: la coerenza è un problema che non funziona completamente, ad esempio quando il sito web non funziona. Risolvere problemi ricorrenti è relativamente facile perché è possibile riprodurli. In questo caso, indica i passaggi per riprodurre il problema, in modo che i nostri specialisti dell'assistenza clienti possano rispondere all'ambiente e risolvere il problema.

Descrizioni di esempio

Esempio uno

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.

Esempio due

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.

Impostazione della priorità e riassegnazione

La priorità ci aiuta a comprendere l'impatto del problema sulla tua attività e influisce sulla rapidità con cui rispondiamo per risolvere il problema. Le priorità sono definite nella tabella seguente. Puoi trovare ulteriori informazioni nella pagina Priorità delle richieste di assistenza.

Definizione di priorità Situazione di esempio
P1: impatto critico: servizio inutilizzabile in produzione L'applicazione o l'infrastruttura è inutilizzabile in produzione, con un tasso significativo di errori rivolti agli utenti. L'impatto sull'attività è fondamentale (perdita delle entrate, potenziale problema di integrità dei dati e così via).
P2: Impatto elevato: utilizzo del servizio gravemente compromesso Le prestazioni dell'infrastruttura sono ridotte in produzione, con un notevole tasso di errori riscontrati dagli utenti o di difficoltà nell'avviare un nuovo sistema di produzione. L'impatto sull'attività è moderato (pericolo di perdita di entrate, diminuzione della produttività e così via).
P3: impatto medio: utilizzo del servizio parzialmente compromesso Il problema ha un ambito e/o una gravità limitati. Il problema non ha alcun impatto visibile agli utenti. L'impatto sull'attività è basso (ad es. inconvenienti o problemi di minore entità relativi ai processi aziendali).
P4: Basso impatto: servizio completamente utilizzabile Impatto commerciale o tecnico minimo o nullo. Opzione consigliata per le richieste di consulenza in cui è preferibile analisi approfondita, risoluzione dei problemi o consulenza per comunicazioni più frequenti.

Quando impostare la priorità più alta

Se hai un problema che interessa servizi fondamentali per l'attività e richiede l'attenzione immediata di Google, scegli "P1" come priorità. Spiegaci nel dettaglio perché hai scelto il livello P1. Includi una breve descrizione dell'impatto del problema sulla tua attività. Ad esempio, un problema con una versione dev potrebbe essere considerato P1, anche se nessun utente finale è interessato direttamente, se blocca una correzione di sicurezza critica.

Quando una richiesta viene impostata come P1, un membro del team di assistenza in servizio viene immediatamente avvisato per trovare l'esperto giusto che si occupi esclusivamente della risoluzione del problema. Riceverai una rapida risposta iniziale. Successivamente, riceverai aggiornamenti regolari.

Apprezziamo i commenti dettagliati che supportano il livello di priorità scelto, perché ci aiutano a rispondere in modo appropriato.

Tempi di risposta

I livelli di priorità dei problemi hanno tempi di risposta predefiniti definiti nelle linee guida per i servizi di assistenza tecnica della piattaforma Google Cloud. Se hai bisogno di una risposta entro un periodo di tempo specifico, comunicacelo nella descrizione della segnalazione. Se un problema P1 deve essere gestito 24 ore su 24, puoi richiedere il servizio "segui il sole". Queste richieste vengono riassegnate più volte al giorno a uno specialista dell'assistenza clienti attivo.

Riassegnazione in corso

Quando le circostanze cambiano, potrebbe essere necessario riassegnare un problema. Ecco alcuni motivi validi per la riassegnazione:

  • Aumento dell'impatto aziendale.
  • Suddivisione del processo di risoluzione. Ad esempio, non hai ricevuto un aggiornamento nel periodo di tempo concordato o il problema è "bloccato" senza progressi dopo lo scambio di diversi messaggi.

Quando si verifica un problema a impatto elevato, la soluzione migliore è impostare il caso con la priorità appropriata per un periodo di tempo adeguato, anziché riassegnarlo. L'escalation non risolve necessariamente la richiesta più rapidamente e subito dopo la modifica della priorità potrebbe anche rallentare la risoluzione della richiesta. Puoi trovare una spiegazione più dettagliata nel video Quando è opportuno riassegnare la richiesta.

Per informazioni su come riassegnare una richiesta, vedi Riassegnare una richiesta.

Indirizza le richieste al fuso orario richiesto

Per via dei fattori su cui si basa la disponibilità dell'assistenza clienti, la tua richiesta di assistenza potrebbe essere assegnata a uno specialista dell'assistenza clienti che lavora al di fuori dell'orario di lavoro. È anche possibile che tu voglia contattare l'assistenza clienti durante i giorni lavorativi di un fuso orario specifico. In questi casi, ti consigliamo di richiedere all'assistenza clienti di inoltrare la richiesta di assistenza al fuso orario più pratico per la tua richiesta. Puoi aggiungere questa richiesta nella descrizione o nella risposta alla richiesta. Ad esempio, Please route this case to the Pacific time zone (GMT-8). Le richieste P1 vengono trasmesse all'assistenza clienti della regione successiva perché segui il sole, mentre per le altre richieste l'attuale proprietario della richiesta continua a occuparsi il giorno successivo.

Fornire feedback con il sondaggio CES

Quando una richiesta viene risolta, verrà inviato via email un sondaggio sul punteggio di attività del cliente (CES) riguardante la tua opinione sullo svolgimento della procedura. Apprezzerei davvero se potessi dedicare qualche minuto a compilarlo, in modo da sapere cosa abbiamo fatto bene e quali sono state le sfide per migliorare questi aspetti.

Ogni modulo di feedback viene esaminato manualmente dal team Customer Experience e comporta le azioni corrispondenti per migliorare la tua esperienza futura. Il punteggio sarà su 5. Un punteggio pari o inferiore a 3 sarebbe considerato difficile dal lato cliente, pertanto ti informeremo su queste risposte. Invece, un punteggio pari o superiore a 4 indica che l'interazione non è stata difficile per il cliente ed è considerata un'esperienza positiva.

Per ulteriori informazioni, guarda il video How to Send Google Cloud Services Feedback with CES (Come inviare feedback sui servizi Google Cloud con il CES).

Problemi difficili o di lunga durata

I problemi la cui risoluzione richiede molto tempo possono diventare obsoleti e poco chiari. Il modo migliore per evitare che questo accada è raccogliere informazioni utilizzando il nostro modello di problemi di lunga durata, con lo stato più recente riepilogato in alto.

Per utilizzare il modello, apri il link precedente e crea una copia. Includi link a tutti i casi pertinenti e a bug di monitoraggio interni. Condividi questo documento con il gruppo del team dedicato all'account e chiedi di condividerlo con esperti dell'assistenza clienti specifici.

Questo documento include:

  • Un riepilogo dello stato attuale riepilogato nella parte superiore.
  • Un elenco delle ipotesi potenzialmente vere.
  • I test o gli strumenti che intendi utilizzare per verificare ogni ipotesi.

Cerca di focalizzare l'attenzione su un singolo problema per ogni richiesta ed evita di riaprirla per trovarne uno nuovo.

Segnalazione di un'interruzione della produzione

Se il problema ha causato l'interruzione della gestione del traffico per gli utenti dall'applicazione o ha un impatto simile critico per l'azienda, potrebbe trattarsi di un'interruzione della produzione. Vogliamo saperlo il prima possibile. I problemi che bloccano un numero ridotto di sviluppatori, al contrario, non sono ciò che consideriamo interruzioni di produzione.

Quando riceviamo un report di un'interruzione della produzione, classifichiamo rapidamente la situazione:

  • Verifica immediata della presenza di problemi noti che interessano l'infrastruttura di Google Cloud.
  • Conferma della natura del problema.
  • Stabilire canali di comunicazione.

Dovresti ricevere una risposta con un breve messaggio, che contiene:

  • Eventuali problemi noti correlati che interessano più clienti.
  • La conferma che possiamo osservare il problema che hai segnalato o una richiesta di ulteriori dettagli.
  • Come intendiamo comunicare.

È quindi importante creare rapidamente una richiesta che includa ora, prodotto, identificatori e località e quindi iniziare più a fondo la risoluzione dei problemi. La tua organizzazione potrebbe avere un processo di gestione degli incidenti definito e questo passaggio dovrebbe essere eseguito quasi all'inizio.

Il processo di gestione degli incidenti di Google definisce un ruolo chiave: l'Incident Commander. Questa persona coinvolge le persone giuste, raccoglie continuamente lo stato più recente e riassume periodicamente lo stato del problema. Delegano ad altri la risoluzione dei problemi e l'applicazione delle modifiche. Questa delega ci permette di analizzare più ipotesi in parallelo. Ti consigliamo di adottare una procedura simile all'interno della tua organizzazione. La persona che ha aperto la richiesta è di solito la scelta migliore per l'Incident Commander, perché ha il maggiore contesto.

Segnalazione di un problema di rete

Le dimensioni e la complessità della rete Google possono rendere difficile identificare il team responsabile del problema. Per diagnosticare i problemi di rete, dobbiamo identificarne le cause principali. Poiché i messaggi di errore di rete sono spesso generici (ad esempio "Impossibile connettersi al server"), dobbiamo raccogliere informazioni diagnostiche dettagliate per restringere le ipotesi possibili.

I diagrammi di flusso dei pacchetti forniscono un'eccellente struttura per il report sui problemi. Questi diagrammi descrivono gli hop importanti che un pacchetto porta dall'origine alla destinazione, insieme a eventuali trasformazioni significative.

Inizia identificando gli endpoint di rete interessati in base all'indirizzo IP internet o all'indirizzo privato RFC 1918 più un identificatore per la rete. Ad esempio, 2.3.4.5 o 10.2.3.4 sulla rete predefinita del progetto Compute Engine.

Prendi nota di tutto ciò che riguarda gli endpoint, ad esempio:

  • Chi li controlla.
  • Se sono associati a un nome host DNS.
  • Qualsiasi incapsulamento intermedio o indiretto, oppure entrambi, come tunneling VPN, proxy e gateway NAT.
  • Qualsiasi filtro intermedio, come firewall o CDN o WAF.

Molti problemi che si manifestano come elevata latenza o perdita di pacchetti intermittente richiedono un'analisi dei percorsi, l'acquisizione di pacchetti o entrambi ai fini della diagnosi.

  • L'analisi dei percorsi è un elenco di tutti gli hop attraversati dai pacchetti ed è familiare come "traceroute". Spesso utilizziamo MTR o tcptraceroute, o entrambi perché hanno una migliore potenza diagnostica. Ti consigliamo di acquisire familiarità con questi strumenti.
  • L'acquisizione di pacchetti (nota anche come "pcap", dal nome della libreria "libpcap") è un'osservazione del traffico di rete reale. È importante acquisire un pacchetto per entrambi gli endpoint contemporaneamente, il che può essere complicato. Ti consigliamo di fare pratica con gli strumenti necessari (ad esempio tcpdump o Wireshark) e assicurarti che vengano installati prima di averne bisogno.