12f-2
Huhtikuun lopussa, kun White Walkers piiritti Winterfellia, meille tapahtui jotain mielenkiintoisempaa: teimme epätavallisen kierroksen. Periaatteessa otamme jatkuvasti käyttöön uusia ominaisuuksia tuotantoon (kuten kaikki muutkin). Mutta tämä oli erilainen. Sen mittakaava oli sellainen, että mahdolliset virheet, joita voimme tehdä, vaikuttavat kaikkiin palveluihimme ja käyttäjiimme. Tämän seurauksena toteutimme kaiken suunnitelmien mukaisesti suunnitellussa ja ilmoitetussa seisokkijaksossa ilman myyntiin kohdistuvia seurauksia. Artikkeli kertoo, kuinka saavutimme tämän ja kuinka kuka tahansa voi toistaa sen kotona.
En nyt kuvaile tekemiämme arkkitehtonisia ja teknisiä päätöksiä tai kerro kuinka kaikki toimii. Nämä ovat pikemminkin marginaaleissa olevia muistiinpanoja siitä, kuinka yksi vaikeimmista julkaisuista tapahtui, jonka olen havainnut ja jossa olin suoraan mukana. En vaadi täydellisyyttä tai teknisiä yksityiskohtia; ehkä ne ilmestyvät toisessa artikkelissa.
Tausta + millainen toiminto tämä on?
Rakennamme pilvialustaa (MCS), jossa työskentelen teknisenä johtajana. Ja nyt on aika lisätä alustaamme IAM (Identity and Access Management), joka tarjoaa kaikkien käyttäjätilien, käyttäjien, salasanojen, roolien, palveluiden ja muiden yhtenäisen hallinnan. Miksi sitä tarvitaan pilvessä, on ilmeinen kysymys: kaikki käyttäjätiedot on tallennettu siihen.
Yleensä tällaisia asioita aletaan rakentaa projektin alussa. Mutta historiallisesti asiat ovat olleet hieman erilaisia MCS:ssä. MCS rakennettiin kahdessa osassa:
- Openstack omalla Keystone-valtuutusmoduulillaan,
- Hotbox (S3-tallennustila), joka perustuu Mail.ru Cloud -projektiin,
jonka ympärille ilmestyi uusia palveluita.
Pohjimmiltaan nämä olivat kaksi erilaista valtuutusta. Lisäksi käytimme joitain erillisiä Mail.ru-kehityksiä, esimerkiksi yleistä Mail.ru-salasanojen tallennustilaa sekä itse kirjoitettua openid-liitintä, jonka ansiosta SSO (päästä päähän -valtuutus) tarjottiin Horizon-paneelissa virtuaalikoneita (natiivi OpenStack-käyttöliittymä).
IAM:n tekeminen meille merkitsi kaiken yhdistämistä yhdeksi järjestelmäksi, täysin omaksemme. Samalla emme menetä mitään toiminnallisuutta matkan varrella, vaan luomme pohjan tulevaisuudelle, jonka avulla voimme jalostaa sitä läpinäkyvästi ilman refaktorointia ja skaalata sitä toiminnallisesti. Myös alussa käyttäjillä oli roolimalli palveluihin pääsystä (keskitetty RBAC, roolipohjainen kulunvalvonta) ja muutakin pientä.
Tehtävä osoittautui ei-triviaaliksi: python ja perl, useita taustaohjelmia, itsenäisesti kirjoitettuja palveluita, useita kehitystiimejä ja ylläpitäjiä. Ja mikä tärkeintä, taistelutuotantojärjestelmässä on tuhansia live-käyttäjiä. Kaikki tämä piti kirjoittaa ja, mikä tärkeintä, levittää ilman uhreja.
Mitä otamme käyttöön?
Hyvin karkeasti sanottuna valmistimme noin 4 kuukaudessa seuraavan:
- Loimme useita uusia demoneita, jotka yhdistävät toimintoja, jotka aiemmin toimivat infrastruktuurin eri osissa. Muille palveluille määrättiin uusi taustajärjestelmä näiden demonien muodossa.
- Kirjoitimme kaikille palveluillemme oman keskusvarastomme salasanoille ja avaimille, joita voidaan vapaasti muokata tarpeen mukaan.
- Kirjoitimme 4 uutta taustaohjelmaa Keystonelle tyhjästä (käyttäjät, projektit, roolit, roolimääritykset), jotka itse asiassa korvasivat sen tietokannan ja toimii nyt yhtenä arkistona käyttäjien salasanoillemme.
- Opetimme kaikille Openstack-palveluillemme hakemaan käytäntöjä kolmannen osapuolen käytäntöpalvelusta sen sijaan, että lukisimme nämä käytännöt paikallisesti jokaiselta palvelimelta (kyllä, näin Openstack toimii oletuksena!)
Tällainen suuri uudistus vaatii suuria, monimutkaisia ja mikä tärkeintä, synkronisia muutoksia useisiin eri kehitystiimien kirjoittamiin järjestelmiin. Kokoonpanon jälkeen koko järjestelmän pitäisi toimia.
Kuinka toteuttaa tällaiset muutokset ja olla sotkematta niitä? Ensin päätimme katsoa hieman tulevaisuuteen.
Käyttöönottostrategia
- Tuote olisi mahdollista rullata useassa vaiheessa, mutta tämä lisäisi kehitysaikaa kolme kertaa. Lisäksi meillä olisi jonkin aikaa täydellinen tietojen synkronointi tietokannoissa. Sinun pitäisi kirjoittaa omat synkronointityökalusi ja elää useiden tietovarastojen kanssa pitkään. Ja tämä luo monenlaisia riskejä.
- Kaikki, mikä voitiin valmistaa läpinäkyvästi käyttäjälle, tehtiin etukäteen. Kesti 2 kuukautta.
- Sallimme itsellemme useita tunteja seisokkeja - vain käyttäjien resurssien luomista ja vaihtamista varten.
- Kaikkien jo luotujen resurssien toiminnan kannalta seisokkeja ei voida hyväksyä. Suunnittelimme, että käyttöönoton aikana resurssien tulisi toimia ilman seisokkeja ja vaikuttaa asiakkaisiin.
- Vähentääksemme vaikutusta asiakkaisiimme, jos jokin menee pieleen, päätimme ottaa käyttöön sunnuntai-iltana. Harvemmat asiakkaat hallitsevat virtuaalikoneita yöllä.
- Varoitimme kaikkia asiakkaitamme, että palvelunhallinta ei ole käytettävissä käyttöönotolle valitun ajanjakson aikana.
Poikkeama: mikä on käyttöönotto?
<varovaisuus, filosofia>
Jokainen IT-asiantuntija osaa helposti vastata, mitä käyttöönotto on. Asennat CI/CD:n ja kaikki toimitetaan automaattisesti kauppaan. 🙂
Tämä on tietysti totta. Mutta vaikeus on, että nykyaikaisilla koodintoimituksen automaatiotyökaluilla ymmärrys itse käyttöönotosta menetetään. Kuinka unohdat pyörän keksimisen eeppisuuden, kun katsot modernia liikennettä. Kaikki on niin automatisoitua, että käyttöönotto tapahtuu usein ymmärtämättä kokonaiskuvaa.
Ja koko kuva on tällainen. Käyttöönotto koostuu neljästä pääasiasta:
- Koodin toimitus mukaan lukien tietojen muuttaminen. Esimerkiksi heidän muuttonsa.
- Koodin palautus on kyky palata takaisin, jos jokin menee pieleen. Esimerkiksi luomalla varmuuskopioita.
- Kunkin käyttöönotto-/palautusoperaation aika. Sinun on ymmärrettävä kahden ensimmäisen pisteen toiminnan ajoitus.
- Vaikutettu toiminnallisuus. On tarpeen arvioida sekä odotetut myönteiset että mahdolliset negatiiviset vaikutukset.
Kaikki nämä näkökohdat on otettava huomioon onnistuneen käyttöönoton varmistamiseksi. Yleensä vain ensimmäinen tai parhaimmillaan toinen kohta arvioidaan, ja sitten käyttöönotto katsotaan onnistuneeksi. Mutta kolmas ja neljäs ovat vielä tärkeämpiä. Kuka käyttäjä haluaisi, jos käyttöönotto kestäisi 3 tuntia minuutin sijaan? Tai jos käyttöönoton aikana tapahtuu jotain tarpeetonta? Vai johtaako yhden palvelun seisokki arvaamattomiin seurauksiin?
Laki 1..n, vapautuksen valmistelu
Aluksi ajattelin kuvailla lyhyesti tapaamisiamme: koko tiimi, sen osat, kasa keskusteluja kahvipisteissä, väittelyjä, testejä, aivoriihiä. Sitten ajattelin, että se olisi tarpeetonta. Neljän kuukauden kehitystyö koostuu aina tästä, varsinkin kun et kirjoita jotain, joka voidaan toimittaa jatkuvasti, vaan yksi iso ominaisuus live-järjestelmälle. Tämä vaikuttaa kaikkiin palveluihin, mutta käyttäjille ei pitäisi muuttua minkään muun kuin "yhden painikkeen verkkokäyttöliittymässä".
Ymmärryksemme siitä, kuinka edetä, muuttui jokaisen uuden tapaamisen jälkeen, ja varsin merkittävästi. Aioimme esimerkiksi päivittää koko laskutustietokantamme. Mutta laskimme ajan ja huomasimme, että tätä oli mahdotonta tehdä kohtuullisessa käyttöönottoajassa. Meillä kului lähes ylimääräinen viikko laskutustietokannan sirpalointiin ja arkistointiin. Ja kun odotettu käyttöönottonopeus ei vieläkään ollut tyydyttävä, tilasimme lisää, tehokkaampia laitteita, joissa koko tukikohta vedettiin. Kyse ei ole siitä, ettemmekö olisi halunneet tehdä tätä aikaisemmin, mutta nykyinen tarve ottaa käyttöön ei jättänyt meille vaihtoehtoja.
Kun joku meistä epäili, että käyttöönotto voisi vaikuttaa virtuaalikoneiden saatavuuteen, käytimme viikon ajan testejä, kokeita, koodianalyysiä ja saimme selvän ymmärryksen, että tuota ei tapahdu tuotannossamme, ja epäilyttävätkin ihmiset olivat samaa mieltä. tämän kanssa.
Sillä välin teknisen tuen kaverit tekivät omia itsenäisiä kokeilujaan kirjoittaakseen asiakkaille ohjeita yhteysmenetelmistä, joiden piti muuttua käyttöönoton jälkeen. He työskentelivät käyttäjän UX:n parissa, laativat ohjeita ja antoivat henkilökohtaisia konsultaatioita.
Automatisoimme kaikki mahdolliset käyttöönottotoiminnot. Jokainen operaatio käsikirjoitettiin, jopa yksinkertaisimmat, ja testejä ajettiin jatkuvasti. He kiistelivät parhaasta tavasta sammuttaa palvelu - jättää daemon pois tai estää pääsy palveluun palomuurilla. Loimme tarkistuslistan ryhmistä jokaiselle käyttöönottovaiheelle ja päivitimme sitä jatkuvasti. Piirimme ja päivitimme jatkuvasti Gantt-kaavion kaikille käyttöönottotöille ajoituksineen.
Ja niin…
Viimeinen esitys ennen julkaisua
...on aika ottaa käyttöön.
Kuten sanotaan, taideteosta ei voi saada valmiiksi, se voi vain saada valmiiksi sen työskentelyn. Sinun on ponnisteltava tahdonvoimalla ymmärtäen, että et löydä kaikkea, mutta uskoen, että olet tehnyt kaikki järkevät oletukset, varautunut kaikkiin mahdollisiin tapauksiin, sulkenut kaikki kriittiset virheet ja kaikki osallistujat tekivät kaikkensa. Mitä enemmän koodia otat käyttöön, sitä vaikeampaa on vakuuttaa itsesi tästä (lisäksi kaikki ymmärtävät, että kaikkea on mahdotonta ennakoida).
Päätimme ottaa käyttöön, kun olimme vakuuttuneita siitä, että olimme tehneet kaikkemme kattaaksemme kaikki käyttäjillemme aiheutuvat riskit, jotka liittyvät odottamattomiin vaikutuksiin ja seisokkeihin. Eli kaikki voi mennä pieleen paitsi:
- Vaikuttaa (meille pyhä, arvokkain) käyttäjäinfrastruktuuriin,
- Toiminnallisuus: Palvelumme käytön tulee olla julkaisun jälkeen sama kuin ennen sitä.
Rullaamassa ulos
Kaksi rullaa, 8 ei häiritse
Otamme käyttökatkon kaikkien käyttäjien pyyntöjen osalta 7 tunnin ajan. Tällä hetkellä meillä on sekä käyttöönottosuunnitelma että palautussuunnitelma.
- Itse käyttöönotto kestää noin 3 tuntia.
- 2 tuntia testaukseen.
- 2 tuntia - varaa muutosten mahdolliselle palautukselle.
Jokaiselle toiminnolle on laadittu Gantt-kaavio, kuinka kauan se kestää, mitä tapahtuu peräkkäin, mitä tehdään rinnakkain.
Osa käyttöönotetusta Gantt-kaaviosta, yksi varhaisista versioista (ilman rinnakkaista suoritusta). Arvokkain synkronointityökalu
Kaikille osallistujille määritetään roolinsa käyttöönottoon, mitä tehtäviä he tekevät ja mistä he ovat vastuussa. Pyrimme saattamaan jokaisen vaiheen automaattiseksi, rullaamaan sen ulos, rullaamme takaisin, keräämme palautetta ja rullaamme sen uudelleen.
ҐҐЂѕѕ.. .Ё .є.
Sunnuntaina 15. klo 29 tuli siis töihin 10 henkilöä. Avainosallisten lisäksi osa tuli vain tukemaan joukkuetta, josta heille erityiskiitos.
On myös syytä mainita, että tärkein testaajamme on lomalla. On mahdotonta ottaa käyttöön ilman testausta, tutkimme vaihtoehtoja. Kollegani suostuu testaamaan meitä lomalta, mistä hän saa valtavat kiitokset koko tiimiltä.
00:00. Lopettaa
Lopetamme käyttäjien pyynnöt, ripustamme kyltin, jossa lukee tekninen työ. Valvonta huutaa, mutta kaikki on normaalia. Tarkistamme, ettei mitään muuta pudonnut kuin sen, minkä piti pudota. Ja aloitamme työt siirtolaisuuden parissa.
Jokaisella on tulostettu käyttöönottosuunnitelma kohta kohdalta, jokainen tietää kuka tekee mitä ja millä hetkellä. Jokaisen toimenpiteen jälkeen tarkistamme ajoitukset varmistaaksemme, ettemme ylitä niitä, ja kaikki menee suunnitelmien mukaan. Ne, jotka eivät osallistu suoraan käyttöönottoon nykyisessä vaiheessa, valmistautuvat lanseeraamalla verkkolelun (Xonotic, tyypin 3 quacks), jotta he eivät häiritse kollegoitaan. 🙂
02:00. Rullattu ulos
Miellyttävä yllätys - saamme julkaisun valmiiksi tuntia aikaisemmin tietokantojemme ja siirtokomentojemme optimoinnin vuoksi. Yleinen huuto "rullattu ulos!" Kaikki uudet toiminnot ovat tuotannossa, mutta toistaiseksi vain me näemme ne käyttöliittymässä. Kaikki siirtyvät testaustilaan, lajittelevat heidät ryhmiin ja alkavat nähdä, mitä lopulta tapahtui.
Se ei mennyt kovin hyvin, ymmärrämme tämän 10 minuutin kuluttua, kun tiimin jäsenten projekteissa ei ole mitään yhteyttä tai toimi. Nopea synkronointi, kerromme ongelmistamme, asetamme prioriteetteja, jaaudumme ryhmiin ja aloitamme virheenkorjauksen.
02:30. Kaksi suurta ongelmaa vastaan neljä silmää
Löydämme kaksi suurta ongelmaa. Ymmärsimme, että asiakkaat eivät näe kaikkia yhdistettyjä palveluita ja kumppanitilien kanssa tulee ongelmia. Molemmat johtuvat epätäydellisistä siirtoskripteistä joissakin reunatapauksissa. Meidän on korjattava se nyt.
Kirjoitamme kyselyitä, jotka tallentavat tämän, vähintään 4 silmällä. Testaamme niitä esituotannon aikana varmistaaksemme, että ne toimivat eivätkä riko mitään. Voit rullata eteenpäin. Samanaikaisesti suoritamme säännöllistä integraatiotestausta, joka paljastaa vielä muutamia ongelmia. Ne ovat kaikki pieniä, mutta ne on myös korjattava.
03:00. -2 ongelmaa +2 ongelmaa
Kaksi edellistä suurta ongelmaa on korjattu, ja myös lähes kaikki pienet ongelmat. Kaikki korjauksiin puuttuvat työskentelevät aktiivisesti tileillään ja raportoivat löytämänsä. Priorisoimme, jaamme ryhmien kesken ja jätämme ei-kriittiset tavarat aamuun.
Suoritamme testit uudelleen, ja he löytävät kaksi uutta suurta ongelmaa. Kaikki palvelukäytännöt eivät saapuneet oikein, joten jotkin käyttäjien pyynnöt eivät läpäise valtuutusta. Lisäksi uusi ongelma kumppanitileissä. Kiirehditään katsomaan.
03:20. Hätäsynkronointi
Yksi uusi ongelma korjattu. Toiseksi järjestämme hätäsynkronoinnin. Ymmärrämme, mitä tapahtuu: edellinen korjaus korjasi yhden ongelman, mutta loi uuden. Pidämme tauon selvittääksemme, kuinka se tehdään oikein ja ilman seurauksia.
03:30. Kuusi silmää
Ymmärrämme, mikä pohjan lopullinen tila tulee olla, jotta kaikki sujuisi hyvin kaikilla yhteistyökumppaneilla. Kirjoitamme pyynnön 6 silmällä, rullaamme sen esituotannossa, testaamme, rullaamme tuotantoon.
04:00. Kaikki toimii
Kaikki testit läpäisty, kriittisiä ongelmia ei ole näkyvissä. Ajoittain jokin tiimissä ei toimi jollekin, reagoimme nopeasti. Useimmiten hälytys on väärä. Mutta joskus jotain ei tule perille tai erillinen sivu ei toimi. Istumme, korjaamme, korjaamme, korjaamme. Erillinen tiimi lanseeraa viimeisen suuren ominaisuuden - laskutuksen.
04:30. Piste, josta ei ole paluuta
Kohta, josta ei ole paluuta, lähestyy, eli aika, jolloin, jos alamme rullata taaksepäin, emme täytä meille annettua seisokkiaikaa. Ongelmia on laskutuksessa, joka tietää ja kirjaa kaiken, mutta kieltäytyy itsepintaisesti poistamasta asiakkailta rahaa. Yksittäisillä sivuilla, toimissa ja tiloissa on useita virheitä. Päätoiminnot toimivat, kaikki testit läpäisevät onnistuneesti. Päätämme, että käyttöönotto on tapahtunut, emme peräänny.
06:00. Avoinna kaikille käyttöliittymässä
Bugit korjattu. Jotkut, jotka eivät houkuttele käyttäjiä, jätetään myöhempään käyttöön. Avaamme käyttöliittymän kaikille. Jatkamme laskutusta, odotamme käyttäjien palautetta ja seurantatuloksia.
07:00. Ongelmia API-latauksessa
On selvää, että suunnittelimme API-kuormituksen hieman väärin ja testasimme tämän kuorman, mikä ei pystynyt tunnistamaan ongelmaa. Tämän seurauksena ≈5 % pyynnöistä epäonnistuu. Liikutaan ja etsitään syytä.
Laskutus on sitkeää, eikä myöskään halua toimia. Päätämme lykätä sitä myöhemmäksi, jotta muutokset voidaan toteuttaa rauhallisesti. Eli kaikki resurssit kertyvät siihen, mutta asiakkaiden poistot eivät mene läpi. Tietenkin tämä on ongelma, mutta verrattuna yleiseen käyttöönottoon se näyttää merkityksettömältä.
08:00. Korjaa API
Teimme korjauksen kuormalle, viat hävisivät. Alamme mennä kotiin.
10:00. Kaikki
Kaikki on korjattu. Valvonnassa on hiljaista ja asiakkaiden luona porukka menee vähitellen nukkumaan. Laskutus säilyy, palautamme sen huomenna.
Sitten päivän aikana tehtiin käyttöönottoja, jotka korjasivat joidenkin asiakkaidemme lokit, ilmoitukset, palautuskoodit ja mukautukset.
Eli käyttöönotto onnistui! Se voisi tietysti olla parempi, mutta teimme johtopäätökset siitä, mikä ei riittänyt saavuttamaan täydellisyyttä.
Yhteensä
Kahden kuukauden aktiivisen käyttöönottovalmistelun aikana suoritettiin 2 tehtävää, jotka kestivät muutamasta tunnista useaan päivään.
Käyttöönoton aikana:
- uudet ja muuttuneet demonit - 5 kappaletta, jotka korvaavat 2 monoliittia;
- muutokset tietokannoissa - kaikki 6 tietokantaamme, joissa on käyttäjätietoja, ovat vaikuttaneet, latauksia on tehty kolmesta vanhasta tietokannasta yhteen uuteen;
- täysin uusittu käyttöliittymä;
- ladatun koodin määrä - 33 tuhatta riviä uutta koodia, ≈ 3 tuhatta riviä koodia testeissä, ≈ 5 tuhatta riviä siirtokoodia;
- kaikki tiedot ovat ehjät, yhdenkään asiakkaan virtuaalikoneen ei ole vaurioitunut. 🙂
Hyviä käytäntöjä hyvään käyttöönottoon
He opastivat meitä tässä vaikeassa tilanteessa. Mutta yleisesti ottaen on hyödyllistä noudattaa niitä minkä tahansa käyttöönoton aikana. Mutta mitä monimutkaisempi käyttöönotto, sitä suurempi rooli niillä on.
- Ensimmäinen asia, joka sinun on tehtävä, on ymmärtää, kuinka käyttöönotto voi vaikuttaa tai vaikuttaa käyttäjiin. Tuleeko seisokkeja? Jos on, mikä on seisokkiaika? Miten tämä vaikuttaa käyttäjiin? Mitkä ovat mahdolliset parhaat ja huonoimmat skenaariot? Ja kattaa riskit.
- Suunnittele kaikki. Jokaisessa vaiheessa sinun on ymmärrettävä kaikki käyttöönoton näkökohdat:
- koodin toimitus;
- koodin palautus;
- kunkin toimenpiteen aika;
- vaikuttanut toiminnallisuus.
- Toista skenaariot, kunnes kaikki käyttöönoton vaiheet ja riskit niissä käy ilmi. Jos sinulla on epäilyksiä, voit pitää tauon ja tarkastella kyseenalaista vaihetta erikseen.
- Jokaista vaihetta voidaan ja pitäisi parantaa, jos se auttaa käyttäjiämme. Se esimerkiksi vähentää seisokkeja tai poistaa joitakin riskejä.
- Palautustestaus on paljon tärkeämpää kuin koodin toimitustestaus. On tarpeen tarkistaa, että palautuksen seurauksena järjestelmä palaa alkuperäiseen tilaan, ja vahvistaa tämä testeillä.
- Kaikki mikä voidaan automatisoida, pitää automatisoida. Kaikki mitä ei voida automatisoida, tulee kirjoittaa etukäteen huijausarkille.
- Kirjaa onnistumiskriteeri. Mitä toimintoja pitäisi olla saatavilla ja mihin aikaan? Jos näin ei tapahdu, suorita palautussuunnitelma.
- Ja mikä tärkeintä - ihmiset. Jokaisen tulee olla tietoinen siitä, mitä he tekevät, miksi ja mikä riippuu heidän toimistaan käyttöönottoprosessissa.
Ja yhdellä lauseella, hyvällä suunnittelulla ja viimeistelyllä voit toteuttaa mitä haluat ilman myyntiin kohdistuvia seurauksia. Jopa jotain, joka vaikuttaa kaikkiin palveluihisi tuotannossa.
Lähde: will.com