Prácticas recomendadas para trabajar con Atención al cliente

En esta guía, se proporcionan las prácticas recomendadas para escribir un caso de asistencia eficaz. Seguir estas prácticas recomendadas nos ayuda a resolver tu caso de asistencia técnica más rápido.

Crea un caso de asistencia

Antes de crear un caso de asistencia, revisa los problemas conocidos para comprobar si ya se presentó un caso.

Para evitar confusiones y que podamos hacer un seguimiento de tu solicitud en un solo punto, crea un caso de asistencia por problema. Se cerrará cualquier caso duplicado que se cree.

Describe tu problema

Es recomendable que escribas un caso de ayuda detallado, ya que esto le permite al equipo de Atención al cliente de Google responder de forma rápida y eficiente. Si faltan detalles importantes en tu caso de asistencia, tendremos que solicitarte más información, lo que lleva tiempo adicional.

Los mejores casos de asistencia son detallados y específicos. Nos cuentan lo que sucedió y lo que esperabas que sucediera. Cuando describas el problema en tu caso de asistencia, incluye los siguientes detalles:

  • Hora: La marca de tiempo específica del momento en que comenzó el problema.
  • Producto: Los productos y las funciones asociados con el problema.
  • Ubicación: Son las zonas en las que se presenta el problema.
  • Identificadores: El ID del proyecto o el ID de aplicación y otros identificadores concretos que nos ayuden a investigar el problema.
  • Artefactos útiles: Cualquier información que puedas proporcionar para ayudarnos a diagnosticar el problema.
  • Tipo de problema: Si el problema es intermitente, transitorio o constante.

Las siguientes secciones describen estos conceptos en mayor detalle.

Tiempo

Indica la fecha y la marca de tiempo en el formato ISO 8601 para indicarnos cuándo notaste el problema por primera vez y cuánto duró.

Ejemplos:

  • Desde las 2017-09-08T15:13:06+00:00 y 5 minutos después, observamos...
  • Observamos un problema intermitente, que se dio por primera vez el 2017-09-10 y sucedió entre 2 y 5 veces…
  • El problema está en curso desde las 2017-09-08T15:13:06+00:00…
  • Desde las 2017-09-08T15:13:06+00:00 hasta las 2017-09-08T15:18:16+00:00…

Es muy probable que el especialista de atención al cliente que resuelve el problema no esté en tu zona horaria, por lo que las afirmaciones relativas como las siguientes hacen que el problema sea más difícil de diagnosticar:

  • "Esto comenzó en algún momento de ayer..." (nos obliga a inferir la fecha implícita).
  • “Notamos el problema el 8/9...” (Es ambiguo, ya que algunos pueden interpretar que esta fecha es el 8 de septiembre y otros, como el 9 de agosto).

Producto

Si bien el formulario de caso básico pide que se especifique un nombre de producto, necesitamos información específica sobre qué función de ese producto tiene el problema. Lo ideal es que tu informe haga referencia a APIs o URLs específicas de la consola de Google Cloud (o capturas de pantalla). En el caso de las API, puedes agregar un vínculo a la página de documentación que contenga el nombre del producto en la URL.

También cuéntanos sobre el mecanismo que usas para iniciar la solicitud (por ejemplo, la API de REST, Google Cloud CLI, la consola de Google Cloud o tal vez una herramienta como Cloud Deployment Manager). Si hay varios productos involucrados, danos cada nombre específicamente.

Ejemplos:

  • “La API de REST de Compute Engine mostró los siguientes errores...”
  • “La interfaz de consulta de BigQuery en console.cloud.google.com está suspendida...”

Las siguientes afirmaciones no son lo suficientemente específicas para saber dónde buscar al momento de diagnosticar el problema:

  • "No se pueden crear instancias..." (necesitamos saber el método que utilizas para crear las instancias).
  • "El comando gcloud compute create instances muestra un error..."(la sintaxis del comando es incorrecta, por lo que no podemos ejecutarlo para reproducir el error; además, no sabemos cuál es el error que se mostró).

Ubicación

Necesitamos conocer la región y la zona de tu centro de datos, ya que a menudo implementamos cambios en una región o zona a la vez. La región y la zona nos permiten identificar el número de versión del software subyacente. Esta información nos ayuda a saber si una versión particular de nuestro software incluye cambios rotundos que están afectando tus sistemas.

Ejemplos:

  • “En us-east1-a…”
  • “Probé en las regiones us-east1 y us-central1…”

Identificadores

Los identificadores específicos nos ayudan a saber cuál de tus proyectos de Cloud está experimentando el problema. Siempre necesitamos conocer el ID del proyecto en formato alfanumérico o el ID de la aplicación. Los nombres de proyecto no son útiles. Si el problema afecta a varios proyectos, debes incluir todos los ID afectados.

