🥇 Saga útfærslunnar, sem hafði áhrif á allt

Óvinir raunveruleikans eftir 12f-2

Í lok apríl, á meðan White Walkers sátu um Winterfell, gerðist eitthvað meira áhugavert fyrir okkur; við gerðum óvenjulega uppsetningu. Í grundvallaratriðum erum við stöðugt að setja nýja eiginleika í framleiðslu (eins og allir aðrir). En þessi var öðruvísi. Umfang þess var slíkt að hugsanleg mistök sem við gætum gert myndu hafa áhrif á alla þjónustu okkar og notendur. Fyrir vikið rúlluðum við öllu út samkvæmt áætlun, innan fyrirhugaðs og tilkynnts tímafrests, án afleiðinga fyrir sölu. Greinin fjallar um hvernig við náðum þessu og hvernig hver sem er getur endurtekið það heima.

Ég mun nú ekki lýsa byggingarfræðilegum og tæknilegum ákvörðunum sem við tókum eða segja hvernig þetta allt virkar. Þetta eru frekar athugasemdir á spássíunni um hvernig ein erfiðasta útfærslan átti sér stað, sem ég fylgdist með og tók beinan þátt í. Ég geri ekki kröfu um að þær séu tæmandi eða tæknilegar upplýsingar; kannski munu þær birtast í annarri grein.

Bakgrunnur + hvers konar virkni er þetta?

Við erum að byggja upp skýjapallur Mail.ru skýjalausnir (MCS), þar sem ég starfa sem tæknistjóri. Og nú er kominn tími til að bæta IAM (Identity and Access Management) við vettvang okkar, sem veitir sameinaða stjórnun á öllum notendareikningum, notendum, lykilorðum, hlutverkum, þjónustu og fleira. Hvers vegna það er nauðsynlegt í skýinu er augljós spurning: allar notendaupplýsingar eru geymdar í því.

Venjulega byrjar slíkir hlutir að vera byggðir strax í upphafi hvers verkefnis. En sögulega hafa hlutirnir verið aðeins öðruvísi í MCS. MCS var byggt í tveimur hlutum:

Openstack með eigin Keystone heimildareiningu,
Hotbox (S3 geymsla) byggt á Mail.ru Cloud verkefninu,

í kringum sem ný þjónusta birtist síðan.

Í meginatriðum voru þetta tvær mismunandi tegundir heimilda. Auk þess notuðum við nokkra sérstaka Mail.ru þróun, til dæmis almenna Mail.ru lykilorðageymslu, auk sjálfskrifaðs openid tengis, þökk sé SSO (enda-til-enda heimild) var veitt á Horizon spjaldinu af sýndarvélum (native OpenStack UI).

Að búa til IAM fyrir okkur þýddi að tengja þetta allt saman í eitt kerfi, algjörlega okkar eigin. Á sama tíma munum við ekki missa neina virkni á leiðinni heldur munum við búa til grunn fyrir framtíðina sem gerir okkur kleift að betrumbæta hana á gagnsæjan hátt án þess að endurskipuleggja hana og skala hana með tilliti til virkni. Einnig í upphafi áttu notendur sér fyrirmynd fyrir aðgang að þjónustu (miðlægt RBAC, hlutverkatengd aðgangsstýring) og ýmislegt fleira.

Verkefnið reyndist ekki léttvægt: Python og perl, nokkrir bakenda, sjálfstætt skrifuð þjónusta, nokkur þróunarteymi og stjórnendur. Og síðast en ekki síst, það eru þúsundir lifandi notenda á bardagaframleiðslukerfinu. Allt þetta þurfti að skrifa og, síðast en ekki síst, rúlla út án mannfalls.

Hvað ætlum við að rúlla út?

Til að orða það mjög gróft, á um það bil 4 mánuðum undirbúum við eftirfarandi:

Við bjuggum til nokkra nýja púka sem söfnuðu saman aðgerðum sem áður virkuðu á mismunandi hlutum innviðanna. Restin af þjónustunni var ávísað nýjum bakenda í formi þessara djöfla.
Við skrifuðum okkar eigin miðlæga geymslu lykilorða og lykla, tiltæk fyrir alla þjónustu okkar, sem hægt er að breyta að vild eftir þörfum.
Við skrifuðum 4 nýja bakenda fyrir Keystone frá grunni (notendur, verkefni, hlutverk, hlutverkaúthlutun), sem í raun kom í stað gagnagrunns þess og virkar nú sem ein geymsla fyrir lykilorð notenda okkar.
Við kenndum öllum Openstack þjónustunum okkar að fara í stefnuþjónustu þriðja aðila fyrir stefnu þeirra í stað þess að lesa þessar reglur á staðnum frá hverjum netþjóni (já, þannig virkar Openstack sjálfgefið!)

Svo mikil endurvinna krefst stórra, flókinna og, síðast en ekki síst, samstilltra breytinga á nokkrum kerfum sem skrifuð eru af mismunandi þróunarteymi. Þegar það hefur verið sett saman ætti allt kerfið að virka.

Hvernig á að rúlla út slíkum breytingum og ekki klúðra því? Fyrst ákváðum við að líta aðeins inn í framtíðina.

Útsetningarstefna

Hægt væri að rúlla vörunni út í nokkrum áföngum en það myndi þrisvar auka þróunartímann. Að auki myndum við í einhvern tíma hafa algjöra afsamstillingu gagna í gagnagrunnunum. Þú þyrftir að skrifa eigin samstillingartæki og búa við margar gagnageymslur í langan tíma. Og þetta skapar margs konar áhættu.
Allt sem hægt var að útbúa gagnsætt fyrir notandann var gert fyrirfram. Það tók 2 mánuði.
Við leyfðum okkur niður í miðbæ í nokkrar klukkustundir - aðeins fyrir notendaaðgerðir til að búa til og breyta tilföngum.
Fyrir rekstur allra þegar stofnaðra auðlinda var niður í miðbæ óviðunandi. Við ætluðum að við útsetningu ættu tilföng að vinna án niður í miðbæ og hafa áhrif á viðskiptavini.
Til að draga úr áhrifum á viðskiptavini okkar ef eitthvað fer úrskeiðis ákváðum við að rúlla út á sunnudagskvöldið. Færri viðskiptavinir stjórna sýndarvélum á kvöldin.
Við vöruðum alla viðskiptavini okkar við því að á tímabilinu sem valið er til útfærslu verður þjónustustjórnun ekki tiltæk.

Útrás: hvað er útsetning?

<varúð, heimspeki>

Sérhver upplýsingatæknisérfræðingur getur auðveldlega svarað hvað útsetning er. Þú setur upp CI/CD og allt kemur sjálfkrafa í búðina. 🙂

Auðvitað er þetta satt. En erfiðleikarnir eru þeir að með nútíma sjálfvirkum tólum fyrir kóðaafhendingu glatast skilningurinn á útfærslunni sjálfri. Hvernig þú gleymir epicness uppfinningu hjólsins þegar þú horfir á nútíma samgöngur. Allt er svo sjálfvirkt að uppsetningin er oft framkvæmd án þess að skilja heildarmyndina.

Og heildarmyndin er svona. Útfærsla samanstendur af fjórum meginþáttum:

Afhending kóða, þar á meðal gagnabreytingar. Til dæmis fólksflutningar þeirra.
Til baka kóða er hæfileikinn til að fara til baka ef eitthvað fer úrskeiðis. Til dæmis með því að búa til afrit.
Tími hverrar útfærslu/tilbakaaðgerðar. Þú þarft að skilja tímasetningu hvers kyns aðgerða á fyrstu tveimur punktunum.
Virkni sem hefur áhrif á. Nauðsynlegt er að leggja mat á bæði væntanleg jákvæð og hugsanleg neikvæð áhrif.

