Isang rollout na kwento na nakaapekto sa lahat

Mga Kaaway ng Realidad sa pamamagitan ng 12f-2

Sa katapusan ng Abril, habang kinubkob ng mga White Walker ang Winterfell, may mas kawili-wiling nangyari sa amin; gumawa kami ng hindi pangkaraniwang rollout. Sa prinsipyo, patuloy kaming naglalabas ng mga bagong feature sa produksyon (tulad ng iba pa). Ngunit iba ang isang ito. Ang sukat nito ay ang anumang mga potensyal na pagkakamali na maaari naming gawin ay makakaapekto sa lahat ng aming mga serbisyo at user. Bilang resulta, inilunsad namin ang lahat ayon sa plano, sa loob ng nakaplanong at inihayag na panahon ng downtime, nang walang mga kahihinatnan para sa mga benta. Ang artikulo ay tungkol sa kung paano namin nakamit ito at kung paano maulit ito ng sinuman sa bahay.

Hindi ko na ilalarawan ang mga desisyong arkitektura at teknikal na ginawa namin o sasabihin kung paano gumagana ang lahat. Ito ay mga tala sa mga margin tungkol sa kung paano naganap ang isa sa pinakamahirap na paglulunsad, na aking naobserbahan at kung saan ako ay direktang kasangkot. Hindi ko inaangkin ang pagkakumpleto o teknikal na mga detalye; marahil ay lilitaw ang mga ito sa ibang artikulo.

Background + anong uri ng functionality ito?

Bumubuo kami ng cloud platform Mail.ru Cloud Solutions (MCS), kung saan ako nagtatrabaho bilang technical director. At ngayon ay oras na upang magdagdag ng IAM (Identity and Access Management) sa aming platform, na nagbibigay ng pinag-isang pamamahala ng lahat ng user account, user, password, tungkulin, serbisyo at higit pa. Kung bakit ito kailangan sa cloud ay isang malinaw na tanong: lahat ng impormasyon ng user ay nakaimbak dito.

Karaniwan ang mga ganitong bagay ay nagsisimulang itayo sa pinakadulo simula ng anumang mga proyekto. Ngunit sa kasaysayan ang mga bagay ay medyo naiiba sa MCS. Ang MCS ay itinayo sa dalawang bahagi:

• Openstack na may sarili nitong Keystone authorization module,
• Hotbox (S3 storage) batay sa Mail.ru Cloud project,

sa paligid kung saan lumitaw ang mga bagong serbisyo.

Sa pangkalahatan, ito ay dalawang magkaibang uri ng awtorisasyon. Dagdag pa, gumamit kami ng ilang hiwalay na pag-unlad ng Mail.ru, halimbawa, isang pangkalahatang imbakan ng password ng Mail.ru, pati na rin ang isang self-written na openid connector, salamat sa kung saan ang SSO (end-to-end na awtorisasyon) ay ibinigay sa panel ng Horizon ng mga virtual machine (katutubong OpenStack UI).

Ang paggawa ng IAM para sa amin ay nangangahulugan ng pagkonekta sa lahat ng ito sa isang solong sistema, ganap na sa amin. Kasabay nito, hindi kami mawawalan ng anumang functionality sa daan, ngunit lilikha ng pundasyon para sa hinaharap na magbibigay-daan sa amin na malinaw na pinuhin ito nang walang refactoring at sukatin ito sa mga tuntunin ng functionality. Gayundin sa simula, ang mga user ay may role model para sa access sa mga serbisyo (central RBAC, role-based access control) at ilang iba pang maliliit na bagay.

Ang gawain ay naging hindi mahalaga: python at perl, maraming backend, independiyenteng nakasulat na mga serbisyo, maraming development team at admin. At ang pinakamahalaga, mayroong libu-libong live na gumagamit sa sistema ng produksyon ng labanan. Ang lahat ng ito ay kailangang isulat at, higit sa lahat, ilunsad nang walang kaswalti.

Ano ang ilalabas natin?

Sa halos 4 na buwan, inihanda namin ang mga sumusunod:

