Niet testen in productie? Test in productie!

Als u uw IT-beveiligingsstandaarden vijf of meer jaar geleden voor het laatst hebt bijgewerkt, is de kans groot dat ze niet goed aansluiten bij de realiteit van de huidige DevOps en site reliability engineering (SRE) – praktijken. Een bijzonder kleverig onderwerp is testen in de productie—en dus, testen met productiegegevens-omdat DevOps en SRE vervagen de lijn tussen wat is productie en wat niet; wat is een test en wat niet.

om een deel van de verwarring op te helderen, gaan we dieper in op deze vragen:

  • waarom scheiden we dev/test-en productiesystemen?
  • wat moeten we beheren volgens de hoge normen van een productiesysteem?
  • Waarom is testen op productiesystemen zo riskant?
  • waarom zouden we testen in productie?
  • hoe zit het met de productiegegevens?
  • Hoe kunnen we testen in productie minder riskant maken?

ik moet opmerken dat dit een opiniestuk is; het is gebaseerd op jaren van collectieve DevOps en testervaring, maar het is niet te lezen als een officiële IBM statement.

waarom scheiden we dev/test-en productiesystemen?

het is standaardpraktijk om ontwikkelings -, test-en productiesystemen verschillend te behandelen, ten minste vanuit een compliance-en risicomanagementstandpunt, voornamelijk omdat ze verschillende beveiligings -, gegevens-en privacycontroles hebben. Laten we een stap terug doen en nadenken over de historische redenen voor de verschillende houdingen ten opzichte van deze implementatieomgevingen.

onze productiesystemen zijn het belangrijkst omdat ze onze bedrijven en overheden runnen. Deze systemen dienen onze klanten en hebben een directe impact op de klanttevredenheid. Het is normaal dat de werkomgeving van een ontwikkelaar af en toe een paar uur ‘gebroken’ wordt, maar we moeten productiesystemen beheren volgens onberispelijke normen van kwaliteit, betrouwbaarheid en beschikbaarheid. Daarom is het cruciaal om de risico ‘ s voor onze productiesystemen te beperken. DevOps en SRE richten zich nog steeds op het vermijden van risico ‘ s, maar ze gebruiken verschillende risicobeperkende strategieën, in vergelijking met andere praktijken (zoals ITIL).

bovendien zijn productiesystemen bijzonder omdat ze toegang hebben tot productiegegevens. Productiegegevens moeten een betrouwbare bron van waarheid zijn, dus we moeten ze beschermen tegen corruptie. Productiegegevens bevatten waarschijnlijk ook informatie die we alleen met geautoriseerde gebruikers kunnen delen, zoals vertrouwelijke of persoonlijke gegevens, dus we moeten ervoor zorgen dat deze worden beschermd door authenticatie en autorisatie op productieniveau. Tot slot moeten we mogelijk een auditspoor bijhouden van toegang tot productiegegevens (aanmaken, lezen, bijwerken en verwijderen), wat niet nodig is voor dev/testsystemen.

1-productiesystemen.jpg

 afbeelding van een gegevensvergrendeling

productiesystemen worden om goede redenen strenger gecontroleerd en gecontroleerd.

we hebben ook een uitstekende zichtbaarheid en controle nodig over de huidige staat van onze productiesystemen. We monitoren ze zorgvuldig zodat we snel problemen kunnen detecteren, en wanneer problemen zich voordoen, maakt het kennen van de huidige configuratie van die systemen het gemakkelijker om snel te herstellen. De meeste mensen kunnen het niet schelen of een ontwikkelaar de configuratie-instellingen op hun persoonlijke laptop wijzigt, maar we vergrendelen productiesystemen tot een bekende configuratie en met veilige change controls op zijn plaats. Of we nu de configuratie vergrendelen via een change-control database of infrastructure-as-code, het doel is hetzelfde: zichtbaarheid en controle.

