Egy bevezetési történet, amely mindenre hatással volt

A valóság ellenségei 12f-2

Április végén, amikor a White Walkers Winterfellt ostromolta, érdekesebb dolog történt velünk: egy szokatlan gurítást végeztünk. Elvileg folyamatosan új funkciókat vezetünk be a termelésbe (mint mindenki más). De ez más volt. Ennek mértéke olyan volt, hogy az esetleges hibák, amelyeket elkövethetünk, minden szolgáltatásunkra és felhasználónkra hatással voltak. Ennek eredményeként mindent a terveknek megfelelően, a tervezett és meghirdetett leállási időn belül, értékesítési következmények nélkül hajtottunk végre. A cikk arról szól, hogyan értük el ezt, és hogyan tudja ezt bárki megismételni otthon.

Most nem írom le az általunk hozott építészeti és műszaki döntéseket, és nem mondom el, hogyan működik mindez. Ezek inkább feljegyzések a margón arról, hogyan zajlott le az egyik legnehezebb kiterjesztés, amit megfigyeltem, és amiben közvetlenül részt vettem. Nem tartok igényt a teljességre vagy a technikai részletekre, talán egy másik cikkben fognak megjelenni.

Háttér + milyen funkció ez?

Felhőplatformot építünk Mail.ru Cloud Solutions (MCS), ahol műszaki igazgatóként dolgozom. És most itt az ideje, hogy hozzáadjuk az IAM-et (Identity and Access Management) a platformunkhoz, amely egységes kezelést biztosít az összes felhasználói fiókhoz, felhasználóhoz, jelszavahoz, szerepkörhöz, szolgáltatáshoz és egyebekhez. Hogy miért van rá szükség a felhőben, az nyilvánvaló kérdés: minden felhasználói információ abban tárolódik.

Az ilyen dolgokat általában a projektek legelején kezdik építeni. De történelmileg a dolgok egy kicsit másképp alakultak az MCS-ben. Az MCS két részből áll:

• Openstack saját Keystone jogosultsági modullal,
• Hotbox (S3 tároló) a Mail.ru Cloud projekten,

amely körül aztán új szolgáltatások jelentek meg.

Lényegében két különböző típusú felhatalmazásról volt szó. Ezenkívül néhány különálló Mail.ru fejlesztést használtunk, például egy általános Mail.ru jelszótárolót, valamint egy saját írású openid csatlakozót, aminek köszönhetően a Horizon panelen SSO (end-to-end engedélyezés) biztosított. virtuális gépek (natív OpenStack felhasználói felület).

Az IAM elkészítése számunkra azt jelentette, hogy mindezt egyetlen rendszerbe kapcsoljuk, teljesen a sajátunkba. Ugyanakkor nem veszítünk el semmilyen funkcionalitást az út során, hanem olyan alapot teremtünk a jövő számára, amely lehetővé teszi, hogy transzparens módon, átalakítás nélkül finomítsuk, és funkcionalitás szempontjából méretezzük. Kezdetben a felhasználóknak is volt példaképe a szolgáltatásokhoz való hozzáférésben (központi RBAC, szerepkör alapú hozzáférés-vezérlés) és még néhány apróság.

A feladat nem triviálisnak bizonyult: python és perl, több háttérprogram, önállóan írt szolgáltatások, több fejlesztőcsapat és adminisztrátor. És ami a legfontosabb, több ezer élő felhasználó van a harci termelési rendszerben. Mindezt meg kellett írni, és ami a legfontosabb, áldozatok nélkül ki kell gördíteni.

Mit dobunk ki?

Nagyon durván fogalmazva kb 4 hónap alatt elkészítettük a következőket:

• Számos új démont hoztunk létre, amelyek a korábban az infrastruktúra különböző részein működő funkciókat összesítették. A többi szolgáltatásnak új backendet írtak elő ezeknek a démonoknak a formájában.
• Saját, minden szolgáltatásunkhoz elérhető központi jelszó- és kulcstárunkat készítettük, amely igény szerint szabadon módosítható.
• 4 új háttérprogramot írtunk a Keystone-hoz a semmiből (felhasználók, projektek, szerepkörök, szerep-hozzárendelések), amelyek valójában felváltották az adatbázisát, és mostantól egyetlen tárhelyként funkcionálnak felhasználói jelszavaink számára.
• Megtanítottuk az összes Openstack-szolgáltatásunkat, hogy a házirendekért egy harmadik féltől származó házirend-szolgáltatást keressenek ahelyett, hogy ezeket a házirendeket minden kiszolgálóról helyileg olvasnák ki (igen, az Openstack alapértelmezés szerint így működik!)

