per 12f-2
A finals d'abril, mentre els White Walkers assetjaven Winterfell, ens va passar una cosa més interessant; vam fer un llançament inusual. En principi, estem constantment implementant noves funcions a la producció (com tothom). Però aquest era diferent. L'envergadura era tal que qualsevol possible error que poguéssim cometre afectaria tots els nostres serveis i usuaris. Com a resultat, vam desplegar tot segons el previst, dins del període d'inactivitat previst i anunciat, sense conseqüències per a les vendes. L'article tracta sobre com ho hem aconseguit i com qualsevol pot repetir-ho a casa.
Ara no descriuré les decisions arquitectòniques i tècniques que vam prendre ni explicaré com funciona tot. Són més aviat notes al marge sobre com es va produir un dels llançaments més difícils, que vaig observar i en el qual vaig participar directament. No reclamo la integritat ni els detalls tècnics; potser apareixeran en un altre article.
Fons + quin tipus de funcionalitat és aquesta?
Estem construint una plataforma al núvol (MCS), on treballo com a director tècnic. I ara és el moment d'afegir IAM (Gestió d'Identitats i Accés) a la nostra plataforma, que proporciona una gestió unificada de tots els comptes d'usuari, usuaris, contrasenyes, rols, serveis i molt més. Per què es necessita al núvol és una pregunta òbvia: tota la informació dels usuaris s'hi emmagatzema.
Normalment, aquestes coses comencen a construir-se al principi de qualsevol projecte. Però històricament les coses han estat una mica diferents a MCS. MCS es va construir en dues parts:
- Openstack amb el seu propi mòdul d'autorització Keystone,
- Hotbox (emmagatzematge S3) basat en el projecte Mail.ru Cloud,
al voltant del qual van aparèixer llavors nous serveis.
Bàsicament, es tractava de dos tipus diferents d'autorització. A més, vam utilitzar alguns desenvolupaments separats de Mail.ru, per exemple, l'emmagatzematge general de contrasenyes de Mail.ru, així com un connector d'identificació oberta escrit per si mateix, gràcies al qual es va proporcionar SSO (autorització d'extrem a extrem) al tauler Horizon. de màquines virtuals (interfície d'usuari nativa d'OpenStack).
Fer IAM per a nosaltres va significar connectar-ho tot en un únic sistema, completament nostre. Al mateix temps, no perdrem cap funcionalitat pel camí, sinó que crearem una base per al futur que ens permetrà refinar-la de manera transparent sense refactoritzar i escalar-la en termes de funcionalitat. També al principi, els usuaris tenien un model d'accés als serveis (RBAC central, control d'accés basat en rols) i algunes altres petites coses.
La tasca va resultar ser no trivial: python i perl, diversos backends, serveis escrits de manera independent, diversos equips de desenvolupament i administradors. I el més important, hi ha milers d'usuaris en directe al sistema de producció de combat. Tot això s'havia d'escriure i, sobretot, desplegar-lo sense víctimes.
Què anem a desplegar?
Per dir-ho molt aproximadament, en uns 4 mesos vam preparar el següent:
- Hem creat diversos dimonis nous que agregaven funcions que funcionaven anteriorment en diferents parts de la infraestructura. A la resta de serveis se'ls va prescriure un nou backend en forma d'aquests dimonis.
- Hem escrit el nostre propi emmagatzematge central de contrasenyes i claus, disponible per a tots els nostres serveis, que es pot modificar lliurement segons ho necessitim.
- Vam escriure 4 nous backends per a Keystone des de zero (usuaris, projectes, rols, assignacions de rols), que, de fet, van substituir la seva base de dades i ara actua com a repositori únic per a les contrasenyes dels nostres usuaris.
- Hem ensenyat a tots els nostres serveis Openstack a anar a un servei de polítiques de tercers per a les seves polítiques en lloc de llegir aquestes polítiques localment des de cada servidor (sí, així és com funciona Openstack per defecte!)
Una reelaboració tan important requereix canvis grans, complexos i, sobretot, sincrònics en diversos sistemes escrits per diferents equips de desenvolupament. Un cop muntat, tot el sistema hauria de funcionar.
Com implementar aquests canvis i no enfonsar-los? Primer vam decidir mirar una mica cap al futur.
Estratègia de desplegament
- Seria possible desplegar el producte en diverses etapes, però això augmentaria el temps de desenvolupament en tres vegades. A més, durant un temps tindríem una desincronització completa de les dades a les bases de dades. Hauríeu d'escriure les vostres pròpies eines de sincronització i viure amb diversos magatzems de dades durant molt de temps. I això crea una gran varietat de riscos.
- Tot el que es podia preparar de manera transparent per a l'usuari es va fer amb antelació. Va trigar 2 mesos.
- Ens vam permetre temps d'inactivitat durant diverses hores, només per a les operacions dels usuaris per crear i canviar recursos.
- Per al funcionament de tots els recursos ja creats, el temps d'inactivitat era inacceptable. Vam planificar que durant el llançament, els recursos haurien de funcionar sense temps d'inactivitat i afectar els clients.
- Per reduir l'impacte sobre els nostres clients si alguna cosa va malament, vam decidir llançar-lo diumenge al vespre. Menys clients gestionen màquines virtuals a la nit.
- Vam advertir a tots els nostres clients que durant el període seleccionat per al llançament, la gestió del servei no estarà disponible.
Digressió: què és un llançament?
<precaució, filosofia>
Cada especialista en TI pot respondre fàcilment què és un llançament. Instal·leu CI/CD i tot es lliura automàticament a la botiga. 🙂
Per descomptat, això és cert. Però la dificultat és que amb les eines modernes d'automatització de lliurament de codi, es perd la comprensió del desplegament en si. Com t'oblides de l'èpica de la invenció de la roda quan mires el transport modern. Tot està tan automatitzat que el desplegament sovint es porta a terme sense entendre tota la imatge.
I tota la imatge és així. El desplegament consta de quatre aspectes principals:
- Lliurament del codi, inclosa la modificació de dades. Per exemple, les seves migracions.
- La recuperació del codi és la capacitat de tornar enrere si alguna cosa va malament. Per exemple, mitjançant la creació de còpies de seguretat.
- Hora de cada operació de llançament/reversió. Heu d'entendre el temps de qualsevol operació dels dos primers punts.
- Funcionalitat afectada. Cal avaluar tant els efectes positius esperats com els possibles negatius.
Tots aquests aspectes s'han de tenir en compte per a un bon llançament. Normalment només s'avalua el primer punt, o en el millor dels casos el segon, i després el llançament es considera reeixit. Però el tercer i el quart són encara més importants. A quin usuari li agradaria que el llançament trigués 3 hores en lloc d'un minut? O si alguna cosa innecessària es veu afectada durant el llançament? O el temps d'inactivitat d'un servei comportarà conseqüències imprevisibles?
Acte 1..n, preparació per alliberament
Al principi vaig pensar en descriure breument les nostres reunions: tot l'equip, les seves parts, munts de discussions als punts de cafè, discussions, proves, pluja d'idees. Llavors vaig pensar que seria innecessari. Quatre mesos de desenvolupament sempre consisteixen en això, sobretot quan no esteu escrivint alguna cosa que es pugui lliurar constantment, sinó una gran característica per a un sistema en directe. La qual cosa afecta tots els serveis, però res hauria de canviar per als usuaris excepte "un botó a la interfície web".
La nostra comprensió de com s'ha de desplegar va canviar a partir de cada nova reunió, i de manera força significativa. Per exemple, anàvem a actualitzar tota la nostra base de dades de facturació. Però vam calcular el temps i ens vam adonar que era impossible fer-ho en un temps de llançament raonable. Vam trigar gairebé una setmana més a fragmentar i arxivar la base de dades de facturació. I quan la velocitat de llançament esperada encara no era satisfactòria, vam demanar maquinari addicional i més potent, on es va arrossegar tota la base. No és que no volguéssim fer-ho abans, però la necessitat actual de desplegar-nos ens va deixar sense opcions.
Quan un de nosaltres va tenir dubtes que el llançament podria afectar la disponibilitat de les nostres màquines virtuals, vam passar una setmana realitzant proves, experiments, anàlisi de codi i vam tenir una clara comprensió que això no passaria a la nostra producció, i fins i tot la gent més dubtosa va estar d'acord. amb aquest.
Mentrestant, els nois del suport tècnic van realitzar els seus propis experiments independents per escriure instruccions per als clients sobre els mètodes de connexió, que se suposa que haurien de canviar després del llançament. Van treballar en l'UX d'usuari, van preparar instruccions i van oferir consultes personals.
Hem automatitzat totes les operacions de desplegament possibles. Totes les operacions es van programar, fins i tot les més senzilles, i les proves s'executaven constantment. Van discutir sobre la millor manera de desactivar el servei: ometre el dimoni o bloquejar l'accés al servei amb un tallafoc. Hem creat una llista de comprovació d'equips per a cada etapa del llançament i l'hem actualitzat constantment. Vam dibuixar i actualitzar constantment un diagrama de Gantt per a tots els treballs de llançament, amb els horaris.
I així ...
L'acte final, abans de desplegar-se
... és hora de desplegar-se.
Com diuen, una obra d'art no es pot acabar, només s'ha acabat de treballar-la. Heu de fer un esforç de voluntat, entenent que no ho trobareu tot, però creient que heu fet totes les suposicions raonables, previst tots els casos possibles, tancat tots els errors crítics i tots els participants van fer tot el que van poder. Com més codi es desplega, més difícil serà convèncer-se d'això (a més, tothom entén que és impossible preveure-ho tot).
Vam decidir que estàvem preparats per llançar-nos quan estàvem convençuts que havíem fet tot el possible per cobrir tots els riscos per als nostres usuaris associats a afectacions i interrupcions inesperades. És a dir, qualsevol cosa pot sortir malament excepte:
- Afectar (sagrada per a nosaltres, més preuada) la infraestructura d'usuaris,
- Funcionalitat: l'ús del nostre servei després del llançament hauria de ser el mateix que abans.
Desplegant
Dues tirades, 8 no interfereixen
Prenem temps d'inactivitat per a totes les sol·licituds dels usuaris durant 7 hores. En aquest moment, tenim un pla de llançament i un pla de retrocés.
- El llançament en si triga unes 3 hores.
- 2 hores per a la prova.
- 2 hores: reserva per a una possible revocació dels canvis.
S'ha elaborat un diagrama de Gantt per a cada acció, quant de temps triga, què passa de manera seqüencial, què es fa en paral·lel.
Una peça d'un diagrama de Gantt desplegable, una de les primeres versions (sense execució paral·lela). L'eina de sincronització més valuosa
Tots els participants tenen el seu paper en el desplegament determinat, quines tasques fan i de què són responsables. Intentem portar cada etapa a l'automaticitat, desplegar-la, tornar-la a fer, recollir comentaris i tornar-la a desplegar.
Crònica dels fets
Així, 15 persones van venir a treballar el diumenge 29 d'abril a les 10h. A més dels participants clau, alguns van venir simplement per donar suport a l'equip, per la qual cosa els agraïm especialment.
També val la pena esmentar que el nostre tester clau està de vacances. És impossible implementar sense provar, estem explorant opcions. Una companya accepta posar-nos a prova des de les vacances, per la qual cosa rep un immens agraïment de tot l'equip.
00:00. Atura
Aturem les sol·licituds dels usuaris, pengem un cartell que diu treball tècnic. El seguiment crida, però tot és normal. Comprovem que no ha caigut res més que el que havia de caure. I comencem a treballar sobre la migració.
Tothom té un pla de desplegament imprès punt per punt, tothom sap qui fa què i en quin moment. Després de cada acció, comprovem els horaris per assegurar-nos que no els superem i tot va segons el previst. Els que no participen directament en el desplegament en l'etapa actual es preparen llançant una joguina en línia (Xonotic, charlatanes tipus 3) per no molestar els seus companys. 🙂
02:00. Desplegat
Una agradable sorpresa: acabem el llançament una hora abans, a causa de l'optimització de les nostres bases de dades i scripts de migració. El crit general, "desplegat!" Totes les funcions noves estan en producció, però fins ara només les podem veure a la interfície. Tothom passa al mode de prova, els classifica en grups i al final comença a veure què ha passat.
No va sortir gaire bé, ens n'adonem al cap de 10 minuts, quan no hi ha res connectat ni treballat en els projectes dels membres de l'equip. Sincronització ràpida, expressem els nostres problemes, establim prioritats, formem equips i entrem en depuració.
02:30. Dos grans problemes contra quatre ulls
Trobem dos grans problemes. Ens vam adonar que els clients no veurien alguns serveis connectats i que sorgirien problemes amb els comptes de socis. Tots dos són deguts a scripts de migració imperfectes per a alguns casos extrems. Hem d'arreglar-ho ara.
Escrivim consultes que ho registren, amb almenys 4 ulls. Els provem durant la preproducció per assegurar-nos que funcionen i que no trenquin res. Podeu rodar més enllà. Al mateix temps, fem les nostres proves d'integració habituals, que revela alguns problemes més. Tots són petits, però també s'han de reparar.
03:00. -2 problemes +2 problemes
S'han solucionat els dos grans problemes anteriors, i gairebé tots els menors també. Tots els que estan desocupats a les solucions estan treballant activament als seus comptes i informant del que troben. Prioritzem, distribuïm entre equips i deixem articles no crítics per al matí.
Tornem a fer les proves, descobreixen dos nous grans problemes. No totes les polítiques de servei han arribat correctament, de manera que algunes sol·licituds dels usuaris no passen l'autorització. A més d'un nou problema amb els comptes de socis. Afanyem-nos a mirar.
03:20. Sincronització d'emergència
S'ha solucionat un problema nou. Per al segon, estem organitzant una sincronització d'emergència. Entenem què està passant: la solució anterior va solucionar un problema, però en va crear un altre. Fem una pausa per descobrir com fer-ho correctament i sense conseqüències.
03:30. Sis ulls
Entenem quin ha de ser l'estat final de la base perquè tot surti bé per a tots els socis. Escrivim una sol·licitud amb 6 ulls, la desenvolupem en preproducció, la provem, la distribuïm per a la producció.
04:00. Tot funciona
Totes les proves superades, no hi ha problemes crítics visibles. De tant en tant, alguna cosa a l'equip no funciona per a algú, reaccionem ràpidament. Molt sovint l'alarma és falsa. Però de vegades alguna cosa no arriba, o una pàgina a part no funciona. Ens asseiem, arreglem, arreglem, arreglem. Un equip independent està llançant la darrera gran funció: la facturació.
04:30. Punt de no retorn
S'acosta el punt de no retorn, és a dir, el moment en què, si comencem a retrocedir, no trobarem el temps d'inactivitat que se'ns ha donat. Hi ha problemes amb la facturació, que ho sap i ho registra tot, però es nega obstinadament a cancel·lar els diners dels clients. Hi ha diversos errors en pàgines, accions i estats individuals. La funcionalitat principal funciona, totes les proves passen amb èxit. Decidim que el llançament s'ha produït, no tornarem enrere.
06:00. Obert per a tothom a la IU
Errors corregits. Algunes que no atreuen als usuaris es deixen per a més endavant. Obrim la interfície a tothom. Continuem treballant en la facturació, esperant els comentaris dels usuaris i els resultats del seguiment.
07:00. Problemes amb la càrrega de l'API
Queda clar que vam planificar una mica malament la càrrega de la nostra API i vam provar aquesta càrrega, que no va poder identificar el problema. Com a resultat, ≈5% de les sol·licituds fracassen. Mobilitzem-nos i busquem el motiu.
La facturació és tossuda i tampoc vol funcionar. Decidim ajornar-ho per més endavant per poder dur a terme els canvis amb calma. És a dir, tots els recursos s'acumulen en ella, però les cancel·lacions dels clients no passen. Per descomptat, això és un problema, però en comparació amb el llançament general sembla poc important.
08:00. Arregla l'API
Vam llançar una solució per a la càrrega, les fallades van desaparèixer. Comencem a anar a casa.
10:00. Tots
Tot està arreglat. És tranquil en el seguiment i al lloc dels clients, l'equip es va a dormir a poc a poc. La facturació es manté, demà la restablirem.
Després, durant el dia, hi va haver llançaments que arreglaven registres, notificacions, codis de retorn i personalitzacions per a alguns dels nostres clients.
Així doncs, el llançament va ser un èxit! Podria, per descomptat, ser millor, però vam treure conclusions sobre allò que no ens va ser suficient per aconseguir la perfecció.
En total
Durant 2 mesos de preparació activa per al desplegament, es van completar 43 tasques, amb una durada des d'un parell d'hores fins a diversos dies.
Durant el llançament:
- dimonis nous i canviats: 5 peces, substituint 2 monòlits;
- canvis dins de les bases de dades: les 6 bases de dades nostres amb dades d'usuari s'han vist afectades, s'han fet descàrregues de tres bases de dades antigues a una de nova;
- interfície completament redissenyada;
- quantitat de codi descarregat: 33 mil línies de codi nou, ≈ 3 mil línies de codi en proves, ≈ 5 mil línies de codi de migració;
- totes les dades estan intactes, no s'ha fet malbé la màquina virtual d'un sol client. 🙂
Bones pràctiques per a un bon desplegament
Ens van guiar en aquesta difícil situació. Però, en general, és útil seguir-los durant qualsevol llançament. Però com més complex és el desplegament, més gran és el paper que tenen.
- El primer que heu de fer és entendre com el llançament pot o afectarà els usuaris. Hi haurà temps d'inactivitat? Si és així, quin és el temps d'inactivitat? Com afectarà això als usuaris? Quins són els millors i pitjors escenaris possibles? I cobrir els riscos.
- Planifica-ho tot. En cada etapa, heu d'entendre tots els aspectes del llançament:
- lliurament del codi;
- retrocés de codi;
- temps de cada operació;
- funcionalitat afectada.
- Juga a través dels escenaris fins que totes les etapes del llançament, així com els riscos de cadascun d'ells, es facin evidents. Si teniu cap dubte, podeu fer una pausa i examinar l'etapa qüestionable per separat.
- Cada etapa pot i s'ha de millorar si ajuda als nostres usuaris. Per exemple, reduirà el temps d'inactivitat o eliminarà alguns riscos.
- Les proves de retrocés són molt més importants que les proves de lliurament de codi. Cal comprovar que com a resultat de la recuperació el sistema tornarà al seu estat original i confirmar-ho amb proves.
- Tot el que es pot automatitzar s'hauria d'automatitzar. Tot el que no es pot automatitzar s'ha d'escriure per endavant en un full de trucs.
- Anoteu el criteri d'èxit. Quina funcionalitat hauria d'estar disponible i a quina hora? Si això no passa, executeu un pla de retrocés.
- I el més important: persones. Tothom ha de ser conscient del que està fent, per què i què depèn de les seves accions en el procés de llançament.
I en una frase, amb una bona planificació i elaboració pots desplegar el que vulguis sense conseqüències per a les vendes. Fins i tot una cosa que afectarà tots els vostres serveis en producció.
Font: www.habr.com