Charity Majors, CTO et co-fondatrice de Honeycomb – Série d’entretiens

Charity est une ingénieure en exploitation et fondatrice de startup accidentelle chez Honeycomb. Avant cela, elle a travaillé chez Parse, Facebook (META ) et Linden Lab sur les infrastructures et les outils de développement, et a souvent fini par gérer les bases de données. Elle est co-auteur de l’ouvrage de O’Reilly sur l’ingénierie de la fiabilité des bases de données, et aime la liberté d’expression, les logiciels libres et le scotch single malt.

Vous étiez la responsable de l’ingénierie de production chez Facebook (maintenant Meta) pendant plus de 2 ans, quels étaient certains de vos points forts pendant cette période et quels sont certains de vos enseignements clés tirés de cette expérience ?

J’ai travaillé sur Parse, qui était un backend pour les applications mobiles, un peu comme Heroku pour les mobiles. Je n’avais jamais été intéressée à travailler dans une grande entreprise, mais nous avons été acquis par Facebook. L’une de mes principales conclusions était que les acquisitions sont vraiment, vraiment difficiles, même dans les meilleures circonstances. Le conseil que je donne toujours aux autres fondateurs maintenant est celui-ci : si vous allez être acquis, assurez-vous d’avoir un sponsor exécutif, et réfléchissez bien à savoir si vous avez un alignement stratégique. Facebook a acquis Instagram peu de temps avant d’acquérir Parse, et l’acquisition d’Instagram n’était pas facile, mais elle a finalement été très réussie parce qu’ils avaient un alignement stratégique et un sponsor solide.

Je n’ai pas eu une période facile chez Facebook, mais je suis très reconnaissante pour le temps que j’y ai passé ; je ne sais pas si j’aurais pu créer une entreprise sans les leçons que j’y ai apprises sur la structure organisationnelle, la gestion, la stratégie, etc. Cela m’a également valu une réputation qui m’a rendue attractive aux yeux des VC, qui ne m’avaient pas accordé l’attention jusqu’à ce moment-là. Je suis un peu irritée par cela, mais je l’accepterai.

Pouvez-vous partager l’histoire de la création de Honeycomb ?

Bien sûr. D’un point de vue architectural, Parse était en avance sur son temps – nous utilisions des microservices avant qu’il n’y ait des microservices, nous avions une couche de données massivement fragmentée, et en tant que plateforme servant plus d’un million d’applications mobiles, nous avions beaucoup de problèmes de multilocataires très compliqués. Nos clients étaient des développeurs, et ils écrivaient et téléchargeaient constamment des extraits de code et de nouvelles requêtes de, disons, “qualité variable” – et nous devions tout accepter et faire fonctionner, d’une manière ou d’une autre.

Nous étions à la pointe de tout un tas de changements qui sont depuis devenus mainstream. Il était une fois que la plupart des architectures étaient assez simples, et qu’elles échouaient de manière répétitive et prévisible. Vous aviez généralement une couche Web, une application et une base de données, et la plupart de la complexité était liée au code de l’application. Vous écriviez donc des vérifications de surveillance pour surveiller ces échecs, et construisez des tableaux de bord statiques pour vos métriques et vos données de surveillance.

Cet industrie a connu une explosion de complexité architecturale au cours des 10 dernières années. Nous avons fait exploser le monolithe, donc maintenant vous avez entre plusieurs services et des milliers de microservices d’application. La persistance polyglotte est la norme ; au lieu de “la base de données”, il est normal d’avoir de nombreux types de stockage différents, ainsi que des couches de mise en cache, des bases de données par microservice, des files d’attente, etc. En plus de cela, vous avez des conteneurs hébergés côté serveur, des services et des plateformes tiers, du code sans serveur, du stockage de blocs, etc.

La partie difficile était de déboguer votre code ; maintenant, la partie difficile est de déterminer où dans le système se trouve le code que vous devez déboguer. Au lieu de échouer de manière répétitive et prévisible, il est plus probable que chaque fois que vous êtes appelé, c’est à propos de quelque chose que vous n’avez jamais vu auparavant et que vous ne verrez peut-être jamais à nouveau.

C’était l’état dans lequel nous nous trouvions à Parse, sur Facebook. Chaque jour, l’ensemble de la plateforme était en panne, et chaque fois, c’était quelque chose de différent et de nouveau ; une application différente qui atteignait le top 10 sur iTunes, un développeur différent qui téléchargeait une requête incorrecte.