Egy ilyen nagy átdolgozás nagy, összetett és ami a legfontosabb, szinkron változtatásokat igényel több rendszerben, amelyeket különböző fejlesztőcsapatok írtak. Összeszerelés után az egész rendszernek működnie kell.

Hogyan lehet végrehajtani az ilyen változtatásokat, és nem elrontani? Először úgy döntöttünk, hogy egy kicsit a jövőbe tekintünk.

Bevezetési stratégia

• Lehetőség lenne több lépcsőben is kiteríteni a terméket, de ez háromszorosára növelné a fejlesztési időt. Ezen túlmenően, egy ideig teljes deszinkronizálást végzünk az adatbázisokban. Meg kell írnia saját szinkronizálási eszközeit, és hosszú ideig több adattárral kell élnie. Ez pedig sokféle kockázatot jelent.
• Mindent előre megcsináltak, ami a felhasználó számára átláthatóan elkészíthető volt. 2 hónapig tartott.
• Több órás leállást hagytunk magunknak – csak az erőforrások létrehozásához és módosításához szükséges felhasználói műveletekhez.
• Az összes, már létrehozott erőforrás működéséhez az állásidő elfogadhatatlan volt. Azt terveztük, hogy a bevezetés során az erőforrásoknak leállás és az ügyfelekre gyakorolt ​​hatás nélkül kell működniük.
• Annak érdekében, hogy csökkentsük az ügyfeleinkre gyakorolt ​​hatást, ha valami elromlik, úgy döntöttünk, hogy vasárnap este elindítjuk. Kevesebb ügyfél kezeli éjszaka a virtuális gépeket.
• Figyelmeztettük minden ügyfelünket, hogy a bevezetésre kiválasztott időszakban a szolgáltatáskezelés nem lesz elérhető.

Kitérő: mi az a bevezetés?

<vigyázat, filozófia>

Minden informatikus könnyen meg tudja válaszolni, mi az a bevezetés. Telepíted a CI/CD-t, és mindent automatikusan az üzletbe szállítanak. 🙂

Természetesen ez igaz. A nehézséget azonban az okozza, hogy a modern kódtovábbítási automatizálási eszközökkel magának a bevezetésnek a megértése elveszett. Hogyan feledkezik meg a kerék feltalálásának epikus voltáról, ha a modern közlekedést nézi. Minden annyira automatizált, hogy a bevezetést gyakran a teljes kép megértése nélkül hajtják végre.

És az egész kép ilyen. A közzététel négy fő szempontból áll:

1. Kód kézbesítése, adatmódosítással együtt. Például a vándorlásaik.
2. A kód visszaállítása a visszalépés lehetősége, ha valami baj van. Például biztonsági mentések létrehozásával.
3. Az egyes közzétételi/visszaállítási műveletek ideje. Meg kell értenie az első két pont bármely műveletének időzítését.
4. Érintett funkcionalitás. Mind a várható pozitív, mind a lehetséges negatív hatásokat értékelni kell.

Mindezeket a szempontokat figyelembe kell venni a sikeres bevezetéshez. Általában csak az első, legjobb esetben a második pontot értékelik, majd a bevezetést sikeresnek tekintik. De a harmadik és a negyedik még fontosabb. Melyik felhasználó szeretné, ha a közzététel egy perc helyett 3 órát venne igénybe? Vagy ha valami szükségtelen dolog éri a bevezetést? Vagy egy szolgáltatás leállása beláthatatlan következményekkel jár?

törvény 1..n, szabadulás előkészítése

Először arra gondoltam, hogy röviden leírom a találkozásainkat: az egész csapat, annak részei, rengeteg megbeszélés a kávézókban, viták, tesztek, ötletbörze. Aztán azt hittem, hogy felesleges. Négy hónapos fejlesztés mindig ebből áll, főleg ha nem folyamatosan szállíthatót írsz, hanem egy élő rendszer egyik nagy funkcióját. Ez az összes szolgáltatást érinti, de semmi sem változhat a felhasználók számára, kivéve „egy gomb a webes felületen”.

A bevezetés módjáról alkotott elképzelésünk minden egyes új találkozó óta megváltozott, és meglehetősen jelentősen. Például frissíteni akartuk a teljes számlázási adatbázisunkat. De kiszámítottuk az időt, és rájöttünk, hogy ezt lehetetlen ésszerű bevezetési idő alatt megtenni. Majdnem egy további hétbe telt a számlázási adatbázis szilánkolása és archiválása. És amikor a várt kifutási sebesség még mindig nem volt kielégítő, további, erősebb hardvert rendeltünk, ahol az egész alapot húzták. Nem arról van szó, hogy nem akartuk ezt hamarabb megtenni, de a jelenlegi bevezetési igény miatt nem maradtunk választási lehetőségeink között.

