Oncall Bot en frontendmonitoring

Het probleem

Stille uitval bij overdrachten aan derden, zoals NFC-controles, werd pas dagen later via de klantenservice ontdekt. Onze alerts waren gebaseerd op drempelwaarden en luidruchtig, dus iedereen had geleerd ze te negeren.

De aanpak

• Relatieve basislijnen in plaats van vaste drempels. De alertservice draait SQL op ClickHouse en vergelijkt elke metric met hetzelfde uur van vorige week. Een conversiedaling van 20% betekent om 3 uur 's nachts in Tokio iets anders dan om 12 uur 's middags in Berlijn, en wereldwijde verkeersschommelingen veroorzaken geen valse alarmen meer.
• Een alert die context meebrengt. Gaat een alert af, dan plaatst die een incidentkaart in het interne chatplatform. Een achtergrondproces verzamelt vervolgens recente frontend-stacktraces uit ClickHouse, de actieve configuratieversie uit de configuratieservice en Kubernetes-deploymentlogs, en stuurt die als gestructureerde prompt naar een zakelijke LLM-API.
• Een samenvatting in de thread. De bot antwoordt met een waarschijnlijke oorzaak, bijvoorbeeld: conversie in stap 3 in Japan 32% gedaald, een null-pointerfout in de NFC-bridgewrapper, een configuratiewijziging die 15 minuten eerder is uitgerold en een timeout bij de gateway van een leverancier in de backend.

Het resultaat

De tijd tot detectie daalde van uren of dagen naar minder dan 5 minuten, de tijd tot mitigatie met 65% en het aantal vals-positieve alerts met 80%. Daarnaast werden de signaal-ruisverhouding van alerts (het aandeel alerts dat bij echte incidenten hoort) en de gemiddelde tijd tussen storingen van frontendmodules bijgehouden.

Waarom zo

Een gewone alert vertelt alleen dat er iets kapot is. Automatisch gegevens verzamelen en samenvatten dicht het gat tussen een metric en iemand die hem begrijpt, en daar ging de meeste reactietijd naartoe.