IzklāŔanas stāsts, kas ietekmēja visu

IzklāŔanas stāsts, kas ietekmēja visu
Realitātes ienaidnieki līdz 12f-2

Aprīļa beigās, kamēr White Walkers aplenca Vinterfelu, ar mums notika kas interesantāks, mēs veicām neparastu izskrējienu. Principā mēs nepārtraukti ievieÅ”am jaunas funkcijas ražoÅ”anā (tāpat kā visi citi). Bet Å”is bija savādāks. Tā mērogs bija tāds, ka visas iespējamās kļūdas, kuras mēs varētu pieļaut, ietekmētu visus mÅ«su pakalpojumus un lietotājus. Rezultātā visu izskrējām pēc plāna, plānotajā un izsludinātajā dÄ«kstāves periodā, bez sekām pārdoÅ”anai. Raksts ir par to, kā mēs to panācām un kā ikviens to var atkārtot mājās.

Es tagad neaprakstÄ«Å”u mÅ«su pieņemtos arhitektoniskos un tehniskos lēmumus un nestāstÄ«Å”u, kā tas viss darbojas. Tās drÄ«zāk ir piezÄ«mes malās par to, kā notika viens no grÅ«tākajiem izlaiÅ”anas gadÄ«jumiem, ko novēroju un kurā es tieÅ”i piedalÄ«jos. Es nepretendēju uz pilnÄ«gumu vai tehniskām detaļām; iespējams, tie parādÄ«sies citā rakstā.

Fons + kāda veida funkcionalitāte ir Ŕī?

Mēs veidojam mākoņa platformu Mail.ru mākoņa risinājumi (MCS), kur strādāju par tehnisko direktoru. Un tagad ir pienācis laiks mÅ«su platformai pievienot IAM (Identity and Access Management), kas nodroÅ”ina vienotu visu lietotāju kontu, lietotāju, paroļu, lomu, pakalpojumu un citu pārvaldÄ«bu. Kāpēc tas ir nepiecieÅ”ams mākonÄ«, ir acÄ«mredzams jautājums: visa lietotāja informācija tiek glabāta tajā.

Parasti Ŕādas lietas sāk bÅ«vēt jebkura projekta paŔā sākumā. Bet vēsturiski lietas MCS ir bijuÅ”as nedaudz atŔķirÄ«gas. MCS tika uzbÅ«vēts divās daļās:

  • Openstack ar savu Keystone autorizācijas moduli,
  • Hotbox (S3 krātuve), pamatojoties uz Mail.ru Cloud projektu,

ap kuru pēc tam parādījās jauni pakalpojumi.

BÅ«tÄ«bā tie bija divi dažādi atļauju veidi. Turklāt mēs izmantojām dažas atseviŔķas Mail.ru izstrādes, piemēram, vispārējo Mail.ru paroļu krātuvi, kā arÄ« paÅ”rakstÄ«tu atvērto savienotāju, pateicoties kuriem panelÄ« Horizon tika nodroÅ”ināta SSO (pilnÄ«ga autorizācija). virtuālo maŔīnu (vietējā OpenStack lietotāja saskarne).

IAM izveide mums nozÄ«mēja to visu savienot vienā sistēmā, kas ir pilnÄ«bā mÅ«su paÅ”u. Tajā paŔā laikā mēs nezaudēsim nevienu funkcionalitāti ceļā, bet radÄ«sim pamatu nākotnei, kas ļaus mums to pārredzami pilnveidot bez pārveidoÅ”anas un mērogot to funkcionalitātes ziņā. ArÄ« sākumā lietotājiem bija paraugs piekļuvei pakalpojumiem (centrālais RBAC, uz lomu balstÄ«ta piekļuves kontrole) un vēl daži sÄ«kumi.

