Staging liegt
De vrijgave kwam uit staging, groen over de hele linie. Drie weken later brandt in productie een pad dat staging nooit heeft gezien.
- Datum
- Onderwerp
- Staging-pariteit
- Bronnen
- 2
- Leestijd
- 2 min
- Versie
- Vertaling
Het patroon ken ik uit veel setups: staging heet “net als productie, alleen kleiner”. Meestal klopt alleen de tweede helft van die zin.
Afbeelding als tekst
Pariteitstabel staging tegenover productie met vijf rijen: injection (sidecar ontbreekt of is verouderd tegenover geïnjecteerd, actuele revisie), policies (PERMISSIVE plus default-allow tegenover STRICT plus default-deny), egress (ALLOW_ANY tegenover REGISTRY_ONLY plus ServiceEntries), CP-revisie (rollout overgeslagen tegenover actuele revisie) en limits (geen of ruim, nauwelijks load tegenover krap ingesteld, onder echte load). De staging-kolom heeft per rij een rode afwijkingsmarkering, de productiekolom is de referentietoestand. Daaronder de pariteitschecklist: deze vijf punten per omgeving controleren, afwijkingen met de reden erbij documenteren. Pointe: Het goedkoopste incident is het incident dat in staging gebeurt.
De delta’s die ik het vaakst aantref, zitten in de mesh zelf. Vijf stuks, in de volgorde waarin ik ze in incident-calls tegenkom.
Injection. In staging draait de sidecar vaak helemaal niet of in een oudere variant, omdat de laatste rollout daar is overgeslagen. Wie zonder proxy test, test een ander netwerk.
Policies. AuthorizationPolicy en PeerAuthentication staan in staging vaak losser ingesteld: PERMISSIVE in plaats van STRICT, default-allow in plaats van default-deny (report #15). Een request die in staging doorkomt, zegt niets over de vraag of hij in productie überhaupt aankomt.
Egress. Is staging op het oude ALLOW_ANY blijven staan (report #16) en staat productie allang op REGISTRY_ONLY, dan meldt een externe aanroep in staging succes en loopt hij in productie tegen een muur aan, omdat de ServiceEntry ontbreekt.
Revisie. Twee omgevingen op twee verschillende control-plane-revisies (report #20) zijn twee verschillende meshes met een vergelijkbare naam.
Limits. In staging draait de sidecar zonder krappe resource limits en zonder echte load. In productie is dezelfde proxy krap ingesteld en zit hij tegen het plafond, onder de load die het verschil maakt. Wie de sidecar-kosten uit report #22 in staging meet, krijgt daarom keurige cijfers voor een ander systeem.
De meeste incidents die “alleen in productie reproduceerbaar” waren, ontpopten zich uiteindelijk als een (deel)verzameling van deze lijst, achteraf opgesteld na de ongewilde nachtdienst.
Een kopie van productie tot op de laatste byte is nooit realistisch. Realistisch is een pariteitschecklist voor deze vijf punten, plus een bewuste keuze: waar staging afwijkt, staat de afwijking met de reden erbij in het document. Al het andere is een incident dat op zijn productiedatum wacht.
De rekensom erachter is eenvoudig. Het goedkoopste incident is het incident dat in staging gebeurt. Elke afwijking die staging doorlaat, verhuist naar productie. Daar kost ze hetzelfde, alleen met massale feedback van klanten.
Staging die niet op zijn minst de mesh-configuratie van productie deelt, test niet jullie applicatie. Hij test een ander systeem dat toevallig dezelfde naam draagt.
Welke van de vijf delta’s treft jullie het meest: injection, policies, egress, revisie of limits?
