Desenvolvimento orientado pela observabilidade

Não há dúvida de que os sistemas se tornam cada vez mais complicados quanto mais distribuídos eles são. Ele faz monitoramentos 24 horas por dia e 7 dias por semana e é essencial para a maioria das empresas. Mas como a observabilidade afetou os ciclos de feedback DevOps cada vez menores? Neste artigo, resumimos os aprendizados sobre o desenvolvimento orientado por observabilidade de Charity Majors, fundadora da Honeycomb e feroz defensora da observabilidade.

DevOps é um convite para re-motivar os desenvolvedores

"Originalmente, o ciclo de feedback era que você quebraria coisas, as pessoas gritariam com você e então o elogiariam quando você as consertasse, mas então a Internet se tornou uma coisa e nossos sistemas ficaram mais complicados", disse Majors à CloudNative 2018, em Londres.

Majors lembrou que todos começamos a possuir o próprio software - porque quem mais iria possuí-lo - mas, à medida que afastamos dessa propriedade, perdemos a capacidade de saber quando algo não estava certo. Os silos levaram os desenvolvedores mais longe de executar o código, e o movimento DevOps apareceu como "uma tentativa de retornar à graça, para retornar ao estado do ciclo de feedback virtuoso", disse Majors.

Cada desenvolvedor precisa ser dono do seu código, com possibilidade de publicar e depurar em produção. Qualquer coisa menor que isso, não está completamente igual ao conceito de dono do DevOps, Majors argumenta:

Torna o software melhor, a pessoa que está depurando tem o contexto mais relevante para depurá-lo quando estiver ativo.

Ela passou a oferecer a Lei de Caridade de DevOps:

Aqueles que escrevem o código podem e devem implantar seu código e apoiá-lo na produção.

O objetivo da automação do DevOps não é apenas a velocidade, mas sim alavancar a motivação intrínseca e a criatividade dos desenvolvedores novamente, libertando-os de trabalhos de reparo não criativos e tediosos:

O que nos faz sentir completo e satisfeito é tudo sobre autonomia, sentir-se fortalecido, construir algo com o que se importa e se importar com isso.

Isso, é claro, está de acordo com os três principais motivadores intrínsecos de Dan Pink para os trabalhadores do conhecimento: autonomia, domínio e propósito.

No entanto, tempo e também os desenvolvedores estão lançando código que parece bem em sua configuração local, mas assim que eles são implementados, todo tipo de problema ocorre. Pode levar dias para descobrir o que está errado, quanto mais consertar o problema. Majors adverte:

A primeira lição de um sistema distribuído é que seu sistema nunca está ativo - seus muitos estados catastróficos existem em um determinado momento.

No entanto, uma vez que o desenvolvimento orientado à observabilidade é implementado com a pilha certa, a instrumentação e, principalmente, a visualização, essas mesmas falhas do sistema podem ser descobertas e tratadas muito mais rapidamente, normalmente em horas ou até minutos.

Como o desenvolvimento orientado por observabilidade está educando os desenvolvedores sobre seus sistemas

O que é desenvolvimento orientado por observabilidade? Ele está alavancando ferramentas e aumentando a praticidade dos desenvolvedores para observar o estado e o comportamento de um sistema, de modo que você aprenda mais sobre esse sistema, incluindo padrões de fragilidade. O ODD está, na verdade, interrogando o sistema, enquanto o monitoramento está apenas definindo e medindo os limiares para ele.

Majors argumenta que o desenvolvimento orientado a testes - o processo de escrever um teste e depois escrever código que passa no teste - está agora pronto para evoluir para o desenvolvimento orientado pela observabilidade. Ambos caem sob a égide do desenvolvimento orientado pelo comportamento, mas a ODD mostra uma compreensão maior desse comportamento.

Majors diz que o desenvolvimento orientado por observabilidade é um processo que você pode usar para estar de prontidão também. A observabilidade faz parte da teoria de controle, que examina como podemos controlar sistemas distribuídos complicados.

