Ejecutar cualquier plataforma distribuida escalable requiere un compromiso con la confiabilidad para garantizar que los clientes tengan lo que necesitan cuando lo necesitan. Las dependencias pueden ser bastante complejas, especialmente con una plataforma tan grande como Roblox. Crear servicios confiables significa que, independientemente de la complejidad y el estado de las dependencias, ningún servicio se interrumpirá (es decir, será altamente accesible), funcionará sin errores (es decir, alto calidad) y sin errores (es decir, Tolerancia a fallos).
Por qué importa la confiabilidad
Nuestro equipo de Identidad de cuenta está comprometido a lograr una mayor confiabilidad, ya que los servicios de cumplimiento que creamos son componentes esenciales de la plataforma. El incumplimiento del cumplimiento puede tener graves consecuencias. El costo de bloquear el funcionamiento natural de Roblox es muy alto, se necesitan recursos adicionales para recuperarse después de un bloqueo y una experiencia de usuario debilitada.
El enfoque típico de la confiabilidad se enfoca principalmente en la disponibilidad, pero en algunos casos los términos se confunden y se usan incorrectamente. La mayoría de las medidas de disponibilidad solo evalúan si los servicios están funcionando, mientras que aspectos como la tolerancia a la partición y la consistencia a veces se pasan por alto o se malinterpretan.
De acuerdo con el teorema CAP, cualquier sistema distribuido puede garantizar solo dos de estos tres aspectos, por lo que nuestros servicios de cumplimiento sacrifican cierta consistencia para ser altamente disponibles y tolerantes a las particiones. Sin embargo, nuestros servicios sacrificaron poco y encontraron mecanismos para lograr una buena coherencia con los cambios arquitectónicos razonables que se explican a continuación.
El proceso para lograr una mayor confiabilidad es iterativo, con una medición rigurosa que combina el trabajo continuo para prevenir, encontrar, detectar y corregir defectos antes de que ocurran incidentes. Nuestro equipo ha identificado un gran valor en las siguientes prácticas:
Medición correcta: construya una observabilidad completa sobre cómo se entrega la calidad a los clientes y cómo las dependencias nos entregan la calidad. Anticipación proactiva: realice actividades como revisiones de arquitectura y evaluaciones de riesgo de dependencia. Priorizar la remediación: preste más atención a la resolución de informes de incidentes para el servicio y las dependencias vinculadas a nuestro servicio.
Construir una mayor confiabilidad requiere una cultura de calidad. Nuestro equipo ya estaba invirtiendo en desarrollo orientado al rendimiento y sabe que el éxito de un proceso depende de su adopción. El equipo adoptó completamente este proceso y aplicó las prácticas como estándar. El siguiente diagrama destaca los componentes del proceso:
El poder de la medición correcta
Antes de profundizar en las métricas, se debe hacer una aclaración rápida sobre las mediciones del nivel de servicio.
SLO (Objetivo de nivel de servicio) es el objetivo de confiabilidad que busca nuestro equipo (es decir, 99,999%). SLI (Indicador de nivel de servicio) es la confiabilidad alcanzada dentro de un período de tiempo (es decir, 99.975% en febrero pasado). SLA (Acuerdo de nivel de servicio) es la confiabilidad acordada para entregar y que nuestros clientes esperan dentro de un período de tiempo determinado (es decir, 99,99% por semana).
El SLI debe reflejar la disponibilidad (sin respuestas no manejadas o faltantes), tolerancia a fallas (sin errores de servicio) y calidad lograda (sin errores inesperados). Por lo tanto, definimos nuestro SLI como el “índice de éxito” de respuestas exitosas sobre el número total de solicitudes enviadas a un servicio. Las respuestas exitosas son aquellas solicitudes que se enviaron de manera oportuna, lo que significa que no se produjo ninguna conectividad, servicio o errores inesperados.
Este SLI o Índice de Éxito se recoge desde el punto de vista de los consumidores (es decir, los clientes). La intención es medir la experiencia real de extremo a extremo brindada a nuestros clientes para que podamos estar seguros de que se están cumpliendo los SLA. No hacerlo crearía una falsa sensación de confiabilidad que ignora todas las preocupaciones de infraestructura para conectarse con nuestros clientes. Al igual que el SLI del consumidor, recopilamos el SLI de dependencia para rastrear cualquier riesgo potencial. En la práctica, todos los SLA de dependencia deben estar alineados con el SLA de servicio y existe una dependencia directa de ellos. El fracaso de uno implica el fracaso de todos. También rastreamos e informamos las métricas del propio servicio (es decir, el servidor), pero esta no es la fuente práctica de alta confiabilidad.
Además de los SLI, cada compilación recopila métricas de calidad que informa nuestro flujo de trabajo de CI. Esta práctica ayuda a reforzar las puertas de calidad (es decir, la cobertura del código) e informar sobre otras métricas importantes, como el cumplimiento del estándar de codificación y el análisis de código estático. Este tema fue tratado anteriormente en otro artículo, Creación de microservicios basados en el rendimiento. La adherencia diligente a la calidad se suma cuando se trata de confiabilidad, ya que cuanto más invertimos en lograr puntajes excelentes, más seguros nos volvemos de que el sistema no fallará en condiciones adversas.
Nuestro equipo tiene dos paneles. One proporciona una visibilidad completa tanto de Consumer SLI como de Dependency SLI. El segundo muestra todas las métricas de calidad. Estamos trabajando para unir todo en un solo tablero, de modo que todos los aspectos que nos interesan estén consolidados y listos para ser informados en cualquier momento.
Anticipar el fracaso
Haciendo revisiones arquitectónicas Es una parte clave de ser digno de confianza. Primero, determinamos si existe redundancia y si el servicio tiene los medios para sobrevivir cuando caen las dependencias. Además de las ideas típicas de replicación, la mayoría de nuestros servicios aplicaron técnicas mejoradas de hidratación de caché doble, estrategias de recuperación doble (como las colas locales de conmutación por error) o estrategias de pérdida de datos (como el soporte transaccional). Estos temas son lo suficientemente extensos como para justificar otra entrada de blog, pero en última instancia, la mejor recomendación es implementar ideas que consideren escenarios de desastre y minimicen cualquier penalización de rendimiento.
Otra cosa importante a esperar es cualquier cosa que pueda mejorar la conectividad. Esto significa ser agresivo con respecto a la baja latencia para los clientes y prepararlos para un tráfico muy alto utilizando técnicas de control de caché, sidecars y políticas de rendimiento para tiempos de espera, interrupciones y reintentos. Estas prácticas se aplican a cualquier cliente, incluidos cachés, almacenes, colas y clientes interdependientes a través de HTTP y gRPC. También significa mejorar las señales de salud de los servicios y comprender que los controles de salud juegan un papel importante en toda la orquestación de contenedores. La mayoría de nuestros servicios emiten mejores señales degradadas como parte de los comentarios de verificación de estado y verifican que todos los componentes críticos funcionen antes de enviar señales saludables.
Dividir los servicios en partes críticas y no críticas ha demostrado ser útil para centrarse en la funcionalidad más importante. Solíamos tener terminales solo para administradores en el mismo servicio y, aunque no se usaban con frecuencia, afectaban las métricas generales de latencia. Trasladarlos a su propio servicio impactó todas las métricas en una dirección positiva.
Evaluación del riesgo de dependencia es una herramienta importante para identificar problemas potenciales con las dependencias. Esto significa que identificamos dependencias bajas de SLI y solicitamos la alineación de SLA. Estas dependencias necesitan atención especial durante las etapas de integración, por lo que dedicamos más tiempo a evaluar y probar si las nuevas dependencias son lo suficientemente maduras para nuestros planes. Un buen ejemplo es la adopción temprana que tuvimos para Roblox Storage-as-a-Service. La integración con este servicio requería el envío de tickets de errores y reuniones periódicas de sincronización para comunicar hallazgos y comentarios. Todo este trabajo utiliza la etiqueta de “confiabilidad” para que podamos identificar rápidamente su origen y prioridades. La caracterización sucedió con frecuencia hasta que estuvimos seguros de que la nueva dependencia estaba lista para nosotros. Este trabajo adicional ayudó a llevar la dependencia al nivel requerido de confiabilidad que esperamos brindar al trabajar juntos hacia un objetivo común.
Trae estructura al caos
Nunca es deseable tener incidentes. Pero cuando lo hacen, hay información importante para recopilar y aprender a ser más confiables. Nuestro equipo tiene un informe de incidentes del equipo creado más allá del típico informe de toda la empresa, por lo que nos enfocamos en todos los incidentes, independientemente de la escala de su impacto. Llamamos a la causa raíz y priorizamos todo el trabajo para mitigarla en el futuro. Como parte de este informe, hemos convocado a otros equipos para solucionar incidentes de adicción de alta prioridad, realizar un seguimiento de la resolución adecuada, mirar hacia atrás y buscar patrones que puedan aplicarse a nosotros.
El equipo produce un Reporte Mensual de Confiabilidad por Servicio que incluye todos los SLI aquí explicados, todos los tickets que abrimos por confiabilidad y las posibles incidencias asociadas al servicio. Estamos tan acostumbrados a generar estos informes que el siguiente paso natural es automatizar su extracción. Hacer esta actividad periódica es importante y es un recordatorio de que la confiabilidad está siendo rastreada y considerada constantemente en nuestro desarrollo.
Nuestra instrumentación incluye métricas personalizadas y alertas mejoradas para que nos llamen lo más rápido posible cuando ocurran problemas conocidos y esperados. Todas las alertas, incluidos los falsos positivos, se revisan cada semana. En este punto, es importante pulir toda la documentación para que nuestros clientes sepan qué esperar cuando se activan alertas y ocurren errores, para que todos sepan qué hacer (por ejemplo, los manuales y las pautas de integración están alineados y actualizados con frecuencia).
En última instancia, la adopción de la calidad en nuestra cultura es el factor más crítico y decisivo para lograr una mayor confiabilidad. Podemos ver cómo estas prácticas aplicadas a nuestra vida diaria ya están dando sus frutos. Nuestro equipo está obsesionado con la confiabilidad y es nuestro logro más importante. Hemos aumentado nuestra conciencia sobre el impacto que pueden tener los posibles defectos y cuándo se pueden introducir. Los servicios que han implementado estas prácticas han logrado consistentemente sus SLO y SLA. Los informes de confiabilidad que nos ayudan a realizar un seguimiento de todo el trabajo que hemos realizado son testimonio del trabajo que ha realizado nuestro equipo y son lecciones valiosas para informar e influir en otros equipos. Así es como la cultura de la confiabilidad toca cada componente de nuestra plataforma.
El camino hacia una mayor confiabilidad no es fácil, pero es necesario si desea crear una plataforma confiable que reinvente cómo se unen las personas.
