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, controlla i problemi noti per verificare se è già stata presentata una richiesta.
Per evitare confusione e per consentirci di monitorare la tua richiesta in un unico punto, crea una richiesta di assistenza per ogni problema. Tutte le richieste duplicate create vengono chiuse.
Descrivere il problema
Scrivere una richiesta di assistenza dettagliata rende più semplice per il team dell'assistenza clienti rispondere in modo rapido ed efficiente. Quando nella richiesta di assistenza mancano dettagli fondamentali, dobbiamo chiedere ulteriori informazioni, il che richiede più tempo.
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.
- Artefatti utili: tutti i dettagli che puoi fornire per aiutarci a diagnosticare il problema.
- Tipo di problema:se il problema è intermittente, transitorio o costante.
Le sezioni seguenti descrivono questi concetti in modo più dettagliato.
Ora
Utilizzando il formato ISO 8601 per la data e il timestamp, comunicaci quando hai notato per la prima volta questo problema e per quanto tempo è durato.
Esempi:
- A partire dalle ore 15:13:06 UTC del 08/09/2017 e per i 5 minuti successivi, abbiamo osservato…
- Osservato a intermittenza, a partire dal 10/09/2017 e osservato 2-5 volte…
- In corso dal giorno 2017-09-08T15:13:06+00:00...
- Dal giorno 2017-09-08T15:13:06+00:00 al giorno 2017-09-08T15:18:16+00:00…
L'esperto dell'assistenza clienti che risolve il problema molto probabilmente non si trova nel tuo fuso orario, quindi le affermazioni relative come le seguenti rendono più difficile la diagnosi del problema:
- "Questo problema è iniziato ieri..." (Ci costringe a dedurre la data implicita.)
- "Abbiamo notato il problema l'8/9..." (Ambiguo, in quanto alcuni potrebbero interpretare questa data come 8 settembre, mentre altri come 9 agosto.)
Prodotto
Anche se il modulo di richiesta di assistenza di base ti chiede 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 a API specifiche o a URL della console (o a screenshot). Google Cloud Per le API, puoi creare un link alla pagina della documentazione, che contiene il nome del prodotto nell'URL.
Inoltre, comunicaci il meccanismo che utilizzi per avviare la richiesta (ad esempio, API REST,Google Cloud CLI, console Google Cloud o uno strumento come Cloud Deployment Manager). Se sono coinvolti più prodotti, fornisci il nome di ciascuno.
Esempi:
- "L'API REST di 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 diagnostichiamo il problema:
- "Impossibile creare istanze…" (Dobbiamo conoscere il metodo che utilizzi per creare istanze.)
- "Il comando
gcloud compute create instancesrestituisce un errore…"(la sintassi del comando è errata, quindi non possiamo eseguirlo per riprodurre l'errore. Inoltre, non sappiamo quale errore hai effettivamente visualizzato.)
Località
Abbiamo bisogno di conoscere la regione e la zona del data center perché spesso implementiamo le 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 le modifiche che causano interruzioni in una determinata versione del nostro software influiscono sui tuoi sistemi.
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 sta riscontrando il problema. Abbiamo sempre bisogno di conoscere l'ID progetto o 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 BigQuery o nomi delle tabelle.
- 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, a un bilanciatore del carico, a una route personalizzata o a un endpoint API. Inoltre, comunicaci se l'indirizzo IP non è correlato ai sistemi di Google (ad esempio, se l'indirizzo IP è per la tua rete internet di casa, 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' Google Cloud IP esterno 218.239.8.9 dal nostro gateway aziendale 56.56.56.56…"
Affermazioni generali come le seguenti sono troppo generiche per diagnosticare il problema:
- "Una delle nostre istanze non è raggiungibile…"
- "Non riusciamo a connetterci a internet…"
Artefatti utili
Fornirci artefatti correlati al problema velocizzerà la risoluzione dei problemi aiutandoci a vedere esattamente ciò che vedi tu.
Ad esempio:
- Utilizza uno screenshot per mostrare esattamente ciò che vedi.
- Per le interfacce basate sul web, fornisci eventuali informazioni di traccia del browser pertinenti.
- Allega l'output di tcpdump, snippet di log e stack trace di esempio.
Tipo di problema
Intermittente: i problemi intermittenti si verificano in modo casuale senza schemi di errore regolari. I problemi intermittenti sono difficili da risolvere perché la loro irregolarità rende difficile raccogliere dati durante l'errore. In questo caso, devi provare a identificare i colli di bottiglia nell'architettura e controllare se le tue risorse raggiungono le soglie di utilizzo massime. Puoi anche eseguire controlli frequenti in un job pianificato 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 gli errori di risoluzione DNS e la perdita di pacchetti.
Temporaneo: i problemi temporanei sono momentanei o esistono solo per un breve periodo di tempo. Se riscontri problemi che si verificano solo per un secondo o pochi microsecondi, puoi verificare la presenza di micro burst di traffico o picchi di utilizzo delle risorse. Nella maggior parte dei casi, i problemi temporanei possono essere ignorati se non si ripresentano spesso e se il servizio è progettato per tollerare errori temporanei. Esempi di questo tipo di errore sono picchi di latenza di rete che si verificano solo per pochi microsecondi e piccole perdite di pacchetti che causano timeout. Il protocollo TCP (Transmission Control Protocol) è progettato per gestire errori come la perdita di piccoli pacchetti e i picchi di latenza e può gestire questi problemi in modo efficace, a meno che la tua applicazione non sia sensibile alla latenza.
Coerenti: i problemi coerenti sono quelli che non vengono risolti completamente, ad esempio quando il tuo sito web non è disponibile. I problemi costanti sono relativamente semplici da risolvere perché possono essere riprodotti. In questo caso, comunicaci i passaggi per riprodurre il problema in modo che i nostri esperti dell'assistenza clienti possano replicare l'ambiente e risolverlo per te.
Esempi di descrizioni
Gli esempi riportati di seguito forniscono descrizioni dettagliate per le richieste di assistenza.
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 comprendere l'impatto di questo problema sulla tua attività e influisce sulla 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 ambiente di produzione | L'applicazione o l'infrastruttura è inutilizzabile in produzione e presenta un tasso significativo di errori visibili agli utenti. 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 è degradata in produzione, con un tasso notevole di errori o difficoltà per gli utenti nell'avvio di un nuovo sistema di produzione. L'impatto aziendale è moderato (rischio di perdita di entrate, diminuzione 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 alcun impatto visibile agli utenti. L'impatto aziendale è basso (ad esempio, disagio o processi aziendali minori interessati). |
| P4 - Impatto basso: servizio completamente utilizzabile | Impatto tecnico o commerciale minimo o nullo. Consigliato per ticket di consulenza in cui analisi approfondite, risoluzione dei problemi o consulenza sono preferibili a comunicazioni più frequenti. |
Quando impostare la priorità più alta
Se hai un problema che interessa servizi essenziali per l'attività e richiede l'attenzione immediata di Google, scegli "P1" come priorità. Spiegaci 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 una versione di sviluppo come P1, anche se nessun utente finale è direttamente interessato, se blocca una correzione di sicurezza critica.
Quando un caso viene impostato come P1, un esperto viene immediatamente avvisato per lavorare esclusivamente sul problema. Ricevi una risposta iniziale rapida per partecipare a una chiamata di risoluzione dei problemi in diretta tramite Google Meet. Se la tua organizzazione non può utilizzare Google Meet, includi un link al software di videoconferenza che preferisci per consentire all'esperto di partecipare. Dopodiché, riceverai aggiornamenti regolari tramite la richiesta.
Apprezziamo i commenti dettagliati che supportano il 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. Prevediamo che tu ti unisca alla chiamata entro 15-30 minuti. Informa l'esperto dell'assistenza se non puoi partecipare alla chiamata per qualsiasi motivo.
- Per impostazione predefinita, la richiesta "segue il sole". Ciò significa che gli esperti dell'assistenza sono disponibili 24 ore al giorno finché il problema non viene risolto o declassato. Se la mitigazione del problema è meglio perseguita in una regione specifica, la richiesta può essere bloccata in un determinato fuso orario. Puoi comunicarci la tua preferenza in merito.
Aumento della priorità P1
- Se il problema ha iniziato a influire sul 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 attenzione immediata.
Impatto non di produzione
Per garantire che le risorse appropriate vengano allocate dove necessario, l'assistenza potrebbe contattarti per rivalutare le richieste contrassegnate come P1 che non influiscono sulla produzione o non causano un elevato impatto aziendale.
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 orario specifico, 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. Durante la risoluzione del problema relativo alla richiesta P1, ti consigliamo di rimanere in contatto per rispondere alle domande fino alla risoluzione del problema per facilitare una comunicazione efficiente. Se non rispondi per più di 3 ore, potremmo ridurre la priorità della richiesta di assistenza a P2 finché non riprendi a rispondere.
Riassegnazione
Quando le circostanze cambiano, potrebbe essere necessario riassegnare un problema. I motivi validi per la riassegnazione sono:
- Aumento dell'impatto sul business.
- Ripartizione della procedura di risoluzione. Ad esempio, non hai ricevuto un aggiornamento nel periodo di tempo concordato o il tuo problema è "bloccato" senza progressi dopo lo scambio di diversi messaggi.
Quando riscontri un problema con un impatto elevato, la soluzione migliore è impostare la priorità appropriata per un periodo di tempo adeguato, anziché riassegnare la richiesta. La riassegnazione non risolve necessariamente la richiesta più rapidamente e la riassegnazione poco dopo la modifica della priorità potrebbe persino rallentare la risoluzione della richiesta. Puoi trovare una spiegazione più dettagliata nel video Quando devi riassegnare.
Per saperne di più, vedi Riassegnare una richiesta.
Instradare 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 attività. È 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 indirizzare la tua
richiesta di assistenza a un fuso orario conveniente 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é segue il sole, mentre le altre richieste rimangono con l'attuale proprietario per continuare a lavorarci il giorno successivo.
Fornire un feedback con il sondaggio CES
Quando un problema viene risolto, ti verrà inviato via email un sondaggio CES (Customer Effort Score) per raccogliere la tua opinione su come è andata la procedura. Ti saremmo molto grati se potessi dedicare qualche minuto alla compilazione del sondaggio, in modo da 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 comporta azioni corrispondenti per migliorare la tua esperienza futura. Il punteggio sarà su 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 è considerata un'esperienza positiva.
Per saperne di più, guarda il video Come inviare feedback sui servizi con CES. Google Cloud
Problemi di lunga data o difficili
I problemi che richiedono molto tempo per essere risolti possono diventare confusi e obsoleti. Il modo migliore per evitare questo problema è raccogliere informazioni utilizzando il nostro modello per i problemi di lunga durata con il riepilogo dello stato più recente in alto.
Per utilizzare il modello, apri il link precedente e crea una copia. Includi i link a tutte le richieste pertinenti e ai bug di monitoraggio interni. Condividi questo documento con il gruppo del tuo team dell'account e chiedi di condividerlo con specialisti specifici dell'assistenza clienti.
Questo documento include:
- Un riepilogo dello stato attuale nella parte superiore.
- Un elenco delle ipotesi potenzialmente vere.
- I test o gli strumenti che intendi utilizzare per testare ogni ipotesi.
Cerca di concentrare ogni richiesta su un singolo problema ed evita di riaprire una richiesta per sollevare un nuovo problema.
Segnalazione di un'interruzione della produzione
Se il problema ha causato l'interruzione della pubblicazione del traffico agli utenti da parte della tua applicazione o ha un impatto simile e critico per l'attività, potrebbe trattarsi di un'interruzione della produzione. Vogliamo saperlo il prima possibile. I problemi che bloccano un numero ridotto di sviluppatori, al contrario, non sono considerati interruzioni della produzione.
Quando riceviamo una segnalazione di interruzione della produzione, esaminiamo rapidamente la situazione:
- Controllo immediato dei problemi noti che interessano l'infrastruttura Google Cloud .
- Conferma della natura del problema.
- Stabilire i canali di comunicazione.
Riceverai una risposta con un breve messaggio contenente:
- Eventuali problemi noti correlati che interessano più clienti.
- Una conferma che possiamo osservare il problema che hai segnalato o una richiesta di maggiori dettagli.
- Come intendiamo comunicare.
Pertanto, è importante creare rapidamente una richiesta includendo ora, prodotto, identificatori e posizione, per poi iniziare una risoluzione dei problemi più approfondita. La tua organizzazione potrebbe aver definito una procedura di gestione degli incidenti e questo passaggio deve 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 gli ultimi aggiornamenti sullo 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 una procedura simile all'interno della tua organizzazione. La persona che ha aperto la richiesta è in genere la scelta migliore per ricoprire il ruolo di responsabile 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 principali 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 sul problema. Questi diagrammi descrivono gli hop importanti che un pacchetto esegue 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 all'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.
Annota qualsiasi informazione significativa sugli endpoint, ad esempio:
- Chi li controlla.
- Se sono associati a un nome host DNS.
- Qualsiasi incapsulamento o reindirizzamento intermedio o entrambi, come il tunneling VPN, i proxy e i gateway NAT.
- Qualsiasi filtro intermedio, come firewall, CDN o WAF.
Molti problemi che si manifestano come latenza elevata o perdita di pacchetti intermittente richiedono un'analisi del percorso o un'acquisizione di pacchetti oppure entrambe per la diagnosi.
- L'analisi del percorso è un elenco di tutti gli hop attraversati dai pacchetti ed è nota come "traceroute". Spesso utilizziamo MTR o tcptraceroute, o entrambi, perché hanno una migliore capacità diagnostica. 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 un pacchetto per entrambi gli endpoint contemporaneamente, il che può essere complicato. È consigliabile fare pratica con gli strumenti necessari (ad esempio tcpdump o Wireshark) e assicurarsi che siano installati prima di averne bisogno.
Segnalazione di un problema relativo alla console Google Cloud
Quando segnali un problema con la console Google Cloud basata sul web, oltre alle indicazioni precedenti, fornisci le seguenti informazioni per aiutarci a restringere le potenziali cause del problema:
- URL delle pagine della console interessate
- ID dei progetti interessati
- Numero di utenti interessati
- Se il problema si verifica su computer diversi
- Browser interessati
- Eventuali estensioni del browser o sistemi firewall in uso
Inoltre, l'inclusione di eventuali informazioni di traccia del browser ci aiuta a comprendere e analizzare il problema.