bi 12f-2
Di dawiya Nîsanê de, dema ku White Walkers Winterfell dorpêç kiribûn, tiştek balkêştir hat serê me; me pêvekek neasayî kir. Di prensîbê de, em bi domdarî taybetmendiyên nû di hilberînê de derdixin (wek her kesê din). Lê ev yek cuda bû. Pîvana wê wusa bû ku her xeletiyên potansiyel ên ku em dikarin bikin dê bandorê li hemî karûbar û bikarhênerên me bike. Wekî encamek, me her tişt li gorî plansaziyê, di nav heyama domdar a plansazkirî û ragihandî de, bêyî encamên firotanê derxist. Gotar li ser vê yekê ye ku me çawa bi dest xist û meriv çawa dikare wê li malê dubare bike.
Ez ê naha biryarên mîmarî û teknîkî yên ku me dane vebêjim an nabêjim ka ew hemî çawa dixebite. Vana bi hûrgulî notên di perdeyan de ne li ser ka çawa yek ji pêşandanên herî dijwar pêk hat, ku min dît û ez rasterast tê de beşdar bûm. Ez bi tevahî an hûrguliyên teknîkî îdîa nakim; dibe ku ew ê di gotarek din de xuya bibin.
Paşnav + ev çi celeb fonksiyon e?
Em platformek ewr ava dikin (MCS), ku ez wekî derhênerê teknîkî dixebitim. Û naha ew dem e ku em IAM (Rêveberiya Nasname û Gihîştinê) li platforma xwe zêde bikin, ku rêveberiya yekgirtî ya hemî hesabên bikarhêner, bikarhêner, şîfre, rol, karûbar û hêj bêtir peyda dike. Çima ew di ewr de hewce ye pirsek eşkere ye: hemî agahdariya bikarhêner di wê de têne hilanîn.
Bi gelemperî tiştên weha di destpêka her projeyan de têne çêkirin. Lê ji hêla dîrokî ve tişt di MCS de hinekî cûda bûne. MCS di du beşan de hate çêkirin:
- Openstack bi modula xweya destûrnameyê Keystone,
- Hotbox (hilanînê S3) li ser bingeha projeya Mail.ru Cloud,
li dora ku xizmetên nû paşê xuya bûn.
Di bingeh de, ev du celebên destûrnameyê bûn. Zêdetir, me hin pêşkeftinên cihêreng ên Mail.ru bikar anîn, mînakî, hilanînek şîfreyek giştî ya Mail.ru, û her weha girêdanek vekirî-xwe-nivîskî, bi saya ku SSO (destûrdana dawî-bi-dawî) di panela Horizon de hate peyda kirin. ji makîneyên virtual (ApenStack UI xwecî).
Çêkirina IAM-ê ji bo me tê wateya girêdana wê hemî bi pergalek yekane, bi tevahî ya me. Di heman demê de, em ê di rê de tu fonksiyonek winda nekin, lê dê bingehek ji bo pêşerojê biafirînin ku dê bihêle ku em bi zelalî bêyî verastkirin û pîvandina wê di warê fonksiyonê de bi rengek zelal safî bikin. Di heman demê de di destpêkê de, bikarhêneran ji bo gihîştina karûbaran (RBAC navendî, kontrola gihîştina-based rol) û hin tiştên piçûk ên din modelek rolê hebûn.
Karûbar derket holê ku ne-tayî ye: python û perl, gelek paşverû, karûbarên serbixwe yên nivîskî, gelek tîmên pêşkeftinê û rêvebiran. Û ya herî girîng, bi hezaran bikarhênerên zindî li ser pergala hilberîna şer hene. Diviyabû ev hemû bihatana nivîsandin û ya herî girîng jî, bêyî kuştî bihatana derxistin.
Em ê çi derxin holê?
Ji bo ku em bi kurtî bêjin, di nav 4 mehan de me ev amade kir:
- Me gelek şeytanên nû afirandin ku fonksiyonên ku berê li beşên cihêreng ên binesaziyê dixebitîn berhev kirin. Karûbarên mayî di forma van cinan de paşverûyek nû hate destnîşan kirin.
- Me depoya xweya navendî ya şîfre û kilîtan nivîsî, ku ji bo hemî karûbarên me peyda dibe, ku li gorî hewcedariya me dikare bi serbestî were guheztin.
- Me 4 paşnavên nû ji bo Keystone ji sifrê nivîsand (bikarhêner, proje, rol, peywirên rolê), ku, bi rastî, databasa wê guherand, û naha ji bo şîfreyên bikarhênerê me wekî depoyek yekane tevdigere.
- Me hemî karûbarên xwe yên Openstack fêr kir ku ji bo polîtîkayên xwe li şûna xwendina van polîtîkayan li herêmî ji her serverê biçin servîsa polîtîkaya partiya sêyemîn (erê, bi vî rengî Openstack ji hêla xwerû ve dixebite!)
Ji nûvekirinek wusa mezin hewceyê guheztinên mezin, tevlihev û, ya herî girîng, hevdemî di gelek pergalên ku ji hêla tîmên pêşkeftinê yên cihêreng ve hatine nivîsandin de hewce dike. Dema ku kom kirin, divê tevahiya pergalê bixebite.
Meriv çawa guheztinên bi vî rengî pêk tîne û wê qut neke? Pêşî me biryar da ku em hinekî li pêşerojê binêrin.
Stratejiya Rollout
- Dê gengaz be ku hilberê di çend qonaxan de were derxistin, lê ev ê dema pêşveçûnê sê caran zêde bike. Wekî din, ji bo demek me dê di databasan de desenkronîzekirina bêkêmasî ya daneyan hebe. Pêdivî ye ku hûn amûrên hevdengkirina xwe binivîsin û ji bo demek dirêj bi gelek firotgehên daneyê re bijîn. Û ev cûrbecûr xetereyan diafirîne.
- Her tiştê ku dikaribû bi zelalî ji bikarhêner re were amadekirin, ji berê ve hate kirin. 2 meh girt.
- Me destûr da ku çend demjimêran domdariya xwe bide - tenê ji bo operasyonên bikarhêner ku çavkaniyan biafirînin û biguhezînin.
- Ji bo xebitandina hemî çavkaniyên ku jixwe hatine afirandin, dema daketinê nayê qebûl kirin. Me plan kir ku di dema danasînê de, pêdivî ye ku çavkanî bêyî demdirêj bixebitin û bandorê li ser xerîdaran bikin.
- Ji bo kêmkirina bandorê li ser xerîdarên me heke tiştek xelet derkeve, me biryar da ku êvara Yekşemê derxînin. Kêm xerîdar bi şev makîneyên virtual îdare dikin.
- Me hişyarî da hemî xerîdarên xwe ku di heyama ku ji bo danasînê hatî hilbijartin de, rêveberiya karûbarê dê ne berdest be.
Digression: rollout çi ye?
<hişyarî, felsefe>
Her pisporê IT-ê dikare bi hêsanî bersivê bide ka pêvek çi ye. Hûn CI/CD saz dikin, û her tişt bixweber ji firotgehê re tê radest kirin. 🙂
Helbet ev rast e. Lê dijwarî ev e ku bi amûrên otomatîkî yên radestkirina kodê ya nûjen re, têgihîştina vesazkirinê bixwe winda dibe. Gava ku hûn li veguheztina nûjen dinêrin hûn çawa epîkbûna dahênana çerxê ji bîr dikin. Her tişt ew qas otomatîkî ye ku pêvekirin bi gelemperî bêyî têgihîştina tevahî wêneyê tête kirin.
Û tevahî wêne bi vî rengî ye. Rollout ji çar aliyên sereke pêk tê:
- Radestkirina kodê, tevî guhartina daneyê. Mînak koçkirina wan.
- Vegerandina kodê şiyana vegerê ye ger tiştek xelet derkeve. Mînakî, bi afirandina hilanînê.
- Demjimêra her operasiyona avêtinê/vegerandinê. Pêdivî ye ku hûn dema her operasyonê ya her du xalên yekem fam bikin.
- Fonksiyona bandorkirî. Pêdivî ye ku hem bandorên erênî yên hêvîdar û hem jî yên neyînî yên gengaz binirxînin.
Pêdivî ye ku hemî van aliyan ji bo pêşkeftinek serketî bêne hesibandin. Bi gelemperî tenê xala yekem, an ya herî çêtirîn xala duyemîn tê nirxandin, û dûv re danasîna serketî tê hesibandin. Lê ya sêyemîn û çarem hê girîngtir in. Kîjan bikarhêner wê jê hez dike ku li şûna deqeyek 3 demjimêran bigire? An jî heke tiştek nepêwist di dema danasînê de bandor bibe? An jî dê domdariya yek karûbar bibe sedema encamên nediyar?
Qanûna 1..n, amadekirina berdanê
Di destpêkê de min fikir kir ku ez bi kurtî civînên me vebêjim: tevahiya tîmê, beşên wê, girseyên nîqaşên li ser xalên qehweyê, nîqaş, ceribandin, bahozên mêjî. Hingê min fikirîn ku ew ê nepêwist be. Çar mehên pêşkeftinê her gav ji vê yekê pêk tê, nemaze gava ku hûn ne tiştek ku bi domdarî were radest kirin dinivîsin, lê yek taybetmendiyek mezin ji bo pergalek zindî. Ku bandorê li ser hemî karûbaran dike, lê divê ji bo bikarhêneran tiştek neyê guheztin ji bilî "yek bişkokek di navgîniya malperê de."
Têgihîştina me ya ku meriv çawa derdixe ji her civînek nû, û pir girîng guherî. Mînakî, em ê hemî databasa fatûreya xwe nûve bikin. Lê me dem hesab kir û fêhm kir ku di demek maqûl de ne gengaz e ku em vê yekê bikin. Hema hema hefteyek zêde ji me re girt ku em databasa fatûreyê perçe bikin û arşîv bikin. Û gava ku leza pêşkeftina hêvîkirî hîn jî ne têrker bû, me ferman da nermalava pêvek, bihêztir, ku li wir tevaya bingehê hat kişandin. Ne ev e ku me nexwest ku zû zû vê yekê bikin, lê hewcedariya heyî ya ku em bişopînin bê vebijark hişt.
Gava ku yekî ji me guman kir ku vedan dikare bandorê li hebûna makîneyên meyên virtual bike, me hefteyek ceribandin, ceribandin, analîza kodê derbas kir û têgihîştinek zelal stend ku ev ê di hilberîna me de çênebe, û tewra mirovên herî gumanbar razî bûn. bi vê.
Di vê navberê de, xortên ji piştgiriya teknîkî ceribandinên xwe yên serbixwe pêk anîn da ku ji bo xerîdaran rêwerzên li ser awayên girêdanê binivîsin, yên ku diviyabû piştî derketinê biguhezin. Wan li ser bikarhêner UX xebitîn, rêwerzan amade kirin û şêwirdariyên kesane peyda kirin.
Me hemî operasyonên danasînê yên ku mimkun bûn otomatîk kirin. Her operasyon hat nivîsandin, tewra yên herî hêsan jî, û ceribandin bi domdarî dihatin meşandin. Wan li ser awayê çêtirîn ku karûbarê qut bike nîqaş kirin - dev ji daemonê berdin an gihîştina karûbarê bi dîwarê agir ve asteng bikin. Me ji bo her qonaxa danasînê navnîşek kontrolê ya tîmê çêkir û bi domdarî nûve kir. Me nexşeyek Gantt-ê ji bo hemî xebata danasînê, digel demjimêran, xêz kir û bi domdarî nû kir.
So wiha…
Çalakiya dawîn, berî ku derkeve holê
...ew dem hatiye.
Weke ku dibêjin, karek hunerî nayê qedandin, tenê xebata li ser qedandiye. Pêdivî ye ku hûn hewildanek îrade bikin, fêm bikin ku hûn ê her tiştî nebînin, lê bawer bikin ku we hemî texmînên maqûl kirine, ji bo hemî dozên gengaz peyda kirine, hemî xeletiyên krîtîk girtine, û hemî beşdaran her tiştê ku ji destê wan hat kirin kirin. Her ku hûn bêtir kodê derxînin, ew qas dijwartir e ku hûn xwe bi vê yekê qane bikin (ji bilî vê, her kes fam dike ku ne gengaz e ku meriv her tiştî pêşbîn bike).
Me biryar da ku dema ku em pê bawer bûn ku me her tiştê gengaz kiriye da ku hemî xetereyên ji bo bikarhênerên xwe yên ku bi bandorên neçaverêkirî û demên daketinê ve girêdayî ne veşêrin, me biryar da ku em amade bibin. Ango, ji bilî:
- Binesaziya bikarhêner (ji me re pîroz, herî hêja) bandor bike,
- Fonksiyonî: Divê karanîna karûbarê me piştî hilanînê wekî berê be.
Rolling out
Du roll, 8 mudaxele nekin
Em ji bo hemî daxwazên bikarhêneran 7 demjimêran wextê dakêşanê digirin. Di vê demê de, me hem plansaziyek veguheztinê û hem jî plansaziyek vegerê heye.
- Veguhastina xwe bi qasî 3 demjimêran digire.
- 2 saet ji bo ceribandinê.
- 2 demjimêr - ji bo vegerandina gengaz a guhertinan rezerv bikin.
Ji bo her çalakiyê nexşeyek Gantt hatîye çêkirin, ew çiqas dirêj dibe, bi rêzê çi diqewime, çi bi paralelî tê kirin.
Parçeyek nexşeyek Gantt-ê, yek ji guhertoyên pêşîn (bêyî darvekirina paralel). Amûra Hevdemkirinê ya Herî Biha
Hemî beşdaran rola wan di pêşandanê de diyar e, ka ew çi karan dikin, û ji bo çi berpirsiyar in. Em hewl didin ku her qonaxê bigihînin otomotîkbûnê, wê derxînin, paşde vegerînin, bertekan berhev bikin û dîsa derxînin holê.
Kronîka bûyeran
Ji ber vê yekê 15ê Nîsanê roja Yekşemê saet 29:10 XNUMX kes hatin ser kar. Ji bilî beşdarên sereke, hin kes bi tenê hatin ku piştgiriyê bidin tîmê, ji ber vê yekê spas taybetî ji wan re.
Di heman demê de hêjayî gotinê ye ku testerê meya sereke di betlaneyê de ye. Ne gengaz e ku meriv bêyî ceribandinê derbikeve, em vebijarkan lêkolîn dikin. Hevalek razî ye ku me ji betlaneyê biceribîne, ji bo vê yekê ew ji tevahiya tîmê spasiyek mezin distîne.
00:00. Rawestan
Em daxwazên bikarhêneran rawestînin, nîşanek ku dibêje xebata teknîkî daliqînin. Çavdêr diqîre, lê her tişt normal e. Em kontrol dikin ku ji bilî tiştê ku diviyabû bikeve tiştek neketiye. Û em dest bi xebata koçberiyê dikin.
Her kes xwedan plansaziyek çapkirî ye xal bi xal, her kes dizane kî çi dike û di kîjan kêliyê de dike. Piştî her çalakiyê, em demjimêran kontrol dikin da ku em ji wan derbas nebin, û her tişt li gorî plansaziyê diçe. Kesên ku di qonaxa heyî de rasterast beşdarî lîstokê nabin, bi destpêkirina pêlîstokek serhêl (Xonotic, tîp 3 quacks) xwe amade dikin da ku hevkarên xwe aciz nekin. 🙂
02:00. Derxistin
Surprîzek xweş - ji ber xweşbînkirina databasên me û nivîsarên koçberiyê, em demjimêrek berê pêşandanê diqedînin. Qîrîna giştî, "derket!" Hemî fonksiyonên nû di hilberînê de ne, lê heya nuha tenê em dikarin wan di navberê de bibînin. Her kes diçe moda ceribandinê, wan di nav koman de dabeş dike, û dest pê dike ku bibîne ka di dawiyê de çi qewimî.
Ew pir baş derneket, em vê yekê piştî 10 hûrdeman fam dikin, dema ku tiştek di projeyên endamên tîmê de ne girêdayî ye an jî dixebite. Hevdengkirina bilez, em pirsgirêkên xwe deng dikin, pêşanîn destnîşan dikin, di tîmê de vediqetin û dikevin xeletiyê.
02:30. Du pirsgirêkên mezin li hember çar çavan
Em du pirsgirêkên mezin dibînin. Me fêm kir ku xerîdar dê hin karûbarên girêdayî nebînin, û dê pirsgirêk bi hesabên hevkar re derkevin. Her du jî ji ber nivîsarên koçberiyê yên bêkêmasî yên ji bo hin dozên devê ne. Divê em niha rast bikin.
Em pirsên ku vê tomar dikin, bi kêmî ve 4 çavan dinivîsin. Em wan di dema pêş-hilberînê de diceribînin da ku pê ewle bin ku ew dixebitin û tiştek naşkînin. Hûn dikarin bêtir bizivirin. Di heman demê de, em ceribandina xweya entegrasyonê ya birêkûpêk dimeşînin, ku çend pirsgirêkên din eşkere dike. Ew hemî piçûk in, lê ew jî hewce ne ku bêne tamîr kirin.
03:00. -2 pirsgirêk +2 pirsgirêk
Du pirsgirêkên mezin ên berê hatine rast kirin, û hema hema hemî piçûk jî. Hemî kesên ku di sererastkirinê de ne mijûl in bi awayekî çalak di hesabên xwe de dixebitin û tiştê ku dibînin radigihînin. Em pêşî didin, di nav tîman de belav dikin, û tiştên ne-krîtîk ji bo sibehê dihêlin.
Em dîsa ceribandinan dimeşînin, ew du pirsgirêkên mezin ên nû kifş dikin. Hemî polîtîkayên karûbarê rast nehatine, ji ber vê yekê hin daxwazên bikarhêner destûrnameyê derbas nakin. Zêdetir pirsgirêkek nû bi hesabên hevalbendan re. Werin em bi lez lê bigerin.
03:20. Hevdemkirina acîl
Pirsgirêkek nû hate çareser kirin. Ji bo ya duyemîn, em hevdemek acîl organîze dikin. Em fêm dikin ka çi diqewime: Çareserkirina berê pirsgirêkek rast kir, lê yekî din çêkir. Em navberekê digirin da ku fêr bibin ka meriv çawa wiya rast û bê encam dike.
03:30. Şeş çav
Em fêm dikin ku divê rewşa dawî ya bingehê çi be da ku her tişt ji bo hemî hevalbendan baş bibe. Em daxwazek bi 6 çavan dinivîsin, wê di pêş-hilberînê de derxînin, ceribandinê bikin, ji bo hilberînê derxînin.
04:00. Her tişt dixebite
Hemî ceribandin derbas bûn, ti pirsgirêkên krîtîk nayên dîtin. Dem bi dem, tiştek di tîmê de ji bo kesek naxebite, em tavilê bertek nîşan didin. Pir caran alarm derew e. Lê carinan tiştek nagihîje, an rûpelek cûda naxebite. Em rûniştin, rast bikin, rast bikin, rast bikin. Tîmek cihêreng taybetmendiya mezin a paşîn dest pê dike - billing.
04:30. Xala bê vegerê
Xala bêveger nêzîk dibe, ango wexta ku, ger em dest bi paşvekişînê bikin, em ê bi wextê ku ji me re hatî dayîn re hevdîtin nekin. Pirsgirêkên fatûreyê hene, ku her tiştî dizane û tomar dike, lê bi serhişkî red dike ku drav ji xerîdar binivîsîne. Li ser rûpel, çalakî û statûyan çend xeletî hene. Karbidestiya sereke dixebite, hemî ceribandin bi serfirazî derbas dibin. Em biryar didin ku vegerandin pêk hat, em ê paşde venegerin.
06:00. Ji bo her kesê di UI de vekin
Bugs rast kirin. Hin ku ji bikarhêneran re ne balkêş in ji bo paşê têne hiştin. Em pêwendiyê ji her kesî re vedikin. Em xebata li ser fatûreyê didomînin, li benda nerînên bikarhêner û encamên şopandinê ne.
07:00. Pirsgirêkên bi barkirina API-ê
Eşkere dibe ku me barkirina li ser API-ya xwe hinekî xelet plan kir û vê barkirinê ceriband, ku nekarî pirsgirêkê nas bike. Wekî encamek, ≈5% daxwazan têk diçin. Em seferber bibin û li sedemê bigerin.
Billing serhişk e û naxwaze bixebite jî. Em biryar didin ku ji bo ku guhertinan bi rengekî aram pêk bînin, wê paşve bidin paş. Ango, hemî çavkanî tê de têne berhev kirin, lê nivîsandina ji xerîdaran derbas nabe. Bê guman, ev pirsgirêkek e, lê li gorî pêşandana gelemperî ew ne girîng xuya dike.
08:00. API-ê rast bikin
Me ji bo barkirinê çareseriyek derxist, têkçûn çûn. Em dest bi çûna malê dikin.
10:00. Gişt
Her tişt sabît e. Di çavdêriyê de bêdeng e û li cîhê xerîdar, tîmê hêdî hêdî diçe xewê. Billing dimîne, em ê sibê restore bikin.
Dûv re di nav rojê de serpêhatî hebûn ku ji bo hin xerîdarên me têketin, agahdarî, kodên vegerê û xwerû rast kirin.
Ji ber vê yekê, pêşandan serketî bû! Dikaribû, bê guman, çêtir be, lê me encam derxist li ser tiştê ku ne bes e ku em bigihîjin kamilbûnê.
Tevahî
Di nav 2 mehên amadekariya çalak a ji bo lîsteyê de, 43 peywir hatin qedandin, ku ji du saetan heya çend rojan dom kir.
Di dema belavkirinê de:
- cinên nû û guherî - 5 perçe, li şûna 2 monolîtan;
- Guhertinên di nav databasan de - her 6 databasên me yên bi daneyên bikarhêner bandor bûne, dakêşan ji sê databasên kevn hatine yek nû;
- eniya bi tevahî ji nû ve hatî sêwirandin;
- hejmara koda dakêşandî - 33 hezar rêzikên koda nû, ≈ 3 hezar rêzikên kodê di ceribandinan de, ≈ 5 hezar rêzikên koda koçberiyê;
- hemî dane saxlem in, ne makîneya virtual ya yek xerîdar zirarê nekiriye. 🙂
Pratîkên baş ên ji bo derxistina baş
Di vê rewşa dijwar de me rêberî kirin. Lê, bi gelemperî dipeyivin, kêrhatî ye ku meriv wan di dema her pêşkeftinê de bişopîne. Lê pêvek çiqas tevlihevtir be, rola wan ew qas mezin dibe.
- Yekem tiştê ku hûn hewce ne bikin ev e ku hûn fêm bikin ka pêvek çawa dikare bandorê li bikarhêneran bike an dê bandor bike. Dê demdirêj hebe? Ger wusa be, dema domandinê çi ye? Ev ê çawa bandorê li bikarhêneran bike? Senaryoyên çêtirîn û herî xirab ên gengaz çi ne? Û rîskan veşêre.
- Her tiştî plan bikin. Di her qonaxê de, hûn hewce ne ku hûn hemî aliyên pêvekirinê fam bikin:
- şandina kodê;
- vegerandina kodê;
- dema her operasyonê;
- fonksiyonê bandor kir.
- Di nav senaryoyan de lîstin heya ku hemî qonaxên pêvekirinê, û her weha xetereyên li ser her yek ji wan eşkere bibin. Ger gumanên we hebin, hûn dikarin navberê bidin û qonaxa gumanbar ji hev veqetînin.
- Ger ew ji bikarhênerên me re bibe alîkar dikare û divê her qonax were çêtir kirin. Mînakî, ew ê dema domandinê kêm bike an hin xetereyan rake.
- Testkirina paşvekêşanê ji ceribandina radestkirina kodê pir girîngtir e. Pêdivî ye ku were kontrol kirin ku di encama vegerê de dê pergal vegere rewşa xweya bingehîn, û vê yekê bi ceribandinan piştrast bike.
- Her tiştê ku dikare bixweber bibe divê bixweber be. Her tiştê ku nekare otomatîk be divê pêşwext li ser kaxezek xapandinê were nivîsandin.
- Pîvana serkeftinê tomar bikin. Divê kîjan fonksiyon û di kîjan demê de hebe? Ger ev yek pêk neyê, planek paşvekêşanê bimeşînin.
- Û ya herî girîng - mirov. Divê her kes hay jê hebe ku ew çi dikin, çima û çi bi kirinên wan ve girêdayî ye ku di pêvajoya pêşandanê de.
Û di yek hevokê de, bi plansazkirin û berfirehkirina baş hûn dikarin her tiştê ku hûn dixwazin bêyî encamên firotanê derxînin holê. Tewra tiştek ku dê bandorê li hemî karûbarên we di hilberînê de bike.
Source: www.habr.com