Charity é uma engenheira de operações e fundadora acidental de uma startup na Honeycomb. Antes disso, ela trabalhou na Parse, Fb e Linden Lab em infraestrutura e ferramentas de desenvolvimento, e sempre parecia acabar executando os bancos de dados. Ela é coautora de O'Reilly's Database Reliability Engineering, e ama liberdade de expressão, software program livre e uísque single malt.
Você foi gerente de engenharia de produção no Fb (agora Meta) por mais de 2 anos. Quais foram alguns dos destaques desse período e quais são algumas das principais lições aprendidas com essa experiência?
Trabalhei no Parse, que period um backend para aplicativos móveis, tipo Heroku para dispositivos móveis. Nunca me interessei em trabalhar em uma grande empresa, mas fomos adquiridos pelo Fb. Uma das minhas principais conclusões foi que aquisições são muito, muito difíceis, mesmo nas melhores circunstâncias. O conselho que sempre dou a outros fundadores agora é este: se você vai ser adquirido, certifique-se de ter um patrocinador executivo e pense muito bem se você tem alinhamento estratégico. O Fb adquiriu o Instagram pouco antes de adquirir o Parse, e a aquisição do Instagram não foi nada fácil, mas no ultimate foi muito bem-sucedida porque eles tinham alinhamento estratégico e um patrocinador forte.
Não tive uma vida fácil no Fb, mas sou muito grato pelo tempo que passei lá; não sei se conseguiria começar uma empresa sem as lições que aprendi sobre estrutura organizacional, gestão, estratégia, and so forth. Também me emprestou um pedigree que me tornou atraente para VCs, nenhum dos quais tinha me dado a hora do dia até aquele momento. Estou um pouco irritado com isso, mas ainda assim vou aceitar.
Você poderia compartilhar a história por trás do lançamento do Honeycomb?
Definitivamente. De uma perspectiva arquitetônica, o Parse estava à frente de seu tempo — usávamos microsserviços antes de existirem microsserviços, tínhamos uma camada de dados massivamente fragmentada e, como uma plataforma que atendia mais de um milhão de aplicativos móveis, tínhamos muitos problemas de multilocação realmente complicados. Nossos clientes eram desenvolvedores, e eles estavam constantemente escrevendo e carregando trechos de código arbitrários e novas consultas de, digamos, “qualidade variável” — e nós apenas tínhamos que absorver tudo e fazer funcionar, de alguma forma.
Estávamos na vanguarda de um monte de mudanças que se tornaram populares desde então. Costumava ser que a maioria das arquiteturas eram bem simples e falhavam repetidamente de maneiras previsíveis. Você normalmente tinha uma camada internet, um aplicativo e um banco de dados, e a maior parte da complexidade estava vinculada ao código do seu aplicativo. Então você escreveria verificações de monitoramento para observar essas falhas e construiria painéis estáticos para suas métricas e dados de monitoramento.
Esta indústria viu uma explosão na complexidade arquitetônica nos últimos 10 anos. Nós explodimos o monólito, então agora você tem de vários serviços a milhares de microsserviços de aplicativos. A persistência poliglota é a norma; em vez de “o banco de dados”, é regular ter muitos tipos diferentes de armazenamento, bem como sharding horizontal, camadas de cache, db-per-microservice, enfileiramento e muito 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 muito mais.
A parte difícil costumava ser depurar seu código; agora, a parte difícil é descobrir onde no sistema está o código que você precisa depurar. Em vez de falhar repetidamente de maneiras previsíveis, é mais provável que cada vez que você for chamado, seja sobre algo que você nunca viu antes e pode nunca mais ver.
Esse period o estado em que estávamos no Parse, no Fb. Todos os dias a plataforma inteira estava caindo, e toda vez period algo diferente e novo; um aplicativo diferente chegando ao high 10 no iTunes, um desenvolvedor diferente carregando uma consulta ruim.
Depurar esses problemas do zero é incrivelmente difícil. Com logs e métricas, você basicamente tem que saber o que está procurando antes de encontrar. Mas começamos a alimentar alguns conjuntos de dados em uma ferramenta do FB chamada Scuba, que nos permitiu fatiar e cortar dimensões arbitrárias e dados de alta cardinalidade em tempo actual, e a quantidade de tempo que levamos para identificar e resolver esses problemas do zero caiu como uma pedra, tipo de horas para… minutos? segundos? Não period mais um problema de engenharia, period um problema de suporte. Você poderia simplesmente seguir a trilha de migalhas de pão até a resposta todas as vezes, clique, clique, clique.
Foi alucinante. Essa fonte massiva de incerteza, trabalho, clientes insatisfeitos e páginas às 2 da manhã simplesmente… desapareceu. Só quando Christine e eu saímos do Fb é que percebemos o quanto ele havia transformado a maneira como interagíamos com software program. A ideia de voltar aos velhos tempos de monitoramento de verificações e painéis period simplesmente impensável.
Mas na época, nós honestamente pensamos que isso seria uma solução de nicho — que resolveria um problema que outras plataformas multitenant massivas poderiam ter. Foi só quando estávamos construindo por quase um ano que começamos a perceber que, nossa, isso está realmente se tornando um problema de todos.
Para leitores não familiarizados, o que é especificamente uma plataforma de observabilidade e como ela se diferencia do monitoramento e das métricas tradicionais?
O monitoramento tradicional tem três pilares famosos: métricas, logs e traces. Normalmente, você precisa comprar muitas ferramentas para atender às suas necessidades: log, tracing, APM, RUM, dashboarding, visualização, and so forth. Cada um deles é otimizado para um caso de uso diferente em um formato diferente. Como engenheiro, você se senta no meio deles, tentando entender todos eles. Você percorre os dashboards procurando padrões visuais, copia e cola IDs de logs para traces e vice-versa. É muito reativo e fragmentado, e normalmente você consulta essas ferramentas quando tem um problema — elas são projetadas para ajudar você a operar seu código e encontrar bugs e erros.
A observabilidade moderna tem uma única fonte de verdade; eventos de log estruturados arbitrariamente amplos. Destes eventos, você pode derivar suas métricas, painéis e logs. Você pode visualizá-los ao longo do tempo como um rastro, pode fatiar e cortar, pode ampliar solicitações individuais e reduzir para a visão de longo prazo. Como 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 loops de suggestions poderosos e estreitos que ajudam você a enviar muito valor aos usuários rapidamente, com confiança, e encontrar problemas antes que seus usuários o façam.
Você é conhecido por acreditar que a observabilidade oferece uma única fonte de verdade em ambientes de engenharia. Como a IA se integra a essa visão e quais são seus benefícios e desafios nesse contexto?
Observabilidade é como colocar seus óculos antes de sair correndo pela rodovia. O desenvolvimento orientado a testes (TDD) revolucionou o software program no início dos anos 2000, mas o TDD vem perdendo eficácia quanto mais complexidade está localizada em nossos sistemas em vez de apenas em nosso software program. Cada vez mais, se você deseja obter os benefícios associados ao TDD, você realmente precisa instrumentar seu código e executar algo semelhante ao desenvolvimento orientado a observabilidade, ou ODD, onde você instrumenta conforme avança, implementa rapidamente e, em seguida, olha para seu código em produção através das lentes da instrumentação que você acabou de escrever e se pergunta: “ele está fazendo o que eu esperava que fizesse e mais alguma coisa parece… estranha?”
Testes sozinhos não são suficientes para confirmar que seu código está fazendo o que deveria fazer. Você não sabe disso até vê-lo assar em produção, com usuários reais em infraestrutura actual.
Esse tipo de desenvolvimento — que inclui produção em loops de suggestions rápidos — é (de forma um tanto contraintuitiva) muito mais rápido, fácil e simples do que depender de testes e ciclos de implantação mais lentos. Uma vez que os desenvolvedores tentaram trabalhar dessa forma, eles são notoriamente relutantes em voltar ao modo lento e antigo de fazer as coisas.
O que me anima sobre IA é que quando você está desenvolvendo com LLMs, você tem que desenvolver em produção. A única maneira de derivar um conjunto de testes é primeiro validando seu código em produção e trabalhando de trás para frente. Eu acho que escrever software program apoiado por LLMs será uma habilidade tão comum quanto escrever software program apoiado por MySQL ou Postgres em alguns anos, e minha esperança é que isso arraste engenheiros chutando e gritando para um modo de vida melhor.
Você levantou preocupações sobre o aumento da dívida técnica devido à revolução da IA. Você poderia elaborar sobre os tipos de dívidas técnicas que a IA pode introduzir e como o Honeycomb ajuda a gerenciar ou mitigar essas dívidas?
Estou preocupado com a dívida técnica e, talvez mais importante, com a dívida organizacional. Um dos piores tipos de dívida técnica é quando você tem um software program que não é bem compreendido por ninguém. O que significa que sempre que você tem que estender ou alterar esse código, ou depurá-lo ou consertá-lo, alguém tem que fazer o trabalho duro de aprendê-lo.
E se você colocar um código em produção que ninguém entende, há uma grande probability de que ele não tenha sido escrito para ser compreensível. Um bom código é escrito para ser fácil de ler, entender e estender. Ele usa convenções e padrões, usa nomenclatura e modularização consistentes, ele atinge um equilíbrio entre DRY e outras considerações. A qualidade do código é inseparável de quão fácil é para as pessoas interagirem com ele. Se começarmos a jogar código em produção porque ele compila ou passa em testes, estamos criando um iceberg enorme de problemas técnicos futuros para nós mesmos.
Se você decidiu enviar um código que ninguém entende, o Honeycomb não pode ajudar com isso. Mas se você se importa em enviar um software program limpo e iterável, instrumentação e observabilidade são absolutamente essenciais para esse esforço. Instrumentação é como documentação mais relatórios de estado em tempo actual. Instrumentação é a única maneira de realmente confirmar que seu software program está fazendo o que você espera que ele faça e se comportando da maneira que seus usuários esperam que ele se comporte.
Como a Honeycomb utiliza IA para melhorar a eficiência e a 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 perguntas e ajudá-los a entender o software program que estão construindo. Nossos engenheiros mais seniores dizem que é ótimo para gerar software program que seria muito tedioso ou irritante de escrever, como quando você tem um arquivo YAML gigante para preencher. Também é útil para gerar trechos de código em linguagens que você não costuma usar ou da documentação da API. Por exemplo, você pode gerar alguns exemplos realmente excelentes e utilizáveis de coisas usando os SDKs e APIs da AWS, já que ele foi treinado em repositórios que têm uso actual desse código.
No entanto, sempre que você deixa a IA gerar seu código, você tem que percorrê-lo linha por linha para garantir que ele esteja fazendo a coisa certa, porque ele certamente produzirá lixo regularmente.
Você poderia dar exemplos de como recursos de IA, como seu assistente de consulta ou integração com o Slack, melhoram a colaboração da equipe?
Sim, com certeza. Nosso assistente de consulta é um ótimo exemplo. Usar construtores de consulta é complicado e difícil, mesmo para usuários avançados. Se você tem centenas ou milhares de dimensões em sua telemetria, nem sempre consegue lembrar de improviso como as mais valiosas são chamadas. E até mesmo 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 pure. Como, “quais são os endpoints mais lentos?”, ou “o que aconteceu depois da minha última implantação?” e ele gera uma consulta e coloca você nela. A maioria das pessoas acha difícil compor uma nova consulta do zero e fácil ajustar uma existente, então isso lhe dá uma vantagem.
O Honeycomb promete resolução mais rápida de incidentes. Você pode descrever como a integração de logs, métricas e rastros em um tipo de dado unificado auxilia na depuração e resolução de problemas mais rápidas?
Tudo está conectado. Você não precisa adivinhar. Em vez de ficar olhando que esse painel parece ter o mesmo formato que aquele painel, ou adivinhar que esse pico em suas métricas deve ser o mesmo que esse pico em seus logs com base em carimbos de tempo… em vez disso, os dados estão todos conectados. Você não precisa adivinhar, você pode apenas perguntar.
Os dados se tornam valiosos pelo contexto. A última geração de ferramentas funcionava removendo todo o contexto no momento da gravação; uma vez descartado o contexto, você nunca mais poderá recuperá-lo.
Também: com logs e métricas, você tem que 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.
Ao armazenar esses dados contextuais ricos, você pode fazer coisas com eles que parecem mágica. Temos uma ferramenta chamada BubbleUp, onde você pode desenhar uma bolha ao redor de qualquer coisa que você acha estranha ou pode ser interessante, e nós calculamos todas as dimensões dentro da bolha versus fora da bolha, a linha de base, e as classificamos e diferenciamos. Então você fica tipo “essa bolha é estranha” e nós imediatamente dizemos a você, “é diferente de xyz maneiras”. TANTO da depuração se resume a “aqui está uma coisa com a qual 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 compilação específico, usando esse pacote de idioma, nesta 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 se trata apenas de dados unificados, embora isso seja uma grande parte disso. Também se trata de quão facilmente lidamos com dados de alta cardinalidade, como IDs exclusivos, IDs de carrinho de compras, IDs de aplicativos, nomes/sobrenomes, and so forth. A última geração de ferramentas não consegue lidar com dados ricos como esses, o que é meio inacreditável quando você pensa sobre isso, porque dados ricos e de alta cardinalidade são os dados mais valiosos e identificadores de todos.
Como melhorar a observabilidade se traduz em melhores resultados comerciais?
Esta é 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 eram todos isolados uns dos outros em ferramentas diferentes. Isso é absurdo — toda pergunta interessante que você quer fazer sobre sistemas modernos tem elementos de todos os três.
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 comerciais que almejamos. É sobre construir valor, não apenas operar. Se você não consegue ver para onde está indo, não consegue se mover muito rapidamente e não consegue corrigir o curso muito rápido. 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.
Para onde você vê o futuro da observabilidade, especialmente no que diz respeito aos desenvolvimentos de IA?
A observabilidade tem cada vez mais a ver com permitir que as equipes estabeleçam ciclos de suggestions rápidos e precisos, para que possam se desenvolver rapidamente e com confiança na produção, desperdiçando menos tempo e energia.
Trata-se de conectar os pontos entre resultados comerciais e métodos tecnológicos.
E é sobre garantir que entendamos o software program que estamos colocando no mundo. À medida que software program e sistemas se tornam cada vez mais complexos, e especialmente à medida que a IA está cada vez mais presente, é mais importante do que nunca que nos responsabilizemos por um padrão humano de compreensão e gerenciabilidade.
De uma perspectiva de observabilidade, veremos níveis crescentes de sofisticação no pipeline de dados — usando aprendizado de máquina e técnicas de amostragem sofisticadas para equilibrar valor e custo, para manter o máximo de detalhes possível sobre eventos discrepantes e eventos importantes e armazenar resumos do restante da forma mais barata possível.
Os fornecedores de IA estão fazendo muitas alegações exageradas sobre como eles podem entender seu software program melhor do que você, ou como eles podem processar os dados e dizer aos seus humanos quais ações tomar. De tudo que 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 ela não pode substituir seus engenheiros.
Obrigado pela ótima entrevista. Os leitores que desejarem saber mais devem visitar o Honeycomb.
