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

En esta guía se incluyen las prácticas recomendadas para escribir una solicitud de asistencia eficaz. Si sigues estas prácticas recomendadas, podremos resolver tu incidencia de asistencia técnica más rápido.

Crear un caso de asistencia

Antes de crear un caso de asistencia, consulta los problemas conocidos para ver si ya se ha enviado un caso.

Para evitar confusiones y poder hacer un seguimiento de tu solicitud en un único punto, crea un caso de asistencia por cada problema. Se cierran los casos duplicados que se creen.

Describir el problema

Si escribes una incidencia de asistencia detallada, el equipo de Atención al Cliente podrá responderte de forma rápida y eficiente. Si faltan detalles importantes en tu caso de asistencia, tendremos que pedirte más información, lo que lleva más tiempo.

Los mejores casos de asistencia son detallados y específicos. Nos indican qué ha ocurrido y qué esperabas que ocurriera. Cuando describas el problema en tu caso de asistencia, incluye los siguientes detalles:

  • Hora: la marca de tiempo específica en la que empezó el problema.
  • Producto: los productos y las funciones asociados al problema.
  • Ubicación: las zonas en las que se produce el problema.
  • Identificadores: el ID del proyecto o de la aplicación y otros identificadores concretos que nos ayuden a investigar el problema.
  • Artefactos útiles: cualquier detalle que puedas proporcionar para ayudarnos a diagnosticar el problema.
  • Tipo de problema: si el problema es intermitente, transitorio o constante.

En las secciones siguientes se describen estos conceptos con más detalle.

Hora

Indícanos la fecha y la marca de tiempo en formato ISO 8601, cuándo notaste este problema por primera vez y cuánto tiempo duró.

Ejemplos:

  • A partir del 2017-09-08T15:13:06+00:00 y durante 5 minutos, hemos observado lo siguiente:
  • Se ha observado de forma intermitente, a partir del 10-09-2017, y se ha observado entre 2 y 5 veces...
  • En curso desde 2017-09-08T15:13:06+00:00...
  • Desde 2017-09-08T15:13:06+00:00 hasta 2017-09-08T15:18:16+00:00...

Es muy probable que el especialista del equipo de Atención al Cliente que resuelva el problema no se encuentre en tu zona horaria, por lo que las afirmaciones relativas como las siguientes dificultan el diagnóstico:

  • "Esto empezó ayer en algún momento..." (Nos obliga a inferir la fecha implícita).
  • "Hemos detectado el problema el 8/9..." (Es ambiguo, ya que algunos podrían interpretar esta fecha como el 8 de septiembre y otros como el 9 de agosto).

Producto

Aunque en el formulario básico de asistencia se le pide que especifique el nombre de un producto, necesitamos información específica sobre la función de ese producto que tiene el problema. Lo ideal es que el informe haga referencia a APIs o URLs de la consola específicas (o capturas de pantalla). Google Cloud En el caso de las APIs, puede incluir un enlace a la página de documentación, que contiene el nombre del producto en la URL.

Indícanos también el mecanismo que utilizas para iniciar la solicitud (por ejemplo, la API REST, la CLI de Google Cloud, la consola Google Cloud o una herramienta como Cloud Deployment Manager). Si hay varios productos implicados, indícanos el nombre de cada uno de ellos.