• Gumawa kami ng ilang bagong daemon na pinagsama-sama ang mga function na dati nang gumana sa iba't ibang bahagi ng imprastraktura. Ang natitirang mga serbisyo ay inireseta ng isang bagong backend sa anyo ng mga demonyong ito.
• Isinulat namin ang aming sariling sentral na imbakan ng mga password at mga susi, na magagamit para sa lahat ng aming mga serbisyo, na maaaring malayang baguhin ayon sa kailangan namin.
• Sumulat kami ng 4 na bagong backend para sa Keystone mula sa simula (mga user, proyekto, tungkulin, pagtatalaga ng tungkulin), na, sa katunayan, pinalitan ang database nito, at ngayon ay nagsisilbing iisang repository para sa aming mga password ng user.
• Itinuro namin sa lahat ng aming serbisyo ng Openstack na pumunta sa isang serbisyo ng patakaran ng third-party para sa kanilang mga patakaran sa halip na basahin ang mga patakarang ito nang lokal mula sa bawat server (oo, ganyan ang paggana ng Openstack bilang default!)

Ang ganitong pangunahing rework ay nangangailangan ng malaki, masalimuot at, pinaka-mahalaga, magkakasabay na pagbabago sa ilang system na isinulat ng iba't ibang mga development team. Kapag naipon, dapat gumana ang buong sistema.

Paano ilalabas ang gayong mga pagbabago at hindi ito sirain? Una, nagpasya kaming tumingin ng kaunti sa hinaharap.

Diskarte sa paglulunsad

• Posibleng ilunsad ang produkto sa maraming yugto, ngunit madaragdagan nito ang oras ng pag-unlad ng tatlong beses. Bilang karagdagan, sa loob ng ilang panahon magkakaroon kami ng kumpletong desynchronization ng data sa mga database. Kailangan mong isulat ang iyong sariling mga tool sa pag-synchronize at mamuhay kasama ang maraming data store sa loob ng mahabang panahon. At ito ay lumilikha ng isang malawak na iba't ibang mga panganib.
• Lahat ng maaaring ihanda nang malinaw para sa gumagamit ay ginawa nang maaga. Tumagal ng 2 buwan.
• Pinahintulutan namin ang aming sarili ng downtime nang ilang oras - para lang sa mga operasyon ng user na gumawa at magbago ng mga mapagkukunan.
• Para sa pagpapatakbo ng lahat ng nagawa nang mapagkukunan, hindi katanggap-tanggap ang downtime. Pinlano namin na sa panahon ng paglulunsad, ang mga mapagkukunan ay dapat gumana nang walang downtime at makakaapekto sa mga kliyente.
• Upang mabawasan ang epekto sa aming mga customer kung may nangyaring mali, nagpasya kaming ilunsad sa Linggo ng gabi. Mas kaunting mga customer ang namamahala ng mga virtual machine sa gabi.
• Binalaan namin ang lahat ng aming mga kliyente na sa panahon na pinili para sa paglulunsad, ang pamamahala ng serbisyo ay hindi magagamit.

Digression: ano ang rollout?

Madaling masasagot ng bawat IT specialist kung ano ang rollout. Nag-install ka ng CI/CD, at lahat ng bagay ay awtomatikong inihahatid sa tindahan. 🙂

Syempre totoo ito. Ngunit ang kahirapan ay dahil sa modernong mga tool sa pag-automate ng paghahatid ng code, nawawala ang pag-unawa sa mismong rollout. Paano mo nakalimutan ang tungkol sa epicness ng pag-imbento ng gulong kapag tumitingin sa modernong transportasyon. Ang lahat ay awtomatiko kaya ang rollout ay madalas na isinasagawa nang hindi nauunawaan ang buong larawan.

At ang buong larawan ay ganito. Binubuo ang rollout ng apat na pangunahing aspeto:

1. Paghahatid ng code, kabilang ang pagbabago ng data. Halimbawa, ang kanilang mga migrasyon.
2. Ang pag-rollback ng code ay ang kakayahang bumalik kung may mali. Halimbawa, sa pamamagitan ng paggawa ng mga backup.
3. Oras ng bawat pagpapatakbo ng rollout/rollback. Kailangan mong maunawaan ang timing ng anumang operasyon ng unang dalawang puntos.
4. Apektadong pag-andar. Kinakailangang suriin ang parehong inaasahang positibo at posibleng negatibong epekto.

Dapat isaalang-alang ang lahat ng aspetong ito para sa matagumpay na paglulunsad. Kadalasan ang una lang, o ang pinakamaganda ay ang pangalawa, na punto ang tinatasa, at pagkatapos ay ang rollout ay itinuturing na matagumpay. Ngunit ang ikatlo at ikaapat ay mas mahalaga. Sinong user ang magugustuhan kung ang paglulunsad ay tumagal ng 3 oras sa halip na isang minuto? O kung maapektuhan ang isang bagay na hindi kailangan sa panahon ng paglulunsad? O ang downtime ng isang serbisyo ay hahantong sa hindi inaasahang kahihinatnan?

