Confiabilidad

En esta sección del framework de arquitectura, se describe cómo aplicar requisitos técnicos y de procedimiento para diseñar y operar servicios confiables en Google Cloud.

El framework consta de la siguiente serie de documentos:

La confiabilidad es la función más importante de cualquier aplicación, ya que si la aplicación no es confiable, los usuarios se irán y las otras funciones ya no serán importantes.

  • Una aplicación debe tener objetivos de confiabilidad medibles, y las desviaciones deben corregirse de inmediato.
  • La aplicación debe estar diseñada para la escalabilidad, la alta disponibilidad y la administración automatizada de cambios.
  • La aplicación debe ser autorreparable siempre que sea posible y debe estar instrumentada para la observabilidad.
  • Los procedimientos operativos que se usan para ejecutar la aplicación deben imponer un trabajo manual mínimo y una carga cognitiva a los operadores, a la vez que garantizan una mitigación de errores rápida.

Estrategias

Usa estas estrategias para lograr la confiabilidad.

El usuario define la confiabilidad. Para las cargas de trabajo orientadas al usuario, debes medir la experiencia del usuario, por ejemplo, la tasa de éxito de las consultas, en lugar de solo las métricas del servidor, como el uso de CPU. En el caso de las cargas de trabajo por lotes y de transmisión, es posible que debas medir los KPI (indicadores clave de rendimiento), como las filas que se analizan por ventana de tiempo, para garantizar que un informe trimestral finalice a tiempo, en lugar de solo las métricas del servidor, como el uso del disco.

Usa confiabilidad suficiente. Tus sistemas deben ser lo bastante confiables a fin de que los usuarios estén satisfechos, pero no deben ser demasiado confiables para que la inversión sea injustificada. Define los objetivos de nivel de servicio (SLO) que establecen el umbral de confiabilidad y usa porcentajes de error aceptable para administrar la frecuencia de cambio. Aplica los principios adicionales que se indican a continuación solo si el SLO justifica el costo.

Crea redundancia. Los sistemas con necesidades con alta confiabilidad no deben tener puntos únicos de fallo, y sus recursos deben replicarse en varios dominios con fallas. Un dominio con fallas es un grupo de recursos que pueden fallar de forma independiente, como una VM, una zona o una región.

Incluye escalabilidad horizontal. Agrega más recursos para asegurarte de que cada componente de tu sistema pueda adaptarse al crecimiento del tráfico o los datos.

Garantiza la tolerancia a la sobrecarga. Diseña los servicios para que se reduzcan con facilidad bajo carga.

Incluye la función de reversión. Cualquier cambio que un operador realice en un servicio debe tener un método bien definido que permita deshacerlo, es decir, para revertir el cambio.

Evita los aumentos repentinos de tráfico. No sincronices solicitudes entre clientes. Si demasiados clientes envían tráfico en el mismo instante, se provocarán aumentos repentinos de tráfico que, en el peor de los casos, causarán fallas en cascada.

Prueba la recuperación de errores. Es probable que tus procedimientos operativos no funcionen cuando los necesites si no los probaste recientemente para recuperarte ante fallas. Los elementos que se deben probar de forma periódica incluyen la conmutación por error regional, la reversión de una actualización y el restablecimiento de los datos de las copias de seguridad.

Detecta fallas. Existe una compensación entre las alertas que se crean demasiado pronto y el agotamiento del equipo de operaciones, en comparación con las alertas que se crean demasiado tarde y las interrupciones prolongadas del servicio. El retraso antes de que se notifique a los operadores sobre interrupciones (también conocido como tiempo de detección o TTD) debe ajustarse para esta compensación.

Realiza cambios incrementales. Los cambios globales instantáneos en la configuración o los objetos binarios del servicio son riesgosos por naturaleza. Te recomendamos implementar los cambios de forma gradual, con “pruebas canary” para detectar errores en las primeras etapas de un lanzamiento en el que su impacto en los usuarios sea mínimo.

Ten una respuesta de emergencia coordinada. Diseña prácticas operativas para minimizar la duración de las interrupciones (también conocidas como tiempo de mitigación o TTM) y ten en cuenta la experiencia del cliente y el bienestar de los operadores. Este enfoque requiere una formalización avanzada de los procedimientos de respuesta con funciones y canales de comunicación bien definidos.