Você entende o que está acontecendo dentro do seu sistema, dentro do seu código, apenas interrogando-o. Você pode responder a novas perguntas sem enviar um novo código?

Majors enfatizou que se trata de atingir o nível certo de abstração, não contribuindo para uma base de código mais complicada:

Quando você tem um sistema observável, sua equipe rastreará de forma rápida e confiável qualquer novo problema sem conhecimento prévio. [Eles vão] entender UX, comportamento e razões para seus códigos e bugs.

A observabilidade não nega o monitoramento, que ainda é uma parte importante da cobertura do DevOps. Mas, de acordo com Majors, o monitoramento não se manteve nos últimos 20 anos, sendo ainda mais adequado para os requisitos locais.

Leva os restos das interrupções passadas para traduzi-los no que esses painéis significam - apenas cerca de dois por cento dos engenheiros de software entendem isso.

Majors citou o fluxo de trabalho da ferramenta de automação de Greg Poirier, vice-presidente de engenharia da Sensu, dizendo que "o monitoramento está morto". Poirier argumenta que é o ato de observar e verificar o comportamento e os resultados de um sistema e seus componentes ao longo do tempo - uma boa definição de desenvolvimento orientado por observabilidade - o que torna o monitoramento de um modelo desatualizado para sistemas complexos.

"É importante criar ferramentas que façam sentido para as pessoas, para que elas vivam em uma realidade", disse Majors, falando sobre a necessidade de painéis transparentes e interorganizacionais.

Para Majors, a observabilidade diz respeito a assegurar que os "desconhecidos conhecidos" sejam maiores ou iguais aos "desconhecidos desconhecidos".

Existem alguns problemas que você só pode ver se estiver de fora. Você precisa reunir os detalhes que permitirão encontrar qualquer um deles.

Majors chama a observabilidade de um jogo de busca de discrepância- se você tem uma dúzia de falhas, o que todas elas têm em comum, com base em dados coletados e consultados? Ela disse que você deve se preocupar se cada solicitação pode ter sucesso e se você pode obter recursos para trabalhar de ponta-a-ponta.

O imenso desafio dos sistemas distribuídos é agravado pelo fato de que eles são, na verdade, mais parecidos com uma rede interconectada de sistemas, muitos dos quais estão fora de nossa esfera de controle. Eles são, portanto, impossíveis de observar diretamente.

O monitoramento está monitorando. Observar é o primeiro teste em produção.

"Cada parte da arquitetura é única, então você tem que testá-la. E você tem que testá-la em produção, porque você só pode testar muito antes de entrar em produção", disse Majors, explicando que implantar código não é on-off, interruptor binário.

Você poderia, é claro, testar antes de implantar em homologação e depois de implantar na produção, mas isso poderia esgotar os recursos de engenharia muitas vezes limitados. Majors defende abraçar a realidade que você está testando em produção tendo a intenção ou não, e recomenda o uso de técnicas como o teste canário como guardrails para ajudar a alcançar a observabilidade.

Ela chama a observabilidade de o elo perdido, permitindo que os proprietários de software testem em produção, oferecendo uma perspectiva de primeiro evento do software, como ele está sendo usado e como está reagindo a esse uso.

Majors diz que um bom monitoramento automatizado inclui essas práticas recomendadas:

• Muitas verificações e alertas ativos acionáveis
• Notificação proativa de engenheiros das falhas e avisos
• Manter um runbook para estabilidade e previsibilidade em sistemas de produção
• Esperar clusters e conjuntos de sistemas fortemente acoplados para todos quebrar de uma só vez

Mas com microservices fica muito mais complicado, com muito mais dos "desconhecidos desconhecidos".

Existem tantos componentes e sistemas de armazenamento que não é possível modelar todo o sistema em sua cabeça. A saúde do sistema é irrelevante - a saúde de cada solicitação individual é de suprema conseqüência.

