Charity Majors, CTO & Co-Founder at Honeycomb – Wywiad

Charity jest inżynierem operacyjnym i przypadkowym założycielem startupu w Honeycomb. Przed tym pracowała w Parse, Facebooku i Linden Lab na infrastrukturze i narzędziach deweloperskich, i zawsze wydawało się, że kończyła jako osoba odpowiedzialna za bazy danych. Jest współautorką książki O’Reilly’ego “Database Reliability Engineering“, i kocha wolność słowa, wolne oprogramowanie i szkocką whisky single malt.

Była Pani kierownikiem inżynierii produkcji w Facebooku (obecnie Meta) przez ponad 2 lata, jakie były Pani największe osiągnięcia w tym okresie i jakie są Pani najważniejsze wnioski z tego doświadczenia?

Pracowałam nad Parse, które było backendem dla aplikacji mobilnych, trochę jak Heroku dla mobilnych. Nigdy nie byłem zainteresowana pracą w dużej firmie, ale zostaliśmy przejęci przez Facebooka. Jednym z moich najważniejszych wniosków było to, że przejęcia są naprawdę, naprawdę trudne, nawet w najlepszych okolicznościach. Rada, którą zawsze daję innym założycielom, brzmi: jeśli zostaniesz przejęty, upewnij się, że masz sponsora wykonawczego i zastanów się, czy masz strategiczne wykorzystanie. Facebook (META ) przejął Instagram nieco przed przejęciem Parse, a przejęcie Instagrama nie było łatwe, ale ostatecznie było bardzo udane, ponieważ mieli strategiczne wykorzystanie i silnego sponsora.

Nie miałam łatwego czasu w Facebooku, ale jestem bardzo wdzięczna za czas spędzony tam; nie wiem, czy mogłabym założyć firmę bez lekcji, które nauczyłam się o strukturze organizacyjnej, zarządzaniu, strategii itp. Dało mi to także renomę, która sprawiła, że stałam się atrakcyjna dla inwestorów, żaden z nich nie dał mi szansy, dopóki nie pracowałam w Facebooku. Jestem trochę zirytowana tym, ale i tak to przyjmuję.

Czy mógłaby Pani opowiedzieć o historii powstania Honeycomb?

Oczywiście. Z architektonicznego punktu widzenia, Parse był firmą, która była przed swoim czasem – używaliśmy mikrousług, zanim jeszcze istniały mikrousługi, mieliśmy ogromnie rozproszoną warstwę danych i jako platforma obsługująca ponad milion aplikacji mobilnych, mieliśmy wiele bardzo skomplikowanych problemów z wielokrotnym najmem. Nasi klienci byli deweloperami, a oni ciągle pisali i uploadowali arbitralne fragmenty kodu i nowe zapytania o, powiedzmy, “różnej jakości” – i musieliśmy to wszystko przyjąć i sprawić, by działało, jakoś.

Byliśmy na czele wielu zmian, które od tego czasu stały się powszechne. Dawniej większość architektur była dość prosta i awaryjna w przewidywalny sposób. Zwykle mieliśmy warstwę sieciową, aplikację i bazę danych, a większość złożoności była związana z kodem aplikacji. Więc pisałeś sprawdziany monitorujące, aby szukać awarii, i konstruowałeś statyczne pulpity dla swoich metryk i danych monitorujących.

Przemysł ten doświadczył eksplozji złożoności architektonicznej w ciągu ostatnich 10 lat. Zniszczyliśmy monolit, więc teraz masz od kilku usług do tysiąca mikrousług aplikacji. Wielojęzyczna persistence jest normą; zamiast “bazy danych” jest normalne, że masz wiele różnych typów magazynowania, a także warstwy buforowania, db-per-microservice, kolejkowanie i więcej. Na dodatek masz kontenery hostowane po stronie serwera, usługi i platformy stron trzecich, kod serwerowy, magazynowanie bloków i więcej.

