Disvolva rakonto, kiu influis ĉion

Malamikoj de la Realo per 12f-2

Fine de aprilo, dum la Blankaj Promenantoj sieĝis Vintremon, io pli interesa okazis al ni; ni faris nekutiman lanĉon. Principe, ni konstante eligas novajn funkciojn en produktadon (kiel ĉiuj aliaj). Sed ĉi tiu estis malsama. La skalo de ĝi estis tia, ke eventualaj eraroj, kiujn ni povus fari, influus ĉiujn niajn servojn kaj uzantojn. Kiel rezulto, ni elvolvis ĉion laŭ plano, ene de la planita kaj anoncita malfunkcioperiodo, sen sekvoj por vendoj. La artikolo temas pri kiel ni atingis tion kaj kiel iu ajn povas ripeti ĝin hejme.

Mi nun ne priskribos la arkitekturajn kaj teknikajn decidojn, kiujn ni faris, nek rakontos kiel ĉio funkcias. Ĉi tiuj estas pli ĝuste notoj en la marĝenoj pri kiel okazis unu el la plej malfacilaj lanĉoj, kiujn mi observis kaj en kiu mi rekte okupiĝis. Mi ne pretendas kompletecon aŭ teknikajn detalojn; eble ili aperos en alia artikolo.

Fono + kia funkcieco estas ĉi tio?

Ni konstruas nuban platformon Mail.ru Cloud Solutions (MCS), kie mi laboras kiel teknika direktoro. Kaj nun estas tempo aldoni IAM (Identeca kaj Aliradministrado) al nia platformo, kiu provizas unuecan administradon de ĉiuj uzantkontoj, uzantoj, pasvortoj, roloj, servoj kaj pli. Kial ĝi estas bezonata en la nubo estas evidenta demando: ĉiuj uzantinformoj estas konservitaj en ĝi.

Kutime tiaj aferoj komencas esti konstruitaj ĉe la komenco mem de ajna projekto. Sed historie aferoj estis iomete malsamaj en MCS. MCS estis konstruita en du partoj:

• Openstack kun sia propra Keystone-rajtigomodulo,
• Hotbox (S3-stokado) bazita sur la projekto Mail.ru Cloud,

ĉirkaŭ kiuj tiam aperis novaj servoj.

Esence, ĉi tiuj estis du malsamaj specoj de rajtigo. Plie, ni uzis iujn apartajn evoluojn de Mail.ru, ekzemple ĝeneralan pasvortan stokadon de Mail.ru, kaj ankaŭ memskribitan openid-konektilon, danke al kiu SSO (fin-al-fina rajtigo) estis provizita en la panelo Horizonto. de virtualaj maŝinoj (denaska OpenStack UI).

Fari IAM por ni signifis ligi ĉion en ununuran sistemon, tute nian. Samtempe, ni ne perdos ajnan funkciecon survoje, sed kreos fundamenton por la estonteco, kiu permesos al ni travideble rafini ĝin sen refactoring kaj skali ĝin laŭ funkcieco. Ankaŭ ĉe la komenco, uzantoj havis rolmodelon por aliro al servoj (centra RBAC, rol-bazita alirkontrolo) kaj iuj aliaj malgrandaj aferoj.

La tasko montriĝis ne-triviala: python kaj perl, pluraj backends, sendepende skribitaj servoj, pluraj evoluteamoj kaj administrantoj. Kaj plej grave, estas miloj da vivaj uzantoj sur la batalproduktadsistemo. Ĉio ĉi devis esti skribita kaj, plej grave, ruliĝita sen viktimoj.

Kion ni disvolvos?

Por diri ĝin tre proksimume, en ĉirkaŭ 4 monatoj ni preparis la jenon:

• Ni kreis plurajn novajn demonojn, kiuj kunigis funkciojn, kiuj antaŭe funkciis en malsamaj partoj de la infrastrukturo. La resto de la servoj estis preskribitaj nova backend en la formo de ĉi tiuj demonoj.
• Ni skribis nian propran centran stokadon de pasvortoj kaj ŝlosiloj, disponeblaj por ĉiuj niaj servoj, kiuj povas esti libere modifitaj laŭbezone.
• Ni skribis 4 novajn backends por Keystone de nulo (uzantoj, projektoj, roloj, rolasigno), kiuj, fakte, anstataŭigis ĝian datumbazon, kaj nun funkcias kiel ununura deponejo por niaj uzantpasvortoj.
• Ni instruis ĉiujn niajn Openstack-servojn iri al triaparta politika servo por iliaj politikoj anstataŭ legi ĉi tiujn politikojn loke de ĉiu servilo (jes, tiel Openstack funkcias defaŭlte!)

Tia grava reverkado postulas grandajn, kompleksajn kaj, plej grave, sinkronajn ŝanĝojn en pluraj sistemoj skribitaj de malsamaj evoluigaj teamoj. Unufoje kunvenita, la tuta sistemo devus funkcii.

Kiel efektivigi tiajn ŝanĝojn kaj ne malŝraŭbi ĝin? Unue ni decidis iom rigardi la estontecon.

Disvolva strategio

• Eblus lanĉi la produkton en pluraj etapoj, sed ĉi tio pliigus la disvolvan tempon trifoje. Krome, dum iom da tempo ni havus kompletan malsinkronigon de datumoj en la datumbazoj. Vi devus skribi viajn proprajn sinkronigajn ilojn kaj vivi kun pluraj datumbutikoj dum longa tempo. Kaj ĉi tio kreas diversajn riskojn.
• Ĉio, kio povus esti preta travideble por la uzanto, estis farita anticipe. Ĝi daŭris 2 monatojn.
• Ni permesis al ni malfunkcion dum kelkaj horoj - nur por uzantoperacioj por krei kaj ŝanĝi rimedojn.
• Por la funkciado de ĉiuj jam kreitaj rimedoj, malfunkcio estis neakceptebla. Ni planis, ke dum lanĉo, rimedoj devus funkcii sen malfunkcio kaj tuŝi klientojn.
• Por redukti la efikon al niaj klientoj se io misfunkcias, ni decidis disvastigi dimanĉon vespere. Malpli da klientoj administras virtualajn maŝinojn nokte.
• Ni avertis ĉiujn niajn klientojn, ke dum la periodo elektita por lanĉo, serva administrado estos neatingebla.

Digreso: kio estas lanĉo?

<singardemo, filozofio>

Ĉiu IT-specialisto povas facile respondi, kio estas lanĉo. Vi instalas CI/KD, kaj ĉio estas aŭtomate liverita al la vendejo. 🙂

Kompreneble ĉi tio estas vera. Sed la malfacileco estas, ke kun modernaj kodaj liveraj aŭtomatigaj iloj, la kompreno pri la elŝuto mem estas perdita. Kiel vi forgesas pri la epopeo de la invento de la rado kiam vi rigardas modernan transporton. Ĉio estas tiel aŭtomatigita, ke la lanĉo ofte efektiviĝas sen kompreni la tutan bildon.

Kaj la tuta bildo estas tia. Disvolviĝo konsistas el kvar ĉefaj aspektoj:

1. Livero de kodo, inkluzive de datuma modifo. Ekzemple, iliaj migradoj.
2. Kodo-returniĝo estas la kapablo reiri se io misfunkcias. Ekzemple, per kreado de sekurkopioj.
3. Tempo de ĉiu ekfunkciigo/returniĝo. Vi devas kompreni la tempon de ajna operacio de la unuaj du punktoj.
4. Trafita funkcieco. Necesas taksi ambaŭ la atendatajn pozitivajn kaj eblajn negativajn efikojn.

