PHP updaten zonder uitval: een werkbaar draaiboek

Begin met een besluit, niet met een installatie

Een updateverzoek als ‘zet PHP even goed’ laat te veel open. Welke website bedoelen we? Alleen het hoofddomein of ook het klantportaal? Wie mag de wijziging uitvoeren? Wanneer is het resultaat goed genoeg? Zonder antwoorden kan een technisch geslaagde wijziging alsnog een zakelijke mislukking worden.

Wij zouden vooraf één wijzigingskaart maken. Daarop staan het doel, de betrokken omgevingen, de uitvoerder, de beslisser en het tijdvak. Niet omdat iedere kleine website een zwaar proces nodig heeft, maar omdat iemand tijdens een storing binnen een minuut moet kunnen begrijpen wat er gebeurde.

Schrijf ook op wat buiten de wijziging valt. Een PHP-update is geen goed moment om tegelijk een nieuw thema, een betaalprovider en een compleet formulierpakket te introduceren. Als die wijzigingen noodzakelijk zijn voor compatibiliteit, behandel je ze als afzonderlijke stappen met eigen controles. Dan blijft de oorzaak van een fout beter te herleiden.

Maak onderscheid tussen haast en improvisatie

Bij een urgente beveiligingsmelding kan wachten op een ideaal onderhoudsmoment onverstandig zijn. Dat betekent niet dat je alle voorbereiding weglaat. Het betekent dat je de voorbereiding verkleint tot de controles die echt nodig zijn om verantwoord te handelen.

Denk aan een minimale set: actuele herstelmogelijkheid, bevestigde doelversie, bereikbare beheerder, controle van de belangrijkste klantactie en een vooraf afgesproken stopbesluit. Wat je niet binnen dat tijdvak kunt bevestigen, noteer je als onzekerheid. Als de bestaande omgeving onaanvaardbaar kwetsbaar blijft, kan tijdelijk beperken of afschermen een betere tussenstap zijn dan onbeperkt doordraaien. Die keuze hoort bij de eigenaar en de verantwoordelijke beheerder.

Breng de echte PHP-omgeving in kaart

Eén domeinnaam zegt nog niet hoeveel uitvoeromgevingen erachter zitten. Een website kan een publieke voorkant, een beheergedeelte, geplande taken en een losse importfunctie hebben. Noteer per onderdeel waar het draait en wie de instellingen beheert.

Gebruik geen gegokt versienummer uit een oude e-mail. Vraag de actuele webomgeving op via het hostingpaneel, een afgeschermde beheervoorziening of de host. Een uitlezing in een terminal kan een ander uitvoerpad vertegenwoordigen dan een webverzoek. PHP maakt zelf onderscheid tussen interfaces zoals CLI en FPM; dat is precies waarom de context van een versiemeting ertoe doet. PHP-documentatie over SAPI.

Een lokaal commando zoals php -v kan dus nuttige informatie geven, maar is geen zelfstandig bewijs dat de publieke website dezelfde runtime gebruikt. Zet ook geen openbaar diagnostiekbestand met configuratiedetails op je website om dit snel op te lossen. Vraag om een controle die niet onnodig serverinformatie publiceert.

Inventariseer meer dan alleen het nummer

Vraag naast de PHP-versie naar de gebruikte extensies, belangrijke limieten, geplande taken en eventuele aparte processen. Je hoeft als ondernemer niet ieder technisch veld te begrijpen. Je wilt wel dat de beheerder kan verklaren welke instellingen behouden moeten blijven.

Een fictief voorbeeld: een opleider gebruikt een website voor aanvragen en een nachtelijke import voor cursustijden. De gewone pagina's werken na de update. De import blijkt echter aan een ander uitvoerpad gekoppeld. Als niemand die taak op de wijzigingskaart heeft gezet, wordt het probleem pas zichtbaar wanneer nieuwe cursusdata ontbreken.

Laat daarom minstens de volgende onderdelen expliciet beoordelen:

• De runtime voor publieke webverzoeken.
• Het beheer en eventuele afzonderlijke applicaties.
• Geplande taken, imports en wachtrijverwerking.
• De extensies die formulieren, afbeeldingen of koppelingen gebruiken.
• De partij die kan bevestigen dat een nieuwe configuratie actief is.