Instrumenta a los sistemas para la observabilidad. Los sistemas deben estar bien instrumentados para habilitar la evaluación rápida, la solución de problemas y el diagnóstico de problemas a fin de minimizar el TTM.

Documenta y automatiza las respuestas de emergencia. En una emergencia, las personas tienen dificultades para definir lo que se debe hacer y realizar tareas complejas. Por lo tanto, debes planificar las acciones de emergencia con anterioridad, documentarlas y, de manera ideal, automatizarlas.

Administra la capacidad. Prevé el tráfico y aprovisiona recursos antes de que se generen los eventos de tráfico máximo.

Reduce el trabajo manual. El trabajo manual es repetitivo, sin valor permanente y aumenta a medida que el servicio crece. Intenta reducir o eliminar el trabajo manual de forma continua. De lo contrario, el trabajo operativo sobrecargará a los operadores, y habrá pocas posibilidades para el crecimiento.

Prácticas recomendadas

Sigue estas prácticas recomendadas para alcanzar la confiabilidad.

  • Define tus objetivos de confiabilidad mediante objetivos de nivel de servicio (SLO) y porcentajes de error aceptable.
  • Genera observabilidad en tu infraestructura y aplicaciones.
  • Diseña para gran escala y alta disponibilidad.
  • Compila capacidades de implementación flexibles y automatizadas.
  • Genera alertas eficientes.
  • Genera un proceso colaborativo para la administración de incidentes.

Define tus objetivos de confiabilidad

Te recomendamos medir la experiencia del cliente existente, su tolerancia a fallas y errores y establecer objetivos de confiabilidad basados en estos eventos. Por ejemplo, no se puede alcanzar un objetivo de tiempo de actividad general del sistema del 100% durante un período infinito y no es significativo si los datos que el usuario espera no están allí.

Establece los SLO según la experiencia del usuario. Mide las métricas de confiabilidad lo más cerca posible del usuario. Si es posible, instrumenta al cliente web o móvil. Si eso no es posible, instrumenta el balanceador de cargas. Medir la confiabilidad en el servidor debe ser el último recurso. Establece el SLO lo bastante alto hasta que el usuario esté satisfecho, pero no más alto que eso.

Debido a la conectividad de red o a otros problemas transitorios del cliente, es posible que tus clientes no perciban algunos problemas de confiabilidad que causa la aplicación durante períodos breves.

Te recomendamos buscar un objetivo inferior pero cercano al 100% para el tiempo de actividad y otras métricas vitales. Este objetivo permite que cualquier persona entregue software más rápido y de alta calidad. También es cierto que, en muchos casos, con un sistema diseñado de forma correcta, se puede lograr una mayor disponibilidad si se reduce el ritmo y el volumen de los cambios.

En otras palabras, los objetivos de confiabilidad que se pueden alcanzar y se ajustan a la experiencia del cliente suelen ayudar a definir el ritmo máximo y el alcance de los cambios (es decir, la velocidad de la función) que los clientes pueden tolerar.

Si no puedes medir la experiencia del cliente existente y definir sus objetivos, te recomendamos un análisis comparativo competitivo. Si no existe una competencia comparable, mide la experiencia del cliente, incluso si aún no puedes definir objetivos; por ejemplo, la disponibilidad del sistema o la tasa de transacciones significativas y exitosas para el cliente. Puedes correlacionar esto con las métricas empresariales o los KPI, como el volumen de pedidos (venta minorista), el volumen de llamadas y tickets de asistencia al cliente y su gravedad, etc. Luego de un tiempo, puedes usar esos ejercicios de correlación para obtener un umbral razonable de satisfacción del cliente, es decir, SLO.

SLI, SLO y ANS

Un indicador de nivel de servicio (SLI) es una medida cuantitativa de algún aspecto del nivel de servicio que se proporciona. Es una métrica, no un objetivo.

Los objetivos de nivel de servicio (SLO) especifican un nivel objetivo para la confiabilidad de tu servicio. Debido a que los SLO son clave para tomar decisiones sobre la confiabilidad basadas en datos, son el núcleo de las prácticas de SRE. El SLO es un valor para un SLI y, cuando el SLI es igual o superior a este, el servicio se considera “bastante confiable”.

Los porcentajes de error aceptable se calculan como (100% – SLO) durante un período. Indican si tu sistema es más o menos confiable de lo necesario en una ventana de tiempo determinada. Por lo general, recomendamos usar una ventana móvil de 30 días.