Ĉiuj ĉi tiuj aspektoj devas esti konsiderataj por sukcesa lanĉo. Kutime nur la unua, aŭ plej bone la dua, punkto estas taksita, kaj tiam la lanĉo estas konsiderata sukcesa. Sed la tria kaj kvara estas eĉ pli gravaj. Kiu uzanto ŝatus ĝin se la lanĉo daŭris 3 horojn anstataŭ unu minuto? Aŭ se io nenecesa estas tuŝita dum la lanĉo? Aŭ ĉu la malfunkcio de unu servo kondukos al neantaŭvideblaj sekvoj?

Akto 1..n, preparo por liberigo

Komence mi pensis mallonge priskribi niajn renkontiĝojn: la tuta teamo, ĝiaj partoj, amasoj da diskutoj ĉe kafejoj, argumentoj, provoj, cerbumoj. Tiam mi pensis, ke ĝi estus nenecesa. Kvar monatoj da evoluo ĉiam konsistas el tio, precipe kiam vi ne skribas ion, kio povas esti liverita konstante, sed unu granda funkcio por viva sistemo. Kiu influas ĉiujn servojn, sed nenio devus ŝanĝiĝi por uzantoj krom "unu butono en la retinterfaco."

Nia kompreno pri kiel disvolviĝi ŝanĝiĝis de ĉiu nova renkontiĝo, kaj sufiĉe signife. Ekzemple, ni ĝisdatigos nian tutan fakturan datumbazon. Sed ni kalkulis la tempon kaj rimarkis, ke estas neeble fari tion en akceptebla tempodaŭro. Ni bezonis preskaŭ plian semajnon por dividi kaj arkivi la fakturan datumbazon. Kaj kiam la atendata rapideco ankoraŭ ne estis kontentiga, ni mendis plian, pli potencan aparataron, kie la tuta bazo estis trenita. Ne estas tio, ke ni ne volis fari tion pli frue, sed la nuna bezono elŝeligi nin lasis nin sen ebloj.

Kiam unu el ni dubis, ke la lanĉo povus influi la haveblecon de niaj virtualaj maŝinoj, ni pasigis semajnon farante testojn, eksperimentojn, kodan analizon kaj ricevis klaran komprenon, ke tio ne okazos en nia produktado, kaj eĉ la plej dubindaj homoj konsentis. kun ĉi tio.

Intertempe, la uloj de teknika subteno faris siajn proprajn sendependajn eksperimentojn por skribi instrukciojn por klientoj pri konektometodoj, kiuj devis ŝanĝiĝi post la lanĉo. Ili laboris pri uzanto UX, preparis instrukciojn kaj disponigis personajn konsultojn.

Ni aŭtomatigis ĉiujn realigajn operaciojn, kiuj eblis. Ĉiu operacio estis skribita, eĉ la plej simplaj, kaj provoj estis konstante rulitaj. Ili kverelis pri la plej bona maniero malŝalti la servon - ellasi la demonon aŭ bloki aliron al la servo per fajroŝirmilo. Ni kreis kontrolon de teamoj por ĉiu etapo de lanĉo kaj ĝisdatigis ĝin konstante. Ni desegnis kaj konstante ĝisdatigis Gantt-diagramon por ĉiuj lanĉaj laboroj, kun tempoj.

Kaj tiel…

La fina akto, antaŭ ol ruliĝi

...estas tempo elruliĝi.

Kiel oni diras, artaĵo ne povas esti finita, nur finita pri ĝi. Vi devas klopodi de volo, komprenante, ke vi ne trovos ĉion, sed kredante, ke vi faris ĉiujn raciajn supozojn, provizis por ĉiuj eblaj kazoj, fermis ĉiujn kritikajn cimojn, kaj ĉiuj partoprenantoj faris ĉion, kion ili povis. Ju pli da kodo vi disvolvas, des pli malfacilas konvinki vin pri tio (krome ĉiuj komprenas, ke ĉio antaŭvidi estas neeble).

