Charity Majors, CTO & Co-Founder la Honeycomb – Interviu în serie

Charity este inginer de operațiuni și fondator accidental de startup la Honeycomb. Înainte de aceasta, a lucrat la Parse, Facebook (META ) și Linden Lab pe infrastructură și instrumente pentru dezvoltatori și a ajuns întotdeauna să ruleze bazele de date. Ea este co-autoarea cărții Ingineria fiabilității bazelor de date de la O’Reilly și îi place libertatea de exprimare, software-ul gratuit și scotch-ul de malt singur.

Ai fost manager de inginerie de producție la Facebook (acum Meta) pentru mai mult de 2 ani, ce au fost unele dintre realizările tale din această perioadă și care sunt unele dintre principalele tale concluzii din această experiență?

Am lucrat la Parse, care era o bază pentru aplicații mobile, ceva similar cu Heroku pentru mobile. Nu am fost niciodată interesat să lucrez la o companie mare, dar am fost achiziționat de Facebook. Una dintre principalele mele concluzii a fost că achizițiile sunt foarte, foarte grele, chiar și în cele mai bune circumstanțe. Sfătuiesc mereu alți fondatori să aibă un sponsor executiv și să se gândească foarte bine la alinierea strategică. Facebook a achiziționat Instagram nu mult înainte de a achiziționa Parse, și achiziția Instagram a fost cu adevărat de succes, deoarece au avut aliniere strategică și un sponsor puternic.

Nu am avut o perioadă ușoară la Facebook, dar sunt foarte recunoscător pentru timpul petrecut acolo; nu cred că aș fi putut să încep o companie fără lecțiile învățate despre structura organizațională, management, strategie etc. Mi-a oferit și o reputație care m-a făcut atractiv pentru investitori, niciunul dintre care nu mi-a acordat atenție până în acel moment. Sunt un pic iritat de asta, dar o să o iau.

Poți să ne spui povestea din spatele lansării Honeycomb?

Sigur. Din punct de vedere arhitectural, Parse a fost înaintea timpului său — am folosit microservicii înainte ca microserviciile să existe, am avut un strat de date masiv shardat și, ca platformă care servea peste un milion de aplicații mobile, am avut multe probleme complicate de multi-tenancy. Clienții noștri erau dezvoltatori, și ei scriau și încărcau constant coduri și interogări noi de, să zicem, “calitate variabilă” — și trebuia să le facem să funcționeze cumva.

Am fost în avangarda unei mulțimi de schimbări care au devenit mainstream. Arhitecturile obișnuite erau destul de simple și eşuau în mod repetat în moduri previzibile. Aveai un strat web, o aplicație și o bază de date, și cea mai mare parte a complexității era legată de codul aplicației. Așa că scriai verificări de monitorizare pentru a urmări aceste eșecuri și construiai dashboard-uri statice pentru datele de monitorizare și metrici.

Industria a văzut o explozie de complexitate arhitecturală în ultimii 10 ani. Am distrus monolitele, așa că acum ai de la câteva servicii la mii de microservicii de aplicații. Persistența poliglotă este norma; în loc de “baza de date” este normal să ai mai multe tipuri de stocare, precum și shardare orizontală, straturi de cache, db-per-microservice, cozi și multe altele. Pe lângă asta, ai containere găzduite pe server, cod serverless, stocare de blocuri și multe altele.

Partea grea era să debughezi codul tău; acum, partea grea este să afli unde în sistemul este codul pe care trebuie să-l debughezi. În loc să eşuezi în mod repetat în moduri previzibile, este mult mai probabil ca, de fiecare dată când primești o pagină, este vorba de ceva pe care nu l-ai văzut niciodată înainte și pe care nu-l vei mai vedea niciodată.

Aceasta era starea noastră la Parse, pe Facebook. În fiecare zi, întreaga platformă se prăbușea, și de fiecare dată era ceva diferit și nou; o aplicație care ajungea în top 10 pe iTunes, un dezvoltator care încărca o interogare proastă.

Debuggingul acestor probleme de la zero este incredibil de greu. Cu jurnale și metrici, practic trebuie să știți ce căutați înainte să-l puteți găsi. Dar am început să alimentăm unele seturi de date într-un instrument FB numit Scuba, care ne-a permis să tăiem și să sfâșiem pe dimensiuni arbitrare și date cu cardinalitate ridicată în timp real, și timpul necesar pentru a identifica și rezolva aceste probleme de la zero a scăzut ca o piatră, de la ore la… minute? secunde? Nu a mai fost o problemă de inginerie; a fost o problemă de suport. Puteai pur și simplu să urmezi urmele până la răspuns, de fiecare dată, click, click, click.

