Questa guida fornisce le best practice per scrivere una richiesta di assistenza efficace. Seguendo queste best practice, ci aiuti a risolvere più rapidamente la tua richiesta di assistenza tecnica.
Crea una richiesta di assistenza
Prima di creare una richiesta di assistenza, rivedi 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. Tutte le richieste duplicate create vengono chiuse.
Descrivi 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 di quando è 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 da 2017-09-08T15:13:06+00:00 e per i 5 minuti successivi, abbiamo osservato…
- Osservato a intermittenza, a partire dal 2017-09-10 e osservato 2-5 volte…
- In corso da 2017-09-08T15:13:06+00:00…
- Da 2017-09-08T15:13:06+00:00 a 2017-09-08T15:18:16+00:00…
È molto probabile che l'esperto dell'assistenza clienti che si occupa del problema non si trovi sul tuo stesso fuso orario, per cui affermazioni relative come le seguenti rendono più difficile la diagnosi:
- "Questo problema è iniziato ieri…" (Ci costringe a dedurre la data implicita.)
- "Abbiamo notato il problema il giorno 8/9…" (Ambiguo, in quanto alcuni potrebbero interpretare questa data come l'8 settembre, mentre altri come il 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 ad API specifiche o a URL della console Google Cloud (o screenshot). Per le API, puoi inserire 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:
- "Non riesco a 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 eseguiamo il deployment delle modifiche in una regione o una zona per volta. In base alla regione e alla zona possiamo identificare il numero di versione del software sottostante. Queste informazioni ci aiutano a sapere se i tuoi sistemi sono interessati da modifiche che provocano un errore in una determinata versione del nostro software.
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 alfanumerico del progetto o dell'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 nella diagnosi della tua richiesta:
- ID delle istanze.
- ID job BigQuery o nomi delle tabelle.
- Indirizzi IP.
Quando specifichi un indirizzo IP, indicaci anche il contesto in cui viene utilizzato. Ad esempio, specifica se l'IP è connesso a un'istanza di computing, 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)…"
- "Durante la connessione all'IP esterno Google Cloud 218.239.8.9 dal nostro gateway aziendale 56.56.56.56…"
Affermazioni generali come quelle seguenti sono troppo generiche per diagnosticare il problema:
- "Una delle nostre istanze non è raggiungibile…"
- "Non riusciamo a connetterci a internet…"
Artefatti utili
Fornendo artefatti correlati al problema, puoi velocizzare 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 sui dati di rilevamento del browser pertinenti.
- Allega l'output di tcpdump, snippet di log e analisi dello stack 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 programmato 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.
Transitorio: i problemi transitori 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 transitori possono essere ignorati se non si ripresentano spesso e se il servizio è progettato per tollerare errori transitori. 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 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.
Costante: i problemi costanti sono quelli che causano un'interruzione completa, ad esempio quando il tuo sito web è del tutto inattivo. 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 risolvere il problema per te.
Descrizioni di esempio
Di seguito sono riportati esempi di descrizioni dettagliate per le richieste di assistenza.
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.
Imposta la priorità e riassegna le richieste
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. Per maggiori informazioni, consulta 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 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 | L'infrastruttura è degradata in produzione, con un tasso notevole 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, diminuzione della produttività e così via). |
| P3 - Impatto medio: utilizzo del servizio parzialmente compromesso | L'ambito e/o la gravità del problema sono limitati. Il problema non ha un impatto visibile agli utenti. L'impatto sull'attività è basso (ad esempio, disagi o processi aziendali minori interessati). |
| P4 - Impatto basso: servizio completamente utilizzabile | Impatto sull'attività o tecnico minimo o nullo. Consigliato per le richieste 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 business critical e richiede l'attenzione immediata di Google, scegli la priorità "P1". 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 una richiesta viene impostata come P1, un esperto viene immediatamente avvisato per lavorare esclusivamente al problema. Ricevi una risposta iniziale rapida per partecipare a una chiamata di risoluzione dei problemi dal vivo tramite Google Meet. Se la tua organizzazione non può utilizzare Meet, includi un link al software di videoconferenza che preferisci per consentire all'esperto di partecipare. Dopodiché, riceverai aggiornamenti regolari nel corso dell'elaborazione della richiesta.
Apprezziamo commenti dettagliati a supporto del livello di priorità scelto, perché ci aiutano a rispondere in modo appropriato.
Come vengono gestite le richieste di assistenza P1
Nuova richiesta P1
- Un esperto dell'assistenza ti contatterà tramite Google Meet o qualsiasi altro mezzo da te fornito. Prevediamo che tu partecipi 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 viene gestita secondo il modello "follow-the-sun". Ciò significa che gli esperti dell'assistenza sono al lavoro 24 ore al giorno finché il problema non viene risolto o declassato. Se è più opportuno lavorare alla mitigazione della richiesta in una regione specifica, è possibile bloccarla su un determinato fuso orario. Puoi comunicarci la tua preferenza in merito.
Aumento della priorità a 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 in produzione
Per garantire l'allocazione delle risorse appropriate laddove necessario, l'assistenza potrebbe contattarti per rivalutare le richieste contrassegnate come P1 che non influiscono sulla produzione o non causano un elevato impatto sull'attività.
Tempi di risposta
I livelli di priorità dei problemi hanno tempi di risposta predefiniti, indicati 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, per facilitare una comunicazione efficiente ti consigliamo di rimanere in contatto per rispondere alle domande fino alla risoluzione del problema. Se non rispondi per più di 3 ore, potremmo ridurre la priorità della richiesta di assistenza a P2 finché non torni a rispondere.
Riassegnazione
Quando le circostanze cambiano, potrebbe essere necessario riassegnare un problema. Motivi validi per la riassegnazione:
- Aumento dell'impatto sull'attività.
- Interruzione del processo di risoluzione. Ad esempio, se non hai ricevuto un aggiornamento entro il periodo di tempo concordato o se il problema è "bloccato" senza progressi dopo lo scambio di diversi messaggi.
Quando riscontri un problema con impatto elevato, la soluzione migliore è impostare la richiesta sulla priorità appropriata per un periodo di tempo adeguato, anziché riassegnarla. La riassegnazione non risolve necessariamente la richiesta in tempi più rapidi e, se eseguita poco dopo la modifica della priorità, potrebbe persino rallentare la risoluzione della richiesta. Puoi trovare una spiegazione più dettagliata nel video When should you escalate.
Per saperne di più, consulta Riassegna una richiesta.
Inoltra le richieste al fuso orario appropriato
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 inoltrare la tua richiesta di assistenza a un fuso orario conveniente per te. 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é adottano il modello "follow-the-sun", mentre le altre richieste rimangono con l'attuale proprietario, che continuerà a lavorarci il giorno successivo.
Fornisci feedback con il sondaggio CES
Quando una richiesta è risolta, riceverai un sondaggio CES (Customer Effort Score) via email con cui registriamo la tua opinione su come si è svolto il processo. 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 vengono intraprese le azioni corrispondenti per migliorare la tua esperienza futura. Il punteggio è in 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 è considerata un'esperienza positiva.
Per saperne di più, guarda il video How to Submit Google Cloud Services Feedback with CES.
Problemi di lunga durata o complessi
I problemi che richiedono molto tempo per essere risolti possono diventare fonte di confusione e non fare progressi. Il modo migliore per evitare questa situazione è raccogliere informazioni utilizzando il nostro template per i problemi di lunga durata con il riepilogo dello stato più recente in alto.
Per utilizzare il template, apri il link precedente e crea una copia. Includi i link a tutte le richieste pertinenti e ai bug di monitoraggio interno. Condividi questo documento con il gruppo del team dedicato al tuo 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.
Segnala un'interruzione della produzione
Se il problema ha causato l'interruzione della gestione del traffico degli utenti da parte della tua applicazione o ha un impatto business critical analogo, 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:
- Controlliamo immediatamente la presenza di problemi noti che interessano l'infrastruttura Google Cloud .
- Confermiamo la natura del problema.
- Stabiliamo 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 località 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 e riassume periodicamente lo stato del problema. Delega 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 incident commander, perché conosce meglio il contesto.
Segnala 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 tunneling VPN, proxy e 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 dei percorsi, un'intercettazione di pacchetti oppure entrambe 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 una migliore capacità diagnostica. Ti consigliamo di acquisire familiarità con questi strumenti.
- L'intercettazione di pacchetti (nota anche come "pcap", dal nome della libreria "libpcap") è un'osservazione del traffico di rete reale. È importante eseguire l'intercettazione di pacchetti 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.
Segnala 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 limitare 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 sui dati di rilevamento del browser pertinenti ci aiuta a comprendere e analizzare il problema.