O TDD cobre apenas os desconhecidos conhecidos, que se tornam um problema de suporte. Estes são previsíveis e podem ser tratados dentro de um prazo previsível e podem ser monitorados em um painel.

Os "desconhecido desconhecido" continuam sendo um problema de engenharia. Estes são freqüentemente abertos no tempo certo para consertar-los, e requerem exploração dos sistemas e criatividade. É sobre o que os desenvolvedores devem gastar seu tempo. A observabilidade aborda esse grande desconhecido.

A observabilidade é sobre caçar seus desconhecidos e descobrir seus eventos

Majors diz, que para fazer a observação correta, você deve trazê-lo no momento em que você considera construir algo, tornando-se uma parte inerente do seu processo de desenvolvimento.

Ela diz que é sobre caçar suas incógnitas, afinar seus instrumentos de dentro para fora. E trata-se de ser um bom administrador de software para o próximo usuário, mesmo que esse usuário esteja seis meses abaixo da linha imaginando por que você fez essa escolha.

Entrando na cabeça do software e explicando de volta para você e para um usuário ingênuo - encontrando esses breadcrumbs e deixando-os para que você possa rastreá-lo de volta à fonte.

O monitoramento é principalmente sobre métricas, enquanto observabilidade é sobre eventos. Majors recomenda que primeiro se concentre na depuração de eventos de alta cardinalidade - informações importantes, mas muitas vezes exclusivas, como números de identificação, nomes de usuário e endereços de e-mail - porque envolvem muito contexto e rastreamento.

Ela diz que os eventos contam histórias que ajudam a descobrir esse contexto e os valores discrepantes, o que, por sua vez, ajuda na identificação do que está errado. Ela continua que a largura de banda e o custo restringem sua capacidade de armazenar "todos os dados o tempo todo", mas é essencial estruturar seus registros de dados agregados "porque é assim que nossos cérebros funcionam e é assim que nosso código funciona".

De acordo com Majors, a criação de um painel não é a resposta: "É um artefato de algum fracasso passado. Ele salta para a resposta, em vez de começar com uma pergunta", argumenta Majors em tempo real, em vez de se agarrar às tendências. Ela continuou a explicar que a observabilidade requer a capacidade de detalhar os dados da amostra até às solicitações brutas. A agregação não funciona porque você nunca pode expandir novamente os dados que foram mesclados anteriormente. A amostragem, no entanto, permite manter um nível de detalhe suficiente para fazer mais perguntas posteriormente. A observabilidade é sobre fazer uma pergunta e seguir a resposta. Em seguida, faça uma nova pergunta. E repetindo este ciclo até você descobrir qual "desconhecido desconhecido".

Proprietários de serviços, não apenas operadores

Os serviços realmente precisam de proprietários, não de operadores, e precisam que seus proprietários se importem com a observabilidade antes mesmo de escrever a primeira linha de código.

No novo mundo do DevOps, isso significa que os desenvolvedores precisam de um nível mais alto de alfabetização operacional e de serem fluentes em seu próprio código. Majors diz que para conseguir essa proficiência e realmente entender o que é "anormal", os desenvolvedores precisam estar observando o código ser executado na produção. Majors sugere que isso pode reduzir o número de incidentes de produção em até 80%.

Ela acredita que, em algum momento no futuro, a inteligência artificial e a aprendizagem automática chegarão ao nível em que o software torna-se sensível ao contexto e autocura.

A principal premissa de Major é que a observabilidade adequada levará a um número muito menor de alertas de pager, com apenas reclamações de latência sendo sinalizadas.

Sobre a autora

Jennifer Riggins é uma jornalista e escritora de tecnologia, onde a transformação digital encontra a cultura, mudando o mundo para um lugar melhor. Siga-a no Twitter @jkriggins.