Trudna część polegała dawniej na debugowaniu kodu; teraz trudna część polega na tym, aby znaleźć w systemie kod, który musisz debugować. Zamiast awarii w przewidywalny sposób, bardziej prawdopodobne jest to, że za każdym razem, gdy dostajesz powiadomienie, jest to coś, czego nie widziałeś wcześniej i może nigdy więcej nie zobaczysz.

To był stan, w jakim byliśmy w Parse, na Facebooku. Każdego dnia cała platforma szła na dno, a za każdym razem było to coś innego i nowego; inna aplikacja trafiająca na pierwsze miejsce na liście iTunes, inny deweloper uploadujący zły zapytanie.

Debugowanie tych problemów od podstaw jest niesamowicie trudne. Z logami i metrykami musisz znać to, czego szukasz, zanim będziesz mógł to znaleźć. Ale zaczęliśmy podawać niektóre zestawy danych do narzędzia Facebooka o nazwie Scuba, które pozwalało nam na cięcie i łączenie na dowolnych wymiarach i danych o wysokiej kardynalności w czasie rzeczywistym, a czas, jaki potrzebowaliśmy, aby zidentyfikować i rozwiązać te problemy od podstaw, spadł jak kamień, jak z godzin na… minuty? sekundy? Nie było to już problemem inżynierskim, ale problemem wsparcia. Mogłeś po prostu śledzić ślady chleba, aby znaleźć odpowiedź za każdym razem, klikając.

Było to oszałamiające. Ten ogromny źródło niepewności i trudu i niezadowolonych klientów i powiadomień o 2 nad ranem… po prostu zniknęło. Nie było to aż do momentu, gdy Christine i ja opuściliśmy Facebooka, że zrozumieliśmy, jak bardzo zmieniło to sposób, w jaki wchodziliśmy w interakcje z oprogramowaniem. Pomysł powrotu do starych, złych czasów monitoringu i pulpitów był po prostu niewyobrażalny.

Ale w tym czasie szczerze myślałam, że to będzie rozwiązanie nisze – że rozwiązuje problem, z którym mogą się spotkać inne ogromne platformy wielokrotne. Nie było to aż do momentu, gdy budowaliśmy przez prawie rok, że zaczęliśmy zdawać sobie sprawę, że, och, tak naprawdę to staje się problemem wszystkich.

Dla czytelników, którzy nie są zaznajomieni, co konkretnie jest platformą obserwowalności i jak różni się od tradycyjnego monitoringu i metryk?

Tradycyjny monitoring słynie z trzech filarów: metryk, logów i śladów. Zwykle musisz kupić wiele narzędzi, aby spełnić swoje potrzeby: logowanie, śledzenie, APM, RUM, dashboarding, wizualizacja itp. Każde z nich jest zoptymalizowane pod kątem innego przypadku użycia w innym formacie. Jako inżynier, siedzisz pośrodku tych wszystkich rzeczy, próbując zrozumieć je wszystkie. Przeglądasz pulpity, szukając wzorców wizualnych, kopiujesz i wklejasz identyfikatory z logów do śladów i z powrotem. Jest to bardzo reaktywne i fragmentaryczne, a zwykle odwołujesz się do tych narzędzi, gdy masz problem – są one zaprojektowane, aby pomóc ci operować twoim kodem i znaleźć błędy i awarie.

Współczesna obserwowalność ma jedną prawdę; arbitralnie szerokie, ustrukturyzowane zdarzenia logowe. Z tych zdarzeń możesz wywnioskować swoje metryki, pulpity i logi. Możesz je wizualizować w czasie jako ślad, możesz ciąć i łączyć, możesz przybliżyć do poszczególnych żądań i oddalić do dalekosiężnego widoku. Ponieważ wszystko jest połączone, nie musisz skakać z narzędzia do narzędzia, zgadywać ani polegać na intuicji. Współczesna obserwowalność nie dotyczy tylko tego, jak operujesz swoimi systemami, ale także tego, jak rozwijasz swój kod. Jest to podłoże, które pozwala ci podłączyć potężne, zwarte pętle sprzężenia zwrotnego, które pomagają ci wysyłać wiele wartości do użytkowników szybko, z zaufaniem i znajdować problemy, zanim twoi użytkownicy je znajdą.

