Recomendaciones para trabajar con la asistencia de Cloud

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 omites detalles importantes en tu caso de ayuda, tendremos que pedirte más información, lo que requiere tiempo adicional. En esta guía, aprenderás cuál es la información que necesitamos para resolver tu caso de ayuda técnica con mayor rapidez.

Describe el problema

Los mejores informes de problemas son detallados y específicos. Nos cuentan lo que sucedió y lo que esperabas que sucediera. Un buen informe de problemas contiene 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: Las zonas en las que se presenta el problema.
  • Identificadores: El ID del proyecto o 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.

Las siguientes secciones describen estos conceptos en mayor detalle.

Hora

Dinos cuándo fue la primera vez que notaste el problema y cuánto tiempo duró. Usa el formato ISO 8601 para las fechas y las marcas de tiempo.

Ejemplos:

  • Entre las 2017-09-08T15:13:06+00:00 y 5 minutos después, observamos que…
  • 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 ingeniero de asistencia encargado de resolver el problema no esté en tu zona horaria, por lo que las descripciones 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 algunas personas pueden interpretar esto como el 8 de septiembre y otros pueden interpretarlo 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 mencione las API específicas o a las URL de Cloud Console (o incluya 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.

Indica también cuál es el mecanismo que estás utilizando para iniciar la solicitud (por ejemplo, la API de REST, la herramienta de gcloud, Cloud Console o tal vez una herramienta como Deployment Manager). Si hay varios productos involucrados, danos cada nombre específicamente.

Ejemplos:

  • “La API de REST de Google 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 puedo crear instancias…” (necesitamos saber el método que estás usando para crear instancias).
  • “El comando gcloud compute create instances arroja 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-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 necesitaremos saber el ID alfanumérico del proyecto o 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, debes especificar si la IP estaba conectada a una instancia de procesamiento, un balanceador de cargas, una ruta personalizada o un extremo de API. Además, infórmanos si la dirección IP no está relacionada con los sistemas de Google (por ejemplo, si la dirección IP corresponde a tu conexión de Internet hogareña, un extremo de VPN o a un sistema de supervisión externo).

Ejemplos:

  • “En el proyecto robot-name-165473 o my-project-id…”
  • “En varios proyectos (incluido my-project-id)…”
  • “Cuando intento establecer una conexión con la IP externa de GCP 218.239.8.9 desde nuestra puerta de enlace empresarial 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). HAR Analyzer tiene instrucciones para tres de los navegadores más populares.
  • Adjunta los resultados de tcpdump, fragmentos de registros y ejemplos de seguimientos de pila.

Cómo definir y aumentar la prioridad

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. Para obtener una lista de definiciones de prioridad, consulta la referencia de procedimientos.

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 está teniendo en tu negocio. Por ejemplo, es posible que consideres que un problema con una versión de desarrollador es de nivel P1 si está bloqueando una solución de seguridad crítica, incluso si ningún usuario final se ve afectado directamente.

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 requiere atención continua las 24 horas del día, puedes solicitar un servicio específico para estos casos. Estos problemas se reasignan a un nuevo ingeniero de asistencia activo varias veces al día.

Cómo aumentar la prioridad

Cuando las circunstancias cambian, es posible que debas aumentar la prioridad del problema para que se lo atienda más rápidamente. Estos son algunos buenos motivos para aumentar la prioridad de un caso:

  • El impacto para la empresa aumentó.
  • Es necesario resolver el problema más rápido.
  • Ya se intercambiaron varios mensajes, pero el problema quedó “atascado” y no avanza.

Para derivar el caso, simplemente cambia su prioridad. Por ejemplo, puedes cambiar un problema de P3 a P2. Si haces esto, dinos por qué es necesario este cambio. Nuestro sistema de manejo de casos notificará a un agente, quien revisará tu caso y hará un seguimiento. Es conveniente que brindes comentarios detallados sobre por qué fue necesario realizar esta derivación, ya que de esa forma podremos brindar una respuesta más adecuada.

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, simplemente abre el vínculo de arriba y haz una copia. Debes incluir vínculos a todos los casos relevantes y errores de seguimiento interno. Comparte este documento con el grupo de tu equipo de cuentas y solicita que lo compartan con ingenieros de asistencia específicos.

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 deje de entregar tráfico a los usuarios o tiene un impacto crítico similar sobre tu empresa, se considera 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:

  • Revisamos inmediatamente si corresponde a algún problema conocido que afecte a la infraestructura de GCP.
  • Confirmamos la naturaleza del problema.
  • Establecemos canales de comunicación.

Puedes esperar una respuesta con un mensaje breve, que contendrá la siguiente información:

  • 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
  • Información sobre nuestro medio de comunicación (por ejemplo, teléfono, Hangout o caso)

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 debe 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, más un identificador de la red. Por ejemplo, 2.3.4.5 o 10.2.3.4 en la red predeterminada del proyecto en 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 intermedias, 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 alta latencia o pérdida intermitente de paquetes requerirán un análisis de ruta o una captura de paquetes 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 porque tienen una mejor capacidad de diagnóstico, así que 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 tomar una captura de paquetes de ambos extremos al mismo tiempo, lo cual puede ser complicado. Es recomendable que practiques con las herramientas necesarias (por ejemplo, tcpdump o Wireshark) y te asegures de tenerlas instaladas antes de requerirlas.

Casos de muestra

Ejemplo 1

Nombre del trabajo:

A_ATL_BIG1toBQ_big_04)201704202

00045_491

Fuente:

S3_avl-transfer

Destino:

CloudStorage: avl-transfer

Hora de inicio (formato ISO 8601): 2017-04-20 20:14:43 PDT

Hora de finalización (formato ISO 8601): 2017-04-21 a las 10:03:44 PDT

Comencé una transferencia de archivos el 2017-04-20 a las 20:14:43 PDT usando la API de transferencia. Este trabajo normalmente tarda 10 minutos en completarse, pero en este caso aún estaba en ejecución cuando lo cancelé al día siguiente (2017-04-21 a las 10:03:44 PDT). Este no es un evento aislado; varios otros trabajos relacionados con la API de transferencia tuvieron retrasos intermitentes y significativos.

Necesitaría que investiguen la causa de los retrasos y compartan con nosotros las recomendaciones que podamos implementar para evitar estos problemas en el futuro.

Ejemplo 2

Hora de inicio (formato ISO 8601): 2017-05-12 a las 11:03:43

Hora de finalización (formato ISO 8601): El problema sigue ocurriendo en el momento de este informe

Resumen del problema:

El cron /cron/payments-service/sync-v2-batch con la API de lista de tareas en cola de App Engine dejó ejecutarse el 2017-05-12 a las 11:03:43. Dependemos de este trabajo para manejar los pagos correctamente.

Vimos errores del almacén de datos y la cola, y luego el cron dejó de ejecutarse. En un intento por arreglar el problema, volvimos a subir cron.xml, pero eso no lo solucionó. Este es el seguimiento del error:

[error trace]

Agradeceríamos que nos indiquen si el problema está relacionado con la API o con nuestra implementación y que nos comuniquen los próximos pasos.

¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…