Los acuerdos de nivel de servicio (ANS) son un contrato explícito o implícito con los usuarios que incluye las consecuencias de cumplir (o no) con los SLO que contienen.

Se recomienda tener SLO internos más estrictos que los externos. La lógica de este enfoque es que el incumplimiento del ANS suele requerir la emisión de un crédito financiero o un reembolso del cliente, y debes abordar los problemas mucho antes de que tengan un impacto financiero. Recomendamos adjuntar SLO internos más estrictos a un proceso a posteriori libre de responsabilidades con revisiones de incidentes.

Si la aplicación tiene una arquitectura multiusuario, típica de las aplicaciones de SaaS que usan varios clientes independientes, asegúrate de capturar los SLI a nivel de usuario. Si mides los SLI solo a nivel global, la supervisión no podrá marcar problemas críticos que afecten a clientes individuales o a una minoría de ellos. Diseña la aplicación para incluir un identificador de usuarios en cada solicitud y propaga ese identificador a través de cada capa de la pila. Propagar este identificador permite que tu sistema de supervisión agregue estadísticas a nivel de usuario en cada capa o microservicio a lo largo de la ruta de la solicitud.

Porcentaje de error aceptable

Usa porcentajes de error aceptable para administrar la velocidad de desarrollo. Si el porcentaje de error aceptable aún no se consumió, sigue lanzando funciones nuevas con rapidez. Cuando el porcentaje de error aceptable sea cercano a cero, suspende o ralentiza los cambios de servicio e invierte recursos de ingeniería en funciones de confiabilidad.

Google Cloud minimiza el esfuerzo de configurar los SLO y los porcentajes de error aceptable con la supervisión de servicios. Este producto ofrece una IU a fin de configurar los SLO de forma manual, una API para la configuración programática de los SLO y paneles integrados dedicados al seguimiento del ritmo de consumo del porcentaje de error aceptable.

Ejemplos de SLI

En los sistemas de entrega, los siguientes SLI son típicos:

  • La disponibilidad indica la fracción de tiempo en que se puede usar un servicio. A menudo, se define en términos de la fracción de solicitudes con formato correcto que se ejecutan con éxito, por ejemplo, el 99%.
  • La latencia indica la rapidez con la que se puede llegar a un porcentaje determinado de solicitudes. A menudo, se define en términos de un percentil distinto de 50, por ejemplo, el percentil 99 en 300 ms.
  • La calidad indica qué tan buena es una respuesta determinada. La definición de calidad suele ser específica del servicio, lo que indica en qué medida el contenido de la respuesta a una solicitud difiere del contenido de respuesta ideal. Puede ser binaria (buena o mala) o se puede expresar en una escala del 0% al 100%.

En los sistemas de procesamiento de datos, los siguientes SLI son típicos:

  • La cobertura indica la fracción de datos que se procesaron, por ejemplo, el 99.9%.
  • La precisión indica la fracción de respuestas que se consideran correctas, por ejemplo, el 99.99%.
  • La actualidad indica qué tan recientes son los datos de origen o las respuestas agregadas; cuanto más frecuentes, mejores (por ejemplo, 20 minutos).
  • La capacidad de procesamiento indica cuántos datos se están procesando, por ejemplo, 500 MiB/s o, incluso, 1,000 RPS.

En los sistemas de almacenamiento, los siguientes SLI son comunes:

  • La durabilidad indica la probabilidad de que se recuperen los datos escritos en el sistema en el futuro, por ejemplo, el 99.9999%. Cualquier incidente relacionado con la pérdida de datos permanente reduce la métrica de durabilidad.
  • Capacidad de procesamiento y latencia (como se describieron antes)

Preguntas sobre el diseño

  • ¿Mides la experiencia del usuario de la confiabilidad de la aplicación?
  • ¿Las aplicaciones cliente están diseñadas para capturar e informar las métricas de confiabilidad?
  • ¿La arquitectura del sistema está diseñada con objetivos de confiabilidad y escalabilidad específicos?
  • En el caso de los sistemas multiusuario, ¿las solicitudes incluyen un identificador de usuarios? ¿Ese identificador se propaga a través de cada capa de la pila de software?