Taka verður tillit til allra þessara þátta til að útfærsla takist vel. Venjulega er aðeins fyrsta, eða í besta falli annað stig metið, og þá er útfærslan talin vel heppnuð. En þriðji og fjórði eru enn mikilvægari. Hvaða notandi myndi vilja það ef útfærslan tæki 3 klukkustundir í staðinn fyrir eina mínútu? Eða ef eitthvað óþarft verður fyrir áhrifum við útsetningu? Eða mun niðurtími einnar þjónustu leiða til ófyrirsjáanlegra afleiðinga?

Lög 1..n, undirbúningur fyrir útgáfu

Í fyrstu datt mér í hug að lýsa fundum okkar í stuttu máli: allt liðið, hluta þess, hrúga af umræðum á kaffiveitingum, rifrildi, prófum, hugarflugi. Þá hélt ég að það væri óþarfi. Fjögurra mánaða þróun samanstendur alltaf af þessu, sérstaklega þegar þú ert ekki að skrifa eitthvað sem hægt er að afhenda stöðugt, heldur einn stóran eiginleika fyrir lifandi kerfi. Sem hefur áhrif á alla þjónustu, en ekkert ætti að breytast fyrir notendur nema „einn hnappur í vefviðmótinu“.

Skilningur okkar á því hvernig eigi að koma út breyttist frá hverjum nýjum fundi, og töluvert. Til dæmis ætluðum við að uppfæra allan innheimtugagnagrunninn okkar. En við reiknuðum út tímann og komumst að því að það var ómögulegt að gera þetta á hæfilegum tíma. Það tók okkur næstum viku í viðbót að klippa og geyma innheimtugagnagrunninn. Og þegar væntanlegur útrásarhraði var enn ekki fullnægjandi pöntuðum við viðbótar, öflugri vélbúnað, þar sem allur grunnurinn var dreginn. Það er ekki það að við vildum ekki gera þetta fyrr, en núverandi þörf fyrir að rúlla út skildi okkur ekki hafa neina valkosti.

Þegar eitt okkar hafði efasemdir um að útbreiðslan gæti haft áhrif á framboð sýndarvélanna okkar, eyddum við viku í að framkvæma prófanir, tilraunir, kóðagreiningu og fengum skýran skilning á því að þetta myndi ekki gerast í framleiðslu okkar og jafnvel þeir sem efast um voru sammála með þessu.

Í millitíðinni gerðu strákarnir frá tækniaðstoðinni sínar eigin sjálfstæðar tilraunir til að skrifa leiðbeiningar fyrir viðskiptavini um tengiaðferðir, sem áttu að breytast eftir útsetningu. Þeir unnu að notendaviðmóti, útbjuggu leiðbeiningar og veittu persónulega ráðgjöf.

Við sjálfvirkum allar útfærsluaðgerðir sem mögulegar voru. Sérhver aðgerð var skrifuð, jafnvel þær einföldustu, og prófanir voru stöðugt keyrðar. Þeir deildu um bestu leiðina til að slökkva á þjónustunni - sleppa púknum eða loka fyrir aðgang að þjónustunni með eldvegg. Við bjuggum til gátlista yfir teymi fyrir hvert stig útsetningar og uppfærðum hann stöðugt. Við teiknuðum og uppfærðum stöðugt Gantt töflu fyrir alla útfærsluvinnu, með tímasetningum.

Og svo…

Lokaþátturinn, áður en hann rúllar út

...það er kominn tími til að rúlla út.

Eins og sagt er er ekki hægt að klára listaverk, bara klára að vinna að því. Þú verður að gera tilraunir með vilja, skilja að þú munt ekki finna allt, en trúa því að þú hafir gert allar sanngjarnar forsendur, gert ráð fyrir öllum mögulegum tilfellum, lokað öllum mikilvægum villum og allir þátttakendur gerðu allt sem þeir gátu. Því meiri kóða sem þú rúllar út, því erfiðara er að sannfæra sjálfan þig um þetta (að auki skilja allir að það er ómögulegt að sjá allt fyrir).