Déboguer ces problèmes à partir de zéro est incroyablement difficile. Avec les journaux et les métriques, vous devez基本alement savoir ce que vous cherchez avant de pouvoir le trouver. Mais nous avons commencé à alimenter certains jeux de données dans un outil de Facebook appelé Scuba, qui nous a permis de découper et de trancher sur des dimensions arbitraires et des données à haute cardinalité en temps réel, et le temps qu’il nous a fallu pour identifier et résoudre ces problèmes à partir de zéro a chuté comme une pierre, comme de heures à… minutes ? secondes ? Ce n’était même plus un problème d’ingénierie, c’était un problème de support. Vous pouviez simplement suivre la piste de miettes jusqu’à la réponse chaque fois, clic-clic-clic.

C’était époustouflant. Cette énorme source d’incertitude et de peine et de clients mécontents et de pages à 2 heures du matin… a disparu. Ce n’est que lorsque Christine et moi avons quitté Facebook que nous nous sommes rendu compte à quel point cela avait transformé la façon dont nous interagissions avec les logiciels. L’idée de revenir aux mauvaises vieilles méthodes de surveillance et de tableaux de bord était tout simplement impensable.

Mais à l’époque, nous pensions honnêtement que c’était une solution de niche – qu’elle résolvait un problème que d’autres grandes plateformes multilocataires pourraient avoir. Ce n’est que lorsque nous avons construit pendant presque un an que nous avons commencé à réaliser que, oh wow, c’est en fait devenu un problème pour tout le monde.

Pour les lecteurs qui ne sont pas familiers, qu’est-ce qu’une plateforme d’observabilité et comment diffère-t-elle de la surveillance et des métriques traditionnelles ?

La surveillance traditionnelle a trois piliers : les métriques, les journaux et les traces. Vous devez généralement acheter de nombreux outils pour répondre à vos besoins : journalisation, traçage, APM, RUM, tableaux de bord, visualisation, etc. Chacun de ces outils est optimisé pour un cas d’utilisation différent et dans un format différent. En tant qu’ingénieur, vous vous situez au milieu de tout cela, essayant de donner un sens à tout cela. Vous parcourrez les tableaux de bord à la recherche de modèles visuels, vous copiez-collez des ID de logs à des traces et vice versa. C’est très réactif et pièce par pièce, et généralement vous faites référence à ces outils lorsque vous avez un problème – ils sont conçus pour vous aider à exploiter votre code et à trouver des bogues et des erreurs.

L’observabilité moderne a une source de vérité unique ; des événements de journal structurés arbitrairement larges. À partir de ces événements, vous pouvez dériver vos métriques, vos tableaux de bord et vos journaux. Vous pouvez les visualiser dans le temps sous forme de trace, vous pouvez découper et trancher, vous pouvez zoomer sur des requêtes individuelles et sur la vue à long terme. Parce que tout est connecté, vous n’avez pas à sauter d’outil en outil, en devinant ou en vous fiant à votre intuition. L’observabilité moderne n’est pas seulement à propos de la façon dont vous exploitez vos systèmes, mais également de la façon dont vous développez votre code. C’est le substrat qui vous permet de connecter des boucles de rétroaction puissantes et serrées qui vous aident à livrer beaucoup de valeur aux utilisateurs rapidement, avec confiance, et à trouver des problèmes avant que vos utilisateurs ne le fassent.

Vous êtes connue pour croire que l’observabilité offre une source de vérité unique dans les environnements d’ingénierie. Comment l’IA s’intègre-t-elle dans cette vision, et quels sont ses avantages et défis dans ce contexte ?

L’observabilité est comme mettre vos lunettes avant de vous lancer sur l’autoroute. Le développement piloté par les tests (TDD) a révolutionné les logiciels au début des années 2000, mais le TDD a perdu de son efficacité à mesure que la complexité est située dans nos systèmes et non plus seulement dans notre logiciel. De plus en plus, si vous voulez obtenir les avantages associés au TDD, vous devez en fait instrumenter votre code et effectuer une sorte de développement piloté par l’observabilité, ou ODD, où vous instrumentez au fur et à mesure, vous déployez rapidement, puis vous regardez votre code en production à travers le prisme de l’instrumentation que vous venez d’écrire et vous vous demandez : “est-ce qu’il fait ce que je m’attendais à ce qu’il fasse, et y a-t-il autre chose qui semble… étrange ?”

Les tests seuls ne suffisent pas à confirmer que votre code fait ce qu’il est censé faire. Vous ne savez pas cela jusqu’à ce que vous l’ayez regardé cuire en production, avec de vrais utilisateurs sur une infrastructure réelle.

Ce type de développement – qui inclut la production dans des boucles de rétroaction rapides – est (un peu contre-intuitivement) beaucoup plus rapide, plus facile et plus simple que de compter sur des tests et des cycles de déploiement plus lents. Une fois que les développeurs ont essayé de travailler de cette façon, ils sont célèbres pour être réticents à revenir à la vieille méthode lente de faire les choses.

