Nossa equipe adora experiências. Cada Slurm não é uma repetição estática do anterior, mas uma reflexão sobre a experiência e uma transição do bom para o melhor. Mas com decidimos aplicar um formato absolutamente novo — oferecer aos participantes condições o mais próximas possível das 'de combate'.
Para resumir brevemente o que fizemos no intensivo: 'Construímos, quebramos, consertamos,
estudamos'. SRE não vale muito na teoria pura — apenas na prática, com soluções reais e problemas reais.
Os participantes foram divididos em equipes, para que o espírito competitivo animado não deixasse ninguém dormir ou jogar 'Angry Birds' no iPhone como exemplo de Dmitry Anatolyevich.
Problemas, falhas, bugs e tarefas foram oferecidos a quatro mentores. Ivan Kruglov, Principal Developer na Booking.com (Países Baixos). Ben Tyler, Principal Developer na Booking.com (EUA). Eduard Medvedev, CTO na Tungsten Labs (Alemanha). Evgeny Varavva, desenvolvedor de perfil amplo no Google (São Francisco).
E os participantes foram divididos em equipes — competindo entre si. Interessante?
Ivan, Ben, Eduard e Evgeny observam os pobres participantes do Slurm SRE com um olhar adequado antes do início da competição.
Então a tarefa:
Nós, nós construiremos um novo mundo…
Há um site agregador de ingressos para o cinema. Os incidentes são criados pelos mentores em um roteiro previamente trabalhado (embora ninguém exclua uma improvisação particularmente sofisticada e astuta), a funcionalidade do site é descrita por várias métricas. Os problemas podem ser os mais diversos: ingressos para o teatro 'Moulin Rouge' não carregam na base; pôsteres de filmes e peças levam mais de 10 segundos para serem carregados na base; a descrição de um filme específico demora a carregar; 0,1% dos pedidos vão parar em lugares já reservados; periodicamente, a sistema de processamento de pagamentos cai por um a dois minutos. E muitas, muitas outras coisas desagradáveis que podem cair sobre o participante do Slurm SRE em seu trabalho real.
Estamos prontos para lidar com tudo… e com todos.
O nosso site sofrido é composto por vários microsserviços. Sua tarefa é agregar dados sobre sessões, preços e assentos disponíveis de todos os cinemas, mostra trailers de filmes, permite escolher o cinema, a sessão, a sala e o lugar, reservar e pagar pelos ingressos. Enfim, tudo o que o espectador pode sonhar. Mas o usuário nem imagina a luta titânica pela estabilidade e disponibilidade do site que ocorre por trás.
Para o site na imersão, formamos os indicadores SLO, SLI, SLA, desenvolvemos a arquitetura e a infraestrutura, fizemos o deploy do site, configuramos o monitoramento e o alerta. E assim começou.
SLO, SLI, SLA
SLI — indicadores de nível de serviço. SLO — objetivos de nível de serviço. SLA — acordos de nível de serviço.
SLA — termo da metodologia ITIL que designa um contrato formal entre o cliente do serviço e seu fornecedor, contendo a descrição do serviço, direitos e obrigações das partes e, o mais importante, o nível de qualidade acordado para a prestação desse serviço.
SLO — é o objetivo de nível de serviço: um valor alvo ou um intervalo de valores para o nível de serviço, que é medido pelo SLI. O valor normal para o SLO é 'SLI ≤ valor alvo' ou 'limite inferior ≤ SLI ≤ limite superior'.
O SLI é um indicador de nível de serviço — uma medida quantitativa bem definida de um aspecto do nível de serviço fornecido. Para a maioria dos serviços, o SLI chave é o tempo de resposta — quanto tempo leva para retornar uma resposta a uma solicitação. Outros SLIs comuns incluem a taxa de erros, geralmente expressa como a proporção de todas as solicitações recebidas, e a capacidade do sistema, geralmente medida em requisições por segundo.
Primeiro, vamos derrubar aviões, e quanto às garotas, bom, as garotas falamos depois...
Fatores internos e externos começaram a 'estragar' o SLO desde os primeiros minutos. Os administradores foram atingidos por tudo — erros dos desenvolvedores, falhas na infraestrutura, influxos de visitantes e ataques DDoS. Tudo que prejudica o SLO.
- Caros participantes, estou aqui para alegrá-los, em primeiro lugar, tudo está caindo... tudo!
No decorrer do evento, os palestrantes discutiram resiliência, orçamento de erros, práticas de teste, gerenciamento de interrupções e carga operacional.
Não somos caldeireiros, nem carpinteiros...
Aqui, os participantes começaram a consertar - o principal é entender por onde começar primeiro.
«- Deus, eu nunca vi algo quebrar assim, nessa forma e nessa posição!»
E então, ocorreu uma falha. O serviço de processamento de pagamentos caiu. Como agir para restaurar a funcionalidade no menor tempo possível?
Os especialistas, olhando carinhosamente para os participantes, preparam a próxima armadilha.
Cada equipe organiza o trabalho do grupo para eliminar a falha - convocam colegas, informam os interessados (stakeholders). Ao mesmo tempo, definem prioridades. Assim, os participantes praticaram trabalhar sob pressão em condições de tempo extremamente limitado.
«- Que tipo de horror é esse?!»
Expiraram… e finalizaram o exercício.
Com os palestrantes, após cada problema resolvido e o site temporariamente estabilizado, as equipes analisavam os incidentes do ponto de vista SRE. Analisavam detalhadamente os problemas - causas e como foram solucionados. Após isso, tanto em equipe quanto coletivamente, tomavam decisões sobre como prevenir futuros incidentes: como melhorar o monitoramento, como mudar a arquitetura adequadamente, como ajustar a abordagem ao desenvolvimento e operação, como corrigir os regulamentos. Os palestrantes demonstraram a prática de realizar análises pós-morte.
«- Quem mais quer sofrimento! - Eu!»
No painel eletrônico, os sucessos das equipes eram registrados de forma rigorosa e clara.
Para os primeiros lugares - prêmio dos stakeholders.
Fonte: habr.com