Onbekend is een geldige uitkomst van deze inventarisatie. ‘Zal wel hetzelfde zijn’ is dat niet.

Kies een doelversie met een reden

De hoogste versie in een keuzelijst is niet automatisch de juiste bestemming voor deze wijziging. De keuze moet passen bij de beveiligingsmelding, ondersteuning door de host en compatibiliteit van de applicatie. Houd de actuele versiedetails bij het incidentoverzicht; kopieer ze niet naar allerlei losse draaiboeken die later verouderen.

Bij een overgang naar een andere PHP-reeks horen andere controles dan bij een gerichte patch binnen de huidige reeks. De officiële migratiegidsen beschrijven wijzigingen die bestaande code kunnen raken en vragen om testen voordat je productie omschakelt. Gebruik de gids voor jouw gekozen overgang, niet willekeurig de nieuwste. Voorbeeld van een officiële PHP-migratiegids.

Wij willen bij de doelversie één korte motivatie zien: welk probleem lossen we op, welke leverancier bevestigt ondersteuning en welke resterende onzekerheid testen we? Daarmee voorkom je dat ‘de host adviseert het’ een eindantwoord wordt zonder te weten waarop dat advies rust.

Vraag gericht door bij de host

Een nuttig bericht is concreet: ‘Welke runtime gebruikt deze webomgeving nu, welke ondersteunde patch is voor onze omgeving beschikbaar, en hoe verifiëren jullie dat de wijziging ook voor de gekoppelde taken geldt?’ Dat geeft een veel bruikbaarder antwoord dan alleen vragen of de hosting veilig is.

Vraag ook wat de host uitvoert en wat jij zelf moet doen. Het installeren van een pakket, omschakelen van een website en controleren van de applicatie kunnen bij verschillende partijen liggen. Spreek af wie elk onderdeel afrondt, zodat er geen stil gat tussen de werkzaamheden blijft.

Leg vast wat vandaag goed werkt

Voor je iets wijzigt, voer je een kleine nulmeting uit. Niet om een uitgebreid rapport te produceren, maar om nieuwe problemen te onderscheiden van bestaande problemen. Een formulier dat voor de update al geen bevestiging verstuurde, verdient aandacht, maar mag niet ongemerkt het oordeel over deze wijziging vervuilen.

Kies de routes waarop de onderneming leunt. Voor een dienstverlener zijn dat bijvoorbeeld contact, offerteaanvraag en afspraak. Voor een ledenomgeving zijn inloggen, toegang tot betaalde inhoud en uitloggen belangrijker. Een webshop heeft daarnaast een eigen testaanpak nodig voor voorraad, prijsberekening en de betaalomgeving.

Gebruik herkenbare testgegevens zonder echte klantinformatie. Leg vast waar een test mag aankomen en voorkom dat een proefaanvraag een verkoopmedewerker of klant onbedoeld in een echte opvolgflow zet. Wanneer een test een externe handeling zou starten, moet daarvoor apart toestemming zijn of een geschikte testomgeving beschikbaar zijn.

Maak acceptatie meetbaar

‘De website ziet er goed uit’ is onvoldoende als acceptatiecriterium. Maak van iedere controle een waarneembare uitkomst. Bijvoorbeeld: het formulier accepteert geldige invoer, toont de bevestiging en maakt precies één herkenbaar testrecord in het afgesproken systeem.

Een bruikbare testkaart heeft vijf velden: handeling, verwacht resultaat, werkelijk resultaat, tijdstip en bewijs. Bewijs kan een korte schermafbeelding zijn of een verwijzing naar een beveiligd log. Sla geen wachtwoorden, sessiesleutels of volledige klantgegevens op in de kaart. Je bewijst de werking, niet hoeveel gevoelige informatie je kunt verzamelen.

Test in een omgeving die genoeg op productie lijkt

Een stagingomgeving is pas nuttig als je weet waarin zij overeenkomt met productie. Een oude kopie met andere plugins, lege instellingen en ontbrekende koppelingen kan een vals gevoel van zekerheid geven. Noteer daarom de relevante verschillen naast de testuitkomsten.

