De knop ‘Implementeren’ is groen. De projectmanager kondigt de upload om 14.00 uur aan. Om 14.20 uur reageert de site, maar de transactionele e-mails komen nog steeds van de oude server, het certificaat heeft betrekking op het verkeerde domein en niemand heeft de ondersteuning op de hoogte gebracht dat er een nieuwe stroom tickets aankomt. Om zes uur 's avonds vraagt het management om een rollback, die niemand binnen twee uur weet uit te voeren.
De overstap naar productie is een organisatorische gebeurtenis, geen code-push. Deze checklist koppelt wat de technologie doet en wat het bedrijf moet begrijpen – zonder onnodig jargon, zonder de onderdelen te vergeten die pijn doen: DNS, MX-records, cookies, facturering.
Vóór de grote dag: zakelijke afstemming
Een vergadering van dertig minuten is voldoende als het een gedeeld document van één pagina oplevert. Elke regel moet een schriftelijk antwoord hebben: het onderhoudsvenster (datum, tijd, zone, die vier uur beschikbaar blijft), drie meetbare succescriteria (verbinding OK, testbetaling OK, serverfoutpercentage minder dan één procent), de beslisser en de rollback-procedure, het communicatieplan (e-mail van de klant, statuspagina, ondersteuningsbrief) en de beperkingen op de gegevens (basismigratie, bevriezing van schrijfbewerkingen).
Als het bedrijf backtracking niet in één zin kan uitleggen, ben je er nog niet klaar voor.
Dit document is geen formaliteit: het verhindert dat een directeur kan aankondigen “alles staat online” terwijl de bevestigingsmails nog steeds niet uitgaan.
Technische checklist: infrastructuur en DNS
Aan de kant van de infrastructuur controleert u of er een recente productieback-up bestaat en of er in de afgelopen zeven dagen een herstel is getest. De productieomgeving moet aansluiten bij de staging (PHP-versies, extensies, geplande taken). Productiegeheimen moeten gescheiden zijn en mogen nooit uit een ontwikkelingsbestand worden gekopieerd. Monitoring moet waarschuwen voor serverfouten, schijfruimte en het verlopen van certificaten. Logboeken moeten gecentraliseerd of toegankelijk zijn zonder drie servers te doorzoeken.
Aan de DNS- en certificatenkant verlaagt u de TTL vierentwintig tot achtenveertig uur vóór de overstap. Documenteer de A-, AAAA- en CNAME-records met een plan om terug te keren naar het oude IP-adres. Als de e-mail van server verandert, controleer dan MX, SPF, DKIM en DMARC. Het TLS-certificaat moet alle hostnamen (www en rootdomein) dekken.
Aan de applicatiekant voer je basismigraties uit met een rollback-script voor het geval er iets misgaat. Wis of warm de cache op, afhankelijk van de gekozen strategie. Gebruik functievlaggen om geleidelijk in te schakelen. Stel een statuscontrolepunt (/health) beschikbaar voor de load balancer.
D-Day: volgorde en rollen
Zestig minuten voor de omschakeling: bevriezing van de inhoud, laatste back-up, bevestiging van het oproepteam. Om H-uur: DNS-omschakeling of verkeerwisseling; houd de verspreiding in de gaten met externe tools, niet alleen vanaf uw bureaublad. Een kwartier later: geautomatiseerde tests en handmatig bedrijfsproces (bestelling, registratie). Een uur later: beoordeling van de statistieken en beslissing om door te gaan of terug te gaan. Vierentwintig uur later: verhoog de DNS TTL en houd een korte autopsie, zelfs als dit lukt.
Noem de rollen: incidentcommandant (beslist over rollback), technisch manager, communicatie, business validator. Zonder namen wacht iedereen tot iemand anders beslist.
Wat de niet-technische persoon moet horen
Leg uit zonder te infantiliseren: “We veranderen waar de site op internet staat – niet alleen het ontwerp. » “DNS-propagatie kan tot X uur duren ondanks een lage TTL. » “Backtracking brengt de oude site terug, niet een tussenversie. » “Het eerste uur is verbeterde monitoring — geen gegarandeerde storing. »
Deze zinnen voorkomen misverstanden zoals “de site is online dus alles werkt” terwijl het betaal- of e-mailproces nog steeds niet werkt.
De top: succesvolle go-live = niemand merkt het – mislukte go-live = iedereen
Marketing telt de confetti. De operatie omvat de volledige trajecten: registratie, betaling, e-mail, administratie, partner-API.
Beslis en ga vooruit zonder blinde vlek
Schrijf een document van één pagina voor het bedrijf en een technische checklist, ondertekend door het team. Test het terugdraaien van de enscenering door het te timen. Als het meer dan een uur duurt, corrigeer dit dan vóór de grote dag. Korte ondersteuning met waarschijnlijke incidenten en typische reacties. Stel een communicatieplan op als de verslechtering langer duurt dan dertig minuten. Houd achtenveertig uur later een autopsie: drie punten om te behouden, drie om te verbeteren.
Zie blue-green deployment en application health check. Vergelijk hosts via de overzicht.
Veelgestelde vragen
Wat is het verschil tussen enscenering en productie?
Productie bedient echte gebruikers met een uptime-verplichting, geteste back-ups, monitoring van waarschuwingen en een gedocumenteerde terugdraaiprocedure. Staging reproduceert de configuratie – niet de daadwerkelijke belasting, noch altijd correct geanonimiseerde gegevens.
Hoe lang vóór de livegang moet u de DNS TTL verlagen?
Vierentwintig tot achtenveertig uur vóór de overschakeling verhoogt u de TTL naar 300 seconden. Hermonteer het na stabilisatie om de belasting van de DNS-servers te verminderen.
Wat moet een niet-technische projectmanager begrijpen?
Het onderhoudsvenster, het resterende risico, wie beslist wanneer er moet worden teruggedraaid, het communicatiekanaal in geval van een incident en meetbare succescriteria – niet een simpel ‘het ziet er goed uit’.
Is een geschreven rollback-runbook vereist?
Ja – stappen genummerd, verantwoordelijke personen genoemd, geschatte duur en minstens één keer getest tijdens de enscenering. Een geïmproviseerde terugdraaiing kost meer dan het initiële incident.
De productie begint wanneer het volledige klanttraject stand houdt – niet wanneer de continue integratiepijplijn groen wordt.