Pense no SRE: veja os projetos através dos olhos de um engenheiro do SRE

Nas críticas de Slurm, Kubernetes tocou a frase: "Kubernetes acabou sendo mais fácil do que eu pensava". Agora não soa mais, o mito da complexidade dos k8s não existe mais. Ele passou para a categoria de ferramentas fáceis de aprender, difíceis de dominar.

Queremos repetir o mesmo com o SRE. Mostre que o SRE é mais fácil e compreensível do que parece. Mude o paradigma: permita que as pessoas vejam o projeto através dos olhos de um engenheiro da SRE.

Como sempre, no início, há muitas incógnitas na equação. E, como sempre, no início, o mais interessante será o primeiro.

De 3 a 5 de fevereiro, sediaremos o Slurm SRE em Moscou. Um ingresso intensivo de três dias custa 60 mil. O que o participante receberá pelo seu dinheiro?

Quando digo a amigos e colegas sobre SRE, me deparo com um ceticismo saudável:

• Pela primeira vez que ouvi falar sobre SRE, é algum tipo de alquimia.
• A implementação do SRE é difícil para gigantes como o Google.
• É caro e longo, eles não dão tempo, não alocam um orçamento.
• O que você descreve é ​​bom demais para ser verdade.

Eu quero fazer essas perguntas.

É hora de descobrir o que é SRE.

No nível do slogan: SRE é uma das implementações do DevOps. Ele apareceu há mais de 10 anos no Google, mas só recentemente começou a penetrar no mercado "regular", principalmente graças ao livro Site Reliability Engeneering, lançado pelo Google em 2016.

A conexão entre SRE e DevOps está bem descrita neste vídeo:

O ruim é que slogans são sobre nada. Bem DevOps, bem, implementação, o próximo "para todos os bons versus todos os ruins".

Você pode ler o livro (e vale a pena). Mas o leitor se encontrará na posição de uma pessoa que estuda karatê a partir de desenhos. O livro descreve o conceito sem aplicação à realidade. O professor conduz a mão por um caminho específico e aponta erros no processo.

O preço inclui uma análise rápida e aprofundada da abordagem e ferramentas SRE.

Implementar o SRE é mais fácil do que parece

No Slurm, tocaremos no SRE com nossas mãos: selecionaremos métricas, configuraremos suas medições, alertas, encontraremos incidentes, resolveremos e analisá-los, reconstruiremos o projeto de acordo com todos os cânones do SRE.

Ou seja, forneceremos instruções passo a passo que você pode implementar por conta própria ao retornar do intensivo.

Eu estou mentindo. De fato, não daremos instruções, mas uma amostra a partir da qual você pode tirar um monte de idéias e soluções.

O preço inclui uma amostra para implementação.

O principal problema é que você precisa convencer aqueles que não estiveram em Slurm. Portanto, idealmente, vale a pena vir intensivamente como uma equipe inteira. Portanto, damos grandes descontos para grupos.

Seria bom chegar a Slerm, liderado pela estação de serviço. E o CEO também é útil, e sobre esta seção ...

... como convencer a alta gerência de que o SRE é útil e necessário.

Geralmente, há um conflito de tarefas entre CEO (alta gerência), STO (gerenciamento de TI), desenvolvedores e operação.

Eu intencionalmente não digo "conflito de interesses", é precisamente um conflito de tarefas.

O CEO precisa de desempenho financeiro. STO - uma situação compreensível, gerenciável e o mais confortável possível. Ou seja, tarefas compreensíveis com valor comercial compreensível, cumprimento de prazos, uma pilha normal, mais recursos e menos fakaps. Os desenvolvedores precisam implementar mais recursos e exploração - para garantir a acessibilidade (que claramente entra em conflito com "mais recursos").

O SRE diz que todos os participantes do processo têm uma única tarefa: a felicidade do usuário. O usuário está satisfeito com um equilíbrio saudável entre novos recursos e a confiabilidade do serviço. Usuário feliz paga mais dinheiro. Para gerenciar a felicidade do usuário, você precisa de ferramentas especializadas.

Além disso, o SRE, baseado em métricas, permite converter indicadores financeiros em indicadores-alvo de várias métricas e, por sua vez, em tarefas das equipes de DevOps.

Permite que você traduza - eu exagerei. A presença dessas métricas permite encontrar o relacionamento entre o estado das métricas e os indicadores financeiros. Essa é uma tarefa grande, mas compreensível, separada.

Existe um projeto DORA, DevOps Research & Assessments , que libera estudos anuais sobre o valor para os negócios e o ROI DevOps e sua subclasse SRE. Agora, estamos traduzindo o relatório atual para o russo. Existem fórmulas de avaliação que podem ser aplicadas à sua empresa com um certo grau de precisão.

Resumo: O SRE oferece às empresas a capacidade de gerenciar o desempenho financeiro, definindo metas de métricas, e a equipe do DevOps, observando as métricas atuais, entende claramente o que precisa ser feito para o benefício máximo do desempenho financeiro. Qual CEO recusará tal ferramenta?

É bem possível obter recursos para a implementação do SRE.

O preço do curso inclui um conjunto de argumentos a favor da mudança para SRE e DevOps.

E mesmo em pequenas empresas, existe um lugar para a SRE.

O SRE é dividido em ferramentas, cultura e estrutura organizacional.

Algumas ferramentas, por exemplo, Service Mesh, são necessárias para projetos grandes e complexos. Mas a mesma tentativa, retirada, injeção de falha e degradação graciosa pode ser implementada em pequenos projetos, e eles oferecem um retorno enorme.

A cultura também é útil em qualquer empresa. O administrador clássico, configurando o Prometheus, agirá de acordo com o padrão: incluirá o monitoramento do consumo de memória e disco e outro monitoramento familiar. O engenheiro do SRE primeiro discutirá os principais indicadores dos processos de negócios com a empresa e, em seguida, configurará seu monitoramento. É imediatamente óbvio que a cultura de engenharia de SRE é útil mesmo em micro-startups.

Mas a estrutura organizacional em pequenas empresas provavelmente não é necessária nem prejudicial. Quando todos os funcionários são generalistas, não há necessidade de alocar à força comandos do SRE.

Tudo o que descrevemos já está funcionando

O curso foi criado por aqueles que há muito implementam o SRE em suas equipes e vivem há muito tempo nesse paradigma. Ivan Kruglov e Ben Tyler, ambos são desenvolvedores principais da Booking.com. Eugene Varavva, desenvolvedor de perfil amplo no Google. Eduard Medvedev, CTO da Tungsten Labs, que cresceu com um engenheiro da SRE.

Edward realiza um webinar "SRE - HYIP ou o futuro?" , 12 de dezembro às 11:00.

Sobre o programa

Quanto ao programa. Já estou recebendo feedback de especialistas de que o programa não está lutando: é muito amplo e às vezes ilógico. É mesmo.

De fato, temos uma estrutura para o programa, um conjunto de idéias que queremos revelar. Temos dois meses de trabalho árduo pela frente, enquanto nos preparamos, o programa será esclarecido: removemos o desnecessário e especificamos o restante.

Mas já em sua forma atual, o programa mostra claramente a direção em que estamos trabalhando.

Todos os itens acima valem o dinheiro?

PS. O que o hub Kubernetes tem a ver com isso

Toda a prática é realizada no Kubernetes. Aqueles que possuem Kubernetes têm um caminho direto para os engenheiros da SRE. Para quem não possui, vá para os cursos do Kubernetes .

Registro para Slurm SRE