Questa pagina è stata tradotta dall'API Cloud Translation.

Best practice per collaborare con l'assistenza clienti

Questa guida fornisce le best practice per scrivere una richiesta di assistenza efficace. L'applicazione di queste best practice ci consente di 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 vedere se è già stata presentata una richiesta.

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.

Descrivi il problema

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

Le migliori richieste di assistenza sono dettagliate e 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 è iniziato il problema.
Prodotto: i prodotti e le funzionalità associati al problema.
Posizione:le zone in cui riscontri il problema.
Identificatori: l'ID progetto o l'ID applicazione e altri identificatori concreti che ci aiutano a effettuare ricerche sul problema.
Artefatti utili:tutti i dettagli che puoi fornire per aiutarci a diagnosticare il problema.
Tipo di problema:il problema è intermittente, transitorio o costante.

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 quanto è durato.

Esempi:

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

Molto probabilmente l'esperto dell'assistenza clienti che risolve il problema non si trova nel tuo fuso orario, quindi frasi relative come la seguente rendono il problema più difficile da diagnosticare:

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

Prodotto

Anche se il modulo di richiesta di base richiede di specificare il nome di un prodotto, abbiamo bisogno di informazioni specifiche sulla funzionalità del prodotto che sta causando il problema. Idealmente, il report farà riferimento ad API specifiche o a URL (o screenshot) della console Google Cloud. Per le API, puoi collegarti alla pagina della documentazione, che contiene il nome del prodotto nell'URL.

Indica 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 ogni nome specifico.

Esempi:

"L'API REST di Compute Engine ha restituito gli errori seguenti..."
"L'interfaccia di query di BigQuery in console.cloud.google.com si blocca..."

Le seguenti affermazioni non sono abbastanza specifiche per capire dove cercare la diagnosi del problema:

"Impossibile creare istanze..." (dobbiamo conoscere il metodo utilizzato per creare le istanze).
"Il comando gcloud compute create instances restituisce un errore..."(La sintassi del comando non è corretta, quindi non possiamo eseguirla per riprodurre l'errore. Inoltre, non sappiamo quale errore hai effettivamente riscontrato.

Località

Dobbiamo conoscere la regione e la zona del tuo data center perché spesso apportiamo modifiche a una regione 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 l'interruzione di modifiche in una determinata versione del software interessa 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 presentano il problema. Dobbiamo sempre conoscere il progetto o l'ID 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 il tuo caso:

ID istanza.
ID job o nomi 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 è connesso a un'istanza Compute, un bilanciatore del carico, una route personalizzata o un endpoint API. Indica inoltre se l'indirizzo IP non è correlato ai sistemi di Google (ad esempio, se l'indirizzo IP è relativo a internet di casa, a un endpoint VPN o a 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 di Google Cloud 218.239.8.9 dal nostro gateway aziendale 56.56.56.56..."

Affermazioni generiche come quelle che seguono sono troppo generiche per aiutare a diagnosticare il problema:

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

Artefatti utili

Fornendoci gli elementi relativi al problema velocizzerai 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 fornisce istruzioni per i tre principali browser.
Collega output tcpdump, snippet di log e analisi dello stack di esempio.

Tipo di problema

Intermittenza: i problemi intermittenti si verificano in modo casuale e non presentano schemi di errore regolari. I problemi intermittenti sono difficili da risolvere perché la loro irregolarità rende difficile la raccolta dei dati durante l'errore. In questo caso, dovresti provare a identificare i colli di bottiglia nell'architettura e verificare se le tue risorse raggiungono la soglia massima di utilizzo. Puoi anche eseguire controlli frequenti in un job pianificato utilizzando l'automazione e, se il controllo non va a buon fine, raccogliere le 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 i problemi si verificano solo per un secondo o per 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 in modo da 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 le piccole perdite di pacchetti che causano timeout. Il protocollo TCP (Transmission Control Protocol) è progettato per risolvere errori come piccoli picchi di perdita di pacchetti e latenza ed è in grado di gestire questi problemi in modo efficace, a meno che l'applicazione non sia sensibile alla latenza.
Coerenza: i problemi ricorrenti sono problemi che non risolvono completamente, ad esempio quando il tuo sito web non è attivo. I problemi costanti sono relativamente semplici da risolvere perché possono essere riprodotti. In questo caso, indica i passaggi per riprodurre il problema in modo che gli esperti dell'assistenza clienti possano replicare l'ambiente e risolvere il problema 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.

Impostare la priorità e riassegnazione

La priorità ci consente di capire l'impatto che questo problema sta avendo sulla tua attività e la velocità con cui rispondiamo per risolverlo. Le priorità sono definite nella tabella seguente. Puoi trovare ulteriori informazioni in 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 e ha un tasso significativo 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 del servizio gravemente compromesso	Le prestazioni dell'infrastruttura sono deteriorate in fase di produzione, poiché presentano un tasso notevole di errori riscontrati dagli utenti o di difficoltà nell'avvio di un nuovo sistema di produzione. L'impatto sul business è moderato (pericolo di perdita delle entrate, diminuzione della produttività e così via).
P3: impatto medio: utilizzo del servizio parzialmente compromesso	Il problema è limitato nell'ambito e/o nella gravità. Il problema non ha alcun impatto visibile all'utente. L'impatto sull'attività è basso (ad esempio, disagi o processi aziendali di minore entità interessati).
P4 - Impatto basso: servizio completamente utilizzabile	Impatto economico o tecnico minimo o nullo. Consigliato per le richieste di consulenza in cui l'analisi approfondita, la risoluzione dei problemi o la consulenza sono preferibili a comunicazioni più frequenti.

Quando impostare la priorità più alta

Se si verifica un problema che interessa servizi fondamentali per l'attività e richiede attenzione immediata da parte di Google, scegli "P1" come priorità. Spiegaci dettagliatamente perché hai scelto P1. Includi una breve descrizione dell'impatto che questo problema ha sulla tua attività. Ad esempio, se la versione dev è bloccata, il problema di una versione dev potrebbe essere P1, anche se nessun utente finale è direttamente interessato, se blocca una correzione di sicurezza critica.

Quando una richiesta viene impostata come P1, un esperto viene immediatamente avvisato che si occupa esclusivamente del problema. Riceverai una rapida risposta iniziale per partecipare a una chiamata in tempo reale per la risoluzione dei problemi tramite Google Meet. Se la tua organizzazione non può utilizzare Google Meet, includi un link al software per videoconferenze che preferisci per la partecipazione dell'esperto. In seguito, 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 da te fornito. Dovresti partecipare alla chiamata entro 15-30 minuti. Informa l'esperto dell'assistenza se per qualche motivo non puoi partecipare alla chiamata.
- Per impostazione predefinita, la richiesta è "Follows the Sun". Ciò significa che gli esperti dell'assistenza interagiscono 24 ore al giorno finché la richiesta non viene mitigata o ridotta. Se è meglio perseguire la mitigazione delle richieste in una regione specifica, questa può essere bloccata a un determinato fuso orario. Puoi comunicarci la tua preferenza in merito a questo effetto.
Aumento priorità P1
- Se il problema ha iniziato a influire sul tuo ambiente di produzione o lo sta per raggiungere, 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 può essere riassegnata per consentire a un esperto dell'assistenza disponibile di prestare attenzione immediata.
Impatto non di produzione

Per garantire che le risorse appropriate vengano allocate quando necessario, l'assistenza può coinvolgerti per rivalutare i casi contrassegnati come P1 che non influiscono sulla produzione o non causano 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 vuoi ricevere una risposta entro un periodo di tempo specifico, faccelo sapere 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. Durante la risoluzione dei problemi relativi alla tua richiesta P1, ti consigliamo di continuare a rispondere alle domande fino alla risoluzione, in modo da facilitare una comunicazione efficiente. Se non rispondi più di tre ore, potremmo ridurre la priorità della richiesta a un livello P2 finché non lo ricontattassi.

Riassegnazione

Se le circostanze cambiano, potrebbe essere necessario riassegnare un problema. Ecco alcuni buoni motivi per riassegnare una richiesta:

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

Quando devi affrontare un problema di grande impatto, la soluzione migliore è impostare la richiesta sulla priorità appropriata per un periodo di tempo adeguato, anziché riassegnarla. L'escalation non risolve necessariamente la richiesta più rapidamente e riassegna poco dopo la modifica della priorità potrebbe persino rallentare la risoluzione della richiesta. Puoi trovare una spiegazione più dettagliata nel video Quando eseguire la riassegnazione.

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

Indirizza 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 del tuo orario di lavoro. In alternativa, potresti rivolgerti all'assistenza clienti nei giorni lavorativi 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 più comodo 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 P1 vengono trasferite all'assistenza clienti della regione successiva perché seguono la domenica, mentre le altre richieste rimarrebbero con l'attuale proprietario della richiesta, che continuerà a lavorare alla richiesta il giorno successivo.

Fornisci un feedback con il sondaggio CES

Quando una richiesta viene risolta, viene inviato via email un sondaggio sul Customer Effort Score (CES) relativo alla tua opinione su come si è svolto il processo. Ti saremmo molto grati se potessi dedicare qualche minuto a compilarlo, per consentirci di 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 genera le azioni corrispondenti per migliorare la tua esperienza futura. Il punteggio sarà da 5 a 5. Un punteggio pari o inferiore a 3 sarebbe considerato difficile dal punto di vista dei clienti. Ti ricontatteremo in merito a queste risposte. D'altra parte, un punteggio pari o superiore a 4 indica che l'interazione non è stata difficile per il cliente e viene considerata un'esperienza positiva.

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

Problemi di lunga data o difficili

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

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

Questo documento comprende:

Un riepilogo dello stato attuale riassunto in alto.
Un elenco delle ipotesi potenzialmente vere.
I test o gli strumenti che intendi utilizzare per verificare ogni ipotesi.

Cerca di fare in modo che ogni richiesta si concentri su un singolo problema ed evita di riaprirla per segnalare un nuovo problema.

Segnalazione di un'interruzione di produzione

Se il problema ha causato l'interruzione della fornitura del traffico agli utenti da parte dell'applicazione o ha un impatto simile critico per l'attività, potrebbe trattarsi di un'interruzione della produzione. Vogliamo aggiornarlo il prima possibile. I problemi che bloccano un numero ridotto di sviluppatori, per contrasto, non sono considerati interruzioni della produzione.

Quando riceviamo una segnalazione di interruzione della produzione, esaminiamo rapidamente la situazione in base a:

Controllo immediato della presenza di problemi noti che interessano l'infrastruttura 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.
Il modo in cui intendiamo comunicare.

Pertanto, è importante creare rapidamente una richiesta che includa 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, che deve essere eseguito poco prima dell'inizio.

Il processo di gestione degli incidenti di Google definisce un ruolo chiave: l'Incident Commander. Questa persona coinvolga 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 consente 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 essere l'Incident Commander, perché dispone del massimo contesto.

Segnalazione di un problema di rete

Le dimensioni e la complessità della rete Google possono rendere difficile l'identificazione del team responsabile del problema. Per diagnosticare i problemi di rete, dobbiamo identificare le cause principali. Poiché i messaggi di errore del networking sono spesso generici (come "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 sui problemi. Questi diagrammi descrivono gli hop importanti che un pacchetto prende lungo un percorso dall'origine alla destinazione, insieme a qualsiasi trasformazione significativa lungo il percorso.

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

Prendi nota di tutti gli aspetti significativi degli endpoint, ad esempio:

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

Molti problemi che si manifestano come alta latenza o perdita intermittente di pacchetti richiederanno un'analisi dei percorsi, un'acquisizione di pacchetti o entrambi per la diagnosi.

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 un potere diagnostico migliore. 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 pacchetti simultanei 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.