Charity Majors, CTO & Co-Founder at Honeycomb – Interview Series

Charity é uma engenheira de operações e fundadora acidental de startup na Honeycomb. Antes disso, ela trabalhou no Parse, Facebook e Linden Lab em infraestrutura e ferramentas de desenvolvedor, e sempre acabou administrando os bancos de dados. Ela é coautora do Database Reliability Engineering da O’Reilly, e adora liberdade de expressão, software livre e uísque single malt.

Você foi a Gerente de Engenharia de Produção do Facebook (agora Meta) por mais de 2 anos, quais foram alguns dos seus destaques durante esse período e quais são algumas das suas principais lições aprendidas com essa experiência?

Eu trabalhei no Parse, que era um backend para aplicativos móveis, tipo um Heroku para móveis. Eu nunca havia me interessado em trabalhar em uma grande empresa, mas fomos adquiridos pelo Facebook. Uma das minhas principais lições aprendidas foi que as aquisições são realmente, realmente difíceis, mesmo nas melhores circunstâncias. O conselho que eu sempre dou a outros fundadores agora é este: se você for adquirido, certifique-se de ter um patrocinador executivo e pense muito bem sobre se você tem alinhamento estratégico. O Facebook adquiriu o Instagram não muito tempo antes de adquirir o Parse, e a aquisição do Instagram não foi exatamente um sucesso, mas foi ultimately muito bem-sucedida porque eles tinham alinhamento estratégico e um forte patrocinador.

Eu não tive um tempo fácil no Facebook, mas sou muito grata pelo tempo que passei lá; não sei se eu poderia ter iniciado uma empresa sem as lições que aprendi sobre estrutura organizacional, gerenciamento, estratégia, etc. Isso também me deu um pedigree que me tornou atraente para os VCs, nenhum deles havia me dado atenção até esse ponto. Estou um pouco irritada com isso, mas ainda assim vou aceitar.

Pode compartilhar a história de como surgiu a ideia de lançar a Honeycomb?

Com certeza. Do ponto de vista arquitetônico, o Parse estava à frente do seu tempo — estávamos usando microserviços antes que existissem microserviços, tínhamos uma camada de dados massivamente fragmentada e, como uma plataforma que servia mais de um milhão de aplicativos móveis, tínhamos muitos problemas de multi-locatário complicados. Nossos clientes eram desenvolvedores, e eles estavam constantemente escrevendo e carregando trechos de código e novas consultas de, digamos, “qualidade variável” — e nós apenas tínhamos que aceitar tudo e fazer funcionar, de alguma forma.

Nós estávamos à vanguarda de uma série de mudanças que desde então se tornaram mainstream. Costumava ser que a maioria das arquiteturas era bastante simples, e elas falhavam repetidamente de maneira previsível. Você normalmente tinha uma camada web, um aplicativo e um banco de dados, e a maioria da complexidade estava ligada ao seu código de aplicativo. Então você escrevia verificações de monitoramento para assistir a essas falhas e construir painéis estáticos para seus métricas e dados de monitoramento.

Essa indústria viu uma explosão de complexidade arquitetônica nos últimos 10 anos. Nós explodimos o monólito, então agora você tem de algumas dezenas a milhares de microserviços de aplicativos. A persistência poliglota é a norma; em vez de “o banco de dados” é normal ter muitos tipos de armazenamento diferentes, bem como fragmentação horizontal, camadas de cache, db-per-microservice, filas e mais. Além disso, você tem contêineres hospedados no lado do servidor, serviços e plataformas de terceiros, código sem servidor, armazenamento em bloco e mais.

A parte difícil costumava ser depurar seu código; agora, a parte difícil é descobrir onde no sistema o código que você precisa depurar está. Em vez de falhar repetidamente de maneira previsível, é mais provável que cada vez que você for chamado, seja sobre algo que você nunca viu antes e pode nunca ver novamente.

Essa é a situação em que estávamos no Parse, no Facebook. Todos os dias a plataforma inteira estava caindo, e todas as vezes era algo diferente e novo; um aplicativo diferente atingindo o top 10 na iTunes, um desenvolvedor diferente carregando uma consulta ruim.

