O noso equipo encántanlle os experimentos. Cada Slurm non é unha repetición estática dos anteriores, senón unha reflexión sobre a experiencia e unha transición de bo a mellor. Pero con decidimos aplicar un formato completamente novo: dar aos participantes condicións o máis próximas ao "combate".
Se describimos brevemente o que fixemos durante o curso intensivo: “Construímos, rompemos, reparamos,
estamos estudando". A SRE vale pouco na mera teoría: só práctica, solucións reais, problemas reais.
Os participantes dividíronse en equipos para que un vigoroso espírito competitivo non permitise a ninguén durmir nin lanzar "Angry Birds" no iPhone, seguindo o exemplo de Dmitry Anatolyevich.
Problemas, fallos, erros e tarefas foron proporcionados aos participantes por catro mentores. Ivan Kruglov, desenvolvedor principal de Booking.com (Países Baixos). Ben Tyler, desenvolvedor principal en Booking.com (EE. UU.). Eduard Medvedev, CTO de Tungsten Labs (Alemaña). Evgeniy Varavva, programador xeral de Google (San Francisco).
Ademais, os participantes divídense en equipos e compiten entre si. Interesante?
Ivan, Ben, Eduard e Evgeniy miran aos pobres participantes de Slurm SRE con amables ollos leninistas antes do comezo da competición.
Entón a tarefa:
Somos nosos, imos construír un mundo novo...
Hai un sitio web de agregación de entradas de cine. Os incidentes son inventados por mentores nun escenario previamente traballado (aínda que ninguén exclúe a improvisación particularmente sofisticada e insidiosa), o rendemento do sitio descríbese mediante varias métricas. Os problemas poden ser moi diferentes: as entradas para o teatro Moulin Rouge non están cargadas na base de datos; os carteis de películas e actuacións cárganse na base de datos en máis de 10 segundos; a descrición dunha película individual conxélase; O 0,1% dos pedidos xa están reservados; De cando en vez, o sistema de procesamento de pagos falla durante un ou dous minutos. E moitas, moitas, moitas cousas desagradables que poden suceder a un participante de Slurm SRE no seu traballo real.
Estamos preparados para todo... e para todos.
O noso sitio web de longa duración consta de varios microservizos. A súa tarefa é agregar datos sobre espectáculos, prezos e asentos dispoñibles de todos os cines; mostra anuncios de películas, permite seleccionar cine, espectáculo, sala e lugar, reservar e pagar as entradas. En xeral, todo o que o espectador só pode soñar. Pero o usuario nin sequera sospeita que loita titánica pola estabilidade e accesibilidade do sitio está a suceder no seu interior.
Para o sitio intensivo, xeramos indicadores SLO, SLI, SLA, desenvolvemos arquitectura e infraestrutura, implantamos o sitio, configuramos monitorización e alerta. E marchamos.
SLO, SLI, SLA
SLI - indicadores de nivel de servizo. Os SLO son obxectivos de nivel de servizo. SLA - Acordos de nivel de servizo.
O SLA é un termo de metodoloxía ITIL que denota un acordo formal entre o cliente dun servizo e o seu provedor, que contén unha descrición do servizo, os dereitos e obrigas das partes e, o máis importante, o nivel de calidade acordado para a prestación deste. servizo.
Un SLO é un obxectivo de nivel de servizo: un valor obxectivo ou rango de valores para un nivel de servizo que se mide polo SLI. Un valor normal para SLO é "SLI ≤ Target" ou "Lower Limit ≤ SLI ≤ Upper Limit".
O SLI é un indicador de nivel de servizo: unha medida cuantitativa coidadosamente definida dun aspecto do nivel de servizo prestado. Para a maioría dos servizos, o SLI clave considérase que é a latencia de solicitude: o tempo que leva devolver unha resposta a unha solicitude. Outros SLI comúns inclúen a taxa de erros, a miúdo expresada como unha fracción de todas as solicitudes recibidas, e o rendemento do sistema, medido normalmente en solicitudes por segundo.
En primeiro lugar, romperemos os avións, despois as nenas, e despois as nenas...
Os factores internos e externos comezaron a "estragar" SLO desde os primeiros minutos. Todo caeu na cabeza dos administradores: erros dos desenvolvedores, fallos na infraestrutura, afluencia de visitantes e ataques DDoS. Todo o que empeora o SLO.
"- Queridos participantes, apúrome a complacervos, o primeiro que fallas é... todo!"
Ao longo do camiño, os relatores trataron a estabilidade, o orzamento de erros, a práctica de probas, a xestión das interrupcións e a carga operativa.
Non somos fogueiros, nin carpinteiros...
Entón os participantes comezaron a arranxar as cousas - o principal é entender o que coller primeiro.
"- Señor, nunca o vin romper así, nesta forma e en tal posición!"
Entón, ocorreu un accidente. O servizo de procesamento de pagos está inactivo. Como actuar para restaurar a funcionalidade no menor tempo posible?
Os expertos, mirando con agarimo aos participantes, preparan outro truco.
Cada equipo organiza o traballo do grupo para eliminar o accidente: implica aos compañeiros, notifica ás partes interesadas (partes interesadas). Ao mesmo tempo, establécense prioridades. Deste xeito, os participantes adestraron para traballar baixo presión en condicións de tempo extremadamente limitadas.
"Que tipo de horror saíu?!"
Exhala... e remata o exercicio
Xunto cos relatores, unha vez resolto cada problema e estabilizado temporalmente o recinto, o equipo estudou as incidencias dende o punto de vista de SRE. Analizamos os problemas en detalle: as causas da aparición, o progreso da eliminación. Despois diso, tanto equipo por equipo como colectivamente, tomamos decisións sobre como evitalos aínda máis: como mellorar o seguimento, como cambiar sabiamente a arquitectura, como axustar o enfoque de desenvolvemento e funcionamento, como corrixir a normativa. Os relatores demostraron a práctica da realización de autopsias.
“¡Quen máis quere tormento! - Eu!"
Os acertos dos equipos foron rexistrados con rigor e claridade no marcador electrónico.
Para os primeiros lugares - un extra das partes interesadas.
Fonte: www.habr.com