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

Charity on ops-insinööri ja vahingossa startup- perustaja Honeycombissa. Ennen tätä hän työskenteli Parsessa, Facebookissa ja Linden Labissa infrastruktuurin ja kehittäjätyökalujen parissa, ja hän usein päätyi johtamaan tietokantoja. Hän on yksi O’Reillyn Database Reliability Engineering -kirjan kirjoittajista, ja hän rakastaa vapautta, vapaata ohjelmistoa ja yksinvalmistettua viskiä.

Olit tuotannon insinöörien johtaja Facebookissa (nyk. Meta) yli 2 vuoden ajan, mitkä olivat joitain korkeimpia kohokohtia tästä ajasta ja mitkä ovat joitain tärkeimmistä opetuksista tästä kokemuksesta?

Työskentelin Parsessa, joka oli taustajärjestelmä mobiilisoftwarelle, jonkinlainen Heroku mobiilille. En ollut kiinnostunut työskentelemästä suuressa yrityksessä, mutta meidät hankittiin Facebookiin. Yksi tärkeimmistä opetuksistani oli, että yritysostot ovat todella, todella vaikeita, jopa parhaimmillaan. Neuvoni aina muille perustajille on, että jos olet ostamassa yritystä, varmista, että sinulla on johtaja, ja mieti todella tarkkaan, onko sinulla strategista linjaa ja vahvaa sponsoria. Facebook (META ) osti Instagramin vain hieman ennen kuin se osti Parsen, ja Instagram-kauppa ei ollut helppo, mutta se oli lopulta hyvin onnistunut, koska heillä oli strategista linjaa ja vahvaa sponsoria.

En käyttänyt helppoa aikaa Facebookissa, mutta olen hyvin kiitollinen ajasta, jonka vietin siellä; en tiedä, olisiniko voinut perustaa yritystä ilman oppeja, joita opin siellä organisaatiosta, johtamisesta, strategiasta jne. Se myös antoi minulle maineen, joka teki minusta houkuttelevan VCs:lle, joista kukaan ei ollut antanut minulle aikaa ennen sitä. Olen vähän ärsyyntynyt tästä, mutta otan sen kuitenkin vastaan.

Voitko kertoa Honeycombin perustamisen tarinan?

Toki. Arkkitehtonisesta näkökulmasta Parse oli aikaansa edellä – käytimme mikropalveluita ennen kuin mikropalveluita oli, meillä oli massiivisesti jaettu tietokantakerros, ja meillä oli paljon hyvin monimutkaisia monen vuokraajan ongelmia. Asiakkaamme olivat kehittäjiä, ja he kirjoittivat ja lataivat jatkuvasti uusia koodinpätkiä ja uusia kyselyjä, joista jotkut olivat, sanotaanko, “vaihtelevaa laatua” – ja meidän piti ottaa se kaikki vastaan ja saada se toimimaan jotenkin.

Olhimme edelläkävijöitä joukossa muutoksia, jotka ovat sittemmin tulleet yleisiksi. Arkkitehtuureja, joissa oli yksinkertainen web-kerros, sovellus ja tietokanta, ja suurin osa monimutkaisuudesta oli sidottu sovelluskoodeihin. Kirjoitimme valvontatarkistuksia vikojen havaitsemiseksi, ja rakensimme statiset dashboardeja metriikoille ja valvontadatalle.

Tämä ala on kokenut räjähdysmäisen arkkitehtuuri-monimutkaisuuden kasvun viimeisen 10 vuoden aikana. Räjäytimme monoliitin, joten nyt sinulla on joko useita palveluita tai tuhansia sovellusmikropalveluita. Polyglot persistence on normi; sen sijaan, että “tietokanta” on normaali, on normaalia, että sinulla on useita eri tietotyyppejä sekä vaakasuorat jakautumiset, välimuistit, tietokanta kussakin mikropalvelussa, jonotus, ja niin edelleen. Sen lisäksi sinulla on palvelinpuolen isännöidyt kontit, kolmannen osapuolen palvelut ja alustat, serverless-koodi, lohko-tallennus, ja niin edelleen.