Recomendaciones

  • Define y mide los SLI centrados en el cliente.
  • Define un porcentaje de error aceptable centrado en el cliente que sea más estricto que tu ANS externo con consecuencias por incumplimientos, por ejemplo, bloqueos de producción.
  • Configura los SLI de latencia para capturar valores atípicos, es decir, percentil 90 o 99, a fin de detectar las respuestas más lentas.
  • Revisa los SLO una vez al año como mínimo.

Recursos

Genera observabilidad en tu infraestructura y aplicaciones

La observabilidad incluye la supervisión, el registro, el seguimiento, la generación de perfiles, la depuración y sistemas similares.

Instrumenta tu código para maximizar la observabilidad. Escribe entradas de registro y de seguimiento, y ten en cuenta la depuración y la solución de problemas cuando exportes métricas de supervisión. Para ello, prioriza los modos de falla más probables o frecuentes del sistema. Audita y reduce la supervisión de forma periódica. Para esto, borra paneles, alertas, seguimientos y registros sin usar o sin utilidad a fin de eliminar el desorden.

La supervisión es la base de la jerarquía de confiabilidad del servicio. Sin una supervisión adecuada, no puedes saber si una aplicación funciona.

Un sistema bien diseñado tiene como objetivo alcanzar una cantidad adecuada de observabilidad a partir de su fase de desarrollo. No esperes hasta que una aplicación esté en producción para comenzar a observarla.

Google Cloud's operations suite ofrece supervisión y registro en tiempo real en Google Cloud y AWS, además de seguimiento, generación de perfiles y depuración. También es capaz de supervisar una malla de servicios mediante Istio y los servicios de App Engine (Cloud Monitoring).

La supervisión de ingeniería excesiva y demasiadas alertas son antipatrones comunes. Para evitar estos antipatrones, borra de forma proactiva las series temporales, los paneles y las alertas que no usas o que raras veces se activan durante las etapas iniciales del lanzamiento externo. Esto también es válido para las entradas de registro que rara vez se analizan.

Evalúa enviar todos los eventos de la aplicación o una muestra de ellos a un almacén de datos en la nube, como BigQuery. Esto es útil porque te permite ejecutar consultas arbitrarias a un costo menor en lugar de diseñar la supervisión directamente. También separa los informes de la supervisión. Cualquier persona que use Google Data Studio o Looker puede realizar informes.

Preguntas sobre el diseño

  • ¿El proceso de revisión del diseño tiene estándares de observabilidad que orienten las revisiones de diseño y de código?
  • ¿Las métricas que exporta la aplicación son adecuadas para solucionar problemas de interrupciones?
  • ¿Las entradas de registro de la aplicación son lo suficientemente detalladas y relevantes para que sean útiles en la depuración?

Recomendaciones

  • Implementa la supervisión desde el comienzo antes de iniciar una migración o mientras compilas una aplicación nueva antes de su primera implementación de producción.
  • Distingue entre los problemas de la aplicación y los problemas subyacentes de la nube; por ejemplo, usa SLI transparente y el Panel de estado de Google Cloud.
  • Define una estrategia de observabilidad más allá de la generación de perfiles que incluya el seguimiento, la generación de perfiles y la depuración.
  • Limpia con regularidad los artefactos de observabilidad que no se usan o no son útiles, incluidas las alertas que no sean prácticas.
  • Envía eventos de aplicación (es decir, métricas de alta cardinalidad) a un sistema de almacén de datos, como BigQuery.

Diseño para gran escala y alta disponibilidad

Diseña una arquitectura multirregional con conmutación por error

Si tu servicio necesita estar activo incluso cuando una región está inactiva, diséñalo para que use grupos de recursos de procesamiento distribuidos en diferentes regiones, con conmutación por error automática cuando una región deje de funcionar. Elimina puntos únicos de fallo, como una base de datos principal de una sola región que puede causar una interrupción global cuando no se puede acceder a ella.

Elimina los cuellos de botella de escalabilidad

Identifica los componentes del sistema que no pueden crecer más allá de los límites de recursos de una sola VM o zona. Algunas aplicaciones están diseñadas para el escalamiento vertical, en el que se necesitan más núcleos de CPU, memoria o ancho de banda de red en una sola VM a fin de manejar una carga mayor. Estas aplicaciones tienen límites estrictos en cuanto a su escalabilidad y, a menudo, requieren una reconfiguración manual para manejar el crecimiento. Vuelve a diseñar estos componentes a fin de que puedan escalarse de forma horizontal mediante fragmentación (partición de VM o zonas), de manera que el crecimiento del tráfico o el uso se puedan manejar con facilidad si se agregan más fragmentos. Estos se pueden agregar de forma automática para controlar los aumentos de carga por fragmento. Como alternativa al diseño nuevo, considera reemplazar estos componentes por servicios administrados que se diseñaron para escalar de forma horizontal sin necesidad de acciones del usuario.