Ce qui m’excite à propos de l’IA, c’est que lorsque vous développez avec des LLM, vous devez développer en production. La seule façon de dériver un ensemble de tests est de valider d’abord votre code en production et de travailler à rebours. Je pense que l’écriture de logiciels avec des LLM sera une compétence aussi courante que l’écriture de logiciels avec MySQL ou Postgres dans quelques années, et j’espère que cela entraînera les ingénieurs à reculons dans une meilleure vie.

Vous avez exprimé des inquiétudes concernant l’accumulation de la dette technique due à la révolution de l’IA. Pouvez-vous élaborer sur les types de dettes techniques que l’IA peut introduire et comment Honeycomb aide à gérer ou à atténuer ces dettes ?

Je m’inquiète à la fois de la dette technique et, peut-être plus important encore, de la dette organisationnelle. L’un des pires types de dettes techniques est lorsque vous avez un logiciel qui n’est pas bien compris par quiconque. Ce qui signifie que chaque fois que vous devez étendre ou modifier ce code, ou le déboguer ou le corriger, quelqu’un doit faire le travail difficile d’apprendre.

Et si vous mettez du code en production que personne ne comprend, il y a une très bonne chance que ce code n’ait pas été écrit pour être compréhensible. Un bon code est écrit pour être facile à lire et à comprendre et à étendre. Il utilise des conventions et des modèles, il utilise des noms et une modularisation cohérents, il équilibre DRY et d’autres considérations. La qualité du code est inséparable de la facilité avec laquelle les gens peuvent interagir avec lui. Si nous commençons simplement à jeter du code en production parce qu’il compile ou passe les tests, nous créons un énorme iceberg de problèmes techniques futurs pour nous-mêmes.

Si vous avez décidé de livrer du code que personne ne comprend, Honeycomb ne peut pas vous aider avec cela. Mais si vous vous souciez de livrer un logiciel propre et itératif, l’instrumentation et l’observabilité sont absolument essentielles à cet effort. L’instrumentation est comme la documentation plus la signalisation de l’état en temps réel. L’instrumentation est la seule façon de confirmer vraiment que votre logiciel fait ce que vous vous attendez à ce qu’il fasse, et se comporte de la manière dont vos utilisateurs s’y attendent.

Comment Honeycomb utilise-t-elle l’IA pour améliorer l’efficacité et l’efficience des équipes d’ingénierie ?

Nos ingénieurs utilisent l’IA beaucoup à l’interne, en particulier CoPilot. Nos ingénieurs plus juniors rapportent utiliser ChatGPT chaque jour pour répondre à des questions et les aider à comprendre les logiciels qu’ils construisent. Nos ingénieurs plus seniors disent que c’est génial pour générer du code qui serait très fastidieux ou ennuyeux à écrire, comme lorsqu’il faut remplir un grand fichier YAML. C’est également utile pour générer des extraits de code dans des langages que vous n’utilisez pas habituellement, ou à partir de la documentation de l’API. Par exemple, vous pouvez générer des exemples vraiment géniaux et utilisables à partir des SDK et des API AWS, puisqu’il a été formé sur des référentiels qui ont une utilisation réelle de ce code.

Cependant, chaque fois que vous laissez l’IA générer votre code, vous devez passer par chaque ligne pour vous assurer qu’il fait la bonne chose, car il hallucinera régulièrement des déchets.

Pouvez-vous fournir des exemples de la façon dont les fonctionnalités alimentées par l’IA, comme votre assistant de requête ou votre intégration Slack, améliorent la collaboration d’équipe ?

Oui, bien sûr. Notre assistant de requête est un excellent exemple. Utiliser des générateurs de requêtes est compliqué et difficile, même pour les utilisateurs avancés. Si vous avez des centaines ou des milliers de dimensions dans votre télémétrie, vous ne pouvez pas toujours vous rappeler de quelles dimensions les plus précieuses sont appelées. Et même les utilisateurs avancés oublient les détails de la façon de générer certains types de graphiques.

Donc notre assistant de requête vous permet de poser des questions en langage naturel. Comme “quels sont les points de terminaison les plus lents ?”, ou “qu’est-ce qui s’est passé après mon dernier déploiement ?” et il génère une requête et vous y insère. La plupart des gens trouvent difficile de composer une nouvelle requête à partir de zéro et facile de modifier une requête existante, donc cela vous donne un avantage.

Honeycomb promet une résolution plus rapide des incidents. Pouvez-vous décrire comment l’intégration des journaux, des métriques et des traces dans un type de données unifié aide à une débogage et à une résolution de problèmes plus rapides ?

Tout est connecté. Vous n’avez pas à deviner. Au lieu de regarder si ce tableau de bord a la même forme que ce tableau de bord, ou de deviner que cette augmentation de vos métriques doit être la même que cette augmentation de vos journaux en fonction des horodatages… au lieu de cela, les données sont toutes connectées. Vous n’avez pas à deviner, vous pouvez simplement demander.