ten slotte, vergeet niet dat we dev/test-en productiesystemen anders beheren omdat er compliance-regels en-voorschriften zijn die specifiek gelden voor productiesystemen. Weinig dingen doden snelheid sneller dan onnodige lasten op onze dev/test omgevingen!

wat moeten we volgens de hoge normen van een productiesysteem beheren?

toen we begonnen na te denken over testen in de productie, realiseerden we ons al snel dat we begonnen met een aanname: het zou gemakkelijk moeten zijn om te bepalen wat wel en wat niet een productieomgeving is. Maar, zoals bij de meeste veronderstellingen, hadden we het mis. Ontwikkelaars en testers willen snel handelen; bij twijfel classificeren we systemen als dev / test in plaats van productie, zodat we niet te maken hebben met de overhead van het productiesysteem. Maar hoe weten we wanneer we productiecontroles moeten invoeren? Het is niet allemaal zwart-wit, maar er zijn verschillende overwegingen.

een paar van de meer duidelijke voorbeelden: we zijn het erover eens dat Ontwikkelaar laptops en omgevingen die specifiek zijn ontworpen voor testen (bijvoorbeeld integratietest, systeemtest, prestatietest) geen productiesystemen zijn. Bovendien is er een algemene consensus dat systemen die echte klanten bedienen met behulp van echte data, direct of achter de schermen, productiesystemen zijn. Er zijn ook systemen die we alleen intern gebruiken, die kritisch genoeg zijn voor de bedrijfsvoering van het bedrijf dat ze ook worden beschouwd als productiesystemen.

2-modernsystems.jpg

 beeld van een computer op een bureau

moderne softwareontwikkeling en leveringspraktijken kunnen de lijn tussen ontwikkelings -, test-en productiesystemen vervagen.

vaak hangt de lijn tussen “productie” en “niet-productie” echter af van uw unieke situatie en van uw gebruik van deze voorwaarden.:

  • Staging
  • Pre-productie
  • pre-live
  • Preview

uw staging omgeving, bijvoorbeeld, kan er een zijn waar u alleen tests tegen uitvoert, in welk geval het meer een testsysteem is. Aan de andere kant, uw staging omgeving zou kunnen zijn wat uw zakelijke partners gebruiken om nieuwe API ‘ s te testen voordat u ze vrij te geven. In dat geval moet je het beheren als een productiesysteem, voor de meeste doeleinden, omdat je verwacht dat het de echte gebruikerservaring van die API ‘ s simuleert. Misschien kun je wat meer downtime tolereren voor dat type server, maar je zou authenticatie en autorisatie van productiekwaliteit moeten gebruiken; je zou controles op je server configuraties moeten plaatsen, en je zou de servers moeten controleren als een productiesysteem.

de preview-omgeving van een content management systeem is een ander voorbeeld van een systeem dat klinkt als het ene type, maar eigenlijk het andere is. Preview content is nog niet gepubliceerd. Misschien is het ook tijdgevoelig, zoals een website voor een onaangekondigd product. Iemand zal de webpagina ‘ s van het nieuwe product publiceren voor de hele wereld om te zien na de aankondiging; maar voor publicatie zijn ze zeer vertrouwelijk. Daarom moet de preview-omgeving nog meer verificatie-en autorisatiecontroles hebben dan de productie-omgeving. Het mag geen voorbeeldpagina weergeven tenzij de huidige gebruiker het recht heeft om deze te bekijken.

we zouden deze ook als productiesystemen moeten behandelen:

  • blauw / groene implementaties. Waarom? De back-upomgeving die geen verkeer krijgt, kan op elk moment de productieomgeving worden.
  • back-upservers in een configuratie met hoge beschikbaarheid. Waarom? De back-upservers kunnen op elk moment het productieverkeer bedienen.
  • Canarische implementaties. Waarom? Deze dienen een klein deel van het productieverkeer.
  • gestage uitrol. Waarom? Alle versies van de hardware en software die het productieverkeer bedienen zijn ” in productie.”
  • A / B testing servers. Waarom? Hoewel “testen” in de naam staat, dienen deze ook voor het productieverkeer.

