poolt 12f-2
Aprilli lõpus, kui White Walkers piiras Winterfelli, juhtus meiega midagi huvitavamat: tegime ebatavalise rulli. Põhimõtteliselt juurutame pidevalt uusi funktsioone tootmisse (nagu kõik teised). Kuid see oli teistsugune. Selle ulatus oli selline, et kõik võimalikud vead, mida võiksime teha, mõjutasid kõiki meie teenuseid ja kasutajaid. Selle tulemusena rullutasime kõik välja plaanipäraselt, kavandatud ja väljakuulutatud seisakuperioodi jooksul, ilma et see oleks müügile kaasa toonud. Artikkel räägib sellest, kuidas me selle saavutasime ja kuidas igaüks saab seda kodus korrata.
Ma ei kirjelda nüüd meie tehtud arhitektuurilisi ja tehnilisi otsuseid ega räägi, kuidas see kõik töötab. Need on pigem märkmed marginaalide kohta selle kohta, kuidas toimus üks raskemaid levitamist, mida ma jälgisin ja millega olin otseselt seotud. Ma ei pretendeeri täielikkusele ega tehnilistele üksikasjadele, võib-olla ilmuvad need mõnes teises artiklis.
Taust + mis funktsioon see on?
Ehitame pilveplatvormi (MCS), kus töötan tehnilise direktorina. Ja nüüd on aeg lisada meie platvormile IAM (Identity and Access Management), mis pakub kõigi kasutajakontode, kasutajate, paroolide, rollide, teenuste ja muu ühtset haldust. Miks seda pilves vaja on, on ilmselge küsimus: kogu kasutajateave on sellesse salvestatud.
Tavaliselt hakatakse selliseid asju ehitama mis tahes projekti alguses. Kuid ajalooliselt on asjad MCS-is olnud veidi erinevad. MCS ehitati kahes osas:
- Openstack oma Keystone'i autoriseerimismooduliga,
- Hotbox (S3 salvestusruum), mis põhineb Mail.ru pilveprojektil,
mille ümber tekkisid siis uued teenused.
Põhimõtteliselt olid need kaks erinevat tüüpi volitused. Lisaks kasutasime mõningaid eraldi Mail.ru arendusi, näiteks üldist Mail.ru paroolisalvestust, aga ka ise kirjutatud openid-pistikut, tänu millele pakuti Horisondi paneelil SSO-d (otspunkti autoriseerimine). virtuaalsetest masinatest (OpenStacki kasutajaliides).
IAM-i tegemine meie jaoks tähendas selle ühendamist ühtsesse süsteemi, mis on täielikult meie oma. Samas ei kaota me oma teekonnal ühtegi funktsionaalsust, vaid loome aluse tulevikule, mis võimaldab seda läbipaistvalt ilma ümbertegemiseta viimistleda ja funktsionaalsuse osas skaleerida. Ka alguses oli kasutajatel eeskujuks juurdepääs teenustele (keskne RBAC, rollipõhine juurdepääsukontroll) ja veel mõned pisiasjad.
Ülesanne osutus mittetriviaalseks: python ja perl, mitu taustaprogrammi, iseseisvalt kirjutatud teenused, mitmed arendusmeeskonnad ja administraatorid. Ja mis kõige tähtsam, lahingutootmissüsteemis on tuhandeid reaalajas kasutajaid. Kõik see tuli kirja panna ja mis kõige tähtsam – ohvriteta välja veeretada.
Mida me välja paneme?
Väga jämedalt öeldes valmistasime umbes 4 kuuga ette järgmise:
- Lõime mitu uut deemonit, mis koondasid funktsioone, mis varem töötasid infrastruktuuri erinevates osades. Ülejäänud teenustele määrati nende deemonite näol uus taustaprogramm.
- Kirjutasime oma keskse paroolide ja võtmete salvestusruumi, mis on saadaval kõigi meie teenuste jaoks ja mida saab vastavalt vajadusele vabalt muuta.
- Kirjutasime Keystone'i jaoks nullist 4 uut taustaprogrammi (kasutajad, projektid, rollid, rollide määramised), mis tegelikult asendasid selle andmebaasi ja toimivad nüüd meie kasutajate paroolide ühtse hoidlana.
- Õpetasime kõiki oma Openstacki teenuseid kasutama oma poliitikaid kolmanda osapoole poliitikateenuses, selle asemel, et neid eeskirju igast serverist kohapeal lugeda (jah, nii töötab Openstack vaikimisi!)
Selline suur ümbertöötamine nõuab suuri, keerulisi ja, mis kõige tähtsam, sünkroonseid muudatusi mitmes süsteemis, mille on kirjutanud erinevad arendusmeeskonnad. Pärast kokkupanemist peaks kogu süsteem töötama.
Kuidas selliseid muudatusi ellu viia ja mitte rikkuda? Kõigepealt otsustasime vaadata veidi tulevikku.
Levitamise strateegia
- Toodet oleks võimalik rullida mitmes etapis, kuid see pikendaks arendusaega kolm korda. Lisaks oleks meil mõnda aega andmebaasides andmete täielik desünkroniseerimine. Peaksite ise kirjutama sünkroonimistööriistad ja elama pikka aega mitme andmesalvega. Ja see tekitab palju erinevaid riske.
- Kõik, mida sai kasutaja jaoks läbipaistvalt ette valmistada, tehti ette. Kulus 2 kuud.
- Lubasime endale mitu tundi seisakuid – ainult kasutajatoiminguteks ressursside loomiseks ja muutmiseks.
- Kõigi juba loodud ressursside tööks oli seisak vastuvõetamatu. Plaanisime, et juurutamise ajal peaksid ressursid töötama ilma seisakuteta ja kliente mõjutamata.
- Et vähendada mõju klientidele, kui midagi läheb valesti, otsustasime käivitada pühapäeva õhtul. Vähem kliente haldab virtuaalmasinaid öösel.
- Hoiatasime kõiki oma kliente, et kasutuselevõtuks valitud perioodil ei ole teenusehaldus saadaval.
Kõrvalekaldumine: mis on levitamine?
<ettevaatust, filosoofia>
Iga IT-spetsialist oskab lihtsalt vastata, mis on juurutamine. Installite CI/CD ja kõik tarnitakse automaatselt poodi. 🙂
See on muidugi tõsi. Kuid raskus seisneb selles, et tänapäevaste koodiedastuse automatiseerimistööriistade puhul kaob arusaam levitamisest endast. Kuidas unustad kaasaegset transporti vaadates ratta leiutamise eepilisuse. Kõik on nii automatiseeritud, et levitamine toimub sageli tervikpilti mõistmata.
Ja kogu pilt on selline. Levitamine koosneb neljast peamisest aspektist.
- Koodi kohaletoimetamine, sh andmete muutmine. Näiteks nende migratsioonid.
- Koodi tagasivõtmine on võimalus tagasi pöörduda, kui midagi läheb valesti. Näiteks varukoopiate loomise kaudu.
- Iga levitamise/tagasi toimingu aeg. Peate mõistma kahe esimese punkti mis tahes toimingu ajastust.
- Mõjutatud funktsionaalsus. On vaja hinnata nii eeldatavaid positiivseid kui ka võimalikke negatiivseid mõjusid.
Kõiki neid aspekte tuleb edukaks kasutuselevõtuks arvesse võtta. Tavaliselt hinnatakse ainult esimest või parimal juhul teist punkti ja seejärel loetakse levitamine edukaks. Kolmas ja neljas on aga veelgi olulisemad. Millisele kasutajale meeldiks, kui levitamine kestaks minuti asemel 3 tundi? Või kui levitamise ajal saab midagi ebavajalikku? Või toob ühe teenuse seisak kaasa ettearvamatud tagajärjed?
Seadus 1..n, vabastamise ettevalmistamine
Algul mõtlesin lühidalt kirjeldada meie kohtumisi: kogu meeskond, selle osad, kuhjad arutelud kohvikupunktides, vaidlused, testid, ajurünnakud. Siis mõtlesin, et see poleks vajalik. Neli kuud arendust koosneb alati sellest, eriti kui te ei kirjuta midagi, mida saaks pidevalt edastada, vaid üks suur funktsioon reaalajas süsteemi jaoks. Mis mõjutab kõiki teenuseid, kuid kasutajate jaoks ei tohiks midagi muutuda, välja arvatud "üks nupp veebiliideses".
Meie arusaam sellest, kuidas levitada, muutus iga uue kohtumise järel ja üsna oluliselt. Näiteks kavatsesime värskendada kogu oma arveldusandmebaasi. Kuid me arvutasime aega ja mõistsime, et seda on võimatu teha mõistliku levitamisaja jooksul. Meil kulus arveldusandmebaasi purustamiseks ja arhiveerimiseks peaaegu nädal. Ja kui loodetud rullumiskiirus ikka ei rahuldanud, tellisime täiendava võimsama riistvara, kus kogu baas oli tiritud. Asi pole selles, et me ei oleks tahtnud seda varem teha, kuid praegune vajadus kasutusele võtta ei jätnud meil valikuvõimalusi.
Kui ühel meist tekkis kahtlus, et kasutuselevõtt võib mõjutada meie virtuaalmasinate saadavust, kulutasime nädala katsetele, katsetele, koodianalüüsile ja saime selge arusaama, et meie tootmises seda ei juhtu, ja isegi kõige kahtlevamad inimesed nõustusid sellega. sellega.
Vahepeal viisid tehnilise toe kutid läbi iseseisvaid katseid, et kirjutada klientidele juhiseid ühendusmeetodite kohta, mis pidid pärast kasutuselevõttu muutuma. Nad töötasid kasutaja UX-i kallal, koostasid juhiseid ja andsid personaalseid konsultatsioone.
Automatiseerisime kõik võimalikud levitamistoimingud. Kõik toimingud olid skriptitud, isegi kõige lihtsamad, ja pidevalt tehti teste. Nad vaidlesid selle üle, milline on parim viis teenuse väljalülitamiseks - jätta deemon välja või blokeerida juurdepääs teenusele tulemüüriga. Koostasime iga levitamisetapi jaoks meeskondade kontrollnimekirja ja värskendasime seda pidevalt. Koostasime ja uuendasime pidevalt Gantti diagrammi kõigi levitamistööde jaoks koos ajastustega.
Ja nii…
Viimane vaatus enne väljalaskmist
...on aeg välja käia.
Nagu öeldakse, kunstiteost ei saa valmis teha, vaid selle kallal töö lõpetada. Peate pingutama oma tahtega, mõistes, et te ei leia kõike, kuid uskudes, et olete teinud kõik mõistlikud eeldused, ette näinud kõik võimalikud juhtumid, sulgenud kõik kriitilised vead ja kõik osalejad tegid kõik, mida suutsid. Mida rohkem koodi välja lasta, seda keerulisem on end selles veenda (pealegi saavad kõik aru, et kõike on võimatu ette näha).
Otsustasime, et oleme valmis kasutusele võtma, kui oleme veendunud, et oleme teinud kõik endast oleneva, et katta kõik kasutajad ootamatute mõjude ja seisakutega seotud riskid. See tähendab, et kõik võib valesti minna, välja arvatud:
- Mõjutada (meile püha, kõige kallim) kasutaja infrastruktuuri,
- Funktsionaalsus: meie teenuse kasutamine pärast levitamist peaks olema sama, mis enne seda.
Välja veeremine
Kaks rulli, 8 ei sega
Võtame kõigi kasutajate taotluste puhul seisakuid 7 tundi. Praegu on meil nii levitamis- kui ka tagasipööramisplaan.
- Käivitamine ise võtab aega umbes 3 tundi.
- 2 tundi testimiseks.
- 2 tundi – reserv muudatuste võimalikuks tühistamiseks.
Iga toimingu kohta on koostatud Gantti diagramm, kui kaua see aega võtab, mis toimub järjestikku, mida tehakse paralleelselt.
Tükk levitatavast Gantti diagrammist, üks varasematest versioonidest (ilma paralleelse täitmiseta). Kõige väärtuslikum sünkroonimistööriist
Kõigil osalejatel määratakse kindlaks nende roll juurutamisel, milliseid ülesandeid nad teevad ja mille eest nad vastutavad. Püüame viia iga etapi automaatsusse, veeretada selle välja, veeretada tagasi, koguda tagasisidet ja uuesti rullida.
Sündmuste kroonika
Niisiis tuli pühapäeval, 15. aprillil kell 29 tööle 10 inimest. Lisaks võtmeosalistele tulid mõned lihtsalt meeskonda toetama, mille eest suur tänu neile.
Samuti tasub mainida, et meie peamine testija on puhkusel. Ilma testimiseta on võimatu kasutusele võtta, uurime võimalusi. Kolleeg on nõus meid puhkuselt proovile panema, mille eest pälvib ta tohutu tänu kogu meeskonnalt.
00:00. Peatus
Peatame kasutajasoovid, riputame üles sildi tehniline töö. Jälgimine karjub, aga kõik on normaalne. Kontrollime, et midagi ei kukkunud peale selle, mis kukkuma pidi. Ja me alustame tööd migratsiooniga.
Kõigil on punkt-punktilt väljaprinditud rullimisplaan, kõik teavad, kes mida ja mis hetkel teeb. Pärast iga toimingut kontrollime aegu, et me neid ei ületaks, ja kõik läheb plaanipäraselt. Need, kes praeguses etapis juurutamises otseselt ei osale, valmistuvad võrgumänguasja (Xonotic, tüüp 3 quacks) turuletoomisega, et kolleege mitte häirida. 🙂
02:00. Veeres välja
Meeldiv üllatus – andmebaaside ja migratsiooniskriptide optimeerimise tõttu lõpetame juurutamise tund varem. Üldine hüüatus: "Välja veeretatud!" Kõik uued funktsioonid on tootmises, kuid seni näeme neid liideses ainult meie. Kõik lähevad testimisrežiimi, sorteerivad nad rühmadesse ja hakkavad nägema, mis lõpuks juhtus.
See ei tulnud väga hästi välja, saame sellest aru 10 minuti pärast, kui meeskonnaliikmete projektides pole midagi ühendatud ega tööta. Kiire sünkroonimine, räägime oma probleemidest, seame prioriteedid, jaguneme meeskondadeks ja alustame silumist.
02:30. Kaks suurt probleemi vs neli silma
Leiame kaks suurt probleemi. Saime aru, et kliendid ei näe mõnda ühendatud teenust ja probleemid tekivad partnerkontodega. Mõlemad on tingitud ebatäiuslikest migratsiooniskriptidest mõne servajuhtumi puhul. Peame selle kohe parandama.
Kirjutame päringuid, mis seda salvestavad, vähemalt 4 silmaga. Testime neid eeltootmise ajal, veendumaks, et need töötavad ega riku midagi. Võite edasi veereda. Samal ajal viime läbi oma regulaarset integratsioonitesti, mis toob esile veel mõned probleemid. Kõik need on väikesed, aga vajavad ka remonti.
03:00. -2 probleemi +2 probleemi
Lahendatud on kaks eelmist suurt probleemi ja peaaegu kõik väiksemad ka. Kõik need, kes pole parandusega hõivatud, töötavad aktiivselt oma kontodel ja annavad teada, mida nad leidsid. Me prioritiseerime, jagame meeskondade vahel ja jätame mittekriitilised asjad hommikuks.
Korraldame testid uuesti ja nad avastavad kaks uut suurt probleemi. Kõik teenusepoliitikad ei jõudnud õigesti kohale, mistõttu mõned kasutajataotlused ei läbi volitust. Lisaks uus probleem partnerkontodega. Kiirustame vaatama.
03:20. Hädaolukorra sünkroonimine
Üks uus probleem parandatud. Teiseks korraldame hädaolukorra sünkroonimise. Saame aru, mis toimub: eelmine parandus parandas ühe probleemi, kuid lõi teise. Teeme pausi, et välja mõelda, kuidas seda õigesti ja tagajärgedeta teha.
03:30. Kuus silma
Saame aru, milline peaks olema baasi lõppseisund, et kõikidel partneritel kõik hästi läheks. Kirjutame 6 silmaga päringu, rullime eeltootmises välja, testime, rullime tootmisse.
04:00. Kõik töötab
Kõik testid läbitud, kriitilisi probleeme pole näha. Aeg-ajalt ei tööta meeskonnas kellegi jaoks midagi, reageerime kiiresti. Enamasti on alarm vale. Kuid mõnikord ei jõua midagi või eraldi leht ei tööta. Istume, parandame, parandame, parandame. Eraldi meeskond on käivitamas viimast suurt funktsiooni – arveldamist.
04:30. Tagasiteed pole
Lähenemas on tagasitulekupunkt ehk aeg, mil tagasi veerema hakates me ei täida meile antud seisakuid. Probleeme on arveldamisega, mis teab ja fikseerib kõike, kuid keeldub kangekaelselt klientidelt raha maha kandmast. Üksikutel lehtedel, toimingutel ja olekutel on mitmeid vigu. Põhifunktsionaalsus töötab, kõik testid läbivad edukalt. Otsustame, et levitamine on toimunud, tagasi me ei keri.
06:00. Avatud kõigile kasutajaliideses
Vead parandatud. Mõned, mis kasutajaid ei köida, jäetakse hilisemaks. Avame liidese kõigile. Jätkame tööd arveldamisega, ootame kasutajate tagasisidet ja jälgime tulemusi.
07:00. Probleemid API laadimisega
Selgub, et planeerisime oma API koormust veidi valesti ja testisime seda koormust, mis ei suutnud probleemi tuvastada. Selle tulemusena ebaõnnestub ≈5% taotlustest. Mobiliseerugem ja otsime põhjust.
Arveldamine on kangekaelne ega taha ka toimida. Otsustame selle hilisemaks lükata, et muudatused rahulikult läbi viia. See tähendab, et kõik ressursid on sinna kogunenud, kuid klientidelt mahakandmised ei lähe läbi. Muidugi on see probleem, kuid võrreldes üldise levikuga tundub see ebaoluline.
08:00. Parandage API
Veeretasime koormale paranduse välja, tõrked kadusid. Hakkame koju minema.
10:00. Kõik
Kõik on fikseeritud. Jälgimisel on vaikne ja klientide juures läheb meeskond tasapisi magama. Arveldus jääb alles, homme taastame.
Seejärel toimus päeva jooksul levitamine, mis parandas mõne meie kliendi logisid, teatisi, tagastuskoode ja kohandusi.
Niisiis, levitamine oli edukas! See võiks muidugi olla parem, kuid tegime järeldused selle kohta, millest meie jaoks täiuslikkuse saavutamiseks ei piisanud.
Kogusummas
2-kuulise aktiivse juurutamise ettevalmistuse jooksul sai täidetud 43 ülesannet, mis kestsid paarist tunnist mitme päevani.
Avaldamise ajal:
- uued ja muudetud deemonid - 5 tükki, asendades 2 monoliiti;
- muudatused andmebaasides - mõjutatud on kõik meie 6 kasutajaandmetega andmebaasi, kolmest vanast andmebaasist on tehtud allalaadimisi ühte uude;
- täielikult ümber kujundatud esiosa;
- allalaaditud koodi kogus - 33 tuhat rida uut koodi, ≈ 3 tuhat koodirida testides, ≈ 5 tuhat rida migratsioonikoodi;
- kõik andmed on terved, ühegi kliendi virtuaalmasin pole kahjustatud. 🙂
Hea levitamise head tavad
Nad juhatasid meid selles keerulises olukorras. Kuid üldiselt on kasulik neid iga levitamise ajal järgida. Kuid mida keerulisem on levitamine, seda suuremat rolli nad mängivad.
- Esimene asi, mida peate tegema, on mõista, kuidas levitamine võib kasutajaid mõjutada või mõjutab. Kas seisakuid tuleb? Kui jah, siis milline on seisak? Kuidas see kasutajaid mõjutab? Millised on võimalikud parimad ja halvimad stsenaariumid? Ja katta riskid.
- Planeerige kõike. Igas etapis peate mõistma levitamise kõiki aspekte.
- koodi kohaletoimetamine;
- koodi tagasipööramine;
- iga toimingu aeg;
- mõjutatud funktsionaalsus.
- Mängige läbi stsenaariumid, kuni kõik levitamise etapid ja ka nende riskid muutuvad ilmseks. Kui teil on kahtlusi, võite teha pausi ja uurida küsitavat etappi eraldi.
- Iga etappi saab ja tuleks täiustada, kui see aitab meie kasutajaid. Näiteks vähendab see seisakuid või eemaldab mõned riskid.
- Tagasipööramistestimine on palju olulisem kui koodi edastamise testimine. Tuleb kontrollida, et tagasipööramise tulemusena naaseb süsteem algsesse olekusse, ning kinnitada seda testidega.
- Kõik, mida saab automatiseerida, tuleks automatiseerida. Kõik, mida ei saa automatiseerida, tuleks eelnevalt petulehele kirja panna.
- Salvestage edukriteerium. Millised funktsioonid peaksid saadaval olema ja mis ajal? Kui seda ei juhtu, käivitage tagasipööramisplaan.
- Ja mis kõige tähtsam – inimesed. Igaüks peaks olema teadlik sellest, mida ta teeb, miks ja mis sõltub tema tegevusest juurutamisprotsessis.
Ja ühe lausega, hea planeerimise ja läbitöötamisega saate kõike, mida soovite, ilma müügi tagajärgedeta. Isegi midagi, mis mõjutab kõiki teie teenuseid tootmises.
Allikas: www.habr.com