Depurar esses problemas do zero é insanamente difícil. Com logs e métricas, você basicamente precisa saber o que está procurando antes de poder encontrá-lo. Mas começamos a alimentar alguns conjuntos de dados em uma ferramenta do Facebook chamada Scuba, que nos permitia fatiar e dividir em dimensões arbitrárias e dados de alta cardinalidade em tempo real, e o tempo que levava para identificar e resolver esses problemas do zero caiu como uma rocha, como de horas para… minutos? segundos? Não era mais um problema de engenharia, era um problema de suporte. Você apenas seguia o rastro de migalhas até a resposta todas as vezes, clicando e clicando.

Foi incrível. Essa enorme fonte de incerteza e esforço e clientes infelizes e páginas às 2 da manhã… simplesmente desapareceu. Não foi até que Christine e eu saíssem do Facebook que percebemos quanto isso havia transformado a maneira como interagíamos com o software. A ideia de voltar aos velhos dias ruins de verificações de monitoramento e painéis era simplesmente impensável.

Mas na época, honestamente pensávamos que isso seria uma solução de nicho — que resolvia um problema que outras plataformas multitenant massivas poderiam ter. Não foi até que tivéssemos passado quase um ano construindo que começamos a perceber que, oh, isso está se tornando um problema para todos.

Para leitores que não estão familiarizados, pode explicar o que específicamente é uma plataforma de observabilidade e como ela difere do monitoramento e métricas tradicionais?

O monitoramento tradicional é famoso por ter três pilares: métricas, logs e rastros. Você normalmente precisa comprar muitas ferramentas para atender às suas necessidades: logging, rastreamento, APM, RUM, dashboarding, visualização, etc. Cada uma delas é otimizada para um caso de uso diferente em um formato diferente. Como engenheiro, você se senta no meio delas, tentando dar sentido a todas elas. Você folheia os painéis procurando por padrões visuais, você copia e cola IDs de logs para rastros e vice-versa. É muito reativo e fragmentado, e normalmente você se refere a essas ferramentas quando tem um problema — elas são projetadas para ajudá-lo a operar seu código e encontrar bugs e erros.

A observabilidade moderna tem uma fonte única de verdade; eventos de log estruturados arbitrariamente amplos. A partir desses eventos, você pode derivar suas métricas, painéis e logs. Você pode visualizá-los ao longo do tempo como um rastro, você pode fatiar e dividir, você pode zoomar em solicitações individuais e para fora da visão geral. Porque tudo está conectado, você não precisa pular de ferramenta em ferramenta, adivinhando ou confiando na intuição. A observabilidade moderna não é apenas sobre como você opera seus sistemas, é sobre como você desenvolve seu código. É o substrato que permite que você conecte laços de feedback poderosos e apertados que ajudam a entregar muitos valores aos usuários rapidamente, com confiança, e encontrar problemas antes que os usuários os encontrem.

Você é conhecida por acreditar que a observabilidade oferece uma fonte única de verdade em ambientes de engenharia. Como a IA se integra a essa visão, e quais são os benefícios e desafios nesse contexto?

A observabilidade é como colocar óculos antes de ir a toda velocidade na estrada. O desenvolvimento orientado a testes (TDD) revolucionou o software no início dos anos 2000, mas o TDD está perdendo eficácia à medida que a complexidade está localizada em nossos sistemas em vez de apenas em nosso software. Cada vez mais, se você quiser obter os benefícios associados ao TDD, você realmente precisa instrumentar seu código e realizar algo semelhante ao desenvolvimento orientado à observabilidade, ou ODD, onde você instrumenta à medida que vai, implanta rapidamente, então olha seu código em produção através da lente da instrumentação que você acabou de escrever e pergunta a si mesmo: “está fazendo o que eu esperava que fizesse, e algo mais parece… estranho?”

Os testes sozinhos não são suficientes para confirmar que seu código está fazendo o que deve fazer. Você não sabe disso até que tenha assistido a ele em produção, com usuários reais em infraestrutura real.

Esse tipo de desenvolvimento — que inclui produção em laços de feedback rápidos — é (um pouco contraintuitivamente) muito mais rápido, fácil e simples do que confiar em testes e ciclos de implantação mais lentos. Uma vez que os desenvolvedores tenham tentado trabalhar dessa maneira, eles são famosos por não quererem voltar à maneira lenta e antiga de fazer as coisas.

