Se usó la API de Cloud Translation para traducir esta página.

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 ayuda 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 ver 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 cierran los casos duplicados que se crean.

Describa el 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 críticos en tu caso de asistencia, tendremos que pedirte más información, lo que requiere 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 experimentas el problema.
Identificadores: El ID del proyecto o 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

Usa el formato ISO 8601 para la fecha y la marca de tiempo, y cuéntanos cuándo fue la primera vez que notaste el problema y cuánto tiempo duró.

Ejemplos:

Desde 2017-09-08T15:13:06+00:00 y hasta 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 resuelva el problema no esté en tu zona horaria, por lo que las declaraciones relativas como las siguientes hacen que el problema sea más difícil de diagnosticar:

"Esto comenzó ayer..." (Nos obliga a inferir la fecha implícita).
"Detectamos el problema el 8/9..." (Ambiguo, ya que algunos podrían interpretar esta fecha como el 8 de septiembre y otros podrían interpretarla 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 específicas o a URLs 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.

Además, cuéntanos sobre el mecanismo que estás usando 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 no responde...”

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

"No se pueden crear las instancias..." (Necesitamos conocer el método que estás usando para crear instancias).
"El comando gcloud compute create instances muestra un error..."(la sintaxis del comando es incorrecta, por lo que no podemos ejecutarlo nosotros mismos 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-b ..."
“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. Además, cuéntanos si la dirección IP no está relacionada con los sistemas de Google (por ejemplo, si la dirección IP corresponde a 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)…”
“Conectando a la IP externa de Google Cloud 218.239.8.9 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.
En el caso de las interfaces basadas en la Web, proporciona un archivo .HAR (Http ARchive). El analizador 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 tu 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 controlar estos problemas de manera eficaz, 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 fáciles de solucionar porque se pueden reproducir. En este caso, indícanos los pasos para reproducir el problema, de modo que nuestros especialistas de Atención al cliente puedan replicar el entorno y solucionar el problema.

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étera).
P2: Impacto alto (uso del servicio gravemente afectado)	La infraestructura está degradada en la producción y presenta una tasa notable de errores que afectan a los usuarios o 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 empresa. Por ejemplo, podrías considerar que un problema con una versión de desarrollo es de nivel P1, incluso si ningún usuario final se ve afectado directamente, si está bloqueando una solución de seguridad crítica.

Cuando un caso se configura como P1, se alerta de inmediato a un experto para que trabaje de forma exclusiva en el problema. Recibes una respuesta inicial rápida para unirte a una llamada de solución de problemas en vivo a través de Google Meet. Si tu organización no puede usar Google Meet, incluye un vínculo al software de videoconferencias que elijas para que el experto se una. Después de eso, recibirás actualizaciones periódicas a través del caso.

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

Qué esperar de la asistencia en casos P1

Nuevo caso P1
- Un experto de asistencia se comunicará contigo a través de Google Meet o cualquier otro puente que proporciones. Esperamos que te unas a la llamada en un plazo de 15 a 30 minutos. Informa al experto en asistencia si no puedes unirte a la llamada por algún motivo.
- La sentencia case “sigue el sol” de forma predeterminada. Esto significa que los expertos en asistencia trabajan las 24 horas del día hasta que se mitigue el caso o se deje de priorizar. Si la mitigación de casos se busca en una región específica, ese caso se puede bloquear en una zona horaria determinada. Puede indicarnos su preferencia a tal efecto.
Aumento de prioridad P1
- Si el problema comenzó a afectar a tu entorno de producción o está a punto de hacerlo, puedes aumentar la prioridad de un caso P2-P4 existente a P1.
- Cuando aumentas la prioridad de un caso existente a P1, el caso de asistencia se puede reasignar para permitir que un experto en asistencia disponible proporcione atención inmediata.
Impacto en la no producción

Para garantizar que se asignen los recursos adecuados cuando sea necesario, es posible que el equipo de asistencia se comunique contigo para reevaluar los casos marcados como P1 que no afectan la producción o no causan un alto impacto comercial.

Tiempos de respuesta

Los niveles de prioridad de los problemas tienen tiempos de respuesta predefinidos que se definen 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 requiere atención continua las 24 horas del día, puedes solicitar el servicio “follow the sun”. Estos casos se reasignan varias veces al día a un especialista activo de atención al cliente. Mientras solucionamos tu caso P1, te recomendamos que permanezcas involucrado para responder preguntas hasta la resolución para facilitar una comunicación eficiente. Si no respondes durante más de 3 horas, es posible que reduzcamos la prioridad del caso a P2 hasta que vuelvas a comunicarte.

Aumenta la prioridad

Cuando las circunstancias cambian, es posible que tengas que derivar un problema. Estos son buenos motivos para derivar el caso:

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 se “ataca” sin progresar después de intercambiar varios mensajes.

Cuando experimentas un problema de alto impacto, la mejor solución es establecer el caso con 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 encontrar una explicación más detallada en el video Cuándo debes derivar el caso.

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

Dirige los casos a la zona horaria requerida

Debido a los factores en los que se basa la disponibilidad del servicio 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 atención al cliente durante los días hábiles de una zona horaria específica. En esos casos, te recomendamos que solicites al equipo de Atención al cliente que dirija tu caso de asistencia a una zona horaria que sea conveniente para tu caso. 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 siguiente región de Atención al cliente porque sigue el sol, mientras que otros permanecen con el propietario actual del caso para seguir trabajando en el caso al día siguiente.

Proporciona comentarios con la encuesta CES

Cuando un caso se resuelve, se envía por correo electrónico una encuesta sobre la puntuación del esfuerzo del cliente (CES) relacionada con tu opinión sobre cómo fue el proceso. Te agradeceríamos mucho que te tomes unos minutos para completarlo, 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 cada formulario de comentarios y toma las medidas correspondientes para mejorar tu experiencia futura. La puntuación será de 5. Para el cliente, una puntuación de 3 o menos sería difícil y realizaremos un seguimiento 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 How to Submit Google Cloud Services Feedback with 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 usar 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 similar para el negocio, 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:

Verifica de inmediato si hay 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, y este paso debería ejecutarse apenas se presente el incidente.

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 la red afectados por la dirección IP de Internet o por la dirección privada RFC 1918, además de 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 encapsulamiento o indirección intermedios, o ambos, como túneles VPN, proxies y puertas de enlace NAT
Cualquier filtrado intermedio, como firewalls, CDN o WAF

Muchos problemas que se manifiestan como una latencia alta o una pérdida intermitente de paquetes requerirán un análisis de la ruta, una captura de paquetes o ambas 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 una mejor capacidad de diagnóstico. Te recomendamos familiarizarte 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 de ambos extremos al mismo tiempo, lo que puede ser complicado. Te recomendamos que practiques con las herramientas necesarias (por ejemplo, tcpdump o Wireshark) y te asegures de que estén instaladas antes de que las necesites.