Best practice per collaborare con l'assistenza clienti

Scrivere una richiesta di assistenza dettagliata aiuta il team di assistenza clienti a risponderti in modo più rapido ed efficiente. Quando nella tua richiesta di assistenza mancano dettagli critici, dobbiamo chiedere ulteriori informazioni, il che richiede più tempo. Questa guida ti fornisce le informazioni necessarie per risolvere la tua richiesta di assistenza tecnica, in modo da poterla risolvere più rapidamente.

Descrizione del problema

I rapporti sui problemi migliori sono sia dettagliati che specifici. Ci dicono cosa è successo e cosa ti aspettavi accadesse. Un report sui problemi corretto contiene i seguenti dettagli:

  • Ora: il timestamp specifico in cui è iniziato il problema.
  • Prodotto: il/i prodotto/i e funzionalità associati al problema.
  • Posizione: la zona o le zone in cui stai riscontrando il problema.
  • Identificatori: l'ID progetto/applicazione e altri identificatori concreti che ci aiutano a esaminare il problema.
  • Artefatti utili: qualsiasi dettaglio che puoi fornire per aiutarci a diagnosticare il problema.
  • Tipo di problema: il problema è intermittente, temporaneo o coerente.

Le seguenti sezioni descrivono questi concetti in modo più dettagliato.

Tempo

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

Esempi:

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

Il tecnico dell'assistenza che risolve il problema molto probabilmente non si trova nel tuo fuso orario, pertanto dichiarazioni relative alla seguente situazione rendono più difficile la diagnosi del problema:

  • "Tutto è iniziato ieri..." Questo valore ci obbliga a dedurre la data implicita.
  • "Abbiamo notato il problema l'8/9..." (Ambiguo, poiché alcuni potrebbero interpretarlo come l'8 settembre, mentre altri potrebbero interpretarlo come il 9 agosto).

Prodotto

Anche se il modulo della richiesta di assistenza di base richiede di specificare il nome di un prodotto, abbiamo bisogno di informazioni specifiche sulla funzionalità del prodotto che presenta il problema. Idealmente, il report farà riferimento ad API o URL di Cloud Console (o screenshot) specifici. 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, strumento gcloud, Cloud Console o forse uno strumento come Deployment Manager). Se sono coinvolti più prodotti, fornisci un nome specifico per ogni servizio.

Esempi:

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