Vaikea osa oli aiemmin koodin virheenkorjaus; nyt vaikea osa on selvittää, missä järjestelmässä koodi on, jonka haluat virheenkorjata. Sen sijaan, että järjestelmä epäonnistuu toistuvasti ennustettavilla tavoilla, on todennäköisempää, että jokainen kerta, kun saat hälytyksen, on jotain, mitä et ole koskaan nähnyt aiemmin eikä ehkä koskaan näe uudelleen.

Virheiden korjaaminen alusta alkaen on hullunhauskaa. Logeilla ja metriikoilla sinun on tiedettävä, mitä etsit, ennen kuin voit löytää sen. Mutta kun aloimme syöttämään joitain tietojoukkoja Facebookin työkaluun nimeltä Scuba, joka salli meidän leikata ja viilata mitä tahansa ulottuvuuksia ja korkean kardinaliteetin dataa reaaliajassa, aika, joka kului ongelmien tunnistamiseen ja ratkaisemiseen alusta alkaen, laski kuin kivi, kuin tuntia … minuutteja? sekunteja? Se ei ollut enää insinöörien ongelma, se oli tuki-ongelma. Voit vain seurata polun jäljillä vastaukseen joka kerta, klikkaa klikkaa.

Se oli mieltävaikuttavaa. Tämä valtava epävarmuuden ja vaivan ja epäonnistuneiden asiakkaiden ja kello 2 aamuyön hälytyksen lähde … katosi. Se ei ollut, kunnes Christine ja minä lähdemme Facebookista, että tajusimme, kuinka paljon se oli muuttanut tapaa, jolla vuorovaikutimme ohjelmistojen kanssa. Ajatus siitä, että palataan vanhaan tapaan valvontatarkistuksiin ja dashboardeihin, oli ajatuksena, jota ei voinut edes ajatella.

Mutta silloin ajattelimme, että tämä on vain niukka ratkaisu – se ratkaisee ongelman, jonka muut massiiviset monen vuokraajan alustat saattavat kohtaamaan. Se ei ollut, kunnes olimme rakentaneet lähes vuoden ajan, että aloimme tajuta, että voi voi, tämä on todella kaikkien ongelma.

Mitä on havaittavuusjärjestelmä, ja miten se eroaa perinteisestä valvonnasta ja metriikoista?

Perinteinen valvonta on kuuluisa kolmesta pilarista: metriikoista, lohkoista ja jäljityksestä. Yleensä sinun on ostettava useita työkaluja, jotta voit tyydyttää tarpeesi: lokitallennus, jäljitys, APM, RUM, dashboarding, visualisointi jne. Kukin näistä on optimoitu eri käyttötarkoitukseen eri muodossa. Insinööri istuu näiden välimaastossa, yrittäen ymmärtää kaikkea.

Moderni havaittavuus on yksittäinen totuuden lähde; mielivaltaisen laajat, rakenteelliset lokitapahtumat. Näistä tapahtumista voit johtaa metriikkasi, dashboardeja ja lokit. Voit visualisoida ne ajan myötä jäljityksenä, voit leikata ja viilata, voit zoomata yksittäisiin pyynnöksiin ja ulos pitkään näkymään. Koska kaikki on kytketty toisiinsa, sinun ei tarvitse hypätä työkalusta toiseen, arvailla tai luottaa intuition. Moderni havaittavuus ei ole vain siitä, miten sinä operoit järjestelmissäsi, vaan myös siitä, miten sinä kehität koodiasi. Se on substraatti, joka mahdollistaa voimakkaat, tiukat palaute-silmukat, jotka auttavat sinua toimittamaan paljon arvoa käyttäjille nopeasti, varmasti ja löytämään ongelmat ennen kuin käyttäjät.

Olet tunnettu uskomuksestasi, että havaittavuus tarjoaa yksittäisen totuuden lähteen insinöörien ympäristöissä. Miten AI liittyy tähän näkemykseen, ja mitkä ovat sen hyödyt ja haasteet tässä asiayhteydessä?