Les données sont rendues précieuses par le contexte. La dernière génération d’outils fonctionnait en éliminant tout le contexte au moment de l’écriture ; une fois que vous avez éliminé le contexte, vous ne pouvez jamais le récupérer.

Aussi : avec les journaux et les métriques, vous devez savoir ce que vous cherchez avant de pouvoir le trouver. Ce n’est pas vrai de l’observabilité moderne. Vous n’avez pas à savoir quoi que ce soit, ou à chercher quoi que ce soit.

Lorsque vous stockez ces données contextuelles riches, vous pouvez faire des choses avec elles qui ressemblent à de la magie. Nous avons un outil appelé BubbleUp, où vous pouvez dessiner une bulle autour de tout ce que vous pensez être étrange ou qui pourrait être intéressant, et nous calculons toutes les dimensions à l’intérieur de la bulle par rapport à l’extérieur de la bulle, la référence, et nous les classons et les différencions. Donc vous êtes comme “cette bulle est étrange” et nous vous disons immédiatement “elle est différente de telle manière”. Beaucoup de débogage se résume à “voici une chose que je m’intéresse, mais pourquoi m’y intéresse-je ?” Lorsque vous pouvez immédiatement identifier que c’est différent parce que ces requêtes proviennent de dispositifs Android, avec cette version de construction, en utilisant ce pack de langues, dans cette région, avec cette ID d’application, avec une grande charge utile… à ce stade, vous savez probablement exactement ce qui ne va pas et pourquoi.

Ce n’est pas seulement à propos des données unifiées, bien que cela soit une grande partie de cela. C’est également à propos de la façon dont nous traitons les données à haute cardinalité de manière fluide, comme les ID uniques, les ID de panier d’achat, les ID d’application, les noms et prénoms, etc. La dernière génération d’outils ne peut pas gérer des données riches comme celles-ci, ce qui est incroyable lorsqu’on y pense, car les données riches et à haute cardinalité sont les plus précieuses et les plus identifiables de toutes.

Comment l’amélioration de l’observabilité se traduit-elle par de meilleurs résultats commerciaux ?

Ceci est l’une des autres grandes transitions de la génération précédente à la nouvelle génération d’outils d’observabilité. Dans le passé, les systèmes, les applications et les données commerciales étaient tous cloisonnés dans des outils différents. C’est absurde – chaque question intéressante que vous voulez poser sur les systèmes modernes a des éléments de tous les trois.

L’observabilité n’est pas seulement à propos des bogues, des temps d’arrêt, des pannes. C’est à propos de garantir que nous travaillons sur les bonnes choses, que nos utilisateurs ont une expérience agréable, que nous réalisons les résultats commerciaux que nous visons. C’est à propos de la création de valeur, et non seulement de l’exploitation. Si vous ne pouvez pas voir où vous allez, vous ne pouvez pas avancer très rapidement et vous ne pouvez pas corriger le cap très rapidement. Plus vous avez de visibilité sur ce que vos utilisateurs font avec votre code, plus vous pouvez être un meilleur ingénieur.

Où voyez-vous l’avenir de l’observabilité aller, en particulier en ce qui concerne les développements de l’IA ?

L’observabilité est de plus en plus à propos de permettre aux équipes de connecter des boucles de rétroaction serrées et rapides, afin qu’elles puissent développer rapidement, avec confiance, en production, et gaspiller moins de temps et d’énergie.

C’est à propos de connecter les points entre les résultats commerciaux et les méthodes technologiques.

Et c’est à propos de garantir que nous comprenons les logiciels que nous mettons dans le monde. À mesure que les logiciels et les systèmes deviennent de plus en plus complexes, et en particulier à mesure que l’IA est de plus en plus présente, il est plus important que jamais que nous nous tenions à un standard humain de compréhension et de gestion.

Depuis une perspective d’observabilité, nous allons voir des niveaux croissants de sophistication dans le pipeline de données – en utilisant l’apprentissage automatique et des techniques d’échantillonnage sophistiquées pour équilibrer la valeur et le coût, pour conserver autant de détails que possible sur les événements aberrants et les événements importants et stocker des résumés du reste de manière aussi économique que possible.

Les fournisseurs d’IA font des affirmations surchauffées sur la façon dont ils peuvent comprendre votre logiciel mieux que vous, ou sur la façon dont ils peuvent traiter les données et dire à vos humains quels actions à prendre. De tout ce que j’ai vu, c’est un rêve coûteux. Les faux positifs sont incroyablement coûteux. Il n’y a pas de substitut à la compréhension de vos systèmes et de vos données. L’IA peut aider vos ingénieurs avec cela ! Mais elle ne peut pas remplacer vos ingénieurs.

Je vous remercie pour cette grande interview, les lecteurs qui souhaitent en savoir plus peuvent visiter Honeycomb.