Act 1..n, paghahanda para sa pagpapalaya

Noong una ay naisipan kong ilarawan nang maikli ang aming mga pagpupulong: ang buong koponan, ang mga bahagi nito, tambak ng mga talakayan sa mga punto ng kape, mga argumento, mga pagsubok, mga brainstorming. Pagkatapos ay naisip ko na ito ay hindi na kailangan. Ang apat na buwan ng pag-unlad ay palaging binubuo nito, lalo na kapag hindi ka nagsusulat ng isang bagay na maaaring maihatid nang tuluy-tuloy, ngunit isang malaking tampok para sa isang live na sistema. Na nakakaapekto sa lahat ng serbisyo, ngunit walang dapat magbago para sa mga user maliban sa "isang button sa web interface."

Ang aming pag-unawa sa kung paano ilunsad ay nagbago mula sa bawat bagong pulong, at medyo makabuluhan. Halimbawa, ia-update namin ang aming buong database ng pagsingil. Ngunit kinakalkula namin ang oras at napagtanto namin na imposibleng gawin ito sa isang makatwirang oras ng paglulunsad. Inabot kami ng halos isang dagdag na linggo upang i-shard at i-archive ang database ng pagsingil. At nang hindi pa rin kasiya-siya ang inaasahang bilis ng paglulunsad, nag-order kami ng karagdagang, mas malakas na hardware, kung saan na-drag ang buong base. Hindi sa hindi namin gustong gawin ito nang mas maaga, ngunit ang kasalukuyang pangangailangang ilunsad ay nag-iwan sa amin na walang mga pagpipilian.

Kapag ang isa sa amin ay nag-alinlangan na ang rollout ay maaaring makaapekto sa pagkakaroon ng aming mga virtual machine, gumugol kami ng isang linggo sa pagsasagawa ng mga pagsubok, eksperimento, pagsusuri ng code at nakatanggap ng malinaw na pag-unawa na hindi ito mangyayari sa aming produksyon, at kahit na ang pinaka-nagdududa na mga tao ay sumang-ayon. kasama nito.

Samantala, ang mga lalaki mula sa teknikal na suporta ay nagsagawa ng kanilang sariling mga independiyenteng eksperimento upang magsulat ng mga tagubilin para sa mga kliyente sa mga paraan ng koneksyon, na dapat na magbago pagkatapos ng paglulunsad. Nagtrabaho sila sa user UX, naghanda ng mga tagubilin at nagbigay ng mga personal na konsultasyon.

Na-automate namin ang lahat ng pagpapatakbo ng rollout na posible. Ang bawat operasyon ay nai-script, kahit na ang pinakasimpleng mga operasyon, at ang mga pagsubok ay patuloy na pinapatakbo. Nagtalo sila tungkol sa pinakamahusay na paraan upang i-off ang serbisyo - alisin ang daemon o harangan ang access sa serbisyo gamit ang isang firewall. Gumawa kami ng checklist ng mga koponan para sa bawat yugto ng paglulunsad at patuloy itong ina-update. Kami ay gumuhit at patuloy na nag-update ng Gantt chart para sa lahat ng rollout na trabaho, na may mga timing.

At kaya…

Ang huling pagkilos, bago ilunsad

...oras na para ilunsad.

Sabi nga nila, hindi makukumpleto ang isang likhang sining, matatapos lamang ang paggawa nito. Kailangan mong gumawa ng isang pagsisikap ng kalooban, na maunawaan na hindi mo mahahanap ang lahat, ngunit naniniwala na ginawa mo ang lahat ng makatwirang pagpapalagay, ibinigay para sa lahat ng posibleng mga kaso, isinara ang lahat ng mga kritikal na bug, at ginawa ng lahat ng mga kalahok ang lahat ng kanilang makakaya. Kung mas maraming code ang inilalabas mo, mas mahirap kumbinsihin ang iyong sarili tungkol dito (bukod sa, naiintindihan ng lahat na imposibleng mahulaan ang lahat).

Napagpasyahan namin na handa na kaming ilunsad nang kumbinsido kaming ginawa namin ang lahat ng posible upang masakop ang lahat ng panganib para sa aming mga user na nauugnay sa mga hindi inaasahang epekto at downtime. Iyon ay, anumang bagay ay maaaring magkamali maliban sa:

