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. La construcción de servicios confiables significa que, independientemente de la complejidad y el estado de las dependencias, un servicio dado será ininterrumpido (es decir, altamente Disponible), funcionará sin errores (es decir, 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 hemos creado son componentes centrales de la plataforma. El incumplimiento puede tener graves consecuencias. El costo de bloquear el funcionamiento natural de Roblox es muy alto, y se necesitan recursos adicionales para recuperarse de una interrupción y una experiencia de usuario comprometida.
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 métricas de disponibilidad simplemente evalúan si los servicios están en funcionamiento, mientras que aspectos como la tolerancia y la consistencia de la partición 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 tanto, nuestros servicios de cumplimiento sacrifican algo de consistencia para ser altamente disponibles y tolerantes a las particiones. Sin embargo, nuestros servicios han sacrificado poco y han encontrado 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 medidas precisas correspondientes a un trabajo continuo para prevenir, encontrar, detectar y corregir fallas antes de que ocurran incidentes. Nuestro equipo ha identificado un gran valor en las siguientes prácticas:
- Medición precisa – Construir una observabilidad completa de cómo se entrega la calidad a los clientes y cómo las dependencias nos entregan la calidad.
- Anticipación proactiva – Realizar actividades como revisiones arquitectónicas y evaluaciones de riesgo de dependencia.
- Priorizar la remediación – Prestar más atención a la resolución de informes de incidencias del servicio y dependencias relacionadas con nuestro servicio.
Construir una mayor confiabilidad requiere una cultura de calidad. Nuestro equipo ya estaba invirtiendo en el desarrollo basado en el rendimiento y sabe que el éxito de un proceso depende de su adopción. El equipo adoptó este proceso en su totalidad y aplicó las prácticas como un estándar. El siguiente diagrama destaca los componentes del proceso:
El poder de la buena medida
Antes de profundizar en las métricas, hay una aclaración rápida sobre las métricas de nivel de servicio.
- El SLO (Objetivo de nivel de servicio) es el objetivo de confiabilidad al que apunta nuestro equipo (99,999%).
- El SLI (Indicador de Nivel de Servicio) es la confiabilidad alcanzada durante un período determinado (es decir, 99,975% en febrero pasado).
- El SLA (Acuerdo de Nivel de Servicio) es la confiabilidad que nos comprometemos a entregar y que nuestros consumidores esperan dentro de un marco de tiempo determinado (es decir, 99,99% por semana).
El SLI debe reflejar la disponibilidad (sin respuestas no administradas o faltantes), tolerancia a fallas (sin errores de servicio) y calidad lograda (sin errores inesperados). Por lo tanto, definimos nuestro SLI como la "tasa de aciertos" de respuestas exitosas en relación con el número total de solicitudes enviadas a un servicio. Las respuestas exitosas son solicitudes que fueron enviadas en tiempo y forma, lo que significa que no
se produjeron errores de conectividad, de servicio o inesperados.
Este SLI o Success Ratio se recopila desde la perspectiva de los consumidores (es decir, los clientes). La intención es medir la experiencia real de extremo a extremo brindada a nuestros consumidores para que estemos seguros de que se están cumpliendo los SLA. No hacerlo crearía una falsa sensación de confiabilidad que ignora todos los problemas 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 alinearse con el SLA de servicio y existe una dependencia directa con 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 esa 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 puede hacer cumplir con fuerza las barreras de calidad (es decir, la cobertura del código) y reportar otras métricas significativas, como el cumplimiento de los estándares de codificación y el análisis de código estático. Este tema ya ha sido tratado en otro artículo, Cree microservicios basados en el rendimiento. La adhesión diligente a la calidad se suma a la confiabilidad, porque cuanto más invertimos en lograr puntajes excelentes, más seguros estamos de que el sistema no fallará en condiciones adversas.
Nuestro equipo tiene dos tableros. Uno proporciona una visibilidad completa del SLI del consumidor y del SLI de dependencia. El segundo muestra todas las métricas de calidad. Estamos trabajando para fusionar todo en un solo tablero, de modo que todos los aspectos que nos importan estén consolidados y listos para informar en cualquier momento.
Anticiparse al fracaso
la columna Acción Revisiones arquitectónicas es un elemento fundamental para ser confiable. Primero, determinamos si hay redundancia y si el servicio tiene los medios para sobrevivir cuando caen las dependencias. Más allá de las ideas típicas de replicación, la mayoría de nuestros servicios han aplicado técnicas mejoradas de hidratación de caché doble, estrategias de recuperación doble (como colas locales de conmutación por error) o estrategias de pérdida de datos (como 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 tengan en cuenta los escenarios de desastre y minimicen cualquier penalización de rendimiento.
Otro aspecto importante a anticipar es cualquier cosa que pueda mejorar la conectividad. Esto significa ser agresivo con la latencia baja para los clientes y prepararlos para un tráfico muy alto mediante el uso de técnicas de control de caché, sidecars y políticas de rendimiento para tiempos de espera, disyuntores y reintentos. Estas prácticas se aplican a todos los clientes, incluidos cachés, almacenes, colas y clientes interdependientes en HTTP y gRPC. También significa mejorar las señales de servicio saludables y comprender que los controles de salud juegan un papel importante en la orquestación de todos los contenedores. La mayoría de nuestros servicios brindan 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.
Desglosar los servicios en elementos críticos y no críticos ha demostrado ser útil para centrarse en la funcionalidad que más importa. Solíamos tener puntos finales 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 tuvo un impacto positivo en cada métrica.
Evaluación del riesgo de adicción es una herramienta importante para identificar posibles problemas de dependencia. Esto significa que identificamos las dependencias con SLI bajo y solicitamos la alineación de SLA. Estas dependencias requieren atención especial durante los pasos de integración. Por lo tanto, 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 resultados y comentarios. Todo este trabajo utiliza la etiqueta de "confiabilidad" para que podamos identificar rápidamente su fuente y prioridades. La caracterización a menudo ocurría hasta que estábamos seguros de que la nueva adicción estaba lista para nosotros. Este trabajo adicional ha ayudado a llevar la dependencia al nivel requerido de confiabilidad que esperamos brindar al actuar juntos por un objetivo común.
Estructura el caos
Nunca es deseable tener incidentes. Pero cuando suceden, hay información significativa para recopilar y aprovechar para ser más confiable. Nuestro equipo tiene un informe de incidentes de equipo que se crea más allá del típico informe de toda la empresa, por lo que nos enfocamos en todos los incidentes, independientemente de la magnitud de su impacto. Identificamos la causa raíz y priorizamos todo el trabajo para mitigarla en el futuro. Como parte de este informe, involucramos a otros equipos para resolver incidentes de dependencia con alta prioridad, realizar un seguimiento con la resolución adecuada, realizar una retrospectiva y buscar patrones que puedan aplicarse a nosotros.
El equipo produce un Reporte mensual de confiabilidad por servicio esto incluye todos los SLI aquí explicados, todos los tickets que hemos abierto por confiabilidad y todas las posibles incidencias asociadas al servicio. Estamos tan acostumbrados a generar estos informes que el siguiente paso natural es automatizar su extracción. Es importante realizar esta actividad periódicamente, y es un recordatorio de que la confiabilidad se supervisa constantemente y se tiene en cuenta en nuestro desarrollo.
Nuestra instrumentación incluye métricas personalizadas y alertas mejoradas para que se nos notifique lo antes posible cuando surjan problemas conocidos y esperados. Todas las alertas, incluidos los falsos positivos, se revisan semanalmente. En este punto, es importante pulir toda la documentación para que nuestros consumidores sepan qué esperar cuando se activen las alertas y cuando ocurran errores, y luego todos sepan qué hacer (por ejemplo, la integración de guías y libros de estrategias se alinea y actualiza con frecuencia).
finalement, abrazar la calidad en nuestra cultura es el factor más crítico y decisivo para lograr una mayor confiabilidad. Podemos observar cómo estas prácticas aplicadas a nuestro trabajo diario 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 podrían tener las fallas potenciales y cuándo podrían presentarse. Los servicios que han implementado estas prácticas han cumplido consistentemente con sus SLO y SLA. Los informes de confiabilidad que nos ayudan a rastrear todo el trabajo que hemos realizado son un testimonio del arduo trabajo que está haciendo nuestro equipo y son lecciones invaluables para informar e influir en otros equipos. Así es como la cultura de la confiabilidad toca todos los componentes de nuestra plataforma.
El camino hacia una mayor confianza no es fácil, pero es necesario si desea crear una plataforma de confianza que reinvente la forma en que las personas se unen.
Alberto es ingeniero de software sénior en el equipo de Identidad de cuenta en Roblox. Tiene una larga historia en la industria del juego, con créditos en numerosos títulos de juegos AAA y plataformas de redes sociales con un fuerte enfoque en arquitecturas altamente escalables. Ahora, ayuda a Roblox a lograr el crecimiento y la madurez aplicando las mejores prácticas de desarrollo.