Uzdevums izrādÄ«jās nenozÄ«mÄ«gs: python un perl, vairāki aizmugure, neatkarÄ«gi rakstÄ«ti pakalpojumi, vairākas izstrādes komandas un administratori. Un pats galvenais, kaujas ražoÅ”anas sistēmā ir tÅ«kstoÅ”iem dzÄ«vu lietotāju. Tas viss bija jāuzraksta un, galvenais, jāizrullē bez upuriem.

Ko mēs izlaidīsim?

Aptuveni 4 mēneÅ”u laikā mēs sagatavojām sekojoÅ”o:

  • Mēs izveidojām vairākus jaunus dēmonus, kas apkopoja funkcijas, kas iepriekÅ” darbojās dažādās infrastruktÅ«ras daļās. Pārējiem pakalpojumiem tika noteikts jauns aizmugure Å”o dēmonu formā.
  • Mēs izveidojām savu centrālo paroļu un atslēgu krātuvi, kas ir pieejama visiem mÅ«su pakalpojumiem un kuru var brÄ«vi mainÄ«t pēc vajadzÄ«bas.
  • Mēs no jauna uzrakstÄ«jām 4 jaunas Keystone aizmugursistēmas (lietotāji, projekti, lomas, lomu pieŔķirÅ”ana), kas faktiski aizstāja tās datu bāzi un tagad darbojas kā viena mÅ«su lietotāju paroļu krātuve.
  • Mēs mācÄ«jām visiem mÅ«su Openstack pakalpojumiem doties uz treŔās puses politikas pakalpojumu, lai iegÅ«tu savas politikas, nevis lasÄ«tu Ŕīs politikas lokāli no katra servera (jā, tas ir veids, kā Openstack darbojas pēc noklusējuma!)

Šādam lielam pārstrādei ir nepiecieÅ”amas lielas, sarežģītas un, pats galvenais, sinhronas izmaiņas vairākās sistēmās, kuras rakstÄ«juÅ”as dažādas izstrādes komandas. Pēc salikÅ”anas visai sistēmai jādarbojas.

Kā Ŕādas izmaiņas izrullēt un nesaskrÅ«vēt? Vispirms nolēmām nedaudz ieskatÄ«ties nākotnē.

IzplatÄ«Å”anas stratēģija

  • Produktu bÅ«tu iespējams izrullēt vairākos posmos, taču tas palielinātu izstrādes laiku trÄ«s reizes. Turklāt kādu laiku mums bÅ«tu pilnÄ«ga datu desinhronizācija datu bāzēs. Jums bÅ«s jāraksta savi sinhronizācijas rÄ«ki un ilgu laiku jādzÄ«vo ar vairākiem datu krātuvēm. Un tas rada visdažādākos riskus.
  • Viss, ko varēja sagatavot lietotājam pārskatāmi, tika darÄ«ts iepriekÅ”. Pagāja 2 mēneÅ”i.
  • Mēs pieļāvām sev dÄ«kstāves vairākas stundas - tikai lietotāju darbÄ«bām, lai izveidotu un mainÄ«tu resursus.
  • Visu jau izveidoto resursu darbÄ«bai dÄ«kstāves bija nepieņemamas. Mēs plānojām, ka izlaiÅ”anas laikā resursiem jādarbojas bez dÄ«kstāves un neietekmējot klientus.
  • Lai mazinātu ietekmi uz mÅ«su klientiem, ja kaut kas noiet greizi, mēs nolēmām sākt darbu svētdienas vakarā. Mazāk klientu pārvalda virtuālās maŔīnas naktÄ«.
  • Mēs brÄ«dinājām visus mÅ«su klientus, ka izlaiÅ”anai izvēlētajā periodā pakalpojumu pārvaldÄ«ba nebÅ«s pieejama.

Atkāpe: kas ir izlaiŔana?

<piesardzība, filozofija>

Katrs IT speciālists var viegli atbildēt, kas ir izvērÅ”ana. JÅ«s instalējat CI/CD, un viss tiek automātiski piegādāts veikalā. šŸ™‚