Onze praktische ondergrens: dezelfde applicatieversie, hetzelfde relevante pluginpakket, vergelijkbare PHP-instellingen en voldoende representatieve gegevens. Persoonsgegevens horen niet automatisch meegekopieerd te worden. Gebruik waar mogelijk geanonimiseerde of synthetische gegevens die dezelfde functies doorlopen.

Scherm de omgeving af voor onbevoegden. Zorg bovendien dat zij niet zelfstandig echte betaalacties, mails, sms-berichten of voorraadmutaties uitvoert. Een testkopie die hetzelfde klantcontact herhaalt als de live omgeving kan meer schade veroorzaken dan de fout die je probeert te voorkomen.

Test eerst de smalle wijziging

Verander eerst alleen wat voor de geplande PHP-overgang nodig is. Voer de acceptatiekaart uit en bekijk de relevante foutmeldingen. Pas als je weet welke problemen bij die stap ontstaan, beslis je of een pluginupdate of codeaanpassing nodig is.

Een fictief installatiebedrijf heeft een aanvraagformulier met een fotoupload. De tekstvelden werken op staging, maar een grotere testfoto mislukt. De juiste conclusie is niet meteen dat ‘PHP niet werkt’. De beheerder onderzoekt eerst of de relevante extensie, limiet of applicatiecode anders is. Het verschil wordt opgelost en dezelfde test wordt herhaald.

Zo blijft het onderzoek begrensd. Je voert geen willekeurige wijzigingen door totdat iets toevallig weer lijkt te werken. Je verzamelt een verklaring die je ook bij de productieovergang kunt gebruiken.

Beoordeel waarschuwingen op functie en risico

Niet iedere melding betekent hetzelfde. Een zichtbare foutpagina, een gemiste achtergrondtaak en een waarschuwing over verouderde code hebben verschillende gevolgen. Laat de beheerder de melding koppelen aan een functie en een vervolgstap.

Wij gebruiken hiervoor drie praktische vragen. Blokkeert dit een noodzakelijke klantactie? Kan dit gegevens beschadigen of ongewenst delen? Is er een duidelijke verklaring en een eigenaar voor herstel? Die vragen zijn nuttiger dan een scherm vol meldingen zonder context doorsturen.

Maak foutmeldingen niet publiek om gemakkelijker te kunnen testen. Laat technische details in een passend afgeschermd log beoordelen. De bezoeker heeft een begrijpelijke foutmelding nodig; de beheerder heeft voldoende diagnostiek nodig. Dat zijn twee verschillende doelgroepen met verschillende informatiebehoeften.

Wanneer een waarschuwing niet blokkerend is, verdwijnt zij niet automatisch van de takenlijst. Leg vast waarom de livegang verantwoord wordt geacht en wanneer de onderliggende oorzaak wordt aangepakt. Tijdelijk accepteren is een expliciet besluit, geen vergetelheid.

Bereid de productieovergang voor

Het onderhoudsmoment moet passen bij zowel bezoekers als beheerders. Een zeer rustig uur is weinig waard als niemand beschikbaar is om een probleem op te lossen. Kies een tijdvak waarin de impact beperkt is en de benodigde mensen bereikbaar zijn.

Spreek vooraf af wie communiceert als het langer duurt. Een korte, eerlijke melding met een bruikbaar contactalternatief helpt meer dan stilte. Beloof geen exacte hersteltijd die je niet kunt onderbouwen. Geef wel aan wanneer de volgende update komt en welke handelingen tijdelijk niet mogelijk zijn.

Voor omgevingen die tijdens de omschakeling nieuwe gegevens ontvangen, moet je bepalen hoe je daarmee omgaat. Een aanvraag van vlak voor de wissel mag niet verdwijnen doordat iemand daarna een oudere database terugzet. De data-aanpak hoort daarom bij het draaiboek, niet alleen bij een technisch noodplan.

De laatste controle voor de wijziging

Loop vlak voor uitvoering deze beslisroute door:

1. Is duidelijk welke omgeving en runtime worden aangepast?
2. Is de doelversie passend en beschikbaar bevestigd?
3. Is de afgesproken herstelmogelijkheid aantoonbaar bruikbaar?
4. Zijn de kritieke tests uitgevoerd en de beperkingen bekend?
5. Zijn uitvoerder en beslisser bereikbaar?
6. Is het stopscenario veilig, ook wanneer de oude runtime kwetsbaar is?

Bij een ontbrekend antwoord volgt geen automatische goedkeuring. De verantwoordelijke beslist of eerst een ontbrekende controle wordt afgerond, de aanpak wordt verkleind of tijdelijk bescherming nodig is. Dit is precies het moment waarop voorbereiding tijd bespaart.

Controleer na omschakelen de werkelijke keten

Na de wijziging kijk je eerst of de bedoelde runtime daadwerkelijk actief is. Daarna herhaal je de acceptatiekaart. Gebruik zo veel mogelijk dezelfde handelingen als in de nulmeting, zodat de uitkomsten vergelijkbaar blijven.

Controleer niet alleen de homepage. Een nette voorpagina kan blijven verschijnen terwijl een formulier of taak faalt. Open de relevante functies in een schone sessie, voer de afgesproken test uit en controleer de bestemming. Als een aanvraag in een CRM hoort te komen, eindigt de test niet bij het bedankscherm.

Zet de resultaten direct op de wijzigingskaart. Een mondeling ‘lijkt goed’ verdwijnt snel wanneer later een collega vraagt wat precies is getest. Een korte registratie met route, uitkomst en tijdstip maakt de overdracht veel sterker.

Wacht ook op uitgestelde functies

Een geplande taak die elk uur draait, kun je niet beoordelen op basis van een controle van twee minuten. Je kunt wel vóór de wijziging afspreken hoe zij veilig getest wordt en wanneer je de normale uitvoering opnieuw controleert.

Houd daarom twee statussen aan: directe acceptatie afgerond en vervolgcontrole afgerond. De eerste betekent dat de belangrijkste gebruikersroutes werken. De tweede betekent dat ook de afgesproken achtergrondprocessen zijn beoordeeld. Daarmee voorkom je dat een wijziging te vroeg als volledig klaar wordt gemeld.

Rollback betekent niet automatisch terug naar kwetsbaar

Een terugweg moet vooraf beschreven zijn, maar terugzetten is geen doel op zichzelf. Als de vorige PHP-versie aantoonbaar kwetsbaar is, kun je niet zonder meer terugschakelen en de website weer volledig openbaar maken. Dan herstel je beschikbaarheid door een bekend beveiligingsprobleem opnieuw te introduceren.

Ons uitgangspunt is een veilige herstelkeuze: de fout in de nieuwe omgeving herstellen, overschakelen naar een andere gepatchte en geteste omgeving, of tijdelijk functies afschermen terwijl het probleem wordt opgelost. Welke optie mogelijk is, hangt af van de inrichting en de ernst van de situatie.

Een oude omgeving kan soms afgeschermd nodig zijn voor onderzoek of gegevenscontrole. Dat is iets anders dan haar opnieuw publiek aanbieden. Leg expliciet vast welke toegang is toegestaan, wie dat besluit neemt en welke voorwaarde geldt voor heropening.

Houd gegevensherstel apart van codeherstel

Het terugzetten van applicatiebestanden en het terugzetten van een database zijn verschillende beslissingen. Bij een databaseherstel kun je gegevens verliezen die na het herstelpunt zijn binnengekomen. Bij een codewijziging moet je weten of de database ondertussen is veranderd.

Vraag daarom niet alleen ‘hebben we een backup?’, maar ook ‘welke onderdelen herstellen we en welke nieuwe gegevens moeten behouden blijven?’ Voor een uitgebreider herstelproces kun je verder met backup en hersteltest. Dat artikel behandelt het bewijs dat terugzetten ook echt lukt.

Een uitgewerkt fictief onderhoudsmoment

Stel: een klein adviesbureau ontvangt aanvragen via een formulier, laat bezoekers afspraken aanvragen en publiceert wekelijks artikelen. De host beheert PHP, een webbouwer beheert WordPress en de eigenaar beslist over tijdelijke onbereikbaarheid. Dit is een verzonnen werksituatie, geen klantresultaat.

