Annoimme teratavuja CI-lokeja LLM:lle

Piilotettu kultakaivos istuu CI-putkissasi

Jokainen suunnittelutiimi luo ne. Miljoonia rivejä joka ikinen päivä – aikaleimat, pinojäljet, riippuvuusselvitykset, testitulokset, rakennusartefaktit ja salaperäiset virheilmoitukset, jotka vierivät ohi nopeammin kuin kukaan jaksaa lukea. CI-lokit ovat nykyaikaisen ohjelmistokehityksen pakokaasuja, ja useimmissa organisaatioissa niitä kohdellaan täsmälleen kuten pakokaasua: tyhjennetään varastoon ja unohdetaan. Mutta entä jos nämä lokit sisältäisivät kuvioita, jotka voisivat ennustaa vikoja ennen kuin ne tapahtuvat, tunnistaa pullonkauloja, jotka maksavat tiimillesi satoja tunteja vuosineljänneksessä, ja paljastaa järjestelmäongelmia, joita yksikään insinööri ei koskaan näe? Päätimme selvittää sen syöttämällä teratavuja CI-lokitietoja suureen kielimalliin – ja se, mitä löysimme, muutti ajattelumme DevOpsista täysin.

Miksi CI-lokit ovat eniten käytettyjä tietoja ohjelmistosuunnittelussa

Ota huomioon valtava määrä. Keskikokoinen suunnittelutiimi, joka suorittaa 200 koontiversiota päivässä useissa arkistoissa, tuottaa päivittäin noin 2–4 Gt raakalokidataa. Yli vuoden aikana se on yli teratavu jäsenneltyä ja puolirakenteista tekstiä, joka kaappaa jokaisen kokoelman, jokaisen testipaketin suorituksen, jokaisen käyttöönottovaiheen ja jokaisen järjestelmäsi kohtaaman virhetilan. Se on täydellinen arkeologinen tallenne suunnitteluorganisaatiosi tuottavuudesta – ja melkein kukaan ei lue sitä.

Ongelma ei ole se, että tiedoilla ei ole arvoa. Se, että signaali-kohinasuhde on brutaali. Tyypillinen CI-ajo tuottaa tuhansia riviä, ja ehkä 3-5 riveistä sisältää toiminnallista tietoa. Insinöörit oppivat etsimään punaista tekstiä, grep-sanaa "FAILED" ja jatkamaan. Mutta tärkeimmät kuviot – hilseilevä testi, joka epäonnistuu joka tiistai, riippuvuus, joka lisää 40 sekuntia jokaiseen koontiversioon, muistivuoto, joka ilmenee vain, kun kolme tiettyä palvelua suoritetaan samanaikaisesti – nämä kuviot ovat näkymättömiä yksittäisen lokin tasolla. Ne ilmestyvät vain suuressa mittakaavassa.

Perinteiset lokianalyysityökalut, kuten ELK-pinot ja Datadog, voivat koota mittareita ja löytää avainsanaosuuksia, mutta ne kamppailevat CI-tulostuksen semanttisen monimutkaisuuden kanssa. Koontivirheviesti, jossa lukee "yhteys evätty portissa 5432" ja viesti, jossa lukee "FATAL: salasanan todennus epäonnistui käyttäjän 'käyttöönotossa'" ovat molemmat tietokantaan liittyviä virheitä, mutta niillä on täysin erilaiset syyt ja ratkaisut. Tämän eron ymmärtäminen vaatii sellaista kontekstuaalista päättelyä, jota vain ihmiset pystyivät viime aikoihin asti tarjota.

Kokeilu: 3,2 teratavun rakennushistorian syöttäminen LLM:lle

Asennus oli konseptiltaan suoraviivainen ja toteutus oli painajaismaista. Keräsimme 14 kuukauden CI-lokeja alustalta, joka palvelee yli 138 000 käyttäjää. Se kattaa useiden palvelujen, ympäristöjen ja käyttöönottokohteiden koontiversiot. Raakatietojoukon koko oli 3,2 teratavua: noin 847 miljoonaa yksittäistä lokiriviä, jotka kattavat 1,6 miljoonaa CI-liukuhihnaa. Puristimme, upoimme ja indeksoimme nämä tiedot ja rakensimme sitten RAG (Retrieval-augmented Generation) -putkiston, joka voisi vastata luonnollisen kielen kysymyksiin rakennushistoriaamme liittyen.

