Crita rollout sing mengaruhi kabeh

Mungsuh saka kasunyatan dening 12f-2

Ing pungkasan April, nalika White Walkers ngepung Winterfell, ana kedadeyan sing luwih menarik kanggo kita; kita nindakake rollout sing ora biasa. Ing asas, kita terus-terusan ngluncurake fitur-fitur anyar menyang produksi (kaya wong liya). Nanging siji iki beda. Skala kasebut kayadene kemungkinan kesalahan sing bisa ditindakake bakal mengaruhi kabeh layanan lan pangguna. Akibaté, kita mbalek metu kabeh miturut rencana, ing wektu downtime ngrancang lan announced, tanpa jalaran kanggo dodolan. Artikel kasebut babagan carane entuk iki lan kepiye sapa bisa mbaleni ing omah.

Aku saiki ora bakal njlèntrèhaké pancasan arsitektur lan technical kita digawe utawa ngomong carane iku kabeh bisa. Iki minangka cathetan ing pinggir babagan carane salah sawijining rollouts sing paling angel ditindakake, sing aku diamati lan aku langsung melu. Aku ora ngaku lengkap utawa rincian teknis; mbok menawa bakal katon ing artikel liyane.

Latar mburi + fungsi apa iki?

Kita mbangun platform awan Solusi Cloud Mail.ru (MCS), ing ngendi aku kerja minangka direktur teknis. Lan saiki wektune nambah IAM (Manajemen Identitas lan Akses) menyang platform kita, sing nyedhiyakake manajemen terpadu kabeh akun pangguna, pangguna, sandhi, peran, layanan lan liya-liyane. Apa sing dibutuhake ing awan minangka pitakonan sing jelas: kabeh informasi pangguna disimpen ing kono.

Biasane, barang-barang kasebut wiwit dibangun ing wiwitan proyek apa wae. Nanging historis, MCS wis rada beda. MCS dibangun ing rong bagean:

• Openstack karo modul wewenang Keystone dhewe,
• Hotbox (panyimpenan S3) adhedhasar proyek Cloud Mail.ru,

watara kang layanan anyar banjur katon.

Ateges, iki rong jinis wewenang sing beda. Kajaba iku, kita nggunakake sawetara pangembangan Mail.ru sing kapisah, umpamane, panyimpenan sandi Mail.ru umum, uga konektor openid sing ditulis dhewe, amarga SSO (wewenang pungkasan) diwenehake ing panel Horizon. mesin virtual (OpenStack UI asli).

Nggawe IAM kanggo kita tegese nyambungake kabeh dadi siji sistem, kabeh dhewe. Ing wektu sing padha, kita ora bakal kelangan fungsi apa wae ing dalan, nanging bakal nggawe dhasar kanggo masa depan sing bakal ngidini kita nyaring kanthi transparan tanpa refactoring lan skala saka segi fungsi. Uga ing wiwitan, pangguna duwe panutan kanggo akses menyang layanan (RBAC pusat, kontrol akses basis peran) lan sawetara perkara cilik liyane.

Tugas kasebut ora pati penting: python lan perl, sawetara backend, layanan sing ditulis kanthi mandiri, sawetara tim pangembangan lan admin. Lan sing paling penting, ana ewonan pangguna langsung ing sistem produksi pertempuran. Kabeh iki kudu ditulis lan, sing paling penting, diluncurake tanpa korban.

Apa sing arep kita luncurake?

Kanggo nggawe kira-kira, kira-kira 4 sasi kita nyiapake ing ngisor iki:

• Kita nggawe sawetara daemon anyar sing nggabungake fungsi sing sadurunge bisa digunakake ing macem-macem bagean infrastruktur. Liyane saka layanan padha diwènèhaké backend anyar ing wangun dhemit iki.
• Kita nulis sandhi lan kunci panyimpenan pusat dhewe, kasedhiya kanggo kabeh layanan, sing bisa diowahi kanthi bebas kaya sing dibutuhake.
• We wrote 4 backends anyar kanggo Keystone saka ngeruk (pangguna, proyèk, peran, assignments peran), kang, ing kasunyatan, diganti database sawijining, lan saiki tumindak minangka repositori siji kanggo sandi pangguna.
• Kita mulang kabeh layanan Openstack kanggo pindhah menyang layanan kabijakan pihak katelu kanggo kawicaksanan tinimbang maca kabijakan kasebut sacara lokal saka saben server (ya, kaya mengkono Openstack minangka standar!)

