Best practice per collaborare con l'assistenza clienti

Questa guida fornisce le best practice per scrivere una richiesta di assistenza efficace. Seguire queste best practice ci aiuta 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 poter monitorare la richiesta in un unico punto, crea una richiesta di assistenza per problema. Le richieste duplicate create vengono chiuse.

Descrizione del problema

Scrivere una richiesta di assistenza dettagliata permette al team di assistenza clienti di risponderti in modo più rapido ed efficiente. Se nella tua richiesta di assistenza mancano dettagli critici, dobbiamo chiederti ulteriori 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 tua richiesta di assistenza, includi i seguenti dettagli:

  • Ora:il timestamp specifico in cui è iniziato il problema.
  • Prodotto: i prodotti e le funzionalità associati al problema.
  • Località: le zone in cui riscontri il problema.
  • Identificatori: l'ID progetto/applicazione e altri identificatori concreti che ci aiutano a indagare sul problema.
  • Artefatti utili: qualsiasi dettaglio che puoi fornire per aiutarci a diagnosticare il problema.
  • Tipo di problema:il problema è intermittente, temporaneo o costante.

Nelle sezioni che seguono vengono descritti questi concetti in maggiore dettaglio.

Ora

Usando il formato ISO 8601 per la data e l'ora, comunicaci quando hai notato per la prima volta questo problema e per quanto tempo.

Esempi:

  • A partire dal 2017-09-08T15:13:06+00:00 e terminando 5 minuti dopo, abbiamo osservato...
  • Osservato a intermittenza, a partire da non prima del 10/09/2017 e osservato 2-5 volte...
  • In corso dal 08-09-2017T15:13:06+00:00...
  • Dal 2017-09-08T15:13:06+00:00 al 2017-09-08T15:18:16+00:00...

