Til að koma nýrri verkefnaútgáfu í framleiðslu þarf vandlega jafnvægi á milli dreifingarhraða og áreiðanleika lausna. Slök gildi hraðar endurtekningar, stuttar endurgjöfarlotur og skjót viðbrögð við beiðnum notenda. Að auki hefur fyrirtækið hundruð forritara sem leggja sig fram um að vera eins afkastamikill og mögulegt er.
Höfundar efnisins, sem við birtum þýðinguna á í dag, segja að fyrirtæki sem leitast við að fylgja slíkum gildum og á sama tíma stækkar verði stöðugt að bæta verkefnadreifingarkerfi sitt. Fyrirtækið þarf að fjárfesta í gagnsæi og áreiðanleika verkferla, gera þetta til að tryggja að þessir ferlar samsvari umfangi verkefnisins. Hér verður fjallað um verkflæði sem hafa þróast í Slack og um nokkrar ákvarðanir sem leiddu til þess að fyrirtækið notaði verkefnadreifingarkerfið sem er til í dag.
Hvernig verkefnadreifingarferli virka í dag
Sérhver PR (pull request) í Slack verður að vera háð kóða endurskoðun og verður að standast öll próf með góðum árangri. Aðeins eftir að þessi skilyrði eru uppfyllt getur forritarinn sameinað kóðann sinn í aðalgrein verkefnisins. Hins vegar er þessi kóði aðeins notaður á vinnutíma, Norður-Ameríkutíma. Þar af leiðandi, vegna þess að starfsmenn okkar eru á vinnustöðum sínum, erum við fullbúin til að leysa óvænt vandamál.
Á hverjum degi gerum við um 12 fyrirhugaðar sendingar. Við hverja uppsetningu er forritarinn sem er tilnefndur sem dreifingarstjóri ábyrgur fyrir því að koma nýju smíðinni í framleiðslu. Þetta er margra þrepa ferli sem tryggir að samsetningin komi vel í framleiðslu. Þökk sé þessari nálgun getum við greint villur áður en þær hafa áhrif á alla notendur okkar. Ef það eru of margar villur, er hægt að snúa uppsetningu samstæðunnar til baka. Ef tiltekið vandamál uppgötvast eftir útgáfu er auðvelt að losa um lagfæringu fyrir það.
Viðmót Checkpoint kerfisins, sem er notað í Slack til að dreifa verkefnum
Líta má á ferlið við að setja nýja útgáfu í framleiðslu sem samanstanda af fjórum skrefum.
▍1. Að búa til útgáfugrein
Hver útgáfa byrjar með nýrri útgáfugrein, punktur í Git sögunni okkar. Þetta gerir þér kleift að tengja merki til útgáfunnar og býður upp á stað þar sem þú getur gert lifandi lagfæringar á villum sem finnast í því ferli að undirbúa útgáfuna fyrir útgáfu til framleiðslu.
▍2. Dreifing í sviðsetningarumhverfi
Næsta skref er að dreifa samsetningunni á sviðsetningarþjónum og keyra sjálfvirkt próf fyrir heildarframmistöðu verkefnisins (reykpróf). Sviðsumhverfið er framleiðsluumhverfi sem tekur ekki á móti utanaðkomandi umferð. Í þessu umhverfi framkvæmum við viðbótarhandvirkar prófanir. Þetta veitir okkur aukið traust á því að breytt verkefni virki rétt. Sjálfvirk próf ein og sér eru ekki nóg til að veita þetta sjálfstraust.
▍3. Dreifing í hundafóður og kanaríumhverfi
Dreifing í framleiðslu byrjar með hundafóðursumhverfi, táknað með hópi gestgjafa sem þjóna innri Slack vinnusvæðum okkar. Þar sem við erum mjög virkir Slack notendur, þá hjálpaði þessi nálgun okkur að ná mörgum villum snemma í uppsetningunni. Eftir að við höfum gengið úr skugga um að grunnvirkni kerfisins sé ekki rofin, er samsetningin sett í kanaríumhverfið. Það táknar kerfi sem standa fyrir um það bil 2% af framleiðsluumferð.
▍4. Smám saman sleppt til framleiðslu
Ef vöktunarvísar fyrir nýju útgáfuna reynast stöðugir og ef við höfum ekki fengið neinar kvartanir eftir að verkefnið hefur verið dreift í kanaríumhverfinu, höldum við áfram að flytja framleiðsluþjónana smám saman yfir í nýju útgáfuna. Dreifingarferlinu er skipt í eftirfarandi stig: 10%, 25%, 50%, 75% og 100%. Fyrir vikið getum við flutt framleiðsluumferð hægt og rólega yfir í nýju útgáfuna af kerfinu. Á sama tíma höfum við tíma til að kanna stöðuna ef einhver frávik koma í ljós.
▍Hvað ef eitthvað fer úrskeiðis við uppsetningu?
Það er alltaf áhætta að gera breytingar á kóða. En við ráðum við þetta þökk sé nærveru vel þjálfaðra „dreifingarleiðtoga“ sem stjórna ferlinu við að koma nýrri útgáfu í framleiðslu, fylgjast með eftirlitsvísum og samræma vinnu forritara sem gefa út kóða.
Ef eitthvað fer virkilega úrskeiðis reynum við að greina vandamálið eins fljótt og hægt er. Við rannsökum vandamálið, finnum PR sem veldur villunum, snúum því til baka, greinum það vandlega og búum til nýja byggingu. Að vísu fer vandamálið stundum óséð þar til verkefnið fer í framleiðslu. Í slíkum aðstæðum er mikilvægast að endurheimta þjónustuna. Þess vegna, áður en við byrjum að rannsaka vandamálið, snúum við strax aftur til fyrri vinnubyggingar.
Byggingareiningar dreifingarkerfis
Við skulum skoða tæknina sem liggur til grundvallar verkefnadreifingarkerfi okkar.
▍Fljótleg dreifing
Verkflæðið sem lýst er hér að ofan kann að virðast, eftir á að hyggja, nokkuð augljóst. En dreifingarkerfið okkar varð ekki svona strax.
Þegar fyrirtækið var miklu minna gat allt forritið okkar keyrt á 10 Amazon EC2 tilvikum. Að dreifa verkefninu í þessum aðstæðum þýddi að nota rsync til að samstilla alla netþjóna fljótt. Áður var nýr kóða aðeins einu skrefi frá framleiðslu, táknað með sviðsetningarumhverfi. Samsetningar voru búnar til og prófaðar í slíku umhverfi og fóru síðan beint í framleiðslu. Það var mjög auðvelt að skilja slíkt kerfi; það gerði öllum forriturum kleift að nota kóðann sem hann hafði skrifað hvenær sem var.
En eftir því sem viðskiptavinum okkar fjölgaði, jókst umfang þeirra innviða sem þarf til að styðja við verkefnið. Fljótlega, miðað við stöðugan vöxt kerfisins, var dreifingarlíkanið okkar, byggt á því að ýta nýjum kóða á netþjónana, ekki lengur vinnu sinni. Það að bæta við hverjum nýjum netþjóni þýddi nefnilega að auka tímann sem þarf til að ljúka uppsetningunni. Jafnvel aðferðir sem byggjast á samhliða notkun rsync hafa ákveðnar takmarkanir.
Við enduðum á því að leysa þetta vandamál með því að fara yfir í algjörlega samhliða dreifingarkerfi, sem var hannað öðruvísi en gamla kerfið. Núna sendum við nefnilega ekki kóða til netþjónanna með samstillingarskriftu. Nú hlóð hver netþjónn sjálfstætt niður nýju samsetninguna, vitandi að það þyrfti að gera það með því að fylgjast með breytingu á Consul lyklinum. Netþjónarnir hlóðu kóðann samhliða. Þetta gerði okkur kleift að viðhalda miklum hraða dreifingar, jafnvel í umhverfi með stöðugum vexti kerfisins.
1. Framleiðsluþjónar fylgjast með Consul lyklinum. 2. Lykilbreytingarnar, þetta segir netþjónunum að þeir þurfi að byrja að hlaða niður nýjum kóða. 3. Netþjónar hlaða niður tarball skrám með forritakóða
▍Atómvæðing
Önnur lausn sem hjálpaði okkur að ná fjölþrepa dreifingarkerfi var kjarnorkuuppsetning.
Áður en frumeindauppsetningar eru notaðar gæti hver uppsetning leitt til fjölda villuboða. Staðreyndin er sú að ferlið við að afrita nýjar skrár á framleiðsluþjóna var ekki atómbundið. Þetta leiddi af sér stuttan tíma þar sem kóðinn sem kallaði nýjar aðgerðir var tiltækur áður en aðgerðirnar sjálfar voru tiltækar. Þegar slíkur kóði var kallaður leiddi það til þess að innri villum var skilað. Þetta birtist í misheppnuðum API beiðnum og brotnum vefsíðum.
Teymið sem vann að þessu vandamáli leysti það með því að kynna hugtakið „heitt“ og „kaldt“ möppur. Kóðinn í heitu möppunni er ábyrgur fyrir vinnslu framleiðsluumferðar. Og í „köldum“ möppum er aðeins verið að undirbúa kóðann til notkunar á meðan kerfið er í gangi. Meðan á uppsetningu stendur er nýr kóði afritaður í ónotaða köldu möppu. Síðan, þegar engin virk ferli eru á þjóninum, er tafarlaust skipt um skráarsafn.
1. Að pakka forritskóðanum niður í „kalda“ möppu. 2. Skipt er um kerfið í „kalda“ möppu, sem verður „heit“ (atómaðgerð)
Niðurstöður: breyting á áherslum í áreiðanleika
Árið 2018 stækkaði verkefnið í þann mælikvarða að mjög hröð dreifing fór að skaða stöðugleika vörunnar. Við vorum með mjög háþróað dreifingarkerfi sem við fjárfestum mikinn tíma og fyrirhöfn í. Allt sem við þurftum að gera var að endurbyggja og bæta dreifingarferli okkar. Við höfum vaxið í nokkuð stórt fyrirtæki þar sem þróunin hefur verið notuð um allan heim til að skipuleggja óslitin samskipti og leysa mikilvæg vandamál. Þess vegna varð áreiðanleiki í brennidepli athygli okkar.
Við þurftum að gera ferlið við að dreifa nýjum Slack útgáfum öruggara. Þessi þörf leiddi til þess að við bættum dreifingarkerfi okkar. Reyndar ræddum við þetta bætta kerfi hér að ofan. Í djúpum kerfisins höldum við áfram að nota hraðvirka og frumeindauppsetningartækni. Leiðin til uppsetningar hefur breyst. Nýja kerfið okkar er hannað til að dreifa nýjum kóða smám saman á mismunandi stigum, í mismunandi umhverfi. Við notum nú fullkomnari stuðningsverkfæri og kerfiseftirlitstæki en áður. Þetta gefur okkur möguleika á að ná og laga villur löngu áður en þær eiga möguleika á að ná til endanotandans.
En við ætlum ekki að hætta þar. Við erum stöðugt að bæta þetta kerfi með því að nota fullkomnari hjálpartæki og verkfæri til sjálfvirkni.
Kæru lesendur! Hvernig virkar ferlið við að dreifa nýjum verkefnaútgáfum þar sem þú vinnur?
Heimild: www.habr.com