Eindejaarsservercontrolelijst: 10 essentiële instellingen

10 serverinstellingen die je aan het einde van het jaar moet controleren

(om te voorkomen dat er iets misgaat)

“Is er iets speciaals dat je aan het einde van het jaar moet controleren?” Kortom: ja, er is.

Het einde van het jaar maakt de server niet bijzonder. Het maakt de mensen wel.

Minder personeel vanwege vakantie en feestdagen
Verstoorde trafficpatronen
Een losser gevoel van urgentie

Daarom is het einde van het jaar vaak de periode met de hoogste kans op incidenten. Deze tekst is geen “doe dit omdat het einde van het jaar is”‑checklist, maar een realistische lijst om te voorkomen dat er tijdens de feestdagen iets misgaat.

1. Schijfruimte en loggroei

Het einde van het jaar betekent niet dat logs minder worden.

Controleer vooral:

Gebruik van /var/log
Logrotatie-instellingen van de applicatie
Grootte van Docker‑containerlogs (of ze oneindig groeien)

Een server met een volle schijf stopt zonder waarschuwing. Wat normaal “een beetje kan” is, kan tijdens de feestdagen een echte storing veroorzaken.

2. Backups: niet alleen bestaan, maar herstellen

Het belangrijkste is niet dat er een backup bestaat, maar dat je er daadwerkelijk van kunt herstellen.

Voer vóór het einde van het jaar minstens één keer het volgende uit:

Controleer of de nieuwste backup bestaat
Verifieer of het archief niet beschadigd is
Herstel de backup in een testomgeving

Zorg dat je de eerste taak van het nieuwe jaar niet begint met “oh, de backup is kapot”.

3. SSL/TLS‑certificaatvervaldatum

Het einde van het jaar en het begin van het nieuwe jaar zijn een veelvoorkomende periode voor certificaat‑verval‑incidenten.

Controleer:

Of Let’s Encrypt‑automatische vernieuwing daadwerkelijk werkt
Of cron‑ of systemd‑timer niet is uitgeschakeld
Of er geen fouten zijn in de recente vernieuwinglogs

De gedachte “automatisch vernieuwen, dus alles oké” is een typische trigger voor storingen.

4. Firewall‑regels en “tijdelijk” geopende poorten

Na een jaar serverbeheer blijven er vaak tijdelijke instellingen achter.

Poorten die voor tests zijn geopend
Tijdelijk geopende IP‑adressen
Niet meer gebruikte service‑poorten

Deze tijdelijke instellingen worden na verloop van tijd een beveiligingslek omdat niemand meer weet waarom ze er zijn. Het einde van het jaar is een goede tijd om ze op te ruimen.

5. SSH‑toegang en sleutelbeheer

Invasies tijdens de feestdagen worden vaak te laat ontdekt.

Daarom is het verstandig om SSH‑instellingen strikt te houden:

Uitgeschakelde wachtwoord‑login
Verwijder ongebruikte SSH‑sleutels
Verwijder sleutels van vertrokken medewerkers of freelancers
Zorg dat beheerders alleen de minimale rechten hebben

De optimistische gedachte “niemand is geïnteresseerd in onze server” is in de beveiliging bijna altijd fout.

6. Cron/Planner‑fouten die stilletjes falen

Cron, systemd‑timer en andere planners falen vaak stil.

Controleer:

Of er geen fouten zijn in recente uitvoerlogs
Of er geen oude jobs zijn die al lang falen
Of er geen onnodige jobs meer draaien

Een kapotte planner aan het einde van het jaar blijft vaak ook in het nieuwe jaar kapot.

7. Resource‑gebruik: niet het gemiddelde, maar de piek

Het einde van het jaar heeft vaak een grotere variabiliteit in traffic.

Tijdelijke pieken in traffic
Abnormale bot‑ of crawler‑toegang
Feestdagenpatronen in bepaalde landen

Daarom moet je monitoring ook kijken naar de piek, niet alleen het gemiddelde.

CPU‑ en geheugenpieken
DB‑verbindingen, wachtrijlengte
Gelijktijdige gebruikers, sessies

“Normaal is oké” is tijdens de feestdagen geen geruststelling.

8. Status van afhankelijkheden

Een server kan prima zijn, maar als een afhankelijkheid uitvalt, stopt de service.

Voorbeelden:

Redis / Memcached
Message brokers (Kafka, RabbitMQ, SQS, etc.)
Externe API’s (betalingen, authenticatie, notificaties)
Bestand/afbeeldingsopslag

Deze services hebben vaak ook veel onderhoud, deployments en periodieke taken. Een storing kan leiden tot “onze logs zijn schoon, maar de service werkt niet”. Controleer ook de statuspagina’s en alarmkanalen.

9. Test of foutmeldingen echt aankomen

Het hebben van een foutmeldingssysteem is niet hetzelfde als dat de meldingen daadwerkelijk binnenkomen.

Forceer een fout en controleer of je een melding krijgt
Controleer e‑mail/Slack/Webhook‑meldingen
Controleer of een severity‑filter de melding blokkeert

Dit is vaak de grootste oorzaak van “we wisten niet dat er een storing was”.

10. Document met “waar te beginnen bij een probleem”

Dit is geen instelling, maar een document.

Lijst van belangrijke services
Toegangsmethoden voor server/container
Loglocaties (nginx, app, DB, queue, etc.)
Herstart/rollback‑procedures
Noodprocedures

Een dergelijk document kan het verschil maken tussen een hard mode en een normale mode bij het oplossen van een storing.