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.
  • Tipo de problema: Si el problema es intermitente, transitorio o constante.

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 muestra un error…" (la sintaxis del comando es incorrecta, por lo que no podemos ejecutarla 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, 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.
  • Para las interfaces basadas en la Web, proporciona un archivo .HAR (Hhttp 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.

Tipo de problema:

  • 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. Ten en cuenta que el Protocolo de control de transmisión (TCP) está diseñado para fallas como pequeñas pérdidas 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 fáciles de solucionar porque se pueden reproducir. En este caso, indícanos los pasos para reproducir el problema, de modo que nuestros ingenieros de asistencia puedan replicar el entorno y solucionar el problema.

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 los procedimientos de asistencia de Cloud.

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 tiene una tasa notoria de errores que afectan a los usuarios o hay dificultad 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, procesos de negocios menores afectados, etcétera).
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 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.

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 (en un plazo de 15 minutos para clientes empresariales y de hasta una hora para clientes con Asistencia por función y Función de producción). Después de ello, recibirás actualizaciones periódicas.

Agradecemos los comentarios detallados que respaldan el nivel de prioridad elegido, ya que nos ayuda a responder de forma adecuada.

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 de atención continua. Estos problemas se reasignan a un nuevo ingeniero de asistencia activo varias veces al día.

Aumenta 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.

Cuando se aumenta la prioridad de un caso de ayuda de GCP, se notifica inmediatamente a un administrador de asistencia que te brindará información actualizada en una hora o menos. El administrador de elevación será el encargado de la nueva prioridad hasta el cierre del caso. El administrador identificará y abordará la causa raíz del aumento de prioridad y notificará las acciones preventivas para evitar aumentos similares en el futuro.

Puedes solicitar el aumento de prioridad de un caso en los comentarios del caso actual o hacer clic en el botón Escalar caso que aparece 60 minutos después de crearlo.

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 utilizamos MTR o tcptraceroute porque tienen una mejor capacidad de diagnóstico, por lo 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

Inicié una transferencia de archivos el 20/04/2017 a las 20:14:43 PDT con la API de transferencia. Este trabajo suele tardar 10 minutos en completarse, pero en este caso, aún se estaba ejecutando cuando lo cancelé al día siguiente (21-04-2017 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 trabajo cron /cron/payments-service/sync-v2-batch, que usa la API de lista de tareas en cola de App Engine, dejó de ejecutarse desde el 12/05/2017 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 indiques si el problema está relacionado con la API o con nuestra implementación y que nos comuniques los próximos pasos.