Havaittavuus on kuin lasien pukeminen ennen kuin lähdet ajamaan valtatielle. Testien ohjattu kehitys (TDD) vallankumous kehittyi ohjelmistossa 2000-luvun alussa, mutta TDD on menettänyt tehokkuuttaan, mitä enemmän monimutkaisuutta on järjestelmissämme eikä vain ohjelmistossamme. Yhä useammin, jos haluat saada TDD:hen liittyvät hyödyt, sinun on todella instrumentoitava koodisi ja suoritettava jonkinlainen havaittavuusohjattu kehitys, tai ODD, jossa instrumentoit mennessäsi, otat nopeasti ja katselet koodiasi tuotannossa instrumentoinnin kautta, jonka äsken kirjoitit, ja kysyt itseltäsi: “Onko se tekemässä sitä, minkä odotin, ja näkyykö siinä jotain … outoa?”

Testit yksin eivät riitä vahvistamaan, että koodisi tekee sitä, minkä sen on tarkoitus tehdä. Et tiedä sitä, kunnes olet katsellut sitä tuotannossa, oikeilla käyttäjillä, oikealla infrastruktuurilla.

Tämänlainen kehitys – joka sisältää tuotannon nopeissa palaute-silmukoissa – on (jonkin verran vastoin odotuksia) paljon nopeampi, helpompi ja yksinkertaisempi kuin riippuminen testistä ja hitaammista käyttöönottojaksoista. Kun kehittäjät ovat kokeilleet työskentelemistä tämänkaltaisesti, he ovat kuuluisasti haluttomia palaamaan vanhaan, hitaampaan tapaan tekemiseen.

Se, mikä minua innostaa AI:sta, on, että kun kehität LLM:ien kanssa, sinun on kehittävä tuotannossa. Ainoa tapa, jolla voit johtaa joukon testejä, on johtaa koodisi tuotannossa ja työskennellä taaksepäin. Luulen, että ohjelmiston kirjoittaminen LLM:ien kanssa tulee olemaan yhtä yleinen taito kuin ohjelmiston kirjoittaminen MySQL:llä tai Postgressilla, ja toivoni on, että tämä raahaa insinöörit potkuin ja itkuin parempaan elämään.

Olet nostanut esille teknisen velan kasvamisen AI-vallankumouksen vuoksi. Voitko selittää, mitä tyyppisiä teknisiä velkoja AI voi aiheuttaa ja miten Honeycomb auttaa niiden hallinnassa tai lieventämisessä?

Olen huolissani sekä teknisestä velasta että, ehkä enemmän, organisaatiosta. Yksi huonoimmista teknisen velan lajeista on, kun sinulla on ohjelmistoa, jota kukaan ei ymmärrä. Mikä tahansa kerta, kun sinun on täytettävä, muutettava tai korjattava koodi, joku on tehtävä vaikea työ sen oppimiseksi.

Ja jos laitat koodin tuotantoon, jota kukaan ei ymmärrä, on hyvin todennäköistä, että se ei ollut kirjoitettu ymmärrettäväksi. Hyvä koodi on kirjoitettu helposti luettavaksi ja ymmärrettäväksi ja laajennettavaksi. Se käyttää konventioita ja malleja, se käyttää johdonmukaista nimeämistä ja modulaarista ja se tasapainottaa DRY:n ja muita huomioon otettavia seikkoja. Koodin laatu on erottamaton siitä, kuinka helppoa on ihmisille vuorovaikuttaa sen kanssa. Jos aloitat laittamaan koodia tuotantoon, koska se käännetyy tai läpäisee testit, luot valtavan tulevaisuuden teknisen ongelman itsellesi.

Jos olet päättänyt laittaa koodia tuotantoon, jota kukaan ei ymmärrä, Honeycomb ei voi auttaa siinä. Mutta jos haluat laittaa puhdasta, iteroitavaa ohjelmistoa, instrumentointi ja havaittavuus ovat ehdottomasti välttämättömiä sille pyrkimykselle. Instrumentointi on kuin dokumentaatio plus reaaliaikainen tilan raportointi. Instrumentointi on ainoa tapa, jolla voit vahvistaa, että ohjelmistosi tekee sitä, minkä odotit, ja käyttäytyy siten, miten käyttäjät odottavat.

