O webinar tem áudio de baixa qualidade, por isso o transcrevemos.
Meu nome é Medvedev Eduard. Hoje vou falar sobre o que é o SRE, como surgiu o SRE, quais são os critérios de trabalho dos engenheiros do SRE, um pouco sobre critérios de confiabilidade, um pouco sobre seu monitoramento. Caminharemos pelos topos, porque em uma hora não dá para contar muito, mas darei materiais para revisão adicional, e estamos todos esperando por você no . em Moscou no final de janeiro.
Primeiramente, 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 de desenvolvimento tradicionais, Dev e Ops são duas equipes completamente diferentes, geralmente com dois objetivos completamente diferentes. O objetivo da equipe de desenvolvimento é implementar novos recursos e atender às necessidades do negócio. O objetivo da equipe de operações é garantir que tudo funcione e que nada quebre. Obviamente, esses objetivos se contradizem diretamente: para que tudo funcione e nada quebre, implemente novos recursos o mínimo possível. Por conta disso, existem muitos conflitos internos que a metodologia que hoje se chama DevOps está tentando resolver.
O problema é que não temos uma definição clara de DevOps e uma implementação clara de DevOps. Falei em uma conferência em Yekaterinburg há 2 anos e até agora a seção DevOps começou com o relatório “O que é DevOps”. Em 2017, o Devops completou quase 10 anos, mas ainda estamos discutindo o que é. E esta é uma situação muito estranha que o Google tentou resolver há alguns anos.
Em 2016, o Google lançou um livro chamado Site Reliability Engineering. E de fato, foi com esse livro que começou o movimento SRE. SRE é uma implementação específica do paradigma DevOps em uma empresa específica. Os engenheiros da SRE estão empenhados em garantir que os sistemas operem de forma confiável. Eles vêm principalmente de desenvolvedores, às vezes administradores com forte experiência em desenvolvimento. E eles fazem o que os administradores de sistema faziam, mas uma sólida experiência em 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 rotineiro, mas sim à automação.
Acontece que o paradigma DevOps nas equipes de SRE é implementado pelo fato de existirem engenheiros de SRE que resolvem problemas estruturais. Aqui está, a mesma conexão entre Dev e Ops da qual as pessoas falam há 8 anos. O papel de um SRE é semelhante ao de um arquiteto, pois os recém-chegados não se tornam SREs. Pessoas em início de carreira ainda não têm experiência, não possuem a amplitude de conhecimento necessária. Porque o SRE requer um conhecimento muito sutil de exatamente o que e quando pode dar errado. Portanto, aqui é necessária alguma experiência, via de regra, tanto dentro como fora da empresa.
Eles perguntam se a diferença entre SRE e Devops será descrita. Ela acaba de ser descrita. Podemos falar sobre o lugar do SRE na organização. Ao contrário desta abordagem clássica de DevOps, onde 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 SRE é uma função que passa de um desenvolvedor para outro. Eles participam de revisões de código da mesma forma que, por exemplo, designers de UX, os próprios desenvolvedores e, às vezes, gerentes de produto. SREs funcionam no mesmo nível. Precisamos aprová-los, precisamos revisá-los, para que para cada implantação o SRE diga: “Ok, esta implantação, este produto não afetará negativamente a confiabilidade. E se isso acontecer, então dentro de alguns limites aceitáveis. Também falaremos sobre isso.
Dessa forma, o SRE tem direito de veto à alteração do 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 de Sites, muitas partes, nem mesmo uma, explicam como evitar esses conflitos.
Eles perguntam como o SRE se relaciona com a segurança da informação. A SRE não está diretamente envolvida na segurança da informação. Basicamente, nas grandes empresas, isso é feito por indivíduos, testadores, analistas. Mas o SRE também interage com eles no sentido de que algumas operações, alguns commits, algumas implantações que afetam a segurança também podem afetar a disponibilidade do produto. Portanto, o SRE como um todo interage com quaisquer equipes, inclusive equipes de segurança, inclusive analistas. Portanto, os SREs são necessários principalmente quando tentam implementar DevOps, mas, ao mesmo tempo, a carga sobre os desenvolvedores torna-se muito grande. Ou seja, a própria equipe de desenvolvimento não consegue mais lidar com o fato de que agora também precisa ser responsável pelas Operações. E há um papel separado. Esta função está prevista no orçamento. Às vezes esse papel está definido no tamanho da equipe, aparece uma pessoa separada, às vezes um dos desenvolvedores passa a ser. É assim que surge o primeiro SRE da equipe.
A complexidade do sistema que é afetado pelo SRE, a complexidade que afeta a confiabilidade da operação, é necessária e acidental. A complexidade necessária ocorre quando a complexidade de um produto aumenta na medida exigida pelos novos recursos do produto. Complexidade aleatória ocorre quando a complexidade do sistema aumenta, mas os recursos do produto e os requisitos de negócios não afetam isso diretamente. Acontece que ou o desenvolvedor cometeu um erro em algum lugar, ou o algoritmo não é o ideal, ou foram introduzidos alguns interesses adicionais que aumentam a complexidade do produto sem necessidade especial. Um bom SRE deve sempre eliminar esta situação. Ou seja, qualquer commit, qualquer implantação, qualquer pull request, onde a dificuldade seja aumentada devido a adição aleatória, deverá ser bloqueado.
A questão é por que não contratar apenas 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 em termos de pessoal. Um desenvolvedor na função de engenheiro nem sempre é a melhor solução de recrutamento, mas a questão aqui é que um desenvolvedor que está envolvido em operações tem um pouco mais de desejo por automação, tem um pouco mais de conhecimento e um conjunto de habilidades para implementar essa automação. E consequentemente, reduzimos não só o tempo de algumas operações específicas, não só a rotina, mas também parâmetros de negócio tão importantes como o MTTR (Mean Time To Recovery, tempo de recuperação). Assim, e falaremos disso um pouco mais tarde, economizamos dinheiro para a organização.
Agora vamos falar sobre os critérios para funcionamento do SRE. E antes de tudo sobre confiabilidade. Em pequenas empresas, startups, muitas vezes acontece que as pessoas presumem que se o serviço for bem escrito, se o produto for bem escrito e corretamente, ele funcionará, não quebrará. É isso, 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 quase as mesmas pessoas que dizem que não precisamos de testes, porque, olha, esses são os três métodos VPI, por que quebrar aqui.
Tudo isso está errado, é claro. E essas pessoas são muitas vezes afetadas por esse código na prática, porque as coisas quebram. Às vezes, as coisas quebram das maneiras mais imprevisíveis. Às vezes as pessoas dizem que não, isso nunca vai acontecer. E isso acontece o tempo todo. Isso acontece com bastante frequência. E é por isso que ninguém busca 100% de disponibilidade, porque 100% de disponibilidade nunca acontece. Esta é a norma. E por isso, quando falamos da disponibilidade de um serviço, falamos sempre em noves. 2 noves, 3 noves, 4 noves, 5 noves. Se traduzirmos isso em tempo de inatividade, então, por exemplo, 5 noves, então isso é um pouco mais de 5 minutos de tempo de inatividade por ano, 2 noves equivalem a 3,5 dias de tempo de inatividade.
Mas é óbvio que em algum momento há uma diminuição do POI, do retorno do investimento. Passar de dois noves para três noves significa menos tempo de inatividade em mais de 3 dias. Passar de quatro noves para cinco reduz o tempo de inatividade em 47 minutos por ano. E acontece que para os negócios isso pode não ser crítico. E em geral a confiabilidade exigida não é uma questão técnica, antes de tudo é uma questão de negócio, é 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 aqui é qual é a confiabilidade dos demais componentes. Porque a diferença entre 4 e 5 noves não será visível num smartphone com 2 noves de fiabilidade. Grosso modo, se algo quebrar em um smartphone do seu serviço 10 vezes por ano, provavelmente 8 vezes a falha ocorreu no lado do sistema operacional. O usuário está acostumado com isso e não vai prestar atenção mais uma vez por ano. É necessário correlacionar o preço do aumento da confiabilidade e do aumento dos lucros.
Apenas no livro sobre SRE há um bom exemplo de aumento de 4 noves para 3 noves. Acontece que o aumento da disponibilidade é de pouco menos de 0,1%. E se a receita do serviço for de US$ 1 milhão por ano, então o aumento na receita será de US$ 900. Se nos custa menos de 900 dólares por ano aumentar a acessibilidade em nove, o aumento faz sentido financeiramente. Se custar mais de 900 dólares por ano, já não faz sentido, porque o aumento da receita simplesmente não compensa os custos laborais, os custos dos recursos. E 3 noves serão suficientes para nós.
É claro que este é um exemplo simplificado em que todas as solicitações são iguais. E passar de 3 noves para 4 noves é bastante fácil, mas ao mesmo tempo, por exemplo, passar de 2 noves para 3, isso já é uma economia de 9 mil dólares, pode fazer sentido financeiro. Naturalmente, na realidade, a falha no pedido de registo é pior do que a falha na visualização da página, os pedidos têm pesos diferentes. Podem ter um critério completamente diferente do ponto de vista empresarial, mas de qualquer forma, via de regra, se não estivermos falando de alguns serviços específicos, esta é uma aproximação bastante confiável.
Recebemos a dúvida se o SRE é um dos coordenadores na hora de escolher uma solução arquitetônica para o serviço. Digamos em termos de integração na infra-estrutura existente, para que não haja perda na sua estabilidade. Sim, SREs, da mesma forma que pull requests, commits, releases afetam a arquitetura, a introdução de novos serviços, microsserviços, a implementação de novas soluções. Por que eu disse antes que é necessária experiência, são necessárias qualificações. Na verdade, o SRE é uma das vozes bloqueadoras em qualquer solução de arquitetura e software. Conseqüentemente, um SRE como engenheiro deve, antes de tudo, não apenas compreender, mas também compreender como algumas decisões específicas afetarão a confiabilidade, a estabilidade e compreender como isso se relaciona com as necessidades do negócio, e de que ponto de vista pode ser aceitável e o que não.
Portanto, agora podemos falar apenas de critérios de confiabilidade, que são tradicionalmente definidos no SRE 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). Acordo de Nível de Serviço talvez seja um termo simbólico, principalmente se você já trabalhou com redes, com provedores, com hospedagem. Este é um acordo geral que descreve o desempenho de todo o seu serviço, penalidades, algumas penalidades por erros, métricas, critérios. E o SLI é a própria métrica de disponibilidade. Ou seja, o que pode ser o SLI: tempo de resposta do serviço, número de erros em porcentagem. Pode ser largura de banda se for algum tipo de hospedagem de arquivos. Quando se trata de algoritmos de reconhecimento, o indicador pode ser, por exemplo, até mesmo a correção da resposta. O SLO (Objetivo de Nível de Serviço) é, respectivamente, uma combinação do indicador SLI, seu valor e período.
Digamos que o SLA poderia ser assim. O serviço está disponível 99,95% do tempo ao longo do ano. Ou 99 tickets de suporte críticos serão fechados dentro de 3 horas por trimestre. Ou 85% das consultas obterão respostas em 1,5 segundos todos os meses. Ou seja, aos poucos passamos a entender que erros e falhas são normais. Esta é uma situação aceitável, estamos a planeá-la, estamos até a contar com isso até certo ponto. Ou seja, o SRE constrói sistemas que podem cometer erros, que devem responder normalmente aos erros, que devem levá-los em consideração. E sempre que possível, devem tratar os erros de forma que o usuário não os perceba, ou perceba, mas haja algum tipo de solução alternativa, graças à qual nem tudo irá falhar 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 falhará com um tempo limite, 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." Este é o princípio da degradação graciosa, que é familiar, por exemplo, ao desenvolvimento front-end, se você já fez isso.
Os próximos termos que falaremos, que são muito importantes para trabalhar com confiabilidade, com erros, com expectativas, são MTBF e MTTR. MTBF é o tempo médio entre falhas. MTTR Mean Time To Recovery, tempo médio de recuperação. Ou seja, quanto tempo se passou desde o momento em que o erro foi descoberto, desde o momento em que o erro apareceu até o momento em que o serviço foi restaurado ao funcionamento normal. O MTBF é corrigido principalmente pelo trabalho na qualidade do código. Ou seja, o fato de os SREs poderem dizer “não”. E é preciso que toda a equipe entenda que quando o SRE diz “não”, ele diz não porque faz mal, não porque é mau, mas porque senão todos vão sofrer.
Novamente, há muitos artigos, muitos métodos, muitas maneiras, mesmo no próprio livro ao qual me refiro com tanta frequência, sobre como garantir que outros desenvolvedores não comecem a odiar o SRE. O MTTR, por outro lado, trata de trabalhar em seus SLOs (Objetivo de Nível de Serviço). E é principalmente automação. Porque, por exemplo, nosso SLO tem um tempo de atividade de 4 noves por trimestre. Isso significa que em 3 meses podemos permitir 13 minutos de inatividade. E acontece que o MTTR não pode ser superior a 13 minutos. Se respondermos a pelo menos 13 parada em 1 minutos, isso significa que já esgotamos todo o orçamento do trimestre. Estamos quebrando o SLO. 13 minutos para reagir e consertar uma falha é muito para uma máquina, mas muito pouco para um ser humano. Porque até a pessoa receber um alerta, até ela reagir, até entender o erro, já são vários 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ê só precise reiniciar o servidor, como se vê, ou criar um novo nó, o MTTR manual já leva cerca de 7 a 8 minutos. Ao automatizar o processo, o MTTR muitas vezes atinge um segundo, às vezes milissegundos. O Google costuma falar em milissegundos, mas na realidade, claro, nem tudo é tão bom.
O ideal é que o SRE automatize quase totalmente seu trabalho, pois isso afeta diretamente o MTTR, suas métricas, o SLO de todo o serviço e, consequentemente, o lucro do negócio. Se o tempo for excedido, somos questionados se o SRE é o culpado. Felizmente, ninguém é culpado. E esta é uma cultura separada chamada post-mortem sem graça, da qual não falaremos hoje, mas analisaremos no Slurm. Este é um tema muito interessante sobre o qual podemos falar muito. Grosso modo, se o tempo previsto por trimestre for ultrapassado, a culpa é de um pouco de todo mundo, o que significa que culpar todo mundo não é produtivo, vamos, em vez disso, talvez não culpar ninguém, mas corrigir a situação e trabalhar com o que temos. Na minha experiência, esta abordagem é um pouco estranha à maioria das equipas, especialmente na Rússia, mas faz sentido e funciona muito bem. Portanto, no final do artigo recomendarei a literatura que você pode ler sobre esse assunto. Ou venha para Slurm SRE.
Deixe-me explicar. Se o tempo de SLO por trimestre for ultrapassado, se o tempo de inatividade não for de 13 minutos, mas de 15, quem pode ser o culpado? É claro que a culpa pode ser do SRE, porque ele claramente cometeu algum tipo de commit ou implantação incorreto. O administrador do data center pode ser o culpado por isso, pois pode ter realizado algum tipo de manutenção não programada. Se a culpa é do administrador do data center, a culpa é do pessoal de Ops, que não calculou a manutenção quando coordenou o SLO. O gerente, diretor técnico ou alguém que assinou o contrato do data center e não prestou atenção ao fato de o SLA do data center não estar projetado para o tempo de inatividade exigido é o culpado por isso. Conseqüentemente, todos, aos poucos, nesta situação são os culpados. E significa que não faz sentido colocar a culpa em alguém nesta situação. Mas é claro que precisa ser corrigido. É por isso que existem postmortems. E se você ler, por exemplo, postmortems do GitHub, e esta é sempre uma história muito interessante, pequena e inesperada em cada caso, você pode substituir que ninguém nunca diz que essa pessoa em particular é a culpada. A culpa é sempre colocada em processos imperfeitos específicos.
Vamos para a próxima pergunta. Automação. Quando falo sobre 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 sem gastar mais tempo para automatizá-la do que realmente economiza. Há um obstáculo. O problema é que quando os SREs automatizam uma tarefa, eles não apenas economizam tempo, mas também dinheiro, porque a automação afeta diretamente o MTTR. Eles salvam, por assim dizer, o moral dos funcionários e desenvolvedores, o que também é um recurso esgotável. Eles reduzem a rotina. E tudo isto tem um efeito positivo no trabalho e, consequentemente, nos negócios, mesmo que pareça que a automatização não faz sentido em termos de custos de tempo.
Na verdade, quase sempre acontece, e há muito poucos casos em que algo não deveria ser automatizado na função de SRE. A seguir falaremos sobre o que é chamado de orçamento de erros, o orçamento para erros. Na verdade, acontece que se tudo for muito melhor para você do que o SLO que você definiu para si mesmo, isso também não é muito bom. Isso é bastante ruim, porque o SLO funciona não apenas como um limite inferior, mas também como um limite superior aproximado. Quando você define um SLO de 99% de disponibilidade, e na verdade você tem 99,99%, acontece que você tem algum espaço para experimentos que não prejudicarão em nada o negócio, porque você mesmo determinou tudo isso juntos, e você está este espaço não uso. Você tem um orçamento para erros, que no seu caso não se esgota.
O que fazemos com isso. Nós o usamos para literalmente tudo. Para testes em condições de produção, para implementação de novos recursos que podem afetar o desempenho, para lançamentos, para manutenção, para paradas planejadas. A regra inversa também se aplica: se o orçamento estiver esgotado, não podemos lançar nada de novo, porque senão ultrapassaremos o SLO. O orçamento já se esgotou, liberamos algo se afetar negativamente o desempenho, ou seja, se isso não for algum tipo de correção que por si só aumente diretamente o SLO, então estamos indo além do orçamento, e isso é uma situação ruim , ele precisa ser analisado post-mortem e, possivelmente, algumas correções no processo.
Ou seja, acontece que se o serviço em si não funcionar bem, e o SLO for gasto e o orçamento for gasto não em experimentos, não em alguns lançamentos, mas por si só, então em vez de algumas correções interessantes, em vez de recursos interessantes, em vez de lançamentos interessantes. Em vez de qualquer trabalho criativo, você terá que lidar com correções estúpidas para colocar o orçamento em ordem ou editar o SLO, e esse também é um processo que não deve acontecer com muita frequência.
Portanto, verifica-se que numa situação em que temos mais orçamento para erros, todos estão interessados: tanto SRE quanto desenvolvedores. Para os desenvolvedores, um grande orçamento para bugs significa que você pode lidar com lançamentos, testes, experimentos. Para os SREs, um orçamento para erros e a inserção desse orçamento significa que eles estão fazendo bem o seu trabalho. E isso afeta a motivação de algum tipo de trabalho conjunto. Se você ouvir seus SREs como desenvolvedores, terá mais espaço para um bom trabalho e muito menos rotina.
Acontece que os experimentos em produção são uma parte muito importante e quase integral do SRE em grandes equipes. E geralmente é chamada de engenharia do caos, que vem da equipe da Netflix que lançou um utilitário chamado Chaos Monkey.
Chaos Monkey se conecta ao pipeline de CI/CD e trava aleatoriamente o servidor em produção. Novamente, na estrutura do SRE, estamos falando do fato de que um servidor caído não é ruim por si só, é esperado. E se estiver dentro do orçamento, é aceitável e não prejudica o negócio. Claro que a Netflix tem servidores redundantes suficientes, replicação suficiente, para que tudo isso possa ser consertado, e para que o usuário como um todo nem perceba, e mais ainda, ninguém sai de um servidor por qualquer orçamento.
A Netflix teve um conjunto completo desses utilitários por um tempo, um dos quais, Chaos Gorilla, desliga completamente uma das zonas de disponibilidade da Amazon. E essas coisas ajudam a revelar, em primeiro lugar, dependências ocultas, quando não está totalmente claro o que afeta o quê, o que depende de quê. E isso, se você estiver trabalhando com um microsserviço e a documentação não for totalmente perfeita, isso pode ser familiar para você. E novamente, isso ajuda muito a pegar erros no código que você não consegue pegar no staging, porque qualquer staging não é exatamente uma simulação exata, devido ao fato da escala de carga ser diferente, o padrão de carga ser diferente, o equipamento ser também, provavelmente, outro. Os picos de carga também podem ser inesperados e imprevisíveis. E esses testes, que novamente não ultrapassam o orçamento, ajudam muito bem a detectar erros na infraestrutura que o teste, os autotestes e o pipeline de CI/CD nunca detectarão. E desde que esteja tudo incluído no seu orçamento, não importa que o seu serviço tenha caído aí, embora possa parecer muito assustador, o servidor caiu, que pesadelo. Não, isso é normal, isso é bom, ajuda a detectar bugs. Se você tiver um orçamento, poderá gastá-lo.
P: Que literatura posso recomendar? Lista no final. Há muita literatura, vou aconselhar alguns relatórios. Como funciona e o SRE funciona em empresas sem produto de software próprio ou com desenvolvimento mínimo. Por exemplo, numa empresa onde a atividade principal não é software. Em uma empresa, onde a atividade principal não é software, o SRE funciona exatamente da mesma forma que em qualquer outro lugar, porque em uma empresa você também precisa usar produtos de software, mesmo que não desenvolvidos, precisa lançar atualizações, precisa mudar a infraestrutura, você precisa crescer, você precisa escalar. E os SREs ajudam a identificar e prever possíveis problemas nesses processos e a controlá-los após o início de algum crescimento e as necessidades de negócios mudarem. Porque não é absolutamente necessário estar envolvido no desenvolvimento de software para ter um SRE se você tiver pelo menos alguns servidores e espera-se que tenha pelo menos algum crescimento.
O mesmo vale para pequenos projetos, pequenas organizações, porque as grandes empresas têm orçamento e espaço para experimentar. Mas, ao mesmo tempo, todos esses frutos de experimentos podem ser usados em qualquer lugar, ou seja, o SRE, claro, apareceu no Google, no Netflix, no Dropbox. Mas, ao mesmo tempo, pequenas empresas e startups já podem ler material condensado, ler livros, assistir reportagens. Eles começam a ouvir falar com mais frequência, olham exemplos específicos, acho que está tudo bem, pode ser muito útil, precisamos disso também, é ótimo.
Ou seja, todo o trabalho principal de padronização desses processos já foi feito para você. Resta a você determinar o papel do SRE especificamente na sua empresa e começar a implementar de fato todas essas práticas, que, novamente, já foram descritas. Ou seja, de princípios úteis para pequenas empresas, esta é sempre a definição de SLA, SLI, SLO. Se você não estiver envolvido com software, estes serão SLAs e SLOs internos, um orçamento interno para erros. Isso quase sempre gera algumas discussões interessantes dentro da equipe e dentro do negócio, porque pode acontecer que você gaste em infraestrutura, em algum tipo de organização de processos ideais, o pipeline ideal é muito mais do que o necessário. E esses 4 noves que você tem no departamento de TI, você realmente não precisa deles agora. Mas, ao mesmo tempo, você poderia gastar tempo, gastar o orçamento com erros em outra coisa.
Dessa forma, o monitoramento e a organização do monitoramento são úteis para uma empresa de qualquer porte. E em geral, esta forma de pensar, onde os erros são algo aceitável, onde há orçamento, onde há Objetivos, é novamente útil para uma empresa de qualquer tamanho, a partir de startups para 3 pessoas.
A última das nuances técnicas a falar é o monitoramento. Porque se estamos falando de SLA, SLI, SLO, não conseguimos entender sem monitorar se cabemos no orçamento, se cumprimos nossos Objetivos e como influenciamos no SLA final. Já vi tantas vezes que o monitoramento acontece assim: existe algum valor, por exemplo, o tempo de uma solicitação ao servidor, o tempo médio ou a quantidade de solicitações ao banco de dados. Ele tem um padrão determinado por um engenheiro. Se a métrica se desviar da norma, chegará um e-mail. Isso tudo é absolutamente inútil, via de regra, porque leva a um tal excesso de alertas, um excesso de mensagens de monitoramento, quando uma pessoa, em primeiro lugar, deve interpretá-los todas as vezes, ou seja, determinar se o valor da métrica significa a necessidade de alguma ação. E em segundo lugar, ele simplesmente deixa de perceber todos esses alertas, quando basicamente nenhuma ação é exigida dele. Essa é uma boa regra de monitoramento e a primeira regra quando o SRE é implementado é que a notificação só deve ser feita quando for necessária uma ação.
No caso padrão, existem 3 níveis de eventos. Existem alertas, existem tickets, existem logs. Alertas são qualquer coisa que exija que você tome medidas imediatas. Ou seja, está tudo quebrado, você precisa consertar agora mesmo. Os ingressos são o que exigem ação atrasada. Sim, você precisa fazer algo, precisa fazer algo manualmente, a automação falhou, mas você não precisa fazer isso nos próximos minutos. Logs são qualquer coisa que não exija ação e, em geral, se tudo correr bem, ninguém jamais os lerá. Você só precisará ler os logs quando, em retrospecto, descobrir que algo quebrou há algum tempo, não sabíamos disso. Ou você precisa fazer alguma pesquisa. Mas em geral tudo que não requer nenhuma ação vai para os logs.
Como efeito colateral de tudo isso, se tivermos definido quais eventos exigem ações e tivermos descrito bem quais deveriam ser essas ações, isso significa que a ação pode ser automatizada. Isto é, o que acontece. Saímos de alerta. Vamos para a ação. Vamos para a descrição desta ação. E então passamos para a automação. Ou seja, qualquer automação começa com uma reação a um evento.
Do monitoramento, passamos para um termo chamado Observabilidade. Também tem havido um pouco de entusiasmo em torno dessa palavra nos últimos anos. E poucas pessoas entendem o que isso significa fora do contexto. Mas o ponto principal é que a Observabilidade é uma métrica para a transparência do sistema. Se algo deu errado, com que rapidez você pode determinar o que exatamente deu errado e qual era o estado do sistema naquele momento. Em termos de código: qual função falhou, qual serviço falhou. Qual era o estado de, por exemplo, variáveis internas, configuração. Em termos de infraestrutura, é em qual zona de disponibilidade ocorreu a falha e, se você tiver algum Kubernetes, em qual pod ocorreu a falha, qual era o estado do pod. E, consequentemente, a Observabilidade tem uma relação direta com o MTTR. Quanto maior a Observabilidade do serviço, mais fácil é identificar o erro, mais fácil é corrigir o erro, mais fácil é automatizar o erro, menor é o MTTR.
Passando novamente para as pequenas empresas, é muito comum perguntar, ainda hoje, como lidar com o tamanho da equipe e se uma equipe pequena precisa contratar um SRE separado. Já falei sobre isso um pouco antes. Nos primeiros estágios de desenvolvimento de uma startup ou, por exemplo, de uma equipe, isso não é de todo necessário, pois o SRE pode assumir uma função de transição. E isso vai animar um pouco a equipe, porque há pelo menos alguma diversidade. Além disso, preparará as pessoas para o fato de que, com o crescimento, em geral, as responsabilidades do SRE mudarão significativamente. Se você contratar uma pessoa, é claro que ela terá algumas expectativas. E essas expectativas não mudarão com o tempo, mas os requisitos mudarão muito. Portanto, como contratar um SRE é bastante difícil nos estágios iniciais. Cultivar o seu próprio é muito mais fácil. Mas vale a pena pensar.
A única exceção, talvez, é quando existem requisitos de crescimento muito rígidos e bem definidos. Ou seja, no caso de uma startup, pode ser algum tipo de pressão dos investidores, algum tipo de previsão de crescimento várias vezes ao mesmo tempo. Então a contratação de um SRE é basicamente justificada porque pode ser justificada. Temos exigências de crescimento, precisamos de uma pessoa que seja responsável pelo fato de que com esse crescimento nada vai quebrar.
Mais uma pergunta. O que fazer quando várias vezes os desenvolvedores cortam uma feature que passa nos testes, mas quebra a produção, carrega a base, quebra outras funcionalidades, qual processo implementar. Assim, neste caso, é o orçamento para erros que é introduzido. E alguns dos serviços, alguns dos recursos já estão sendo testados na produção. Pode ser canário, quando apenas um pequeno número de usuários, mas já em produção, um recurso é implantado, mas já com a expectativa de que se algo quebrar, por exemplo, para meio por cento de todos os usuários, ainda atenderá ao orçamento para erros. Assim, sim, haverá um erro, para alguns usuários tudo quebrará, mas já dissemos que isso é normal.
Houve uma pergunta sobre as ferramentas SRE. Ou seja, há algo em particular que os SREs usariam e que todos os outros não usariam. Na verdade, existem alguns utilitários altamente especializados, existe algum tipo de software que, por exemplo, simula cargas ou realiza testes canários A/B. Mas basicamente o kit de ferramentas SRE é o que seus desenvolvedores já estão usando. Porque o SRE interage diretamente com a equipe de desenvolvimento. E se você tiver ferramentas diferentes, levará tempo para sincronizar. Principalmente se os SREs trabalham em equipes grandes, em grandes empresas onde pode haver várias equipes, é a padronização de toda a empresa que vai ajudar muito aqui, porque se forem utilizadas 50 utilidades diferentes em 50 equipes, isso significa que o SRE deve conhecê-las todos. E é claro que isso nunca acontecerá. E a qualidade do trabalho, a qualidade do controle de pelo menos algumas das equipes diminuirá significativamente.
Nosso webinar está chegando ao fim. Consegui contar algumas coisas básicas. É claro que nada sobre SRE pode ser dito e compreendido em uma hora. Mas espero ter conseguido transmitir essa forma de pensar, os principais pontos-chave. E aí será possível, se tiver interesse, se aprofundar no tema, aprender por conta própria, ver como está sendo implementado por outras pessoas, em outras empresas. E, portanto, no início de fevereiro, venha até nós no Slurm SRE.
O Slurm SRE é um curso intensivo de três dias que vai falar sobre o que estou falando agora, mas com muito mais profundidade, com casos reais, com prática, todo o intensivo é voltado para trabalhos práticos. As pessoas serão divididas em equipes. Todos vocês trabalharão em casos reais. Assim, temos os instrutores da Booking.com Ivan Kruglov e Ben Tyler. Temos um maravilhoso Eugene Barrabás do Google, de São Francisco. E vou te contar uma coisa também. Então não deixe de nos visitar.
Então, a bibliografia. Existem referências no SRE. no mesmo livro, ou melhor, em 2 livros sobre SRE, escritos pelo Google. Outro , onde os termos e sua aplicação são um pouco mais detalhados. Os próximos 3 são relatórios sobre SRE em diferentes empresas. Primeiro - , esta é uma palestra de Ben Trainer do Google. Segundo - . O terceiro é novamente . Quarto relatório de , que tem apenas 5 funcionários-chave da SRE em 190 países. É muito interessante observar tudo isso, porque assim como o DevOps significa coisas muito diferentes para empresas e até equipes diferentes, o SRE tem responsabilidades muito diferentes, mesmo em empresas de tamanhos semelhantes.
Mais 2 links sobre os princípios da engenharia do caos: , . E no final tem 3 listas da série Awesome Lists about sobre e sobre . A lista no SRE é incrivelmente grande, não é preciso passar por tudo, são cerca de 200 artigos. Eu recomendo fortemente artigos de lá sobre planejamento de capacidade e sobre post-mortem sem culpa.
Artigo interessante:
Obrigado por me ouvir todo esse tempo. Espero que você tenha aprendido alguma coisa. Espero que você tenha material suficiente para aprender ainda mais. E ver você. Esperançosamente em fevereiro.
O webinar foi apresentado por Eduard Medvedev.
PS: para quem gosta de ler, Eduard deu uma lista de referências. Aqueles que preferem entender na prática podem .
Fonte: habr.com