Además de los ID de proyecto o aplicación, hay varios otros identificadores que nos ayudan a diagnosticar tu caso:

  • ID de instancia
  • ID de trabajo de BigQuery o nombres de tablas
  • Direcciones IP

Cuando especifiques una dirección IP, también debes decirnos el contexto en el que se utiliza. Por ejemplo, especifica si la IP está conectada a una instancia de procesamiento, un balanceador de cargas, una ruta personalizada o un extremo de API. También indícanos si la dirección IP no está relacionada con los sistemas de Google (por ejemplo, si es para tu Internet doméstica, un extremo de VPN o un sistema de supervisión externo).

Ejemplos:

  • “En el proyecto robot-name-165473 o my-project-id…”
  • “En varios proyectos (incluido my-project-id)…”
  • “Conexión a la IP externa 218.239.8.9 de Google Cloud desde nuestra puerta de enlace corporativa 56.56.56.56...”

Las descripciones generales como las siguientes son demasiado vagas, por lo que no son útiles para diagnosticar el problema:

  • “No podemos conectarnos con una de nuestras instancias…”.
  • “No podemos conectarnos por Internet…”.

Artefactos útiles

Si nos proporcionas artefactos relacionados con el problema, se acelerará el proceso de solución, ya que podremos ver exactamente lo mismo que tú.

Por ejemplo:

  • Usa una captura de pantalla para mostrar exactamente lo que ves.
  • Para las interfaces basadas en la Web, proporciona un archivo .HAR (Http ARchive). El analizador de HAR tiene instrucciones para tres de los navegadores más populares.
  • Adjunta los resultados de tcpdump, fragmentos de registros y ejemplos de seguimientos de pila.

Problem type

  • Intermitente: Los problemas intermitentes ocurren de forma aleatoria sin patrones de falla habituales. La solución de estos problemas es difícil porque su irregularidad dificulta la recopilación de datos durante la falla. En este caso, debes intentar identificar los cuellos de botella en la arquitectura y verificar si tus recursos están alcanzando su límite máximo de uso. También puedes ejecutar verificaciones frecuentes en un trabajo programado mediante la automatización. Si la verificación no es exitosa, recopila información de depuración durante la falla. Algunos ejemplos de este tipo de errores son la resolución de DNS y la pérdida de paquetes.

  • Transitorio: Los problemas transitorios son momentáneos o existen solo durante un período breve. Si tienes problemas que ocurren solo durante un segundo o unos microsegundos, puedes comprobar si hay pequeños picos de actividad en el tráfico o picos de utilización de recursos. En la mayoría de los casos, los problemas transitorios se pueden ignorar si no se repiten con frecuencia y si el servicio está diseñado para tolerar fallas transitorias. Algunos ejemplos de este tipo de errores son los aumentos repentinos de latencia de red, que ocurren solo durante algunos microsegundos y las pequeñas pérdidas de paquetes que causan tiempos de espera. El protocolo de control de transmisión (TCP) está diseñado para fallas como pequeñas pérdida de paquetes y aumentos repentinos de latencia, y puede manejar estos problemas de manera efectiva, a menos que tu aplicación sea sensible a la latencia.

  • Constante: Los problemas constantes son aquellos que producen fallas totales, como cuando tu sitio web está inactivo. Los problemas constantes son relativamente sencillos porque se pueden reproducir. En este caso, cuéntanos los pasos para reproducir el problema, de modo que nuestros especialistas de atención al cliente puedan replicar el entorno y solucionar el problema por ti.

Descripciones de ejemplo

Primer ejemplo

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.

Segundo ejemplo

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.

Establece la prioridad y auméntala

La prioridad nos ayuda a comprender el impacto que este problema tiene en tu negocio y afecta la rapidez con la que respondemos para resolverlo. Las prioridades se definen en la siguiente tabla. Puedes obtener más información en Prioridad de los casos de asistencia.

Definición de la prioridad Ejemplo de situación
P1: Impacto crítico (servicio inutilizable en producción) La aplicación o infraestructura es inutilizable en producción y presenta una tasa de errores significativa que afecta a los usuarios. El impacto en el negocio es crítico (pérdida de ingresos, posible problema de integridad de los datos, etc.).
P2: Impacto alto (uso del servicio gravemente afectado) La infraestructura se deteriora en la producción y tiene una tasa notoria de errores que afectan a los usuarios o tiene dificultades para poner en marcha un nuevo sistema de producción. El impacto en el negocio es moderado (peligro de pérdida de ingresos, disminución de la productividad, etcétera).
P3: Impacto medio (uso del servicio parcialmente afectado) El problema está limitado en alcance o severidad. El problema no tiene un impacto visible para el usuario. El impacto en el negocio es bajo (por ejemplo, inconvenientes o procesos comerciales menores afectados).
P4: Impacto bajo (servicio totalmente utilizable) El impacto técnico o comercial del problema es escaso o nulo. Se recomienda para tickets de consulta en los que se prefiere el análisis, la solución de problemas o el asesoramiento en profundidad, en lugar de comunicaciones más frecuentes.

