Prod Verification, Release Strategies og End-to-End AI Workflow

Gevinster:

Forståelse af risikoreducerende frigivelsesstrategier (blå-grøn, kanariefugl, featureflag) og produktverifikationsdisciplin (sundhedstjek, røgtest, overvågning af gyldent signal)
Evne til at implementere vanen med at udarbejde en klar rollback-plan før implementering og verificere kritiske forretningsstier efter implementering
Evne til at kombinere alle de dele, der er lært gennem modulet i en end-to-end AI-understøttet arbejdsgang og anvende princippet om 'AI producerer, mennesker verificerer og står inde for' ved hvert trin

Hele dette modul strømmede mod ét punkt: sikker levering af kode og infrastruktur til produktion (det levende miljø, der bruges af rigtige kunder). Nu er vi ved det mest kritiske og stressende led i kæden: at få en forandring live og verificere, at den faktisk virker der. En fejl her er ikke abstrakt - den rammer direkte kunden, omsætningen og omdømmet. Det er derfor, modne teams går til produktion ikke ved at "håbe", men med kontrollerede udgivelsesstrategier og systematisk verifikation.

I denne sidste enhed kombinerer vi to ting: (1) frigivelsesmetoder, der reducerer risikoen (kanariefugl, blågrøn, featureflag) og disciplinen for produktverifikation; (2) hvordan hver del, vi lærte gennem modulet – CI/CD, IaC, container, overvågning, hændelse, omkostninger, script, sikkerhed – samles i et enkelt AI-drevet end-to-end workflow. Lad os gentage det indledende citat en sidste gang: AI genererer og accelererer udkast ved hvert trin; Men det er dig, der trykker på knappen "Jeg tager dette live" og står inde for udfaldet.

Frigiv strategier, der reducerer risikoen

At skubbe en ændring til alle brugere på samme tid er den mest risikable måde. Modne metoder:

Blue-Green Deployment: To identiske miljøer opretholdes - "blå" (live) og "grøn" (ny version). Den nye version er klargjort og testet i grøn, så er trafikken pludselig skiftet til grøn. Hvis der er et problem, går trafikken straks tilbage til blå. Hurtig tilbagerulning er dens største fordel.
Canary Deployment: Den nye version udgives først til en lille procentdel af brugerne (f.eks. 5 %); Hvis målene er gode, skal du gradvist stige til 100 %. Et problem påvirker en lille del af brugeren, ikke hele brugeren.
Feature Flag: Den nye funktion indtaster koden, men er blokeret af et flag; Den åbnes for visse brugere, når de bliver bedt om det. Der er en sondring mellem deployment og "release"; Hvis der er et problem, slås flaget fra uden at rulle koden tilbage.

Tip: Det hurtigste sikkerhedsnet er at have en rollback klar før hver implementering. "Hvis noget går galt, hvordan kan jeg så vende tilbage til den gamle version på 60 sekunder?" Hvis der ikke er noget klart svar på spørgsmålet, er du ikke klar til at udføre den implementering.

Produktbekræftelse: Arbejdet slutter ikke, når implementeringen slutter

Bare fordi en implementering ser "grøn" ud, betyder det ikke, at den virker. Systematisk verifikation:

Sundhedstjek: Er tjenesten oppe, svarer /healthz?
Røgtest: Virker de få mest kritiske brugerstier (login, betaling, søgning) faktisk? Automatisk og hurtig.
Hold øje med gyldne signaler: Fejlrate efter implementering, latens, er trafikken normal? (Fire signaler på enhed 6.)
Udvid gradvist: Se på metrics ved hvert trin, mens du øger Canary-procenten.
Observationsvindue: Overvåg nøje i en periode (f.eks. 30 min) efter udsættelse; Luske problemer er ikke umiddelbart synlige.

Forsigtig: AI kan producere en liste over røgtest eller verifikationer, men det er din opgave at bestemme, hvilke brugerstier der er "kritiske". AI giver en generel liste; Kun du ved, at dit betalingsflow, din mest indtægtsskabende vej, skal testes.

Sammenligning af udgivelsesstrategier

Strategi

Hovedfordel

Omkostninger/kompleksitet

mest passende

Blå-grøn

Øjeblikkelig tilbagerulning

To miljøer = 2x ressourcer

Hvis hurtig hentning er kritisk

