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 per consentirci di monitorare la tua richiesta in un unico punto, crea una richiesta di assistenza per ogni problema. Le richieste duplicate create vengono chiuse.

Descrizione del problema

Scrivere una richiesta di assistenza dettagliata consente al team dell'assistenza clienti di risponderti in modo rapido ed efficiente. Quando nella richiesta di assistenza mancano dettagli importanti, dobbiamo chiederti ulteriori informazioni, il che richiede tempo aggiuntivo.

Le migliori richieste di assistenza sono dettagliate e specifiche. Ci dicono cosa è successo e cosa ti aspettavi che succedesse. Quando descrivi il problema nella 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 o l'ID applicazione e altri identificatori concreti che ci aiutano a esaminare il problema.
  • Elementi utili:tutti i dettagli che puoi fornire per aiutarci a diagnosticare il problema.
  • Tipo di problema: il problema è intermittente, transitorio o costante.

Le sezioni seguenti descrivono questi concetti in maggiore dettaglio.

Ora

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

Esempi:

  • A partire dal giorno 08-09-2017T15:13:06+00:00 e terminando 5 minuti dopo, abbiamo osservato…
  • Osservato a intermittenza, a partire dal giorno 10-09-2017 e osservato 2-5 volte...
  • In corso dal 08-09-2017T15: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 risolve il problema non si trovi nel tuo fuso orario, pertanto affermazioni relative come quelle riportate di seguito rendono più difficile la diagnosi del problema:

  • "Il problema si è verificato ieri..." (Ci costringe a dedurre la data implicita).
  • "Abbiamo notato il problema l'8/9…" (Ambigua, in quanto alcuni potrebbero interpretare questa data come 8 settembre, mentre altri come 9 agosto).

Prodotto