het is belangrijk om consistent te zijn wanneer u regels en heuristieken toepast op uw systemen en omgevingen. Je moet een staging omgeving niet beschouwen als een productie systeem de ene dag en een test systeem de volgende. Dat is een recept voor een ramp. Zorg ervoor dat iedereen begrijpt welke van de systemen productiesystemen zijn en welke niet, documenteer de beslissingen van uw team en eventuele uitzonderingen.

als u zich inspant om te begrijpen welke systemen wel of niet productiesystemen zijn, en deze op de juiste wijze behandelt, zorgt u ervoor dat u uw productiesystemen beschermt zonder uw ontwikkelings-en testsnelheid te schaden.

Waarom is testen op productiesystemen zo riskant?

wanneer mensen zeggen: “niet testen in productie”, is dat omdat ze verschillende mogelijke (slechte) resultaten willen vermijden:

  • beschadigde of ongeldige gegevens
  • uitgelekte beschermde gegevens
  • onjuiste omzetterekening (geannuleerde orders, enz.)
  • overbelaste systemen
  • onbedoelde bijwerkingen of effecten op andere productiesystemen
  • hoge foutenpercentages die alarmsignalen en oproeppagina ‘ s veroorzaken
  • Scheve analytics (Traffic trechters, A/B testresultaten, enz.)
  • onnauwkeurige verkeerslogboeken vol met script-en botactiviteit
  • niet-naleving van normen

waarom zouden we toch in productie moeten testen?

Ja, testen in de productie is riskant, maar we moeten het nog steeds doen, en ook niet in zeldzame of uitzonderlijke gevallen. Deze tests-in-productie worden geaccepteerd als best practices in de Devops en SRE gemeenschappen:

  • A / B testing and experiments
  • Usability testing and UX research
  • Final smoke testing of blue / green implementations
  • Feature flags
  • gefaseerde uitrol
  • Canary testing
  • Health checks and other production system monitoring, including scripted health tests
  • Visual regression testing of web pages to compare staged vs. productie versies
  • Toegankelijkheid regressie testen (na de eerste test en implementatie)
  • Scripts scannen webpagina ’s voor gebroken links en fouten
  • Real user monitoring
  • Chaos engineering
  • Failover testen
  • Andere tests van high-availability/disaster recovery plannen
  • Bug bounty ‘programma’ s

Productie tests helpen ons:

  • het Voorkomen van slechte implementaties uit te breken productie systemen
  • Objectief bepalen welke ervaringen zijn effectiever
  • Ontwerp heerlijke gebruiker/site interactions
  • Geleidelijk nieuwe functies uit
  • snelle feedback op het succes of falen van onze laatste wijzigingen
  • Vangen problemen voor gebruikers in de gaten
  • Begrijpen web pagina prestatie-eigenschappen en de impact
  • het uitbouwen van een meer veerkrachtige systemen
  • Verbeteren van de kwaliteit van het systeem

Door het uitvoeren van verschillende soorten productie-tests, tijdens de implementatie of op een frequente planning, kunnen we een verscheidenheid aan kritieke niet-functionele vereisten dekken:

ervaringen van Gebruikers Beschikbaarheid Roll-out wijzigingen Terugkoppeling Kwaliteit Prestaties Veerkracht
A/B testen
Usability/UX
rooktest
Functie vlaggen
Gefaseerde roll-outs
Canarische testen
Health checks
Regressie testen
Broken-link-checkers
Real user monitoring
Chaos engineering
Failover testen
HA/DR testen
Bug bounty
Penetration testing

Doelen van de verschillende soorten productie tests

