Reactief beheer is duurder dan het lijkt
De meeste IT-problemen kondigen zich aan. Een schijf die vol loopt, een back-up die twee nachten mislukt, een certificaat dat verloopt, een access point dat elke nacht herstart: dat zijn allemaal signalen die dagen tot weken voor de storing zichtbaar zijn. Bij reactief beheer ziet niemand ze, en begint het werk pas als de eerste medewerker belt dat iets niet meer werkt.
Reken het voor uw eigen organisatie eens door. Veertig medewerkers die een halve dag niet bij de bestandsserver kunnen, zijn honderdzestig verloren uren. Daar komen de spoedkosten bij, plus het inhaalwerk en het gesprek met de klant die zijn levering niet op tijd kreeg. De aanpassing die de storing had voorkomen, was in dit voorbeeld een uur werk en een nieuwe schijf. Dat verschil is de kern van proactief beheer.
Wat er continu gemeten wordt
Proactief beheer is geen houding, maar een meetsysteem. Op elk relevant onderdeel van uw omgeving staat een agent of een controle die zich met vaste tussenpozen meldt. Blijft die melding uit, of komt er een waarde uit die buiten de afgesproken grens valt, dan ontstaat er een alert.
Infrastructuur en servers
De onderdelen waar een storing meteen de hele organisatie raakt.
- Schijfruimte, geheugen en processorbelasting
- Back-upjobs, foutmeldingen en restorepunten
- Verlopende certificaten en licenties
Netwerk en verbindingen
Signalen die vaak al degraderen voordat iets echt uitvalt.
- Beschikbaarheid van firewall, switches en access points
- Pakketverlies en latency op de internetverbinding
- Firmware- en patchniveau van apparatuur
Werkplekken
Klachten over trage laptops zijn meestal meetbaar te maken.
- Schijfgezondheid, batterijstatus en temperatuur
- Update- en antivirusstatus per apparaat
- Terugkerende crashes en trage opstarttijden
De signalen die een storing aankondigen
Onderstaande voorbeelden komen uit de dagelijkse praktijk. Ze lijken klein, maar het zijn precies de meldingen die een dag uitval schelen.
| Signaal | Wat het vaak betekent | Wat er dan gebeurt |
|---|---|---|
| Systeemschijf boven 85 procent gevuld | Updates gaan mislukken en de server loopt binnen weken vast | Opschonen of uitbreiden in een gepland onderhoudsvenster |
| SMART-meldingen op een harde schijf | De schijf gaat op korte termijn defect | Preventief vervangen terwijl de omgeving nog draait |
| Back-upjob twee nachten op rij mislukt | Er is op dit moment geen bruikbaar herstelpunt | Direct onderzoek, want dit raakt uw hele herstelstrategie |
| Certificaat verloopt binnen dertig dagen | Website, VPN of mailflow valt op de vervaldatum uit | Vernieuwen en uitrollen voor de deadline |
| Oplopend pakketverlies op de WAN-verbinding | De lijn of de apparatuur degradeert | Melding bij de provider, onderbouwd met meetgegevens |
| UPS-batterij aan het einde van zijn levensduur | Bij de eerste stroomstoring valt de server hard uit | Batterij vervangen voor het stormseizoen |
| Herstarts buiten het onderhoudsvenster | Hardware-, voeding- of geheugenprobleem | Logs analyseren voordat het apparaat definitief uitvalt |
Dat tweede signaal over de back-up is het belangrijkste van de rij. Een back-upschema is alleen waard wat de laatste geslaagde run waard is; zie ook de 3-2-1 backup rule uitgelegd en onze back-up en disaster recovery.
Een alert is nog geen oplossing
Monitoring aanzetten is een middag werk. Er waarde uit halen is een proces. Zonder dat proces krijgt u vooral een mailbox vol meldingen die niemand meer leest, en dat is gevaarlijker dan geen monitoring, omdat het schijnzekerheid geeft. Wat er minimaal geregeld moet zijn:
- Drempelwaarden per systeem in plaats van standaardwaarden. Een testserver op 90 procent schijfgebruik is geen incident, uw bestandsserver wel.
- Ruis actief opruimen. Elke melding die drie keer geen actie opleverde, is een verkeerd ingestelde drempel.
- Prioritering en escalatie: wie krijgt wat, binnen welke tijd, en wie wordt gebeld als er niemand reageert.
- Duidelijkheid over dekking buiten kantooruren. Monitoring die 24 uur per dag meet maar van negen tot vijf wordt bekeken, is precies dat.
- Elke alert eindigt in een ticket of een bewuste onderdrukking, zodat er achteraf navolgbaar is wat er gebeurd is.
Bij werkplekbeheer en endpoint management zit dit proces standaard in de dienst, inclusief maandelijkse rapportage over wat er gemeten en opgelost is.
Monitoring is geen securitymonitoring
Een belangrijk misverstand: beschikbaarheidsmonitoring vertelt u of systemen werken en presteren, niet of iemand zich in uw omgeving heeft genesteld. Een aanvaller zorgt er juist voor dat alles normaal blijft draaien. Detectie van verdacht gedrag vraagt andere middelen: endpointdetectie, logverzameling en analyse door mensen die daar continu naar kijken.
Dat zijn dus twee aparte lagen die u beide nodig heeft. Zie managed detection and response en incident response voor de securitykant, en netwerkmonitoring voor de beschikbaarheidskant.
Zes vragen aan uw IT-partner
Vrijwel elke IT-dienstverlener noemt zichzelf proactief. Deze vragen maken snel duidelijk wat daar in de praktijk achter zit.
- Wat wordt er precies gemonitord, en wat expliciet niet? Vraag om een lijst, niet om een geruststelling.
- Wat is de afgesproken reactietijd, en is dat ook een hersteltijd? Dat zijn twee verschillende afspraken.
- Wie kijkt er buiten kantooruren naar de meldingen, en hoe verloopt de escalatie ’s nachts?
- Ontvang ik een maandrapportage die ik aan de directie kan laten zien, met opgeloste en voorkomen incidenten?
- Welke acties voert u zelfstandig uit, en waarvoor vraagt u eerst toestemming?
- Hoeveel drempelwaarden zijn het afgelopen jaar bijgesteld? Een partij die daar geen antwoord op heeft, tunet niet.
Van storingen naar onderhoud
Het doel van proactief beheer is niet dat er nooit meer iets stukgaat, maar dat vervanging en onderhoud op een gepland moment gebeuren in plaats van op het slechtst mogelijke. Wij brengen in kaart wat er in uw omgeving nu wel en niet gemeten wordt, en wat de eerste tien controles zijn die het meeste opleveren.
Geef een reactie