Tragédia (do
alemão Tragödie do
Latin tragoedia de
outro grego τραγωδία) é um gênero de obra de arte destinada à montagem no palco em que o enredo leva os personagens a um resultado catastrófico.
A maioria das tragédias está escrita em verso. Essa tragédia foi escrita por Baruch Sadogursky (
@jbaruch ) e Leonid Igolnik (
@ligolnik ). Se estamos falando de DevOps em larga escala, o que é isso senão uma tragédia?
Este artigo é marcado pela severidade do realismo, retrata a realidade de um grande desenvolvimento de maneira mais acentuada, como um monte de contradições internas. Revela os conflitos mais profundos da realidade de forma extremamente intensa e saturada, adquirindo o valor de um símbolo artístico.
E agora terminamos de jogar Belinsky e bem-vindos ao corte! Há texto e vídeo. Não tome reféns!
Como você sabe, os gregos adoravam os diagramas de Venn. E mostraremos até três - e tudo sobre o DevOps.
Existe uma descrição tradicional do DevOps - essa é a interseção das áreas de Operações, Desenvolvimento e QA. Historicamente, é interessante que o controle de qualidade tenha sido adicionado posteriormente.
Hoje, porém, falaremos sobre outra coisa - a interseção de tecnologia, processo e pessoas. Sobre o que você precisa fazer com todos esses três componentes para obter o DevOps.
Agora compare mais dois gráficos:
Às vezes acontece.
Pentagon Inc.
Vamos começar a história com uma empresa mítica chamada Pentágono, que lida com transações com cartão de crédito.
Ato I - Bombeiros
Pessoas . A empresa está apenas começando seu trabalho, possui três engenheiros. Todos os três vieram da mesma empresa de defesa. Os caras são espertos o suficiente, então eles têm tudo: JavaScript, Node, React, Docker, microsserviços.
Processo . Como será o processo quando houver três pessoas em uma equipe? Kanban: em um pedaço de papel ou no Trello. Os caras são espertos e entendem que o controle de qualidade é necessário desde o início, portanto, testes de TDD, unidade e integração. Sem operações, todos têm raiz.
Ferramentas Assim, para três pessoas que estão apenas levantando algo:
JIRA ,
GitHub ,
Travis CI , etc.
Vamos falar sobre como essas pessoas vivem nessa bela pilha. Em primeiro lugar, como em boas startups - estamos vendo, vendo um produto e aguardando o primeiro cliente.
De repente, um milagre aconteceu - uma organização que organiza as melhores conferências no espaço pós-soviético decidiu confiar nesses caras e fazer suas transações através deles.
O que uma startup real faz quando obtém seu primeiro cliente? Comemora! E por volta das três da noite, quando tudo está em um estado
especial , o cliente liga e diz que nada está funcionando.
Claro, antes de tudo, entre em pânico!
O próximo passo é lutar! Nós olhamos para os logs, por exemplo.
Vimos, vimos, um dos nossos três heróis - Vasya, tendo voltado para casa após o festival, cometeu sua pequena ideia. Lembramos que, após a confirmação e os testes serem aprovados, tudo entra em produção.
Bem, qual de nós não falhou na produção? Não culparemos Vasya. Reverta para a confirmação anterior. Não vai! Por alguma razão, não há biblioteca suficiente, chamada teclado esquerdo.
Para quem não sabe o que aconteceu com o teclado esquerdo, contamos. Então,
em 23 de março de 2016, metade da Internet quebrou . Em geral, o módulo esquerdo do teclado em JavaScript simplesmente insere espaços no lado esquerdo das linhas. E metade da Internet dependia direta ou transitivamente desse módulo. O autor do teclado esquerdo de alguma forma conseguiu brigar com os proprietários do repositório central do npm, então ele simplesmente se afastou deles, pegando todo o seu trabalho. O npm geralmente é um sistema misterioso: eles não apenas verificam quando você adiciona um novo módulo para download, mas também todos os módulos antigos.
Assim, vez após vez, a luta contra o fogo continua. E os problemas são os mesmos o tempo todo.
Ato II - Instaladores de Alarmes de Incêndio
Notícias da empresa: levantou dinheiro, encontrou um investidor, contratou 27 pessoas, uma delas com experiência em operações. Apareceram 100 clientes e até suporte técnico.
O processo, portanto, também deve receber uma atualização. Apareceu o Scrum normal, teste exploratório. Percebemos que o NoOps não existe, porque existem Ops (se a arquitetura não possui servidor, o servidor ainda está lá, simplesmente não é seu). Como é errado acordar toda a equipe à noite, um desenvolvedor de plantão apareceu.
Consequentemente, o conjunto de ferramentas se expandiu. No mínimo, a Base de Conhecimento apareceu, já que agora existe um atendente e ele precisa procurar informações em algum lugar. Outra novidade é o
JFrog Artifactory : um sistema que permite armazenar o que foi ancorado ontem para que você possa reverter facilmente (a lição com o teclado esquerdo não foi em vão), em vez de reconstruí-lo novamente. Colocamos um sistema para coletar logs e procurá-los.
Pingdom foi adicionado - sistema de monitoramento encantador: você fornece um URL e informa se ele funciona ou travou.
Então, nesse ponto, eles levantaram dinheiro novamente. Então, notamos. Sexta-feira, três da manhã, o cliente liga. Algo não funciona: Visa e MasterCard são aprovados, mas o American Express não.
E como o suporte reage primeiro quando um cliente liga às três da manhã? Panic!
Então chamamos o atendente. Adivinha quem está de plantão? Claro, Vasya! Adivinhe em que estado Vasya está. Sim Mas Vasya se recompõe, olha para o apoio que o enviou e diz que ele está desconfiado de tudo isso e já fez isso. Portanto, Vasya simplesmente leva e repara. Todo mundo vai dormir. O interrogatório começa na segunda-feira.
Aqui está um exemplo de um documento específico que produzimos para a base de conhecimento, para que, se algo se repetir novamente, ele possa ser encontrado rapidamente. Além disso, às vezes é mostrado aos clientes:
O documento exibe os principais títulos, motivos, características e uma lista de eventos. Os sintomas devem ser indicados, é fornecida uma descrição técnica do que exatamente quebrou e como corrigi-lo. A parte mais importante do documento é a principal razão pela qual algo caiu.
No caso de Vasya, temos um excesso de fila de logs. Você precisa limpá-lo das transações com cartão de crédito e, além disso, aumentar seu tamanho. Por exemplo, aos 42!
Esse processo é muito bom para a melhoria contínua interna e garante a instalação dos mesmos "detectores de fumaça". A segunda razão pela qual este documento é importante é o relatório ao cliente. Alguns serviços, depois de ficarem "deitados" por um tempo, publicam as razões para isso.
Às vezes, o problema acaba sendo tão catastrófico que não vale a pena falar sobre isso.
No GitLab,
em fevereiro de 2017 , uma pessoa excluiu um banco de dados de produção. Aqui está a análise que o GitLab enviou:
Então, em algum lugar existe backup, ninguém sabe onde. Em seguida, foram encontrados backups, mas eles estavam vazios. Sim, existe um despejo de base. Mas foi feito em uma versão diferente do postgres, portanto não se encaixa. Temos instantâneos, mas eles não têm banco de dados. A replicação do S3 também não funcionou devido à falta de dados.
Portanto, cinco técnicas diferentes para fazer backup de dados não funcionaram. Achamos que isso não pode ser publicado, pois ninguém mais confiará neles. Mas, dependendo de como você fala sobre isso, o cliente pode perdoar. Verdade, apenas uma vez.
A propósito, aquele cara que fez isso ganhou uma promoção. Além disso, ele mudou seu status no twitter para
Especialista em banco de
dados (remoção) no GitLab .
Ato III - Climax
Então, o que está acontecendo em nossa empresa? Eles levantaram dinheiro novamente, contrataram várias pessoas - agora temos cinco engenheiros de operações e uma pessoa envolvida em desempenho. Há um arquiteto chefe. Uma equipe de sucesso do cliente apareceu, cobrindo todos os setores que podem precisar de suporte. Eles são desacelerados para que o restante da equipe possa continuar trabalhando. Freqüentemente, em uma equipe como essa, há um grupo que pode construir relacionamentos com operações ou suporte e, também periodicamente, é necessário contratar engenheiros no scrum, no sprint ou durante um mês. A empresa cresceu, um advogado, um diretor financeiro apareceu. A base de clientes aumentou para 1000.
À medida que a equipe cresce, o processo de desenvolvimento deve mudar.
O SAFE apareceu - uma estrutura que explica o que fazer scrum quando há muitas equipes ou centros de desenvolvimento - mais de um. O número de processos presentes no Safe pode matar um cavalo, mas se todos eles puderem ser executados de uma só vez. Se você retirar apenas as peças necessárias nesta fase do desenvolvimento da empresa, tudo ficará bem.
O teste do sistema aparece quando grandes equipes têm certas necessidades ou se você possui um sistema enorme a partir do qual precisa criar algo. Equipes de scrum individuais podem testar bem seus sistemas, mas alguém deve ser responsável pelo fato de que todo o sistema deve ser montado em produção.
E a equipe de operações? Como dissemos, existem duas opções para executar o DevOps. O primeiro é para o livro e para instruções da Netflix, Google e Twitter. O segundo é na vida real, onde nem todos os engenheiros podem confiar na raiz da produção.
Caminho de escalação é um conceito importante que permite resolver qualquer problema em um determinado momento, porque no final do caminho de escalação existe o telefone celular do CEO, após uma chamada na qual todos os problemas desaparecem em 5 horas e 58 minutos.
SOC II - um conjunto de padrões que o fornecedor fornece ao cliente. Esses padrões confirmam que a empresa possui certas soluções de segurança, abordagens para a divisão do trabalho.
Lista de pendências - uma lista de problemas que precisam ser resolvidos para melhorar o sistema. Normalmente, o arquiteto anterior se torna o arquiteto principal, que deve examinar as necessidades do sistema e as necessidades do produto e priorizar essas tarefas.
As ferramentas, é claro, também estão sendo aprimoradas.
Há mais novidades. Vasya foi promovido. Ele agora é vice-presidente de engenharia.
Sexta, sábado e domingo passam - nada acontece. Tudo funciona. Todo mundo está em choque. Segunda-feira chega, um advogado chega a Vasya e diz que ele estava em uma conferência de advogados e ouviu falar da LGPL 2.2 lá. Vasya não tem idéia se eles têm LGPL 2.2.
As pessoas trabalharam por um longo tempo e depois encontraram o LGPL 2.2. Precisa cortar. Mas isso está sendo cortado por uma parte saudável do sistema, e ninguém cancelou o lançamento amanhã. Bem, nada, lidou com isso.
O diretor do fundo vem a Vasya:
- Quanto dinheiro você precisa para servidores e produção? Fazendo o orçamento para o próximo ano ...
- 42 - diz Vasya.
Também resolvemos esse problema.
Eles vêm a Vasya e dizem que existe um cliente em potencial, mas ele teme que nunca tenhamos um cliente em grande escala e quer estar convencido de que será bom. Sabemos pela história que, nesta fase, todos morreram.
Mas, como devemos ter um final feliz, anexamos à tragédia grega.
Epílogo - Melhoria Proativa
Agora, vamos falar sobre o último estágio do dimensionamento do DevOps - melhoria proativa. É sobre prevenção de incêndio.
Nenhuma mudança está acontecendo com as pessoas. Mas com o processo - muito mesmo.
Como temos um engenheiro de desempenho, ele deve, de alguma forma, monitorar o sistema. Apareceu o gerenciamento de licenças e segurança. Desempenho proativo - agora estamos observando atentamente onde os principais indicadores estão se movendo e consertando as coisas antes que um grande incêndio comece. Ao expandir um produto, é aconselhável ter algo a dizer: se você deseja ter um microsserviço, pelo menos deve ter monitoramento padrão, logs e assim por diante.
Conseqüentemente, existem ferramentas que suportam tudo isso. Por exemplo, uma ferramenta para monitoramento de licença e segurança é o
JFrog Xray .
Blazemeter - como agora há desempenho proativo, você precisa gerar uma carga de alguma forma. Coisas estão surgindo como Service Virtualization, que permite usar objetos simulados para APIs remotas, porque nem todo fornecedor com quem você trabalha pode fornecer uma API de teste.
Análise
Vamos analisar alguns eventos de atos anteriores.
Lembra do caso em que Vasily planejou um orçamento com um dedo no céu? Ao trabalhar em um de nossos produtos, queríamos descobrir em que recursos estavam sendo gastos. Depois de agrupar tudo o que estava na lista de pendências, obtivemos este diagrama:
Por engano, pensávamos que estávamos gastando 80% no Big Feature A - na verdade, são necessários apenas 13%. Ao mesmo tempo, 34% vai para Manter as luzes acesas - coisas que precisam ser feitas nos produtos: consertar bugs, atualizar bibliotecas etc.
De fato, existe apenas uma métrica objetiva da qualidade do produto: satisfação do cliente, expressa em chamadas para suporte.
Segundo exemplo. Quebramos todos os defeitos de criticidade:
65% dos tickets pertencem aos primeiros níveis de criticidade. Isso é um pesadelo?
Agora pegue os mesmos dados e olhe para eles de um ângulo diferente.
Agora, o gráfico reflete a situação após o interrogatório. Aconteceu que 52% dos ingressos foram fechados pelo engenheiro usando as informações fornecidas, ou seja, ele escreveu ao suporte o que eles não sabiam. Apenas cerca de 20% dos tickets foram fechados com algum tipo de alteração de código. Assim, verifica-se que a pesquisa e o desenvolvimento não são os culpados. Nem mesmo o apoio é o culpado. De fato, não tínhamos treinamento - e Vasya, como vice-presidente de engenharia, depois de ver quanto gasta tempo com todo tipo de bobagem, ele enviou um monte de engenheiros para treinar suporte.
Os caras corrigiram a documentação em gargalos, os logs. Como resultado, a peça, que levou muito tempo para os desenvolvedores, desapareceu.
Conclusões
Em todos os estágios, do combate a incêndios à instalação de alarmes e resolução proativa de problemas, existem muitos processos, pessoas, especialistas, abordagens, ferramentas que precisam ser instaladas. Tudo isso não pode ser feito em um dia. Além disso, algumas coisas não são necessárias em alguns estágios de desenvolvimento.
É importante entender que, nas pessoas, nos processos e nas ferramentas, algumas melhorias são constantemente necessárias.
O que exatamente precisa ser melhorado, seremos ajudados a descobrir exatamente os números de que falamos. Somente com base nesses dados podemos tomar as decisões corretas sobre onde investir tempo e o que avançar.
E não se esqueça dos dois princípios fundamentais do DevOps:
- Você constrói - você é o dono.
- A dor é instrutiva.
No próximo domingo, Baruch e Leonid entregarão um relatório "#DataDrivenDevOps" no DevOops 2018 em São Petersburgo. Venha, haverá muitas coisas interessantes: aqui estão os relatórios , aqui está John Willis , e aqui está uma festa com BoFs e karaokê . Esperando por você!