Ejemplos:

  • "La API REST de Compute Engine ha devuelto 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 como para saber dónde buscar al diagnosticar el problema:

  • "No se pueden crear instancias..." (Necesitamos saber el método que usas para crear instancias).
  • "El comando gcloud compute create instances da error..."(La sintaxis del comando es incorrecta, por lo que no podemos ejecutarlo para reproducir el error. Además, no sabemos qué error has visto exactamente.

Ubicación

Necesitamos saber la región y la zona de tu centro de datos porque solemos implementar cambios en una región o zona a la vez. La región y la zona son un proxy del número de versión del software subyacente. Esta información nos ayuda a saber si los cambios incompatibles de una versión concreta de nuestro software afectan a tus sistemas.

Ejemplos:

  • "En us-east1-b ..."
  • "He probado las regiones us-east1 y us-central1..."

Identificadores

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

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

  • IDs de instancia.
  • IDs de tareas o nombres de tablas de BigQuery.
  • Direcciones IP.

Cuando especifique una dirección IP, indíquenos también el contexto en el que se usa. Por ejemplo, especifica si la IP está conectada a una instancia de Compute, un balanceador de carga, una ruta personalizada o un endpoint de API. Indícanos también si la dirección IP no está relacionada con los sistemas de Google (por ejemplo, si la dirección IP es de tu conexión a Internet doméstica, un endpoint de VPN o un sistema de monitorización externo).

Ejemplos:

  • "En el proyecto nombre-robot-165473 o mi-id-proyecto..."
  • "En varios proyectos (incluido my-project-id)..."
  • "Conectando con la IP externa 218.239.8.9 desde nuestra pasarela corporativa 56.56.56.56..." Google Cloud

Las afirmaciones generales como las siguientes son demasiado genéricas para ayudar a diagnosticar el problema:

  • "No se puede acceder a una de nuestras instancias..."
  • "No podemos conectarnos a Internet..."

Artefactos útiles

Si nos proporciona artefactos relacionados con el problema, acelerará el proceso de solución, ya que nos ayudará a ver exactamente lo que ve usted.

Por ejemplo:

  • Usa una captura de pantalla para mostrar exactamente lo que ves.
  • En el caso de las interfaces basadas en web, proporciona la información de seguimiento del navegador pertinente.
  • Adjunta la salida de tcpdump, fragmentos de registros y ejemplos de rastreos de pila.

Tipo de problema

  • Intermitente: los problemas intermitentes se producen de forma aleatoria sin patrones de fallo regulares. Los problemas intermitentes son difíciles de solucionar porque su irregularidad dificulta la recogida de datos durante el fallo. En este caso, debe intentar identificar los cuellos de botella en la arquitectura y comprobar si sus recursos están alcanzando sus umbrales máximos de uso. También puedes ejecutar comprobaciones frecuentes en un trabajo programado mediante la automatización y, si la comprobación falla, recoger información de depuración durante el fallo. Algunos ejemplos de este tipo de fallo son los errores de resolución de DNS y la pérdida de paquetes.

  • Transitorio: los problemas transitorios son momentáneos o solo duran un breve periodo. Si tienes problemas que solo duran un segundo o unos pocos microsegundos, puedes comprobar si hay microexplosiones de tráfico o picos de uso de recursos. En la mayoría de los casos, los problemas transitorios se pueden ignorar si no se repiten a menudo y si tu servicio está diseñado para tolerar fallos transitorios. Algunos ejemplos de este tipo de fallos son los picos de latencia de red que se producen solo durante unos microsegundos y las pequeñas pérdidas de paquetes que provocan que se agote el tiempo de espera. El protocolo de control de la transmisión (TCP) se ha diseñado para fallos, como la pérdida de paquetes pequeños y los picos de latencia, y puede gestionar estos problemas de forma eficaz, a menos que tu aplicación sea sensible a la latencia.

  • Constantes: son problemas que fallan por completo, como cuando tu sitio web está inactivo. Los problemas constantes son relativamente fáciles de solucionar porque se pueden reproducir. En ese caso, indícanos los pasos para reproducir el problema para que nuestros especialistas del equipo de Asistencia puedan replicar el entorno y ayudarte a solucionarlo.

Descripciones de ejemplo

En los siguientes ejemplos se ofrecen descripciones detalladas de casos de asistencia.

Ejemplo 1

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.

Ejemplo 2

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.

Definir la prioridad y derivar

La prioridad nos ayuda a entender el impacto que tiene este problema en tu empresa y afecta a la rapidez con la que respondemos para resolverlo. Las prioridades se definen en la siguiente tabla. Puedes consultar más información en Prioridad de las solicitudes de asistencia.

Definición de prioridad Situación de ejemplo
P1: impacto crítico (el servicio no se puede utilizar en producción) La aplicación o la infraestructura no se pueden usar en producción y tienen una tasa significativa de errores visibles para los usuarios. El impacto en la empresa es crítico (pérdida de ingresos, posible problema de integridad de los datos, etc.).
P2: impacto alto (el servicio se ha visto gravemente afectado) La infraestructura está degradada en producción y tiene una tasa notable de errores visibles para los usuarios o dificultades para poner en marcha un nuevo sistema de producción. El impacto en la empresa es moderado (peligro de pérdida de ingresos, disminución de la productividad, etc.).
P3: impacto medio (el servicio se ha visto parcialmente afectado) El problema tiene un alcance o una gravedad limitados. La incidencia no tiene ningún impacto visible para los usuarios. El impacto en la empresa es bajo (por ejemplo, inconvenientes o procesos empresariales menores afectados).
P4: impacto bajo (el servicio está totalmente operativo) El impacto técnico o en el negocio es mínimo o nulo. Recomendado para consultas en las que se prefiera un análisis en profundidad, una solución de problemas o una asesoría a comunicaciones más frecuentes.

Cuándo definir la prioridad más alta

Si tienes un problema que afecta a servicios críticos para tu empresa y necesitas que Google te preste atención de inmediato, elige "P1" como prioridad. Explícanos con detalle por qué has seleccionado P1. Incluye una breve descripción del impacto que está teniendo este problema en tu empresa. Por ejemplo, puedes considerar que un problema con una versión de desarrollo es P1, aunque no afecte directamente a ningún usuario final, si impide aplicar una corrección de seguridad crítica.

Cuando se asigna la prioridad P1 a un caso, se alerta inmediatamente a un experto para que trabaje exclusivamente en el problema. Recibirás una respuesta inicial rápida para unirte a una llamada de asistencia en directo a través de Google Meet. Si tu organización no puede usar Google Meet, incluye un enlace al software de videoconferencia que prefieras para que el experto pueda unirse. Después, recibirás actualizaciones periódicas a través del caso.

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

Qué puedes esperar de la asistencia en los casos de prioridad P1

  • Nuevo caso de prioridad P1

    • Un experto del equipo de Asistencia se pondrá en contacto contigo a través de Google Meet o de cualquier otro medio que le proporciones. Esperamos que te unas a la llamada en un plazo de entre 15 y 30 minutos. Informa al experto del equipo de Asistencia si no puedes unirte a la llamada por algún motivo.
    • De forma predeterminada, el caso "sigue al sol". Esto significa que los expertos del equipo de Asistencia están disponibles las 24 horas del día hasta que se resuelve el problema o se reduce su prioridad. Si la mitigación de un caso se debe llevar a cabo en una región específica, se puede bloquear en una zona horaria determinada. Puedes indicarnos si prefieres que se aplique este efecto.

  • Aumento de la prioridad P1

    • Si el problema ha empezado a afectar a tu entorno de producción o está a punto de hacerlo, puedes aumentar la prioridad de un caso de asistencia de P2 a P4 a P1.
    • Si aumentas la prioridad de un caso a P1, es posible que se reasigne para que un experto de Asistencia disponible pueda prestarte atención inmediata.

  • Impacto en entornos de no producción

    Para asegurarnos de que se asignan los recursos adecuados donde sea necesario, es posible que el equipo de Asistencia se ponga en contacto contigo para volver a evaluar los casos marcados como P1 que no afecten a la producción ni tengan un impacto empresarial alto.

Tiempos de respuesta

Los niveles de prioridad de los problemas tienen tiempos de respuesta predefinidos que se especifican en las directrices de los servicios de asistencia técnica de Google Cloud Platform. Si necesitas una respuesta antes de una hora concreta, indícalo en la descripción de tu denuncia. Si un problema de prioridad 1 requiere atención las 24 horas, puedes solicitar el servicio de seguimiento solar. Estos casos se reasignan varias veces al día a un especialista de Atención al Cliente activo. Mientras investigamos tu caso de prioridad P1, te recomendamos que sigas participando para responder a las preguntas hasta que se resuelva el problema y así facilitar la comunicación. Si no respondes en un plazo de 3 horas, es posible que reduzcamos la prioridad del caso a P2 hasta que vuelvas a ponerte en contacto con nosotros.

Derivación

Si las circunstancias cambian, es posible que tengas que derivar un problema. Estos son algunos motivos de peso para derivar el problema:

  • Aumento del impacto empresarial.
  • Desglose del proceso de resolución. Por ejemplo, si no has recibido ninguna novedad en el plazo acordado o si tu problema no avanza después de intercambiar varios mensajes.

Cuando se produce un problema grave, la mejor solución es asignar al caso la prioridad adecuada durante un tiempo suficiente, en lugar de derivarlo. Derivar un caso no significa que se vaya a resolver más rápido y, si lo haces poco después de cambiar la prioridad, puede que incluso se tarde más en resolverlo. Puedes consultar una explicación más detallada en el vídeo Cuándo debes derivar.

Para obtener información sobre cómo derivar un caso, consulte Derivar un caso.

Derivar las incidencias a la zona horaria necesaria

Debido a los factores en los que se basa la disponibilidad del servicio de atención al cliente, es posible que tu caso de asistencia se asigne a un especialista que trabaje fuera de tu horario de apertura. También es posible que quieras ponerte en contacto con el equipo de Asistencia en los días hábiles de una zona horaria específica. En estos casos, te recomendamos que solicites al equipo de Atención al Cliente que derive tu caso de asistencia a una zona horaria que te venga bien. Puedes añadir 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 de prioridad 1 se transfieren al servicio de atención al cliente de la siguiente región porque sigue el sol, mientras que los demás casos se quedan con el propietario actual para que siga trabajando en ellos al día siguiente.

Enviar comentarios con la encuesta de esfuerzo del cliente

Cuando se resuelva un caso, se te enviará por correo una encuesta de CES (Customer Effort Score) para que nos digas qué te ha parecido el proceso. Te agradeceríamos que dedicaras unos minutos a rellenarla para saber qué hemos hecho bien y cuáles han sido los retos, de modo que podamos mejorar estos aspectos.

El equipo de Experiencia del Cliente revisa manualmente todos los formularios de comentarios y toma las medidas correspondientes para mejorar tu experiencia en el futuro. La puntuación será sobre 5. Una puntuación de 3 o inferior se consideraría difícil desde el punto de vista del cliente. 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 considera una experiencia positiva.

Para obtener más información, consulta el vídeo Cómo enviar comentarios sobre los servicios Google Cloud con CES.

Problemas prolongados o difíciles

Los problemas que tardan mucho en resolverse pueden volverse confusos y obsoletos. La mejor forma de evitarlo es recoger información mediante nuestra plantilla de problema de larga duración, con el estado más reciente resumido en la parte superior.

Para usar la plantilla, abre el enlace anterior y haz una copia. Incluye enlaces a todos los casos pertinentes y errores de seguimiento internos. Comparte este documento con el grupo de tu equipo de cuenta y pídele que lo comparta con especialistas concretos del equipo de Asistencia.

Este documento incluye lo siguiente:

  • Un resumen del estado actual en la parte superior.
  • Una lista de las hipótesis que pueden ser verdaderas.
  • Las pruebas o herramientas que tienes intención de usar para probar cada hipótesis.

Intenta que cada caso se centre en un solo problema y no vuelvas a abrir un caso para plantear un problema nuevo.

Informar de una interrupción de la producción

Si el problema ha provocado que tu aplicación deje de servir tráfico a los usuarios o tiene un impacto similar en la actividad empresarial, es posible que se trate de una interrupción de la producción. Queremos saberlo lo antes posible. En cambio, los problemas que afectan a un número reducido de desarrolladores no se consideran interrupciones de producción.

Cuando recibimos un informe sobre una interrupción de la producción, clasificamos rápidamente la situación de la siguiente manera:

  • Comprobando inmediatamente si hay problemas conocidos que afecten a la infraestructura de Google Cloud .
  • Confirmar la naturaleza del problema.
  • Establecer canales de comunicación.

Recibirás una respuesta con un breve mensaje que incluye lo siguiente:

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

Por lo tanto, es importante crear rápidamente un caso que incluya la hora, el producto, los identificadores y la ubicación, y, a continuación, empezar a solucionar el problema en profundidad. Es posible que tu organización tenga un proceso de gestión de incidentes definido, por lo que este paso debería ejecutarse al principio.

El proceso de gestión de incidentes de Google define un rol clave: el responsable del incidente. Esta persona se asegura de que participen las personas adecuadas, recoge continuamente la información más reciente y resume periódicamente el estado del problema. Delega en otros usuarios para solucionar problemas y aplicar cambios. Esta delegación nos permite investigar varias hipótesis en paralelo. Te recomendamos que establezcas un proceso similar en tu organización. La persona que ha abierto el caso suele ser la más adecuada para dirigir el incidente, ya que tiene más contexto.

Informar de un problema de red

El tamaño y la complejidad de la red de Google pueden dificultar la identificación del equipo responsable del problema. Para diagnosticar problemas de red, debemos identificar las causas principales específicas. Como los mensajes de error de red suelen ser generales (por ejemplo, "No se puede conectar al servidor"), necesitamos recoger información de diagnóstico detallada para acotar las posibles hipótesis.

Los diagramas de flujo de paquetes proporcionan una estructura excelente para el informe de problemas. En estos diagramas se describen los saltos importantes que da un paquete a lo largo de una ruta desde el origen hasta el destino, así como las transformaciones significativas que se producen durante el trayecto.

Empieza por identificar los endpoints de 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.

Anota cualquier información relevante sobre los endpoints, como la siguiente:

  • Quién los controla.
  • Si están asociados a un nombre de host DNS.
  • Cualquier encapsulación o indirección intermedias, o ambas, como la tunelización de VPN, los proxies y las pasarelas NAT.
  • Cualquier filtrado intermedio, como cortafuegos, CDN o WAF.

Muchos problemas que se manifiestan como una latencia alta o una pérdida de paquetes intermitente requieren un análisis de ruta o una captura de paquetes, o ambos, para poder diagnosticar el problema.

  • El análisis de rutas es una lista de todos los saltos que atraviesan los paquetes y se conoce como "traceroute". A menudo usamos MTR o tcptraceroute, o ambos, porque tienen una mayor capacidad de diagnóstico. Te recomendamos que te familiarices con estas herramientas.
  • La captura de paquetes (también conocida como "pcap", del nombre de la biblioteca "libpcap") es una observación del tráfico de red real. Es importante hacer una captura de paquetes de ambos endpoints al mismo tiempo, lo que puede ser complicado. Te recomendamos que practiques con las herramientas necesarias (por ejemplo, tcpdump o Wireshark) y que te asegures de que están instaladas antes de necesitarlas.

Informar de un problema con la consola Google Cloud

Cuando informes de un problema con la consola web, además de las indicaciones anteriores, proporciona la siguiente información para ayudarnos a acotar las posibles causas del problema: Google Cloud

  • URLs de las páginas de la consola afectadas
  • IDs de los proyectos afectados
  • Número de usuarios afectados
  • Si el problema se produce en diferentes ordenadores
  • Navegadores afectados
  • Las extensiones del navegador o los sistemas de cortafuegos que se estén usando

Además, si incluye cualquier información de seguimiento del navegador pertinente, nos ayudará a entender e investigar el problema.