iki 12f-2
Balandžio pabaigoje, Baltiesiems vaikštyniams apgulus Vinterfelą, mums nutiko kažkas įdomesnio – mes atlikome neįprastą važiavimą. Iš esmės mes nuolat diegiame naujas funkcijas (kaip ir visi kiti). Tačiau šis buvo kitoks. Jos mastas buvo toks, kad bet kokios galimos klaidos, kurias galime padaryti, turės įtakos visoms mūsų paslaugoms ir vartotojams. Dėl to viską išriedėjome pagal planą, per suplanuotą ir paskelbtą prastovos laikotarpį, be pasekmių pardavimui. Straipsnis yra apie tai, kaip mes tai pasiekėme ir kaip kiekvienas gali tai pakartoti namuose.
Dabar neaprašysiu mūsų priimtų architektūrinių ir techninių sprendimų ir nepasakosiu, kaip visa tai veikia. Tai greičiau pastabos paraštėse apie tai, kaip vyko vienas iš sunkiausių diegimų, kurį stebėjau ir kuriame aš tiesiogiai dalyvavau. Nepretenduoju į išsamumą ar technines detales, galbūt jie bus kitame straipsnyje.
Fonas + kokia tai funkcija?
Kuriame debesų platformą (MCS), kur dirbu technikos direktoriumi. O dabar laikas prie mūsų platformos pridėti IAM (tapatybės ir prieigos valdymą), kuris suteikia vieningą visų vartotojų paskyrų, vartotojų, slaptažodžių, vaidmenų, paslaugų ir kt. valdymą. Kodėl jis reikalingas debesyje – akivaizdus klausimas: jame saugoma visa vartotojo informacija.
Paprastai tokie dalykai pradedami statyti pačioje bet kokių projektų pradžioje. Tačiau istoriškai viskas MCS buvo šiek tiek kitokia. MCS buvo pastatytas iš dviejų dalių:
- Openstack su savo Keystone autorizacijos moduliu,
- „Hotbox“ (S3 saugykla), pagrįsta Mail.ru debesies projektu,
aplink kurį tada atsirado naujų paslaugų.
Iš esmės tai buvo du skirtingi įgaliojimų tipai. Be to, naudojome kai kuriuos atskirus Mail.ru patobulinimus, pavyzdžiui, bendrąją Mail.ru slaptažodžių saugyklą, taip pat savarankiškai parašytą atvirą jungtį, kurios dėka skydelyje „Horizon“ buvo pateiktas SSO (autorizacija nuo galo iki galo). virtualių mašinų (savoji „OpenStack“ vartotojo sąsaja).
Padaryti IAM mums reiškė visa tai sujungti į vieną sistemą, visiškai savo. Kartu neprarasime nė vieno funkcionalumo pakeliui, o sukursime pagrindą ateičiai, leisiantį skaidriai jį tobulinti be pertvarkymo ir funkcionalumo mastelį. Taip pat pradžioje vartotojai turėjo pavyzdinį prieigos prie paslaugų modelį (centrinį RBAC, vaidmenimis pagrįstą prieigos kontrolę) ir kai kurias kitas smulkmenas.
Užduotis pasirodė nebanali: python ir perl, keletas backendų, savarankiškai parašytos paslaugos, kelios kūrėjų komandos ir administratoriai. Ir svarbiausia, kad kovos gamybos sistemoje yra tūkstančiai gyvų vartotojų. Visa tai reikėjo parašyti ir, svarbiausia, išriedėti be aukų.
Ką mes išleisime?
Labai grubiai tariant, per maždaug 4 mėnesius paruošėme:
- Sukūrėme keletą naujų demonų, kurie sujungė funkcijas, kurios anksčiau veikė įvairiose infrastruktūros dalyse. Likusioms paslaugoms buvo paskirta nauja šių demonų forma.
- Mes sukūrėme savo centrinę slaptažodžių ir raktų saugyklą, prieinamą visoms mūsų paslaugoms, kurią galime laisvai keisti pagal poreikį.
- Nuo pat pradžių sukūrėme 4 naujas „Keystone“ pagrindines programas (vartotojus, projektus, vaidmenis, vaidmenų priskyrimus), kurios iš tikrųjų pakeitė jos duomenų bazę ir dabar veikia kaip viena mūsų vartotojų slaptažodžių saugykla.
- Išmokėme visas savo „Openstack“ paslaugas ieškoti trečiosios šalies politikos tarnybos, o ne skaityti šias strategijas vietoje iš kiekvieno serverio (taip, „Openstack“ veikia pagal numatytuosius nustatymus!)
Toks didelis pertvarkymas reikalauja didelių, sudėtingų ir, svarbiausia, sinchroniškų kelių sistemų pakeitimų, kuriuos parašė skirtingos kūrėjų komandos. Surinkus, visa sistema turėtų veikti.
Kaip išrutulioti tokius pokyčius ir nesusukti? Pirmiausia nusprendėme šiek tiek pažvelgti į ateitį.
Išleidimo strategija
- Produktą būtų galima išvynioti keliais etapais, tačiau tai padidintų kūrimo laiką tris kartus. Be to, kurį laiką turėtume visišką duomenų desinchronizavimą duomenų bazėse. Turėtumėte sukurti savo sinchronizavimo įrankius ir ilgą laiką gyventi su keliomis duomenų saugyklomis. Ir tai sukuria daugybę įvairių pavojų.
- Viskas, ką buvo galima skaidriai paruošti vartotojui, buvo padaryta iš anksto. Prireikė 2 mėnesių.
- Leidome sau kelias valandas prastovos – tik naudotojo operacijoms kurti ir keisti išteklius.
- Visų jau sukurtų išteklių veikimui prastovos buvo nepriimtinos. Planavome, kad diegimo metu ištekliai turėtų veikti be prastovų ir nedarytų įtakos klientams.
- Siekdami sumažinti poveikį klientams, jei kas nors negerai, nusprendėme pradėti sekmadienio vakarą. Mažiau klientų naktimis valdo virtualias mašinas.
- Įspėjome visus savo klientus, kad pasirinktu diegimui laikotarpiu paslaugų valdymas nebus pasiekiamas.
Nukrypimas: kas yra išleidimas?
<atsargiai, filosofija>
Kiekvienas IT specialistas gali nesunkiai atsakyti, kas yra diegimas. Įdiegsite CI/CD ir viskas automatiškai pristatoma į parduotuvę. 🙂
Žinoma, tai tiesa. Tačiau sunkumas yra tas, kad naudojant šiuolaikinius kodo pristatymo automatizavimo įrankius prarandamas supratimas apie patį diegimą. Kaip pamiršti rato išradimo epiškumą žiūrint į šiuolaikinį transportą. Viskas taip automatizuota, kad diegimas dažnai atliekamas nesuvokiant viso vaizdo.
Ir visas vaizdas yra toks. Išleidimas susideda iš keturių pagrindinių aspektų:
- Kodo pristatymas, įskaitant duomenų modifikavimą. Pavyzdžiui, jų migracijos.
- Kodo grąžinimas – tai galimybė grįžti atgal, jei kas nors negerai. Pavyzdžiui, kurdami atsargines kopijas.
- Kiekvienos išleidimo / atšaukimo operacijos laikas. Turite suprasti bet kurios pirmųjų dviejų taškų operacijos laiką.
- Paveiktas funkcionalumas. Būtina įvertinti ir laukiamą teigiamą, ir galimą neigiamą poveikį.
Į visus šiuos aspektus reikia atsižvelgti, kad diegimas būtų sėkmingas. Paprastai vertinamas tik pirmasis, geriausiu atveju antrasis taškas, o tada diegimas laikomas sėkmingu. Tačiau trečiasis ir ketvirtasis yra dar svarbesni. Kuriam naudotojui patiktų, jei išleidimas truktų 3 valandas, o ne minutę? Arba, jei išleidžiant nukenčia kažkas nereikalingo? O gal vienos paslaugos prastovos sukels nenuspėjamų pasekmių?
1..n aktas, pasirengimas paleisti
Iš pradžių galvojau trumpai apibūdinti mūsų susitikimus: visa komanda, jos dalys, krūvos diskusijų kavos taškuose, ginčai, testai, minčių šturmai. Tada pagalvojau, kad tai bus nereikalinga. Keturi kūrimo mėnesiai visada susideda iš to, ypač kai rašote ne tai, ką galima nuolat pristatyti, o vieną didelę tiesioginės sistemos savybę. Tai turi įtakos visoms paslaugoms, tačiau vartotojams neturėtų pasikeisti niekas, išskyrus „vieną mygtuką žiniatinklio sąsajoje“.
Mūsų supratimas apie tai, kaip pradėti, pasikeitė po kiekvieno naujo susitikimo ir gana reikšmingai. Pavyzdžiui, ketinome atnaujinti visą atsiskaitymo duomenų bazę. Tačiau apskaičiavome laiką ir supratome, kad per protingą diegimo laiką to padaryti neįmanoma. Mums prireikė beveik papildomos savaitės, kol suskaidėme ir suarchyvavome atsiskaitymo duomenų bazę. O kai lauktas išleidimo greitis vis tiek netenkino, užsisakėme papildomą, galingesnę aparatūrą, kur buvo tempiama visa bazė. Tai nereiškia, kad nenorėjome to padaryti anksčiau, bet dabartinis poreikis diegti nepaliko jokių galimybių.
Kai vienam iš mūsų kilo abejonių, kad diegimas gali turėti įtakos mūsų virtualių mašinų prieinamumui, savaitę atlikome testus, eksperimentus, kodo analizę ir gavome aiškų supratimą, kad mūsų gamyboje taip neatsitiks, ir net labiausiai abejojantys žmonės sutiko. su šiuo.
Tuo tarpu techninės pagalbos vaikinai atliko savo nepriklausomus eksperimentus, norėdami klientams parašyti instrukcijas apie prisijungimo būdus, kurie turėjo pasikeisti po įdiegimo. Jie dirbo su vartotojo UX, ruošė instrukcijas ir teikė asmenines konsultacijas.
Automatizavome visas įmanomas išleidimo operacijas. Kiekviena operacija, net ir pati paprasčiausia, buvo scenarijus, o testai buvo nuolat vykdomi. Jie ginčijosi dėl geriausio būdo išjungti paslaugą – praleisti demoną arba užblokuoti prieigą prie paslaugos naudojant ugniasienę. Kiekvienam diegimo etapui sukūrėme kontrolinį komandų sąrašą ir nuolat jį atnaujinome. Mes nubraižėme ir nuolat atnaujinome Ganto diagramą, skirtą visiems diegimo darbams su terminais.
Ir taip…
Paskutinis veiksmas prieš išleidžiant
...atėjo laikas išriedėti.
Kaip sakoma, meno kūrinys negali būti užbaigtas, tik baigtas dirbti su juo. Turite dėti valios pastangas, suprasdami, kad visko nerasite, bet tikėdami, kad padarėte visas pagrįstas prielaidas, numatėte visus įmanomus atvejus, pašalinote visas kritines klaidas ir visi dalyviai padarė viską, ką galėjo. Kuo daugiau kodo išleisite, tuo sunkiau tuo įsitikinti (be to, visi supranta, kad visko numatyti neįmanoma).
Nusprendėme, kad esame pasirengę diegti, kai buvome įsitikinę, kad padarėme viską, kas įmanoma, kad padengtume visą naudotojų riziką, susijusią su netikėtais poveikiais ir prastovomis. Tai yra, viskas gali suklysti, išskyrus:
- Paveikti (mums šventa, brangiausia) vartotojo infrastruktūra,
- Funkcionalumas: mūsų paslauga po išleidimo turėtų būti naudojama taip pat, kaip ir prieš ją.
Išsivyniojantis
Du ritinėliai, 8 netrukdo
Visoms vartotojų užklausoms imame prastovos 7 valandas. Šiuo metu turime ir išleidimo planą, ir atšaukimo planą.
- Pats išleidimas trunka apie 3 valandas.
- 2 valandos bandymui.
- 2 valandos – rezervas galimam pakeitimų atšaukimui.
Kiekvienam veiksmui sudaryta Ganto diagrama, kiek laiko tai trunka, kas vyksta nuosekliai, kas daroma lygiagrečiai.
Išleistos Ganto diagramos dalis, viena iš ankstyvųjų versijų (be lygiagretaus vykdymo). Vertingiausias sinchronizavimo įrankis
Visiems dalyviams nustatomas jų vaidmuo diegiant, kokias užduotis jie atlieka ir už ką yra atsakingi. Stengiamės kiekvieną etapą priartinti prie automatizavimo, išvynioti, atsukti atgal, renkame atsiliepimus ir vėl iškeliame.
Įvykių kronika
Taigi sekmadienį, balandžio 15 d., 29 val., į darbą atėjo 10 žmonių. Be pagrindinių dalyvių, kai kurie atvyko tiesiog palaikyti komandos, už tai jiems ypatingas ačiū.
Taip pat verta paminėti, kad mūsų pagrindinis testuotojas atostogauja. Neįmanoma įdiegti be bandymų, mes ieškome galimybių. Kolegė sutinka mus išbandyti iš atostogų, už tai sulaukia didžiulio viso kolektyvo padėkos.
00:00. Sustabdyti
Sustabdome vartotojų prašymus, pakabiname lentelę su užrašu techninis darbas. Stebėjimas rėkia, bet viskas normalu. Patikriname, ar nenukrito niekas, išskyrus tai, kas turėjo kristi. Ir mes pradedame darbą su migracija.
Kiekvienas turi atspausdintą išleidimo planą taškas po taško, visi žino, kas ką daro ir kuriuo momentu. Po kiekvieno veiksmo tikriname laiką, kad įsitikintume, jog jų neviršijame, ir viskas vyksta pagal planą. Tie, kurie dabartiniame etape tiesiogiai nedalyvauja išleidime, ruošiasi paleisti internetinį žaislą (Xonotic, 3 tipo quacks), kad netrukdytų kolegoms. 🙂
02:00. Iškočiojama
Malonus siurprizas – išleidimą baigiame valanda anksčiau dėl mūsų duomenų bazių ir perkėlimo scenarijų optimizavimo. Bendras šauksmas: „Išvyniota! Visos naujos funkcijos yra gamyboje, tačiau kol kas jas matome sąsajoje tik mes. Visi pereina į testavimo režimą, suskirsto juos į grupes ir pradeda matyti, kas galiausiai atsitiko.
Nelabai pavyko, tai suvokiame po 10 minučių, kai komandos narių projektuose niekas nesusieja ar neveikia. Greitas sinchronizavimas, mes išreiškiame savo problemas, nustatome prioritetus, susiskirstome į komandas ir pradedame derinti.
02:30. Dvi didelės problemos prieš keturias akis
Pastebime dvi dideles problemas. Supratome, kad kai kurių prijungtų paslaugų klientai nematys, kils problemų dėl partnerių paskyrų. Abu yra dėl netobulų perkėlimo scenarijų kai kuriems kraštutiniams atvejams. Turime tai pataisyti dabar.
Rašome užklausas, kurios tai įrašo, su mažiausiai 4 akimis. Išbandome juos išankstinės gamybos metu, kad įsitikintume, ar jie veikia ir nieko nesulaužo. Galite riedėti toliau. Tuo pačiu metu atliekame įprastą integracijos testavimą, kuris atskleidžia dar keletą problemų. Visi jie nedideli, bet ir juos reikia taisyti.
03:00. -2 problemos +2 problemos
Dvi ankstesnės didelės problemos buvo išspręstos ir beveik visos nedidelės. Visi tie, kurie nėra užsiėmę taisymais, aktyviai dirba savo paskyrose ir praneša apie tai, ką rado. Suskirstome prioritetus, paskirstome komandoms, o nekritinius daiktus paliekame rytui.
Atliekame bandymus dar kartą, jie atranda dvi naujas dideles problemas. Ne visos paslaugų strategijos buvo pateiktos tinkamai, todėl kai kurios vartotojų užklausos nepraeina prieigos teisės. Be to, nauja problema, susijusi su partnerių paskyromis. Suskubkime žiūrėti.
03:20. Avarinis sinchronizavimas
Ištaisyta viena nauja problema. Antruoju atveju organizuojame avarinį sinchronizavimą. Suprantame, kas vyksta: ankstesnis pataisymas išsprendė vieną problemą, bet sukūrė kitą. Darome pertrauką, kad išsiaiškintume, kaip tai padaryti teisingai ir be pasekmių.
03:30. Šešios akys
Suprantame, kokia turi būti galutinė bazės būsena, kad visiems partneriams viskas vyktų gerai. Rašome užklausą 6 akimis, išvyniojame priešgamyboje, testuojame, išriečiame gamybai.
04:00. Viskas veikia
Visi testai išlaikyti, kritinių problemų nesimato. Kartkartėmis kažkam komandoje kažkas nepasiseka, reaguojame operatyviai. Dažniausiai pavojaus signalas yra klaidingas. Tačiau kartais kažkas neateina arba atskiras puslapis neveikia. Sėdim, taisom, taisom, taisom. Atskira komanda pristato paskutinę didelę funkciją – atsiskaitymą.
04:30. Taškas be sugrįžimo
Artėja negrįžimo taškas, tai yra laikas, kai, pradėję riedėti atgal, nesutiksime suteiktos prastovos. Iškyla problemų su atsiskaitymu, kuris viską žino ir fiksuoja, bet atkakliai atsisako nurašyti pinigus iš klientų. Atskiruose puslapiuose, veiksmuose ir būsenose yra keletas klaidų. Pagrindinis funkcionalumas veikia, visi testai sėkmingai praeina. Nusprendžiame, kad išleidimas įvyko, atgal nebesuksime.
06:00. Atvira visiems naudotojo sąsajoje
Ištaisytos klaidos. Kai kurios, kurios nepatinka vartotojams, paliekamos vėlesniam laikui. Mes atveriame sąsają visiems. Mes ir toliau dirbame su atsiskaitymu, laukiame vartotojų atsiliepimų ir stebėjimo rezultatų.
07:00. Problemos su API įkėlimu
Tapo aišku, kad šiek tiek neteisingai suplanavome savo API apkrovą ir išbandėme šią apkrovą, kuri negalėjo nustatyti problemos. Dėl to ≈5 % užklausų nepavyksta. Mobilizuokime ir ieškokime priežasties.
Atsiskaitymas užsispyręs ir taip pat nenori dirbti. Nusprendžiame jį atidėti vėlesniam laikui, kad pakeitimus atliktume ramiai. Tai yra, visi resursai sukaupti jame, tačiau nurašymai iš klientų nevyksta. Žinoma, tai yra problema, tačiau, palyginti su bendru diegimu, ji atrodo nesvarbi.
08:00. Pataisyti API
Išriedėjome krovinio pataisymą, gedimai išnyko. Pradedam eiti namo.
10:00. Visi
Viskas sutvarkyta. Stebint tylu, o pas klientus komanda pamažu eina miegoti. Atsiskaitymas lieka, atstatysime rytoj.
Tada per dieną buvo įdiegtos kai kurių mūsų klientų žurnalai, pranešimai, grąžinimo kodai ir pritaikymai.
Taigi, diegimas buvo sėkmingas! Žinoma, gali būti ir geriau, bet padarėme išvadas, ko nepakako, kad pasiektume tobulumą.
Iš viso
Per 2 aktyvaus pasiruošimo diegimui mėnesius buvo atliktos 43 užduotys, trukusios nuo poros valandų iki kelių dienų.
Išleidimo metu:
- nauji ir pakeisti demonai - 5 vnt, pakeičiantys 2 monolitus;
- pasikeitimai duomenų bazėse - visos 6 mūsų duomenų bazės su vartotojų duomenimis buvo paveiktos, iš trijų senų duomenų bazių buvo atsisiunčiama į vieną naują;
- visiškai pertvarkyta priekinė dalis;
- atsisiųsto kodo kiekis - 33 tūkst. naujo kodo eilučių, ≈ 3 tūkst. kodo eilučių testuose, ≈ 5 tūkst. eilučių migracijos kodo;
- visi duomenys nepažeisti, nebuvo pažeista nei vieno kliento virtuali mašina. 🙂
Gera sėkmingo diegimo praktika
Jie mums vadovavo šioje sudėtingoje situacijoje. Tačiau apskritai naudinga jų laikytis bet kokio diegimo metu. Tačiau kuo sudėtingesnis diegimas, tuo didesnis jų vaidmuo.
- Pirmas dalykas, kurį turite padaryti, yra suprasti, kaip diegimas gali arba turės įtakos naudotojams. Ar bus prastovos? Jei taip, kokia yra prastovos laikas? Kaip tai paveiks vartotojus? Kokie galimi geriausi ir blogiausi scenarijai? Ir padengti riziką.
- Suplanuokite viską. Kiekviename etape turite suprasti visus išleidimo aspektus:
- kodo pristatymas;
- kodo grąžinimas;
- kiekvienos operacijos laikas;
- paveiktas funkcionalumas.
- Žaiskite scenarijus, kol visi išleidimo etapai ir rizika kiekviename iš jų taps akivaizdūs. Jei turite kokių nors abejonių, galite padaryti pertrauką ir atskirai panagrinėti abejotiną etapą.
- Kiekvieną etapą galima ir reikia tobulinti, jei tai padeda mūsų vartotojams. Pavyzdžiui, tai sumažins prastovos laiką arba pašalins tam tikrą riziką.
- Atšaukimo testavimas yra daug svarbesnis nei kodo pristatymo testavimas. Būtina patikrinti, ar dėl atšaukimo sistema grįš į pradinę būseną, ir tai patvirtinti bandymais.
- Viskas, ką galima automatizuoti, turi būti automatizuota. Viskas, ko negalima automatizuoti, turėtų būti iš anksto surašyta cheat sheet.
- Įrašykite sėkmės kriterijų. Kokios funkcijos turėtų būti prieinamos ir kokiu laiku? Jei taip neatsitiks, vykdykite atšaukimo planą.
- O svarbiausia – žmonės. Kiekvienas turėtų žinoti, ką daro, kodėl ir kas priklauso nuo jo veiksmų diegimo procese.
Ir vienu sakiniu, gerai suplanavę ir išdirbę, galite įdiegti viską, ko norite, be pasekmių pardavimui. Netgi tai, kas turės įtakos visoms jūsų paslaugoms gamyboje.
Šaltinis: www.habr.com