SRE lento. Un experimento completo con expertos de Booking.com y Google.com

A nuestro equipo le encantan los experimentos. Cada Slurm no es una repetición estática de los anteriores, sino una reflexión sobre la experiencia y una transición de bueno a mejor. Pero con SRE de barrio bajo Decidimos aplicar un formato completamente nuevo: brindar a los participantes condiciones lo más cercanas posible al "combate".

Si resumimos brevemente lo que hicimos durante el curso intensivo: “Construimos, rompemos, reparamos,
estamos estudiando." La ERE vale poco en mera teoría: sólo en la práctica, soluciones reales, problemas reales.

Los participantes se dividieron en equipos para que un vigoroso espíritu competitivo no permitiera a nadie quedarse dormido o ejecutar "Angry Birds" en el iPhone, siguiendo el ejemplo de Dmitry Anatolyevich.

Cuatro mentores proporcionaron a los participantes problemas, fallos, errores y tareas. Ivan Kruglov, desarrollador principal de Booking.com (Países Bajos). Ben Tyler, desarrollador principal de Booking.com (EE. UU.). Eduard Medvedev, CTO de Tungsten Labs (Alemania). Evgeniy Varavva, desarrollador general de Google (San Francisco).

Además, los participantes se dividen en equipos y compiten entre sí. ¿Interesante?

SRE lento. Un experimento completo con expertos de Booking.com y Google.com
Ivan, Ben, Eduard y Evgeniy miran a los pobres participantes de Slurm SRE con amables ojos leninistas antes del inicio de la competición.

Entonces la tarea:

Somos nuestros, construiremos un nuevo mundo ...

Hay un sitio web de agregación de entradas de cine. Los incidentes son inventados por mentores en un escenario previamente elaborado (aunque nadie excluye una improvisación particularmente sofisticada e insidiosa), el rendimiento del sitio se describe mediante varias métricas. Los problemas pueden ser muy diferentes: las entradas para el teatro Moulin Rouge no se cargan en la base de datos; los carteles de películas y espectáculos se cargan en la base de datos en más de 10 segundos; la descripción de una película individual se congela; El 0,1% de los pedidos ya están reservados; De vez en cuando, el sistema de procesamiento de pagos falla durante uno o dos minutos. Y muchas, muchas, muchas cosas desagradables que le pueden suceder a un participante de Slurm SRE en su trabajo real.

SRE lento. Un experimento completo con expertos de Booking.com y Google.com
Estamos listos para manejar cualquier cosa... y todos.

Nuestro sufrido sitio web consta de varios microservicios. Su tarea es agregar datos sobre espectáculos, precios y asientos disponibles de todos los cines; muestra anuncios de películas, permite seleccionar cine, espectáculo, sala y lugar, reservar y pagar entradas. En general, todo aquello con lo que el espectador sólo puede soñar. Pero el usuario ni siquiera sospecha la lucha titánica que se libra en su interior por la estabilidad y accesibilidad del sitio.

Para el sitio intensivo, generamos indicadores SLO, SLI, SLA, desarrollamos arquitectura e infraestructura, implementamos el sitio, configuramos monitoreo y alertas. Y allá vamos.

SLO, SLI, SLA

SLI - indicadores de nivel de servicio. Los SLO son objetivos de nivel de servicio. SLA: acuerdos de nivel de servicio.

SLA es un término de la metodología ITIL que denota un acuerdo formal entre el cliente de un servicio y su proveedor, que contiene una descripción del servicio, los derechos y obligaciones de las partes y, lo más importante, el nivel de calidad acordado para la prestación de este. servicio.

Un SLO es un objetivo de nivel de servicio: un valor objetivo o rango de valores para un nivel de servicio que mide el SLI. Un valor normal para SLO es "SLI ≤ Objetivo" o "Límite inferior ≤ SLI ≤ Límite superior".

El SLI es un indicador del nivel de servicio: una medida cuantitativa cuidadosamente definida de un aspecto del nivel de servicio prestado. Para la mayoría de los servicios, se considera que el SLI clave es la latencia de solicitud: cuánto tiempo se tarda en devolver una respuesta a una solicitud. Otros SLI comunes incluyen la tasa de error, a menudo expresada como una fracción de todas las solicitudes recibidas, y el rendimiento del sistema, generalmente medido en solicitudes por segundo.

Primero que nada, romperemos los aviones, y luego las chicas, y luego las chicas...

Los factores internos y externos comenzaron a "estropear" a SLO desde los primeros minutos. Todo recayó sobre las cabezas de los administradores: errores de los desarrolladores, fallas de infraestructura, una afluencia de visitantes y ataques DDoS. Todo lo que empeora SLO.

SRE lento. Un experimento completo con expertos de Booking.com y Google.com
“- Queridos participantes, me apresuro a complacerlos, lo primero que fallan es… ¡todo!”

A lo largo del camino, los oradores discutieron la estabilidad, el presupuesto de errores, la práctica de pruebas, la gestión de interrupciones y la carga operativa.

No somos fogoneros, ni carpinteros...

Luego, los participantes comenzaron a arreglar las cosas; lo principal es entender qué agarrar primero.

SRE lento. Un experimento completo con expertos de Booking.com y Google.com
“- ¡Señor, nunca lo había visto romperse así, en esta forma y en tal posición!”

Entonces ocurrió un accidente. El servicio de procesamiento de pagos no funciona. ¿Cómo actuar para restablecer la funcionalidad en el menor tiempo posible?

SRE lento. Un experimento completo con expertos de Booking.com y Google.com
Los expertos, mirando con cariño a los participantes, preparan otro truco.

Cada equipo organiza el trabajo del grupo para eliminar el accidente: involucra a colegas, notifica a las partes interesadas (partes interesadas). Al mismo tiempo, se establecen prioridades. De esta manera, los participantes se entrenaron para trabajar bajo presión en condiciones de tiempo extremadamente limitadas.

SRE lento. Un experimento completo con expertos de Booking.com y Google.com
“¡¿Qué clase de horror ha salido?!”

Exhala... y termina el ejercicio.

Junto con los ponentes, una vez resuelto cada problema y estabilizado temporalmente el lugar, el equipo estudió las incidencias desde el punto de vista de la SRE. Analizamos los problemas en detalle: las causas de su aparición, el progreso de la eliminación. Después de eso, tanto equipo por equipo como colectivamente, tomamos decisiones sobre cómo prevenirlos aún más: cómo mejorar el monitoreo, cómo cambiar sabiamente la arquitectura, cómo ajustar el enfoque de desarrollo y operación, cómo corregir las regulaciones. Los oradores demostraron la práctica de realizar autopsias.

SRE lento. Un experimento completo con expertos de Booking.com y Google.com
“¡Quién más quiere tormento! - ¡I!"

Los éxitos de los equipos se registraron de forma estricta y clara en el marcador electrónico.

SRE lento. Un experimento completo con expertos de Booking.com y Google.com

Para los primeros lugares: una bonificación de las partes interesadas.

SRE lento. Un experimento completo con expertos de Booking.com y Google.com

Fuente: habr.com

Añadir un comentario