Pienelle Incident Support -tiimillemme (vain 6 asiantuntijaa) kaksi mittaria ovat ehdottoman tärkeitä: ja . speed of detection accuracy of diagnosis Saamme tapauksia miljoonilta käyttäjiltä eri puolilta maailmaa Kun käyttäjän tapaus tulee sisään, yksi keskeisistä työkaluista, joihin luotamme - muiden ohella - on . 48 countries Kibana Koska järjestelmämme on monitoiminen (mikropalvelut, paikalliset sääntelyyn liittyvät erityispiirteet, A/B-kokeet ja paljon muuta), päädymme usein etsimään analysoimalla käyttäjään liittyviä tapahtumia lokeissa. Neula hyttysessä Jopa kokeneelle asiantuntijalle tämä vie aikaa, jotta: ymmärtää, mitä oikeasti tapahtui, erottavat melut todellisista asioista, yhdistää tekniset tapahtumat todelliseen käyttäjäkokemukseen. Keskimäärin tällainen analyysi on , ja epäselvissä tilanteissa se voi kestää paljon kauemmin. at least 15 minutes per case Halusin, että kirja lukisi kuin Ei niin kuin raaka tapahtuma. story Ja kyllä - tämä on Mutta pikemminkin a . not a replacement for an engineer Ajattelun kiihdytin Ajatuksen Automaatio on rakennettu Tämä yhdistää useita työkaluja: n8n Slackin Kibana (Välttämättömyyden kautta) LLM (suuri kieli malli) Ja muuttaa sen yksinkertaiseksi, käytännölliseksi työnkuluksi tukihenkilöille. Miten se toimii Luodaan omistettu Slack-kanava. Asiantuntija lähettää kanavalle käyttäjän UID:n – vain numeron. Automaatio kaappaa UID:n ja lähettää pyynnön Clairvoyance Kibanaan käyttämällä ennalta määriteltyjä suodattimia. Kaikki käyttäjän toiminnan lokit viimeisten 6 tunnin aikana tallennetaan. Jos mitään lokeja ei löydy, selkeä "ei aktiivisuutta löytynyt" -viesti julkaistaan Slack-harjaan. If logs exist, they are processed: empty entries are removed, duplicates are eliminated, data is structured and normalized, everything is bundled into a single dataset. Täydellinen lokipaketti lähetetään LLM: lle yhdessä räätälöidyn kehotuksen kanssa, joka on räätälöity tiimimme tarpeisiin. LLM analysoi tapahtumat ja palauttaa ihmisen luettavan yhteenvedon (enintään 600 merkkiä). Vastaus lähetetään takaisin alkuperäiseen Slack-viivaan noin 2 minuutin kuluttua pyynnöstä. Tämän putken alkuperäinen kehittäminen johti , josta suuri osa meni asianmukaisesti konfiguroituihin tunnistetietoihin (erityisesti Slackille - käsittelen sitä myöhemmin). 30 hours Odotamme, että aktiivisella käytöllä tämä automaatio säästää tiimiä. . up to 60 hours per month Mitä LLM todella vastaa? Vastaus on aina jäsennelty ja vastaa hyvin erityisiin kysymyksiin: Mitä virheitä havaittiin? Yhteenveto positiivisista (normaaleista) tapahtumista Miten virheet voisivat vaikuttaa käyttäjän työnkulkuun Kun ongelmat tarkalleen ottaen tapahtuivat (aikamerkit) Mitä toimenpiteitä asiantuntijan tulisi tehdä seuraavaksi Tämän seurauksena emme vain näe Mutta todellinen : Mitä käyttäjä teki, missä he löysivät ongelman ja kuinka kriittinen se oli. ”HTTP 400 on Endpoint X” context Ja kyllä - . no sensitive data is ever sent to the LLM Automaation keskeiset tavoitteet 1. Humanisoi lokin lukemista Kibana on tehokas työkalu, mutta lokien lukeminen silmäsi kanssa on väsyttävää ja kognitiivisesti kallista - varsinkin kun tapahtumat leviävät ajan myötä ja useissa palveluissa. Halusin, että tuote näytti kuin Ei mikään tekninen roska. clear explanation 2. Analyysiajan lyhentäminen Before automation: 15+ minuuttia käyttäjäkohtaisesti After automation: 1–2 minuuttia (lähetä UID → saada yhteenveto) Tämä on erityisen tärkeää huippukuormituksen tai massiivisten tapahtumien aikana. Mahdollistaa syvällisemmän analyysin Automaatio ei pelkästään säästä aikaa – se mahdollistaa: tunnistaa järjestelmäkysymykset nopeammin, tunnistaa toistuvat virhemallit käyttäjien välillä, parantaa asiantuntijoiden taitoja korostamalla uusia ongelma-alueita, ymmärtää paremmin, miten sovellus käyttäytyy reaalimaailmassa. Loppujen lopuksi tämä lähestymistapa vähentää merkittävästi kehittäjien aikaa, joka kuluu vain käyttäjäkokemuksen kautta kuvattujen ongelmien tutkimiseen. Kenelle tämä työkalu sopii? Ennen kaikkea : asiantuntijoiden tukeminen, insinöörit, jotka työskentelevät käyttäjäkohtaisten tapahtumien kanssa, Joukkueet, jotka tarvitsevat nopeasti ymmärtää "mitä meni pieleen" ilman heti sukeltaa Kibanaan. Onko tämä lopullinen versio? Ei, tämä on a Tällä hetkellä a , jossa täysi käynnistys on suunniteltu etukäteen . living tool Hiljainen testausvaihe 2026 Testin aikana: Kiireet ovat hienostuneita, eri LLM: t ja malliversioita verrataan, Suodatuslogiikkaa ja vastausmalleja parannetaan. Jopa nyt automaatio täyttää päätavoitteensa: . making logs understandable and saving time Putkilinjan rakenne Triggerit Pöytäliina alkaa tapahtumasta, joka on omistettu Slack-kanavalle ( ) ja Slack Trigger Tapahtuman tyyppi: Uusi viesti lähetetty kanavaan Input: käyttäjän UID lähetetään tavallisena tekstinä Tietojen valmistelu Viestin tiedot poistetaan ja muunnetaan käyttämällä Valitse tarvittava JSON-muoto: Set nodes Ylempi haara: UID (numerona) Lower branch: thread context (kanavan tunnus ja thread timestamp) Lataa Retrieval UID on siirretty Kibanaan ( ) käyttämällä Indeksissä näkyy selkeästi. Elasticsearch / Get Many traces-main Lehtiä etsitään määritellyn ajan ikkunan sisällä. user_id Ehdollinen logiikka Yksi checks whether any events were found: IF node No events: Data is merged with the thread context A predefined “NO EVENTS” message is posted to Slack Events found: Logs are aggregated, minimized, and normalized Data is sent to the LLM for analysis Vastaus toimitukseen LLM-tulostus yhdistetään Slack-teeman kontekstiin ja lähetetään vastauksena alkuperäiseen teemaan. Node yksityiskohdat Tyylikäs trigger Vaatii valmiiksi määritetyt Slack-tunnukset ja kanavan tunnuksen (saatavilla Se on Slack. Avoimen kanavan yksityiskohdat Aseta solmuja Käytetään syöttötietojen poistamiseen ja normalisointiin: uid → parsettuna viestin tekstistä numerona thread data: channel → original message timestamp thread_ts Elasticsearch Node Näytä tarkat tiedot Vaatii Kibana-tietojen ja indeksi-ID:n (joita löytyy ) on Indeksinhallinta Tärkeimmät asetukset : Rajoitus: 1000 kohdetta(Korkeammat arvot aiheuttivat usein porttiajanjaksoja.) Query: time range: now-6h filter by user_id limited source fields last 1000 events Koodi Node (minimisaattori) Valmistaa lokit LLM-analyysiin: normalisoi kentät (aika, sisältö) naamioi potentiaaliset PII:t (puhelin/sähköposti – vaikka sitä ei olisi, lisäsuojana), Pitkän aikavälin arvot, poistaa tyhjät kentät, Tapahtumien määrä ajan myötä, samankaltaisten tapahtumien toistaminen, laskee kevyitä tilastoja (HTTP-koodit, päätepisteet) rakentaa kompakin esitteen, jossa on 500 parasta yhteenlaskettua tapahtumaa ja tiukka pituusraja. Tämä on ratkaisevan tärkeää, jotta vältytään lähettämästä suuria, token-halpoja hyötykuormia LLM: lle. OpenAI Node (viesti mallille) Vaatii OpenAI-tietojen ja mallin valinnan (tällä hetkellä testin aikana) GPT-4.1-Mini Ohjelma on suunniteltu näkökulmasta a : second-line technical support specialist luokittele ensin käyttäjä (kuljettaja / matkustaja / kuriiri), focus on technical errors, jos virheitä ei ole, analysoida liiketoiminnan tilaa (asiakirjat, kiellot, profiilin tila), noudata tiukkaa vastausmallia, jossa on merkkirajoituksia, yhteydet konkreettisiin päätepisteisiin ja aikatauluihin, erillinen tekninen analyysi käyttäjäkohtaisen työnkulun vaikutuksesta. Tämä rakenne muuttaa raaka-aineita . clear, actionable insights Esimerkki alla olevasta tuotannosta: Lopulliset ajatukset Tämä automaatio ei korvaa insinöörejä – se auttaa heitä ajattelemaan nopeammin.Kääntämällä raaka-aikataulut lyhyiksi, jäsennellyiksi kertomuksiksi tiimi vähentää kognitiivista kuormitusta ja nopeuttaa tapahtumien analysointia menettämättä asiayhteyttä. N8n-työkaluilla ja nykyaikaisilla LLM-ohjelmilla pienetkin tiimit voivat rakentaa käytännöllisiä, ihmisen kannalta ystävällisiä havainnointikerroksia.