Við ákváðum að við værum tilbúin að fara í notkun þegar við vorum sannfærð um að við hefðum gert allt sem unnt var til að mæta öllum áhættum fyrir notendur okkar sem tengdust óvæntum áhrifum og niður í miðbæ. Það er, allt getur farið úrskeiðis nema:

Hafa áhrif á (heilagt okkur, dýrmætustu) notendainnviði,
Virkni: notkun þjónustu okkar eftir útfærslu ætti að vera sú sama og áður.

Rúlla út

Tvö rúlla, 8 trufla ekki

Við tökum niður tíma fyrir allar beiðnir frá notendum í 7 klukkustundir. Á þessum tíma erum við bæði með útfærsluáætlun og afturköllunaráætlun.

Útfærslan sjálf tekur um það bil 3 klukkustundir.
2 tímar til að prófa.
2 klukkustundir - áskilið fyrir hugsanlega afturköllun breytinga.

Búið er að gera Gantt-töflu fyrir hverja aðgerð, hversu langan tíma hún tekur, hvað gerist í röð, hvað er gert samhliða.

Hluti af útfærslu Gantt-töflu, ein af fyrstu útgáfunum (án samhliða framkvæmdar). Verðmætasta samstillingartækið

Allir þátttakendur hafa ákveðið hlutverk sitt í útfærslunni, hvaða verkefni þeir vinna og hverju þeir bera ábyrgð á. Við reynum að koma hverju stigi í sjálfvirkni, rúlla því út, rúlla því til baka, safna viðbrögðum og rúlla því út aftur.

Annáll atburða

Svo mættu 15 manns til vinnu sunnudaginn 29. apríl kl.10. Auk lykilþátttakenda komu nokkrir einfaldlega til að styðja við bakið á liðinu og er þeim sérstaklega þakkað fyrir það.

Það er líka rétt að minnast á að lykilprófari okkar er í fríi. Það er ómögulegt að rúlla út án þess að prófa, við erum að kanna valkosti. Samstarfsmaður samþykkir að prófa okkur frá fríi, fyrir það fær hún gríðarlega þakklæti frá öllu teyminu.

00:00. Hættu
Við hættum notendabeiðnum, hengjum upp skilti sem segir tæknivinnu. Eftirlitið öskrar en allt er eðlilegt. Við athugum að ekkert hafi dottið annað en það sem átti að detta. Og við byrjum að vinna að fólksflutningum.

Allir eru með útprentaða útsetningaráætlun lið fyrir lið, allir vita hver er að gera hvað og á hvaða augnabliki. Eftir hverja aðgerð athugum við tímasetningar til að tryggja að við förum ekki fram úr þeim og allt gengur samkvæmt áætlun. Þeir sem taka ekki þátt í útsetningunni beint á núverandi stigi eru að undirbúa sig með því að setja á markað leikfang á netinu (Xonotic, tegund 3 quacks) til að trufla ekki samstarfsmenn sína. 🙂

02:00. Rúllaði út
Það kom skemmtilega á óvart - við ljúkum útsetningu klukkutíma fyrr, vegna hagræðingar á gagnagrunnum okkar og flutningsforskriftum. Hershöfðinginn hrópaði, "rúllað út!" Allar nýjar aðgerðir eru í framleiðslu, en enn sem komið er getum við aðeins séð þær í viðmótinu. Allir fara í prófunarham, raða þeim í hópa og byrja að sjá hvað gerðist á endanum.

Það kom ekkert sérstaklega vel út, við gerum okkur grein fyrir þessu eftir 10 mínútur, þegar ekkert er tengt eða að vinna í verkefnum liðsmanna. Fljótleg samstilling, við tjáum vandamál okkar, setjum forgangsröðun, brjótumst inn í teymi og förum í villuleit.