Protams, tā ir taisnÄ«ba. Taču grÅ«tÄ«bas rada tas, ka, izmantojot mÅ«sdienÄ«gus koda piegādes automatizācijas rÄ«kus, tiek zaudēta izpratne par paÅ”u izlaiÅ”anu. Kā jÅ«s aizmirstat par riteņa izgudroÅ”anas episkumu, skatoties uz mÅ«sdienu transportu. Viss ir tik automatizēts, ka izlaiÅ”ana bieži tiek veikta, neizprotot visu ainu.

Un visa bilde ir tāda. IzlaiŔana sastāv no četriem galvenajiem aspektiem:

  1. Koda piegāde, ieskaitot datu modifikāciju. Piemēram, viņu migrācijas.
  2. Koda atcelÅ”ana ir iespēja atgriezties, ja kaut kas noiet greizi. Piemēram, izveidojot dublējumus.
  3. Katras izlaiŔanas/atcelŔanas darbības laiks. Jums ir jāsaprot jebkuras pirmo divu punktu darbības laiks.
  4. Ietekmētā funkcionalitāte. Jāizvērtē gan sagaidāmās pozitīvās, gan iespējamās negatīvās sekas.

Visi Å”ie aspekti ir jāņem vērā, lai tas bÅ«tu veiksmÄ«gs. Parasti tiek novērtēts tikai pirmais vai labākajā gadÄ«jumā otrais punkts, un pēc tam izlaiÅ”ana tiek uzskatÄ«ta par veiksmÄ«gu. Bet treÅ”ais un ceturtais ir vēl svarÄ«gāki. Kuram lietotājam tas patiktu, ja izlaiÅ”ana aizņemtu 3 stundas, nevis minÅ«ti? Vai arÄ« izlaiÅ”anas laikā tiek ietekmēts kaut kas nevajadzÄ«gs? Vai arÄ« viena pakalpojuma dÄ«kstāve radÄ«s neparedzamas sekas?

Akts 1..n, sagatavoŔana atbrīvoŔanai

Sākumā izdomāju Ä«si aprakstÄ«t mÅ«su tikÅ”anās: visa komanda, tās daļas, diskusiju kaudzes kafijas punktos, strÄ«di, testi, prāta vētras. Tad es domāju, ka tas bÅ«tu lieki. Tas vienmēr sastāv no četru mēneÅ”u izstrādes, it Ä«paÅ”i, ja jÅ«s nerakstāt kaut ko tādu, ko var piegādāt pastāvÄ«gi, bet gan vienu lielu funkciju dzÄ«vai sistēmai. Kas ietekmē visus pakalpojumus, taču lietotājiem nevajadzētu mainÄ«ties nekas, izņemot ā€œvienu pogu tÄ«mekļa saskarnēā€.

MÅ«su izpratne par to, kā izvērst, mainÄ«jās pēc katras jaunas tikÅ”anās, turklāt diezgan bÅ«tiski. Piemēram, mēs plānojām atjaunināt visu norēķinu datu bāzi. Bet mēs aprēķinājām laiku un sapratām, ka to nav iespējams izdarÄ«t saprātÄ«gā izlaiÅ”anas laikā. Mums bija nepiecieÅ”ama gandrÄ«z papildu nedēļa, lai sadalÄ«tu un arhivētu norēķinu datu bāzi. Un, kad paredzētais izlaiÅ”anas ātrums joprojām nebija apmierinoÅ”s, mēs pasÅ«tÄ«jām papildu, jaudÄ«gāku aparatÅ«ru, kur tika vilkta visa bāze. Nav tā, ka mēs nevēlējāmies to darÄ«t ātrāk, taču paÅ”reizējā nepiecieÅ”amÄ«ba ieviest mums nelika mums nekādu iespēju.

Kad kādam no mums radās Å”aubas, ka izlaiÅ”ana varētu ietekmēt mÅ«su virtuālo maŔīnu pieejamÄ«bu, mēs pavadÄ«jām nedēļu, veicot testus, eksperimentus, kodu analÄ«zi un saņēmām skaidru izpratni, ka mÅ«su ražoÅ”anā tas nenotiks, un pat visÅ”aubÄ«gākie cilvēki piekrita. ar Å”o.

