Nossa equipe adora experimentos. Cada Slurm não é uma repetição estática dos anteriores, mas uma reflexão sobre a experiência e uma transição do bom para o melhor. Mas com decidimos aplicar um formato completamente novo - para dar aos participantes condições o mais próximas possível do “combate”.
Se resumirmos brevemente o que fizemos durante o curso intensivo: “Construímos, quebramos, reparamos,
estamos estudando." A SRE vale pouco em mera teoria – apenas prática, soluções reais, problemas reais.
Os participantes foram divididos em equipes para que um forte espírito competitivo não permitisse que ninguém adormecesse ou lançasse “Angry Birds” no iPhone, a exemplo de Dmitry Anatolyevich.
Problemas, falhas, bugs e tarefas foram fornecidos aos participantes por quatro mentores. Ivan Kruglov, desenvolvedor principal da Booking.com (Holanda). Ben Tyler, desenvolvedor principal da Booking.com (EUA). Eduard Medvedev, CTO da Tungsten Labs (Alemanha). Evgeniy Varavva, desenvolvedor geral do Google (São Francisco).
Além disso, os participantes são divididos em equipes e competem entre si. Interessante?
Ivan, Ben, Eduard e Evgeniy olham para os pobres participantes do Slurm SRE com olhares leninistas gentis antes do início da competição.
Então a tarefa:
Nós somos nossos, vamos construir um novo mundo ...
Existe um site agregador de ingressos de cinema. Os incidentes são inventados por mentores num cenário pré-elaborado (embora ninguém exclua improvisações particularmente sofisticadas e insidiosas), o desempenho do site é descrito por várias métricas. Os problemas podem ser muito diferentes: os ingressos para o teatro Moulin Rouge não são carregados no banco de dados; pôsteres de filmes e performances são carregados no banco de dados em mais de 10 segundos; a descrição de um filme individual congela; 0,1% dos pedidos já estão reservados; De tempos em tempos, o sistema de processamento de pagamentos trava por um ou dois minutos. E muitas, muitas, muitas coisas desagradáveis que podem acontecer a um participante do Slurm SRE em seu trabalho real.
Estamos prontos para lidar com qualquer coisa... e com todos.
Nosso sofrido site consiste em vários microsserviços. A sua função é agregar dados sobre espectáculos, preços e lugares disponíveis de todos os cinemas; mostra anúncios de filmes, permite seleccionar cinema, espectáculo, sala e local, reservar e pagar bilhetes. Em geral, tudo com que o espectador só pode sonhar. Mas o usuário nem suspeita da luta titânica pela estabilidade e acessibilidade do site que está acontecendo lá dentro.
Para o site intensivo, geramos indicadores de SLO, SLI, SLA, desenvolvemos arquitetura e infraestrutura, implantamos o site, montamos monitoramento e alertas. E lá vamos nós.
SLO, SLI, SLA
SLI - indicadores de nível de serviço. SLOs são metas de nível de serviço. SLA – acordos de nível de serviço.
SLA é um termo da metodologia ITIL que denota um acordo formal entre o cliente de um serviço e seu fornecedor, contendo uma descrição do serviço, os direitos e obrigações das partes e, o mais importante, o nível de qualidade acordado para a prestação deste serviço. serviço.
Um SLO é um objetivo de nível de serviço: um valor alvo ou intervalo de valores para um nível de serviço medido pelo SLI. Um valor normal para SLO é “SLI ≤ Target” ou “Lower Limit ≤ SLI ≤ Upper Limit”.
O SLI é um indicador de nível de serviço – uma medida quantitativa cuidadosamente definida de um aspecto do nível de serviço prestado. Para a maioria dos serviços, o SLI principal é considerado a latência da solicitação – quanto tempo leva para retornar uma resposta a uma solicitação. Outros SLIs comuns incluem a taxa de erros, geralmente expressa como uma fração de todas as solicitações recebidas, e a taxa de transferência do sistema, geralmente medida em solicitações por segundo.
Primeiro de tudo, vamos quebrar os aviões, e depois as meninas, e depois as meninas...
Fatores internos e externos começaram a “estragar” o SLO desde os primeiros minutos. Tudo caiu na cabeça dos administradores: erros dos desenvolvedores, falhas de infraestrutura, fluxo de visitantes e ataques DDoS. Tudo o que piora o SLO.
“- Caros participantes, apresso-me em agradá-los, a primeira coisa que vocês falham é... tudo!”
Ao longo do caminho, os palestrantes discutiram estabilidade, orçamento de erros, práticas de testes, gerenciamento de interrupções e carga operacional.
Não somos foguistas, nem carpinteiros...
Aí os participantes começaram a consertar as coisas - o principal é entender o que pegar primeiro.
“- Senhor, nunca vi quebrar assim, nesta forma e em tal posição!”
Então, ocorreu um acidente. O serviço de processamento de pagamentos está fora do ar. Como agir para restaurar a funcionalidade no menor tempo possível?
Os especialistas, olhando com carinho para os participantes, preparam mais uma manobra.
Cada equipe organiza o trabalho do grupo para eliminar o acidente - envolve colegas, notifica as partes interessadas (stakeholders). Ao mesmo tempo, são definidas prioridades. Desta forma, os participantes treinaram para trabalhar sob pressão em condições de tempo extremamente limitadas.
“Que tipo de horror surgiu?!”
Expire... e termine o exercício
Juntamente com os palestrantes, após a resolução de cada problema e a estabilização temporária do local, a equipe estudou os incidentes do ponto de vista do SRE. Analisamos detalhadamente os problemas - as causas da ocorrência, o progresso da eliminação. Depois disso, tanto equipa a equipa como colectivamente, tomámos decisões sobre como evitá-los ainda mais: como melhorar a monitorização, como alterar sabiamente a arquitectura, como ajustar a abordagem ao desenvolvimento e operação, como corrigir os regulamentos. Os palestrantes demonstraram a prática da condução post-mortem.
“Quem mais quer tormento! - EU!"
Os sucessos das equipes foram registrados de forma estrita e clara no placar eletrônico.
Para os primeiros lugares - um bônus das partes interessadas.
Fonte: habr.com