Pengolahan ulang utama kasebut mbutuhake owah-owahan sing gedhe, rumit lan, sing paling penting, sinkron ing sawetara sistem sing ditulis dening tim pangembangan sing beda-beda. Sawise dipasang, kabeh sistem kudu bisa digunakake.

Kepiye carane ngowahi owah-owahan kasebut lan ora ngaco? Kawitan kita mutusaké kanggo katon sethitik menyang mangsa.

Strategi rollout

• Bisa diluncurake produk kasebut ing pirang-pirang tahapan, nanging iki bakal nambah wektu pangembangan kaping telu. Kajaba iku, kanggo sawetara wektu kita bakal duwe desynchronization lengkap data ing database. Sampeyan kudu nulis alat sinkronisasi dhewe lan manggon ing pirang-pirang toko data nganti suwe. Lan iki nggawe macem-macem risiko.
• Kabeh sing bisa disiapake kanthi transparan kanggo pangguna wis rampung sadurunge. Butuh 2 sasi.
• Kita ngidini awake dhewe downtime nganti pirang-pirang jam - mung kanggo operasi pangguna kanggo nggawe lan ngganti sumber daya.
• Kanggo operasi kabeh sumber daya sing wis digawe, downtime ora bisa ditampa. Kita ngrancang yen sajrone rollout, sumber daya kudu bisa digunakake tanpa downtime lan mengaruhi klien.
• Kanggo nyuda impact ing pelanggan yen ana sing salah, kita mutusake kanggo muter ing dina Minggu sore. Kurang pelanggan sing ngatur mesin virtual ing wayah wengi.
• Kita ngelingake kabeh klien yen sajrone wektu sing dipilih kanggo diluncurake, manajemen layanan ora kasedhiya.

Digression: apa iku rollout?

<ati-ati, filsafat>

Saben spesialis IT bisa kanthi gampang mangsuli apa sing diluncurake. Sampeyan nginstal CI / CD, lan kabeh kanthi otomatis dikirim menyang toko. 🙂

Mesthi iki bener. Nanging kangelan yaiku kanthi alat otomatisasi pangiriman kode modern, pangerten babagan peluncuran kasebut ilang. Carane lali bab epicness saka penemuan setir nalika ndeleng transportasi modern. Kabeh dadi otomatis supaya rollout asring ditindakake tanpa mangerteni kabeh gambar.

Lan kabeh gambar kaya iki. Rollout kasusun saka papat aspek utama:

1. Pangiriman kode, kalebu modifikasi data. Contone, migrasi.
2. Rollback kode yaiku kemampuan kanggo bali yen ana sing salah. Contone, liwat nggawe serep.
3. Wektu saben operasi rollout / rollback. Sampeyan kudu ngerti wektu operasi saka rong titik pisanan.
4. Fungsi sing kena pengaruh. Perlu kanggo ngevaluasi efek positif lan negatif sing dikarepake.

Kabeh aspek kasebut kudu digatekake supaya bisa sukses. Biasane mung sing pertama, utawa paling apik sing nomer loro, sing ditaksir, banjur rollout dianggep sukses. Nanging nomer telu lan kaping papat luwih penting. Pangguna endi sing seneng yen diluncurake njupuk 3 jam tinimbang menit? Utawa yen ana sing ora perlu kena pengaruh nalika diluncurake? Utawa bakal downtime siji layanan mimpin kanggo jalaran ranyono?

Undhang-undhang 1..n, preparation kanggo release

Kaping pisanan, aku mikir babagan ringkesan rapat-rapat kita: kabeh tim, bagean-bagean, tumpukan diskusi ing titik kopi, bantahan, tes, brainstorming. Banjur aku mikir bakal ora perlu. Patang sasi pembangunan tansah kalebu iki, utamané nalika sampeyan ora nulis soko sing bisa dikirim terus, nanging siji fitur amba kanggo sistem urip. Sing mengaruhi kabeh layanan, nanging ora ana sing kudu diganti kanggo pangguna kajaba "siji tombol ing antarmuka web."

Pangerten babagan cara muter diganti saka saben rapat anyar, lan cukup signifikan. Contone, kita bakal nganyari kabeh database tagihan. Nanging kita ngetung wektu lan nyadari yen ora bisa nindakake iki ing wektu rollout sing cukup. Kita butuh meh seminggu ekstra kanggo shard lan arsip database tagihan. Lan nalika kacepetan rollout samesthine isih ora marem, kita dhawuh tambahan, hardware luwih kuat, ngendi kabeh basa nyeret. Ora amarga kita ora pengin nindakake iki kanthi cepet, nanging kabutuhan saiki ora ana pilihan.