Pa to laiku tehniskā atbalsta puiÅ”i veica savus neatkarÄ«gus eksperimentus, lai rakstÄ«tu klientiem instrukcijas par savienojuma metodēm, kurām pēc izlaiÅ”anas bija jāmainās. Viņi strādāja pie lietotāja UX, sagatavoja instrukcijas un sniedza personÄ«gas konsultācijas.

Mēs automatizējām visas iespējamās izlaiÅ”anas darbÄ«bas. Katra darbÄ«ba tika skripta, pat visvienkārŔākā, un pastāvÄ«gi tika izpildÄ«ti testi. Viņi strÄ«dējās par labāko veidu, kā izslēgt pakalpojumu - izlaist dēmonu vai bloķēt piekļuvi pakalpojumam ar ugunsmÅ«ri. Mēs izveidojām komandu kontrolsarakstu katram izlaiÅ”anas posmam un pastāvÄ«gi to atjauninājām. Mēs izveidojām un pastāvÄ«gi atjauninājām Ganta diagrammu visiem izlaiÅ”anas darbiem ar laiku.

LÄ«dz ar toā€¦

Pēdējais cēliens pirms izlaiÅ”anas

...ir laiks izrullēt.

Kā saka, mākslas darbu nevar pabeigt, tikai pabeigt pie tā strādāt. Jāpieliek gribas pūles, saprotot, ka visu neatradīsi, bet ticot, ka esi izdarījis visus saprātīgos pieņēmumus, paredzējis visus iespējamos gadījumus, novērsis visas kritiskās kļūdas un visi dalībnieki izdarīja visu, ko varēja. Jo vairāk koda izlaižat, jo grūtāk ir sevi par to pārliecināt (turklāt visi saprot, ka visu paredzēt nav iespējams).

Mēs nolēmām, ka esam gatavi izlaiÅ”anai, kad bijām pārliecināti, ka esam darÄ«juÅ”i visu iespējamo, lai segtu visus riskus mÅ«su lietotājiem, kas saistÄ«ti ar negaidÄ«tām ietekmēm un dÄ«kstāvēm. Tas nozÄ«mē, ka viss var noiet greizi, izņemot:

  1. Ietekmē (mums svēto, visdārgāko) lietotāju infrastruktūru,
  2. Funkcionalitāte: mÅ«su pakalpojuma izmantoÅ”anai pēc izlaiÅ”anas jābÅ«t tādai paÅ”ai kā pirms tās.

Izrullē

IzklāŔanas stāsts, kas ietekmēja visu
Divi ruļļi, 8 netraucē

Mēs ņemam dÄ«kstāvi visiem lietotāju pieprasÄ«jumiem 7 stundas. PaÅ”laik mums ir gan izlaiÅ”anas plāns, gan atcelÅ”anas plāns.

  • Pati izlaiÅ”ana aizņem apmēram 3 stundas.
  • 2 stundas testÄ“Å”anai.
  • 2 stundas - rezerve iespējamai izmaiņu atcelÅ”anai.

Katrai darbībai ir sastādīta Ganta diagramma, cik ilgi tas notiek, kas notiek secīgi, kas tiek darīts paralēli.

IzklāŔanas stāsts, kas ietekmēja visu
Izlaistas Ganta diagrammas daļa, viena no sākotnējām versijām (bez paralēlas izpildes). Visvērtīgākais sinhronizācijas rīks

Visiem dalÄ«bniekiem ir noteikta viņu loma izvērÅ”anā, kādus uzdevumus viņi veic un par ko viņi ir atbildÄ«gi. Mēs cenÅ”amies panākt, lai katrs posms tiktu automatizēts, izvērsts, atgriezts, apkopot atsauksmes un izvērst to vēlreiz.

Notikumu hronika