kanariefugle

Begrænser virkningen til små skiver

Trafikstyring påkrævet

Kæmpe brugerbase

FeatureFlag

Adskiller implementering fra udgivelse

Flagforvaltningsgæld

Gradvis/målrettet åbning

Rullende opdatering

Enkel, ressourcevenlig

langsom tilbagerulning

Simple tjenester

End-to-end AI-drevet workflow

Lad os nu kombinere hele modulet i et enkelt flow. Lad os sige, at du udgiver en ny mikrotjeneste. AI producerer udkast på hvert trin; du bekræfter ved hvert trin:

Kode & beholder (Enhed 4): AI producerer en optimeret, sikker Dockerfile; Du bekræfter no-hemmeligheden og størrelsen.
CI/CD (Enhed 2): Skriver AI-test-build-deploy pipeline; Du indsnævrer tilladelserne og tjekker de hemmelige referencer.
Infrastruktur (Enhed 3): Definerer de nødvendige ressourcer med AI Terraform; Du læser planens output og leder ikke efter uventede sletninger.
Orkestrering (Enhed 5): AI producerer Kubernetes-manifester; du verificerer ressourcegrænsen, sonden og RBAC.
Sikkerhed (Enhed 10): Prioriterer AI-scanningsoutput; Du får fat i de udnyttelige først.
Overvågning (Enhed 6): AI genererer alarmregler og dashboard; Du tester tærsklerne med dine tidligere data.
Frigivelse og validering (denne enhed): Skitserer AI-røgtesten og tilbagerulningsplanen; du starter kanariefugle, se metrics, tryk på knappen.
Hvis hændelsen opstår (Enhed 7): AI genererer hypotese og postmortem skitse; Du verificerer og lærer lektien.
Omkostninger (enhed 8): AI overvåger spild af nye ressourcer; Du træffer de rigtige beslutninger om størrelse.

Ved hvert trin forbliver den fælles regel konstant: AI producerer og accelererer, mennesker verificerer og garanterer. Dette er essensen af modulet.

tre minisager

Tilfælde 1 — kanariefugle begrænsede en katastrofe til 5 %. Et team gav den nye version til 5 % brugere med kanariefugle. Dashboardet, som AI producerede, viste med det samme, at fejlraten sprang til 8% i dette udsnit. Holdet tog det tilbage uden at øge det til 100 %; Problemet berørte kun 5 % af brugerne, og det var i et par minutter. Hvis der var et big-bang-implementering, ville alle kunder blive berørt.

Tilfælde 2 — røgtest fangede den manglende vej. AI tilbød et røgtestsæt, men det havde ikke et "betalings" flow. Ingeniøren tilføjede det, vel vidende at den mest kritiske indtægtsstrøm var betaling. Post-deploy-testen brød lige ved kassen - en tredjepartsnøgle var udløbet. Bekræftelse fangede et stille tab af omsætning inden for få minutter.

Sag 3 — klar tilbagerulning gemt på 90 sekunder. Et team, der installerede blå-grøn, tog den nye version til grøn; Efter 2 minutter blev forsinkelsen fordoblet. De gjorde trafikken til blå på 90 sekunder med den tilbagerulning, de forberedte på forhånd. De fandt den grundlæggende årsag (en langsom forespørgsel i den nye version) ikke under pres, så roligt. Den klare tilbagerulningssti gjorde afbrydelsen næsten usynlig.

Fire kopierbare skabeloner

1) Valg af udgivelsesstrategi:

Jeg vil prod følgende service: [SERVICE/KONTEKST: antal brugere, udfaldstolerance, infrastruktur]. Hvilken en anbefaler du mellem blå-grøn, kanariefugle og featureflag? Sammenlign fordelene, omkostningerne og tilbagerulningshastigheden for hver i denne sammenhæng. Kom med et forslag, men angiv, at jeg tager den endelige beslutning.

2) Røgtest / verifikationsliste:

Lav et udkast til røgtest og verifikationsliste for [SERVICE], som jeg vil køre efter implementeringen: sundhedstjek, de mest kritiske brugerstier, hvilke metrics skal jeg overvåge i hvor mange minutter? Antag, at jeg vil markere de mest kritiske forretningsveje og lade feltet stå tomt.

3) Tilbageføringsplan:

Jeg bruger [DEPLOY METHOD]. Skriv mig en klar tilbagerulningsplan: med hvilken kommando/trin ruller jeg tilbage til den gamle version, hvor lang tid tager det, hvad er risikoen for selve rollback (f.eks. kan databasemigrering ikke rulles tilbage), hvad skal jeg tjekke før rollback?

4) Tjekliste for ende-til-ende udgivelser:

Lav en ende-til-ende forberedelsestjekliste til frigivelse til et nyt [SERVICE]-projekt: kode-/billedsikkerhed, pipeline, infrastrukturplan, overvågning og alarmering, sikkerhedsscanning, frigivelsesstrategi, rollback og verifikation. Tjek hvert element med spørgsmålet "Er jeg klar?" Gør det til et spørgsmål.

Svag prompt / Stærk prompt

Svag: "Hvordan får jeg det her til prod?"

Resultat: ingen kontekst; AI viser generelle implementeringstrin, den adresserer ikke din risikotolerance, brugerskalering og tilbagerulningsbehov.

Güçlü: "Jeg vil prodere en betalingstjeneste med 10 millioner brugere, min tolerance for nedetid er meget lav. Anbefaler du Canary eller Blue-Green, hvorfor? Hvilke kritiske stier skal jeg teste efter implementering, hvilke målinger skal jeg overvåge i hvor mange minutter, og hvordan skal en 60-sekunders tilbagerulningsplan være? Jeg vil tage den endelige beslutning."

Forskel: den anden prompt angiver skala, tolerance og forventning om tilbagerulning; Det kræver strategi + verifikation + fortrydelse og lader beslutningen være op til mennesket.

Almindelige fejl

Implementering uden en tilbagerulningsplan. Hvis der ikke er nogen vej tilbage, er hver implementering et gamble.
Big-bang implementering. At give det til hele brugeren på én gang maksimerer risikoen.
Forudsat "grøn = arbejder". Den service, der har bestået sundhedstjekket, kan være ødelagt på den kritiske vej.
Tænker, at du forlader kritiske forretningsveje til AI. Du skal markere metoderne såsom betaling.
Overvåges ikke efter implementering. Luske problemer dukker ikke op i det første minut; observationsvindue er påkrævet.
Tænker at databasemigrering er reversibel. Nogle ændringer ruller ikke tilbage; planlægges særskilt.

Sammenfattende

At gå til prod er det mest kritiske led i kæden og gøres ikke ved at "håbe", men med kontrollerede strategier: blå-grøn giver øjeblikkelig tilbagerulning, begrænser den kanariske effekt til et lille udsnit, og adskiller funktionsflagsimplementering fra frigivelse. Arbejdet er ikke slut, når indsættelsen er afsluttet; Systematisk verifikation gennem sundhedstjek, røgtest og gyldne signalovervågning er afgørende. AI genererer og accelererer udkast ved hvert trin gennem hele modulet - fra Dockerfile til pipeline, fra Terraform til alarmregel, fra postmortem til omkostningsanalyse. Men den kompetente person forbliver, som verificerer hvert trin, trykker på gå live-knappen og står inde for resultatet. Dette er den gyldne regel for end-to-end AI-drevne DevOps.

Ansøgningsopgave

Vælg en tjeneste (virkelig eller fiktiv) at udgive på. (1) Vælg en strategi, der passer til din kontekst med skabelonen "Udgiv strategivalg" og skriv hvorfor. (2) Få en verifikationsliste genereret med skabelonen "Røgtest / verifikationsliste", og tilføj selv de mest kritiske forretningsstier. (3) Forbered en 60 sekunders tilbagerulningsplan med skabelonen "Rollback-plan" og kontroller, om der er nogen irreversible trin i den.

tjekliste

[ ] Jeg valgte en udgivelsesstrategi (kanariefugl/blå-grøn/flag), der passer til min kontekst.
[ ] Jeg har en klar og hurtig tilbagerulningsplan klar inden implementering.
[ ] Jeg har selv tilføjet de mest kritiske forretningsveje (f.eks. betaling) til mine røgtest.
[ ] Efter deployering overvåger jeg de gyldne signaler gennem et observationsvindue.
[ ] Jeg planlagde også irreversible trin (databasemigrering osv.).
[ ] Jeg bekræftede AI-planen ved hvert trin; Jeg tog beslutningen om at gå live.