Degrada los niveles de servicio con facilidad

Diseña tus servicios para que detecten sobrecarga y muestren respuestas de menor calidad al usuario o dejen de recibir tráfico de forma parcial en lugar de que fallen por completo bajo sobrecarga. Por ejemplo, un servicio puede responder a las solicitudes de los usuarios con páginas web estáticas mientras inhabilita de forma temporal el comportamiento dinámico que es más costoso, o puede permitir operaciones de solo lectura mientras inhabilita de manera temporal las actualizaciones de datos.

Implementa una retirada exponencial con jitter

Cuando los clientes móviles encuentran una respuesta de error de tu servicio, deben volver a intentarlo luego de un retraso aleatorio. Si reciben errores repetidos, deberán esperar cada vez más tiempo antes de volver a intentarlo, además de agregar compensaciones horarias aleatorias (jitter) a cada operación de reintento. Esto evita que grandes grupos de clientes generen aumentos repentinos de tráfico instantáneos luego de fallas en la red móvil, ya que es posible que estos aumentos causen fallas en los servidores.

Predice eventos de tráfico máximo y planifícalos

Si tu sistema experimenta períodos conocidos de tráfico máximo, como el Black Friday en el caso de los minoristas, invierte tiempo en prepararlo para evitar una pérdida significativa de ingresos y tráfico. Prevé el tamaño del aumento repentino del tráfico, agrega un búfer y asegúrate de que tu sistema tenga suficiente capacidad de procesamiento para manejar el aumento. Prueba la carga del sistema con la combinación esperada de solicitudes de usuarios para asegurarte de que su capacidad estimada de control de cargas coincida con la capacidad real. Realiza ejercicios para que el equipo de operaciones lleve a cabo simulacros de interrupciones en los que practiquen sus procedimientos de respuesta y apliquen los procedimientos colaborativos de administración de incidentes entre equipos que se analizan a continuación.

Realiza pruebas de recuperación ante desastres

No esperes a que ocurra un desastre. Haz pruebas de forma periódica en tus procedimientos y procesos de recuperación ante desastres y verifícalos. Puede que también quieras planificar una arquitectura para alta disponibilidad (HA). No se superpone por completo con la recuperación ante desastres (DR), pero a menudo es necesario tener en cuenta la HA cuando piensas en los valores de los objetivos de tiempo de recuperación (RTO) y de los objetivos de punto de recuperación (RPO). La HA ayuda a asegurar un nivel de rendimiento operativo acordado, que suele ser el tiempo de actividad para un período mayor que el normal. Cuando ejecutas cargas de trabajo de producción en Google Cloud, puedes usar un sistema distribuido a nivel global para que, si ocurre algún error en una región, la aplicación continúe prestando servicio, incluso si se reduce su disponibilidad. En definitiva, la aplicación invoca su plan de DR.

Preguntas sobre el diseño

  • ¿La aplicación puede escalar verticalmente si agrega más VM sin cambios arquitectónicos?
  • ¿Cada componente de la arquitectura es escalable de forma horizontal mediante fragmentación o de otro modo?
  • ¿Las aplicaciones cliente están diseñadas para evitar la sincronización de solicitudes entre clientes?
  • ¿La aplicación puede manejar la falla de toda una región de la nube sin una interrupción global?
  • ¿Las solicitudes de los usuarios se distribuyen de manera uniforme entre fragmentos y regiones?
  • ¿La aplicación puede detectar cuándo está sobrecargada y cambiar su comportamiento para evitar interrupciones?

Recomendaciones

  • Implementa una retirada exponencial con aleatorización en la lógica de reintento de error de las aplicaciones cliente.
  • Implementa una arquitectura multirregional con conmutación por error automática para obtener alta disponibilidad.
  • Usa el balanceo de cargas para distribuir las solicitudes de los usuarios en fragmentos y regiones.
  • Diseña la aplicación para que se degrade bajo sobrecarga con facilidad mediante la entrega de respuestas parciales o una funcionalidad limitada en lugar de que falle por completo.
  • Establece un proceso recurrente basado en datos para la planificación de capacidad, con pruebas de carga y previsiones del tráfico a fin de impulsar el aprovisionamiento de recursos.
  • Establece procedimientos de recuperación ante desastres y pruébalos de forma periódica.

