Questa pagina è stata tradotta dall'API Cloud Translation.

Best practice per collaborare con l'assistenza clienti

Questa guida fornisce le best practice per scrivere un'assistenza efficace per verificare se è così. Seguire queste best practice ci consente di risolvere il problema della tua assistenza tecnica più velocemente.

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. Eventuali richieste duplicate create vengono chiuse.

Descrivi il problema

Scrivere una richiesta di assistenza dettagliata semplifica l'assistenza clienti il nostro team per rispondere 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 nel tuo 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 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 seguenti sezioni descrivono questi concetti in modo più dettagliato.

Ora

Utilizzando il formato ISO 8601 la data e l'ora, facci sapere quando hai notato il problema per la prima volta e a lungo.

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 risolva il problema non il tuo fuso orario, quindi affermazioni relative come la seguente rendono il problema più difficile per diagnosticare:

"È iniziato ieri..." (ci obbliga a dedurre la data implicita).
"Abbiamo notato il problema il 9/8…" (la risposta è ambigua, perché alcuni potrebbero interpretarla la data dell'8 settembre, che per altri potrebbe essere interpretata come 9 agosto).

Prodotto

Anche se il modulo di richiesta di base richiede di specificare il nome di un prodotto, informazioni specifiche sulla funzionalità del prodotto che presenta 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.

Comunicaci anche il meccanismo che stai utilizzando per avviare la richiesta (ad ad esempio API REST, Google Cloud CLI, console Google Cloud o magari uno strumento come con Cloud Deployment Manager. Se sono coinvolti più prodotti, indicali ciascuno del nostro nome.

Esempi:

"L'API REST Compute Engine ha restituito gli errori seguenti..."
"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 stai utilizzando per creare istanze).
"Il comando gcloud compute create instances restituisce un errore..."( la sintassi del comando non è corretta, quindi non possiamo eseguirla noi stessi per riprodurre . Inoltre, non sappiamo quale errore hai effettivamente visualizzato.

Località

Dobbiamo conoscere la regione e la zona del tuo data center perché spesso implementiamo modifiche a una regione o 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 sapere se le modifiche che provocano un errore in una particolare versione del software interessano il tuo sistemi operativi.

Esempi:

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

Identificatori

Gli identificatori specifici ci aiutano a identificare quale dei tuoi progetti Cloud è che stai 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 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…"
"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 riscontrando.

Ad esempio:

Utilizza uno screenshot per mostrare esattamente ciò che vedi.
Per le interfacce basate sul web, fornisci un'immagine .HAR (HTP) ARchive). L'HAR analizzatore sintattico ha istruzioni per i tre principali browser.
Allega l'output di tcpdump, snippet dei log, tracce dello stack di esempio.

Tipo di problema

Intermittenza: si verificano problemi intermittenti in modo casuale e non schemi di errore. 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 hai problemi che si verificano solo per un secondo o qualche secondo microsecondi, puoi verificare la presenza di micro burst di traffico o di picchi di risorse agli utenti. 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 i picchi di latenza di rete si verificano solo per pochi microsecondi e le piccole perdite di pacchetti che timeout. Il protocollo TCP (Transmission Control Protocol) è progettato per gestire errori come piccole perdite 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, illustraci i passaggi per riprodurre il problema in modo che gli specialisti dell'assistenza clienti possano di replicare l'ambiente e risolvere il problema al posto tuo.

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 consente di capire l'impatto che questo problema sta avendo sulla tua attività e incide sulla velocità con cui rispondiamo per risolvere il problema. Le priorità sono definite nella tabella seguente. Puoi trovare ulteriori informazioni in Richieste di assistenza. la priorità.

Definizione della priorità	Situazione di esempio
P1 - Impatto critico: servizio inutilizzabile in produzione	L'applicazione o l'infrastruttura è inutilizzabile in produzione, a causa del 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	Le prestazioni dell'infrastruttura sono ridotte, con un tasso notevole di errori riscontrati dagli utenti o difficoltà nell'avviare un nuovo sistema di produzione. L'impatto sull'attività è moderato (pericolo di perdita delle entrate, una diminuzione della produttività e così via).
P3: impatto medio: utilizzo del servizio parzialmente compromesso	Il problema è limitato in termini di ambito e/o gravità. 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 economico o tecnico minimo o nullo. Consigliato per ticket 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 hai un problema che interessa servizi ed esigenze aziendali critici attenzione immediata da parte di Google, scegli "P1" come priorità. Spiegaci nel nel dettaglio perché hai selezionato P1. Includi una breve descrizione dell'impatto che questo problema sta avendo sulla tua attività. Ad esempio, potresti considerare un problema con un sia 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 immediatamente avvisato del fatto che lavora in modo esclusivo per ulteriore assistenza sul problema. Ricevi una rapida risposta iniziale per partecipare a una live risolvere i problemi di chiamata 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 altra ponte da te fornito. Ci aspettiamo che tu partecipi alla chiamata entro 15-30 minuti. Comunica all'esperto dell'assistenza se non riesci a partecipare alla chiamata per qualsiasi motivo.
- La richiesta "Follows the Sun" per impostazione predefinita. Ciò significa che gli esperti dell'assistenza sono coinvolti 24 ore al giorno finché la richiesta non viene 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 priorità P1
- Se il problema ha iniziato a influire sul tuo ambiente di produzione o puoi aumentare la priorità di una richiesta P2 - P4 esistente impostandola su P1.
- Quando aumenti la priorità di una richiesta esistente a P1, la richiesta di assistenza possono essere riassegnate per consentire a un esperto dell'assistenza disponibile di fornire immediatamente di attenzione.
Impatto non produttivo

Al fine di garantire che siano allocate risorse appropriate, ove necessario, il sostegno può interagire con te per rivalutare i casi contrassegnati come P1 che non hanno alcun impatto o causare un impatto elevato sul business.

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 una risposta entro un orario specifico, faccelo sapere nella descrizione della segnalazione. Se un P1 problema deve essere gestito in modo continuo, puoi chiedere "segui le "Sole". Questi vengono riassegnate più volte al giorno a un servizio di assistenza clienti attivo specialista. 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 un P2 fino a quando non decidi di coinvolgere nuovamente il team.

Riassegnazione

Quando le circostanze cambiano, potrebbe essere necessario riassegnarlo. Motivi positivi per la riassegnazione sono:

Aumento dell'impatto sul business.
Suddivisione del processo di risoluzione. Ad esempio, non hai ricevuto aggiornalo entro il periodo di tempo concordato o il problema risulta "bloccato" senza l'avanzamento 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 situazione rapidamente l'escalation poco dopo la modifica della priorità potrebbe persino causare essere più lento. Puoi trovare una spiegazione più dettagliata nel video Quando riassegnare la richiesta.

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

Indirizza le richieste al fuso orario richiesto

A causa dei fattori su cui si basa l'assistenza clienti la disponibilità del servizio si basa, richiesta di assistenza può essere assegnata a uno specialista dell'assistenza clienti che lavora al di fuori del tuo orario di lavoro. È anche possibile che tu voglia contattare l'assistenza clienti durante i giorni lavorativi di un fuso orario specifico. Nella in questi casi, consigliamo di richiedere all'assistenza clienti di indirizzare di assistenza in un fuso orario più comodo per la tua richiesta. Puoi aggiungere questo nella descrizione o nella risposta. 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, invia un sondaggio sul Customer Effort Score (CES) relativo alla tua ricevere un'opinione su com'è andata la procedura. Avremmo davvero bisogno se puoi dedicare qualche minuto a compilarlo, così sapremo 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 azioni corrispondenti per migliorare la tua esperienza futura. Il punteggio sarà su 5. Un punteggio pari o inferiore a 3 sarebbe considerato difficile da lato cliente. D'altra parte, un punteggio pari o superiore a 4 indica che l'interazione non è stata difficile per il cliente e che è stata considerata un'esperienza positiva.

Per ulteriori informazioni, consulta la sezione Come inviare feedback sui servizi Google Cloud con CES.

Problemi di lunga data o difficili

I problemi che richiedono molto tempo per essere risolti possono diventare confusi e obsoleti. Il meglio per evitare che ciò accada è raccogliere informazioni utilizzando il nostro problema di lunga durata modello con lo stato più recente riassunto 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 del tuo account e chiedi di condividerlo con specialisti dell'assistenza clienti specifici.

Questo documento comprende:

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

Cerca di concentrare ogni richiesta su un singolo problema ed evita di riaprirla per segnalarne uno nuovo.

Segnalazione di un'interruzione di produzione

Se il problema ha causato l'interruzione della gestione del traffico per gli utenti da parte della tua applicazione oppure ha un impatto business-critical simile, potrebbe trattarsi di un'interruzione della produzione. Vogliamo di informazioni al più presto. I problemi che bloccano un numero ridotto di sviluppatori, invece, non sono considerati interruzioni della produzione.

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

Controllare immediatamente la 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 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.
Il modo in cui 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.

Il processo di gestione degli incidenti di Google definisce un ruolo chiave: l'Incident Commander. Questa persona coinvolga le persone giuste, raccoglie continuamente e riassumere periodicamente lo stato del problema. Delegano a altri per risolvere i problemi e applicare le modifiche. Questa delega ci consente analizza più ipotesi in parallelo. Ti consigliamo di stabilire un processo 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 Google possono rendere difficile l'identificazione quale 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 sui problemi. 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 in base all'indirizzo IP internet o 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.
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 richiedono l'analisi dei percorsi, l'acquisizione dei pacchetti o entrambe le operazioni per la diagnosi.

L'analisi dei percorsi è un elenco di tutti gli hop seguiti dai pacchetti. noto come "traceroute". Spesso utilizziamo MTR o tcptraceroute, o entrambi, perché hanno una maggiore capacità di diagnostica. Ti consigliamo di acquisire familiarità con questi strumenti.
Acquisizione pacchetto (nota anche come "pcap", dal nome della libreria) "libpcap") indica 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 averne bisogno.