Boa noite a todos!
A intensidade de nossos lançamentos varia de mês para mês. Antes de os alunos de setembro terminarem o segundo mês do curso
“Devops - Práticas e Ferramentas” , estamos abrindo o próximo fluxo. Estamos novamente prontos para compartilhar com você materiais úteis sobre o assunto e aguardamos
lições abertas não menos úteis.
Hoje, veremos a primeira parte do artigo sobre como a documentação permite que as equipes de SRE gerenciem serviços novos e existentes.
SRE (engenharia de confiabilidade do site, traduzida aproximadamente como "garantir a confiabilidade dos sistemas de informação", os especialistas neste campo têm a mesma abreviação) - uma disciplina especial, pensamento e um conjunto de abordagens técnicas destinadas a garantir o bom funcionamento dos produtos e serviços da Web. A SRE está na encruzilhada do desenvolvimento de software e engenharia de sistemas, resolve problemas operacionais e desenvolve soluções escaláveis, confiáveis e eficientes para o design, criação e operação de sistemas distribuídos em larga escala.
Os principais objetivos da SRE:
- Monitoramento e coleta de métricas - determinando o comportamento desejado do serviço, estudando o comportamento real do serviço e eliminando as diferenças.
- Resposta a incidentes - detecção e resposta eficaz a falhas de serviço para manter a disponibilidade do serviço consistente com seu SLA (contrato de nível de serviço).
- Planejamento de capacidade - prever a demanda futura e fornecer a quantidade necessária de recursos de computação nos locais apropriados para atender a essa demanda.
- Escalonamento de serviço - implantação e remoção previsíveis da capacidade de computação de um serviço em um datacenter, geralmente como resultado do planejamento de capacidade.
- Gerenciamento de mudanças - alterando o comportamento de um serviço sem perder sua confiabilidade.
- Desempenho - design, desenvolvimento e engenharia relacionados a dimensionamento, isolamento, latência, rendimento e eficiência.
O foco da SRE está no ciclo de vida do serviço: da ideia e do design à implantação, operação, melhoria de desempenho e, finalmente, desativação.
Antes de lançar o serviço SRE, eles o apoiam consultando no campo da arquitetura do sistema, desenvolvendo plataformas de software, estruturas e planos de capacidade e realizando uma revisão do lançamento.
Quando um serviço já está em execução, os SREs o suportam da seguinte maneira:
- Eles medem e monitoram a disponibilidade, latência e condição geral do sistema.
- Verifique as alterações planejadas do sistema.
- Eles escalam a estabilidade do sistema usando alguns mecanismos, por exemplo, automação.
- Melhore o sistema promovendo mudanças destinadas a aumentar a confiabilidade e a velocidade.
- Conduza a resposta a incidentes e post-mortem "inocente".
Quando a vida de um serviço estiver prestes a terminar, o SRE a desativará de maneira previsível, com explicações claras e documentação completa.
Uma equipe madura de SRE sempre tem documentação completa para cada função de SRE. Se você gerencia uma equipe do SRE ou planeja organizá-la, este artigo o ajudará a entender os tipos de documentação de que sua equipe precisa, o que ajudará a planejar e priorizar o trabalho na documentação em paralelo com outras tarefas da equipe.
História do SRE
Antes de discutir as nuances da documentação do SRE, vejamos um dia na vida de Zoe, o SRE recém-criado.
A segunda mudança de Zoe no papel de SRE está em andamento no projeto principal da AcmeSale na Acme Inc. Enquanto ela está apenas se adaptando à equipe, ela observa o trabalho de seus colegas e faz anotações. Mas agora ela ainda tem um pager.
Por sorte, o pager liga às 2:30 da manhã. A mensagem diz "Job Ragnarok recostou-se", Zoe não faz ideia do que isso significa. Ela folheia suas anotações e encontra um link para a página principal do painel. Tudo parece bem. Ela tenta encontrar algum documento referenciando Ragnarok na intranet da Acme e, após alguns minutos preciosos, encontra um documento desatualizado na arquitetura de serviço, que acaba sendo uma dependência crítica para o AcmeSale.
Felizmente, há um link para a página “Ragnarok Ops” na discoteca, que encontrou um link para um painel com gráficos úteis. A página também menciona o script ragtool, provavelmente capaz de ajudar a resolver o problema, mas Zoe ouve pela primeira vez. Portanto, ela envia uma solicitação de ajuda do pager para outro SRE com muitos anos de experiência neste serviço e ferramentas. Infelizmente, não há resposta. Zoe verifica o e-mail e vê uma mensagem de que seu colega está offline por uma hora devido a problemas de saúde. Depois de pesar todos os prós e contras, ela a chama de techlie, mas a ligação entra no correio de voz. Tudo sugere que você precisa resolver esse problema sozinho.
Depois de passar algum tempo procurando informações sobre o misterioso script ragtool, ela encontra um documento com uma breve descrição de seus parâmetros de linha de comando, bem como onde pode ser encontrado. Ela lança um ragtool - recomeça e cruza os dedos na esperança. Nada muda, o tráfego cai ainda mais. Ela olha desesperadamente para o restante das opções de linha de comando, mas não tem certeza de que elas não irão prejudicar ainda mais. Por fim, ela decide usar o ragtool –balance e - dc = atlanta, porque fica claro nos gráficos que o problema é especialmente perceptível no data center de Atlanta. O gráfico do tráfego começa a subir lentamente, e Zoe se alegra com a vitória. MTTR (tempo médio para reparo) é de 45 minutos.
No dia seguinte, Zoe conduz uma discussão post-mortem do incidente. Isso ocorre porque o problema acabou sendo especialmente grande e resultou em perda de receita, além de o gerente pedir mais post-mortem. Ela pergunta à equipe como o resto dos participantes resolveria esse problema e ela ouve três abordagens diferentes. Acontece que um único processo de solução de problemas simplesmente não existe. Seus colegas também admitem que a notificação "recuou" não é o melhor nome e a falha ocorreu devido a um bug conhecido que simplesmente não era uma prioridade.
Por fim, Steve, seu techlid, pergunta: “Qual versão do ragtool você adquiriu?”, E observa que a versão usada é terrivelmente antiga. Uma nova versão foi lançada há uma semana, juntamente com uma documentação completamente nova, descrevendo todos os recursos e até explicando como resolver o problema "Job Ragnarok recostou-se". Esta versão reduziria o MTTR para cinco minutos.
A existência de uma nova versão do ragtool é uma surpresa para metade da equipe, enquanto a outra metade está mais ou menos consciente da nova versão e guia. A versão mais recente do script está no diretório inicial de Steve, obviamente na pasta bin /. Zoe acrescenta isso a suas anotações para uso futuro, esperando refinar com calma o resto do turno. Ela se pergunta se o técnico ou um membro da equipe lidará com os problemas discutidos no post-mortem, ou se todos os futuros SREs terão que passar por uma experiência tão dolorosa.
Mais tarde naquele dia, Zoe participa de uma reunião em que a equipe do SRE se comunica com a equipe de desenvolvimento sobre a transferência de serviço. Steve lidera a reunião, faz várias perguntas anteriores sobre procedimentos operacionais e o atual problema de confiabilidade do serviço, pedindo aos desenvolvedores que façam alterações antes que a equipe do SRE possa assumir a responsabilidade pelo serviço. Zoe já esteve em vários comícios realizados por Steve e outros SREs seniores. Ela entende que as perguntas e as tarefas distribuídas pelos desenvolvedores são muito diferentes, dependendo de quem está realizando a reunião e que problema a equipe do SRE lidou na semana passada.
Zoe secretamente sonha com padrões e procedimentos mais consistentes, mas ainda não entende como atingir esse objetivo. Mais tarde, ela ouve dois desenvolvedores rindo da máquina de café, que muitas perguntas estavam vagamente relacionadas ao pager e geralmente não entendem de onde vieram. Zoe quer que os desenvolvedores entendam que o SRE não apenas carrega um pager com eles. Voltando ao local de trabalho, Zoe encontra vários tickets que precisam ser resolvidos e não pensa mais nisso.
Felizmente, todos os personagens e eventos desta história são inventados. No entanto, pense se isso é semelhante a algo que você encontrou na realidade. A solução para os problemas dessa equipe fictícia é muito óbvia e, na próxima seção, discutiremos mais detalhadamente.
A importância da documentação
Nos estágios iniciais da existência da equipe de SRE, a organização depende muito do trabalho de indivíduos altamente qualificados dentro da equipe. A equipe armazena importantes conceitos e princípios de exploração como partículas de “conhecimento tribal” que são transmitidas verbalmente aos novos membros da equipe. Se esses princípios não forem unificados e não documentados, provavelmente, em algum momento, eles terão que ser dolorosamente ensinados novamente por tentativa e erro. Às vezes, os membros da equipe executam procedimentos operacionais como uma sequência estrita de etapas definidas por seus predecessores no passado distante, sem nem mesmo entender as relações de causa e efeito dessas etapas. Se isso não for interrompido, os processos se fragmentam e se degeneram, custa apenas à equipe começar a crescer para resolver novos problemas.
A equipe do SRE pode impedir esse processo, criando documentação de alta qualidade que servirá como base para o crescimento dessas equipes e introduzindo uma abordagem sistemática para gerenciar serviços novos e desconhecidos. Esses documentos preservam o conhecimento tribal na forma em que é fácil encontrá-lo, mantê-lo e procurá-lo. Os novos membros da equipe são treinados através de um programa sistemático e ponderado. Essas são as características da equipe madura de SRE.
O restante deste artigo descreve os vários tipos de documentos que o SRE cria durante o ciclo de vida de um serviço suportado.
O FIM
Na
próxima parte, consideraremos todos esses tipos em detalhes, mas por enquanto estamos aguardando seus comentários e perguntas, e também convidamos você a
uma lição aberta .