Jest Pani znana z przekonania, że obserwowalność oferuje jedną prawdę w środowiskach inżynierskich. Jak AI wpisuje się w tę wizję, a jakie są jej korzyści i wyzwania w tym kontekście?

Obserwowalność jest jak założenie okularów przed ruszeniem w drogę. Rozwój sterowany testami (TDD) rewolucjonizował oprogramowanie na początku lat 2000, ale TDD traci na skuteczności, im więcej złożoności jest zlokalizowanej w naszych systemach, a nie tylko w naszym oprogramowaniu. Coraz częściej, jeśli chcesz uzyskać korzyści związane z TDD, musisz naprawdę zainstrumentować swój kod i wykonać coś w rodzaju obserwowalności sterowanej przez rozwój, czyli ODD, gdzie instrumentujesz, gdy idziesz, wdrażasz szybko, a potem spoglądasz na swój kod w produkcji przez pryzmat instrumentacji, którą właśnie napisałeś, i pytasz się: “czy robi to, co powinien robić, i czy coś innego wygląda… dziwnie?”

Testy same w sobie nie są wystarczające, aby potwierdzić, że twój kod robi to, co powinien. Nie wiesz, dopóki nie obejrzysz go w produkcji, z prawdziwymi użytkownikami na prawdziwej infrastrukturze.

Typ rozwoju, który obejmuje produkcję w szybkich pętlach sprzężenia zwrotnego, jest (trochę przeciwnie do oczekiwań) znacznie szybszy, łatwiejszy i prostszy niż poleganie na testach i wolniejszych cyklach wdrażania. Gdy tylko deweloperzy spróbują pracować w ten sposób, są słynni z niechęci do powrotu do starego, wolnego sposobu robienia rzeczy.

To, co mnie ekscytuje w AI, to to, że gdy rozwijasz z LLM, musisz rozwijać w produkcji. Jedynym sposobem, aby wywnioskować zestaw testów, jest najpierw walidacja twojego kodu w produkcji i pracowanie wstecz. Myślę, że pisanie oprogramowania wspieranego przez LLM będzie tak powszechnym umiejętnością, jak pisanie oprogramowania wspieranego przez MySQL lub Postgres w ciągu kilku lat, a moja nadzieja jest taka, że to pociągnie inżynierów za sobą do lepszego życia.

Zgłosiła Pani obawy dotyczące narastającego długu technicznego z powodu rewolucji AI. Czy mógłaby Pani wyjaśnić, jakie typy długu technicznego AI może wprowadzić i jak Honeycomb pomaga w zarządzaniu lub łagodzeniu tych długów?

Martwię się o dług techniczny i, być może jeszcze bardziej, o dług organizacyjny. Jednym z najgorszych rodzajów długu technicznego jest to, gdy masz oprogramowanie, które nie jest dobrze zrozumiane przez nikogo. Co oznacza, że za każdym razem, gdy musisz rozszerzyć lub zmienić ten kod, lub debugować lub naprawić go, ktoś musi wykonać ciężką pracę, aby go nauczyć.

I gdy wprowadzasz kod do produkcji, który nikt nie rozumie, istnieje duże prawdopodobieństwo, że nie został napisany, aby był zrozumiały. Dobry kod jest napisany, aby być łatwym do czytania i zrozumienia oraz rozwijania. Używa konwencji i wzorców, używa spójnych nazw i modularizacji, szuka równowagi między DRY a innymi rozważaniami. Jakość kodu jest nieodłączna od tego, jak łatwo ludzie mogą z nim współpracować. Jeśli po prostu zaczniesz wrzucać kod do produkcji, bo kompiluje się lub przechodzi testy, tworzysz ogromny lodowiec przyszłych problemów technicznych dla siebie.

Jeśli zdecydujesz się na wysłanie kodu, który nikt nie rozumie, Honeycomb nie może pomóc w tym. Ale jeśli dbasz o wysyłanie czystego, iterowalnego oprogramowania, instrumentacja i obserwowalność są absolutnie niezbędne do tego wysiłku. Instrumentacja jest jak dokumentacja plus raportowanie stanu w czasie rzeczywistym. Instrumentacja jest jedynym sposobem, aby potwierdzić, że twój kod robi to, co powinien, i zachowuje się tak, jak twoi użytkownicy oczekują.