Ensimmäinen haaste oli esikäsittely. CI-lokit eivät ole puhdasta tekstiä. Ne sisältävät ANSI-värikoodeja, itsensä päälle kirjoittavia edistymispalkkeja, binaarisia artefaktien tarkistussummia ja aikaleimoja vähintään neljässä eri muodossa sen mukaan, mikä työkalu ne on luonut. Käytimme kolme viikkoa vain normalisointiin – kohinan poistamiseen, aikaleimien standardointiin ja kunkin lokisegmentin merkitsemiseen metatiedoilla siitä, mihin putkilinjan vaiheeseen, tietovarastoon, haaraan ja ympäristöön se kuului.

Toinen haaste oli hinta. Päätelmien suorittaminen teratavuilla tekstiä ei ole halpaa edes aggressiivisen lohkomisen ja haun optimoinnin kanssa. Kävimme läpi merkittäviä laskentapisteitä pelkästään ensimmäisen kuukauden aikana, lähinnä siksi, että alkuperäinen lähestymistapamme oli liian naiivi – lähetimme liikaa kontekstia kyselyä kohden ja emme olleet tarpeeksi valikoivia sen suhteen, mitkä lokisegmentit olivat olennaisia. Toisen kuukauden loppuun mennessä pienensimme kyselykohtaisia kustannuksia 87 % parempien upotusstrategioiden ja kaksivaiheisen hakujärjestelmän ansiosta, joka esisuodatti pienemmän mallin ennen lähettämistä suurempaan.

Viisi LLM:n löytämää mallia, joita ihmiset eivät koskaan tekisi

Ensimmäisen kyselyviikon aikana järjestelmä esitti oivalluksia, joiden löytäminen manuaalisesti ihmisanalyytikon olisi kestänyt kuukausia. Nämä eivät olleet reunatapauksia tai uteliaisuutta – ne olivat systeemisiä ongelmia, jotka vuotivat todellisia suunnittelutunteja.

1. Phantom-riippuvuussarja. Yksittäinen npm-pakettipäivitys yhdeksän kuukautta aiemmin toi 22 sekunnin viiveen jokaiseen JavaScript-koontiversioon. Viive peitettiin, koska se osui samaan aikaan CI-infrastruktuurin päivityksen kanssa, joka teki rakentamisesta kaiken kaikkiaan nopeampaa. Net-net, buildit ilmestyivät nopeammin, mutta ne olisivat voineet olla vielä 22 sekuntia nopeampia. Yli 400 JS-koontiversiota päivässä, mikä oli 2,4 tuntia hukattua laskentaa päivittäin.
2. Aikavyöhykehiutale. Testisarjan epäonnistumisprosentti oli 4,7 % – juuri tarpeeksi korkea ollakseen ärsyttävää, juuri tarpeeksi alhainen, ettei kukaan halunnut korjata sitä. LLM havaitsi, että viat korreloivat lähes täydellisesti koonnoksilla, jotka käynnistettiin kello 23:00 ja 01:00 UTC välillä, kun päivämäärän vertailutoiminto ylitti päivän rajan. Kaksirivinen korjaus eliminoi hiutaleen kokonaan.
3. Hiljainen palautuskuvio. Vaiheiden käyttöönotot onnistuivat 99,2 % ajasta, mutta LLM huomasi, että 31 % "onnistuneista" vaiheistuksen käyttöönotoista seurasi saman palvelun uusi käyttöönotto 45 minuutin sisällä. Tämä viittaa siihen, että ensimmäinen käyttöönotto oli toiminnallisesti rikki huolimatta kaikkien tarkastusten läpäisystä. Tämä johti siihen, että havaittiin, että integrointitesti meni läpi valepalvelun välimuistissa olevien vastausten vuoksi.
4. Maanantaiaamun pullonkaula. Rakennusjonoajat nousivat 340 % joka maanantai kello 9.00–10.30 paikallista aikaa, koska viikonloppuna työskennelleet kehittäjät ajoivat kaikki muutokset ennen standupia. Korjaus ei ollut tekninen – se oli toimiva: CI-runnerpoolin skaalausaikataulua porrastettiin maanantain nousujen ennakoimiseksi.
5. Kääntäjän lippu, jota kukaan ei asettanut. 67 % C++-koontiversioista oli käynnissä ilman, että käännös oli käytössä, mikä lisäsi keskimäärin 3,8 minuuttia koontiversiota kohti. Lippu oli dokumentoitu perehdytysoppaassa, mutta sitä ei koskaan lisätty jaettuun CI-määritysmalliin.