Ni decidis, ke ni pretas lanĉi, kiam ni konvinkiĝis, ke ni faris ĉion eblan por kovri ĉiujn riskojn por niaj uzantoj asociitaj kun neatenditaj efikoj kaj malfunkcioj. Tio estas, io povas misfunkcii krom:

1. Afekta (sankta por ni, plej altvalora) uzantinstrukturo,
2. Funkcio: la uzo de nia servo post la lanĉo devus esti la sama kiel antaŭ ĝi.

Elruliĝante

Du rulo, 8 ne malhelpas

Ni prenas malfunkcion por ĉiuj petoj de uzantoj dum 7 horoj. Ĉi-momente, ni havas ambaŭ planon de lanĉado kaj planon de restarigo.

• La lanĉo mem daŭras proksimume 3 horojn.
• 2 horoj por testado.
• 2 horoj - rezervu por eventuala retroigo de ŝanĝoj.

Diagramo de Gantt estis desegnita por ĉiu ago, kiom da tempo ĝi daŭras, kio okazas sinsekve, kio estas farita paralele.

Peco de ruliga diagramo de Gantt, unu el la fruaj versioj (sen paralela ekzekuto). La Plej Valora Sinkroniga Ilo

Ĉiuj partoprenantoj havas sian rolon en la lanĉo determinita, kiajn taskojn ili faras, kaj pri kio ili respondecas. Ni provas alporti ĉiun etapon al aŭtomateco, ruliĝi ĝin, ruliĝi ĝin reen, kolekti reagojn kaj ruliĝi ĝin denove.

Kroniko de eventoj

Do, 15 homoj venis labori dimanĉe, la 29-an de aprilo, je la 10-a. Krom la ĉefaj partoprenantoj, kelkaj venis simple por subteni la teamon, pro kio specialan dankon al ili.

Ankaŭ menciindas, ke nia ŝlosila testilo estas feria. Estas neeble ruliĝi sen testado, ni esploras eblojn. Kolegio konsentas testi nin de feriado, pro kio ŝi ricevas grandegan dankemon de la tuta teamo.

00:00. Haltu
Ni ĉesas uzantpetojn, pendigas ŝildon dirante teknika laboro. La monitorado krias, sed ĉio estas normala. Ni kontrolas, ke nenio falis krom tio, kio devis fali. Kaj ni komencas labori pri migrado.

Ĉiuj havas presitan landan planon punkto post punkto, ĉiuj scias kiu faras kion kaj en kiu momento. Post ĉiu ago, ni kontrolas la tempon por certigi, ke ni ne superas ilin, kaj ĉio iras laŭ plano. Tiuj, kiuj ne partoprenas en la disvolvo rekte en la nuna etapo, prepariĝas lanĉante retan ludilon (Xonotic, tipo 3 kvakuloj) por ne ĝeni siajn kolegojn. 🙂

02:00. Elruliĝis
Agrabla surprizo - ni finas la lanĉon unu horon pli frue, pro la optimumigo de niaj datumbazoj kaj migraj skriptoj. La ĝenerala krio, "elvolvita!" Ĉiuj novaj funkcioj estas en produktado, sed ĝis nun nur ni povas vidi ilin en la interfaco. Ĉiuj iras en testareĝimon, ordigas ilin en grupojn, kaj komencas vidi kio okazis finfine.

Ĝi ne rezultis tre bone, ni rimarkas tion post 10 minutoj, kiam nenio estas konektita aŭ funkcias en la projektoj de la teamanoj. Rapida sinkronigo, ni voĉigas niajn problemojn, fiksas prioritatojn, eniras teamojn kaj eniras sencimigi.

02:30. Du grandaj problemoj kontraŭ kvar okuloj
Ni trovas du grandajn problemojn. Ni rimarkis, ke klientoj ne vidos iujn konektitajn servojn, kaj problemoj aperos kun partneraj kontoj. Ambaŭ ŝuldiĝas al neperfektaj migraj skriptoj por kelkaj randkazoj. Ni devas ripari ĝin nun.

