Em 21 de maio, um curso intensivo SRE terá início em Slurme. Durante três dias inteiros, os participantes mergulharão na teoria e na prática de suporte a serviços de alta carga. Sem tarefas de trabalho, sem assuntos familiares - apenas estude. Abaixo do corte, nós dizemos o que o espera se você decidir aderir.
Ajuda SRE
Site Reliability Engineering (SRE) - garantindo a confiabilidade dos sistemas de informação. Esta é uma nova abordagem para oferecer suporte a sites, serviços e aplicativos com milhares e milhões de usuários. A abordagem se originou no Google e agora está se espalhando pelo mundo. Na Rússia, o SRE foi implementado em Yandex, Mail.ru, Sberbank, Tinkoff, MTS, Megafon e outras empresas.
Desenvolvedores e administradores de sistema experientes tornam-se engenheiros SRE: é importante um conhecimento profundo dos sistemas operacionais de servidor, operação de rede, ferramentas de monitoramento, bem como habilidades de programação. Todas essas habilidades são superpostas à metodologia SRE - práticas específicas que ajudam a garantir alta confiabilidade.
“SRE não é tanto sobre alertas e autópsias. Trata-se do fato de que o código que mina à noite não chega à produção. ”
Da comunicação com engenheiros que implementaram SRE
Por muito tempo, a principal fonte de conhecimento sobre SRE foi o livro de mesmo nome do Google. Agora, existem vários programas de treinamento de inglês e russo. Um deles é o SRE intensivo em Slurme.
Formato intensivo
O curso intensivo ocorre online e consiste em palestras e sessões práticas. Haverá transmissão em Zoom e chat no Telegram com palestrantes.
Dois tipos de prática. Os exercícios práticos são de dois tipos: personalização por exemplo e trabalho em tarefas, cuja solução não é predeterminada. No curso intensivo, eles são chamados de casos .
Trabalho em equipe em um serviço real. Para trabalhar nos casos, os participantes do intensivo estão unidos em equipes de 5 a 8 pessoas. Cada equipe recebe um estande com um aplicativo - diversos VDS, que hospeda um site de pedidos de ingressos .
Serviço de encomenda de bilhetes, cujo funcionamento estável será assegurado pelos participantes da Simulação Intensiva de
Falhas.Durante o intensivo, várias falhas importantes ocorrerão no trabalho do site, e a tarefa da equipe é encontrar a causa, eliminar e prevenir sua recorrência. Os casos são baseados em experiências reais: os palestrantes coletaram os problemas que enfrentaram durante a prática de SRE e criaram um ambiente para simular esses problemas.
Palestrantes experientes. O programa intensivo foi desenvolvido e será conduzido por:
- Ivan Kruglov, Engenheiro de Software da Equipe da Databricks.
- Artyom Artemiev, Chefe SRE da TangoMe.
- Pavel Selivanov, Engenheiro de DevOps Sênior da Mail.ru Cloud Solutions.
Apoiar. Os curadores ajudarão a unir equipes e organizar o trabalho conjunto. Palestrantes e engenheiros de suporte técnico da Slurm irão apoiá-lo na solução de problemas complexos.
Formato remoto. As palestras são transmitidas em Zoom, a discussão das tarefas ocorre no Slack. Todas as notas das aulas serão preservadas e ficarão disponíveis após o intensivo, convém voltar a elas depois de um tempo, já em um ambiente mais tranquilo.
Três dias de imersão total. O intensivo é projetado para três dias inteiros, das 10h às 18h, horário de Moscou. Haverá pequenos intervalos entre as palestras e o almoço.
Comece em 21 de maio. Ainda há espaço.
Saiba mais e inscreva-se
Abaixo está o programa intensivo completo.
Dia 1: familiarizando-se com a teoria da SRE, configurando monitoramento e alerta
No primeiro dia, você conhecerá a teoria da SRE, aprenderá a configurar o monitoramento e alerta, além de se associar aos demais participantes do intensivo.
Vamos falar sobre as métricas SLO, SLI, SLA e como elas se relacionam com os requisitos de negócios. Compartilharemos as melhores práticas para configurar o monitoramento e regras para o corpo de bombeiros. Daremos os primeiros casos práticos.
Tópico 1: Monitoramento
- Por que você precisa de monitoramento,
- Sintomas versus causas,
- Black-Box vs. Monitoramento de caixa branca,
- Sinais dourados,
- Percentis,
- Alertando,
- Observabilidade.
Prática: Fazendo um painel básico e configurando os alertas necessários.
Tópico 2: teoria SRE
- SLO, SLI, SLA,
- Durabilidade,
- Orçamento de erro.
Prática: Adicionando alertas SLO / SLI + ao painel.
Prática: Primeira carga do sistema.
Caso 1: vício a jusante. Em um sistema grande, há muitos serviços interdependentes e nem sempre funcionam igualmente bem. É especialmente ofensivo quando o seu serviço está em ordem, e o vizinho, do qual você depende, cai periodicamente. O projeto formativo se encontrará em tais condições, e você fará com que ele continue a dar a qualidade ao mais alto nível possível.
Tópico 3: Gerenciamento de Incidentes
- Engenharia de Resiliência,
- Como a brigada de incêndio se alinha
- Quão eficaz é sua equipe no incidente,
- 7 regras para um líder de incidente,
- 5 regras para um bombeiro,
- HiPPO - opinião da pessoa mais bem paga. Líder de comunicações.
Caso 2: vício ascendente. Uma coisa é quando você depende de um serviço com um SLO baixo. É outra questão quando seu serviço é assim para outras partes do sistema. Isso acontece se os critérios de avaliação não forem acordados: por exemplo, você responde a uma solicitação em um segundo e a considera um sucesso, mas o serviço dependente espera apenas 500, horário de Moscou, e sai com um erro. Nesse caso, discutiremos a importância da conciliação das métricas e aprenderemos a olhar para a qualidade pelos olhos do cliente.
Tópico 4: SRE integrando um projeto
Em grandes empresas, não é incomum formar uma equipe de SRE separada, que conta com o apoio de serviços de outros departamentos. Mas nem todo serviço está pronto para ser suportado. Diremos a você quais requisitos ele deve atender.
Dia 2: resolvendo problemas com o meio ambiente e arquitetura
O segundo dia é quase inteiramente construído em torno da resolução de dois casos: problemas com o ambiente (haverá uma análise detalhada do Health Checking) e problemas com a arquitetura. Os palestrantes falarão sobre como trabalhar com autópsias e fornecerão modelos que você pode usar em sua equipe.
Tópico 5: Verificação de saúde
- Verificação de saúde no Kubernetes,
- Nosso serviço está vivo?
- Sondas de execução,
- initialDelaySeconds,
- Porto Secundário de Saúde,
- Sidecar Health Server,
- Sonda sem cabeça,
- Sonda de hardware.
Caso 3: problemas ambientais e o Healthcheck correto. A tarefa do Healthcheck é detectar um serviço de tempo de inatividade e bloquear o tráfego para ele, para que os usuários não enfrentem problemas. E se você acha que basta fazer o root de uma solicitação ao serviço e obter uma resposta, engana-se: mesmo que o serviço responda, isso não garante seu desempenho - pode haver problemas no ambiente. Através deste caso, você aprenderá como configurar o Healthcheck correto e não deixar o tráfego ir onde não pode ser processado.
Tópico 6: Prática de trabalho com autópsias - escrevemos uma autópsia com base no caso anterior e analisamos com os palestrantes.
Tópico 7: Resolvendo problemas de infraestrutura
- Monitorando MySQL,
- SLO / SLI para MySQL,
- Detecção de anomalia.
Caso 4: problemas com o banco de dados. O banco de dados também pode ser uma fonte de problemas. Por exemplo, se você não monitorar a retransmissão de replicação, a réplica se tornará obsoleta e o aplicativo retornará dados antigos. Além disso, é especialmente difícil depurar esses casos: agora os dados são inconsistentes, mas depois de alguns segundos, eles se foram, e a causa do problema não está clara. Através do case, você sentirá toda a dor da depuração e aprenderá como prevenir tais problemas.
Dia 3: blindagem de tráfego e liberações de canário
Existem dois casos de alta disponibilidade de produção: blindagem de tráfego e implantação canário. Você aprenderá sobre essas abordagens e como aplicá-las. Não estamos planejando afinação hardcore à mão, embora quem sabe.
Tópico 8: Proteção de tráfego
- comportamento dos gráficos de crescimento do número de solicitações e operações comerciais
- saturação e planejamento de capacidade
- traffic shielding rate limiting
- sidecar rate-limiting 100
5: traffic shielding. ? , 100 , 1000. , , , . , .
9: Canary Deployment
- k8s (Rolling Update vs Recreate),
- canary blue-green ,
- blue-gree/canary release k8s,
- canary release GitLab CI/CD,
- canary release,
- .gitlab-ci.yml.
6: . ,
, - . , . Canary Deployment, .