02:30. Tvö stór vandamál á móti fjögur augu
Við finnum tvö stór vandamál. Við gerðum okkur grein fyrir því að viðskiptavinir myndu ekki sjá einhverja tengda þjónustu og vandamál myndu koma upp með reikninga samstarfsaðila. Hvort tveggja stafar af ófullkomnum flutningsforskriftum fyrir sum jaðartilvik. Við þurfum að laga það núna.

Við skrifum fyrirspurnir sem skrá þetta, með að minnsta kosti 4 augum. Við prófum þau í forframleiðslu til að tryggja að þau virki og brotni ekki neitt. Þú getur rúllað áfram. Á sama tíma keyrum við reglulega samþættingarprófun okkar sem leiðir í ljós nokkur vandamál til viðbótar. Þær eru allar litlar en þarf líka að gera við þær.

03:00. -2 vandamál +2 vandamál
Tvö fyrri stóru vandamálin hafa verið lagfærð og næstum öll minniháttar líka. Allir þeir sem eru óuppteknir í lagfæringum eru virkir að vinna í reikningum sínum og segja frá því sem þeir finna. Við forgangsraðum, deilum á milli teyma og skiljum eftir ómikilvæg atriði fyrir morguninn.

Við keyrum prófin aftur, þau uppgötva tvö ný stór vandamál. Ekki komu allar þjónustureglur rétt, þannig að sumar notendabeiðnir standast ekki heimild. Plús nýtt vandamál með reikninga samstarfsaðila. Við skulum flýta okkur að skoða.

03:20. Neyðarsamstilling
Eitt nýtt mál lagað. Í öðru lagi erum við að skipuleggja neyðarsamstillingu. Við skiljum hvað er að gerast: fyrri lagfæringin lagaði eitt vandamál en skapaði annað. Við tökum okkur hlé til að finna út hvernig á að gera það rétt og án afleiðinga.

03:30. Sex augu
Við skiljum hvernig endanlegt ástand grunnsins ætti að vera svo allt gangi vel fyrir alla samstarfsaðila. Við skrifum beiðni með 6 augum, rúllum henni út í forframleiðslu, prófum hana, rúllum henni út til framleiðslu.

04:00. Allt er að virka
Öll próf stóðust, engin mikilvæg vandamál eru sýnileg. Af og til virkar eitthvað í teyminu ekki fyrir einhvern, við bregðumst strax við. Oftast er viðvörunin fölsk. En stundum kemur eitthvað ekki, eða sérstök síða virkar ekki. Við sitjum, laga, laga, laga. Sérstakt teymi er að setja af stað síðasta stóra eiginleikann - innheimtu.

04:30. Point of no return
Það er ekki aftur snúið, það er sá tími þegar við, ef við byrjum að snúa aftur til baka, munum ekki mæta niður í miðbænum sem okkur er gefinn. Það eru vandamál með innheimtu, sem veit og skráir allt, en harðneitar að afskrifa peninga frá viðskiptavinum. Það eru nokkrar villur á einstökum síðum, aðgerðum og stöðu. Helstu virkni virkar, öll próf standast með góðum árangri. Við ákveðum að útsetning hafi átt sér stað, við munum ekki snúa aftur.

06:00. Opið fyrir alla í HÍ
Villur lagaðar. Sumir sem höfða ekki til notenda eru látnir bíða síðar. Við opnum viðmótið fyrir alla. Við höldum áfram að vinna að innheimtu, bíðum eftir viðbrögðum notenda og fylgjumst með niðurstöðum.

07:00. Vandamál með API hleðslu
Það verður ljóst að við misskipulögðum aðeins álagið á API okkar og prófuðum þetta álag, sem gat ekki greint vandamálið. Þess vegna mistakast ≈5% beiðna. Virkjum og leitum að ástæðunni.

Innheimta er þrjósk og vill ekki virka heldur. Við ákveðum að fresta því þar til síðar til að framkvæma breytingarnar í rólegheitum. Það er, allt fjármagn safnast í það, en afskriftir frá viðskiptavinum ganga ekki í gegn. Auðvitað er þetta vandamál, en miðað við almenna útsetningu virðist það ekki mikilvægt.