Tātad svētdien, 15.aprÄ«lÄ«, pulksten 29 ieradās darbā 10 cilvēki. Papildus galvenajiem dalÄ«bniekiem daži ieradās vienkārÅ”i atbalstÄ«t komandu, par ko viņiem Ä«paÅ”s paldies.

Ir arÄ« vērts pieminēt, ka mÅ«su galvenais testētājs ir atvaļinājumā. Bez testÄ“Å”anas to nav iespējams ieviest, mēs pētām iespējas. Kolēģe piekrÄ«t mÅ«s pārbaudÄ«t no atvaļinājuma, par ko viņa saņem milzÄ«gu pateicÄ«bu no visas komandas.

00:00. Stop
Pārtraucam lietotāju pieprasījumus, izkarinām zīmi ar uzrakstu tehniskais darbs. Monitorings kliedz, bet viss normāli. Mēs pārbaudām, vai nav nokritis nekas cits, kā tikai tam, kam vajadzēja krist. Un mēs sākam darbu pie migrācijas.

Ikvienam ir izdrukāts izvērÅ”anas plāns punkts punktā, visi zina, kas ko un kurā brÄ«dÄ« dara. Pēc katras darbÄ«bas mēs pārbaudām laiku, lai pārliecinātos, ka mēs tos nepārsniegsim, un viss notiek saskaņā ar plānu. Tie, kuri nepiedalās tieÅ”i paÅ”reizējā posmā, gatavojas, laižot klajā tieÅ”saistes rotaļlietu (Xonotic, 3. tipa quacks), lai netraucētu saviem kolēģiem. šŸ™‚

02:00. Izrullēts
PatÄ«kams pārsteigums ā€“ datubāzu un migrācijas skriptu optimizācijas dēļ mēs pabeidzam izlaiÅ”anu stundu agrāk. Vispārējais kliedziens: "izrullēts!" Visas jaunās funkcijas ir ražoÅ”anā, taču lÄ«dz Å”im tās redzam tikai mēs saskarnē. Visi pāriet uz testÄ“Å”anas režīmu, saŔķiro tos grupās un sāk redzēt, kas beigās notika.

Ne pārāk labi sanāca, to saprotam pēc 10 minÅ«tēm, kad komandas biedru projektos nekas nav pieslēgts vai nestrādā. Ātrā sinhronizācija, mēs izrunājam savas problēmas, nosakām prioritātes, sadalāmies komandās un veicam atkļūdoÅ”anu.

02:30. Divas lielas problēmas pret četrām acīm
Mēs atklājam divas lielas problēmas. Mēs sapratām, ka klienti neredzēs dažus saistītos pakalpojumus, un radīsies problēmas ar partneru kontiem. Abas ir saistītas ar nepilnīgiem migrācijas skriptiem dažiem malas gadījumiem. Mums tas tagad ir jāizlabo.

Mēs rakstām vaicājumus, kas to ieraksta ar vismaz 4 acÄ«m. Mēs tos pārbaudām pirmsražoÅ”anas laikā, lai pārliecinātos, ka tie darbojas un neko nesalauž. Vari ripot tālāk. Tajā paŔā laikā mēs veicam regulāro integrācijas testÄ“Å”anu, kas atklāj vēl dažas problēmas. Tās visas ir mazas, bet arÄ« tās ir jāremontē.

03:00. -2 problēmas +2 problēmas
Ir novērstas divas iepriekŔējās lielās problēmas, kā arÄ« gandrÄ«z visas mazākās problēmas. Visi, kas nav aizņemti ar labojumiem, aktÄ«vi strādā savos kontos un ziņo par atrasto. Mēs nosakām prioritātes, sadalām tos starp komandām un atstājam nekritiskās lietas uz rÄ«ta pusi.

Mēs veicam testus vēlreiz, viņi atklāj divas jaunas lielas problēmas. Ne visas pakalpojumu politikas tika saņemtas pareizi, tāpēc daži lietotāju pieprasījumi neiztur autorizāciju. Turklāt jauna problēma ar partneru kontiem. Steidzam skatīties.