Ni skribas demandojn, kiuj registras ĉi tion, kun almenaŭ 4 okuloj. Ni testas ilin dum antaŭproduktado por certigi, ke ili funkcias kaj ne rompas ion ajn. Vi povas ruliĝi plu. Samtempe ni faras nian regulan integrigan testadon, kiu malkaŝas kelkajn pliajn problemojn. Ili ĉiuj estas malgrandaj, sed ili ankaŭ devas esti riparitaj.

03:00. -2 problemoj +2 problemoj
La du antaŭaj grandaj problemoj estis solvitaj, kaj preskaŭ ĉiuj malgrandaj ankaŭ. Ĉiuj tiuj neokupitaj en korektoj aktive laboras en siaj kontoj kaj raportas kion ili trovas. Ni prioritatas, distribuas inter teamoj kaj lasas nekritikajn erojn por la mateno.

Ni denove faras la testojn, ili malkovras du novajn grandajn problemojn. Ne ĉiuj servaj politikoj alvenis ĝuste, do iuj uzantpetoj ne pasas rajtigon. Krome nova problemo kun partneraj kontoj. Ni rapidu rigardi.

03:20. Urĝa sinkronigo
Unu nova problemo riparita. Por la dua, ni organizas krizan sinkronigon. Ni komprenas, kio okazas: la antaŭa riparo riparis unu problemon, sed kreis alian. Ni prenas paŭzon por ekscii kiel fari ĝin ĝuste kaj sen konsekvencoj.

03:30. Ses okuloj
Ni komprenas, kia estu la fina stato de la bazo, por ke ĉio iru bone por ĉiuj partneroj. Ni skribas peton kun 6 okuloj, ruliĝas ĝin en antaŭproduktado, provas ĝin, ruliĝas ĝin por produktado.

04:00. Ĉio funkcias
Ĉiuj provoj pasis, neniuj kritikaj problemoj estas videblaj. De tempo al tempo, io en la teamo ne funkcias por iu, ni rapide reagas. Plej ofte la alarmo estas falsa. Sed foje io ne alvenas, aŭ aparta paĝo ne funkcias. Ni sidas, fiksas, fiksas, riparas. Aparta teamo lanĉas la lastan grandan funkcion - fakturado.

04:30. Punkto de nereveno
Alproksimiĝas la nerevena punkto, tio estas, la tempo, kiam, se ni komencos retroiri, ni ne renkontos la malfunkcion donitan al ni. Estas problemoj kun fakturado, kiu scias kaj registras ĉion, sed obstine rifuzas forĵeti monon de klientoj. Estas pluraj eraroj sur individuaj paĝoj, agoj kaj statusoj. La ĉefa funkcio funkcias, ĉiuj provoj sukcesas. Ni decidas, ke la lanĉo okazis, ni ne retroiros.

06:00. Malfermita por ĉiuj en la UI
Cimoj fiksitaj. Iuj, kiuj ne plaĉas al uzantoj, restas por poste. Ni malfermas la interfacon al ĉiuj. Ni daŭre laboras pri fakturado, atendante uzantajn komentojn kaj kontrolajn rezultojn.

07:00. Problemoj kun API-ŝarĝo
Evidentiĝas, ke ni iomete misplanis la ŝarĝon sur nia API kaj testis ĉi tiun ŝarĝon, kiu ne povis identigi la problemon. Kiel rezulto, ≈5% de petoj malsukcesas. Ni mobiliziĝu kaj serĉu la kialon.

Fakturado estas obstina kaj ankaŭ ne volas labori. Ni decidas prokrasti ĝin ĝis poste por efektivigi la ŝanĝojn trankvile. Tio estas, ĉiuj rimedoj estas akumulitaj en ĝi, sed forĵetaĵoj de klientoj ne trairas. Kompreneble, ĉi tio estas problemo, sed kompare kun la ĝenerala lanĉo ĝi ŝajnas negrava.

08:00. Ripari API
Ni eligis solvon por la ŝarĝo, la misfunkciadoj foriris. Ni komencas iri hejmen.

