Hoe triageert u wachtdienstmeldingen voordat ze een mens oproepen?
Een AI werknemer voor de wachtdienst die bij elke melding een eerste diagnose opstelt, de stacktrace, de recente deploys en de gecorreleerde logs ophaalt, deze in het incidentkanaal plaatst, en alleen een aangewezen persoon oproept wanneer hij de melding niet kan oplossen of de ernst hoog is.
×
Er komt om 3 uur 's nachts een melding binnen. Voordat iemand er iets mee kan doen, moet iemand wakker worden, de stacktrace ophalen, nagaan wat er recent is uitgerold, de logs doorzoeken en uitzoeken of dit een echt incident is of ruis. Het meeste daarvan is mechanisch, en het meeste gebeurt voordat de mens enige context heeft: welke fout is dit, wanneer begon die, wat is er net daarvoor uitgerold, gaat het om één gebruiker of om allemaal. De dienstdoende engineer beantwoordt deze vragen met de hand, half wakker, nog voordat hij kan beoordelen of de oproep terecht was. De gebruikelijke oplossingen zijn onvolledig. Bij elke melding oproepen verspilt de wachtdienst aan ruis en leert mensen de oproepen te negeren. Drempels bijstellen vermindert de ruis, maar verbergt ook echte regressies. Een runbook helpt, maar iemand moet nog steeds wakker zijn om het te volgen. Niets ervan doet het verzamelen voor u.
Elke melding activeert de AI werknemer voor de wachtdienst. Wanneer de errortracking afgaat, start de melding een run in uw eigen omgeving met alleen leestoegang tot de errortracker, de logs en GitHub. Hij haalt de stacktrace op, somt de deploys op sinds de fout voor het eerst verscheen, correleert de logs rond de piek, en plaatst een eerste diagnose in het incidentkanaal. Hij roept alleen een aangewezen persoon op wanneer hij de melding niet kan oplossen of de ernst hoog is.
Zie precies hoe het werk wordt gedaan.
Draait bij elke melding, zodra die binnenkomt
Een ondertekende webhook vanuit uw errortracking wijst ernaar. Elke melding activeert hem, en elke keer start een nieuwe run met de gegevens van de melding als startpunt. Eén melding, één run, één schone lei. Er wordt niets meegenomen tussen incidenten, en gelijktijdige meldingen worden parallel getriageerd.
Neemt uw triageplaybook mee
Hoe u triageert reist met hem mee als skill: welke services veel ruis geven, hoe een echte regressie eruitziet tegenover een bekende valse melding, de ernstregels voor wanneer op te roepen, en eerdere incidenten met hun grondoorzaken. Wanneer een melding onschuldig blijkt, legt u dat vast en herkent hij het de volgende keer.
Maakt verbinding met alleen lezen, met rechten die u instelt
Hij leest het foutticket (stacktrace, frequentie en tijdstip van eerste voorkomen) om de fout in de tijd te plaatsen, haalt de logregels rond de piek op en legt ze naast de trace, controleert op GitHub de commits en PRs die er net daarvoor zijn uitgerold, en plaatst de diagnose, de vermoedelijke deploy en het bewijs als één bericht in het incidentkanaal. Inloggegevens blijven in het geheugen, worden nooit naar schijf geschreven en worden nooit aan het model getoond.
Alleen lezen, hij deployt of draait nooit terug
Hij onderzoekt de errortracker, de logs en GitHub, maar deployt niet, draait niet terug en wijzigt niets. Meldingen met hoge ernst en alles wat hij niet kan oplossen roepen direct een aangewezen persoon op. De diagnose wordt meegestuurd, niet als vervanging van de oproep.
Roept op met het werk al gedaan
De trace, het deployvenster, de gecorreleerde logs en een eerste diagnose komen binnen de eerste minuut in het kanaal. Een bekende onschuldige piek wordt gesloten met de redenering erbij. Een melding met hoge ernst of een onopgeloste melding roept de dienstdoende engineer op met het werk al gedaan, zodat hij de oproep opent met context in plaats van een lege terminal.
Draait in uw eigen omgeving
Elke melding draait geïsoleerd binnen uw eigen infrastructuur en haalt traces, logs en deployhistorie op om de diagnose op te bouwen; alleen het geplaatste bericht en een eventuele oproep verlaten de omgeving. Uw data verlaat uw omgeving nooit.
Rechten die u instelt
De inloggegevens voor errortracking, logging en GitHub blijven in het geheugen, worden tijdens de run ingebracht en worden nooit aan het model of de logs getoond.
Alleen lezen, grijpt nooit in
Hij deployt nooit, draait nooit terug en wijzigt nooit iets. Meldingen met hoge ernst en onopgeloste meldingen roepen een aangewezen persoon op, die verantwoordelijk is voor elke actie die wordt ondernomen.
Diagnose meegestuurd, nooit een vervanging
Een oproep gaat nog steeds naar een persoon wanneer die terecht is. De AI werknemer verzamelt de context; hij bepaalt niet de oplossing en onderdrukt geen echte regressie.
De regels zijn van u
Het triageplaybook, de ernstregels, de skills en de rechten zijn van u, met versiebeheer en gewijzigd op uw voorwaarden, niet in het dashboard van een leverancier.
De mechanische eerste minuten van een incident gebeuren voordat iemand wordt opgeroepen, en wanneer de AI werknemer wel oproept, doet hij dat met de trace, de verdachte deploy en de gecorreleerde logs erbij. De dienstdoende engineer besteedt zijn tijd aan beslissen en oplossen in plaats van half wakker context verzamelen.
Eerste analyse
Diagnose in het kanaal voordat de oproep afgaat
Minder ruis
Onschuldige meldingen gesloten met redenering, geen oproep
3 systemen
Errortracking, logs en deployhistorie in één AI werknemer
Onze gratis AI-audit laat zien waar AI kansen biedt voor uw bedrijf, welke risico's daarbij komen kijken, en zet meteen uw eerste AI werknemer aan het werk.
Hoe houden AI werknemers uw documentatie synchroon met de code?
Doorloopt dagelijks de samengevoegde code, herschrijft de documentatie die door die wijzigingen is geraakt, en opent één beoordeelbare pull request. Publiceren wacht op een merge door een mens.
×Hoe testen AI werknemers elke pull request voordat een mens deze beoordeelt?
Checkt elke pull request uit, draait de suite, beproeft de wijziging via de edge op een testdeploy, en plaatst het resultaat. Blijft weg van productie en laat de merge aan een persoon over.
×Hoe krijgt u een postmortem opgesteld op het moment dat een incident is opgelost?
Reconstrueert de incidenttijdlijn, zet die af tegen deploys en logpieken en opent een gestructureerde postmortem als een document PR. De AI werknemer stelt op, het team maakt af.
×