03:20. Ārkārtas sinhronizācija
Izlabota viena jauna problēma. Otrajā gadÄ«jumā mēs organizējam ārkārtas sinhronizāciju. Mēs saprotam, kas notiek: iepriekŔējais labojums novērsa vienu problēmu, bet radÄ«ja citu. Paņemam pārtraukumu, lai saprastu, kā to izdarÄ«t pareizi un bez sekām.

03:30. SeŔas acis
Mēs saprotam, kādam jābÅ«t bāzes galÄ«gajam stāvoklim, lai visiem partneriem viss izdotos labi. Uzrakstam pieprasÄ«jumu ar 6 acÄ«m, izrullējam pirmsražoÅ”anā, testējam, izrullējam ražoÅ”anai.

04:00. Viss darbojas
Visas pārbaudes ir izturētas, nekādas kritiskas problēmas nav redzamas. Ik pa laikam kādam komandā kaut kas nelÄ«dz, mēs operatÄ«vi reaģējam. Visbiežāk trauksme ir nepatiesa. Bet dažreiz kaut kas nesanāk vai atseviŔķa lapa nedarbojas. Sēžam, labojam, labojam, labojam. AtseviŔķa komanda laiž klajā pēdējo lielo funkciju ā€“ norēķinus.

04:30. NeatgrieŔanās punkts
Tuvojas neatgrieÅ”anās punkts, tas ir, laiks, kad, ja sāksim ripināt atpakaļ, mēs nesasniegsim mums doto dÄ«kstāvi. Problēmas ir ar rēķiniem, kas visu zina un fiksē, bet spÄ«tÄ«gi atsakās norakstÄ«t naudu no klientiem. AtseviŔķās lapās, darbÄ«bās un statusos ir vairākas kļūdas. Galvenā funkcionalitāte darbojas, visas pārbaudes veiksmÄ«gi izietas. Mēs nolemjam, ka izlaiÅ”ana ir notikusi, mēs neatgriezÄ«simies.

06:00. Atvērts visiem lietotāja interfeisa lietotājiem
Izlabotas kļūdas. Daži, kas lietotājus neinteresē, tiek atstāti vēlākam laikam. Mēs atveram saskarni ikvienam. Mēs turpinām darbu pie rēķinu izrakstÄ«Å”anas, gaidot lietotāju atsauksmes un uzraudzÄ«bas rezultātus.

07:00. Problēmas ar API ielādi
Kļūst skaidrs, ka mēs nedaudz nepareizi plānojām mÅ«su API slodzi un pārbaudÄ«jām Å”o slodzi, kas nevarēja identificēt problēmu. Rezultātā ā‰ˆ5% pieprasÄ«jumu neizdodas. Mobilizēsimies un meklēsim iemeslu.

Norēķini ir spÄ«tÄ«gi un arÄ« nevēlas darboties. Nolemjam to atlikt uz vēlāku laiku, lai izmaiņas veiktu mierÄ«gi. Tas ir, tajā tiek uzkrāti visi resursi, bet norakstÄ«Å”ana no klientiem netiek cauri. Protams, tā ir problēma, taču salÄ«dzinājumā ar vispārējo izlaiÅ”anu tā Ŕķiet mazsvarÄ«ga.

08:00. Labojiet API
Izritinājām slodzes labojumu, kļūmes pazuda. Sākam iet mājās.

10:00. Visi
Viss ir fiksēts. Uzraudzībā ir kluss, un pie klientu komanda pamazām iet gulēt. Rēķins paliek, mēs to atjaunosim rīt.

Pēc tam dienas laikā tika veikta izlaiÅ”ana, kas dažiem mÅ«su klientiem laboja žurnālus, paziņojumus, atgrieÅ”anas kodus un pielāgojumus.

Tātad izlaiÅ”ana bija veiksmÄ«ga! Varētu, protams, bÅ«t labāk, taču izdarÄ«jām secinājumus par to, ar ko mums nepietika, lai sasniegtu pilnÄ«bu.

