O webinar tem um som ruim e, por isso, o deciframos.
Meu nome é Edward Medvedev. Hoje vou falar sobre o que é o SRE, como ele apareceu, quais critérios os engenheiros do SRE trabalham, um pouco sobre critérios de confiabilidade, um pouco sobre seu monitoramento. Subimos as escadas, porque você não dirá muito em uma hora, mas darei materiais para familiarização adicional e todos esperamos por você no Slerm SRE . em Moscou no final de janeiro.
Primeiro, vamos falar sobre o que é SRE - Site Reliability Engineering. E como apareceu como uma posição separada, como uma direção separada. Tudo começou com o fato de que nos círculos tradicionais de desenvolvimento, Dev e Ops são duas equipes completamente diferentes, geralmente com dois objetivos completamente diferentes. O objetivo da equipe de desenvolvimento é implantar novos recursos e atender às necessidades dos negócios. O objetivo da equipe de operações é que tudo funcione e nada quebre. Obviamente, esses objetivos se contradizem diretamente: para que tudo funcione e nada quebre, implantar novos recursos é o mínimo possível. Por esse motivo, existem muitos conflitos internos que a metodologia, que agora é chamada DevOps, está tentando resolver.
O problema é que não temos uma definição clara de DevOps e uma implementação clara de DevOps. Eu falei em uma conferência em Ecaterimburgo há 2 anos, e até agora a seção DevOps começou com uma apresentação de "O que é DevOps". Em 2017, o devo tem quase 10 anos, mas ainda discutimos o que é. E essa é uma situação muito estranha que o Google tentou resolver há vários anos.
Em 2016, o Google lançou um livro chamado Site Reliability Engineering. E, de fato, foi a partir deste livro que o movimento SRE começou. O SRE é uma opção específica para implementar o paradigma DevOps em uma empresa específica. Os engenheiros da SRE estabelecem o objetivo de garantir um desempenho confiável do sistema. Eles são extraídos principalmente de desenvolvedores, às vezes de administradores com forte experiência em desenvolvimento. E eles estão fazendo o que os administradores de sistema fizeram antes, mas uma sólida experiência no desenvolvimento e conhecimento do sistema em termos de código leva ao fato de que essas pessoas não estão inclinadas ao trabalho administrativo de rotina, mas tendem à automação.
Acontece que o paradigma do DevOps nas equipes de SRE é implementado pelo fato de existirem engenheiros de SRE que resolvem problemas estruturais. Aqui está, a própria conexão entre Dev e Ops sobre a qual as pessoas falam há 8 anos. O papel do SRE é semelhante ao papel de um arquiteto, no sentido de que os recém-chegados ao SRE não. As pessoas no início de uma carreira ainda não têm experiência, não possuem a amplitude necessária de conhecimento. Porque o SRE requer um conhecimento muito bem do que exatamente e quando exatamente pode dar errado. Portanto, é necessária alguma experiência aqui, como regra, dentro e fora da empresa.
Eles perguntam se a diferença entre SRE e devops será descrita. Ela acabou de ser descrita. Podemos falar sobre o lugar da SRE na organização. Diferente dessa abordagem clássica do DevOps, onde o Ops ainda é um departamento separado, o SRE faz parte da equipe de desenvolvimento. Eles estão envolvidos no desenvolvimento de produtos. Existe até uma abordagem em que o SRE é uma função que se move de um desenvolvedor para outro. Eles participam de revisões de código da mesma maneira que, por exemplo, designers de UX, próprios desenvolvedores e, às vezes, gerentes de produto. O SRE trabalha no mesmo nível. Precisamos da atualização deles, da revisão, para que, para cada implantação do SRE, diga: “Bem, nesta implantação, este produto não afetará negativamente a confiabilidade. E se isso acontecer, então até certo ponto. Também falaremos sobre isso.
Consequentemente, o SRE veta mudar o código. E, em geral, isso também leva a algum tipo de pequeno conflito se o SRE for implementado incorretamente. No mesmo livro sobre Engenharia de confiabilidade do site, muitas partes, nem mesmo uma, informam como evitar esses conflitos.
Eles perguntam como o SRE se relaciona com a segurança da informação. O SRE não está diretamente envolvido na segurança da informação. Basicamente, em grandes empresas, indivíduos, testadores e analistas fazem isso. Mas o SRE também interage com eles no sentido de que algumas operações, algumas confirmações, algumas implantações que afetam a segurança também podem afetar a disponibilidade do produto. Portanto, o SRE como um todo interage com qualquer equipe, incluindo equipes de segurança, incluindo analistas. Portanto, a maioria dos SREs é necessária quando eles tentam implementar o DevOps, mas ao mesmo tempo a carga nos desenvolvedores se torna muito grande. Ou seja, a própria equipe de desenvolvimento não pode mais lidar com o fato de que agora eles também precisam ser responsáveis pelas operações. E um papel separado aparece. Essa função está planejada no orçamento. Às vezes, esse papel é definido no tamanho da equipe, aparece uma pessoa separada, às vezes se torna um dos desenvolvedores. Portanto, o primeiro SRE aparece na equipe.
A complexidade do sistema, que é afetada pelo SRE, a complexidade que afeta a confiabilidade do trabalho, é necessária e aleatória. A complexidade necessária é quando a complexidade de um produto aumenta na medida em que novos recursos do produto exigem. Complexidade aleatória é quando a complexidade do sistema aumenta, mas o recurso do produto e os requisitos de negócios não afetam diretamente isso. Acontece que ou o desenvolvedor cometeu um erro em algum lugar, ou o algoritmo não é o ideal, ou são introduzidos alguns interesses adicionais que aumentam a complexidade do produto sem necessidade especial. Um bom SRE sempre deve interromper essa situação. Ou seja, qualquer confirmação, implantação ou solicitação de recebimento em que a complexidade aumenta devido a adições aleatórias deve ser bloqueada.
A questão é: por que não contratar um engenheiro, um administrador de sistemas com muito conhecimento na equipe. Dizem que um desenvolvedor no papel de engenheiro não é a melhor solução de pessoal. Um desenvolvedor no papel de engenheiro nem sempre é a melhor solução de equipe, mas o ponto aqui é que o desenvolvedor que lida com o Ops tem um pouco mais de desejo por automação, tem um pouco mais de conhecimento e habilidades para implementar essa automação. E, consequentemente, estamos reduzindo não apenas o tempo de operações específicas, não apenas a rotina, mas também parâmetros comerciais importantes como MTTR (tempo médio de recuperação, tempo de recuperação). Assim, e isso também será um pouco mais tarde, economizamos dinheiro para a organização.
Agora vamos falar sobre os critérios para o trabalho da SRE. E antes de tudo sobre confiabilidade. Nas pequenas empresas, startups, muitas vezes acontece que as pessoas assumem que, se o serviço for bem escrito, se o produto for bem e corretamente escrito, ele funcionará, não será interrompido. É tudo, escrevemos um bom código, então não há nada para quebrar. O código é muito simples, não há nada para quebrar. São as mesmas pessoas que dizem que não precisamos de testes, porque, veja, esses são três métodos de VPI, por que quebrar?
Está tudo errado, é claro. E muitas vezes essas pessoas mordem esse código na prática, porque as coisas quebram. As coisas às vezes quebram da maneira mais imprevisível. Às vezes as pessoas dizem que não, isso nunca vai acontecer. E tudo acontece exatamente. Isso acontece com bastante frequência. E, portanto, ninguém nunca se esforça para 100% de disponibilidade, porque 100% de disponibilidade nunca acontece. Essa é a norma. E, portanto, quando falamos sobre a disponibilidade de um serviço, sempre falamos sobre noves. 2 noves, 3 noves, 4 noves, 5 noves. Se você traduzir isso em tempo de inatividade, por exemplo, 5 noves, isso significa um pouco mais de 5 minutos de inatividade por ano, 2 noves são 3,5 dias de inatividade.
Mas é óbvio que, em algum momento, há uma diminuição no POI, no retorno do investimento. Passando de dois a nove, isso significa reduzir o tempo de inatividade em mais de 3 dias. Passar de quatro para nove reduz o tempo de inatividade em 47 minutos por ano. E acontece que para uma empresa isso pode não ser crítico. E, em geral, a confiabilidade necessária não é uma questão técnica, antes de tudo, é uma questão de negócios, é uma questão de produto. Qual nível de tempo de inatividade é aceitável para os usuários do produto, o que eles esperam, quanto pagam, por exemplo, quanto dinheiro perdem, quanto dinheiro o sistema perde.
Uma questão importante nesse caso é qual é a confiabilidade dos componentes restantes. Porque a diferença entre 4 e 5 noves não será visível em um smartphone com 2 noves de confiabilidade. Grosso modo, se algo quebrar em um smartphone em seu serviço 10 vezes por ano, provavelmente 8 vezes a falha ocorreu precisamente no lado do sistema operacional. O usuário está acostumado a isso e não prestará atenção uma vez por ano. É necessário correlacionar o preço de aumentar a confiabilidade e aumentar o lucro.
Apenas no livro sobre SRE, há um bom exemplo de como aumentar para 4 noves a partir de 3 noves. Acontece que o aumento na disponibilidade é um pouco menor que 0,1%. E se a receita do serviço for de US $ 1 milhão por ano, o aumento da receita será de US $ 900. Se aumentar a acessibilidade em nove nos custa menos de US $ 900 por ano, esse aumento faz sentido financeiro. Se custa mais de US $ 900 por ano, não faz mais sentido, porque o crescimento da receita simplesmente não compensa os custos de mão de obra, os recursos. E três noves serão suficientes para nós.
Obviamente, este é um exemplo simplificado em que todas as consultas são iguais. E de 3 a 4, é muito fácil alternar, mas ao mesmo tempo, por exemplo, alternar de 2 para 3 já é uma economia de 9 mil dólares, pode fazer sentido financeiramente. Naturalmente, na realidade, uma falha em uma solicitação de registro é pior do que uma falha na exibição de uma página; as solicitações têm peso diferente. Eles podem ter critérios muito diferentes do ponto de vista dos negócios, mas ainda assim, como regra, se não estamos falando de nenhum serviço específico, essa é uma aproximação bastante confiável.
Perguntamos se o SRE é um dos coordenadores ao escolher uma solução de arquitetura para um serviço. Vamos assumir, em termos de integração na infraestrutura existente, para que não haja perda de estabilidade. Sim, os SREs têm o mesmo efeito em solicitações, confirmações, liberações, afetam a arquitetura, a introdução de novos serviços, microsserviços e a introdução de novas soluções. Por que eu disse antes que preciso de experiência, preciso de qualificações. De fato, o SRE é uma das vozes de bloqueio em qualquer solução de arquitetura e software. Assim, o SRE como engenheiro deve, em primeiro lugar, não apenas entender, mas também entender como quaisquer soluções específicas afetarão a confiabilidade, a estabilidade e entender como isso se relaciona às necessidades do negócio e de que ponto de vista pode ser. é permitido e com o que não.
Portanto, agora podemos apenas falar sobre critérios de confiabilidade, que no SRE são tradicionalmente definidos como SLA (Service Level Agreement). Provavelmente um termo familiar. SLI (Indicador de Nível de Serviço). SLO (objetivo de nível de serviço). O Contrato de Nível de Serviço é possivelmente um termo de referência, especialmente se você trabalhou com redes, fornecedores e hospedagem. Este é um acordo geral que descreve o desempenho de todo o seu serviço, penalidade, algumas penalidades por erros, métricas e critérios. E SLI é a própria métrica de disponibilidade. Ou seja, o que pode ser SLI: tempo de resposta do serviço, o número de erros em termos percentuais. Isso pode ser largura de banda se se trata de algum tipo de hospedagem de arquivo. Se estamos falando de algoritmos de reconhecimento, um indicador pode ser, por exemplo, até a exatidão da resposta. SLO (Service Level Objective) é uma combinação do indicador SLI, seu valor e período, respectivamente.
Digamos que o SLA possa ser assim. O serviço está disponível 99,95% do tempo ao longo do ano. Ou 99 tíquetes de suporte crítico serão fechados dentro de 3 horas por trimestre. Ou 85% dos pedidos serão respondidos dentro de 1,5 segundos todos os meses. Ou seja, gradualmente chegamos a entender que erros e falhas são completamente normais. Esta é uma situação aceitável, estamos planejando, estamos contando com isso até certo ponto. Ou seja, o SRE cria sistemas que podem cometer erros, que devem responder normalmente aos erros que devem levar em consideração. E, se possível, eles devem lidar com os erros de forma que o usuário não os note ou os observe, mas existe uma solução alternativa para a qual tudo não cairá completamente.
Por exemplo, se você enviar um vídeo para o YouTube, e o YouTube não puder convertê-lo imediatamente, se o vídeo for muito grande, se o formato não for ideal, a solicitação naturalmente não ficará esgotada, o YouTube não apresentará um erro 502, o YouTube dirá: "Criamos tudo, Seu vídeo está sendo processado. Estará pronto em cerca de 10 minutos. ” Esse é o princípio da degradação graciosa, que é familiar, por exemplo, no desenvolvimento do frontend, se você já fez isso.
Os termos a seguir sobre os quais falaremos são muito importantes para trabalhar com confiabilidade, com erros e expectativas: MTBF e MTTR. MTBF é o tempo médio entre falhas. MTTR Mean Time To Recovery, tempo médio para recuperação. Ou seja, quanto tempo se passou desde o momento em que o erro foi detectado, desde o momento em que o erro apareceu até o momento em que o serviço foi totalmente restaurado ao normal. O MTBF é corrigido principalmente trabalhando na qualidade do código. Ou seja, na medida em que a SRE pode dizer não. E você precisa entender toda a equipe que, quando o SRE diz "não", ele diz isso não porque é prejudicial, não porque é ruim, mas porque, caso contrário, todos sofrerão.
Novamente, existem muitos artigos, muitos métodos, muitas maneiras, mesmo no livro a que me refiro com tanta frequência, como impedir que outros desenvolvedores comecem a odiar o SRE. O MTTR, por outro lado, está trabalhando no seu SLO (objetivo de nível de serviço). E isso é principalmente automação. Porque, por exemplo, nosso SLO é um tempo de atividade de 4 noves por trimestre. Isso significa que em três meses podemos permitir 13 minutos de inatividade. E acontece que não podemos ter MTTR por mais de 13 minutos. Se reagirmos por pelo menos 1 tempo de inatividade por 13 minutos, isso significa que já esgotamos todo o orçamento do trimestre. Estamos quebrando o SLO. 13 minutos para uma reação e corrigir uma falha é muito para o carro, mas muito pouco para uma pessoa. Porque enquanto um alerta chega a uma pessoa, enquanto ela reage, até que ele entenda o erro, isso já dura alguns minutos. Até que uma pessoa entenda como consertar, o que exatamente consertar, o que fazer, isso levará mais alguns minutos. E, de fato, mesmo que você precise apenas reiniciar o servidor ou criar um novo nó, o MTTR manual já dura cerca de 7-8 minutos. Ao automatizar um processo, o MTTR frequentemente atinge um segundo, às vezes um milissegundo. O Google geralmente fala em milissegundos, mas, na realidade, é claro, as coisas não são tão boas.
Idealmente, o SRE deve automatizar seu trabalho quase completamente, porque afeta diretamente o MTTR, suas métricas, o SLO de todo o serviço e, portanto, o lucro dos negócios. Se o tempo for excedido, pergunte-nos se a culpa é do SRE. Para o bem, ninguém é o culpado. E essa é uma cultura separada chamada postmortem sem balança, sobre a qual não falaremos hoje, mas analisaremos sobre Slurme. Este é um tópico muito interessante que pode ser discutido muito. Grosso modo, se o tempo alocado para um quarto for excedido, todos serão culpados por um pouco, o que significa que culpar a todos não é produtivo, deixe-nos, talvez não culpe ninguém, mas corrija a situação e trabalhe com o que temos. Na minha experiência, essa abordagem para a maioria das equipes, especialmente na Rússia, é um pouco estranha, mas faz sentido e funciona muito bem. Portanto, recomendarei no final do artigo e a literatura que pode ser lida sobre este tópico. Ou venha para Slurm SRE.
Eu vou explicar Se o tempo de SLO por trimestre for excedido, se o tempo de inatividade não for 13 minutos, mas 15, quem pode ser o culpado por isso? É claro que o SRE pode ser o culpado, porque ele obviamente fez algum tipo de consolidação ou implantação incorreta. O administrador do centro de dados pode ser o culpado por isso, porque, talvez, alguma manutenção não programada tenha sido realizada. Se o administrador do datacenter é o responsável, o responsável pela operação não calculou a manutenção ao coordenar o SLO. O gerente, diretor técnico ou alguém que assinou o contrato do datacenter e não prestou atenção ao fato de que o datacenter do SLA não foi projetado para o tempo de inatividade necessário é o culpado. Por conseguinte, pouco a pouco todos são os responsáveis por esta situação. E isso significa que não faz sentido culpar alguém nesta situação. Mas é claro que você precisa corrigi-lo. Portanto, existem post-mortem. E se você ler, por exemplo, o post-mortem do Github, que é sempre uma história muito interessante, pequena e inesperada em cada caso específico, você pode substituir que ninguém nunca diz que essa pessoa em particular é culpada. A culpa é sempre atribuída a processos imperfeitos específicos.
Vamos para a próxima pergunta. Automação Normalmente, quando falo de automação em outros contextos, muitas vezes me refiro a uma tabela que informa quanto tempo você pode trabalhar na automação de uma tarefa para não demorar mais tempo para automatizá-la do que geralmente salva. Há um problema. O problema é que, quando o SRE automatiza alguma tarefa, eles economizam não apenas tempo, mas também dinheiro, porque a automação afeta diretamente o MTTR. Eles economizam, por assim dizer, o moral dos funcionários e desenvolvedores, que também é um recurso esgotável. Eles reduzem a rotina. E tudo isso afeta positivamente o trabalho e, como conseqüência, o negócio, mesmo que pareça que a automação não faça sentido em termos de custos de tempo.
De fato, quase sempre aconteceu, e há muito poucos casos em que não vale a pena automatizar algo no papel de SRE. Além disso, falaremos sobre o que é chamado de orçamento de erros, o orçamento para erros. De fato, acontece que se tudo é muito melhor para você do que o SLO que você definiu para si mesmo, isso também não é muito bom. Isso é ruim, porque o SLO funciona não apenas como um limite inferior, mas também como um limite superior aproximado. Quando você define o SLO com 99% de acessibilidade e, na verdade, possui 99,99%, verifica-se que você tem algum espaço para experimentação que não prejudicará os negócios, porque você mesmo determinou isso juntos e você é o espaço não use. Você tem um orçamento para erros que não são gastos no seu caso.
O que estamos fazendo com ele. Nós o usamos literalmente para tudo. Para testes em condições de produção, para a implantação de novos recursos que podem afetar o desempenho, liberações, manutenção e paradas programadas. A regra oposta também se aplica: se o orçamento estiver esgotado, não podemos descarregar nada novo, pois, caso contrário, o SLO será excedido. O orçamento já está esgotado, não lançamos algo, se isso afetará negativamente a produtividade, ou seja, se não houver algum tipo de correção que aumente diretamente o SLO, então vamos além do orçamento, e essa é uma situação ruim, ela precisa ser analisada , post-mortem e possivelmente algum tipo de correção do processo.
Ou seja, acontece que, se o serviço em si funciona mal e o SLO é gasto e o orçamento não é gasto em experimentos, não em alguns lançamentos, mas por si só, em vez de correções interessantes para desenvolvedores, em vez de recursos interessantes, em vez de interessantes. lançamentos. Em vez de qualquer tipo de trabalho criativo, você precisará fazer correções estúpidas para retornar o orçamento ao pedido ou editar o SLO, e esse também é um processo que não deve ocorrer com muita frequência.
Portanto, acontece que em uma situação em que temos mais orçamento para erros, todos estão interessados: o SRE e os desenvolvedores. Para os desenvolvedores, um grande orçamento para erros significa que você pode lidar com versões, testes e experimentos. Para o SRE, o orçamento para erros e a entrada nesse orçamento significa que eles realmente fazem seu trabalho diretamente bem. E isso afeta a motivação para algum tipo de colaboração. Se você ouvir seus SREs como desenvolvedores, terá mais espaço para um bom trabalho e muito menos rotina.
Acontece que a experimentação na produção é uma parte bastante importante e quase integral do SRE em grandes equipes. E é geralmente chamado de engenharia do caos, que veio da equipe da Netflix que lançou um utilitário chamado Chaos Monkey.
O Chaos Monkey se conecta ao pipeline do CI / CD e descarta o servidor aleatoriamente em produção. Novamente, na estrutura do SRE, estamos falando sobre o fato de que um servidor com falha não é ruim por si só, é esperado. E se estiver incluído no orçamento, é aceitável e não prejudica os negócios. , , , , , .
- , , Chaos Gorilla, . , -, , , , . , , , . , , , - , , , , , . . , , , , , CI/CD . , , , , , , , . , , , . , .
: ? . , . , SRE . , , . , , SRE , , , , , , , . SRE , - . , SRE, - .
, , . , SRE , , . , , . , , , , , , .
, . SRE , . , , SLA, SLI, SLO. , SLA SLO, . - , , , - , , . 4 , IT , . , - .
. , - , , Objectives, , 3 .
, , . SLA, SLI, SLO, , , Objectives, SLA. , : - , , . . , -. , , , , , -, , : - . -, , . , SRE , , .
3 . , , . – , . , , , . – , . , - , - , , . – , , , . , - - , . - . , , .
, , , , , . , . . . . . , .
, Observability. . , . , Observability . - , , , . : , . , , , . , - Kubernetes, , . Observability MTTR. Observability , , , , MTTR.
, , , , SRE. . , , , SRE . , - . , , -, SRE . , , , - . , . SRE . . .
, , , . - , - . SRE, -, , . , , , .
. , , , , , , . . , . canary, , , , - , , , . , , , , .
SRE. , - , SRE, . - , - , , , canary A/B . SRE , . SRE . , , . SRE , , , , 50 50 , , SRE . . , .
. - . , SRE . , , . , , , , , , . SRE.
SRE — , , , , , , . . . Booking.com . , . - . .
, . SRE. , 2 SRE, . SLA, SLI, SLO , . 3 SRE . – Keys to SRE , . — SRE . SRE . SRE , 5 SRE 190 . , DevOps , SRE , .
2 chaos ingeneering: (1) , (2) . 3 Awesome Lists chaos ingeneering , SRE SRE . SRE , , 200 . capacity planning blameless postmortem.
: SRE as a life choice
, . , - . , , . . .
.
PS: para quem gosta de ler, Edward deu uma lista de referências. Aqueles que preferem entender na prática são bem-vindos no Slörme SRE .