Le seguenti affermazioni non sono abbastanza specifiche per sapere dove esaminare la diagnosi del problema:

  • "Non può creare istanze..." (Dobbiamo sapere quale metodo stai usando per creare istanze).
  • "Il comando gcloud compute create instances restituisce un errore..."(La sintassi del comando è sbagliata, quindi non possiamo eseguirlo manualmente per riprodurre l'errore. Inoltre, non sappiamo quale errore hai effettivamente riscontrato.

Località

Dobbiamo conoscere la tua area geografica e la tua zona data center perché spesso implementiamo le modifiche a un'area geografica o una zona alla volta. La regione e la zona sono un proxy per il numero di versione del software sottostante. Queste informazioni ci consentono di sapere se i cambiamenti di sistema in una determinata versione del nostro software interessano i tuoi sistemi.

Esempi:

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

Identificatori

Gli identificatori specifici ci aiutano a identificare quale dei tuoi progetti cloud sta riscontrando il problema. Dobbiamo sempre conoscere l'ID del progetto o dell'applicazione. I nomi dei progetti non sono utili. Se il problema riguarda più progetti, includi tutti gli ID interessati.

Oltre agli ID progetto o applicazione, ci sono diversi altri identificatori che consentono di diagnosticare il tuo caso:

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

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

Esempi:

  • "In robots-name-165473 or my-project-id..."
  • "In più progetti (incluso my-project-id)..."
  • "Connessione a IP esterno 218.239.8.9 di GCP dal nostro gateway aziendale 56.56.56.56..."

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

  • "Una delle nostre istanze non è raggiungibile..."
  • "Non possiamo connetterci da Internet..."

Manufatti utili

Fornire gli artefatti relativi al problema accelera la risoluzione dei problemi aiutandoci a vedere esattamente ciò che vedi.

Ad esempio:

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

Tipo di problema:

  • Intermittente. I problemi intermittenti si verificano in modo casuale senza pattern di errore regolari. I problemi intermittenti sono difficili da risolvere perché la loro irregolarità rende difficile la raccolta dei dati durante il guasto. In questo caso, devi provare a identificare i colli di bottiglia nell'architettura e verificare se le risorse stanno raggiungendo il loro utilizzo massimo della soglia. Puoi anche eseguire controlli frequenti in un job programmato utilizzando l'automazione e, se il controllo non va a buon fine, raccogliere informazioni di debug durante l'errore. Esempi di questo tipo di errore sono errori di risoluzione DNS e perdita di pacchetti.

  • Temporaneo: i problemi temporanei sono temporanei o presenti solo per un breve periodo di tempo. Se si verificano problemi che si verificano solo per un secondo o alcuni microsecondi, puoi controllare la presenza di micro burst di traffico o utilità dei picchi di risorse. Nella maggior parte dei casi, i problemi temporanei possono essere ignorati se non si verificano spesso e se il servizio è progettato per resistere a errori temporanei. Esempi di questo tipo di errore sono i picchi di latenza di rete che si verificano solo per pochi microsecondi e piccole perdite di pacchetti che causano il timeout. Tieni presente che il protocollo TCP (Transmission Control Protocol) è progettato per errori come la perdita di pacchetti di piccole dimensioni e picchi di latenza e può gestire questi problemi in modo efficace, a meno che l'applicazione non sia sensibile alla latenza.

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

Impostare la priorità e riassegnare la priorità

La priorità ci consente di comprendere l'impatto di questo problema sulla tua attività e influisce sulla velocità di risposta per risolvere il problema. Le priorità sono definite nella tabella seguente. Puoi trovare ulteriori informazioni nella pagina Procedure di assistenza Cloud.

Definizione di priorità Situazione di esempio
P1 - Impatto critico: servizio inutilizzabile in ambiente di produzione L'applicazione o l'infrastruttura è inutilizzabile in produzione, con una frequenza significativa di errori per l'utente. L'impatto aziendale è critico (perdita di entrate, potenziale problema di integrità dei dati e così via).
P2 - Impatto elevato: utilizzo del servizio gravemente compromesso L'infrastruttura è ridotta in produzione, con una notevole frequenza di errori rivolti agli utenti o difficoltà ad 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 una portata e/o una gravità limitata. Il problema non ha alcun impatto visibile all'utente. L'impatto sull'attività è basso (ad esempio, disagi, processi aziendali minori interessati e così via).
P4 - Impatto basso: servizio completamente utilizzabile Poco o nessun impatto tecnico o aziendale. Consigliato per i ticket di consulenza in cui sono richieste analisi approfondite, risoluzione dei problemi o consulenza a comunicazioni più frequenti.

Quando impostare la priorità più alta

Se hai un problema che riguarda servizi aziendali critici e necessita di un'attenzione immediata da parte di Google, scegli "P1" come priorità. Spiegaci nel dettaglio perché hai selezionato P1. Includi una breve descrizione dell'impatto di questo problema sulla tua attività. Ad esempio, potresti considerare un problema con una versione sviluppatore come P1, anche se nessun utente finale è interessato direttamente, se blocca una correzione critica della sicurezza.

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

Apprezziamo i commenti dettagliati che supportano il 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, faccelo sapere nella descrizione del report. Se un problema P1 deve essere gestito 24 ore su 24, puoi richiedere il servizio "sun". che vengono riassegnate più volte al giorno a un tecnico dell'assistenza attivo.

Riassegnazione

Se le circostanze cambiano, potrebbe essere necessario riassegnare il problema per dare più attenzione. I motivi giusti per la riassegnazione sono:

  • Aumento dell'impatto commerciale.
  • Il problema deve essere risolto più velocemente.
  • Il problema è "bloccato" senza progressi dopo lo scambio di diversi messaggi.

Per informazioni su come riassegnare una richiesta e su cosa succede quando esegui la riassegnazione di una richiesta, consulta l'articolo su come riassegnare una richiesta.

Se non sai con certezza se la riassegnazione sia la soluzione giusta, dedica un paio di minuti al nostro video clip su Quando è il momento di riassegnare la segnalazione.

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 un tecnico dell'assistenza che lavora al di fuori dell'orario di lavoro. È anche possibile che tu voglia interagire con l'assistenza clienti durante gli orari di apertura di un fuso orario specifico. In tali 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 timezone (GMT-8). Le richieste di assistenza P1 vengono trasmesse all'assistenza clienti successiva perché rispetta il sole, mentre le altre richieste rimangono presso l'attuale proprietario per continuare a occuparsi della richiesta il giorno successivo.

Fornire feedback con un sondaggio sul CES

Una volta risolta una richiesta, verrà inviato via email un sondaggio per il punteggio del cliente (CES) relativo alla tua opinione sull'andamento della procedura. Ti saremmo davvero grati se potessi dedicare qualche minuto alla compilazione, in modo da sapere cosa è andato bene e quali sono le difficoltà per migliorare questi aspetti.

Ogni modulo di feedback viene esaminato manualmente dal team Customer Experience e restituisce le azioni corrispondenti per migliorare l'esperienza futura. Il punteggio sarà su 5. Un punteggio pari o inferiore a 3 sarebbe considerato stressante dal lato del cliente, quindi ti contatteremo in merito a queste risposte. Inoltre, un punteggio pari a 4 o superiore indica che l'interazione è stata facile (facile) per il cliente e pertanto è considerata un'esperienza positiva.

Per ulteriori informazioni, consulta la pagina su come inviare feedback sui servizi GCP con il CES.

Problemi di lunga durata o difficili

I problemi la cui risoluzione richiede molto tempo possono confondersi. Il modo migliore per evitare questo problema è raccogliere informazioni utilizzando il nostro modello di problema a lunga esecuzione con l'ultimo stato riassunto all'inizio.

Per utilizzare il modello, è sufficiente aprire il link riportato sopra e creare una copia. Includi link a tutti i casi pertinenti e ai bug di monitoraggio interni. Condividi questo documento con il gruppo del tuo team dedicato al tuo account e chiedi di condividerlo con tecnici dell'assistenza specifici.

Questo documento include:

  • Un riepilogo dello stato corrente all'inizio dell'elenco.
  • Un elenco di ipotesi potenzialmente vere.
  • I test o gli strumenti che intendi utilizzare per verificare ogni ipotesi.

Fai in modo che ogni richiesta sia incentrata su un singolo problema ed evita di riaprirla per avviare una nuova richiesta.

Segnalazione di un'interruzione della produzione

Se il problema ha causato l'interruzione della pubblicazione dell'applicazione per il traffico degli utenti o se ha un impatto business-critical simile, potrebbe esserci un'interruzione del processo di produzione. Vogliamo saperlo il prima possibile. I problemi che bloccano un piccolo numero di sviluppatori, per contrasto, non sono ciò che noi consideriamo interruzioni di produzione.

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

  • Controllo immediato della presenza di problemi noti che interessano l'infrastruttura GCP.
  • Conferma della natura del problema.
  • Stabilire canali di comunicazione.

Puoi aspettarti una risposta con un breve messaggio contenente:

  • Eventuali problemi noti correlati che riguardano più clienti.
  • Conferma che possiamo osservare il problema che hai segnalato o di aver bisogno di ulteriori dettagli.
  • Il modo in cui intendiamo comunicare.

Pertanto, è importante creare rapidamente una richiesta includendo ora, prodotto, identificatori e località, quindi avviare una risoluzione dei problemi più approfondita. La tua organizzazione potrebbe avere un processo di gestione degli incidenti definito e questo passaggio deve essere eseguito molto vicino all'inizio.

Il processo di gestione degli incidenti di Google definisce un ruolo chiave: il comandante dell'incidente. Questa persona si rivolge alle persone giuste, raccoglie continuamente lo stato più recente e riepiloga periodicamente lo stato del problema. Delegano ad altri utenti per risolvere i problemi e applicare modifiche. Questa delega ci consente di esaminare più ipotesi in parallelo. Ti consigliamo di stabilire una procedura simile nella tua organizzazione. La persona che ha aperto la richiesta è in genere la scelta migliore per essere il comandante dell'incidente perché ha il massimo contesto.

Segnalazione di un problema di rete

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

I diagrammi di flusso dei pacchetti offrono una struttura eccellente per il report sui problemi. Questi grafici descrivono gli hop importanti che un pacchetto intraprende lungo un percorso da origine a destinazione, insieme ad eventuali trasformazioni significative lungo il percorso.

Per iniziare, identifica gli endpoint di rete interessati mediante l'indirizzo IP Internet o 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 è significativo sugli endpoint, ad esempio:

  • Chi li controlla.
  • Indica se sono associati a un nome host DNS.
  • Qualsiasi incapsulamento e/o indiretto intermedi, 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 del percorso e/o un'acquisizione di pacchetti per la diagnosi.

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

Esempi di richieste

Esempio 1

Nome job:

A_ATL_BIG1toBQ_big_04)201704202

