Vendosja Blue-Green
Dy mjedise të plota prodhimi, me trafikun e zhvendosur nga njëri te tjetri — duke lejuar një kthim të menjëhershëm dhe të plotë nëse mjedisi i ri sillet keq.
Vendosja & Aktivizimi · Hapi 05 · Si Punojmë
Rilëshimi është një vendim, jo një ngjarje.
Zhvillimi & Integrimi prodhon softuer të verifikuar — por softueri i verifikuar nuk është ende softuer në prodhim. Kjo fazë rregullon se si, kur dhe me çfarë sigurie ai softuer ekspozohet ndaj trafikut real të prodhimit, dhe siguron që personat përgjegjës për operimin e tij janë të përgatitur para se ai të arrijë.
Në OpenQCore, vendosja trajtohet si një ekspozim i kontrolluar i rrezikut, jo një moment i vetëm i pakthyeshëm. Një publikim nuk është "i përfunduar" kur kodi arrin në prodhim. Ai konsiderohet i përfunduar kur është ekspozuar gradualisht, është vëzhguar nën kushte reale dhe është konfirmuar i sigurt — me një rrugë të përcaktuar kthimi nëse nuk është.
Jo kjo pyetje
"A është kodi gati për dërgim?"
Kjo pyetje, në vend të saj
"Si ta ekspozojmë këtë ndryshim te përdoruesit e vërtetë në një mënyrë që kufizon rrezatimin e ndikimit të asaj që nuk e parashikuam — dhe a mund ta kthejmë shpejt nëse kemi nevojë?"
Dorëzim Progresiv · Përmbajtja e Rrezikut · Rikthyeshmëria · Gatishmëria · Mundësimi
Pse vendosja ndjek verifikimin
I verifikuar nuk është i njëjtë me i provuar në prodhim.
Faza e mëparshme konfirmon se një ndryshim e përmbush kriterin e pranimit gjatë testimit. Ajo nuk konfirmon se si sillet ai ndryshim nën ngarkesën reale të prodhimit, sjelljen reale të përdoruesve, ose ndërveprimet reale me sisteme që nuk mund të riprodhohen plotësisht në një mjedis testimi. Deployment & Enablement ekzistojnë pikërisht sepse kjo hendek është real — dhe sepse mbyllja e tij në mënyrë të sigurt kërkon disiplinën e vet.
Gati për Vendosje → Ekspozim i Kontrolluar në Prodhim
Pse disiplina e vendosjes ka rëndësi
Shpejtësia pa kthyeshmëri nuk është progres.
E njëjta kërkim i DORA i prezantuar gjatë Zhvillimit & Integrimit — Accelerate (2018) nga Forsgren, Humble dhe Kim — kombinon metrikat e prodhimit me dy metrika të qëndrueshmërisë që janë veçanërisht të rëndësishme në këtë fazë.
Frekuenca e vendosjeve
Sa shpesh një organizatë publikon me sukses në prodhim.
Forsgren, Humble & Kim, Accelerate (2018); DORA, kërkimi 'State of DevOps'.
Koha për rikthimin e shërbimit
Sa kohë duhet për t'u rikuperuar kur një vendosje degradon prodhimin.
Forsgren, Humble & Kim, Accelerate (2018); DORA, kërkimi 'State of DevOps'.
Organizatët me performancë të lartë, në këtë kërkim, nuk thjesht vendosin shpesh — ato vendosin në një mënyrë që mban kohën e rikthimit të shkurtër kur diçka shkon keq. OpenQCore i trajton këto si një objektiv të vetëm, jo si një kompromis: praktikat në këtë fazë janë të dizajnuara për ta bërë vendosjen si të shpeshtë ashtu edhe shpejt të kthyeshme.
Strategjitë e Dorëzimit Progresiv
Ndani vendimin për publikim nga vendimi për vendosje.
Praktikat e formalizuara në librin influent Continuous Delivery (2010) të Humble dhe Farley dallojnë vendosjen e një ndryshimi nga lëshimi i tij tek përdoruesit — një dallim që OpenQCore e trajton si një zgjedhje themelore të dizajnit për mënyrën se si softueri arrin në prodhim.
Lëshime Canary
Një version i ri ekspozohet së pari një fraksioni të vogël të trafikut real, vëzhgohet kundrejt sinjaleve të përcaktuara, dhe zgjerohet vetëm pasi ato sinjale konfirmohen.
Flamuj Veçorish
Kodi mund të vendoset në prodhim duke mbetur i çaktivizuar për përdoruesit — duke ndarë aktin e dërgimit të kodit nga akti i ekspozimit të një funksionaliteti.
Mjediset e Vendosjes & Promovimi
Një ndryshim fiton rrugën e tij drejt prodhimit. Ai nuk dërgohet atje drejtpërdrejt.
Një ndryshim kalon nëpër mjedise të përcaktuara — zhvillim, staging dhe prodhim — me verifikim të qartë në çdo promovim, jo thjesht një kalim testi i vetëm i ndjekur nga një publikim i drejtpërdrejtë.
Zhvillim
Ku një ndryshim ndërtohet dhe verifikohet fillimisht në izolim.
Staging
Ku një ndryshim verifikohet kundrejt kushteve, konfigurimit dhe integrimeve të ngjashme me prodhimin.
Prodhim
Ku një ndryshim ekspozohet ndaj trafikut real — në mënyrë progresive dhe nën vëzhgim.
Dizajni i Kthimit dhe i Rikuperimit
Plani i Kthimit është shkruar para shpërndarjes, jo gjatë incidentit.
Një strategji kthimi e vendosur ndërsa një sistem është tashmë i degraduar është një strategji e vendosur nën presion, me informacion të paplotë dhe shpesh shumë vonë. OpenQCore përcakton rrugën e kthimit për një ndryshim para se ai të shpërndahet — jo pasi diçka shkon keq.
Kushtet e Përcaktuara të Trigërimit të Kthimit
Sinjalet specifike që do të nxisnin një kthim, të dakorduara paraprakisht dhe jo të gjykuara në moment.
Kompatibiliteti i të Dhënave dhe i Shtetit
Marrja në konsideratë e qartë nëse një kthim është i sigurt duke pasur parasysh çdo ndryshim në të dhëna ose skema që ka sjellë shpërndarja.
Objektivi i Kohës së Rikuperimit
Një objektiv i përcaktuar për se sa shpejt duhet të rikthehet shërbimi nëse kërkohet një kthim.
Infrastruktura si Kod dhe Riprodhueshmëria
Një shpërndarje që nuk mund të përsëritet saktësisht nuk mund t'i besohet.
Hapat e shpërndarjes përcaktohen si kod — nën kontrollin e versioneve, të rishikuara dhe të ekzekutuara në mënyrë identike çdo herë — në vend që të kryhen si veprime manuale që varen nga kujtesa e një individi për rendin e saktë. Kjo është një praktikë themelore në të njëjtin trup kërkimor për dorëzim të vazhdueshëm të përmendur më sipër: një proces shpërndarjeje që nuk mund të riprodhohet saktësisht nuk mund të verifikohet dhe nuk mund të automatizohet në mënyrë të sigurt.
Vlerësimi i Rrezikut të Shpërndarjes
Çdo shpërndarje vlerësohet para se të ndodhë, jo pas saj.
Në përputhje me modelimin e kërcënimeve të prezantuar gjatë Zhvillimit dhe Integrimit, çdo shpërndarje vlerësohet për profilin e saj specifik të rrezikut para se të vazhdojë.
Rrezja e Ndikimit
Sa përdorues, sisteme ose rrjedha pune do të preken nëse ky ndryshim specifik sillet në mënyrë të papritur.
Kthyeshmëria
Sa shpejt dhe në mënyrë të pastër ky ndryshim specifik mund të zhbëhet nëse kërkohet.
Ekspozimi i Varësive
Cilat sisteme ose ekipe pasuese preken nga kjo shpërndarje, dhe nëse ato janë informuar.
Pipeline-i i Rishpërndarjes Progresive
Ekspozimi rritet vetëm kur provat e mbështesin.
Canary (përqindje e vogël) → Monitoroni sinjalet e përcaktuara → Zgjeroni ekspozimin → Monitoroni sinjalet e përcaktuara → Shpërndarje e plotë. Në çdo pikë të kësaj sekuence, një rikthim është një rezultat i projektuar — jo një improvizim emergjent. Zgjerimi në fazën e ardhshme është një vendim i marrë kundrejt provave të mbledhura në fazën aktuale, jo një parazgjedhje që ndodh automatikisht me kalimin e kohës.
Kjo qasje pasqyron konceptin e një buxheti gabimesh, përshkruar në Site Reliability Engineering të Google (2016): një sasi e përcaktuar, e pranueshme e paqëndrueshmërisë që i lejohet një sistemi të shpenzojë, e përdorur për ta bërë kompromisin midis shpejtësisë së lëshimit dhe besueshmërisë një vendim të qartë dhe të matur në vend që të jetë i nënkuptuar.
Përgatitja: Dokumentacioni & Gatishmëria e Ekipit
Një sistem që askush nuk mund ta operojë nuk është në të vërtetë i shpërndarë.
Shpërndarja shpesh trajtohet si e përfunduar sapo softueri të funksionojë në prodhim. OpenQCore e trajton si të përfunduar vetëm kur personat përgjegjës për operimin, mbështetjen dhe zgjidhjen e problemeve të atij softueri janë me të vërtetë të përgatitur për ta bërë këtë.
Udhëzime operative
Procedura të dokumentuara për detyrat operative të zakonshme, mënyrat e njohura të dështimit, dhe si të përgjigjeni ndaj tyre.
Gatishmëria për thirrje (On-Call)
Konfirmim që personat përgjegjës për përgjigjen ndaj incidenteve kanë aksesin, kontekstin dhe rrugët e eskalimit që u nevojiten.
Transferimi i njohurive
Dorëzim i qartë i kuptimit operacional tek ekipi ose organizata që do të marrë në pronësi sistemin në të ardhmen.
Porta e vendimit për shpërndarjen
Një shpërndarje kryhet sepse provat e mbështesin — jo sepse është e planifikuar.
Çdo shpërndarje e planifikuar arrin një portë vendimmarrëse të përcaktuar përpara se të vazhdojë.
Shpërndarje
Vlerësimi i rrezikut, plani i rikthimit dhe gatishmëria janë përmbushur — shpërndarja vazhdon.
Shtyrje
Një rrezik i identifikuar ende nuk është zbutur në mënyrë të mjaftueshme — shpërndarja pret derisa të zbutet.
Rikthim
Një ndryshim i shpërndarë ka shkaktuar një kusht të përcaktuar rikthimi — gjendja e mëparshme rikthehet.
Eskalimi i incidentit
Një shpërndarje ka shkaktuar një ndikim që kërkon një përgjigje formale ndaj incidentit përtej një rikthimi standard.
Një portë shpërndarjeje që kurrë nuk e shtyn ose nuk rikthen nuk po vlerëson rrezikun — thjesht po regjistron një orar.
Çfarë prodhon kjo fazë
Një sistem aktiv dhe aftësia për ta operuar.
Në varësi të shkallës së angazhimit, kjo fazë prodhon:
Udhëzuesi i shpërndarjes
Procedura specifike dhe e përsëritshme e përdorur për të shpërndarë këtë ndryshim dhe ndryshime të ngjashme në të ardhmen.
Plani i rikthimit
Kushtet e përcaktuara të aktivizimit, procedura dhe objekti i kohës së rikuperimit për kthimin pas të kësaj shpërndarjeje.
Regjistri i Promovimit të Mjedisit
Dokumentacioni për mënyrën se si ndryshimi u kalua përmes zhvillimit, testimit (staging) dhe prodhimit, dhe çfarë u verifikua në çdo fazë.
Dokumenti i Vlerësimit të Rrezikut
Rrezja e ndikimit, kthyeshmëria dhe ekspozimi ndaj varësive të vlerësuara para vendosjes.
Materialet e Aftësimit të Ekipit
Runbook-et, konfirmimi i gatishmërisë për thirrje, dhe transferimi i njohurive i përfunduar para dorëzimit.
Raporti i Rilëshimit Progresiv
Sinjalet e vëzhguara në çdo fazë të ekspozimit dhe provat që mbështesin zgjerimin drejt shpërndarjes së plotë.
Nga Vendosja te Monitorimi & Optimizimi
Në prodhim (live) nuk është e njëjtë me të kuptuarit.
Deployment & Enablement krijon një sistem që funksionon në mënyrë të sigurt në prodhim, me njerëzit përgjegjës të përgatitur për ta operuar atë. Ai ende nuk siguron një kuptim të vazhdueshëm të mënyrës se si sistemi sillet me kalimin e kohës, apo një mekanizëm të strukturuar për ta përmirësuar. Ky është qëllimi i fazës së ardhshme dhe përfundimtare në këtë metodologji.
Ekspozim i Kontrolluar në Prodhim → Gatishmëria Operacionale → Monitorimi & Optimizimi
Hapi 06
Monitorimi & Optimizimi
Kuptoni se si sillet në të vërtetë një sistem në funksionim, dhe përmirësojeni atë në mënyrë të vazhdueshme bazuar në prova reale.
Referencat Kërkimore & Metodologjike
Forsgren, N., Humble, J., & Kim, G. — Accelerate: The Science of Lean Software and DevOps (2018); Google Cloud, kërkimi DORA State of DevOps
Burimi i metrikeve të frekuencës së vendosjes dhe kohës së rikuperimit të përmendura më sipër.
Humble, J. & Farley, D. — Continuous Delivery: Rilëshime të Besueshme të Softuerit përmes Ndërtimit, Testimit dhe Automatizimit të Vendosjes (2010)
Burimi i dallimit midis deploy/release, zbatimit blue-green, dhe parimeve të infrastrukturës si kod (infrastructure-as-code) të përmendura më sipër.
Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (red.) — Site Reliability Engineering: Si Menaxhon Google Sistemet e Prodhimit (2016)
Burimi i konceptit të buxhetit të gabimeve të përmendur në seksionin e zbatimit progresiv më sipër.