1. Makakaapekto (sagrado sa amin, pinakamahalaga) imprastraktura ng gumagamit,
2. Functionality: ang paggamit ng aming serbisyo pagkatapos ng rollout ay dapat na kapareho ng dati.

Rolling out

Dalawang roll, 8 huwag makialam

Nagsasagawa kami ng downtime para sa lahat ng kahilingan mula sa mga user sa loob ng 7 oras. Sa oras na ito, mayroon kaming parehong rollout plan at rollback plan.

• Ang rollout mismo ay tumatagal ng humigit-kumulang 3 oras.
• 2 oras para sa pagsubok.
• 2 oras - magreserba para sa isang posibleng rollback ng mga pagbabago.

Ang isang Gantt chart ay iginuhit para sa bawat aksyon, kung gaano katagal ito, kung ano ang nangyayari nang sunud-sunod, kung ano ang ginagawa nang magkatulad.

Isang piraso ng isang rollout na Gantt chart, isa sa mga naunang bersyon (nang walang parallel execution). Ang Pinakamahalagang Tool sa Pag-synchronize

Ang lahat ng mga kalahok ay may kanilang tungkulin sa paglulunsad na tinutukoy, kung anong mga gawain ang kanilang ginagawa, at kung ano ang kanilang pananagutan. Sinusubukan naming dalhin ang bawat yugto sa pagiging awtomatiko, i-roll out ito, i-roll ito pabalik, mangolekta ng feedback at i-roll out itong muli.

Chronicle ng mga pangyayari

Kaya, 15 katao ang pumasok sa trabaho noong Linggo, Abril 29, alas-10 ng gabi. Bilang karagdagan sa mga pangunahing kalahok, ang ilan ay dumating lamang upang suportahan ang koponan, kung saan espesyal na salamat sa kanila.

Nararapat ding banggitin na ang aming key tester ay nasa bakasyon. Imposibleng ilunsad nang walang pagsubok, nag-e-explore kami ng mga opsyon. Sumasang-ayon ang isang kasamahan na subukan kami mula sa bakasyon, kung saan natatanggap niya ang napakalaking pasasalamat mula sa buong koponan.

00:00. Tumigil ka
Itinigil namin ang mga kahilingan ng user, ibinaba ang isang karatulang nagsasabing teknikal na gawain. Ang pagsubaybay ay sumisigaw, ngunit ang lahat ay normal. Sinusuri namin na walang nahulog maliban sa dapat na mahulog. At nagsimula kaming magtrabaho sa migration.

Ang bawat isa ay may naka-print na plano sa paglulunsad bawat punto, alam ng lahat kung sino ang gumagawa ng kung ano at sa anong sandali. Pagkatapos ng bawat aksyon, sinusuri namin ang mga timing upang matiyak na hindi namin lalampas ang mga ito, at lahat ay naaayon sa plano. Ang mga hindi nakikilahok sa rollout nang direkta sa kasalukuyang yugto ay naghahanda sa pamamagitan ng paglulunsad ng online na laruan (Xonotic, type 3 quacks) upang hindi makaistorbo sa kanilang mga kasamahan. 🙂

02:00. Inilunsad
Isang kaaya-ayang sorpresa - natapos namin ang paglulunsad ng isang oras nang mas maaga, dahil sa pag-optimize ng aming mga database at migration script. Ang pangkalahatang sigaw, "inilunsad!" Ang lahat ng mga bagong pag-andar ay nasa produksyon, ngunit sa ngayon ay makikita lamang natin ang mga ito sa interface. Ang bawat tao'y pumunta sa pagsubok mode, pag-uri-uriin ang mga ito sa mga grupo, at nagsisimula upang makita kung ano ang nangyari sa dulo.

Hindi ito naging maganda, napagtanto namin ito pagkatapos ng 10 minuto, kapag walang konektado o gumagana sa mga proyekto ng mga miyembro ng koponan. Mabilis na pag-sync, boses namin ang aming mga problema, nagtatakda ng mga priyoridad, pumasok sa mga koponan at pumunta sa pag-debug.

02:30. Dalawang malaking problema laban sa apat na mata
Nakahanap kami ng dalawang malalaking problema. Napagtanto namin na hindi makikita ng mga customer ang ilang konektadong serbisyo, at magkakaroon ng mga problema sa mga partner na account. Parehong dahil sa hindi perpektong migration script para sa ilang edge case. Kailangan nating ayusin ito ngayon.