10:00. Ĉiuj
Ĉio estas fiksita. Estas trankvile en monitorado kaj ĉe la loko de la klientoj, la teamo iom post iom endormiĝas. La fakturado restas, ni restarigos ĝin morgaŭ.

Tiam dum la tago okazis lanĉoj, kiuj riparis protokolojn, sciigojn, revenkodojn kaj personigojn por iuj el niaj klientoj.

Do, la lanĉo estis sukcesa! Kompreneble povus esti pli bona, sed ni eltiris konkludojn pri tio, kio ne sufiĉis por ke ni atingu perfektecon.

Tuta

Dum 2 monatoj da aktiva preparo por la lanĉo, 43 taskoj estis plenumitaj, daŭrantaj de kelkaj horoj ĝis pluraj tagoj.

Dum lanĉo:

• novaj kaj ŝanĝitaj demonoj - 5 pecoj, anstataŭante 2 monolitojn;
• ŝanĝoj en la datumbazoj - ĉiuj 6 niaj datumbazoj kun uzanto-datumoj estis tuŝitaj, elŝutoj estis faritaj de tri malnovaj datumbazoj al unu nova;
• tute restrukturita fasado;
• kvanto de elŝutita kodo - 33 mil linioj da nova kodo, ≈ 3 mil linioj da kodo en testoj, ≈ 5 mil linioj da migra kodo;
• ĉiuj datumoj estas sendifektaj, neniu virtuala maŝino de kliento estis difektita. 🙂

Bonaj praktikoj por bona disvastigo

Ili gvidis nin en ĉi tiu malfacila situacio. Sed, ĝenerale, estas utile sekvi ilin dum iu ajn lanĉo. Sed ju pli kompleksa estas la lanĉo, des pli granda estas la rolo ili ludas.

1. La unua afero, kiun vi devas fari, estas kompreni kiel la lanĉo povas aŭ influos uzantojn. Ĉu estos malfunkcio? Se jes, kio estas la malfunkcio? Kiel ĉi tio influos uzantojn? Kio estas la eblaj plej bonaj kaj plej malbonaj okazoj? Kaj kovri la riskojn.
2. Planu ĉion. En ĉiu etapo, vi devas kompreni ĉiujn aspektojn de lanĉo:
   • kodo livero;
   • kodo-returniĝo;
   • tempo de ĉiu operacio;
   • trafita funkcieco.
3. Ludu tra la scenaroj ĝis ĉiuj etapoj de la lanĉo, same kiel la riskoj ĉe ĉiu el ili, fariĝos evidentaj. Se vi havas dubojn, vi povas preni paŭzon kaj ekzameni la dubindan etapon aparte.
4. Ĉiu etapo povas kaj devas esti plibonigita se ĝi helpas niajn uzantojn. Ekzemple, ĝi reduktos malfunkcion aŭ forigos iujn riskojn.
5. Rollback-testado estas multe pli grava ol koda liverotestado. Necesas kontroli, ke kiel rezulto de la malfunkciigo la sistemo revenos al sia originala stato, kaj konfirmi tion per provoj.
6. Ĉio, kio povas esti aŭtomatigita, devus esti aŭtomatigita. Ĉio, kio ne povas esti aŭtomatigita, devus esti skribita anticipe sur trompfolio.
7. Registri la sukceskriterion. Kio funkcio devus esti disponebla kaj je kiu tempo? Se ĉi tio ne okazas, lanĉu rebonplanon.
8. Kaj plej grave - homoj. Ĉiuj devas konscii pri tio, kion ili faras, kial kaj kio dependas de siaj agoj en la procezo de lanĉo.

Kaj en unu frazo, kun bona planado kaj ellaboro vi povas elvolvi ion ajn, kion vi volas, sen konsekvencoj por vendoj. Eĉ io, kio influos ĉiujn viajn servojn en produktado.

fonto: www.habr.com