Jak Honeycomb wykorzystuje AI do poprawy wydajności i skuteczności zespołów inżynierskich?

Nasi inżynierowie korzystają z AI bardzo często wewnętrznie, zwłaszcza z CoPilot. Nasi młodsi inżynierowie mówią, że używają ChatGPT każdego dnia, aby odpowiedzieć na pytania i pomóc im zrozumieć oprogramowanie, które budują. Nasi starsi inżynierowie mówią, że jest to wspaniałe do generowania oprogramowania, które byłoby bardzo nużące lub irytujące do napisania, jak na przykład gdy masz ogromny plik YAML do wypełnienia. Jest to również przydatne do generowania fragmentów kodu w językach, których nie używasz zwykle, lub z dokumentacji API. Na przykład możesz wygenerować naprawdę dobre, użyteczne przykłady rzeczy, korzystając z SDK i API AWS, ponieważ zostało przeszkolone na repozytoriach, które mają prawdziwe użycie tego kodu.

Jednak za każdym razem, gdy pozwolisz AI wygenerować twój kod, musisz przejść przez niego linia po linii, aby upewnić się, że robi to, co powinien, bo z pewnością wygeneruje głupoty regularnie.

Czy mógłaby Pani podać przykłady, jak funkcje zasilane przez AI, takie jak asystent zapytań lub integracja ze Slack, ulepszają współpracę zespołową?

Tak, na pewno. Nasz asystent zapytań jest wspaniałym przykładem. Używanie konstruktorów zapytań jest skomplikowane i trudne, nawet dla użytkowników zaawansowanych. Jeśli masz setki lub tysiące wymiarów w swoich danych telemetrycznych, nie możesz zawsze pamiętać, jak nazywają się najcenniejsze z nich. I nawet użytkownicy zaawansowani zapominają szczegółów, jak generować pewne rodzaje wykresów.

Nasz asystent zapytań pozwala ci zadawać pytania przy użyciu języka naturalnego. Na przykład “jakie są najwolniejsze punkty końcowe?” lub “co się stało po moim ostatnim wdrożeniu?” i generuje zapytanie i wprowadza cię w nie. Większość ludzi uważa, że składanie nowego zapytania od podstaw jest trudne i łatwiej jest je tylko dostosować.

Honeycomb obiecuje szybsze rozwiązywanie incydentów. Czy mógłaby Pani opisać, jak integracja logów, metryk i śladów w jeden, zunifikowany typ danych pomaga w szybszym debugowaniu i rozwiązywaniu problemów?

Wszystko jest połączone. Nie musisz zgadywać. Zamiast przyglądać się, czy ten pulpit wygląda tak samo jak tamten pulpit, czy zgadywać, że ten szczyt w twoich metrykach musi być taki sam jak ten szczyt w twoich logach na podstawie znaczników czasu… zamiast tego dane są wszystkie połączone. Nie musisz zgadywać, możesz po prostu spytać.

Dane są warte dzięki kontekstowi. Poprzednie pokolenie narzędzi działało przez usuwanie wszystkiego kontekstu w czasie zapisu; gdy już raz usunąłeś kontekst, nie możesz go już odzyskać.

Również: z logami i metrykami musisz wiedzieć, czego szukasz, zanim będziesz mógł to znaleźć. To nie jest prawdą w przypadku nowoczesnej obserwowalności. Nie musisz wiedzieć niczego, nie musisz szukać niczego.