Compila capacidades de implementación flexibles y automatizadas

Asegúrate de que todos los cambios puedan revertirse

Si no hay una forma bien definida de deshacer ciertos tipos de cambios, cambia el diseño del servicio para admitir la reversión y prueba los procesos de reversión de forma periódica. Puede ser costoso implementarlo en aplicaciones para dispositivos móviles, y sugerimos que los desarrolladores apliquen Firebase Remote Config a fin de facilitar la reversión de funciones.

Distribuye el tráfico para las promociones y los lanzamientos programados

En el caso de los eventos promocionales, como las ventas que comienzan en un momento preciso (por ejemplo, a la medianoche) que incentivan a muchos usuarios a conectarse al servicio en simultáneo, agrega retrasos aleatorios antes de iniciar solicitudes a fin de diseñar el código del cliente para que distribuya el tráfico en segundos. Esto evita aumentos repentinos de tráfico instantáneos que podrían causar fallas en los servidores a la hora de inicio programada.

Implementa lanzamientos progresivos con pruebas canary

Lanza versiones nuevas de ejecutables y cambios de configuración de forma incremental y comienza con un alcance pequeño, como algunas VM en una zona. Tu objetivo es detectar errores cuando solo una pequeña parte del tráfico de usuarios se ve afectada, antes de lanzar el cambio a nivel global. Configura un sistema de “pruebas canary” que esté al tanto de tales cambios y que realice una comparación A/B entre las métricas de los servidores modificados y el resto de los servidores para marcar comportamientos anómalos. El sistema en versión canary debe alertar a los operadores sobre los problemas e incluso podría detener de forma automática los lanzamientos. Después de que el cambio pase las pruebas canary, propágalo a alcances más grandes de forma gradual, como una zona completa y, luego, a una segunda zona. Esto permite que el sistema modificado controle volúmenes de tráfico de usuario cada vez más grandes para exponer cualquier error latente.

Automatiza la compilación, la prueba y la implementación

Usa las canalizaciones de CI/CD para eliminar el trabajo manual del lanzamiento a fin de compilar pruebas automatizadas en tus versiones. Realiza implementaciones y pruebas de integración automatizadas.

La automatización es útil, pero no una panacea. Incluye una parte razonable de los costos de mantenimiento y riesgos de confiabilidad más allá de los costos iniciales de desarrollo y configuración.

Te recomendamos comenzar con un inventario y una evaluación del costo del trabajo de los equipos que administran tus sistemas. Haz de este un proceso continuo que se inicie antes de invertir en la automatización personalizada para extender lo que ya ofrecen los socios y servicios de Google Cloud. A menudo, puedes ajustar la automatización de Google Cloud, por ejemplo, el algoritmo de ajuste de escala automático de Compute Engine.

Consideramos que el trabajo manual, repetitivo, automatizable y reactivo es una dificultad que no suele tener un valor duradero y crece tan rápido como su origen. Para obtener más información, consulta el capítulo del libro de SRE Elimina el trabajo manual.

Las siguientes son algunas de las principales áreas en las que la eliminación del trabajo manual mediante Google proporcionó una automatización configurable o personalizada que ayudó a nuestros clientes:

  • Administración de identidades, por ejemplo, Cloud Identity y Google IAM
  • Soluciones alojadas en Google Cloud en lugar de “implementar una propia”, por ejemplo, la administración de clústeres (Google Kubernetes Engine), la base de datos relacional (Cloud SQL), el almacén de datos (BigQuery) y la administración de API (Apigee)
  • Servicios de Google Cloud y aprovisionamiento de usuarios, por ejemplo, Cloud Deployment Manager, Terraform o Cloud Foundation Toolkit
  • Aprovisionamiento de capacidad adicional, por ejemplo, varios productos de Google Cloud que ofrecen ajuste de escala automático configurable
  • Canalizaciones de CI/CD con implementación automatizada, por ejemplo, Cloud Build
  • Análisis de versiones canary para validar implementaciones, por ejemplo, Kayenta.
  • Entrenamiento de modelos automatizado (para aprendizaje automático), por ejemplo, AutoML

