Eiti prie turinio 
Šiandien diegimas be prastovos lemia, ar prieglobos klientai galės naudotis nepertraukiamais atnaujinimais ir perkėlimais, ar praras pajamas. Parodysiu, kaip konkrečiai Diegimas be prastovos su išbandytomis strategijomis, automatizavimu ir švariu stebėjimu, įskaitant technologijas, taktiką ir konkrečių atvejų tyrimus.
Centriniai taškai
- StrategijosMėlynai žalias, kanarėlių spalvos, ritininis, funkcijų jungikliai
- AutomatizavimasCI/CD, IaC, testai, priežiūra
- EismoApkrovos balansavimo įrenginys, maršrutizavimas, būklės patikrinimai
- DuomenysCDC, dvigubas rašymas, šešėlinis skaitymas
- ValdymasStebėsena, SLO, atšaukimas
Ką prieglobos paslaugų teikėjams iš tikrųjų reiškia nulinis prastovos laikas
Nulinę prastovos trukmę vertinu ne kaip rinkodaros formulę, o kaip Veiklos standartas išleidžiant, migruojant ir atliekant techninę priežiūrą. Vartotojai nepastebi jokių trikdžių, net jei keičiu versijas, migruoju duomenis ar keičiu infrastruktūrą. Svarbi kiekviena sekundė, nes prisijungimas, išsiregistravimas ir API skambučiai turi vykti sklandžiai. Prastovos kainuoja pasitikėjimą, o dažnai ir tiesiogiai pinigus; parduotuvė, kurios kasdienė apyvarta siekia 240 000 eurų, praranda apie 167 eurus per minutę. Todėl architektūrą, procesus ir testus kuriu taip, kad bet kada galėčiau saugiai paleisti ir, atsiradus anomalijoms, iškart grąžinti atgal.
Pagrindinės strategijos iš pirmo žvilgsnio: Mėlynai-žalios spalvos, "Canary", "Rolling", "Toggles".
Naudoju "Blue-Green", kai noriu atspindėti aplinką ir per kelias sekundes perjungti eismą; taip sumažinu riziką ir išsaugau švarus Atsarginis lygis. "Canary" tinka pirmiausia siųsti naujas versijas nedideliam naudotojų skaičiui ir patikrinti jas naudojant realius rodiklius. Slenkančius atnaujinimus į instancijas diegiu etapais, o į sveikatos patikrinimus įtraukiu tik sveikas posoles. Funkcijų perjungikliai leidžia man įjungti arba sustabdyti funkcijas neperdiegus, o tai ypač naudinga atliekant jautrius vartotojo sąsajos pakeitimus. Kartu pasiekiamas greitas išleidimas, saugus testavimas gyvame kontekste ir aiškios galimybės nedelsiant atšaukti.
Eismo valdymas ir apkrovos balansavimas be trikdžių
Perjungiu duomenų srautą naudodamas 7 sluoksnio maršrutizavimą, sesijų tvarkymą ir sveikatos zondus, kad naudotojai nejaustų jokių perėjimų, o Keisti išlieka kontroliuojamas. "Blue-Green" atveju įeinančiam srautui nustatau maršruto taisykles ir seansus atskiriu lipniomis politikomis arba slapukais. Naudodamas "Canary", iš pradžių 1-5 % nukreipiu į naują versiją ir didinu etapais, jei klaidų dažnis ir uždelsimas yra tinkami. Palaipsniniams atnaujinimams naudingos kiekvieno egzemplioriaus neveikimo žymos, kad apkrovos balansavimo įrenginys nesiųstų jokių užklausų į diegimo mazgus. Pateikiu kompaktišką įrankių ir sąrankų apžvalgą Apkrovos balansavimo įrenginių palyginimas, kuriame nurodomos tipinės taisyklės, būklės patikrinimai ir TLS perkėlimas.
Nuolatinės paslaugos, sesijos ir jungtys
Nulinės prastovos dažnai nepavyksta dėl būsenos: sesijų, talpyklų ir atvirų jungčių. Nuosekliai iškeliu seansus į išorę (pvz., bendrąją saugyklą), jei įmanoma, naudoju bebūklės žymenis ir aktyvuoju Prijungimas Išleidimas, kad paleistos užklausos baigtųsi švariai. WebSockets arba serverio siunčiamų įvykių atveju išplečiu nutraukimo malonė, Anksti pažymiu atvejus kaip „ištuštėjančius“ ir palieku laisvą rezervą. Lipnias sesijas naudoju būtent tada, kai to reikalauja senasis kodas; kartu planuoju jas pakeisti, nes lipniosios politikos apsunkina mastelio keitimą ir "kanarėlių" padalijimą. Apriboju ilgas duomenų bazės operacijas mažesnėmis partijomis ir idempotencija, kad pakartotiniai bandymai nesukeltų šalutinių efektų.
Automatizavimas ir CI/CD: nuo įsipareigojimo iki išleidimo į gamybą
Automatizuoju kūrimą, testavimą, saugumo patikrinimus ir išleidimą aiškiu CI/CD vamzdynu, kad galėčiau atkurti, greitai ir saugus pristatyti. Prieš pradedant kontroliuojamą diegimą, kiekvienas pakeitimas tikrinamas atliekant vienetinius, integracinius ir bandomuosius testus. Varteliai sustabdo vamzdyną, jei padidėja klaidų skaičius arba pastebimas vėlavimas. Infrastruktūrą apibrėšiu kaip kodą, kad nuosekliai sukurčiau ir pakartočiau aplinkas. Jei norite įsigilinti, geriausią vamzdynų, grįžtamojo perkėlimo ir integracijos į debesis praktiką rasite straipsnyje CI/CD žiniatinklio prieglobos srityje.
Duomenų bazės perkėlimas be pertrūkių: CDC, dvigubas rašymas, šešėlinis skaitymas
Perkėlimo etapus suskirsčiau į schemos parengimą, masinį perkėlimą ir tiesioginį sinchronizavimą, kad parduotuvė ir toliau generuotų pardavimus, o duomenys būtų sinchronizuojami. pilnas lieka. Pakeitimų duomenų fiksavimas sinchronizuoja vykstančius pakeitimus realiuoju laiku. Pereinamuoju laikotarpiu lygiagrečiai rašau į senąją ir naująją duomenų bazes, kad nebūtų prarasti jokie užsakymai. Šešėlinis skaitymas patvirtina užklausas tikslinėje aplinkoje nedarant poveikio naudotojams. Tik tada, kai vientisumas, našumas ir klaidų lygis yra tinkami, perjungiu skaitymo apkrovą ir baigiu dvigubą rašymą.
Schemos evoliucija naudojant plėsti/sutraukti ir internetinį DDL
Planuoju duomenų bazės pakeitimus Atgalinis suderinamumasPirmiausia leidžiu atlikti papildomus pakeitimus (nauji stulpeliai su numatytaisiais, nauji indeksai, peržiūros), tada pritaikau kodą ir tik pabaigoje pašalinu senąjį kodą. Šis išplėtimo / susitraukimo modelis užtikrina, kad senosios ir naujosios programos versijos veiktų lygiagrečiai. Sunkias DDL operacijas atlieku internetu, kad operacijos nebūtų blokuojamos - pavyzdžiui, "MySQL" atveju, naudojant replikaciją ir atstatymą internetu. Ilgus perkėlimus suskirstau į mažus etapus, aiškiai matuodamas vykdymo laiką ir užraktus. Jei reikia, naudoju trigerius arba paslaugos logiką laikinai Dvigubi įrašai ir naudokite idempotenciją, kad užtikrintumėte, jog pakartojimai nesukurtų dublikatų. Kiekvienam pakeitimui suteikiamas unikalus migracijos ID, kad iškilus problemoms galėčiau jį iš naujo nustatyti.
Tinkamai naudoti funkcijų perjungiklius ir laipsnišką pristatymą
Griežtai laikau funkcijų vėliavėles versijomis ir dokumentais, kad galėčiau tikslingai kontroliuoti funkcijas ir išvengti paveldėtų problemų. Venkite gali. Žymos apima riziką, nes iš karto išjungiu funkcijas, kai tik padidėja klaidų skaičius. Progresyvus pristatymas susiejamas su tokiais rodikliais kaip sėkmingas prisijungimas, kasos konversija, P95 vėlavimas ir atminties šuoliai. Taisyklės nustato, kada aktyvuoju arba sustabdau kitą etapą. Tai leidžia man pateikti naujas funkcijas naudotojams nesukeliant pavojaus visai versijai.
Stebimumas, SLO ir apsauginiai barjerai nuspėjamiems išleidimams
Stebiu diegimą naudodamas žurnalus, metrikas ir pėdsakus, kad galėčiau anksti atpažinti anomalijas ir jas pašalinti. įsikišti. Paslaugų lygio tikslai apibrėžia aiškias ribas, pavyzdžiui, klaidų biudžeto, vėlavimo ir prieinamumo atžvilgiu. Jei ribos pasiekiamos, diegimas automatiškai sustabdomas ir pradedamas grįžimas atgal. Sintetinė stebėsena kas kelias minutes tikrina pagrindinius kelius, pavyzdžiui, prisijungimo ar išsiuntimo. Atlikimo knygose reakcijos aprašomos žingsnis po žingsnio, kad galėčiau veikti greitai, o ne improvizuoti ad hoc.
Bandymai tiesioginiame kontekste: šešėlinis srautas, dubliavimas ir apkrova
Prieš padidindamas kanarėlės dalį, siunčiu veidrodinis srautą į naują versiją ir įvertinti atsakymus nedarant įtakos naudotojams. Palyginsiu būsenos kodus, naudingosios apkrovos formatus, vėlavimą ir šalutinius poveikius. Sintetinė apkrova imituoja tipines apkrovos bangas (pvz., dienos pokyčius, rinkodaros piką) ir anksti atskleidžia pajėgumo problemas. Nustatau aiškias hipotezes ir atšaukimo kriterijus A/B tipo poveikiui, kad nepriimčiau sprendimų „pagal nuojautą“. Viską galima išmatuoti - ir tik išmatuojamus dalykus galima didinti be pertraukų.
Praktinis atvejo tyrimas: e. prekybos perkėlimas be prastovų
Migravau "MySQL" duomenų bazę į naują klasterį, o kasdien gaudavau dešimtis tūkstančių užsakymų ir kiekvieną minutę gaudavau apie 4 000 eurų pajamų. Pirmiausia parengiau schemą ir atlikau ne piko metu vykdomą masinį perkėlimą, kad kuo mažiau Krovinys sumažinti. Tada susiejau CDC su binlogais ir per kelias sekundes sinchronizavau įterpimus, atnaujinimus ir ištrynimus. 48 valandas programa lygiagrečiai rašė į šaltinį ir tikslą ir tikrino šešėlinio skaitymo nuoseklumą. Po stabilių metrikų, teisingos skaičiavimo logikos ir švarių indeksų perjungiau skaitymo apkrovą, sustabdžiau dvigubą rašymą ir pervedžiau senąją duomenų bazę į tik skaitymo režimą tolesniems patikrinimams.
"Kubernetes" specialios apsaugos priemonės, kad būtų išvengta prastovų
Naudodamasis "Kubernetes" nustačiau Pasirengimas- ir Gyvybingumas-Atsargiai nustatiau zondus taip, kad srautą matytų tik sveikos kapsulės, o sugedę procesai būtų automatiškai pakeičiami. Pasirenku konservatyvias diegimo strategijas: maxUnavailable=0 ir nuosaikus maxSurge užtikrina pajėgumą atnaujinimų metu. A preStop-Hook drain'o jungtys, o pakankamas terminationGracePeriod apsaugo nuo sunkių atšaukimų. PodDisruptionBudgets apsaugo pajėgumus mazgo priežiūros metu. Horizontal Pod Autoscaler I taikosi į signalus, artimus SLO (P95 latencija, eilės gylis), ne tik į CPU. Planuoju atskiras QoS klases darbo vietoms ir migracijos darbo krūviams, kad jie neišstumtų gamybinio srauto.
Strategijos matrica: Kada ką naudoti?
Taktiką renkuosi atsižvelgdamas į riziką, komandos brandą ir paslaugos architektūrą, kad būtų subalansuotos sąnaudos ir nauda. tinka. "Blue-Green" spindi aiškiai dubliuojamoje aplinkoje ir griežtuose vėlavimo reikalavimuose. Kanarėlė siūlo tikslią kontrolę funkcijoms su neaiškia naudojimo elgsena. Rolling pelno taškus, kai veikia daug egzempliorių ir yra horizontalaus mastelio keitimo galimybė. Funkcijų jungikliai papildo kiekvieną variantą, nes galiu valdyti funkcijas neperdiegdamas.
| Strategija | Stipriosios pusės | Tipinė rizika | Tinka |
|---|---|---|---|
| Mėlynai žalias | Greitas perjungimas, aiškus atsarginis lygis | Dvigubai daugiau reikiamų išteklių | Verslui svarbios taikomosios programos |
| Kanarėlės | Smulkiagrūdis valdymas | Sudėtinga stebėsena | Naujos funkcijos, neaiškus poveikis |
| Rolling | Maža didžiausia apkrova diegimo metu | Sudėtingos būsenos paslaugos | Dideli klasteriai, mikroservisai |
| Funkcijų jungikliai | Galimas skubus deaktyvavimas | Vėliava - skola, būtinas valdymas | Nuolatinis pristatymas |
Išlaidų, pajėgumų ir "FinOps" stebėjimas
"Blue-Green" reiškia dvigubai didesnį pajėgumą - sąmoningai tai planuoju ir reguliuoju per mastelio tikslus ir Efemeriška aplinka trumpalaikiams bandymams. Atliekant "kanarines" diegimo operacijas stebiu tokius sąnaudų veiksnius, kaip išėjimo, saugojimo IO ir CDN išvalymo rodikliai, nes dėl mažesnio gedimų skaičiaus sutaupytų lėšų neturi suvalgyti pernelyg didelės diegimo išlaidos. Spartinančiosios talpyklos pašildymas ir artefaktų pakartotinis panaudojimas sumažina šaltojo paleidimo išlaidas. Įtemptais sezonais (pvz., pardavimo kampanijų metu) įšaldau rizikingus pakeitimus ir palaikau parengtus buferinius pajėgumus, kad subalansuočiau prastovų riziką ir operacines išlaidas.
Sumažinkite riziką: Grįžimas atgal, duomenų apsauga ir atitiktis
Turiu paruoštą pilną grįžimo atgal planą, kad galėčiau iš karto grįžti prie naujausios versijos, jei atsirastų anomalijų. atgalpakeisti. Artefaktai ir konfigūracijos lieka su versijomis, kad galėčiau tiksliai atkurti būsenas. Patikrinu, ar duomenų keliai atitinka BDAR reikalavimus, ir šifruoju transportavimą bei poilsį. Reguliariai tikrinu atsargines kopijas, atlikdamas atkūrimo pratimus, o ne tik žalius žymėjimus. Prieigos kontrolė, dvigubos kontrolės principas ir audito žurnalai užtikrina, kad pakeitimus būtų galima atsekti.
Išorinė priklausomybė, ribos ir atsparumas
Daug nesėkmių kyla dėl trečiųjų šalių API, mokėjimo paslaugų teikėjų ar ERP sąsajų. Integracijas apjungiu su Grandinės pertraukikliai, Timeout ir retries su backoff ir atskyrimas per eiles. Kanarų etapuose atsižvelgiu į spartos ribas, kad nauja apkrova nesugriautų partnerių API. Jei paslaugų teikėjui nepavyksta, pradedamos taikyti atsarginės priemonės (pvz., asinchroninis apdorojimas, alternatyvūs šliuzai), o vartotojo sąsaja išlieka jautri. Širdies dūžiai ir sintetinės patikros stebi kritines priklausomybes atskirai, kad nereikėtų laukti naudotojų pranešimų apie klaidas ir sužinoti, kad išorinė paslauga užstrigo.
Saugumas ir slapta rotacija be sutrikimų
Sertifikatus, žetonus ir duomenų bazės įgaliojimus keičiu be pertrūkių naudodamas Dvigubų įgaliojimų etapas einplane: Senoji ir naujoji paslaptis galioja lygiagrečiai trumpą laiką. Diegimas pirmiausia atnaujina gavėjus, tada atšaukiam senąją paslaptį. Dėl parašo raktų naujus raktus išplatinu anksčiau ir leidžiu jiems išsisaugoti, kol juos aktyvuoju. mTLS ir griežtą TLS politiką laikau standartinės veiklos dalimi, o ne ypatingu atveju - taip išlaikoma pusiausvyra tarp saugumo ir prieinamumo.
Rekomendacijos prieglobos paslaugų teikėjams: nuo 0 iki "fail-safe
Pradedu nuo nedidelio, bet aiškaus vamzdyno, užuot kūręs didžiulę sistemą iš karto, ir plečiu ją žingsnis po žingsnio, naudodamas testus, "vartus" ir stebėjimo galimybes, kol išleidžiamos naujos versijos. Patikimas paleisti. "WordPress" aplinkose remiuosi etapais, tik skaitymui skirtais techninės priežiūros langais, skirtais turinio įšaldymui, ir duomenų bazių diegimu. Naudingų taktikų ir sąrankų sąrašą pateikiau straipsnyje apie Nulis prastovų su "WordPress. Tuo pačiu metu kiekvienai paslaugai nustatau SLO ir susieju jas su automatinio sustabdymo taisyklėmis. Kiekvieną savaitę analizuoju išleidimo rodiklius ir mokau komandą, kaip greitai ir saugiai grįžti atgal.
Kontrolinis sąrašas ir sėkmės rodikliai, siekiant nulinės prastovos
- ParuošimasAtkūrimo planas, artefaktai su versijomis, vykdymo knygos, budėjimas pagal iškvietimą.
- SuderinamumasIšplėsti / sudaryti sutartis dėl schemos, API versijų, funkcijų vėliavų.
- Eismo: Sveikatos zondai, ryšio mokymas, išskaidyti kanarėlių lygiai.
- DuomenysCDC, tik dvigubo įrašymo laikinosios, idempotencijos ir nuoseklumo patikros.
- StebimumasInformacinės lentelės, įspėjimai apie SLO ribas, stebėjimo mėginių ėmimas diegimo metu.
- ApsaugaSlapta rotacija su dviguba faze, mTLS, audito žurnalai.
- AtsparumasGrandinės pertraukikliai, laiko pertraukos, atsarginiai variantai trečiųjų šalių paslaugų teikėjams.
- Išlaidos: Planuokite talpos buferius, talpyklos atšilimą, CDN išvalymą.
- Pagrindiniai rodikliaiKlaidų dažnis (4xx/5xx pagal galinį tašką), P95/P99 vėlavimas, prisotinimas (CPU, atminties, IO), eilės gylis, atšaukimo dažnis, sėkmingas prisijungimas, talpyklos pasiekimo dažnis, regresijos pavojaus signalai kiekvienoje versijoje.
Apibendrinimas sprendimų priėmėjams
Tikro atsparumo pasiekiu derindamas strategijas ir kiekvieną žingsnį paversdamas išmatuojamu, o ne pasikliaudamas viltimi ar rizikuodamas. į ignoruoti. "Blue-Green" užtikrina greitą perjungimą, "Canary" suteikia įžvalgų apie apkrovą, "Rolling" užtikrina nuolatinį paslaugų veikimą, o "Toggles" perjungia saugias funkcijas. CI/CD, IaC ir testai užtikrina atkuriamą kokybę. CDC, dvigubo rašymo ir šešėlinio skaitymo funkcijos saugiai perkelia duomenis į naujas sistemas. Dėl aiškių SLO, griežto stebimumo ir išbandyto "Rollback" diegimas išlieka nuspėjamas - net kai ant kortos pastatytas didelis duomenų srautas ir pajamos.