Gdy przechowujesz te bogate dane kontekstowe, możesz z nimi robić rzeczy, które wydają się magią. Mamy narzędzie o nazwie BubbleUp, gdzie możesz narysować bąbel wokół czegokolwiek, co uważasz za dziwne lub co może być interesujące, i obliczamy wszystkie wymiary wewnątrz bąbla w porównaniu z zewnętrznymi, podstawą, sortujemy i różnicujemy. Więc możesz powiedzieć “ten bąbel jest dziwny” i my natychmiast powiemy ci, “różni się w xyz sposobach”. Tak wiele debugowania sprowadza się do “oto coś, o co mi chodzi, ale dlaczego mi chodzi?” Gdy możesz natychmiast zidentyfikować, że jest to inaczej, ponieważ te żądania pochodzą z urządzeń z Androidem, z tym konkretnym identyfikatorem kompilacji, używając tego pakietu językowego, w tym regionie, z tym identyfikatorem aplikacji, z dużym ładunkiem… w tym momencie prawdopodobnie już wiesz, co jest nie tak i dlaczego.

To nie tylko kwestia zunifikowanego typu danych – choć to jest ogromna część tego. To również kwestia tego, jak łatwo radzimy sobie z danymi o wysokiej kardynalności, takimi jak unikalne identyfikatory, identyfikatory koszyka, identyfikatory aplikacji, imiona i nazwiska, w regionie, z dużym ładunkiem… poprzednie pokolenie narzędzi nie może obsłużyć takich bogatych danych, co jest niezbyt wiarygodne, gdy się o tym myśli, ponieważ bogate dane o wysokiej kardynalności są najcenniejszymi i najbardziej identyfikującymi danymi.

Jak poprawa obserwowalności przekłada się na lepsze wyniki biznesowe?

To jest jeden z innych dużych zmian od poprzedniego pokolenia do nowego pokolenia narzędzi obserwowalności. W przeszłości systemy, aplikacje i dane biznesowe były oddzielone od siebie w różne narzędzia. Jest to absurdalne – każde interesujące pytanie, które chcesz zadać nowoczesnym systemom, ma elementy wszystkich trzech.

Obserwowalność nie dotyczy tylko błędów, awarii lub przestojów. Chodzi o to, aby upewnić się, że pracujemy nad odpowiednimi rzeczami, że nasi użytkownicy mają dobry опыт, że osiągamy wyniki biznesowe, które chcemy osiągnąć. Chodzi o budowanie wartości, a nie tylko operowanie. Jeśli nie możesz zobaczyć, dokąd idziesz, nie możesz poruszać się szybko i nie możesz szybko skorygować kursu. Im więcej widoczności masz w tym, co robią twoi użytkownicy z twoim kodem, tym lepszym i silniejszym inżynierem możesz być.

Gdzie widzi Pani przyszłość obserwowalności, zwłaszcza w odniesieniu do rozwoju AI?

Obserwowalność staje się coraz bardziej umożliwiająca zespołom podłączenie szybkich, zwartych pętlek sprzężenia zwrotnego, aby mogły rozwijać się szybko, z zaufaniem, w produkcji, i marnować mniej czasu i energii.

To jest o tym, aby połączyć kropki między wynikami biznesowymi a metodami technicznymi.

I jest to o tym, aby upewnić się, że rozumiemy oprogramowanie, które wypuszczamy na świat. Im bardziej złożone staje się oprogramowanie i systemy, a zwłaszcza gdy AI jest coraz bardziej obecne, tym bardziej ważne jest, abyśmy trzymali się ludzkiego standardu zrozumiałości i zarządzali naszymi systemami.

Pod względem obserwowalności będziemy widzieć coraz bardziej zaawansowane poziomy w potoku danych – używając uczenia maszynowego i zaawansowanych technik próbkowania, aby zrównoważyć wartość z kosztem, aby zachować jak najwięcej szczegółów o wyjątkowych zdarzeniach i ważnych zdarzeniach i przechowywać podsumowania reszty tanio.

Producentów AI robią wiele przesadzonych twierdzeń o tym, jak mogą lepiej zrozumieć twoje oprogramowanie niż ty sam. Z tego, co widziałam, jest to drogi sen. Fałszywe pozytywy są niesamowicie kosztowne. Nie ma substytutu dla zrozumienia twoich systemów i twoich danych. AI może pomóc twoim inżynierom w tym! Ale nie może ich zastąpić. Dziękuję za wspaniały wywiad, czytelnicy, którzy chcą dowiedzieć się więcej, powinni odwiedzić Honeycomb.