00045_491

Fonte:

S3_avl-transfer

Destinazione:

Cloud Storage: trasferimento avl

Ora di inizio (formato ISO 8601): 20-04-2017 20:14:43 PDT

Ora di fine (formato ISO 8601): 21-04-2017 alle 10:03:44 PDT

Ho iniziato un trasferimento di file il 20-04-2017 alle 20:14:43 PDT utilizzando l'API di trasferimento. Il completamento del job normalmente richiede 10 minuti, ma in questo caso il job era ancora in esecuzione quando l'ho annullato il giorno successivo (21-04-2017 alle 10:03:44 PDT). Non si tratta di un evento isolato; molti altri job che riguardano l'API Transfer hanno avuto ritardi intermittenti e significativi.

Esaminare la causa dei ritardi e suggerire eventuali best practice che possiamo implementare per evitare questi problemi in futuro.

Esempio 2

Ora di inizio (formato ISO 8601): 12-05-2017 alle 11:03:43

Ora di fine (formato ISO 8601): il problema si verifica ancora al momento di questo report.

Riepilogo dei problemi:

La cron /cron/payments-service/sync-v2-batch che utilizza l'API App Engine Task Queue non viene più eseguita dalle 11:03:43 del 12/05/2017. Ci affidiamo a questo lavoro per la corretta gestione dei pagamenti.

Sono stati rilevati errori del datastore e della coda, quindi la cron si è interrotta. Abbiamo tentato di risolvere il problema senza riuscire a caricare nuovamente il file cron.xml. Ecco la traccia dell'errore:

[error trace]

Indica se il problema riguarda l'API o la nostra implementazione e comunicaci i passaggi successivi.