"Kalleimmat bugit eivät ole niitä, jotka kaatavat sovelluksesi. Ne varastavat hiljaa 30 sekuntia jokaisesta koontiversiosta, päivittäin, vuosien ajan – kunnes joku lopulta kysyy oikean kysymyksen oikeasta tietojoukosta."

Käytännön CI Intelligence -kerroksen rakentaminen

Kokeilu sai meidät vakuuttuneeksi siitä, että LLM-pohjainen lokianalyysi ei ole uutuus – se on aito toimintakyky. Mutta käytännön tekeminen vaatii harkittua arkkitehtuuria. Et voi vain ohjata raakalokeja chat-käyttöliittymään ja odottaa hyödyllisiä vastauksia. Järjestelmä tarvitsee rakenteen, ja se on integroitava insinöörien jo käyttämiin työnkulkuihin.

Päädyimme kolmiportaiseen lähestymistapaan. Ensimmäinen taso on automaattinen triage: jokainen epäonnistunut koontiversio luokitellaan automaattisesti perimmäisen syyluokan (infrastruktuuri, riippuvuus, testilogiikka, kokoonpano tai hiutale) mukaan luotettavuuspisteillä. Pelkästään tämä lyhensi rakennusvirheiden korjaamiseen kuluvaa keskimääräistä aikaa 34 %, koska insinöörien ei enää tarvinnut käyttää 10 minuuttia lokien lukemiseen vain selvittääkseen, mistä aloittaa etsiminen. Toinen taso on trendien havaitseminen: viikoittainen tiivistelmä, joka paljastaa esiin nousevat mallit – kasvavat epäonnistumisasteet, kasvavat rakennusajat, uudet virheiden allekirjoitukset – ennen kuin niistä tulee kriittisiä. Kolmas taso on interaktiivinen tutkimus: käyttöliittymä, jossa insinöörit voivat kysyä luonnollisella kielellä kysymyksiä rakennushistoriasta, kuten "Miksi palvelu X epäonnistui useammin maaliskuun julkaisun jälkeen?" tai "Mikä on yleisin syy maksuputkien aikakatkaisuvirheisiin?"

Tiimeille, jotka hoitavat monimutkaisia toimintoja – erityisesti niille, jotka hallitsevat useita liiketoimintatoimintoja, kuten CRM:ää, laskutusta, palkanlaskentaa ja analytiikkaa 207 integroitua moduulia ohjaavan Mewayzin kaltaisten alustojen kautta – tällainen havaittavuus tulee entistä kriittisemmäksi. Kun yksittäinen käyttöönotto koskettaa asiakaskohtaisia ​​työnkulkuja, laskutuslogiikkaa ja HR-järjestelmiä samanaikaisesti, CI-putken keskinäisten riippuvuuksien ymmärtäminen ei ole valinnaista. Se on välttämätöntä luotettavuuden ylläpitämiseksi, josta yli 138 000 käyttäjää on riippuvainen.

Mikä ei toimi (vielä)

Rehellisyys on tärkeämpää kuin hype. Tällä lähestymistavalla on selvät rajoitukset, jotka jokaisen sitä harkitsevan tulisi ymmärtää. LLM:t hallusinoivat, ja kun he hallusinoituvat CI-lokeista, tulokset voivat olla vakuuttavasti vääriä. Olemme nähneet, että järjestelmä luottaa luottavaisesti koontivirheen syyksi riippuvuusristiriitaan, jota ei koskaan ollut olemassa, ja joka on täydennetty keinotekoisilla versionumeroilla. RAG-putkilinja vähentää tätä merkittävästi, mutta ei poista sitä. Jokainen järjestelmän tuottama oivallus vaatii vielä ihmisen tarkastamisen ennen toimintaa.