…en Eén uitschieter (want is er niet altijd een probleemkind?): Penetratietest van derden (“pen”). Moeten we het op productiesystemen doen? Aan de ene kant, het is onmiskenbaar riskant; bijvoorbeeld, als pen testers vinden een injectie kwetsbaarheid, je zou kunnen eindigen met beschadigde gegevens in uw database. Aan de andere kant, hackers zijn waarschijnlijk het uitvoeren van pen testen suites op uw internet-gerichte systemen elke week. Daarom, pen testen gebeurt op veel van uw productiesystemen of u goedkeuren van het of niet. Daarom heb ik het opgenomen in deze lijst van productietesten. Ik heb twee aanbevelingen:

  • zorg ervoor dat uw te huur testers werken met een productie-achtige omgeving en niet met speelgoed.
  • Voer de meest populaire beveiligingstestsuites uit tegen uw testsystemen en repareer eventuele fouten die u vindt voordat iedereen dezelfde tests uitvoert tegen uw productiesystemen.

3-hackresistent.jpg

een hacker

uw productiesystemen moeten bestand zijn tegen hackpogingen en gracieus omgaan.

tot slot, heb je gemerkt dat deze tests-in-productie iets gemeen hebben? Geen van hen maakt “testkopieën” van productiegegevens. Ze werken allemaal direct op echte productiesystemen en data.

hoe zit het met de productiegegevens?

hier is een snelkoppeling: Dev / test-omgevingen hebben mogelijk geen speciale testgegevens nodig. Ze kunnen vaak gebruik maken van productiegegevens die beschikbaar zijn voor iedereen, zoals de werkelijke inhoud van webpagina ‘ s, zolang uw tests die gegevens niet wijzigen, bespaart u de tijd en kosten van het maken van testgegevens. Alle productietesten in de vorige sectie vallen in deze categorie, net als veel webservices en API ‘ s.

maar pas op! Alleen omdat gegevens beschikbaar zijn op het internet of een REST API is gratis te gebruiken betekent niet dat je het kunt gebruiken voor uw dev/test doeleinden. Zorg ervoor dat u alle toepasselijke licentieovereenkomsten en websitegebruiksovereenkomsten begrijpt en naleeft voordat u open gegevens gebruikt en gebruikt.

het is geweldig als u tijd en geld kunt besparen door productiegegevens te gebruiken, maar sommige van uw applicaties en services moeten uw gegevensopslag wijzigen, dus u hebt ook tests nodig die gegevens wijzigen. Het uitvoeren van deze tests in de productie is moeilijk te doen zonder uw productiesystemen te beschadigen. Geconfronteerd met deze realiteit, wanneer het nodig wordt om de gegevensopslag te wijzigen om een testscenario te valideren, kiezen de meeste ontwikkelteams ervoor om verschillende gegevensbronnen te hebben: één voor dev/test en één voor productie. Maar hoe stel je testgegevens in die realistisch en compleet genoeg zijn voor een goede test?

als uw productiedatabase klein genoeg is, kunt u er technisch een kopie van maken en dan testen, maar het kopiëren van productiegegevens naar een dev/test omgeving is problematisch omdat het beveiliging en privacy controles kan omzeilen. (GDPR, iemand?)

laten we een voorbeeld nemen. U hebt uw zorgvuldig doordachte beveiligings-en privacycontroles ingevoerd. U stelt uw productiesystemen zo in dat alleen mensen met een” need to know ” toegang hebben tot persoonlijke gegevens; u weet waar uw gegevens worden opgeslagen; u hebt een proces ingesteld voor het verwijderen van persoonlijke gegevens uit uw systemen op aanvraag; en ga zo maar door. Misschien heb je klantadressen en telefoonnummers in je database. Als iemand de database kopieert naar een dev/test systeem, en je hebt je beveiliging en privacy controles daar Niet geïmplementeerd, heb je een gat in je systeem. Als een klant zijn “recht op verwijdering” uitoefent en u verzoekt zijn adres en telefoonnummer te verwijderen, Hoe weet u dan welke dev/test-systemen u moet updaten om die informatie te verwijderen? Wat als de laptop van een ontwikkelaar of een test mobiel apparaat met persoonlijke gegevens op het wordt gestolen? Moet u een inbreuk op de beveiliging melden en beperken? Om deze gaten te dichten, moet u ofwel persoonlijke gegevens uit uw dev/test-systemen houden of dev/test-systemen met toegang tot persoonlijke gegevens opnemen in uw compliance-scope voor productiegegevens.