Cuándo establecer la prioridad más alta

Si tienes un problema que afecta los servicios esenciales de la empresa y necesita atención inmediata de Google, elige el nivel de prioridad "P1". Explícanos en detalle por qué seleccionaste P1. Incluye una breve descripción del impacto que este problema tiene en tu negocio. Por ejemplo, puedes considerar que un problema con una versión de desarrollador es P1, incluso si ningún usuario final se ve afectado directamente, si está bloqueando una corrección de seguridad crítica.

Cuando un caso se establece como P1, un miembro del equipo de asistencia en servicio recibe una alerta de inmediato para encontrar al experto adecuado que se ocupe exclusivamente del problema. Recibirás una respuesta inicial rápida. Luego, recibirás actualizaciones periódicas.

Valoramos los comentarios detallados que respaldan el nivel de priorización elegido, ya que nos ayuda a responder adecuadamente.

Tiempos de respuesta

Los niveles de prioridad de los problemas tienen tiempos de respuesta predefinidos que se indican en los Lineamientos de los servicios de asistencia técnica de Google Cloud Platform. Si necesitas una respuesta antes de un plazo específico, avísanos en la descripción de tu informe. Si un problema de nivel P1 debe abordarse las 24 horas del día, puedes solicitar un servicio que permita “seguir el sol”. Estos casos se reasignan varias veces al día a un especialista activo de atención al cliente.

Aumenta la prioridad

Cuando las circunstancias cambian, es posible que debas derivar un problema. Estos son algunos buenos motivos para la elevación:

  • El impacto para la empresa aumentó.
  • Desglose del proceso de resolución. Por ejemplo, no recibiste una actualización en el tiempo acordado o tu problema está "atascado" sin progreso después de intercambiar varios mensajes.

Cuando experimentas un problema de alto impacto, la mejor solución es establecer el caso en la prioridad adecuada durante un período adecuado, en lugar de derivarlo. La elevación no necesariamente resuelve el caso más rápido, y hacerlo poco después del cambio de prioridad puede incluso hacer que la resolución del caso sea más lenta. Puedes obtener una explicación más detallada en el video Cuándo deberías derivar.

Si quieres obtener información para derivar un caso, consulta Deriva un caso.

Enrutar los casos a la zona horaria requerida

Debido a los factores en los que se basa la disponibilidad de Atención al cliente, tu caso de asistencia podría asignarse a un especialista en atención al cliente que trabaje fuera de tu horario de atención. También es posible que quieras comunicarte con el servicio de atención al cliente durante los días hábiles de una zona horaria específica. En esos casos, te recomendamos que solicites a Atención al cliente que dirija tu caso de asistencia a una zona horaria que te resulte conveniente. Puedes agregar esta solicitud en la descripción o respuesta de tu caso. Por ejemplo, Please route this case to the Pacific time zone (GMT-8) Los casos P1 se transfieren a la Atención al cliente de la siguiente región porque sigue el sol, mientras que otros casos permanecen con el propietario actual del caso para continuar trabajando en el caso al día siguiente.

Proporciona comentarios con la encuesta de CES

Cuando se resuelve un caso, se envía por correo electrónico una encuesta de Puntuación del esfuerzo del cliente (CES) relacionada con tu opinión sobre cómo fue el proceso. Te agradeceríamos mucho si puedes tomarte unos minutos para completarla, de modo que sepamos qué hicimos bien y cuáles fueron los desafíos para mejorar estos aspectos.

El equipo de experiencia del cliente revisa manualmente todos los formularios de comentarios y da como resultado las acciones correspondientes para mejorar tu experiencia futura. La puntuación será sobre 5. Una puntuación de 3 o inferior se consideraría difícil por parte del cliente, y nos comunicaremos contigo sobre estas respuestas. Por otro lado, una puntuación de 4 o más significa que la interacción no fue difícil para el cliente y se consideró una experiencia positiva.

Para obtener más información, mira el video Cómo enviar comentarios de los servicios de Google Cloud con CES.

Problemas difíciles o de larga duración