Amikor egyikünknek kétségei támadtak afelől, hogy a bevezetés befolyásolhatja virtuális gépeink elérhetőségét, egy hetet töltöttünk tesztekkel, kísérletekkel, kódelemzéssel, és világosan megértettük, hogy ez nem fog megtörténni a termelésünkben, és még a legkétségesebb emberek is egyetértettek vele. ezzel.

Eközben a technikai támogatás srácai önálló kísérleteket végeztek, hogy utasításokat írjanak az ügyfeleknek a csatlakozási módokról, amelyeknek a bevezetés után megváltozniuk kellett. Dolgoztak a felhasználói UX-en, utasításokat készítettek és személyes konzultációkat adtak.

Minden lehetséges bevezetési műveletet automatizáltunk. Minden műveletet leírtak, még a legegyszerűbbeket is, és folyamatosan futottak a tesztek. Vitatkoztak a szolgáltatás kikapcsolásának legjobb módjáról - hagyja ki a démont, vagy blokkolja a hozzáférést a szolgáltatáshoz egy tűzfallal. A bevezetés minden szakaszához elkészítettük a csapatok ellenőrzőlistáját, amelyet folyamatosan frissítettünk. Készítettünk és folyamatosan frissítettük a Gantt-diagramot az összes bevezetési munkához, az időzítésekkel.

És aztán…

Az utolsó felvonás, a megjelenés előtt

...ideje kigurulni.

Ahogy mondani szokták, egy műalkotást nem lehet befejezni, csak befejezni a munkát. Akarattal kell törekednie, megértenie, hogy nem talál meg mindent, de hinnie kell, hogy minden ésszerű feltételezést megtett, minden lehetséges esetre gondoskodott, minden kritikus hibát lezárt, és minden résztvevő mindent megtett, amit tudott. Minél több kódot dobsz ki, annál nehezebb meggyőzni magad erről (ráadásul mindenki érti, hogy lehetetlen mindent előre látni).

Úgy döntöttünk, hogy készen állunk a bevezetésre, amikor meg voltunk győződve arról, hogy mindent megtettünk annak érdekében, hogy fedezzük a felhasználóinknak a váratlan hatásokkal és leállásokkal kapcsolatos kockázatait. Vagyis bármi elromolhat, kivéve:

1. Befolyásolja a (számunkra szent, legértékesebb) felhasználói infrastruktúrát,
2. Funkcionalitás: szolgáltatásunk használatának a bevezetést követően ugyanolyannak kell lennie, mint azt megelőzően.

Elterjedni

Két tekercs, 8 ne zavarjon

A felhasználóktól érkező összes kérés esetén 7 órás állásidőt veszünk igénybe. Jelenleg egy bevezetési és egy visszaállítási tervünk is van.

• Maga a kiterjesztés körülbelül 3 órát vesz igénybe.
• 2 óra a tesztelésre.
• 2 óra – tartalék a változtatások esetleges visszaállítására.

Minden akcióhoz Gantt-diagram készült, mennyi ideig tart, mi történik egymás után, mi történik párhuzamosan.

Egy részlet a közzétett Gantt-diagramból, az egyik korai verzió (párhuzamos végrehajtás nélkül). A legértékesebb szinkronizálási eszköz

Minden résztvevőnek meg van határozva a szerepe a bevezetésben, milyen feladatokat végez, és mi a felelős. Igyekszünk minden szakaszt automatizálni, kigörgetni, visszagörgetni, visszajelzéseket gyűjteni és újra kidobni.

Az események krónikája

Így április 15-én, vasárnap este 29 órára 10-en jöttek dolgozni. A kiemelt résztvevők mellett néhányan egyszerűen csak szurkolni jöttek a csapatnak, amit külön köszönünk nekik.

Azt is érdemes megemlíteni, hogy a legfontosabb tesztelőnk szabadságon van. Tesztelés nélkül lehetetlen kihelyezni, vizsgáljuk a lehetőségeket. Egy kolléga vállalja, hogy tesztel minket a nyaralásból, amiért óriási köszönetet kap az egész csapattól.

00:00. Állj meg
Leállítjuk a felhasználói kéréseket, kifüggesztjük a műszaki munka feliratát. A monitor üvölt, de minden normális. Ellenőrizzük, hogy semmi más nem esett-e le, mint aminek esnie kellett. És elkezdjük a migrációval kapcsolatos munkát.