Mittakaava on edelleen haaste. Vaikka hakujärjestelmä pystyy käsittelemään kyselyitä tehokkaasti, uusien lokien ensimmäinen indeksointi ja upottaminen on laskennallisesti kallista. Käsittelemme päivittäin noin 800 000 uutta lokiriviä, ja indeksin pitäminen tuoreena vaatii erityistä infrastruktuuria. Pienemmille joukkueille kustannus-hyötylaskenta ei välttämättä suosi tätä lähestymistapaa – ei ainakaan vielä. Kun mallin kustannukset laskevat edelleen (ne ovat laskeneet noin 90 % viimeisten 18 kuukauden aikana vastaavan kyvyn osalta), talous muuttuu.

Tässä on myös turvallisuuskysymys. CI-lokit voivat sisältää salaisuuksia – API-avaimia, yhteysmerkkijonoja, sisäisiä URL-osoitteita – huolimatta parhaimmista yrityksistä puhdistaa ne. Näiden tietojen lähettäminen ulkoisille LLM-sovellusliittymille sisältää riskin. Vähennämme tätä paikallisella pesuputkella ja suorittamalla päätelmiä itseisännöidyistä malleista herkille tietovarastoille, mutta se lisää monimutkaisuutta ja kustannuksia. Tiimien tulee arvioida huolellisesti uhkamallinsa ennen kuin ottavat käyttöön mitään vastaavaa.

Aloitus ilman teratavuja

Et tarvitse suurta tietojoukkoa tai omistautunutta ML-suunnittelutiimiä aloittaaksesi arvon poimimisen CI-lokeistasi. Tässä on pragmaattinen lähtökohta, jonka jokainen tiimi, jolla on muutama sata versiota viikossa, voi toteuttaa:

• Aloita virheluokittelulla. Vie viimeisten 90 päivän epäonnistuneet rakennuslokit. Luokittele jokainen virhe luokkiin mitä tahansa LLM-sovellusliittymää käyttämällä. Jopa yksinkertainen taksonomia (infra vs. koodi vs. config vs. flake) tarjoaa välitöntä arvoa priorisoinnille.
• Seuraa koontiversion keston trendejä. Jäsennä aikaleimat lokeistasi luodaksesi aikasarjan rakennusten kestoista liukuhihnavaihetta kohti. Syötä poikkeamat LLM:lle ympäröivän lokikontekstin kanssa ja kysy perussyyhypoteesia.
• Automatisoi "ilmeiset" kysymykset. Aseta epäonnistumisen jälkeinen koukku, joka lähettää epäonnistuneen koontiversion viimeiset 500 riviä LLM:lle kehotteen avulla: "Tee yhteenveto tästä CI-virheestä yhdellä lauseella ja ehdota todennäköisintä korjausta." Pelkästään tämä säästää 5–10 minuuttia jokaista ryhmän insinööriä kohden.
• Luo haettavissa oleva arkisto. Käytä upotuksia tehdäksesi lokihistoriastasi kyselyn luonnollisella kielellä. LangChainin ja LlamaIndexin kaltaiset työkalut tekevät tästä yllättävän helposti saavutettavissa jopa tiimeille, joilla ei ole ML-kokemusta.

Tärkeintä on aloittaa pienestä, vahvistaa, että oivallukset ovat tarkkoja, ja laajentaa asteittain. Tällaisten analyysien työkaluekosysteemi kypsyy nopeasti, ja se, mikä vuosi sitten vaati mukautettua infrastruktuuria, on yhä enemmän saatavilla valmiina komponentteina.

Tulevaisuus on operatiivista älykkyyttä

Puhumme todella muusta kuin lokianalyysistä – se on perustavanlaatuinen muutos kohti operatiivista älykkyyttä. Sama lähestymistapa, joka toimii CI-lokeissa, koskee asiakastuen lippuja, myyntiputkitietoja, rahoitustapahtumia ja toiminnallisia työnkulkuja. Yhteinen lanka on, että organisaatiot luovat valtavia määriä puolistrukturoitua tekstidataa, joka sisältää toimivia malleja, ja LLM:t sopivat ainutlaatuisesti näiden mallien löytämiseen.