4-locklaptop.jpg

een laptop met hangslot en smartphone

het vergrendelen van uw laptop en telefoon met een ketting is niet het beste plan. Neem aan dat deze apparaten uiteindelijk zullen worden gestolen en beslissen hoe ze dienovereenkomstig te beheren.

het voor de hand liggende alternatief is om mock data te gebruiken voor dev/test omgevingen, maar beslissen wanneer mock data te gebruiken voor het testen is moeilijk omdat het maken en onderhouden van mock data tijdrovend en foutgevoelig is. Als u begint met een productiedatabase en deze handmatig scrubt om gevoelige gegevens te verbergen of te verwijderen, kunt u iets missen. Als je te ver gaat met een scrub, kun je de gegevens beschadigen of het testen ervan beperken. Omgekeerd, als u het opbouwen van een test database vanaf nul, het is moeilijk om alle permutaties en rand gevallen die u nodig hebt om een goede test suite te maken.

alleen u en uw teamgenoten kunnen beslissen welke richting de juiste is om te nemen voor uw unieke doeleinden, maar hier zijn enkele overwegingen die zullen helpen:

  • begrijp welke besturingselementen er op uw productiegegevens staan voordat u deze gebruikt en respecteer die besturingselementen.
  • zorg ervoor dat uw hele team het eens is over de Betekenis van gevoelige gegevens en persoonlijke gegevens.
  • definieer en accepteer uw protocollen voor het verwerken van gevoelige en persoonlijke gegevens.
  • documenteer en begrijp de gevoelige en persoonlijke gegevens in uw systemen. Zorg ervoor dat uw ontwikkelaars en testers precies begrijpen welke gevoelige en persoonlijke gegevens zij gebruiken.
  • als u besluit om productiegegevens te saneren om persoonlijke of gevoelige informatie te verwijderen, zorg er dan voor dat het proces voor het saneren van de gegevens zelf geen gat is in beveiliging/privacy/compliance. Overweeg software van derden om te schrobben en te ontsmetten, omdat het minder waarschijnlijk fouten veroorzaakt dan een oplossing van eigen bodem.

Hoe kunnen we testen in productie minder riskant maken?

de bedoeling van het adagium “niet testen in productie” is om onze productiesystemen te beschermen. Nu we hebben vastgesteld dat we elke dag in de productie kunnen en moeten testen, hoe houden we onze productiesystemen veilig?

5-checklist.jpg

een controlelijst

heb een testplan en voltooi het voordat u een nieuw onderdeel in productie neemt. Goed geteste code is minder kans om te falen in de productie.

eerst en vooral, test alle systemen grondig met geautomatiseerde tests voordat u naar de productie. Ik geloof in 100% geautomatiseerde unit test dekking, met unit tests in dezelfde change set of pull request als de code veranderingen die ze valideren. U moet meerdere testlagen voltooien voordat u naar de productie gaat: functional / behavioral testing, integratie testen, implementatie / configuratie testen, toegankelijkheid testen, security testen, en high-availability failover testen. En als je bezig bent met geleidelijke uitrol van nieuwe functies, test het uitrolproces ook. En ja, ik geloof ook in handmatige tests, maar nooit als vervanging voor testautomatisering!

hoe zit het met het testen in vrije vorm in de productie? Twee woorden: wees voorzichtig. “Bug hunt” dagen, bijvoorbeeld, zijn een best practice waar je iedereen in je team vragen om een bepaalde hoeveelheid tijd te besteden aan het vinden van bugs in uw software. Deze zijn leuk en productief… als je maar de juiste vangrails opzet. Bekijk met uw team de risico ‘ s van het testen in de productie en leer uw bug jagers wat ze niet moeten doen, zoals het plaatsen van bestellingen met behulp van hun persoonlijke creditcard en onmiddellijk de bestelling te annuleren. Dit soort tests kan interfereren met de omzet erkenning en order statistieken.