È molto probabile che l'esperto dell'assistenza clienti che risolve il problema non si trovi nel tuo fuso orario, pertanto dichiarazioni relative alle seguenti affermazioni rendono più difficile la diagnosi del problema:

  • "È iniziato ieri" Ci obbliga a dedurre la data implicita.
  • "Abbiamo notato il problema l'8/08..." (Ambiguo, poiché alcuni potrebbero interpretare questa data come l'8 settembre, mentre altri potrebbero interpretarla come il 9 agosto).

Prodotto

Il modulo di base richiede di specificare il nome del prodotto, ma abbiamo bisogno di informazioni specifiche sulla funzionalità del prodotto che presenta il problema. Idealmente, il report farà riferimento a specifiche API o URL di console Google Cloud (o screenshot). Per le API, puoi inserire un link alla pagina della documentazione, che contiene il nome del prodotto nell'URL.

Fornisci anche informazioni sul meccanismo che stai utilizzando per avviare la richiesta (ad esempio, API REST, Google Cloud CLI, console Google Cloud o strumento come Cloud Deployment Manager). Se sono coinvolti più prodotti, comunicaci ogni nome.

Esempi:

  • "L'API REST di Compute Engine ha restituito i seguenti errori..."
  • "L'interfaccia di query BigQuery in console.cloud.google.com è in fase di sospensione..."

Le seguenti affermazioni non sono abbastanza specifiche per sapere dove trovare la 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 eseguirla per riprodurre l'errore). Inoltre, non sappiamo quale errore hai effettivamente visualizzato.

Località

Dobbiamo conoscere l'area geografica e la zona del tuo data center perché spesso implementiamo le modifiche a un'area geografica o 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 un errore in una determinata versione del nostro software interessano i tuoi sistemi.

Esempi:

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

Identificatori

Identificatori specifici ci aiutano a identificare quale dei tuoi progetti Cloud sta riscontrando il problema. Abbiamo sempre bisogno di conoscere l'ID alfanumerico del progetto o dell'applicazione. I nomi dei progetti non sono utili. Se il problema riguarda più progetti, includi ogni ID interessato.

Oltre agli ID progetto o applicazione, diversi altri identificatori aiutano a diagnosticare la tua richiesta:

  • ID istanza.
  • ID job BigQuery o nomi di tabella.
  • Indirizzi IP.

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

Esempi:

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

Dichiarazioni generali come le seguenti sono troppo generiche per aiutare a diagnosticare il problema:

  • "Una delle nostre istanze non è raggiungibile..."
  • "Impossibile connettersi da Internet..."

Artefatti utili

Fornendoci gli artefatti correlati al problema, accelera la risoluzione dei problemi, aiutandoci a vedere esattamente ciò che vedi.

Ecco alcuni esempi:

  • Usa uno screenshot per mostrare esattamente ciò che vedi.
  • Per le interfacce basate sul Web, fornisci un file .HAR (HttpARchive). L'analizzatore HAR contiene istruzioni per i tre browser principali.
  • Allega output tcpdump, snippet di log e analisi dello stack di esempio.

Tipo di problema

  • Intermittente: i problemi intermittenti si verificano in modo casuale senza pattern di errore normali. I problemi intermittenti sono difficili da risolvere perché la loro irregolarità rende difficile raccogliere i dati durante l'errore. In questo caso, devi cercare di identificare i colli di bottiglia nell'architettura e verificare se le risorse stanno raggiungendo gli utilizzi massimi della soglia. Puoi anche eseguire controlli frequenti in un job programmato usando l'automazione e, se il controllo non va a buon fine, raccogliere informazioni di debug durante l'esito negativo. 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 hai problemi che si verificano solo per un secondo o per pochi microsecondi, puoi controllare la presenza di micro burst di traffico o di utilizzo delle risorse di picco. Nella maggior parte dei casi, i problemi temporanei possono essere ignorati se non si verificano spesso e se il tuo servizio è progettato per tollerare guasti temporanei. Esempi di questo tipo di errore sono i picchi di latenza di rete che si verificano solo per pochi microsecondi e le piccole perdite di pacchetti che causano il timeout. Il protocollo TCP (Transmission Control Protocol) è progettato per consentire errori, ad esempio la perdita di pacchetti e i picchi di latenza, e consente di gestire questi problemi in modo efficace, a meno che l'applicazione non sia sensibile alla latenza.

  • Regolare: i problemi coerenti sono problemi che hanno esito negativo, ad esempio quando il tuo sito web non è disponibile. I problemi coerenti sono relativamente facili da risolvere perché possono essere riprodotti. In questo caso, comunicaci i passaggi per riprodurre il problema, in modo che i nostri esperti dell'assistenza clienti possano replicare l'ambiente e risolverlo per te.

Esempi di descrizioni

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 di questo problema sulla tua attività e la velocità con cui rispondiamo per risolverlo. Le priorità sono definite nella tabella seguente. Puoi trovare ulteriori informazioni nella pagina relativa alla priorità delle richieste di assistenza.

Definizione della priorità Situazione di esempio
P1: Impatto critico: servizio inutilizzabile in produzione L'applicazione o l'infrastruttura è inutilizzabile in produzione, con una frequenza significativa di errori rivolti agli utenti. L'impatto sull'attività è critico (perdita di entrate, potenziale problema di integrità dei dati e così via).
P2: Impatto elevato: utilizzo dei servizi gravemente compromesso L'infrastruttura è ridotta in produzione, con una notevole frequenza di errori per l'utente o difficoltà a avviare un nuovo sistema di produzione. L'impatto sul business è moderato (pericolo di perdita di entrate, diminuzione della produttività ecc.).
P3: impatto medio: utilizzo dei servizi parzialmente compromesso Il problema è limitato per ambito e/o gravità. Il problema non ha alcun impatto visibile all'utente. L'impatto sull'attività è basso (ad esempio, disagio o processi aziendali minori interessati).
P4: Impatto basso: servizio completamente utilizzabile Impatto commerciale o tecnico minimo o nullo. Consigliato per i ticket di consulenza in cui sono preferiti analisi approfondite, risoluzione dei problemi o consulenza a comunicazioni più frequenti.

Quando impostare la priorità più alta

Se hai un problema che interessa i servizi aziendali critici e richiede l'attenzione immediata da parte di Google, scegli "P1" come priorità. Spiegaci in modo dettagliato il motivo per cui hai selezionato P1. Includi una breve descrizione dell'impatto di questo problema sulla tua attività. Ad esempio, potresti considerare un problema con una versione di sviluppo come P1, anche se nessun utente finale è direttamente interessato, se sta bloccando una correzione di sicurezza critica.

Quando una richiesta viene impostata come P1, un membro del team di assistenza di competenza verrà immediatamente avvisato di trovare l'esperto giusto per lavorare esclusivamente sul problema. Riceverai una risposta iniziale rapida. Successivamente, riceverai aggiornamenti regolari.

Apprezziamo i commenti dettagliati a supporto del livello di priorità scelto, perché ci aiuta 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 di Google Cloud Platform. Se hai bisogno di una risposta entro un orario specifico, comunicacelo nella descrizione del report. Se un problema di P1 deve essere gestito giorno e notte, puoi richiedere il servizio "Segui il sole". Questi casi vengono riassegnati più volte al giorno a un esperto dell'assistenza clienti attivo.

Riassegnazione

Quando le circostanze cambiano, potresti dover riassegnare un problema. Motivi validi per una riassegnazione sono:

  • Aumento dell'impatto sul business.
  • Suddivisione del processo di risoluzione. Ad esempio, non hai ricevuto un aggiornamento nella quantità di tempo concordata o il tuo problema è "bloccato" senza progressi dopo lo scambio di diversi messaggi.

Quando si verifica un problema ad alto impatto, la soluzione migliore è impostare il caso sulla priorità appropriata per un periodo di tempo adeguato, anziché riassegnare il caso. La riassegnazione non risolve necessariamente il caso più rapidamente e la riassegnazione poco dopo il cambio di priorità potrebbe anche rallentare la risoluzione della richiesta. Potete trovare una spiegazione più dettagliata nel video Quando è necessario eseguire la riassegnazione.

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

Instrada le richieste al fuso orario richiesto

A causa 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 apertura. È possibile anche che tu voglia interagire con l'assistenza clienti durante gli orari di apertura di un fuso orario specifico. In questi casi, ti consigliamo di richiedere all'assistenza clienti di indirizzare la richiesta di assistenza a un fuso orario pratico per la tua richiesta. Puoi aggiungere questa richiesta nella descrizione o nella risposta della richiesta. Ad esempio, Please route this case to the Pacific time zone (GMT-8). Le richieste di assistenza P1 vengono trasferite all'assistenza clienti a livello di area geografica perché segue il sole, mentre altre richieste rimarranno con l'attuale proprietario per continuare a lavorare alla richiesta il giorno successivo.

Fornire feedback con il sondaggio CES

Quando un caso viene risolto, via email viene inviato un sondaggio del Cliente relativo al punteggio dell'impegno relativo alla tua opinione sull'andamento della procedura. Ti saremmo molto grati se potessi dedicare qualche minuto a compilarlo, in modo da sapere cosa ha fatto bene e quali sono state le sfide per migliorare questi aspetti.

Ogni modulo di feedback viene esaminato manualmente dal team Customer Experience e si traduce in azioni corrispondenti per migliorare la tua esperienza futura. Il punteggio sarà da 5. Un punteggio pari a 3 o inferiore sarebbe considerato difficile dal lato cliente e ti ricontatteremo su queste risposte. D'altra parte, un punteggio pari o superiore a 4 significa che l'interazione è stata facile (facile) per il cliente ed è stata considerata un'esperienza positiva.

Per ulteriori informazioni, guarda il video How to Submit Google Cloud Services Feedback with CES.

Problemi di lunga durata o difficili

I problemi che richiedono molto tempo per risolvere i problemi possono creare confusione e non essere più aggiornati. Il modo migliore per evitare che ciò accada è raccogliere informazioni utilizzando il nostro modello di problema di lunga durata con l'ultimo stato riepilogato in alto.

Per utilizzare il modello, apri il link precedente e crea una copia. Includere link a tutte le richieste pertinenti e ai bug interni di monitoraggio. Condividi questo documento con il gruppo del tuo team dedicato all'account e chiedi di condividerlo con esperti specifici dell'assistenza clienti.

Questo documento include:

  • Un riepilogo dello stato attuale, riassunto in alto.
  • Un elenco di ipotesi che potrebbero essere vere.
  • I test o gli strumenti che intendi utilizzare per verificare ogni ipotesi.

Cerca di mantenere ogni richiesta incentrata su un singolo problema ed evita di riaprirla per visualizzare un nuovo problema.

Segnalare un'interruzione della produzione

Se il problema ha causato l'interruzione della gestione del traffico da parte della tua applicazione per gli utenti o ha un impatto business-critical simili, potrebbe trattarsi di un'interruzione della produzione. Vogliamo saperlo il prima possibile. I problemi che bloccano un numero ridotto di sviluppatori, contrasto, non sono ciò che noi consideriamo interruzioni del processo di produzione.

Quando riceviamo una segnalazione relativa a un'interruzione della produzione, valutiamo rapidamente la situazione in base a:

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

Puoi aspettarti una risposta con un breve messaggio, che contiene:

  • Eventuali problemi noti correlati che interessano più clienti.
  • Confermando che possiamo esaminare il problema che hai segnalato o richiesta di ulteriori dettagli.
  • Il modo in cui intendiamo comunicare.

Pertanto, è importante creare rapidamente una richiesta che includa tempo, prodotto, identificatori e posizione, quindi iniziare una risoluzione dei problemi più approfondita. La tua organizzazione potrebbe avere un processo di gestione degli incidenti definito e questo passaggio deve essere eseguito all'inizio.

Il processo di gestione degli incidenti di Google definisce un ruolo chiave: Commander. Questa persona acquisisce le persone giuste, raccoglie continuamente lo stato più recente e riepiloga periodicamente lo stato del problema. Delegano ad altri il compito di risolvere i problemi e applicare le modifiche. Questa delega ci consente di esaminare più ipotesi in parallelo. Ti consigliamo di definire una procedura simile nella tua organizzazione. La persona che ha aperto la richiesta è in genere la scelta migliore per scegliere come comandante degli incidenti perché ha il contesto più ampio.

Segnalazione di un problema di rete

Le dimensioni e la complessità della rete Google possono rendere difficile l'identificazione del team proprietario del problema. Per diagnosticare i problemi di rete, dobbiamo identificare cause principali molto specifiche. 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 offrono una struttura eccellente per il report sui problemi. Questi grafici descrivono gli hop importanti seguiti da un pacchetto lungo un percorso da origine a destinazione, insieme a eventuali trasformazioni significative lungo il percorso.

Inizia identificando gli endpoint di rete interessati tramite l'indirizzo IP Internet o tramite l'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.
  • Indica se sono associati a un nome host DNS.
  • Qualsiasi incapsulamento e/o inversione intermedia, come tunneling VPN, proxy e gateway NAT.
  • Qualsiasi filtro intermedio, come firewall, CDN o WAF.

Molti problemi che si manifestano come latenza elevata o perdita di pacchetti intermittente richiedono un'analisi del percorso e/o un'acquisizione dei pacchetti per la diagnosi.

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