Recomendamos priorizar la eliminación del trabajo manual antes de la automatización y aprovechar al máximo la automatización configurable de Google para reducir el trabajo sobrante como segundo paso. El tercer paso, que se puede hacer en paralelo con el primero y el segundo, implica evaluar la compilación o la compra de otras soluciones si el costo del trabajo manual sigue siendo alto, por ejemplo, más del 50% del tiempo para cualquier equipo que administre tus sistemas de producción. Cuando compiles o compres soluciones, ten en cuenta los costos de integración, seguridad, privacidad y cumplimiento.

Si encuentras un producto o servicio de Google Cloud que solo satisface tus necesidades técnicas de forma parcial en relación con la automatización o eliminación de flujos de trabajo manuales, considera presentar una solicitud de función a través de tu representante de cuenta de Google Cloud. Puede ser una prioridad para nuestros clientes o parte de nuestra hoja de ruta y, si es así, conocer la prioridad y el cronograma de la función te ayudará a evaluar mejor las compensaciones de compilar tu propia solución en comparación con esperar para usarla como una función de Google Cloud.

Preguntas sobre el diseño

  • ¿El proceso de cambios de los ejecutables y las opciones de configuración es automático?
  • ¿La automatización de cambios está diseñada para habilitar una reversión rápida de cada cambio posible?
  • Para los cambios que no se pueden revertir, como los cambios de esquema, ¿existe un proceso de revisión de diseño para garantizar la compatibilidad con versiones posteriores y anteriores entre las versiones binarias actuales o anteriores y los esquemas de datos?
  • ¿Los archivos de configuración del sistema están fragmentados, de modo que sus cambios se puedan implementar de forma incremental en lugar de global?

Recomendaciones

  • Configura pruebas canary de nuevos lanzamientos y opciones de configuración.
  • Define cuál es el trabajo manual para tus equipos y evalúa su costo de forma periódica.
  • Elimina los el trabajo manual o los flujos de trabajo innecesarios antes de desarrollar la automatización personalizada.
  • Ajusta la configuración predeterminada o, si no se proporciona, crea una para usar la automatización existente que ya está disponible en los servicios de Google Cloud.
  • Evalúa la compilación (o la compra) de la automatización personalizada si los costos de mantenimiento y los riesgos de confiabilidad y seguridad del servicio valen la pena. También recomendamos evaluar el software de código abierto bien mantenido.

Crea alertas eficientes

Retraso de alertas optimizadas

Ajusta el retraso configurado antes de que el sistema de supervisión notifique a las personas sobre un problema a fin de minimizar el TTD mientras se maximiza la señal y el ruido. Usa la tasa de consumo del porcentaje de error aceptable para derivar la configuración de alertas óptima.

Alerta sobre los síntomas, no sobre las causas

Activa alertas según el impacto directo en la experiencia del usuario, es decir, el incumplimiento de los SLO globales o por cliente. No crees alertas sobre todas las posibles causas subyacentes de una falla, en especial cuando el impacto se limita a una sola réplica. Un sistema distribuido bien diseñado se recupera sin problemas de las fallas de una sola réplica.

Compila un proceso colaborativo de administración de incidentes

Será inevitable que, en un futuro, el sistema bien diseñado presente fallas en sus SLO. Ten en cuenta que, ante la ausencia de un SLO, los clientes definirán de manera general cuál es el nivel de servicio aceptable en función de su experiencia pasada y lo escalará al grupo de asistencia técnica o similar, sin importar lo que incluya tu ANS.

Para brindar un servicio adecuado a tus clientes, recomendamos establecer e implementar con regularidad un plan de administración de incidentes. El plan puede ser una lista de tareas de una sola página con 10 elementos aproximadamente. Este proceso ayudará a tu equipo a reducir el tiempo promedio de detección (MTTD) y el tiempo promedio de mitigación (MTTM). Usamos MTTM en lugar de MTTR porque este último es ambiguo. La R se usa a menudo como “reparación” o “recuperación” para referirse a “corrección completa” en lugar de “mitigación”. De forma explícita, MTTM significa mitigación en lugar de una corrección completa.

Un sistema bien diseñado en el que las operaciones sean excelentes aumentará el tiempo promedio entre fallas (MTBF). Consulta las secciones sobre el diseño de sistemas y la excelencia operativa para obtener más detalles.