configureer uw productiesystemen ook niet handmatig, niet voor testdoeleinden of om enige andere reden. Handmatige wijzigingen laten uw systemen in een onbekende staat, en het kan erg moeilijk zijn om ze terug te krijgen naar een bekende configuratie. Beheer de configuratie van uw productiesystemen met behulp van infrastructure-as-code (Chef, Helm, enz.) en / of release management en orkestratie tooling, zoals IBM UrbanCode Deploy of Kubernetes.

zorg ervoor dat u uw experimenten hebt gepland in overeenstemming met de basisprincipes van chaos engineering.:

  1. plan een experiment
  2. bevatten de blast radius
  3. schaal of squash

u kunt het risico op chaos engineering ook verminderen door aan deze voorwaarden te voldoen: solide geautomatiseerde testdekking, goede monitoring en alarmering, een setup met hoge beschikbaarheid met snelle geautomatiseerde failover, en een team dat klaar staat om service te herstellen binnen uw service-level objectives (SLOs) als iets mislukt. Binnen mijn team doen we normaal gesproken de eerste fail-over-tests voor elk onderdeel in een weekend met de ontwikkelaar op afroep aanwezig, en teams “afstuderen” om te testen op veerkracht tijdens de normale werkuren nadat ze de eerste reeks tests hebben doorstaan.

6-Domino.jpg

vallende Domino ' s

laat chaos engineering, schaalbaarheid of prestatietesten geen cascade van problemen in uw systeem veroorzaken. Los gekoppelde componenten, goede foutafhandeling en geplande foutmodi helpen om storingen te isoleren.

zorg er bij het plannen van schaalbaarheid en prestatietesten voor dat u geen invloed hebt op uw klanten. Niet gooien een bos van API verzoeken op uw productiesysteem en hoop voor het beste. Gebruik een aparte, geïsoleerde omgeving als de kosten-batenanalyse dit rechtvaardigt. Als u de schaalbaarheid of prestaties in de productie moet testen, moet u het verkeer geleidelijk opvoeren tijdens het monitoren van uw systemen en stoppen voordat de service wordt onderbroken of defect raakt. En vergeet niet om te filteren schaalbaarheid / prestaties test verkeer van uw productie analytics!

deze risicoreductietechnieken zullen u helpen uw productiesystemen veerkrachtig te houden en minder kans op falen als gevolg van testen in de productie.

conclusie

testen in de productie is uiterst waardevol en een beste praktijk in moderne software-engineering, IT-operaties en IT-beveiliging. Productietests helpen ons:

  • het Voorkomen van slechte implementaties uit te breken productie systemen
  • Objectief bepalen welke ervaringen zijn effectiever
  • Ontwerp heerlijke gebruiker/site interactions
  • Geleidelijk nieuwe functies uit
  • snelle feedback op het succes of falen van onze laatste wijzigingen
  • Vangen problemen voor gebruikers in de gaten
  • Begrijpen web pagina prestatie-eigenschappen en de impact
  • het uitbouwen van een meer veerkrachtige systemen
  • Verbeteren van de kwaliteit van het systeem

Daarom moeten we niet voorkomen in het testen productie; in plaats daarvan moeten we de inherente risico ‘ s begrijpen en veiligheidsmaatregelen in onze systemen opnemen om ze aan te pakken. We moeten ook onze veiligheids-en nalevingsnormen actualiseren om rekening te houden met moderne productietesten.

dank aan de aanwezigen van de” test in production “open space op Devopsdays Charlotte, die samenwerkten om te brainstormen en te destilleren wat we echt bedoelen met de termen” test “en” productie ” en wat we echt moeten doen om onze productiesystemen te beschermen. Ik wil ook graag Craig Cook en Jocelyn Sese bedanken voor hun nuttige feedback over vroege ontwerpen van dit artikel.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.