Mindenkinek van egy pontról pontra kinyomtatott terítési terve, mindenki tudja, hogy ki mit csinál és melyik pillanatban. Minden egyes művelet után ellenőrizzük az időzítéseket, hogy ne lépjük túl azt, és minden a terv szerint halad. Azok, akik az aktuális szakaszban nem vesznek részt közvetlenül a kihelyezésben, egy online játék (Xonotic, 3-as típusú quack) piacra dobásával készülnek, hogy ne zavarják kollégáikat. 🙂

02:00. Kigördült
Kellemes meglepetés - adatbázisaink és migrációs szkriptjeink optimalizálása miatt egy órával korábban fejezzük be a közzétételt. Az általános kiáltás: „Kigurult!” Minden új funkció élesben van, de egyelőre csak mi láthatjuk őket a felületen. Mindenki tesztelési módba lép, csoportokba rendezi őket, és elkezdi látni, mi történt a végén.

Nem sikerült túl jól, ezt 10 perc után vesszük észre, amikor a csapattagok projektjeiben semmi sem kapcsolódik vagy működik. Gyors szinkronizálás, hangot adunk a problémáinknak, felállítjuk a prioritásokat, csapatokba bomlik és elkezdjük a hibakeresést.

02:30. Két nagy probléma négy szem ellen
Két nagy problémát találunk. Felismertük, hogy az ügyfelek nem látnak egyes kapcsolódó szolgáltatásokat, és problémák merülnek fel a partnerfiókokkal. Mindkettő a tökéletlen áttelepítési szkripteknek köszönhető bizonyos éles esetekben. Most meg kell javítanunk.

Olyan lekérdezéseket írunk, amelyek ezt rögzítik, legalább 4 szemmel. Az előgyártás során teszteljük őket, hogy megbizonyosodjunk arról, hogy működnek, és nem törnek el semmit. Tovább gurulhatsz. Ugyanakkor lefuttatjuk a rendszeres integrációs tesztelésünket, amely feltár még néhány problémát. Mindegyik kicsi, de ezeket is javítani kell.

03:00. -2 probléma +2 probléma
A két korábbi nagy probléma megoldódott, és szinte az összes kisebb probléma is. Mindazok, akik nem foglalkoznak a javításokkal, aktívan dolgoznak a fiókjukon, és jelentik, amit találnak. Részesítjük, szétosztjuk a csapatok között, és reggelre hagyjuk a nem kritikus dolgokat.

Újra lefuttatjuk a teszteket, két új nagy problémát fedeznek fel. Nem minden szolgáltatási szabályzat érkezett meg megfelelően, ezért néhány felhasználói kérés nem megy át az engedélyezésen. Plusz egy új probléma a partnerfiókokkal. Rohanjunk megnézni.

03:20. Vészhelyzeti szinkronizálás
Egy új probléma javítva. A másodikhoz vészszinkronizálást szervezünk. Értjük, mi történik: az előző javítás javított egy problémát, de egy másikat hozott létre. Tartunk egy kis szünetet, hogy kitaláljuk, hogyan kell helyesen és következmények nélkül csinálni.

03:30. Hat szem
Megértjük, hogy mi legyen a bázis végső állapota, hogy minden partner számára jól menjen. 6 szemmel kérést írunk, előgyártásban kigörgetjük, teszteljük, gyártásra kigurítjuk.

04:00. Minden működik
Minden teszt sikeres, kritikus probléma nem látható. Időnként valakinek nem megy valami a csapatban, azonnal reagálunk. Leggyakrabban a riasztás hamis. De néha valami nem érkezik meg, vagy egy külön oldal nem működik. Ülünk, javítunk, javítunk, javítunk. Külön csapat indítja el az utolsó nagy funkciót - a számlázást.

04:30. Pont ahonnan nincs visszatérés
Közeledik az a pont, ahonnan nincs visszaút, vagyis az az idő, amikor ha elkezdünk visszagurulni, nem fogunk megfelelni a nekünk adott leállásnak. Problémák vannak a számlázással, amely mindent tud és rögzít, de makacsul nem hajlandó pénzt leírni az ügyfelekről. Számos hiba található az egyes oldalakon, műveleteken és állapotokon. A fő funkció működik, minden teszt sikeresen sikeres. Úgy döntünk, hogy a kihelyezés megtörtént, nem gurulunk vissza.

06:00. Mindenki számára nyitott a felhasználói felületen
Hibák javítva. Néhányat, amely nem vonzza a felhasználókat, későbbre hagyjuk. Mindenki számára megnyitjuk a felületet. Továbbra is dolgozunk a számlázáson, várjuk a felhasználói visszajelzéseket és a nyomon követési eredményeket.