Miten Honeycomb hyödyntää AI:ta parantamaan insinööritiimien tehokkuutta ja tehokkuutta?

Meidän insinöörit käyttävät AI:ta paljon sisäisesti, erityisesti CoPilottiä. Meidän nuoremmat insinöörit kertovat käyttävänsä ChatGPT:ä joka päivä vastaamaan kysymyksiin ja auttamaan heitä ymmärtämään ohjelmistoa, jonka he rakentavat. Meidän vanhemmat insinöörit sanovat, että se on loistava generoimaan ohjelmistoa, joka olisi hyvin tylsää tai ärsyttävää kirjoittaa, kuten kun sinulla on valtava YAML-tiedosto täytettäväksi. Se on myös hyödyllistä generoimaan koodin paloja kielillä, joita et yleensä käytä, tai API-dokumentaatiosta. Kuten voit generoida erittäin hyviä, käytettäviä esimerkkejä asioiden käytöstä AWS-SDK:iden ja API:iden kanssa, koska se on koulutettu repositorioissa, joissa on todellista käyttöä kyseisestä koodista.

Kuitenkin, aina kun annat AI:lle generoida koodiasi, sinun on käydävä sen läpi rivi riviltä, jotta voit varmistaa, että se tekee oikean asian, koska se absoluuttisesti hallusinoi roskaa säännöllisesti.

Voitko antaa esimerkkejä siitä, miten AI-pohjaiset ominaisuudet, kuten kyselyavustajasi tai Slack-integraationne, parantavat tiimien yhteistyötä?

Kyllä. Kyselyavustajamme on hyvä esimerkki. Kyselyjen rakentaminen on monimutkaista ja vaikeaa, jopa valmiudelle. Jos sinulla on satoja tai tuhansia ulottuvuuksia telemetriissasi, et välttämättä muista aina, mitkä arvokkaimmat niistä ovat, ja miten niitä generoidaan. Kyselyavustajamme antaa sinun kysyä kysymyksiä luonnollisella kielellä. Kuten “mitkä ovat hitaimmat päätepisteet?” tai “mitä tapahtui viimeisen käyttöönottoni jälkeen?” ja se generoi kyselyn ja laskee sinut siihen. Useimmat ihmiset löytävät sen helpommaksi muokata olemassa olevaa kyselyä kuin luoda uusi alusta alkaen, joten se antaa sinulle etulyöntiaseman.

Honeycomb lupailee nopeampaa vikojen ratkaisemista. Voitko kuvata, miten lokien, metriikkojen ja jäljitysten yhdistäminen yhdenmukaiseen tietotyyppiin auttaa nopeammissa vikojen etsinnässä ja ratkaisemisessa?

Kaikki on kytketty toisiinsa. Et tarvitse arvata. Sen sijaan, että tarkkailet, että tämä dashboard näyttää samalta kuin tuo dashboard, tai arvaat, että tämä metriikkojen nousu on sama kuin tämä lokien nousu aikaleimojen perusteella … sen sijaan data on kaikki kytketty toisiinsa. Et tarvitse arvata, voit vain kysyä.

Data on arvokasta kontekstin vuoksi. Edellinen sukupolvi työkaluja toimi poistamalla kaiken kontekstin kirjoittamisen aikana; kun olet heittänyt kontekstin pois, et voi koskaan saada sitä takaisin.

Lisäksi: lokien ja metriikkojen kanssa sinun on tiedettävä, mitä etsit, ennen kuin voit löytää sen. Tämä ei ole totta modernista havaittavuudesta. Et tarvitse tietää mitään, tai etsiä mitään.

Kun tallennat tätä rikasta kontekstuaalista dataa, voit tehdä asioita, jotka tuntuvat magialta. Meillä on työkalu nimeltä BubbleUp, jossa voit piirtää kuplan ympärille mitä tahansa, mitä luulet outona tai mielenkiintoisena, ja laskemme kaikki ulottuvuudet kuplan sisällä ja ulkopuolella, perusviivan, ja lajitamme ja eroamme niitä. Joten voit sanoa “tämä kupla on outo” ja me sanomme välittömästi, “se on erilainen näissä xy-tavoissa”. Niin paljon vikojen etsintää johtuu siitä, että “tämä asia minua kiinnostaa, mutta miksi minua kiinnostaa?” Kun voit välittömästi tunnistaa, että se on erilainen, koska ne pyynnöt tulevat Android-laitteista, tämän rakennusnumeron kanssa, käyttäen tätä kielipakettia, tässä alueessa, tämän sovelluksen ID:llä, suurella kuormalla … sinä luultavasti tiedät jo täsmälleen, mitä on vikana ja miksi.