De webbouwer maakt eerst een kaart met drie kritieke routes. Voor iedere route is bekend waar de aanvraag hoort te verschijnen. De eigenaar kiest een testadres dat niet in een automatische campagne terechtkomt. De host bevestigt welke runtime de website gebruikt en hoe de doelversie wordt geactiveerd.

Op een afgeschermde kopie wordt de wijziging getest. De aanvraagroute werkt, maar de afspraakbevestiging geeft een fout. De koppeling blijkt een aanpassing nodig te hebben. Die aanpassing wordt apart vastgelegd, waarna dezelfde test slaagt. Pas daarna wordt een productievenster gekozen.

Tijdens de omschakeling controleert de host de runtime en voert de webbouwer de afgesproken routes uit. De eigenaar ziet de herkenbare testaanvragen terug en bevestigt de zakelijke werking. Een latere taakcontrole staat nog open. Het verslag zegt daarom niet ‘alles klaar’, maar benoemt precies die resterende controle.

Dit proces heeft geen wonderstap. De winst zit in duidelijke grenzen: één wijziging, herkenbare tests, een veilige herstelroute en iemand die de uitkomst beoordeelt.

Wat je na afloop bewaart

Bewaar een compact onderhoudsverslag op een plek waar de opvolgende beheerder het kan vinden. Daarin staan de datum, betrokken omgeving, oorspronkelijke en nieuwe runtime, aanleiding, uitgevoerde controles, bekende beperkingen en verantwoordelijke personen of rollen.

Laat gevoelige gegevens weg. Een bewijsverwijzing naar een beveiligd beheersysteem is beter dan een rapport met sessiecookies of klantinformatie. Geef ook een volgende controledatum of gebeurtenis aan, bijvoorbeeld een geplande pluginvervanging die nog effect kan hebben op de compatibiliteit.

Een goed verslag voorkomt dat je bij de volgende melding opnieuw vanaf nul begint. Je weet welke processen belangrijk zijn, wie de hosting beheert en waar eerdere tests te vinden zijn. Daarmee wordt onderhoud een herhaalbare routine in plaats van steeds een kleine crisis.

Zorg voor overdracht als de uitvoerder vertrekt

Een onderhoudsmoment kan technisch klaar zijn terwijl de overdracht nog ontbreekt. Spreek daarom af wie de website na het werkvenster in de gaten houdt. Dat hoeft geen permanente bewaking door een mens te zijn. Het moet wel duidelijk zijn waar een foutmelding terechtkomt en wie reageert als een medewerker de volgende ochtend iets afwijkends ziet.

Geef die persoon een korte samenvatting in gewone taal. Welke functies zijn getest? Welke taak moet nog op haar normale tijdstip draaien? Welke wijziging mag voorlopig niet zonder overleg worden uitgevoerd? Daarmee voorkom je dat een collega uit goede bedoelingen opnieuw instellingen omschakelt en het onderzoek moeilijker maakt.

Zet bij open punten een eigenaar en een concreet eerstvolgend controlemoment. ‘Later nakijken’ is te vaag. ‘Na de eerstvolgende geplande import controleren of nieuwe items zichtbaar zijn’ is toetsbaar. Als die controle niet lukt, verandert de status naar niet bevestigd. Een eerdere geslaagde test blijft dan nuttig bewijs, maar wordt geen alibi om het open punt te vergeten.

Deze overdracht is ook belangrijk bij uitbesteed beheer. De host kan zijn technische taak afsluiten voordat jouw functionele controles klaar zijn. Laat beide partijen hun eigen onderdeel afronden en bewaar het gezamenlijke eindbeeld.

Veelgestelde vragen

Maak de eerstvolgende stap klein en concreet

Je hoeft niet alle hostingtechniek zelf te leren. Je moet wel kunnen vragen wat er draait, welke wijziging nodig is, hoe je de werking controleert en wat er gebeurt wanneer die controle faalt. Met die vier vragen wordt een PHP-update bestuurbaar.

Wil je dat we de verdeling tussen host, websitebouwer en jouw belangrijkste klantprocessen samen scherp krijgen? Plan een gesprek. Dan beginnen we bij de omgeving en de route die voor jouw bedrijf moet blijven werken.