Modul eksamen

1. Hvilken af følgende er den bedste placering til DevOps og AI i skyen?

A) Kunstig intelligens er et assistent og beslutningsstøtteværktøj; Folk er ansvarlige for kritiske beslutninger, der påvirker produktet ✔
B) Kunstig intelligens kan afslutte prod-udrulninger og hemmelig rotation uden menneskelig godkendelse
C) Kunstig intelligens er kun nyttig til at skrive dokumentation, det har intet med infrastruktur at gøre
D) Audit er unødvendigt, fordi kunstig intelligens altid producerer mere pålidelige kommandoer end ingeniøren

Beskrivelse: Det er et assistent- og beslutningsstøtteværktøj, der accelererer tekstintensive opgaver såsom pipeline, konfiguration, script og log med kunstig intelligens. Ansvaret for beslutninger, der påvirker nedetid, penge og sikkerhed, såsom produktionsfrigivelse, hemmelig styring og endelig anvendelse, forbliver hos den kompetente ingeniør.

2. Hvilket er det mest nøjagtige udtryk for verifikationsdisciplinen før implementering af en DevOps-kommando eller -konfiguration produceret af kunstig intelligens?

A) Hvis output ser glat og sikkert ud, kan det køres direkte i prod
B) Output er kun sikkert, hvis der ikke er nogen syntaksfejl, ingen yderligere kontrol er påkrævet
C) Tilslut outputtet til kilden, planlæg/tørkør og filtrer det med din systemkontekst; så ansøg ✔
D) At gøre det første forsøg direkte i prod og se resultatet er den hurtigste verifikation

Forklaring: Tretrinsbekræftelse er essentiel: at forbinde outputtet til kilden (er kommandoen/flaget faktisk i de officielle dokumenter), køre det tørt (se, hvad der sker med planen/--dry-run), og sende det gennem systemfilteret (passer det inden for dens arkitektoniske og sikkerhedsmæssige kontekst). Flydende betyder ikke nøjagtighed.

3. Hvad er den korrekte tilgang, når man spørger kunstig intelligens om en fejl eller implementeringsproblem med en .env-fil, der indeholder en rigtig databaseadgangskode?

A) Mask reelle hemmeligheder med <PLACEHOLDER>; del kun maskeret fejl og kontekst ✔
B) Indsættelse af hele .env-filen som den er løser problemet hurtigere
C) Da hemmelighederne allerede er base64, er det sikkert at indsætte almindeligt
D) Det er sikkert at indsætte adgangskoden, fordi kunstig intelligens aldrig gemmer den

Beskrivelse: Der indsættes ingen rigtige hemmeligheder i AI-prompten. Værdier som adgangskoder og tokens er maskeret med <PLACEHOLDER>; kun fejlmeddelelsen og den nødvendige kontekst deles. Hvis hemmeligheden allerede er blevet lækket, skal den annulleres og roteres med det samme.

4. Hvilken af følgende er den korrekte håndtering af hemmeligheder (adgangskode, token) i en CI/CD-pipeline?

A) Det opbevares i platformens hemmelige lager og kaldes ved reference (f.eks. ${{ secrets.X }}), ikke skrevet i almindelig tekst ✔
B) Skrevet i klartekst til pipeline YAML for nemheds skyld
C) Det verificeres ved at trykke på ekko og log i begyndelsen af hvert job.
D) Hvis defineret med den bredeste tilladelse (write-all), øges sikkerheden

Forklaring: Hemmeligheder skrives ikke til YAML i almindelig tekst; Det opbevares i platformens hemmelige lager og kaldes med referencer såsom ${{ secrets.X }}. Derudover, med princippet om mindste autoritet, indsnævres token-tilladelser, og den hemmelige log registreres ikke.

5. I infrastrukturstyring med Terraform, hvad er det mest kritiske skridt at tage, før en ændring implementeres live?

A) At køre 'terraform ansøge' direkte; planen er spild af tid
B) Sikkerhedskopiering af statens fil til et offentligt depot
C) Kør 'terraform plan' og kontroller ødelægge/erstat linjerne i outputtet, og anvend derefter ✔
D) Afinstaller udbyderversionen og sørg for, at den nyeste version kommer automatisk