Los problemas que tardan mucho tiempo en resolverse pueden volverse confusos o dejar de avanzar. La mejor manera de evitar esto es recopilar información con nuestra plantilla de problemas de larga duración, en la que debe resumirse el estado más reciente en la parte superior.

Para utilizar la plantilla, abre el vínculo anterior y haz una copia. Incluye vínculos a todos los casos relevantes y errores de seguimiento interno. Comparte este documento con el grupo de tu equipo de cuentas y pídeles que lo compartan con especialistas específicos de Atención al cliente.

Este documento incluye lo siguiente:

  • Un resumen del estado actual en la parte superior
  • Una lista de hipótesis potencialmente verdaderas
  • Las pruebas o herramientas que deseas usar para poner a prueba cada hipótesis

Trata de mantener cada caso centrado en un solo problema y evita volver a abrir un caso para mencionar un problema nuevo.

Cómo informar una interrupción de la producción

Si el problema hizo que tu aplicación dejara de entregar tráfico a los usuarios o tiene un impacto crítico para la empresa similar, es posible que se trate de una interrupción de la producción. Queremos tomar conocimiento lo antes posible. No consideramos como interrupciones de la producción a los problemas que bloquean a una pequeña cantidad de desarrolladores.

Cuando recibimos un informe de interrupción de la producción, usamos el siguiente procedimiento para clasificar la situación rápidamente:

  • Verificación inmediata de problemas conocidos que afecten la infraestructura de Google Cloud.
  • Confirmamos la naturaleza del problema.
  • Establecemos canales de comunicación.

Puedes esperar una respuesta con un mensaje breve, que contiene lo siguiente:

  • Cualquier problema conocido relacionado que afecte a varios clientes
  • Una confirmación de que podemos observar el problema que se informó o una solicitud de más detalles
  • Cómo pretendemos comunicarnos.

Por lo tanto, es importante crear rápidamente un caso que incluya la hora, el producto, los identificadores y la ubicación, y luego comenzar una solución de problemas más profunda. Es posible que tu organización tenga un proceso de administración de incidentes definido, por lo que este paso debe ejecutarse muy cerca del comienzo.

El proceso de administración de incidentes de Google define una función clave: el comandante del incidente. Esta persona involucra a las personas adecuadas, recopila continuamente el estado más reciente del problema y resume periódicamente su estado. Delega trabajo a otros, para solucionar problemas y aplicar cambios. Esta delegación nos permite investigar varias hipótesis en paralelo. Te recomendamos que se establezca un proceso similar dentro de tu organización. La persona que abrió el caso suele ser la mejor opción como comandante del incidente, ya que es quien posee más información del contexto.

Cómo informar un problema de herramientas de redes

El tamaño y la complejidad de la red de Google pueden dificultar la identificación del equipo propietario del problema. Para diagnosticar problemas de red, necesitamos identificar causas raíz muy específicas. Debido a que los mensajes de error de la red a menudo son generales (como “No se puede establecer una conexión al servidor”), necesitamos recopilar información de diagnóstico detallada para reducir las hipótesis posibles.

Los diagramas de flujo de paquetes proporcionan una estructura excelente para el informe de problemas. Estos diagramas describen los saltos importantes que da un paquete a lo largo de una ruta, desde el origen hasta el destino, junto con cualquier transformación significativa en el camino.

Comienza por identificar los extremos de red afectados por la dirección IP de Internet o por la dirección privada RFC 1918 más un identificador de la red. Por ejemplo, 2.3.4.5 o 10.2.3.4 en la red predeterminada del proyecto de Compute Engine.

Agrega cualquier dato significativo relacionado con los extremos, como los siguientes ejemplos:

  • Quién los controla
  • Si están asociados con un nombre de host DNS
  • Cualquier encapsulación o indirección intermedia, o ambas, como túneles VPN, proxies y puertas de enlace NAT
  • Cualquier filtrado intermedio, como firewalls, CDN o WAF

Muchos problemas que se manifiestan como de latencia alta o pérdida intermitente de paquetes requerirán un análisis de la ruta, una captura de paquetes o ambos para el diagnóstico.

  • El análisis de ruta es una lista de todos los saltos que recorren los paquetes y es conocido como “traceroute”. A menudo usamos MTR o tcptraceroute, o ambos porque tienen mejor capacidad de diagnóstico. Te recomendamos que te familiarices con estas herramientas.
  • La captura de paquetes (también conocida como "pcap", por el nombre de la biblioteca "libpcap") es una observación del tráfico de red real. Es importante realizar una captura de paquetes para ambos extremos al mismo tiempo, lo que puede ser complicado. Es recomendable que practiques con las herramientas necesarias (por ejemplo, tcpdump o Wireshark) y te asegures de tenerlas instaladas antes de que las necesites.