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

En esta guía, se proporcionan las prácticas recomendadas para redactar una asistencia eficaz para determinar si este es el caso. Seguir estas prácticas recomendadas nos ayuda a resolver tu asistencia técnica más rápido.

Crea un caso de asistencia

Antes de crear un caso de asistencia, revisa la problemas para ver si caso ya fue presentado.

Para evitar confusiones y que podamos hacer un seguimiento de su solicitud en un solo punto, crea un caso de asistencia por problema. Los casos duplicados que se crean cerrado.

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 tu caso de asistencia es si faltan detalles críticos, necesitamos solicitar más información, lo que demora 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 tu 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 el ID de aplicación y otros identificadores concretos que nos ayudan 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

Con el formato ISO 8601 para la fecha y la marca de tiempo, cuéntanos cuándo notaste el problema por primera vez y cómo lo que duró.

Ejemplos:

  • Desde 2017-09-08T15:13:06+00:00 y hasta 5 minutos después, observado...
  • 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 está solucionando el problema no esté en tu zona horaria, de modo que las instrucciones relativas como las siguientes dificultan el problema para diagnosticar:

  • “Esto comenzó en algún momento de ayer…” (nos obliga a inferir la fecha implícita).
  • "Detectamos el problema el 8/9..." (Es ambiguo, ya que algunos podrían interpretar esto fecha como 8 de septiembre y otros podrían interpretarlo como 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 acerca del mecanismo que estás usando para iniciar la solicitud (por 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, proporciona cada uno en su nombre específico.

Ejemplos:

  • “La API de REST de Compute Engine mostró los siguientes errores...”
  • “La interfaz de consulta de BigQuery en console.cloud.google.com es pasando el rato..."

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..." (el es incorrecta, por lo que no podemos ejecutarlo nosotros mismos para reproducir el . 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. Para 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. Indícanos también si la dirección IP no es relacionados con los sistemas de Google (por ejemplo, si la dirección IP es de tu casa Internet, 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 Gateway 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 .HAR (HTTP) ARchive). El HAR analizador 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 lo hacen. repetirse con frecuencia y si tu servicio está diseñado para tolerar situaciones transitorias fallas. 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 una pequeña 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 porque se pueden reproducir. En este caso, indica los pasos que debes seguir. reproducir el problema para 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 encontrar más información en Caso de asistencia prioridad.

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 se degrada en la producción y tiene una tasa notable. de errores que enfrentan 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 empresariales menores afectados).
P4: Impacto bajo (servicio totalmente utilizable) El impacto técnico o comercial del problema es escaso o nulo. Recomendado 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é elegiste P1. Incluye una breve descripción del impacto de este problema. tiene en tu empresa. Por ejemplo, podrías considerar un problema con un desarrollador sea P1, incluso si ningún usuario final se ve directamente afectado, si es una solución de seguridad crítica.

Cuando un caso se configura como P1, se alerta de inmediato a un experto para que trabaje exclusivamente sobre el problema. Recibirás una respuesta inicial rápida para unirte a una reunión para solucionar problemas por medio de Google Meet. Si tu organización no puede usar Google Meet, incluye un vínculo al software de videoconferencia que elijas para que se una el experto. Después, recibirás actualizaciones periódicas a través de la para determinar si este es el 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 por medio de Google Meet o cualquier otro puente que brindas. Esperamos que te unas a la llamada en un plazo de 15 a 30 minutos. minutos. Infórmale al experto del equipo de asistencia si no puedes unirte a la llamada y por una buena razón.
    • La sentencia case “sigue al sol” de forma predeterminada. Esto significa que los expertos en asistencia interactuar las 24 horas del día hasta que el caso se mitigue o deje de priorizar. Si el caso la mitigación se persigue mejor en una región específica, ese caso puede quedar limitado a 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 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 pueden reasignarse para permitir que un experto disponible proporcione asistencia atención.

  • Impacto en la no producción

    Para garantizar que se asignen los recursos adecuados cuando sea necesario, es posible que el equipo interactuar contigo para reevaluar los casos marcados como P1 que no tienen impacto o que causen un alto impacto comercial.

Tiempos de respuesta

Los niveles de prioridad de los problemas tienen tiempos de respuesta predefinidos que se definen en la página Lineamientos de los servicios de asistencia técnica de Cloud Platform Si necesitas una respuesta antes de un momento específico, avísanos en la descripción de tu informe. Si es un modelo P1 se debe gestionar las 24 horas del día, puedes solicitar "sigue el sol". Estos los casos se reasignan varias veces al día a un equipo activo de Atención al cliente especialista. Mientras solucionamos tu caso P1, te recomendamos que sigas que están comprometidos a responder preguntas hasta la resolución para facilitar la comunicación. 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. Buenas razones para la derivación son las siguientes:

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

Si experimentas un problema de alto impacto, la mejor solución es establecer la con la prioridad adecuada por una cantidad de tiempo adecuada, en lugar de elevando la escala. La derivación no necesariamente resuelve el caso más rápido y escalar poco después del cambio de prioridad incluso puede hacer que la resolución del caso puede ser más lento. Encontrarás una explicación más detallada en la sección ¿Cuándo debes deriva el video.

Para obtener información sobre cómo derivar un caso, consulta Cómo derivar un caso a caso.

Dirige los casos a la zona horaria requerida

Debido a los factores por los que el servicio de atención al cliente disponibilidad se basa, el el caso de asistencia podría asignarse a un especialista en atención al cliente que fuera de tu horario de atención. También es posible que quieras interactuar con atención al cliente durante los días hábiles de una zona horaria específica. En en estos casos, le recomendamos que solicite al servicio de atención al cliente que dirija su a una zona horaria que sea conveniente para tu caso. Puedes agregar esto solicitar en la descripción o respuesta de su caso. Por ejemplo, Please route this case to the Pacific time zone (GMT-8) Los casos P1 se transfieren a los siguientes región de Atención al cliente porque sigue las sol mientras que, en otros casos, se quedaría con el propietario actual del caso para seguir trabajando en él. el caso al día siguiente.

Proporciona comentarios con la encuesta CES

Cuando se resuelve un caso, se lleva a cabo una encuesta de Puntuación del esfuerzo del cliente (CES) relacionada con tu su opinión sobre el proceso se enviaría por correo electrónico. Realmente te agradecemos si puedes tomarte unos minutos para completarlo, de modo que sabremos qué hicimos bien y cuáles fueron los desafíos para mejorar esos aspectos.

El equipo de Experiencia del cliente revisa manualmente todos los formularios de comentarios y los resultados en las acciones correspondientes para mejorar tu experiencia futura. Puntuación será de 5. Una puntuación de 3 o menos se consideraría difícil desde el del cliente, y realizaremos un seguimiento contigo sobre estas respuestas. Del otro 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, mira el video How to Submit Google Cloud Services Feedback 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 usar la plantilla, abre el vínculo anterior y haz una copia. Incluir vínculos a todos los casos relevantes y errores de seguimiento interno. Compartir este documento con con el grupo del equipo de cuentas y pedirles que lo compartan Especialistas en 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 tiene un impacto crítico similar para la empresa, ya que podría tratarse de una interrupción en 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. Tu organización podría tener un proceso definido de administración de incidentes, y este paso se debe ejecutar 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.

Comience por identificar los extremos de la red afectados por la dirección IP de Internet o por Dirección privada RFC 1918 y más un identificador para 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 de alta latencia o pérdida intermitente de paquetes requieran 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”. Solemos usar MTR o tcptraceroute o ambos porque tienen una mejor capacidad de diagnóstico. Te recomendamos familiarizarte con estas herramientas.
  • 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 para ambos extremos al mismo tiempo, lo cual puede ser complicado. Es recomendable que practiques con las herramientas necesarias (por ejemplo, tcpdump Wireshark) y de que estén instalados antes de que los necesites.