Tästä syystä liiketoimintaa keskittävillä alustoilla on rakenteellinen etu. Kun CRM-tietosi, projektinhallinta, laskutus, HR-tietueet ja analytiikka ovat kaikki yhdessä järjestelmässä – kuten Mewayzin integroitua moduuliarkkitehtuuria käyttävillä tiimeillä – verkkotunnusten välisen älykkyyden mahdollisuudet moninkertaistuvat. CI-lokien kuvio saattaa korreloida asiakkaiden vaihtuvuuden kanssa. Tukilipukkeiden piikki saattaa ennustaa käyttöönoton epäonnistumisen. Nämä yhteydet tulevat näkyviin vasta, kun tiedot elävät yhdistetyissä järjestelmissä eristyneiden siilojen sijaan.

Seuraavan vuosikymmenen aikana menestyvät tiimit eivät välttämättä ole niitä, joilla on eniten suunnittelijoita tai suurimmat budjetit. He oppivat kuuntelemaan omia tietojaan – mukaan lukien ne teratavut, jotka he ovat heittäneet pois. CI-lokisi puhuvat. Kysymys kuuluu, oletko valmis kuulemaan, mitä heillä on sanottavaa.

Usein kysytyt kysymykset

Voivatko LLM:t todella löytää hyödyllisiä malleja CI-lokeista?

Ehdottomasti. Suuret kielimallit ovat erinomaisia ​​toistuvien kuvioiden tunnistamisessa massiivisesta jäsentämättömästä tekstistä. Kun ne kohdistetaan teratavuihin CI-lokeja, ne voivat paljastaa virhekorrelaatioita, hilseileviä testiallekirjoituksia ja riippuvuusristiriitoja, joita insinöörit eivät koskaan havaitse manuaalisesti. Tärkeintä on strukturoida tiedonkeruuputki oikein, jotta malli vastaanottaa kunnolla paloiteltuja, kontekstuaalisia lokisegmenttejä raakakohinan sijaan.

Millaisia CI-häiriöitä voidaan ennustaa lokianalyysin avulla?

LLM-pohjainen lokianalyysi voi ennustaa infrastruktuuriin liittyviä aikakatkaisuja, toistuvia riippuvuusratkaisuvirheitä, muistiin sidottuja koontiversion kaatumisia ja tiettyjen koodipolkujen käynnistämiä epämääräisiä testejä. Se tunnistaa myös hitaasti hiipiviä regressioita, joissa rakennusajat pidentyvät vähitellen viikkojen kuluessa. Tätä lähestymistapaa käyttävät tiimit havaitsevat tyypillisesti peräkkäisiä virhekuvioita kahdesta kolmeen sprinttiä ennen kuin niistä tulee estäviä tapahtumia tuotantokäyttöönotoissa.

Kuinka paljon CI-lokitietoja tarvitset, ennen kuin analyysistä tulee arvokasta?

Merkekkäät kuviot ilmenevät yleensä analysoituaan 30–90 päivän jatkuvaa putkistohistoriaa useiden haarojen välillä. Pienemmät tietojoukot tuottavat pintatason oivalluksia, mutta todellinen arvo tulee ristiinviittauksista tuhansiin koontiajoihin. Tiimille, jotka hallitsevat monimutkaisia työnkulkuja CI-putkistojensa rinnalla, Mewayzin kaltaiset alustat tarjoavat 207 integroitua moduulia alkaen 19 $/kk käyttötietojen keskittämiseksi osoitteessa app.mewayz.com.

Onko CI-lokien syöttäminen LLM:lle turvallisuusriski?

Se voi tapahtua, jos sitä käsitellään huolimattomasti. CI-lokit sisältävät usein ympäristömuuttujia, API-avaimia, sisäisiä URL-osoitteita ja infrastruktuurin tietoja. Ennen kuin käsittelet lokeja minkä tahansa LLM:n kautta, sinun on otettava käyttöön vankat muokkausputket, jotka poistavat salaisuudet, valtuustiedot ja henkilökohtaiset tunnistetiedot. Itseisännöidyt tai paikalliset mallin käyttöönotot vähentävät merkittävästi altistumista verrattuna raakalokien lähettämiseen kolmannen osapuolen pilvipohjaisiin päätepisteisiin.