Nalika salah siji saka kita duwe mamang manawa rollout bisa mengaruhi kasedhiyan mesin virtual, kita ngenteni seminggu kanggo nganakake tes, eksperimen, analisis kode lan entuk pangerten sing jelas manawa iki ora bakal kedadeyan ing produksi kita, lan malah wong sing paling ragu setuju. karo iki.

Ing sawetoro wektu, wong lanang saka dhukungan teknis nindakake eksperimen independen dhewe kanggo nulis instruksi kanggo klien babagan cara sambungan, sing mesthine diganti sawise diluncurake. Dheweke nggarap UX pangguna, nyiapake instruksi lan menehi konsultasi pribadi.

Kita ngotomatisasi kabeh operasi rollout sing bisa ditindakake. Saben operasi ditulis, malah sing paling gampang, lan tes terus ditindakake. Dheweke mbantah babagan cara paling apik kanggo mateni layanan kasebut - ngilangi daemon utawa mblokir akses menyang layanan kasebut kanthi firewall. Kita nggawe dhaptar mriksa tim kanggo saben tahapan rollout lan nganyari terus-terusan. Kita nggambar lan terus-terusan nganyari grafik Gantt kanggo kabeh karya sing diluncurake, kanthi wektu.

Lan supaya…

Tumindak pungkasan, sadurunge muter metu

... wis wayahe kanggo muter metu.

Kaya sing dicritakake, karya seni ora bisa rampung, mung rampung. Sampeyan kudu nggawe gaweyan saka bakal, ngerti sing ora bakal nemokake kabeh, nanging pracaya sing wis digawe kabeh pemanggih cukup, kasedhiya kanggo kabeh kasus bisa, ditutup kabeh kewan omo kritis, lan kabeh peserta nindakake kabeh padha bisa. Sing luwih akeh kode sing diluncurake, luwih angel kanggo ngyakinake dhewe babagan iki (liyane, kabeh wong ngerti manawa ora bisa diramalake kabeh).

Kita mutusake yen kita wis siyap kanggo muter nalika kita yakin yen kita wis nindakake kabeh sing bisa kanggo nutupi kabeh risiko kanggo pangguna sing ana gandhengane karo efek sing ora dikarepke lan downtimes. Sing, apa wae bisa salah kajaba:

1. Ngaruhi (suci kanggo kita, paling larang regane) infrastruktur pangguna,
2. Fungsi: panggunaan layanan sawise diluncurake kudu padha karo sadurunge.

Muter metu

Rong gulung, 8 ora ngganggu

We njupuk downtime kanggo kabeh panjalukan saka kedhaftar kanggo 7 jam. Ing wektu iki, kita duwe rencana rollout lan rencana rollback.

• Rollout dhewe njupuk kira-kira 3 jam.
• 2 jam kanggo tes.
• 2 jam - cadangan kanggo rollback bisa owah-owahan.

A grafik Gantt wis digambar munggah kanggo saben tumindak, suwene iku njupuk, apa mengkono sequentially, apa wis rampung ing podo karo.

Bagean saka grafik Gantt sing diluncurake, salah sawijining versi awal (tanpa eksekusi paralel). Alat Sinkronisasi Paling Berharga

Kabeh peserta duwe peran ing rollout sing ditemtokake, tugas apa sing ditindakake, lan tanggung jawabe. Kita nyoba kanggo nggawa saben tataran kanggo automaticity, muter metu, muter maneh, ngumpulake saran lan muter metu maneh.

Babad kedadeyan

Dadi, dina Minggu, 15 April, 29 wong teka kerja, jam 10 bengi. Saliyane peserta utama, sawetara teka mung kanggo ndhukung tim, kang khusus thanks kanggo wong-wong mau.

Iku uga worth sebutno sing tester tombol kita ing vacation. Ora mungkin diluncurake tanpa tes, kita njelajah pilihan. A rowange setuju kanggo nyoba kita saka vacation, kang ditampa matur nuwun banget saka kabeh tim.

00:00. mandeg
We mungkasi panjalukan pangguna, nyumerepi tandha ngandika karya technical. Pemantauan njerit, nanging kabeh normal. Kita priksa manawa ora ana sing ambruk kajaba sing kudune tiba. Lan kita miwiti nggarap migrasi.