A fost uluitor. Acea sursă imensă de incertitudine și muncă și clienți nefericiți și pagini la 2 dimineața… a dispărut. Nu a fost până când Christine și eu am părăsit Facebook că am realizat cât de mult a transformat modul în care interacționăm cu software-ul. Ideea de a reveni la vechile zile proaste de monitorizare și dashboard-uri a fost de neconceput.

Dar, la momentul respectiv, am crezut sincer că aceasta va fi o soluție de nișă — că rezolvă o problemă pe care alte platforme masive multitenant ar putea să o aibă. Nu a fost până când am construit timp de aproape un an că am început să realizăm că, wow, aceasta devine o problemă pentru toată lumea.

Pentru cititorii care nu sunt familiarizați, ce este specific o platformă de observabilitate și cum se diferențiază de monitorizarea tradițională și metrici?

Monitorizarea tradițională are cele trei piloni: metrici, jurnale și urme. De obicei, trebuie să cumpărați multe instrumente pentru a satisface nevoile dvs.: jurnalizare, urmărire, APM, RUM, dashboard-ing, vizualizare etc. Fiecare dintre acestea este optimizat pentru un anumit caz de utilizare într-un format diferit. Ca inginer, stai în mijlocul acestor instrumente, încercând să dai sens tuturor. Treci prin dashboard-uri căutând modele vizuale, copiezi și lipiți ID-uri din jurnale în urme și înapoi. Este foarte reactiv și fragmentat, și de obicei vă referiți la aceste instrumente atunci când aveți o problemă — sunt proiectate pentru a vă ajuta să operați codul și să găsiți bug-uri și erori.

Observabilitatea modernă are o singură sursă de adevăr; evenimente de jurnal structurate, arbitrar de largi. Din aceste evenimente puteți deriva metrici, dashboard-uri și jurnale. Puteți vizualiza-le în timp ca o urmă, puteți tăia și sfâșia, puteți mări imaginea la solicitări individuale și micșorați-o la vedere lungă. Deoarece totul este conectat, nu trebuie să săriți de la un instrument la altul, ghicind sau bazându-vă pe intuiție. Observabilitatea modernă nu este doar despre cum operați sistemele dvs., ci și despre cum dezvoltați codul dvs. Este substratul care vă permite să conectați bucle de feedback puternice și strânse care vă ajută să livrați multă valoare utilizatorilor dvs. rapid, cu încredere, și să găsiți problemele înainte ca utilizatorii dvs. să o facă.

Ești cunoscut pentru convingerea ta că observabilitatea oferă o singură sursă de adevăr în mediile de inginerie. Cum se integrează AI în această viziune, și care sunt beneficiile și provocările sale în acest context?

Observabilitatea este ca și cum ai pune ochelarii înainte de a te arunca pe autostradă. Dezvoltarea condusă de teste (TDD) a revoluționat software-ul la începutul anilor 2000, dar TDD a început să piardă eficacitatea pe măsură ce complexitatea a fost localizată în sistemele noastre, și nu doar în software-ul nostru. În mod tot mai mare, dacă doriți să obțineți beneficiile asociate cu TDD, trebuie să instrumentați codul dvs. și să efectuați ceva asemănător cu dezvoltarea condusă de observabilitate, sau ODD, unde instrumentați pe măsură ce mergeți, depuneți rapid, apoi priviți codul dvs. în producție prin lentila instrumentației pe care tocmai ați scris-o și întrebați-vă: “se comportă așa cum mă așteptam să se comporte, și este ceva… ciudat?”

Testele singure nu sunt suficiente pentru a confirma că codul dvs. face ceea ce ar trebui să facă. Nu știți asta până nu l-ați urmărit în producție, cu utilizatori reali pe infrastructură reală.

Acest tip de dezvoltare — care include producția în bucle de feedback rapide — este (într-un mod oarecum contraintuitiv) mult mai rapid, mai ușor și mai simplu decât să vă bazați pe teste și cicluri de implementare mai lente. Odată ce dezvoltatorii au încercat să lucreze în acest fel, sunt faimoși pentru faptul că nu vor să se întoarcă la modul vechi și lent de a face lucrurile.

Ce mă entuziasmează despre AI este că, atunci când dezvoltați cu LLM-uri, trebuie să dezvoltați în producție. Singurul mod în care puteți deriva un set de teste este prin validarea codului dvs. în producție și lucrați înapoi. Cred că scrierea de software sprijinită de LLM-uri va fi la fel de comună ca scrierea de software sprijinită de MySQL sau Postgres în câțiva ani, și sper că aceasta îi va trage pe ingineri într-un mod mai bun de viață.