Forklaring: 'terraform plan' skal køres før 'terraform gælder'. Planen viser, hvad der skal tilføjes, hvad der skal ændres, og især hvad der skal slettes (ødelægges), uden at gøre noget. Hvis der ses en uventet ødelæg eller udskift linje, skal applicering ikke anvendes.

6. Hvad betyder det, og hvad skal der gøres, hvis '-/+ replace'-linjen for produktionsdatabasen vises i et Terraform-planoutput?

A) Kilden vil blot blive opdateret på stedet, der er ingen risiko
B) Ressourcen vil blive slettet og genskabt; Der er risiko for tab af data, ansøgning bør stoppes, hvis det ikke forventes ✔
C) Tilføjelse af en ny ressource, eksisterende database påvirkes ikke
D) Dette er kun en advarsel, som sikkert kan ignoreres

Forklaring: '-/+ replace' betyder, at ressourcen vil blive slettet og genskabt; For en database betyder det tab af data. Hvis det ikke forventes, skal ansøgningen stoppes, ændringen skal konverteres til en sikker metode, eller det uforanderlige felt skal forblive urørt.

7. Hvilket af følgende er sandt for, at en Dockerfile er produktionsklar med hensyn til sikkerhed og størrelse?

A) For nemheds skyld skal du indlejre hemmeligheden i billedet med ENV og køre den som root
B) Brug altid ':latest' tagget og hold basisbilledet så stort som muligt
C) Byg i et trin og efterlader alle byggeværktøjer i det endelige billede
D) Ikke indlejring af hemmeligheden, arbejde med uautoriseret BRUGER, ved hjælp af lille og stabilt basisbillede og multi-stage build ✔

Beskrivelse: Et produktionsklart billede: indlejrer ikke hemmeligheden (injicerer den under kørsel), kører med en uautoriseret BRUGER i stedet for root, bruger et lille og versioneret basisbillede (slankt/alpint, ikke :nyeste), og skaleres ned med en flertrins-build. Den scannes også for sårbarheder før offentliggørelse.

8. Hvad er den vigtigste risiko ved ikke at definere ressourcegrænser for en implementering i Kubernetes?

A) Pod starter aldrig, fordi limit er et obligatorisk felt
B) Kun en advarsel vises på overvågningstavlen, driften påvirkes ikke
C) Kubernetes håndhæver automatisk sikre standardgrænser, ingen risiko
D) Poden kan vokse ubegrænset og forbruge nodens ressourcer og dermed nedbryde nabotjenester ✔

Forklaring: En Pod, der ikke har nogen ressourcebegrænsning, kan vokse ubegrænset, forbruge alle ressourcerne i den node, den kører på, og crashe nabotjenester, for eksempel med en hukommelseslækage. Det er derfor, at definere anmodninger/grænser er grundlaget for robusthed.

9. Hvordan undgår man 'alarmtræthed' i overvågning og alarmopsætning?

A) Indstil alarmer på så mange målinger som muligt og generer advarsler ved hver udsving.
B) Indstil alle alarmer til det højeste niveau
C) Udløsning af alarmer med øjeblikkelige værdier uden at indstille en tid (for)
D) Holde alarmer handlingsorienterede og på den rigtige hast, teste tærskler med historiske data, flette unødvendige ✔

Beskrivelse: Hver alarm skal kunne handles og have den rigtige hastende karakter; Information, der ikke kræver handling, vises på tavlen, den vækker ikke nogen. Alarmtærskler testes i forhold til systemets historiske data, og unødvendige/gentagne alarmer konsolideres. På denne måde vil den rigtige alarm ikke fare vild i støjen.

10. Hvad er den bedste prioritetsordre under en produktionshændelse?

A) Find først den nøjagtige grundårsag og reducer den først, når årsagen er klar.
B) Skriv først obduktionsrapporten, og tryk derefter på tjenesten
C) Reducer først (gendan/gendan service), efterlad rodårsagsanalyse til senere ✔
D) Find først den ansvarlige for hændelsen og rapporter den

Forklaring: Den gyldne regel er 'reducer først, undersøg senere'. Målet er først at gendanne tjenesten eller rulle den tilbage til en kendt-god version (afbøde); Grundårsagsanalyse udføres roligt, efter at trykket er faldet. Venter du på at finde den nøjagtige årsag, øges genoprettelsestiden (MTTR).

11. Hvad er hovedformålet med ulastelig postmortem-kultur?

