Iedereen die ooit alarmering heeft ingericht, kent het moment waarop je telefoon niet meer stopt met trillen. Bij mij kwam dat moment in de vorm van 344 pushberichten binnen tien minuten. Niet omdat er 344 dingen kapot waren. Er was precies één ding aan de hand. Maar mijn eigen bewakingssysteem vond het nodig om dat ene ding per gebeurtenis te melden, en die gebeurtenissen kwamen honderden keren voorbij.

Het vervelende was niet eens de storing zelf. Het vervelende was dat ik na twintig berichten al niet meer keek. Ik dacht letterlijk: ik lees die tientallen berichten toch niet, ik raak alleen maar geïrriteerd, wat heb ik hier eigenlijk aan? En dat is het gevaarlijkste wat er met alarmering kan gebeuren. Op het moment dat je je alarmen negeert, is je alarmering erger dan geen alarmering, want je bent de illusie van bewaking gaan betalen met echte blindheid.

In dit stuk pluis ik uit waarom dit gebeurde, waarom het een structurele ontwerpfout is en niet gewoon pech, en hoe ik het herontwierp tot een systeem dat bij dezelfde storing precies één bericht stuurt, of helemaal geen.

De fout die iedereen intuïtief maakt#

De oorzaak was een ontwerpkeuze die zo logisch voelt dat vrijwel iedereen hem maakt: één gebeurtenis, één melding. Er gebeurt iets vermeldenswaardigs, dus je stuurt een bericht. Klinkt redelijk.

Het probleem is dat gebeurtenissen zich niet netjes één voor één aandienen. Een enkele storing kan honderden gebeurtenissen genereren. In mijn geval had ik een beveiligingslaag teruggezet naar een standaard-set regels, en op mijn drukke werkserver vuurde één van die regels honderden keren per minuut. Elke keer een gebeurtenis. Elke gebeurtenis een bericht. Reken uit.

Zo bekeken was het geen ongeluk maar wiskunde. Melden-per-gebeurtenis werkt prima zolang gebeurtenissen zeldzaam zijn, en klapt gegarandeerd om zodra er iets is dat in een storm van gebeurtenissen resulteert. En laat een storing nou net het moment zijn waarop gebeurtenissen zich massaal opstapelen. Oftewel: dit ontwerp faalt precies wanneer je het het hardst nodig hebt.

Waarom je hier niet met een simpele drempel wegkomt#

De eerste reflex is: dan zet ik toch een limiet? Maximaal tien berichten per uur, klaar. Dat helpt tegen de spam, maar creëert een nieuw probleem. Want welke tien houd je over? Als je botweg afkapt, mis je misschien juist het ene bericht dat er wél toe deed, verstopt tussen de ruis. Je hebt de hoeveelheid verlaagd, maar niet het onderscheid tussen belangrijk en onbelangrijk gemaakt.

En dat onderscheid is nu precies het moeilijke. Van die 344 berichten waren er 343 pure ruis, afkomstig van normaal gedrag op een ontwikkelserver, en misschien één die ergens op wees. Een domme limiet weet dat verschil niet. Je hebt iets nodig dat kan lezen wat er gebeurt en kan beoordelen: is dit signaal of is dit achtergrondruis?

Het herontwerp: verzamelen, clusteren, beoordelen, pas dan melden#

Zo heb ik het opnieuw opgezet, en dit is het patroon dat ik sindsdien op elke luidruchtige alarmbron toepas.

Stap één: gebeurtenissen gaan niet naar je telefoon, maar naar een opslag. De eerste en belangrijkste verandering. Geen enkele gebeurtenis leidt nog direct tot een bericht. Alles wordt weggeschreven naar een logopslag. De bron mag zo hard vuren als hij wil, jouw telefoon merkt er niets van.

Stap twee: elk kwartier kijkt een proces naar de nieuwe gebeurtenissen. Op een vast ritme, in mijn geval elke vijftien minuten, wordt de nieuwe oogst opgehaald. Niet gebeurtenis voor gebeurtenis, maar de hele batch in één keer.

Stap drie: clusteren. Die batch wordt gegroepeerd op soort. Honderden gebeurtenissen die eigenlijk allemaal hetzelfde zijn, worden teruggebracht tot een handvol clusters. In mijn geval kromp een batch van 236 losse gebeurtenissen naar 4 clusters. Dat alleen al maakt het overzichtelijk.

Stap vier: laat een goedkoop Ai-model de batch beoordelen. En hier komt de kern. Die vier clusters gaan naar een klein, goedkoop taalmodel met één opdracht: is dit normale ruis, of zit hier iets verdachts tussen? Een mens zou dat oordeel ook kunnen vellen, maar een mens wil je hier niet voor wakker maken. Een goedkoop model kost centen en is uitstekend in dit soort triage: het hoeft niet briljant te zijn, het hoeft alleen ruis van signaal te scheiden.

Stap vijf: maximaal één bericht, en alleen bij een echt signaal. Zegt het model “dit is allemaal normaal gedrag”? Dan gebeurt er niets. Stilte. Zegt het model “hier zit iets wat aandacht verdient”? Dan krijg ik precies één bericht, met de samenvatting van wat er speelt. Nooit meer honderden losse meldingen.

Het resultaat is dat mijn telefoon in de meeste gevallen gewoon stil blijft, precies zoals het hoort, en alleen trilt als er echt iets is. Diezelfde storing die me ooit 344 berichten kostte, zou nu resulteren in één bericht of geen, afhankelijk van of het clustertje ruis of gevaar bleek.

De vuistregel die je overal kunt gebruiken#

Los van alle techniek is dit de regel die ik eruit heb gehaald, en die geldt voor elke automatische melding die je ooit inricht:

Voor een luidruchtige, repetitieve bron: nooit één-melding-per-gebeurtenis. Verzamel, groepeer, laat iets beoordelen, en meld alleen bij een echt signaal.

Dedupliceer daarbij op basis van “wat heb ik al gezien” (een tijdstempel van de laatste verwerking), niet op de inhoud van elk bericht. En accepteer dat stilte de norm hoort te zijn. Een goed alarmsysteem is een systeem dat je meestal niet hoort.

Wat betekent dit voor jouw bedrijf?#

Ook als jij nooit een beveiligingslog zult zien, loop je dit risico. Overal waar iets automatisch een melding stuurt, of dat nu een voorraadsysteem is, een webshop, een boekingsplatform of een koppeling met je boekhouding, zit dezelfde valkuil: melden-per-gebeurtenis dat omslaat in een lawine zodra er iets misgaat.

Drie dingen om op te letten:

  1. Meet of je je eigen alarmen nog leest. Als het antwoord “nee, ik heb ze uitgezet” of “ik scroll er overheen” is, heb je geen alarmering meer, je hebt ruis. Dat is een signaal op zich.
  2. Vraag hoe meldingen worden samengevat. Krijg je bij een probleem één begrijpelijke melding, of een stortvloed? Een leverancier die je bij elke storing bedelft onder berichten, heeft dit niet doordacht.
  3. Zie stilte niet als verdacht, maar als het doel. Het doel van goede automatisering is niet meer meldingen, maar minder. Een stille telefoon die precies één keer trilt op het juiste moment is oneindig veel waardevoller dan een telefoon die de hele dag trilt en die je daarom negeert.

De echte kunst van bewaking zit niet in méér melden, maar in beter zwijgen. Wil je uitzoeken waar in jouw bedrijf de alarmering ruis produceert in plaats van rust? Bekijk mijn gratis downloads of neem via de consulting-pagina contact op.