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 casi per capire se è già stata presentata.

Per evitare confusione e consentirci di monitorare la tua richiesta in un unico punto, creare una richiesta di assistenza per problema. Eventuali richieste duplicate che vengono create vengono chiuso.

Descrivi il problema

Scrivere una richiesta di assistenza dettagliata semplifica l'assistenza clienti il nostro team per rispondere in modo rapido ed efficiente. Se la tua richiesta di assistenza viene mancano dettagli critici, dobbiamo chiedere più informazioni, il che tempo aggiuntivo.

Le migliori richieste di assistenza sono dettagliate e specifiche. Ci dicono cosa è successo e cosa ti aspettavi che sarebbe successo. 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.
  • 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.

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 da 2017-09-08T15:13:06+00:00 e termina 5 minuti dopo, osservato...
  • Osservato a intermittenza, a partire non prima del 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 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 l'8/09..." (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 della console Google Cloud (oppure screenshot). 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 di BigQuery in console.cloud.google.com è impiccagione..."

Le seguenti affermazioni non sono abbastanza specifiche per capire dove guardare quando diagnosticare 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 riscontrato.

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 del software sottostante. 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 il progetto alfanumerico l'ID 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, diversi altri identificatori ci aiutano 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. Per esempio: puoi specificare se l'IP è connesso a un'istanza Compute, un bilanciatore del carico, una route personalizzata o un endpoint API. Indica anche se l'indirizzo IP non è in relazione ai sistemi Google (ad esempio, se l'indirizzo IP è relativo alla tua abitazione internet, un endpoint VPN o 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 dalla nostra gateway 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 velocizzeremo la risoluzione dei problemi aiutandoci a vedere esattamente quello che vedi tu.

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.
  • Collega output tcpdump, snippet di log e analisi 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 la raccolta dei dati durante l'errore. In questo caso, dovresti cercare di identificare i colli di bottiglia nell'architettura verifica se le tue risorse stanno raggiungendo la soglia massima di utilizzo. Tu puoi anche eseguire controlli frequenti in un job pianificato utilizzando l'automazione e, se non riesce, raccogli le informazioni di debug durante l'errore. Esempi gli errori di risoluzione DNS e la perdita di pacchetti.

  • Temporaneo: i problemi temporanei sono temporanei o esistono solo per un breve periodo. un periodo di tempo. Se hai problemi che si verificano solo per un secondo o qualche secondo microsecondi, puoi controllare 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 tollerare i cambiamenti errori. 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 gli errori come piccoli picchi di perdita di pacchetti e latenza e può gestire anche risolvere i problemi in modo efficace, a meno che l'applicazione non sia sensibile alla latenza.

  • Coerenza: i problemi coerenti sono problemi che non superano completamente, ad esempio ad esempio quando il sito web non è disponibile. Un problema ricorrente è relativamente facile risolvere i problemi 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.

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 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 una frequenza 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à ecc.).
P3: impatto medio: utilizzo del servizio parzialmente compromesso Il problema è limitato nell'ambito e/o nella gravità. Il problema non presenta visibile agli utenti. L'impatto sull'attività è basso (ad es. inconvenienti, o piccole procedure aziendali interessate).
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à. Spiegacelo in nel dettaglio perché hai selezionato P1. Includi una breve descrizione dell'impatto di questo problema che 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 per videoconferenze che preferisci per far partecipare l'esperto. In seguito, riceverai aggiornamenti regolari tramite per verificare se è così.

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 parteciperai alla chiamata entro le 15-30 minuti. Informa l'esperto dell'assistenza se non puoi partecipare alla chiamata perché.
    • 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 il caso mitigazione è meglio perseguire in una regione specifica, tale caso può essere bloccato 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 riguarda 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 di produzione

    Per garantire che siano assegnate risorse adeguate, 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 nella Linee guida per i servizi di assistenza tecnica della piattaforma 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 i problemi della tua richiesta P1, ti consigliamo di rimanere è impegnato a rispondere alle domande fino alla loro risoluzione la comunicazione. 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

Se le circostanze cambiano, potrebbe essere necessario riassegnare un problema. 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 riscontri un problema di grande impatto, la soluzione migliore è impostare il caso alla priorità appropriata per un periodo di tempo adeguato, invece che è in fase di riassegnazione. La riassegnazione non risolve necessariamente la situazione rapidamente l'escalation poco dopo la modifica della priorità potrebbe persino causare essere più lento. Per una spiegazione più dettagliata, consulta la sezione Quando dovresti riassegnare il video.

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 tua disponibilità 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 voglia interagire presso l'assistenza clienti nei giorni lavorativi di uno specifico fuso orario. 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 passate alla successiva dell'assistenza clienti in una determinata regione perché segue le sole mentre le altre richieste rimarrebbero presso l'attuale proprietario della richiesta, caso il giorno successivo.

Fornisci 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 potrebbe essere considerato difficile da e ti contatteremo in merito a queste risposte. Dall'altra parte un punteggio pari o superiore a 4 indica che l'interazione non è stata difficoltosa cliente e considerata come 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 la cui risoluzione richiede molto tempo possono diventare poco chiari e obsoleti. Il meglio per evitare che ciò accada è raccogliere informazioni utilizzando la nostra sezione Risoluzione dei problemi 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 gruppo del tuo team dedicato all'account e chiedigli di condividerlo con Esperti dell'assistenza clienti.

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 sollevare un nuovo problema.

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. Problemi che bloccano un piccolo numero di sviluppatori, non sono quelle che consideriamo 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.
  • Una conferma che possiamo osservare il problema che hai segnalato oppure un per ulteriori dettagli.
  • Il modo in cui intendiamo comunicare.

È quindi importante creare rapidamente una richiesta includendo ora, prodotto identificatori e località, quindi avvia procedure di risoluzione dei problemi più approfondite. Il tuo potrebbe avere definito un processo di gestione degli incidenti. Questa fase dovrebbe essere eseguito quasi 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 definire 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é ha il contesto.

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 principali molto specifiche. I messaggi di errore della rete sono spesso generali (ad es. "Impossibile connettersi al server"), dobbiamo raccogliere dati diagnostici dettagliati informazioni per restringere le ipotesi possibili.

I diagrammi di flusso dei pacchetti forniscono una struttura eccellente per il report sui problemi. Questi i diagrammi descrivono gli hop importanti che un pacchetto prende lungo un percorso dall'origine alla destinazione, insieme a 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 nella 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 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 usiamo MTR o tcptraceroute o entrambi perché hanno un potere diagnostico migliore. 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 prendere acquisire pacchetti per entrambi gli endpoint contemporaneamente, il che può essere complicato. È buona norma esercitarsi con gli strumenti necessari (ad esempio, tcpdump oppure Wireshark) e assicurati che siano installati prima di averne bisogno.