Ai ridicat preocupări cu privire la datoria tehnică în creștere din cauza revoluției AI. Poți să explici care sunt tipurile de datorii tehnice pe care AI le poate introduce și cum Honeycomb ajută la gestionarea sau mitigarea acestor datorii?

Sunt îngrijorat atât de datoria tehnică, cât și, poate mai important, de datoria organizațională. Unul dintre cele mai rele tipuri de datorii tehnice este atunci când aveți software care nu este bine înțeles de nimeni. Care înseamnă că, de fiecare dată când trebuie să extindeți sau să modificați acel cod, sau să-l debugați sau să-l reparați, cineva trebuie să facă munca grea de a-l învăța.

Și dacă puneți cod în producție pe care nimeni nu-l înțelege, există o șansă foarte bună că nu a fost scris pentru a fi înțeles. Un cod bun este scris pentru a fi ușor de citit și înțeles și extins. Folosește convenții și modele, folosește denumiri și modularizare consistente, echilibrează DRY și alte considerații. Calitatea codului este inseparabilă de cât de ușor este pentru oameni să interacționeze cu el. Dacă începeți să aruncați cod în producție pentru că se compilează sau trece testele, creați o mulțime de probleme tehnice viitoare pentru dvs.

Dacă ați decis să livrați cod pe care nimeni nu-l înțelege, Honeycomb nu vă poate ajuta cu asta. Dar dacă vă pasă de a livra software curat și iterabil, instrumentația și observabilitatea sunt absolut esențiale pentru efortul dvs. Instrumentația este ca documentația plus raportarea stării în timp real. Instrumentația este singurul mod în care puteți confirma cu adevărat că software-ul dvs. face ceea ce vă așteptați să facă, și se comportă așa cum utilizatorii dvs. se așteaptă să se comporte.

Cum utilizează Honeycomb AI pentru a îmbunătăți eficiența și eficacitatea echipelor de ingineri?

Inginerii noștri folosesc AI mult intern, mai ales CoPilot. Inginerii noștri mai juniori raportează că folosesc ChatGPT în fiecare zi pentru a răspunde la întrebări și pentru a-i ajuta să înțeleagă software-ul pe care îl construiesc. Inginerii noștri mai seniori spun că este grozav pentru generarea de software care ar fi foarte plictisitor sau enervant de scris, cum ar fi atunci când aveți un fișier YAML imens de completat. Este, de asemenea, util pentru generarea de fragmente de cod în limbaje pe care nu le folosiți de obicei, sau din documentația API-ului. Ca, de exemplu, puteți genera exemple foarte bune și utilizabile de cod utilizând SDK-urile și API-urile AWS, deoarece a fost antrenat pe depozite care au utilizări reale ale acelui cod.

Cu toate acestea, de fiecare dată când lăsați AI să genereze codul dvs., trebuie să treceți prin el linie cu linie pentru a vă asigura că face ceea ce ar trebui să facă, pentru că va “halucina” gunoaie în mod regulat.

Poți să ne oferi exemple de moduri în care caracteristicile bazate pe AI, cum ar fi asistentul dvs. de interogare sau integrarea cu Slack, îmbunătățesc colaborarea în echipă?

Da, sigur. Asistentul nostru de interogare este un exemplu grozav. Utilizarea constructorilor de interogări este complicată și grea, chiar și pentru utilizatorii avansați. Dacă aveți sute sau mii de dimensiuni în telemetrie, nu puteți întotdeauna să vă amintiți ce sunt cele mai valoroase numite. Și chiar utilizatorii avansați uită detaliile despre cum să genereze anumite tipuri de grafice.

Deci asistentul nostru de interogare vă permite să puneți întrebări utilizând limbaj natural. Ca, de exemplu, “care sunt cele mai lente puncte de capăt?” sau “ce s-a întâmplat după ultima mea implementare?” și generează o interogare și vă introduce în ea. Majoritatea oamenilor găsesc dificil să compună o nouă interogare de la zero și ușor să ajusteze una existentă, așa că vă oferă un avantaj.

Honeycomb promite o rezolvare mai rapidă a incidentelor. Poți să descrii cum integrarea jurnalelor, metricilor și urmelor într-un tip de date unificat ajută la o rezolvare mai rapidă a problemelor și la o rezolvare mai rapidă a problemelor?

Totul este conectat. Nu trebuie să ghiciți. În loc să priviți că acest dashboard pare a fi aceeași formă ca și acel dashboard, sau să ghiciți că acest vârf în metricile dvs. trebuie să fie același ca și acest vârf în jurnalele dvs. pe baza marcajelor de timp… în loc de toate astea, datele sunt toate conectate. Nu trebuie să ghiciți, puteți pur și simplu să întrebați.