Nagsusulat kami ng mga query na nagre-record nito, na may hindi bababa sa 4 na mata. Sinusubukan namin ang mga ito sa panahon ng pre-production para matiyak na gumagana ang mga ito at walang masisira. Maaari kang gumulong. Kasabay nito, pinapatakbo namin ang aming regular na pagsubok sa pagsasama, na nagpapakita ng ilan pang isyu. Lahat sila ay maliit, ngunit kailangan din nilang ayusin.

03:00. -2 problema +2 problema
Ang dalawang nakaraang malalaking problema ay naayos na, at halos lahat ng mga menor de edad din. Ang lahat ng walang trabaho sa mga pag-aayos ay aktibong nagtatrabaho sa kanilang mga account at nag-uulat kung ano ang kanilang nahanap. Nag-prioritize kami, namamahagi sa mga koponan, at nag-iiwan ng mga hindi kritikal na item para sa umaga.

Muli naming pinapatakbo ang mga pagsubok, natuklasan nila ang dalawang bagong malalaking problema. Hindi lahat ng mga patakaran sa serbisyo ay dumating nang tama, kaya ang ilang mga kahilingan ng user ay hindi pumasa sa awtorisasyon. Dagdag pa ng bagong problema sa mga account ng kasosyo. Bilisan natin tingnan.

03:20. Emergency sync
Isang bagong isyu ang naayos. Para sa pangalawa, nag-aayos kami ng isang emergency na pag-sync. Naiintindihan namin kung ano ang nangyayari: naayos ng nakaraang pag-aayos ang isang problema, ngunit lumikha ng isa pa. Nagpapahinga kami upang malaman kung paano ito gagawin nang tama at walang mga kahihinatnan.

03:30. Anim na mata
Naiintindihan namin kung ano dapat ang panghuling estado ng base upang maging maayos ang lahat para sa lahat ng mga kasosyo. Sumulat kami ng isang kahilingan na may 6 na mata, i-roll out ito sa pre-production, subukan ito, i-roll out ito para sa produksyon.

04:00. Lahat ay gumagana
Ang lahat ng mga pagsubok ay pumasa, walang mga kritikal na problema ang nakikita. Paminsan-minsan, may isang bagay sa team na hindi gumagana para sa isang tao, agad kaming tumutugon. Kadalasan ay hindi totoo ang alarma. Ngunit kung minsan ay may hindi dumarating, o hindi gumagana ang isang hiwalay na pahina. Umupo kami, ayusin, ayusin, ayusin. Ang isang hiwalay na koponan ay naglulunsad ng huling malaking tampok - pagsingil.

04:30. Point of no return
Papalapit na ang punto ng walang pagbabalik, iyon ay, ang oras kung kailan, kung magsisimula tayong gumulong, hindi natin sasagutin ang downtime na ibinigay sa atin. May mga problema sa pagsingil, na nakakaalam at nagtatala ng lahat, ngunit matigas ang ulo na tumanggi na isulat ang pera mula sa mga kliyente. Mayroong ilang mga bug sa mga indibidwal na pahina, pagkilos, at status. Gumagana ang pangunahing pag-andar, matagumpay na pumasa ang lahat ng mga pagsubok. Napagpasyahan namin na ang rollout ay naganap na, hindi kami babalik.

06:00. Bukas para sa lahat sa UI
Naayos ang mga bug. Ang ilan na hindi nakakaakit sa mga user ay naiwan sa ibang pagkakataon. Binubuksan namin ang interface sa lahat. Patuloy kaming nagtatrabaho sa pagsingil, naghihintay ng feedback ng user at mga resulta ng pagsubaybay.

07:00. Mga problema sa pag-load ng API
Nagiging malinaw na medyo mali ang pagplano namin sa pag-load sa aming API at sinubukan ang pag-load na ito, na hindi matukoy ang problema. Bilang resulta, ≈5% ng mga kahilingan ang nabigo. Magpakilos tayo at hanapin ang dahilan.

Ang pagsingil ay matigas ang ulo at ayaw ding magtrabaho. Nagpasya kaming ipagpaliban ito hanggang sa ibang pagkakataon upang maisagawa ang mga pagbabago sa isang mahinahong paraan. Iyon ay, ang lahat ng mga mapagkukunan ay naipon dito, ngunit ang mga write-off mula sa mga kliyente ay hindi dumaan. Siyempre, ito ay isang problema, ngunit kumpara sa pangkalahatang paglulunsad ay tila hindi mahalaga.