Se ei ole vain yhdenmukaisen datan asia – se on myös siitä, miten helposti me hallitsemme korkean kardinaliteetin dataa, kuten yksilöllisiä ID:itä, ostoskori-ID:itä, sovellus-ID:itä, etu- ja sukunimiä, jne. Edellinen sukupolvi työkaluja ei voi käsitellä rikasta dataa, mikä on melkein uskomatonta, kun ajattelet sitä, että rikas, korkea kardinaliteetin data on arvokkainta ja määrittävintä dataa.

Miten havaittavuuden parantaminen kääntyy paremmiksi liiketoimintatuloksi?

Tämä on yksi suurimmista muutoksista edellisestä sukupolvesta uuteen havaittavuustyökaluihin. Aiemmin järjestelmät, sovellukset ja liiketoimintadata olivat erillisiä työkaluissa. Tämä on absurdia – jokainen mielenkiintoinen kysymys, jonka haluat kysyä modernista järjestelmästä, sisältää elementtejä kaikista kolmesta.

Havaittavuus ei ole vain vikojen tai downtimeista tai keskeytyksistä. Se on varmistamisesta, että työmme on oikein, että käyttäjämme ovat saavuttamassa hyvää kokemusta, että saavutamme liiketoimintatavoitteemme. Se on arvon luomisesta, ei vain toiminnasta. Jos et voi nähdä, minne olet menossa, et voi liikkua nopeasti ja et voi korjata kurssia nopeasti. Mitä enemmän näet, mitä käyttäjäsi tekevät koodillasi, sitä parempi ja vahvempi insinööri voit olla.

Mihin suuntaan näet havaittavuuden tulevan kehittyvän, erityisesti AI-kehitysten osalta?

Havaittavuus on yhä enemmän siitä, että tiimit voivat kytkeä tiukat, nopeat palaute-silmukat, jotta he voivat kehittää nopeasti, varmasti, tuotannossa, ja hävitä vähemmän aikaa ja energiaa.

Se on yhdistämistä liiketoimintatuloksien ja teknisten menetelmien välillä.

Ja se on varmistamisesta, että ymmärrämme ohjelmistoa, jonka laitamme maailmaan. Koska ohjelmisto ja järjestelmät tulevat yhä monimutkaisemmiksi, ja erityisesti kun AI on yhä enemmän mukana, on tärkeämpää kuin koskaan, että meidän on pidettävä itseämme vastuussa inhimillisestä ymmärtämisen ja hallitsemisen standardista.

Tulevaisuuden havaittavuuden näkökulmasta näemme tulevan lisää sofistikoitumista dataputkessa – käyttäen koneoppimista ja sofistikoitunutta näytteidenottotekniikkaa tasapainottamaan arvoa ja kustannuksia, pitämään niin paljon yksityiskohtia poikkeuksellisista tapahtumista ja tärkeistä tapahtumista ja tallentamaan tiivistelmät loput muista halvasti.

AI-toimittajat tekevät paljon ylimitoitettuja väitteitä siitä, miten he voivat ymmärtää ohjelmistosi paremmin kuin sinä itse, tai miten he voivat prosessoida dataa ja kertoa ihmisille, mitä toimia heidän on tehtävä. Kaiken, mitä olen nähnyt, tämä on kallis unelma. Väärät positiiviset ovat erittäin kalliita. Ei ole korvausta ymmärtämiseen järjestelmistäsi ja datastasi. AI voi auttaa insinöörejäsi siinä! Mutta se ei voi korvata insinöörejäsi. Kiitos haastattelusta, lukijat, jotka haluavat oppia lisää, kannattaa vierailla Honeycombissa.