Com base em uma discussão de bate-papo
Recentemente, surgiram verdadeiras batalhas sobre a definição de DevOps e SRE.
Apesar do fato de que, de muitas maneiras, as discussões sobre esse assunto já me deixaram nervoso, inclusive eu, decidi levar minha opinião sobre esse assunto ao tribunal da comunidade Habra. Para quem estiver interessado, seja bem-vindo ao gato. E que tudo comece de novo!
Pré-história
Assim, nos tempos antigos, uma equipe de desenvolvedores de software e administradores de servidores vivia separadamente. O primeiro escreveu o código com sucesso, o segundo, usando várias palavras calorosas e afetuosas dirigidas ao primeiro, configurou os servidores, chegando periodicamente aos desenvolvedores e recebendo em resposta um abrangente “tudo funciona na minha máquina”. O negócio esperava o software, estava tudo parado, quebrava de vez em quando, todo mundo ficava nervoso. Principalmente aquele que pagou por toda essa bagunça. Era gloriosa da lâmpada. Bem, você já sabe de onde vem o DevOps.
O nascimento das práticas DevOps
Aí vieram caras sérios e disseram - isso não é uma indústria, você não pode trabalhar assim. E trouxeram modelos de ciclo de vida. Aqui, por exemplo, está o modelo V.
Então, o que vemos? Uma empresa vem com um conceito, os arquitetos projetam soluções, os desenvolvedores escrevem o código e então ela falha. Alguém de alguma forma testa o produto, alguém de alguma forma o entrega ao usuário final e, em algum lugar na saída desse modelo milagroso, está um cliente empresarial solitário esperando o tempo prometido à beira-mar. Chegamos à conclusão de que precisamos de métodos que nos permitam estabelecer esse processo. E decidimos criar práticas que os implementassem.
Uma digressão lírica sobre o que é a prática
Por prática quero dizer uma combinação de tecnologia e disciplina. Um exemplo é a prática de descrever infraestrutura usando código terraform. Disciplina é como descrever a infraestrutura com código, está na cabeça do desenvolvedor, e a tecnologia é o próprio terreno.
E eles decidiram chamá-las de práticas DevOps – acho que eles queriam dizer do Desenvolvimento às Operações. Criamos várias coisas inteligentes – práticas de CI/CD, práticas baseadas no princípio IaC, milhares delas. E lá vamos nós, os desenvolvedores escrevem código, os engenheiros DevOps transformam a descrição do sistema na forma de código em sistemas funcionais (sim, o código é, infelizmente, apenas uma descrição, mas não a personificação do sistema), a entrega continua, e assim por diante. Os administradores de ontem, tendo dominado novas práticas, orgulhosamente se reciclaram como engenheiros de DevOps, e tudo começou a partir daí. E houve noite e houve manhã... desculpe, não foi daí.
Não está tudo bem de novo, graças a Deus
Assim que tudo se acalmou e vários “metodologistas” astutos começaram a escrever livros grossos sobre práticas de DevOps, surgiram disputas silenciosas sobre quem era o notório engenheiro de DevOps e que DevOps é uma cultura de produção, e o descontentamento surgiu novamente. De repente, descobriu-se que a entrega de software não é uma tarefa trivial. Cada infraestrutura de desenvolvimento tem sua própria pilha, em algum lugar você precisa montá-la, em algum lugar você precisa implantar o ambiente, aqui você precisa do Tomcat, aqui você precisa de uma maneira astuta e complicada de iniciá-lo - em geral, sua cabeça está latejando. E o problema, curiosamente, acabou sendo principalmente na organização dos processos - essa função de entrega, como um gargalo, começou a bloquear os processos. Além disso, ninguém cancelou as operações. Não é visível no modelo V, mas ainda há todo o ciclo de vida à direita. Com isso, é necessário de alguma forma manter a infraestrutura, monitorar o monitoramento, resolver incidentes e também lidar com a entrega. Aqueles. sente-se com um pé tanto no desenvolvimento quanto na operação - e de repente acabou sendo Desenvolvimento e Operações. E então houve o entusiasmo geral pelos microsserviços. E com eles, o desenvolvimento de máquinas locais começou a migrar para a nuvem - tente depurar algo localmente, se houver dezenas e centenas de microsserviços, a entrega constante se tornará um meio de sobrevivência. Para uma “pequena e modesta empresa” tudo bem, mas mesmo assim? E o Google?
SRE do Google
O Google veio, comeu os maiores cactos e decidiu: não precisamos disso, precisamos de confiabilidade. E a confiabilidade deve ser gerenciada. E decidi que precisamos de especialistas que gerenciem a confiabilidade. Liguei para eles, engenheiros de SR, e disse: é isso para vocês, façam bem, como sempre. Aqui está o SLI, aqui está o SLO, aqui está o monitoramento. E ele meteu o nariz nas operações. E ele chamou seu SRE de “DevOps confiável”. Tudo parece estar bem, mas há um hack sujo que o Google poderia pagar - para a posição de engenheiros de SR, contratar pessoas que fossem desenvolvedores qualificados e também fizessem um pouco de lição de casa e entendessem o funcionamento dos sistemas em funcionamento. Além disso, o próprio Google tem problemas em contratar essas pessoas - principalmente porque aqui compete consigo mesmo - é preciso descrever a lógica do negócio para alguém. A entrega foi atribuída aos engenheiros de liberação, SR - os engenheiros gerenciam a confiabilidade (claro, não diretamente, mas influenciando a infraestrutura, alterando a arquitetura, rastreando mudanças e indicadores, lidando com incidentes). Legal, você pode . Mas e se você não for o Google, mas a confiabilidade ainda for uma preocupação?
Desenvolvimento de ideias DevOps
Só então chegou o Docker, que cresceu a partir do lxc, e então vários sistemas de orquestração, como Docker Swarm e Kubernetes, e engenheiros de DevOps exalaram - a unificação de práticas simplificou a entrega. Ele simplificou a tal ponto que se tornou possível até mesmo terceirizar a entrega para desenvolvedores - o que é o deploy.yaml. A conteinerização resolve o problema. E a maturidade dos sistemas CI/CD já está no nível de escrever um arquivo e pronto - os desenvolvedores podem cuidar disso sozinhos. E então começamos a falar sobre como podemos fazer nosso próprio SRE, com... ou pelo menos com alguém.
SRE não está no Google
Bem, ok, entregamos a entrega, parece que podemos expirar, voltar aos bons e velhos tempos, quando os administradores observavam a carga do processador, ajustavam os sistemas e bebiam silenciosamente algo incompreensível nas canecas em paz e sossego... Pare. Não foi por isso que começamos tudo (o que é uma pena!). De repente, acontece que na abordagem do Google podemos facilmente adotar práticas excelentes - não é a carga do processador que é importante, e nem a frequência com que trocamos os discos lá, ou otimizamos o custo na nuvem, mas as métricas de negócios são as mesmas notórias. SLx. E ninguém removeu deles o gerenciamento de infraestrutura, e eles precisam resolver incidentes, estar de plantão periodicamente e, em geral, manter o controle dos processos de negócios. E pessoal, comecem a programar aos poucos em bom nível, o Google já está esperando por vocês.
Para resumir. De repente, mas você já está cansado de ler e mal pode esperar para cuspir e escrever para o autor um comentário no artigo. O DevOps como prática de entrega sempre foi e será. E não vai a lugar nenhum. O SRE como um conjunto de práticas operacionais torna esta entrega bem-sucedida.
Fonte: habr.com