08:00. Lagaðu API
Við settum út lagfæringu fyrir álagið, bilanir fóru í burtu. Við byrjum að fara heim.

10:00. Allt
Allt er lagað. Það er rólegt í eftirliti og hjá viðskiptavinum fer liðið smám saman að sofa. Innheimtan er eftir, við endurheimtum hana á morgun.

Svo á daginn voru útfærslur sem lagfærðu annála, tilkynningar, skilakóða og sérstillingar fyrir suma viðskiptavini okkar.

Þannig að uppsetningin tókst! Það gæti auðvitað verið betra, en við drógum ályktanir um hvað væri ekki nóg til að við náum fullkomnun.

Alls

Á 2 mánaða virkum undirbúningi fyrir útfærsluna var 43 verkum lokið, allt frá nokkrum klukkustundum upp í nokkra daga.

Við útsetningu:

nýir og breyttir djöflar - 5 stykki, koma í stað 2 einlita;
breytingar innan gagnagrunnanna - allir 6 gagnagrunnarnir okkar með notendagögnum hafa orðið fyrir áhrifum, niðurhal hefur verið gert úr þremur gömlum gagnagrunnum yfir í einn nýjan;
algjörlega endurhannað framhlið;
magn niðurhalaðs kóða - 33 þúsund línur af nýjum kóða, ≈ 3 þúsund línur af kóða í prófum, ≈ 5 þúsund línur af flutningskóða;
öll gögn eru ósnortin, ekki skemmdist sýndarvél eins viðskiptavinar. 🙂

Góðar venjur fyrir góða útsetningu

Þeir leiddu okkur í þessari erfiðu stöðu. En almennt séð er gagnlegt að fylgja þeim meðan á útfærslu stendur. En því flóknari sem útsetningin er, því stærra hlutverk gegna þeir.

Það fyrsta sem þú þarft að gera er að skilja hvernig útfærslan getur eða mun hafa áhrif á notendur. Verður niðurtími? Ef svo er, hver er niðurtíminn? Hvaða áhrif mun þetta hafa á notendur? Hver eru möguleg bestu og versta aðstæður? Og hylja áhættuna.
Skipuleggðu allt. Á hverju stigi þarftu að skilja alla þætti útfærslu:
- afhending kóða;
- kóða afturköllun;
- tíma hverrar aðgerð;
- áhrif á virkni.
Spilaðu í gegnum atburðarásina þar til öll stig útfærslunnar, sem og áhættan við hvert þeirra, verða augljós. Ef þú hefur einhverjar efasemdir geturðu dregið þig í hlé og skoðað hið vafasama stig sérstaklega.
Hvert stig má og ætti að bæta ef það hjálpar notendum okkar. Til dæmis mun það draga úr niður í miðbæ eða fjarlægja ákveðna áhættu.
Afturköllunarpróf eru miklu mikilvægari en afhendingarprófun kóða. Nauðsynlegt er að ganga úr skugga um að vegna afturköllunarinnar muni kerfið fara aftur í upprunalegt ástand og staðfesta það með prófunum.
Allt sem hægt er að gera sjálfvirkt ætti að vera sjálfvirkt. Allt sem ekki er hægt að gera sjálfvirkt ætti að skrifa fyrirfram á svindlblað.
Skráðu árangursviðmiðið. Hvaða virkni ætti að vera tiltæk og á hvaða tíma? Ef þetta gerist ekki skaltu keyra afturköllunaráætlun.
Og síðast en ekki síst - fólk. Allir ættu að vera meðvitaðir um hvað þeir eru að gera, hvers vegna og hvað veltur á aðgerðum þeirra í útfærsluferlinu.

Og í einni setningu, með góðri skipulagningu og útfærslu geturðu útfært allt sem þú vilt án þess að það hafi afleiðingar fyrir sölu. Jafnvel eitthvað sem mun hafa áhrif á alla þjónustu þína í framleiðslu.

Heimild: www.habr.com

Frumsaga sem hafði áhrif á allt