07:00. Problémák az API betöltésével
Világossá válik, hogy kissé rosszul terveztük meg az API terhelését, és teszteltük ezt a terhelést, amely nem tudta azonosítani a problémát. Ennek eredményeként a kérelmek ≈5%-a sikertelen. Mozgósítsunk, és keressük az okát.

A számlázás makacs, és nem is akar működni. Úgy döntünk, hogy későbbre halasztjuk, hogy a változtatásokat nyugodtan lehessen végrehajtani. Vagyis minden erőforrás felhalmozódik benne, de az ügyfelektől származó leírások nem mennek át. Természetesen ez probléma, de az általános bevezetéshez képest lényegtelennek tűnik.

08:00. Fix API
Kidolgoztunk egy javítást a terhelésre, a hibák megszűntek. Kezdünk hazamenni.

10:00. Minden
Minden fix. Csendes a figyelés, és az ügyfeleknél a csapat fokozatosan elalszik. A számlázás marad, holnap visszaállítjuk.

Aztán a nap folyamán olyan bevezetések történtek, amelyek javították a naplókat, az értesítéseket, a visszatérési kódokat és a testreszabásokat egyes ügyfeleink számára.

Szóval sikeres volt a bevezetés! Persze lehetne jobb is, de levontuk a következtetéseket, hogy mi nem volt elég a tökéletesség eléréséhez.

Összességében

A kiírásra való 2 hónapos aktív felkészülés során 43 feladatot végeztek el, amelyek néhány órától több napig tartottak.

Közzététel közben:

• új és megváltozott démonok - 5 darab, 2 monolit helyett;
• változások az adatbázisokon belül - mind a 6 felhasználói adatokat tartalmazó adatbázisunk érintett, három régi adatbázisból egy újba történt letöltés;
• teljesen újratervezett frontend;
• letöltött kód mennyisége - 33 ezer sor új kód, ≈ 3 ezer sor kód a tesztekben, ≈ 5 ezer sor migrációs kód;
• minden adat sértetlen, egyetlen ügyfél virtuális gépe sem sérült meg. 🙂

Jó gyakorlatok a jó közzétételhez

Ők vezettek minket ebben a nehéz helyzetben. Általánosságban elmondható azonban, hogy hasznos követni őket minden bevezetés során. De minél összetettebb a bevezetés, annál nagyobb szerepet játszanak.

1. Az első dolog, amit meg kell tennie, hogy megértse, hogyan érintheti vagy érinti a közzététel a felhasználókat. Lesz-e leállás? Ha igen, mi az állásidő? Hogyan érinti ez a felhasználókat? Melyek a lehetséges legjobb és legrosszabb forgatókönyvek? És fedezze a kockázatokat.
2. Tervezz meg mindent. Minden szakaszban meg kell értenie a közzététel minden szempontját:
   • kód kézbesítés;
   • kód visszagörgetése;
   • az egyes műveletek ideje;
   • érintett funkcionalitás.
3. Játssz végig a forgatókönyveken, amíg a bevezetés minden szakasza, valamint az egyes kockázatok nyilvánvalóvá nem válnak. Ha kétségei vannak, tartson egy kis szünetet, és külön vizsgálja meg a kérdéses szakaszt.
4. Minden egyes szakaszt lehet és kell is fejleszteni, ha ez segít felhasználóinknak. Például csökkenti az állásidőt vagy eltávolít bizonyos kockázatokat.
5. A visszagörgetési tesztelés sokkal fontosabb, mint a kódküldés tesztelése. Ellenőrizni kell, hogy a visszaállítás eredményeként a rendszer visszaáll-e eredeti állapotába, és ezt tesztekkel meg kell erősíteni.
6. Mindent, ami automatizálható, automatizálni kell. Mindent, ami nem automatizálható, előre le kell írni egy csalólapra.
7. Jegyezze fel a sikerességi feltételt. Milyen funkcióknak kell rendelkezésre állniuk és mikor? Ha ez nem történik meg, futtasson egy visszaállítási tervet.
8. És ami a legfontosabb - az emberek. Mindenkinek tisztában kell lennie azzal, hogy mit csinál, miért és mi függ a tetteitől a bevezetési folyamatban.

És egy mondatban: jó tervezéssel és kidolgozottsággal bármit kidobhatsz, amit csak akarsz, anélkül, hogy az értékesítésre nézve következményekkel járna. Még olyasmi is, ami hatással lesz az összes termelési szolgáltatására.

Forrás: will.com