A) Identifikation af den person, der begik fejlen, og lægger ansvaret på ham/hende
B) Fokus på systemer og processer og tilskyndelse til læring; ✔ At lære lektioner, der forhindrer gentagelse i stedet for at bebrejde
C) Anmeld aldrig hændelsen og sørg for, at den bliver glemt
D) Kun skrive tekniske detaljer og ikke tilføje handlingsegnede elementer

Forklaring: Ulastelig postmortem fokuserer på spørgsmålet 'hvilket system og proces tillod denne fejl', ikke 'hvem gjorde det'. Folk deler fejlen åbenlyst, hvis de ved, at de ikke vil blive straffet; Den skjulte fejl gentages. Rapporten er ikke en anklagerapport, men et læringsdokument fyldt med handlingsorienterede emner.

12. Hvad er det mest logiske skridt at tage inden for skyomkostningsoptimering (FinOps), før man går over til forpligtede rabatter (Reserveret/Opsparingsplan)?

A) Tag det længst mulige engagement først, tænk på spild senere
B) Først skal du rydde op i affaldet (tomgangslukning, den rigtige størrelse), og derefter forpligte dig til engageret brug ✔
C) Flyt alle ressourcer til Spot-kapacitet med det samme
D) Sletning af den dyreste vare uden gennemgang af fakturadata

Forklaring: Affald skal ryddes op først (lukning af ledige ressourcer, reduktion af overdimensionerede ressourcer). Ellers låser du det spildte forbrug til en nedsat pris i 1-3 år. Den rigtige størrelse og tomgangsrengøring kræver ingen forpligtelse og er tæt på risikofri.

13. Hvad er den vigtigste sikkerhedsforanstaltning, hvis et AI-foreslået script har linjen 'rm -rf "$DIR"/'?

A) At køre scriptet direkte i prod uden at læse det vil fremskynde
B) Tilføj set -euo pipefail og tom variabel kontrol og prøv med tørkør først ✔
C) Det er tilstrækkeligt at forkorte variabelnavnet
D) Brug af rm -rf --force i stedet for rm løser problemet

Forklaring: Hvis $DIR er tom, kan denne sætning forsøge at slette rodmappen. Stop ved den udefinerede variabel med 'set -u' og kontroller, at variablen ikke er tom, før du sletter den (f.eks. [ -n "$DIR" ] || exit 1) undgår katastrofe. Derudover bør destruktive operationer prøves med tørløb først.

14. Hvad er den første ting at gøre, hvis en cloud-adgangsnøgle ved et uheld lækker ind i et offentligt lager?

A) Annuller og forny (drej) nøglen med det samme; Det er ikke nok at slette alene ✔
B) Bare slet filen fra lageret, og nøglen er sikker
C) Ikke at gøre noget, fordi ingen så det
D) At gøre opbevaringen privat eliminerer behovet for at dreje nøglen

Forklaring: Den lækkede hemmelighed skal annulleres og roteres med det samme. Bare sletning af filen er ikke nok, fordi hemmeligheden forbliver i Git-historien, og offentlige arkiver scannes af bots inden for få sekunder. Efter annullering/return bliver virkningen evalueret og en hemmelig scanner tilføjet for at forhindre gentagelse.

15. Hvilken af følgende fremgangsmåder minimerer risikoen, når en ny version af Prod frigives?

A) Give den nye version til alle brugere på samme tid (big-bang) og ikke forberede en tilbagerulningsplan
B) Anser, at implementeringen er afsluttet, så snart den ser "grøn" ud, uden at udføre yderligere verifikation
C) Brug af en kontrolleret strategi såsom kanariefugle/blå-grønt/funktionsflag, færdiglavet tilbagerulningsplan og røgtest + metrisk overvågning efter deployering ✔
D) At overlade testning af kritiske forretningsveje udelukkende til kunstig intelligens og slet ikke bestemme dem.

Forklaring: Kontrollerede udgivelsesstrategier (startende med en lille procentdel med kanariefugle, øjeblikkelig tilbagerulning med blå-grøn, adskillelse af implementering fra udgivelse med funktionsflag) begrænser risikoen. Derudover er en klar tilbagerulningsplan før indsættelse og overvågning af gyldent signal med røgtest efter indsættelse afgørende; "at se grønt ud" betyder ikke, at det virker.