También es importante establecer una cultura libre de responsabilidades a posteriori y un proceso de revisión de incidentes. “Libre de responsabilidades” significa que tu equipo debe evaluar y documentar de manera objetiva la razón por la que se produjeron los errores. Los errores se tratan como oportunidades de aprendizaje, no como fuente de críticas. Siempre intenta que el sistema sea más resiliente para que pueda recuperarse con rapidez de los errores humanos o, incluso mejor, detectarlos y prevenirlos.

Reduce el MTTD

Un requisito previo para reducir el MTTD es implementar las recomendaciones que se describieron en las secciones “Observabilidad” y “Define tus objetivos de supervisión”, por ejemplo, poder distinguir entre los problemas de la aplicación y los subyacentes de la nube.

Un conjunto de SLI bien ajustado alerta a tu equipo en el momento adecuado sin generar una sobrecarga de alertas. Para obtener orientación, consulta Ajusta tus métricas de SLI: lecciones de CRE.

Reduce el MTTM

Para reducir el MTTM, ten un plan de administración de incidentes documentado de forma adecuada y bien implementado. Además, ten datos disponibles sobre los cambios.

Ejemplo de un plan de administración de incidentes

  • Se detectaron problemas de producción (alerta, página) o se escalaron.
  • ¿Debería delegar en primer lugar? Sí, si tú y tu equipo no pueden resolver esto.
  • ¿Es un incumplimiento de la privacidad o la seguridad? Si es así, delégalo al equipo de privacidad o seguridad.
  • ¿Es una emergencia o están en riesgo los SLO? Si tienes dudas, trata la situación como si fuera una emergencia.
  • ¿Debo involucrar a más personas? Sí, si afecta a más del X% de los clientes o si toma más de Y minutos en resolverse. Si tienes dudas, siempre debes involucrar a más personas, en especial durante el horario de atención.
    • Define un canal de comunicación principal, por ejemplo, IRC, Hangouts Chat o Slack.
    • Delega funciones definidas con anterioridad, por ejemplo:
      • Comandante de incidentes: responsable de la coordinación general
      • Líder de comunicaciones: responsable de controlar la comunicación interna y externa
      • Líder de operaciones: responsable de mitigar el problema
    • Define la finalización del incidente. Esto puede requerir la confirmación de un representante del equipo de asistencia.
  • Colabora en el proceso a posteriori.
  • Asiste a reuniones recurrentes de revisión de incidentes a posteriori para ofrecerle al personal elementos de acción y debatirlos.

Grafos

A continuación, se presenta una lista no exhaustiva de grafos que debes tener en cuenta. Los encargados de ofrecer respuestas ante incidentes deben poder verlos en una sola vista.

  • Indicadores de nivel de servicio, por ejemplo, solicitudes exitosas divididas por el total
  • Configuración o lanzamientos binarios
  • Solicitudes por segundo al sistema
  • Errores por segundo que muestra el sistema
  • Solicitudes por segundo del sistema a sus dependencias
  • Errores por segundo del sistema a sus dependencias

También vemos con frecuencia el tamaño de la solicitud y la respuesta, el costo de la consulta, los grupos de subprocesos (para buscar una regresión que induce el agotamiento del grupo) y las métricas de JVM que se grafican (si corresponde).

Prueba algunas situaciones en términos de la ubicación de estos grafos. También puedes aplicar el aprendizaje automático para mostrar el subconjunto correcto de estos grafos (es decir, técnicas de detección de anomalías).

Por último, como se mencionó antes, otro enfoque común para la mitigación rápida es diseñar sistemas y cambios que se puedan revertir con facilidad.

Recomendaciones

  • Establece tus equipos y realiza capacitaciones sobre el plan de administración de incidentes.
  • Implementa las recomendaciones de la sección “Observabilidad” para reducir el MTTD.
  • Compila un panel de cambios que puedas consultar durante los incidentes.
  • Documenta los fragmentos de consultas o compila un panel de Data Studio.
  • Evalúa Firebase Remote Config a fin de mitigar los problemas de lanzamiento relacionados con las aplicaciones para dispositivos móviles.
  • Implementa recomendaciones de la sección “Recuperación ante desastres” para disminuir el MTTM de un subconjunto de incidentes.
  • Diseña y prueba la configuración y las reversiones binarias.
  • Implementa las recomendaciones de las secciones “Diseño de sistemas” y “Recuperación ante desastres” para aumentar el MTBF.

Recursos