Anche se il modulo della richiesta di base ti chiede di specificare il nome di un prodotto, abbiamo bisogno di informazioni specifiche sulla funzionalità del prodotto in cui si verifica il problema. Idealmente, il report farà riferimento ad API specifiche o a URL (o screenshot) della console Google Cloud . 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 utilizzi per avviare la richiesta (ad esempio API REST, Google Cloud CLI, console Google Cloud o forse uno strumento come Cloud Deployment Manager. Se sono coinvolti più prodotti, fornisci il nome specifico di ciascuno.

Esempi:

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

Le seguenti affermazioni non sono abbastanza specifiche per sapere dove cercare quando si diagnostica il problema:

  • "Impossibile creare istanze…" (Dobbiamo sapere il metodo che utilizzi per creare le istanze).
  • "Il comando gcloud compute create instances genera un errore…"(la sintassi del comando non è corretta, quindi non possiamo eseguirlo autonomamente per riprodurre l'errore. Inoltre, non sappiamo quale errore hai effettivamente visualizzato.

Località

Abbiamo bisogno di conoscere la regione e la zona del tuo data center perché spesso implementiamo le modifiche in una regione o una zona alla volta. La regione e la zona sono un proxy per il numero di versione del software di base. Queste informazioni ci aiutano a capire se le modifiche in una determinata versione del nostro software stanno interessando i tuoi sistemi.

Esempi:

  • "In us-east1-b …"
  • "Ho provato le regioni us-east1 e us-central1…"

Identificatori

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

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

  • ID istanza.
  • ID job o nomi di tabelle BigQuery.
  • mediante i loro indirizzi IP interni. Il peering di rete VPC è un approccio

Quando specifichi un indirizzo IP, indicaci anche il contesto in cui viene utilizzato. Ad esempio, specifica se l'IP è collegato a un'istanza Compute, a un bilanciatore del carico, a un percorso personalizzato o a un endpoint API. Comunicaci anche se l'indirizzo IP non è correlato ai sistemi di Google (ad esempio, se si tratta dell'indirizzo IP della tua rete internet di casa, di un endpoint VPN o di 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 quelle che seguono sono troppo generiche per aiutarci a diagnosticare il problema:

  • "Una delle nostre istanze non è raggiungibile…"
  • "Non riusciamo a connetterci da internet…"

Artefatti utili

Forniscici gli elementi correlati al problema per velocizzare la risoluzione dei problemi aiutandoci a vedere esattamente cosa stai vedendo.

Ad esempio:

  • Utilizza uno screenshot per mostrare esattamente ciò che vedi.
  • Per le interfacce basate sul web, fornisci un file.HAR (ARchivettp). Lo strumento di analisi HAR contiene istruzioni per tre dei principali browser.
  • Allega l'output di tcpdump, snippet dei log, tracce dello stack di esempio.

Tipo di problema

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

  • Transitori: i problemi transitori sono momentanei o esistono solo per un breve periodo di tempo. Se si verificano problemi che durano solo per un secondo o per alcuni microsecondi, puoi verificare la presenza di micro picchi di traffico o di picchi di utilizzo delle risorse. Nella maggior parte dei casi, i problemi temporanei possono essere ignorati se non si ripetono spesso e se il servizio è progettato per essere tollerante nei confronti di errori temporanei. Esempi di questo tipo di errore sono picchi di latenza della rete che si verificano solo per alcuni microsecondi e piccole perdite di pacchetti che causano timeout. Il protocollo TCP (Transmission Control Protocol) è progettato per gestire errori come piccole perdita di pacchetti e picchi di latenza e può gestire questi problemi in modo efficace, a meno che la tua applicazione non sia sensibile alla latenza.

  • Costanti: i problemi costanti sono quelli che non vanno a buon fine, ad esempio quando il tuo sito web è offline. I problemi coerenti sono relativamente facili da risolvere perché possono essere riprodotti. In questo caso, indicaci i passaggi per riprodurre il problema in modo che i nostri esperti dell'assistenza clienti possano replicare l'ambiente e risolvere il problema per te.

Descrizioni di esempio

Esempio 1

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 2

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 capire l'impatto di questo problema sulla tua attività e influisce sulla rapidità con cui rispondiamo per risolverlo. Le priorità sono definite nella tabella seguente. Puoi trovare ulteriori informazioni nella pagina Priorità della richiesta di assistenza.

Definizione della priorità Situazione di esempio
P1 - Impatto critico: servizio inutilizzabile in ambiente di produzione L'applicazione o l'infrastruttura non è utilizzabile in produzione, con un tasso significativo di errori per gli utenti. L'impatto sull'attività è critico (perdita di entrate, potenziale problema di integrità dei dati e così via).
P2: Impatto elevato: utilizzo del servizio gravemente compromesso L'infrastruttura è in degrado in produzione, con un tasso significativo di errori rivolti agli utenti o difficoltà nell'avvio di un nuovo sistema di produzione. L'impatto sull'attività è moderato (pericolo di perdita di entrate, calo 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 un impatto visibile per gli utenti. L'impatto sull'attività è basso (ad esempio, disagio o procedimenti aziendali minori interessati).
P4: Impatto basso: servizio completamente utilizzabile Impatto tecnico o aziendale ridotto o nullo. Consigliato per richieste di consulenza in cui sono preferite analisi approfondite, risoluzione dei problemi o consulenza rispetto a comunicazioni più frequenti.

Quando impostare la priorità più alta

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

Quando una richiesta viene impostata come P1, un esperto viene avvisato immediatamente per lavorare esclusivamente sul problema. Riceverai una risposta iniziale rapida per partecipare a una chiamata di risoluzione dei problemi in tempo reale tramite Google Meet. Se la tua organizzazione non può utilizzare Google Meet, includi un link al software di videoconferenza di tua scelta per consentire all'esperto di partecipare. Dopodiché riceverai aggiornamenti regolari tramite la richiesta.

Apprezziamo i commenti dettagliati a supporto del livello di priorità scelto perché ci aiutano a rispondere in modo appropriato.

Cosa aspettarsi dall'assistenza per le richieste P1

  • Nuova richiesta P1

    • Un esperto dell'assistenza ti contatterà tramite Google Meet o qualsiasi altro ponte che fornisci. Ti aspettiamo entro 15-30 minuti. Comunica all'esperto dell'assistenza se non riesci a partecipare alla chiamata per qualsiasi motivo.
    • Per impostazione predefinita, la cover "segue il sole". Ciò significa che gli esperti dell'assistenza sono disponibili 24 ore su 24 finché la richiesta non viene attenuata o depriorizzata. Se la mitigazione della richiesta è preferibile in una regione specifica, la richiesta può essere bloccata su un determinato fuso orario. Puoi comunicarci la tua preferenza in merito a questo effetto.

  • Aumento della priorità P1

    • Se il problema ha iniziato a interessare il tuo ambiente di produzione o sta per farlo, puoi aumentare la priorità di una richiesta P2-P4 esistente a P1.
    • Quando aumenti la priorità di una richiesta esistente a P1, la richiesta di assistenza potrebbe essere riassegnata per consentire a un esperto dell'assistenza disponibile di fornire immediata attenzione.

  • Impatto non produttivo

    Per garantire l'allocazione delle risorse appropriate dove necessario, l'assistenza potrebbe contattarti per rivalutare le richieste contrassegnate come P1 che non influiscono sulla produzione o che hanno un impatto elevato sull'attività.

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'ora specifica, comunicacelo nella descrizione della segnalazione. Se un problema P1 deve essere gestito 24 ore su 24, puoi richiedere il servizio "follow the sun". Queste richieste vengono riassegnate più volte al giorno a un esperto dell'assistenza clienti attivo. Mentre risolviamo la tua richiesta P1, ti consigliamo di rimanere coinvolto per rispondere alle domande fino alla risoluzione per facilitare una comunicazione efficiente. Se non rispondi per più di 3 ore, potremmo ridurre la priorità della richiesta a P2 finché non ti ricontatteremo.

Riassegnazione

Quando le circostanze cambiano, potrebbe essere necessario riassegnarlo. Ecco alcuni buoni motivi per la riassegnazione:

  • Aumento dell'impatto sul business.
  • Analisi dettagliata della procedura di risoluzione. Ad esempio, non hai ricevuto un update nel periodo di tempo concordato o il problema è "bloccato" senza progressi dopo lo scambio di diversi messaggi.

Quando si verifica un problema ad alto impatto, la soluzione migliore è impostare la richiesta sulla priorità appropriata per un periodo di tempo adeguato, anziché eseguire la riassegnazione. La riassegnazione non risolve necessariamente la richiesta più velocemente e la riassegnazione poco dopo la modifica della priorità potrebbe persino causare una risoluzione più lenta della richiesta. Puoi trovare una spiegazione più dettagliata nel video Quando riassegnare la richiesta.

Per informazioni su come riassegnarla, vedi 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 un esperto dell'assistenza clienti che lavora al di fuori del tuo orario di apertura. È anche possibile che tu voglia contattare l'assistenza clienti durante i giorni lavorativi di un fuso orario specifico. In questi casi, ti consigliamo di chiedere all'assistenza clienti di inoltrare la richiesta di assistenza a un fuso orario comodo per te. 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é seguono il sole, mentre le altre rimangono con l'attuale proprietario della richiesta per continuare a lavorarci il giorno successivo.

Fornire un feedback con il sondaggio CES

Quando una richiesta viene risolta, ti invieremo via email un sondaggio CES (Customer Effort Score) per conoscere la tua opinione sulla procedura. Ti saremmo davvero grati se potessi dedicare qualche minuto alla compilazione di questo modulo, per consentirci di sapere cosa abbiamo fatto bene e quali sono state le difficoltà per migliorare questi aspetti.

Ogni modulo di feedback viene esaminato manualmente dal team Customer Experience e porta a azioni corrispondenti per migliorare la tua esperienza futura. Il punteggio sarà su una scala da 1 a 5. Un punteggio pari o inferiore a 3 è considerato difficile dal punto di vista del cliente. D'altra parte, un punteggio pari o superiore a 4 indica che l'interazione non è stata difficile per il cliente ed è stata considerata un'esperienza positiva.

Per saperne di più, guarda il video Come inviare feedback sui servizi Google Cloud con CES.

Problemi complessi o che richiedono molto tempo

I problemi che richiedono molto tempo per essere risolti possono diventare confusi e obsoleti. Il modo migliore per evitarlo è raccogliere le informazioni utilizzando il nostro modello per i problemi che richiedono molto tempo con lo stato più recente riassunto in alto.

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

Questo documento include:

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

Cerca di limitare ogni richiesta a un singolo problema ed evita di riaprirla per segnalarne un altro.

Segnalazione di un'interruzione della produzione

Se il problema ha causato l'interruzione del traffico inviato agli utenti o ha un impatto simile per l'attività, potrebbe trattarsi di un'interruzione della produzione. Vogliamo اطلاع دارnel più breve tempo possibile. I problemi che bloccano un numero ridotto di sviluppatori, invece, non sono considerati interruzioni della produzione.

Quando riceviamo una segnalazione di un'interruzione della produzione, valutiamo rapidamente la situazione:

  • Controllare immediatamente la 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 contenente:

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

Pertanto, è importante creare rapidamente una richiesta che includa ora, prodotto, identificativi e posizione, per poi iniziare la risoluzione dei problemi più approfondita. La tua organizzazione potrebbe avere una procedura di gestione degli incidenti definita e questo passaggio dovrebbe essere eseguito all'inizio.

La procedura di gestione degli incidenti di Google definisce un ruolo chiave: l'incident commander. Questa persona coinvolge le persone giuste, raccoglie continuamente l'ultimo stato e riassume periodicamente lo stato del problema. Delegano ad altri la risoluzione dei problemi e l'applicazione delle modifiche. Questa delega ci consente di esaminare più ipotesi in parallelo. Ti consigliamo di stabilire un procedimento simile all'interno della tua organizzazione. La persona che ha aperto la richiesta è solitamente la scelta migliore per il ruolo di comandante dell'incidente perché ha il contesto più completo.

Segnalazione di un problema di rete

Le dimensioni e la complessità della rete di Google possono rendere difficile identificare il team responsabile del problema. Per diagnosticare i problemi di rete, dobbiamo identificare cause di fondo 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 possibili ipotesi.

I diagrammi di flusso dei pacchetti forniscono una struttura eccellente per il report del problema. Questi diagrammi descrivono i hop importanti che un pacchetto percorre lungo un percorso dalla sorgente alla destinazione, nonché eventuali trasformazioni significative lungo il percorso.

Inizia identificando gli endpoint di rete interessati dall'indirizzo IP di internet o dall'indirizzo privato RFC 1918, oltre a 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 qualsiasi informazione significativa sugli endpoint, ad esempio:

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

Molti problemi che si manifestano con latenza elevata o perdita di pacchetti intermittente richiedono per la diagnosi un'analisi del percorso o un'acquisizione di pacchetti o entrambe.

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