08:00. Ayusin ang API
Naglunsad kami ng pag-aayos para sa pagkarga, nawala ang mga pagkabigo. Magsisimula na kaming umuwi.

10:00. Lahat
Naayos na ang lahat. Tahimik sa pagsubaybay at sa lugar ng mga customer, unti-unting natutulog ang team. Nananatili ang pagsingil, ibabalik namin ito bukas.

Pagkatapos sa araw ay may mga rollout na nag-aayos ng mga log, notification, return code at customization para sa ilan sa aming mga kliyente.

Kaya, matagumpay ang rollout! Siyempre, maaari itong maging mas mahusay, ngunit gumawa kami ng mga konklusyon tungkol sa kung ano ang hindi sapat para sa amin upang makamit ang pagiging perpekto.

Sa kabuuan

Sa loob ng 2 buwan ng aktibong paghahanda para sa paglulunsad, 43 gawain ang natapos, na tumatagal mula sa ilang oras hanggang ilang araw.

Sa panahon ng paglulunsad:

• bago at binagong mga demonyo - 5 piraso, pinapalitan ang 2 monolith;
• mga pagbabago sa loob ng mga database - lahat ng 6 sa aming mga database na may data ng user ay naapektuhan, ang mga pag-download ay ginawa mula sa tatlong lumang database sa isang bago;
• ganap na muling idisenyo na frontend;
• dami ng na-download na code - 33 libong linya ng bagong code, ≈ 3 libong linya ng code sa mga pagsubok, ≈ 5 libong linya ng migration code;
• buo ang lahat ng data, wala ni isang virtual machine ng customer ang nasira. 🙂

Magandang kagawian para sa mahusay na paglulunsad

Ginabayan nila kami sa mahirap na sitwasyong ito. Ngunit, sa pangkalahatan, kapaki-pakinabang na sundin ang mga ito sa panahon ng anumang paglulunsad. Ngunit kung mas kumplikado ang paglulunsad, mas malaki ang papel na ginagampanan nila.

1. Ang unang bagay na kailangan mong gawin ay maunawaan kung paano makakaapekto o makakaapekto ang rollout sa mga user. Magkakaroon ba ng downtime? Kung gayon, ano ang downtime? Paano ito makakaapekto sa mga user? Ano ang mga posibleng pinakamahusay at pinakamasamang sitwasyon? At takpan ang mga panganib.
2. Planuhin ang lahat. Sa bawat yugto, kailangan mong maunawaan ang lahat ng aspeto ng paglulunsad:
   • paghahatid ng code;
   • rollback ng code;
   • oras ng bawat operasyon;
   • apektadong pag-andar.
3. I-play ang mga sitwasyon hanggang sa maging malinaw ang lahat ng yugto ng rollout, pati na rin ang mga panganib sa bawat isa sa kanila. Kung mayroon kang anumang mga pagdududa, maaari kang magpahinga at suriin nang hiwalay ang kaduda-dudang yugto.
4. Ang bawat yugto ay maaari at dapat na mapabuti kung ito ay makakatulong sa aming mga gumagamit. Halimbawa, babawasan nito ang downtime o aalisin ang ilang mga panganib.
5. Mas mahalaga ang rollback testing kaysa sa code delivery testing. Kinakailangang suriin na bilang resulta ng rollback ang system ay babalik sa orihinal nitong estado, at kumpirmahin ito sa pamamagitan ng mga pagsubok.
6. Lahat ng bagay na maaaring awtomatiko ay dapat na awtomatiko. Lahat ng hindi maaaring awtomatiko ay dapat na isulat nang maaga sa isang cheat sheet.
7. Itala ang pamantayan ng tagumpay. Anong pag-andar ang dapat na magagamit at sa anong oras? Kung hindi ito mangyayari, magpatakbo ng rollback plan.
8. At ang pinakamahalaga - mga tao. Dapat malaman ng lahat kung ano ang kanilang ginagawa, bakit at ano ang nakasalalay sa kanilang mga aksyon sa proseso ng paglulunsad.

At sa isang pangungusap, na may mahusay na pagpaplano at pagpapaliwanag maaari mong ilunsad ang anumang gusto mo nang walang mga kahihinatnan para sa mga benta. Kahit na isang bagay na makakaapekto sa lahat ng iyong mga serbisyo sa produksyon.

Pinagmulan: www.habr.com