Saben uwong duwe rencana rollout sing dicithak, saben wong ngerti sapa sing nindakake apa lan ing wektu apa. Sawise saben tumindak, kita mriksa wektu kanggo mesthekake yen kita ora ngluwihi, lan kabeh dadi miturut rencana. Sing ora melu rollout langsung ing tahap saiki lagi nyiapake kanthi ngluncurake dolanan online (Xonotic, tipe 3 quacks) supaya ora ngganggu kanca-kancane. 🙂

02:00. Digulung metu
Kejutan sing nyenengake - kita ngrampungake peluncuran sejam sadurunge, amarga optimasi database lan skrip migrasi kita. Jerit umum, "digulung!" Kabeh fungsi anyar ing produksi, nanging mung kita bisa ndeleng ing antarmuka. Saben uwong pindhah menyang mode testing, ngurutake menyang kelompok, lan wiwit ndeleng apa kedaden ing pungkasan.

Ora dadi apik banget, kita nyadari iki sawise 10 menit, nalika ora ana sing nyambung utawa nggarap proyek anggota tim. Sinkronisasi cepet, kita nyuwarake masalah kita, nyetel prioritas, dadi tim lan pindhah menyang debugging.

02:30. Loro masalah gedhe vs papat mata
Kita nemokake loro masalah gedhe. Kita temen maujud sing pelanggan ora bakal weruh sawetara layanan disambungake, lan masalah bakal njedhul karo akun partner. Loro-lorone amarga skrip migrasi sing ora sampurna kanggo sawetara kasus pinggir. Kita kudu ndandani saiki.

Kita nulis pitakon sing ngrekam iki, kanthi paling ora 4 mata. Kita nyoba nalika pra-produksi kanggo mesthekake yen bisa digunakake lan ora ngrusak apa-apa. Sampeyan bisa muter ing. Ing wektu sing padha, kita nganakake tes integrasi reguler, sing nuduhake sawetara masalah liyane. Kabeh mau cilik, nanging uga kudu didandani.

03:00. -2 masalah +2 masalah
Loro masalah gedhe sadurunge wis diatasi, lan meh kabeh masalah cilik. Kabeh sing ora duwe masalah ing mbenakake aktif ing akun lan nglaporake apa sing ditemokake. We prioritize, disebaraké antarane tim, lan ninggalake item non-kritis kanggo esuk.

Kita mbukak tes maneh, dheweke nemokake loro masalah gedhe anyar. Ora kabeh kabijakan layanan teka kanthi bener, mula sawetara panjaluk pangguna ora entuk wewenang. Plus masalah anyar karo akun partner. Ayo cepet-cepet ndeleng.

03:20. Sinkronisasi darurat
Siji masalah anyar didandani. Kanggo sing kapindho, kita ngatur sinkronisasi darurat. Kita ngerti apa sing kedadeyan: fix sadurunge ndandani masalah siji, nanging nggawe liyane. Kita ngaso kanggo ngerteni carane nindakake kanthi bener lan tanpa akibat.

03:30. Enem mripat
Kita ngerti apa kahanan pungkasan saka pangkalan supaya kabeh dadi apik kanggo kabeh mitra. We nulis panjalukan karo 6 mata, muter metu ing pra-produksi, nyoba, muter metu kanggo produksi.

04:00. Kabeh mlaku
Kabeh tes lulus, ora ana masalah kritis sing katon. Saka wektu kanggo wektu, ana ing tim sing ora bisa digunakake kanggo wong, kita nanggepi kanthi cepet. Paling asring weker palsu. Nanging kadhangkala ana sing ora teka, utawa kaca sing kapisah ora bisa digunakake. Kita lungguh, ndandani, ndandani, ndandani. Tim kapisah ngluncurake fitur gedhe pungkasan - tagihan.

04:30. Titik ora bali
Titik ora bali wis nyedhak, yaiku, wektu nalika, yen kita wiwit muter maneh, kita ora bakal ketemu downtime sing diwenehake marang kita. Ana masalah karo tagihan, kang mangerténi lan ngrekam kabeh, nanging stubbornly nolak kanggo nulis dhuwit saka klien. Ana sawetara bug ing kaca, tumindak, lan status individu. Fungsi utama bisa digunakake, kabeh tes lulus kanthi sukses. Kita mutusake yen rollout wis kelakon, kita ora bakal muter maneh.