Datele sunt făcute valoroase de context. Ultima generație de instrumente a funcționat prin îndepărtarea tuturor contextelor la momentul scrierii; odată ce ați aruncat contextul, nu-l puteți recupera niciodată.

De asemenea: cu jurnale și metrici, trebuie să știți ce căutați înainte să-l puteți găsi. Acest lucru nu este valabil pentru observabilitatea modernă. Nu trebuie să știți nimic, sau să căutați nimic.

Când stocați aceste date contextuale bogate, puteți face lucruri cu ele care par a fi magie. Avem un instrument numit BubbleUp, unde puteți desena o bulă în jurul a oricărui lucru pe care îl considerați ciudat sau care ar putea fi interesant, și calculăm toate dimensiunile din interiorul bulei versus exteriorul bulei, baza de referință, și le sortați și le diferențiați. Așa că sunteți “această bulă este ciudată” și imediat vă spunem “este diferită în moduri xyz”. Atât de multe debugări se reduc la “am un lucru pe care îl pasă, dar de ce îl pasă?” Când puteți identifica imediat că este diferit pentru că aceste solicitări provin de la dispozitive Android, cu această versiune de construcție, utilizând acest pachet de limbă, în această regiune, cu această ID de aplicație, cu o încărcătură mare… până în acest moment, probabil că știți exact ce este în neregulă și de ce.

Nu este doar despre datele unificate, deși acesta este un aspect enorm. Este, de asemenea, despre modul în care gestionăm cu ușurință datele cu cardinalitate ridicată, cum ar fi ID-uri unice, ID-uri de coș de cumpărături, ID-uri de aplicații, nume și prenume, în regiuni, cu o încărcătură mare… Generația anterioară de instrumente nu poate gestiona date bogate de acest fel, ceea ce este incredibil când vă gândiți la asta, deoarece datele bogate și cu cardinalitate ridicată sunt cele mai valoroase și identificabile.

Cum se traduce îmbunătățirea observabilității în rezultate comerciale mai bune?

Acesta este unul dintre celelalte schimbări majore de la generația anterioară la noua generație de instrumente de observabilitate. În trecut, sistemele, aplicațiile și datele de afaceri erau toate izolate în instrumente separate. Acest lucru este absurd — fiecare întrebare interesantă pe care doriți să o puneți despre sistemele moderne are elemente ale tuturor acestora.

Observabilitatea nu este doar despre bug-uri, sau downtime, sau închideri. Este despre a vă asigura că lucrați la lucrurile potrivite, că utilizatorii dvs. au o experiență grozavă, că atingeți rezultatele comerciale pe care le visați. Este despre construirea valorii, nu doar despre operare. Dacă nu puteți vedea unde mergeți, nu puteți să vă deplasați foarte repede și nu puteți corecta cursul foarte repede. Cu cât aveți mai multă vizibilitate asupra a ceea ce fac utilizatorii dvs. cu codul dvs., cu atât mai bun și mai puternic inginer puteți fi.

Unde vezi viitorul observabilității ducându-se, mai ales în ceea ce privește dezvoltările AI?

Observabilitatea este din ce în ce mai mult despre conectarea echipelor pentru a crea bucle de feedback rapide, astfel încât să poată dezvolta rapid, cu încredere, în producție, și să nu irosescă timp și energie.

Este despre conectarea punctelor dintre rezultatele comerciale și metodele tehnologice.

Și este despre a vă asigura că înțelegeți software-ul pe care îl lansați în lume. Pe măsură ce software-ul și sistemele devin din ce în ce mai complexe, și mai ales pe măsură ce AI devine din ce în ce mai integrat, este mai important ca oricând să vă țineți contabilizați la un standard uman de înțelegere și gestionare.

În ceea ce privește observabilitatea, vom vedea niveluri tot mai mari de sofisticare în pipeline-ul de date — utilizând tehnici de învățare automată și de eșantionare sofisticate pentru a echilibra valoarea și costul, pentru a păstra cât mai multe detalii despre evenimentele outlier și despre evenimentele importante și pentru a stoca rezumate ale restului în mod cât mai ieftin posibil.

Producătorii de AI fac multe afirmații supraîncălzite despre modul în care pot înțelege software-ul dvs. mai bine decât dvs., sau despre modul în care pot procesa datele și vă pot spune ce acțiuni să întreprindeți. Din tot ceea ce am văzut, acesta este un vis scump. Falsele pozitive sunt incredibil de costisitoare. Nu există înlocuitor pentru înțelegerea sistemelor și a datelor dvs. AI poate ajuta inginerii dvs. cu asta! Dar nu poate înlocui inginerii dvs.

Mulțumim pentru acest interviu grozav, cititorilor care doresc să afle mai multe despre Honeycomb.