Kopā

2 mēneÅ”u laikā, aktÄ«vi gatavojoties izlaiÅ”anai, tika izpildÄ«ti 43 uzdevumi, kas ilga no pāris stundām lÄ«dz vairākām dienām.

IzlaiŔanas laikā:

  • jauni un mainÄ«ti dēmoni - 5 gab., nomainot 2 monolÄ«tus;
  • izmaiņas datu bāzēs - ir ietekmētas visas 6 mÅ«su datu bāzes ar lietotāju datiem, veiktas lejupielādes no trim vecām datu bāzēm uz vienu jaunu;
  • pilnÄ«bā pārveidota priekÅ”puse;
  • lejupielādētā koda apjoms - 33 tÅ«kstoÅ”i rindu jauna koda, ā‰ˆ 3 tÅ«kstoÅ”i koda rindu testos, ā‰ˆ 5 tÅ«kstoÅ”i rindu migrācijas kods;
  • visi dati ir neskarti, nav bojāta neviena klienta virtuālā maŔīna. šŸ™‚

Laba prakse sekmīgai izlaiŔanai

Viņi mÅ«s vadÄ«ja Å”ajā sarežģītajā situācijā. Bet, vispārÄ«gi runājot, ir lietderÄ«gi tos ievērot jebkuras izlaiÅ”anas laikā. Bet jo sarežģītāka ir ievieÅ”ana, jo lielāku lomu tās spēlē.

  1. Pirmā lieta, kas jums jādara, ir saprast, kā izlaiÅ”ana var vai ietekmēs lietotājus. Vai bÅ«s dÄ«kstāves? Ja jā, kāds ir dÄ«kstāves laiks? Kā tas ietekmēs lietotājus? Kādi ir iespējamie labākie un sliktākie scenāriji? Un segt riskus.
  2. Plānojiet visu. Katrā posmā jums ir jāsaprot visi izlaiŔanas aspekti:
    • koda piegāde;
    • koda atcelÅ”ana;
    • katras operācijas laiks;
    • ietekmētā funkcionalitāte.
  3. Izmēģiniet scenārijus, lÄ«dz kļūst acÄ«mredzami visi izlaiÅ”anas posmi, kā arÄ« riski katrā no tiem. Ja jums ir kādas Å”aubas, varat ieturēt pauzi un apskatÄ«t apÅ”aubāmo posmu atseviŔķi.
  4. Katru posmu var un vajadzētu uzlabot, ja tas palīdz mūsu lietotājiem. Piemēram, tas samazinās dīkstāves laiku vai novērsīs dažus riskus.
  5. AtcelÅ”anas pārbaude ir daudz svarÄ«gāka nekā koda piegādes pārbaude. Ir jāpārbauda, ā€‹ā€‹vai atcelÅ”anas rezultātā sistēma atgriezÄ«sies sākotnējā stāvoklÄ«, un apstipriniet to ar testiem.
  6. Viss, ko var automatizēt, ir jāautomatizē. Viss, ko nevar automatizēt, iepriekÅ” jāraksta uz krāpÅ”anās lapas.
  7. Ierakstiet veiksmes kritēriju. Kādai funkcionalitātei jābÅ«t pieejamai un kurā laikā? Ja tas nenotiek, palaidiet atcelÅ”anas plānu.
  8. Un pats galvenais ā€“ cilvēki. Ikvienam ir jāapzinās, ko viņi dara, kāpēc un kas ir atkarÄ«gs no viņa darbÄ«bām ievieÅ”anas procesā.

Vienā teikumā sakot, ar labu plānoÅ”anu un izstrādi jÅ«s varat ieviest visu, ko vēlaties, bez sekām uz pārdoÅ”anu. Pat kaut kas, kas ietekmēs visus jÅ«su pakalpojumus ražoÅ”anā.

Avots: www.habr.com

Pievieno komentāru