Veel storingen komen niet door code, maar door een instelling die iemand ooit met de hand heeft aangepast en daarna is vergeten. Met configuratiebeheer willen we op elk moment kunnen zeggen hoe een systeem is ingesteld, waarom en sinds wanneer.
Een sprekend voorbeeld
Dit klint misschien wat abstract. Laten we het daarom zo concreet mogelijk proberen te maken. We hadden laatst te maken met een probleem: gebruikers konden niet meer bij één van onze applicaties. Een kritiek probleem dus (zie incidentenbeheer). Wat bleek? De rate limit blokeerde alle gebruikers.
Maar dan denk je misschien? Wat is dit nu? Na wat debuggen kwamen we er achter dat de rate limit was gebaseerd op het interne IP-adres, en niet het externe-IP. (Oke, technisch verhaal, nginx etc). Kortom: we moesten wat configuratie aanpassen om dit op te lossen.
Het korte antwoord zou dan kunnen zijn: configuratie aangepast. Applicatie draait weer. Klant blij. Wij blij.
Echter: dit is natuurlijk niet de enige klant waar dit een probleem kan vormen!
Daarom houden we in een centraal register een configuragie-item bij. Deze foutieve configuratie passen we aan en vervolgens zorgen we dat de andere klant-applicaties ook aangepast worden!
Elke instelling is een configuratie-item (CI)
Een configuratie-item (CI) is een logisch geheel van instellingen met één functie, bijvoorbeeld:
- de instellingen van de webserver;
- die van de logverzameling;
- de beveiligingstooling;
- de geplande taken.
Ook de versies van geïnstalleerde pakketten horen erbij. Elk CI krijgt een eigenaar en een eigen versienummer, los van de andere.
Eén bron van waarheid
Voor elk item is vastgelegd wat de officiële bron is. Voor onze eigen infrastructuur is dat een centrale, versiebeheerde opslag, ingedeeld per onderdeel. Bij elk onderdeel staat een korte toelichting met in elk geval het versienummer. Is er een risico op compatibiliteitsproblemen met de applicatie, dan staan daar ook een wijzigingslog en de combinaties die we getest hebben.
Wijzigingen lopen daardoor via dezelfde review als onze code: voorstel, beoordeling, goedkeuring. Je ziet wie wat veranderde en kunt een eerdere versie terughalen.
Voor software van anderen gebruiken we alleen openbare, algemeen gebruikte pakketbronnen waar kwetsbaarheden gevolgd worden. Een eigen bron mag alleen als wijzelf of een directe partner die beheert. Wie iets installeert, controleert ook of de beveiligingsupdates erop zitten.
Weten wat waar draait. Naast de bron houden we een configuratiedatabase (CMDB) bij, onderdeel van ons overzicht van assets. Per productieserver staat daarin onder meer:
- van wie de server is en bij welk project hij hoort;
- in welke omgeving hij draait;
- welke applicatieversie erop staat en welke versie van elk CI;
- wie de laatste release uitvoerde en wanneer.
Zo kunnen we een server vergelijken met wat hij zou moeten zijn en zien we drift, het langzaam afwijken van de afgesproken situatie.
Wijzigen tijdens een release. Configuratie op productie veranderen we alleen binnen een productierelease, in het afgesproken venster. De engineer:
- haalt de goedgekeurde versie van het CI op uit de bron;
- controleert of de syntax klopt en of het CI past bij de applicatieversie die live gaat;
- past het toe, met de hand volgens vaste stappen of met een script;
- werkt de CMDB bij met de nieuwe versie, de verwijzing naar de bron, tijdstip, uitvoerder en bijbehorend wijzigingsverzoek.
Een stap overslaan komt ons duur te staan: een kloppende CMDB is de reden dat we later weten wat er draait.
Terugdraaien. Elk wijzigingsverzoek heeft zo nodig een terugdraaiplan. Veroorzaakt een nieuwe versie problemen, dan voeren we dat plan uit, zetten we de vorige versie terug uit de bron en passen we de CMDB aan. Is er downtime of een beveiligingsrisico geweest, dan volgt een nabespreking.
Uitzonderingen en handmatig ingrijpen. Soms moet je buiten de standaardweg om, bijvoorbeeld voor een extra back-up vóór een release of een herstel na een incident. Dat gebeurt met hogere rechten dan de instellingen eigenlijk bedoeld zijn. Zulke handmatige acties op productie, buiten een vaste procedure, leggen we vast in een actielogboek. Waar het kan plannen we ze vooraf en laat een tweede persoon ze goedkeuren (vier-ogenprincipe). Gereedschap zetten we zo in dat je niet per ongeluk de verkeerde omgeving raakt, bijvoorbeeld met duidelijke labels.
Netwerk op hoofdlijnen. Voor netwerken gelden dezelfde uitgangspunten. Ontwikkel-, test- en productieomgevingen houden we logisch gescheiden en toegang geven we met zo min mogelijk rechten. Thuis of onderweg werk je alleen op beheerde of goedgekeurde apparaten, met versleuteling, firewall en automatische updates, en je gebruikt voor toegang tot bedrijfssystemen alleen goedgekeurde beveiligde verbindingen.
Regelmatig nalopen. Bij een CI-review kijken we of het nog klopt, of er verouderde onderdelen weg kunnen en of bekende kwetsbaarheden zijn aangepakt. Dat hoort bij onze aanpak voor continu verbeteren: afwijkingen die we vinden, krijgen een eigenaar en worden rechtgezet. Dankzij de versies en de terugdraaiplannen kunnen we een server ook opnieuw opbouwen als dat nodig is.