O que me entusiasma sobre a IA é que, quando você está desenvolvendo com LLMs, você tem que desenvolver em produção. A única maneira de derivar um conjunto de testes é validando seu código em produção e trabalhando de trás para frente. Acho que escrever software respaldado por LLMs será uma habilidade tão comum quanto escrever software respaldado por MySQL ou Postgres em alguns anos, e minha esperança é que isso arraste os engenheiros chutando e gritando para uma vida melhor.

Você levantou preocupações sobre a dívida técnica crescente devido à revolução da IA. Pode elaborar sobre os tipos de dívidas técnicas que a IA pode introduzir e como a Honeycomb ajuda a gerenciar ou mitigar essas dívidas?

Estou preocupada com a dívida técnica e, talvez mais importante, a dívida organizacional. Um dos piores tipos de dívida técnica é quando você tem software que não é bem entendido por ninguém. O que significa que qualquer vez que você tenha que estender ou alterar esse código, ou depurá-lo ou corrigi-lo, alguém tem que fazer o trabalho difícil de aprendê-lo.

E se você colocar código em produção que ninguém entende, há uma boa chance de que ele não foi escrito para ser compreendido. O código bom é escrito para ser fácil de ler e entender e estender. Ele usa convenções e padrões, usa nomeação e modularização consistentes, equilibra DRY e outras considerações. A qualidade do código é inseparável de quão fácil é para as pessoas interagir com ele. Se você simplesmente começar a jogar código em produção porque compila ou passa nos testes, você está criando um iceberg massive de problemas técnicos futuros para si mesmo.

Se você decidiu enviar código que ninguém entende, a Honeycomb não pode ajudar com isso. Mas se você se importa em enviar software limpo e iterável, instrumentação e observabilidade são absolutamente essenciais para esse esforço. A instrumentação é como documentação mais relatórios de estado em tempo real. A instrumentação é a única maneira de realmente confirmar que seu software está fazendo o que você espera que faça, e se comporta da maneira que seus usuários esperam que se comporte.

Como a Honeycomb utiliza a IA para melhorar a eficiência e eficácia das equipes de engenharia?

Nossos engenheiros usam muito a IA internamente, especialmente o CoPilot. Nossos engenheiros mais juniores relatam usar o ChatGPT todos os dias para responder a perguntas e ajudá-los a entender o software que estão construindo. Nossos engenheiros mais seniores dizem que é ótimo para gerar software que seria muito tedioso ou chato de escrever, como quando você tem um grande arquivo YAML para preencher. É útil para gerar trechos de código em linguagens que você não usa normalmente, ou a partir da documentação da API. Como, você pode gerar alguns exemplos realmente bons e úteis de coisas usando os SDKs e APIs do AWS, desde que tenha sido treinado em repositórios que têm uso real desse código.

No entanto, qualquer vez que você deixe a IA gerar seu código, você tem que passar por ele linha por linha para garantir que esteja fazendo a coisa certa, porque ele absolutamente vai hallucinar lixo regularmente.

Pode fornecer exemplos de como os recursos alimentados por IA, como o seu assistente de consulta ou integração com o Slack, melhoram a colaboração em equipe?

Sim, com certeza. Nosso assistente de consulta é um ótimo exemplo. Usar construtores de consultas é complicado e difícil, mesmo para usuários avançados. Se você tiver centenas ou milhares de dimensões em sua telemetria, você não pode sempre lembrar de cabeça quais são os mais valiosos. E mesmo os usuários avançados esquecem os detalhes de como gerar certos tipos de gráficos.

Então nosso assistente de consulta permite que você faça perguntas usando linguagem natural. Como, “quais são os endpoints mais lentos?”, ou “o que aconteceu após minha última implantação?” e ele gera uma consulta e o coloca nela. A maioria das pessoas acha difícil compor uma nova consulta do zero e fácil ajustar uma existente, então ele dá uma vantagem.

A Honeycomb promete uma resolução mais rápida de incidentes. Pode descrever como a integração de logs, métricas e rastros em um tipo de dados unificado ajuda na depuração e resolução de problemas mais rápidas?

Tudo está conectado. Você não precisa adivinhar. Em vez de olhar para esse painel e pensar que ele tem a mesma forma que aquele painel, ou adivinhar que esse pico nas suas métricas deve ser o mesmo que esse pico nos seus logs com base em carimbos de data e hora…. em vez disso, os dados estão todos conectados. Você não precisa adivinhar, você pode simplesmente perguntar.