06:00. Mbukak kanggo kabeh wong ing UI
Bugs didandani. Sawetara sing ora narik kawigaten pangguna ditinggalake mengko. Kita mbukak antarmuka kanggo kabeh wong. Kita terus nggarap tagihan, ngenteni umpan balik pangguna lan asil ngawasi.

07:00. Masalah karo mbukak API
Dadi cetha yen kita rada salah ngrancang beban ing API lan nguji beban iki, sing ora bisa ngenali masalah kasebut. Akibaté, ≈5% panjalukan gagal. Ayo mobilisasi lan goleki alasane.

Billing wangkal lan ora pengin bisa uga. Kita mutusake kanggo nundha nganti mengko supaya bisa nindakake owah-owahan kanthi tenang. Sing, kabeh sumber daya akumulasi ing, nanging write-off saka klien ora liwat. Mesthi, iki minangka masalah, nanging yen dibandhingake karo rollout umum, katon ora penting.

08:00. Ndandani API
We mbalek metu fix kanggo mbukak, Gagal ilang. Kita wiwiti mulih.

10:00. Kabeh
Kabeh wis didandani. Iku sepi ing ngawasi lan ing panggonan pelanggan, tim mboko sithik turu. Tagihan tetep, kita bakal mulihake sesuk.

Banjur ing wayah awan ana rollouts sing tetep log, kabar, kode bali lan kustomisasi kanggo sawetara klien kita.

Dadi, peluncuran kasebut sukses! Mesthi wae, bisa dadi luwih apik, nanging kita nggawe kesimpulan babagan apa sing ora cukup kanggo nggayuh kasampurnan.

Total

Sajrone 2 sasi persiapan aktif kanggo rollout, 43 tugas rampung, suwene saka sawetara jam nganti pirang-pirang dina.

Sajrone rollout:

• dhemit anyar lan diganti - 5 bêsik, ngganti 2 monoliths;
• owah-owahan ing basis data - kabeh 6 database kita karo data pangguna wis kena pengaruh, download wis digawe saka telung database lawas kanggo siji anyar;
• frontend rampung redesigned;
• jumlah kode sing diunduh - 33 ewu baris kode anyar, ≈ 3 ewu baris kode ing tes, ≈ 5 ewu baris kode migrasi;
• kabeh data utuh, ora mesin virtual siji customer kang rusak. 🙂

Praktek apik kanggo rollout apik

Dheweke nuntun kita ing kahanan sing angel iki. Nanging, umume, migunani kanggo ngetutake nalika diluncurake. Nanging luwih rumit rollout, luwih gedhe peran sing dimainake.

1. Wangsulan: Bab ingkang pisanan sampeyan kudu nindakake iku ngerti carane rollout bisa utawa bakal mengaruhi pangguna. Bakal ana downtime? Yen mangkono, apa downtime? Kepiye carane iki bakal mengaruhi pangguna? Apa skenario sing paling apik lan paling ala? Lan nutupi risiko.
2. Rencana kabeh. Ing saben tahap, sampeyan kudu ngerti kabeh aspek peluncuran:
   • pangiriman kode;
   • kode rollback;
   • wektu saben operasi;
   • fungsi kena pengaruh.
3. Puter liwat skenario nganti kabeh tahapan rollout, uga risiko ing saben, dadi ketok. Yen sampeyan duwe keraguan, sampeyan bisa ngaso lan mriksa tahapan sing bisa dipertanyakan kanthi kapisah.
4. Saben tahap bisa lan kudu ditingkatake yen mbantu pangguna. Contone, bakal nyuda downtime utawa mbusak sawetara risiko.
5. Pengujian rollback luwih penting tinimbang uji coba pangiriman kode. Sampeyan perlu kanggo mriksa sing minangka asil saka rollback sistem bakal bali menyang negara asli, lan konfirmasi iki karo tes.
6. Kabeh sing bisa otomatis kudu otomatis. Kabeh sing ora bisa otomatis kudu ditulis ing advance ing sheet ngapusi.
7. Rekam kriteria sukses. Apa fungsi sing kudu kasedhiya lan ing wektu apa? Yen iki ora kelakon, mbukak rencana rollback.
8. Lan sing paling penting - wong. Saben uwong kudu ngerti apa sing ditindakake, kenapa lan apa gumantung saka tumindake ing proses rollout.

Lan ing siji ukara, kanthi perencanaan lan elaborasi sing apik, sampeyan bisa muter apa wae sing dikarepake tanpa akibat kanggo dodolan. Malah soko sing bakal mengaruhi kabeh layanan ing produksi.

Source: www.habr.com