El mes pasado me encargaron calcular el acuerdo de nivel de servicio (SLA) de mi servicio Serverless. Primero, tuve que pensar cómo abordar la tarea.
Hasta donde yo sabía, SLA era un contrato legalmente vinculante entre una empresa y sus clientes respecto de la disponibilidad de sus servicios y el tiempo de inactividad previsto durante un año.
Además, si la empresa no cumplía con su obligación, tenía que reembolsar el dinero a sus clientes.
Esta entrada de blog es el fruto de mi investigación y proceso de pensamiento.
En esta publicación del blog, encontrará mis definiciones, pautas y enfoque para comprender SLA, SLI, SLO, RTO y RTP, y otras definiciones relacionadas en un contexto de servicio sin servidor, incluida la estimación de la disponibilidad de un servicio sin servidor. Además, aprenderá a mejorar su RTO y reducir el tiempo de inactividad del servicio.
Descargo de responsabilidad: No soy abogado, solo un arquitecto que intenta darle sentido a todo, así que consulte a su equipo legal antes de publicar un SLA.
Tabla de contenido
Definiciones
Repasemos algunos términos y definiciones básicos antes de estimar un SLA potencial de servicio sin servidor de muestra.
Desastre de servicio
Antes de que podamos hablar sobre la salud o disponibilidad del servicio, debemos entender qué es un desastre de servicio.
Un desastre de servicio es un evento en el que el caso de uso comercial crítico de un servicio deja de funcionar durante algún tiempo. Sin embargo, no significa que todo el servicio esté fuera de línea.
Piense en un servicio de visualización de registros. El servicio está en línea; puede iniciar sesión, pero no ver ningún registro. ¿Se considera eso un desastre de servicio?
Yo diría que sí. El caso de uso empresarial crítico es que los usuarios pueden ver registros, y este flujo está interrumpido. Puedo iniciar sesión en el servicio, pero no puedo hacer nada.
Por otro lado, es posible que tenga un caso de uso comercial secundario que deje de funcionar, pero que sea menos crítico para el cliente. Por supuesto, es una molestia y un problema de producción. Sin embargo, el cliente aún puede usar el servicio en este caso, por lo que es posible que no se considere oficialmente como "tiempo de inactividad".
Para ser claros, sus equipos de producto y legales son los que definen estos casos de uso.
Es esencial comprenderlos ya que afectan directamente el tiempo de inactividad.
Nota: diferentes casos de uso comerciales pueden tener otros requisitos de disponibilidad, pero en esta guía, me centraré en el caso de uso simple donde todos comparten una definición de SLA.
SLI
Los indicadores de nivel de servicio (SLI) son los números reales que miden el estado y la disponibilidad de un sistema. Registraremos cada tiempo de inactividad por desastre y calcularemos la disponibilidad del servicio utilizando la siguiente fórmula:
Disponibilidad = Tiempo de actividad ÷ (Tiempo de actividad + tiempo de inactividad)
Por ejemplo, un servicio estuvo en línea durante 700 horas a lo largo de un mes y sufrió 30 horas de inactividad debido a diversos desastres.
Disponibilidad = 700 ÷ (700 + 30) * 100
Disponibilidad = 700 ÷ 730 * 100
Disponibilidad = 0,958 * 100
Disponibilidad = 95,8%
La organización se esfuerza por mejorar y acercar el SLI al SLO.
SLO
El objetivo de nivel de servicio (SLO) es la meta interna de la organización para mantener los sistemas disponibles y funcionando según el estándar.
Este porcentaje representa dónde la organización quiere estar en términos de disponibilidad, dónde se esfuerza por estar pero actualmente NO ESTÁ allí.
Suele ser superior a SLI y SLA.
Acuerdo de nivel de servicio
Un acuerdo de nivel de servicio (SLA) define el nivel de servicio que un cliente espera de un proveedor, establece las métricas con las que se mide ese servicio y las soluciones o sanciones, si las hubiera, en caso de que no se alcancen los niveles de servicio acordados. - https://www.cio.com/article/274740/outsourcing-sla-definitions-and-solutions.html
Por ejemplo: AWS Code Deploy SLA :
AWS define los términos de compensación para cuando se incumple el contrato y el porcentaje de tiempo de actividad mensual del servicio está por debajo del umbral del SLA.
Pero ¿qué significa 99,9?
Según la calculadora SLA, 99,9 se traduce a:
De modo que, si AWS CodeDeploy no funciona durante más de 43 minutos y 28 segundos en un solo mes, nosotros, los clientes, recibimos un 10 % de crédito por servicio. ¡Genial!
Si ha habido un tiempo de inactividad más significativo, recibimos más crédito, hasta un crédito completo por un SLA del 95 % o menos, lo que equivale a más de 1,5 días de tiempo de inactividad en un solo mes.
Ejemplo de negocio
El nivel de servicio (SLI) de su servicio ha sido del 99,94 % durante el último año, lo que se traduce en 5 horas y 12 minutos de inactividad. El SLI se basa en incidentes de inactividad de servicio por desastres reales.
Por otro lado, supongamos que su objetivo de disponibilidad interna, SLO, es del 99,99 %, lo que se traduce en aproximadamente 4 minutos de inactividad mensual, lo cual es bastante ambicioso.
Sin embargo, desea tener un pequeño margen de maniobra, por lo que define su SLA como una disponibilidad del 99,9 %.
Su SLI está por encima del SLA, por lo que los clientes están contentos y hay margen de mejora para llegar al ambicioso SLO.
Capas de servicio
Un servicio tiene dos capas que nos interesan en el contexto de disponibilidad:
Capa de aplicación: el código comercial, en nuestro caso, es el código de los controladores Lambda.
Capa de infraestructura: recursos y configuración sin servidor: DynamoDB, configuración de AppConfig, máquina de estados de función Step, etc.
Conmutación por error de zonas de disponibilidad frente a conmutación por error de regiones
No todos los servicios deben tener un único punto de conmutación por error.
Es posible que tenga un servicio global donde se requiera conmutación por error entre regiones; por ejemplo,
Si su servicio no responde en us-east-1, debe dirigir a su cliente a la región de respaldo, us-east-2, lo antes posible.
La mayoría de los servicios sin servidor admiten conmutación por error y recuperación automática de múltiples zonas de disponibilidad listas para usar.
Los servicios como DynamoDB y Aurora admiten el mecanismo de la tabla global, que permite una conmutación por error automática por región. Serverless simplifica bastante estos aspectos siempre que los configure correctamente en su configuración de infraestructura como código.
RTO
El RTO ayuda a comprender el porcentaje de tiempo de actividad del servicio del SLA. Definámoslo:
El objetivo de tiempo de recuperación (RTO) es la sigla de Recovery Time Objective y es una medida de la rapidez con la que una aplicación debe volver a estar disponible después de una interrupción del servicio . En otras palabras, el RTO es la respuesta a la pregunta: "¿Cuánto tiempo se tardó en recuperarse después de la notificación de la interrupción del proceso empresarial?" - druva.com
Cuatro etapas de la gestión de la recuperación ante desastres
Un desastre puede manifestarse en ambas capas de servicio. Puede ocurrir debido a una configuración incorrecta de los recursos de la infraestructura o a un error en el código de la función Lambda.
La gestión de un desastre consta de varias etapas. La duración de estas etapas determina el tiempo de recuperación del servicio, el RTO:
Tiempo hasta la primera respuesta : es necesario que el desarrollador o el ingeniero de soporte de bomberos comiencen a manejar el desastre desde el comienzo de la primera alerta o notificación al cliente.
Tiempo para encontrar la causa : el tiempo que tarda el desarrollador o el ingeniero de soporte técnico en encontrar la causa raíz del desastre. Los desarrolladores deben revisar registros, métricas y seguimientos para determinar el problema.
Tiempo para corregir: el momento de implementar una corrección de errores, revertir confirmaciones anteriores o deshabilitar una función. Estos cambios activan una ejecución de la canalización de CI/CD en producción. En el mejor de los casos: se envía una reversión de código y se implementa en las últimas confirmaciones, lo que no requiere un mayor desarrollo de una corrección de errores. En el peor de los casos: un desarrollador escribe un código nuevo y realiza pruebas para solucionar el problema mientras el servicio está inactivo, lo que se traduce en un tiempo de inactividad adicional.
Es hora de notificar a los usuarios que el servicio está nuevamente funcionando.
Muchos factores pueden afectar el tiempo que los desarrolladores dedican a las etapas 2 y 3, por ejemplo:
Porcentaje de cobertura de código.
Complejidad del código de servicio.
Calidad de observabilidad del servicio.
Dependencia del servicio respecto de servicios externos.
Competencia en equipo.
Preparación del equipo para la recuperación ante desastres, es decir, scripts de respaldo, capacitación en manejo de desastres.
Como puedes ver, el RTO puede variar entre varios minutos, varias horas o incluso días.
Las etapas números 2 y 3 tienen el mayor potencial de causar un tiempo de inactividad prolongado.
RTO de los servicios administrados de AWS
Por otro lado, el RTO de los servicios gestionados de AWS es el tiempo que tarda la infraestructura en:
Identificar que una zona o región de disponibilidad está inactiva.
Enrutar (conmutar por error) los datos del usuario o servicio a una A/Z o región diferente.
En los servicios administrados de AWS, la conmutación por error y la recuperación de A/Z se realizan automáticamente, lo que acelera el RTO. DynamoDB es un ejemplo de un servicio administrado de AWS que se encarga de eso por usted.
En cuanto a las conmutaciones por error regionales, Route53 admite la conmutación por error automática de DNS , que puede enrutar a una región diferente si una región está inactiva.
El mecanismo de tablas globales de DynamoDB y Aurora son otros ejemplos de servicios administrados por AWS que manejan automáticamente el tiempo de inactividad regional para usted, lo que acelera el RTO.
¿Cómo se "estima" el RTO?
Lo llamo una suposición; se necesitan años de datos SLI para estimar el RTO con precisión.
Si ese no es el caso, es necesario hacer una "conjetura" calculada teniendo en cuenta las cuatro etapas del manejo de desastres y los factores que las impactan.
Discutiremos cómo puedes mejorar estos factores y el RTO en la última parte de esta publicación.
OPR
Un objetivo de punto de recuperación (RPO) es el tiempo máximo permitido para restaurar los datos, que puede o no significar una pérdida de datos. Es la antigüedad de los archivos o datos en el almacenamiento de respaldo que se requiere para reanudar las operaciones normales si se produce una falla en el sistema informático o en la red. Para definir la diferencia de manera más concisa: RPO es el tiempo desde la última copia de seguridad de los datos hasta que se produjo un incidente [que puede haber causado la pérdida de datos]. - evolveip.net
El RPO depende de la frecuencia de las copias de seguridad de la base de datos.
Si utiliza bases de datos sin servidor, está de suerte. Tienen los mejores mecanismos de recuperación y copias de seguridad en un momento determinado.
Cuando se configura adecuadamente, el RPO puede reducirse a minutos con copias de seguridad puntuales de DynamoDB y Aurora.
Introducción de RTO y RPO en un ejemplo de continuidad empresarial
En nuestro servicio de muestra, un RTO típico es de una hora, el RPO es de 15 minutos y la última copia de seguridad de la base de datos se realizó a las 12 del mediodía.
A las 12:15, segundos antes de que se realice la siguiente copia de seguridad, ocurre un desastre.
El tiempo de recuperación (RTO) es de una hora en promedio, como fue el caso en este desastre. A las 13:15, después de una hora de inactividad, el servicio volvió a estar en línea. Nuestra pérdida de datos, en este caso, es de 15 minutos, ya que la última copia de seguridad se realizó a las 12:00.
Cómo estimar el SLA
Siga estos pasos:
Defina qué se considera un desastre en su servicio. Defina los flujos críticos del servicio y qué infraestructura y código de aplicación son relevantes para ellos.
Calcule su SLI de servicio actual según los datos de incidentes pasados. El SLI predice el futuro y ayuda a suponer cuántos incidentes tendrá en un año.
Calcule el RTO de su servicio.
Calcule el tiempo de inactividad anual en días: suponga cuántos incidentes por año puede esperar y multiplíquelo por el RTO que calculó en el paso 3. Asegúrese de cambiarlo a una unidad de día.
Fórmula de SLA: (365 - {días de inactividad}) / 365 * 100 = SLA donde 365 son 365 días, lo que se traduce en un tiempo de actividad del servicio anual 24 horas al día, 7 días a la semana.
Ejemplo de estimación de SLA
Calculemos el SLA para un 'servicio de pedidos' sin servidor que permite a los clientes crear y ver pedidos de un producto.
Sigamos los cuatro pasos de la estimación del SLA:
Flujo comercial crítico: crear nuevos pedidos de clientes. La visualización de pedidos existentes no se considera un flujo vital.
SLI actual: 99,99 % (un incidente anterior en producción durante aproximadamente una hora)
RTO: consulte la estimación a continuación. Utilizaremos un enfoque más seguro y asumiremos que los incidentes futuros requerirán que el equipo depure y solucione el problema en lugar de una simple reversión del código.
Incidentes estimados cada dos años. Tiempo de inactividad anual => 2* RTO = 2* 0,25 = 0,5 días de tiempo de inactividad durante un año.
Nivel de servicio: (365-0,5)/365 * 100 = 99,86 % Nivel de servicio
Estimación de RTO
La capa de infraestructura de los servicios utiliza AWS Lambda, Amazon API Gateway y Amazon DynamoDB.
La calidad del código de servicio es alta; la cobertura del código es de alrededor del 90%.
SLA del servicio AWS en uso: mínimo SLA GARANTIZADO: 99,95 %
Calcularemos un RTO de 6 horas, es decir, 0,25 días, suponiendo que los incidentes futuros requieran más tiempo para investigar y depurar que una simple reversión de código que demora una hora. Si bien el único incidente pasado tardó una hora en resolverse, entendemos que fue la excepción y no la norma. Es mejor estar del lado seguro en lugar de prometer estimaciones que a su equipo le resultará difícil cumplir en el futuro.
En el futuro, cuando haya más ejemplos de incidentes pasados, podremos ajustar el número de RTO al promedio de incidentes reales.
Tenga en cuenta que el SLA es inferior al SLA garantizado para nuestro servicio AWS: 99,86 < 99,95. Esto tiene sentido, ya que podemos tener un SLA que sea inferior o igual al SLA de la infraestructura y los servicios AWS de los que dependemos, pero no superior.
Segunda nota: nuestro SLI es más alto que el SLA y actualmente ofrecemos una mejor disponibilidad que la prometida a los clientes.
Cómo mejorar su RTO: preparación para desastres
Debes aceptar que es sólo cuestión de tiempo hasta que suceda algo terrible.
No puedes prepararte para todo, pero puedes tener pólizas de seguro y tratar de preparar a tu equipo y servicio para muchos desastres.
Repasemos algunos elementos de acción que pueden preparar a su equipo para lo peor, disminuyendo así el RTO, mejorando la disponibilidad y mejorando el porcentaje potencial de SLA.
Prácticas de CI/CD
Implementación de Canary para funciones de AWS Lambda
Implementación canaria para AWS Lambda: para un entorno de producción, utilice implementaciones canarias con reversiones automáticas al ver los registros de errores de AWS Lambda o las alarmas de AWS CloudWatch activadas.
Las implementaciones de Canary cambian gradualmente el tráfico a su nueva versión de AWS Lambda y revierten el cambio ante la primera aparición de errores.
Una forma de lograrlo es utilizar AWS Code Deploy con AWS Lambda.
Implementación de Canary para configuración dinámica de Lambda
Las implementaciones de Canary también son relevantes en el dominio de la configuración dinámica de aplicaciones.
Los indicadores de funciones son un tipo de configuración dinámica y le permiten cambiar rápidamente el comportamiento de su función de AWS Lambda. Una forma de mejorar la confianza en el lanzamiento de una función es activarla o desactivarla rápidamente.
Recuperación de la crisis
Copias de seguridad
Realice una copia de seguridad de sus datos y de los datos de sus clientes.
Habilite las copias de seguridad cada hora de sus tablas de DynamoDB, bases de datos Aurora, índices de OpenSearch o cualquier otra entidad de base de datos. Es mejor prevenir que curar.
Algunos servicios, como DynamoDB, ofrecen copias de seguridad automáticas y facilidad de restauración.
Cuanto más frecuente sea la copia de seguridad, menor será el RPO.
El SOP (procedimiento operativo estándar)
Cuente con un equipo de soporte 24/7
Crear procesos claros para manejar desastres.
Los procesos reducen el RTO en caso de desastre.
Cree un proceso para restaurar datos de producción desde la copia de seguridad.
Crear una copia de seguridad es una cosa, pero restaurar desde una copia de seguridad cuando el tiempo avanza y hay clientes molestos en su puerta es otra.
Debe crear un proceso bien definido para restaurar cualquier base de datos de forma rápida y segura.
Desarrolle los scripts necesarios, defina el proceso de restauración (quién lo ejecuta, cuándo, cómo), pruébelo en entornos que no sean de producción y capacite a su personal de soporte para usarlo.
Además, debes crear un proceso para realizar cambios, scripts y correcciones ad hoc en la cuenta de producción. A veces, no puedes esperar a que se implemente una corrección de errores desde la cuenta de desarrollo a la de producción, y puede llevar demasiado tiempo pasar por todas las etapas de la cadena de suministro de CI/CD.
A veces es necesario contar con una forma rápida, auditada y segura de modificar los datos de producción.
Asegúrese de que esté auditado, requiera aprobaciones adicionales y no infrinja ninguna normativa a la que esté obligado.
Practique la ejecución de estos scripts al menos una vez por trimestre.
Ingeniería del caos
Espere lo inesperado. Se producirán cortes y errores en el servidor, incluso en entornos sin servidor.
Tienes que estar preparado
Utilice la simulación de inyección de fallas de AWS para crear caos en su cuenta de AWS, hacer que sus llamadas a la API de AWS fallen y ver cómo se comporta su servicio.
Intente diseñar para el fracaso lo más temprano posible en su recorrido hacia Serverless.
Observabilidad y preparación para el apoyo
Las buenas prácticas de observación y registro ayudarán a los desarrolladores a resolver problemas más rápidamente y a recibir notificaciones de un incidente inminente antes de que ocurra el desastre, reduciendo así el RTO.
Identificación de correlación
En mi opinión, la sesión de depuración perfecta es aquella en la que puedo rastrear una única actividad de usuario en múltiples servicios con una sola identificación: el infame valor de identificación de correlación .
Una forma de lograr esta experiencia es inyectar un valor de identificación de correlación en los registros de servicio.
Además, debe pasar este valor a cualquier llamada posterior a los servicios a través de encabezados de solicitud/evento (atributos de AWS SNS/encabezados HTTP, etc.).
Vea un ejemplo aquí con AWS Lambda Powertools Logger.
Paneles de observación
Cree paneles de AWS CloudWatch que proporcionen una descripción general de alto nivel del estado de su servicio para su equipo de SRE.
Debe contener registros de errores manejables e información de servicio, para que los no desarrolladores puedan identificar rápidamente los errores y su causa raíz.
Deje los paneles complicados que contienen métricas de servicio de bajo nivel de CloudWatch a los paneles de los desarrolladores.
Trabaje en estrecha colaboración con el equipo de SRE, agregue mensajes de registro precisos que describan los problemas de servicio y cree el tablero.
Lea más sobre observabilidad y CloudWatch aquí .
Alertas
Defina alertas de CloudWatch sobre registros de errores críticos o métricas de CloudWatch que se correlacionen con una deficiencia grave del servicio o una denegación de servicio.
Estos pueden incluir fallas de la función Lambda, problemas de latencia, tiempos de espera de la función Lambda, errores de DynamoDB, problemas de inicio de sesión de Cognito, etc.
Cada alarma debe investigarse y mitigarse rápidamente.
Capacitación
Invierta tiempo y esfuerzo en la formación de soporte para desarrolladores y SRE.
Cada registro de error del panel o métrica de CloudWatch debe tener una acción predefinida que el SRE debe tomar.
Incluya pautas como "Si ve 'X' e 'Y', probablemente significa que Z es un problema; siga estos pasos para mitigar Z".
Asegúrese de que los SRE comprendan la arquitectura impulsada por eventos de alto nivel del servicio para que puedan respaldarlo de manera más eficiente.
Gracias a Ronen Mintz por la reseña y los comentarios.
Yorumlar