Os dados são tornados valiosos pelo contexto. A última geração de ferramentas funcionava removendo todo o contexto no momento da gravação; uma vez que você tenha descartado o contexto, você nunca pode recuperá-lo novamente.

Além disso: com logs e métricas, você precisa saber o que está procurando antes de poder encontrá-lo. Isso não é verdade para a observabilidade moderna. Você não precisa saber nada, ou procurar por nada.

Quando você está armazenando esses dados ricos e contextuais, você pode fazer coisas com ele que parecem mágicas. Temos uma ferramenta chamada BubbleUp, onde você pode desenhar uma bolha em torno de qualquer coisa que você acha estranha ou que pode ser interessante, e computamos todas as dimensões dentro da bolha vs fora da bolha, a linha de base, e classificamos e diferençamos. Então você é como “essa bolha é estranha” e imediatamente dizemos, “é diferente em xyz maneiras”. Tanta depuração se resume a “aqui está uma coisa que me importo, mas por que me importo com isso?” Quando você pode identificar imediatamente que é diferente porque essas solicitações estão vindo de dispositivos Android, com esse ID de build particular, usando esse pacote de idioma, nessa região, com esse ID de aplicativo, com uma grande carga útil… agora você provavelmente sabe exatamente o que está errado e por quê.

Não é apenas sobre os dados unificados, embora isso seja uma grande parte disso. É também sobre como lidamos com dados de alta cardinalidade de forma eficaz, como IDs únicos, IDs de carrinho de compras, IDs de aplicativos, primeiros/nomes de última, etc. A última geração de ferramentas não consegue lidar com dados ricos como esse, o que é quase inacreditável quando você pensa sobre isso, porque dados ricos e de alta cardinalidade são os mais valiosos e identificáveis de todos.

Como melhorar a observabilidade se traduz em melhores resultados de negócios?

Essa é uma das outras grandes mudanças da geração passada para a nova geração de ferramentas de observabilidade. No passado, sistemas, aplicativos e dados de negócios estavam todos isolados em ferramentas diferentes. Isso é absurdo — todas as perguntas interessantes que você deseja fazer sobre sistemas modernos têm elementos de todos os três.

A observabilidade não é apenas sobre bugs, ou tempo de inatividade, ou interrupções. É sobre garantir que estamos trabalhando nas coisas certas, que nossos usuários estão tendo uma ótima experiência, que estamos alcançando os resultados de negócios que estamos visando. É sobre construir valor, não apenas operar. Se você não pode ver para onde está indo, você não consegue se mover muito rapidamente e não consegue corrigir o curso muito rapidamente. Quanto mais visibilidade você tiver sobre o que seus usuários estão fazendo com seu código, melhor e mais forte engenheiro você pode ser.

Onde você vê o futuro da observabilidade indo, especialmente em relação aos desenvolvimentos da IA?

A observabilidade está cada vez mais sobre permitir que as equipes conectem laços de feedback apertados e rápidos, para que possam desenvolver rapidamente, com confiança, em produção, e desperdiçar menos tempo e energia.

É sobre conectar os pontos entre resultados de negócios e métodos tecnológicos.

E é sobre garantir que entendamos o software que estamos colocando no mundo. À medida que o software e os sistemas se tornam cada vez mais complexos, e especialmente à medida que a IA está cada vez mais no mix, é mais importante do que nunca que nos responsabilizemos por um padrão humano de compreensão e gerenciamento.

Do ponto de vista da observabilidade, vamos ver níveis crescentes de sofisticação na pipeline de dados — usando aprendizado de máquina e técnicas de amostragem sofisticadas para equilibrar valor vs custo, para manter tanto detalhe quanto possível sobre eventos de outlier e eventos importantes e armazenar resumos do resto de forma barata.

Os fornecedores de IA estão fazendo muitas alegações superaquecidas sobre como podem entender seu software melhor do que você, ou como podem processar os dados e dizer a seus humanos quais ações tomar. De tudo o que eu vi, isso é um sonho caro. Falsos positivos são incrivelmente caros. Não há substituto para entender seus sistemas e seus dados. A IA pode ajudar seus engenheiros com isso! Mas não pode substituir seus engenheiros.

Obrigada pela grande entrevista, leitores que desejam aprender mais devem visitar Honeycomb.