🥇Sejarah pelancaran, yang menjejaskan segala-galanya

Musuh Realiti oleh 12f-2

Pada penghujung April, semasa White Walkers mengepung Winterfell, sesuatu yang lebih menarik berlaku kepada kami; kami melakukan pelancaran yang luar biasa. Pada dasarnya, kami sentiasa melancarkan ciri baharu ke dalam pengeluaran (seperti orang lain). Tetapi yang ini berbeza. Skalanya sedemikian rupa sehingga sebarang kemungkinan kesilapan yang boleh kami lakukan akan menjejaskan semua perkhidmatan dan pengguna kami. Akibatnya, kami melancarkan segala-galanya mengikut rancangan, dalam tempoh masa henti yang dirancang dan diumumkan, tanpa akibat untuk jualan. Artikel ini adalah tentang cara kami mencapai ini dan cara sesiapa sahaja boleh mengulanginya di rumah.

Sekarang saya tidak akan menerangkan keputusan seni bina dan teknikal yang kami buat atau memberitahu cara semuanya berfungsi. Ini agak nota dalam margin tentang bagaimana salah satu pelancaran yang paling sukar berlaku, yang saya perhatikan dan yang saya terlibat secara langsung. Saya tidak menuntut kelengkapan atau butiran teknikal; mungkin ia akan dipaparkan dalam artikel lain.

Latar belakang + apakah jenis fungsi ini?

Kami sedang membina platform awan Penyelesaian Awan Mail.ru (MCS), tempat saya bekerja sebagai pengarah teknikal. Dan kini tiba masanya untuk menambahkan IAM (Pengurusan Identiti dan Akses) pada platform kami, yang menyediakan pengurusan bersatu bagi semua akaun pengguna, pengguna, kata laluan, peranan, perkhidmatan dan banyak lagi. Mengapa ia diperlukan dalam awan adalah soalan yang jelas: semua maklumat pengguna disimpan di dalamnya.

Biasanya perkara sedemikian mula dibina pada awal mana-mana projek. Tetapi dari segi sejarah perkara telah berbeza sedikit dalam MCS. MCS dibina dalam dua bahagian:

Openstack dengan modul kebenaran Keystone sendiri,
Hotbox (storan S3) berdasarkan projek Cloud Mail.ru,

sekitar yang mana perkhidmatan baharu muncul.

Pada asasnya, ini adalah dua jenis kebenaran yang berbeza. Selain itu, kami menggunakan beberapa perkembangan Mail.ru yang berasingan, contohnya, storan kata laluan Mail.ru am, serta penyambung openid yang ditulis sendiri, terima kasih kepada SSO (keizinan hujung-ke-hujung) disediakan dalam panel Horizon mesin maya (UI OpenStack asli).

Membuat IAM untuk kami bermakna menghubungkan semuanya ke dalam satu sistem, sepenuhnya milik kami. Pada masa yang sama, kami tidak akan kehilangan sebarang fungsi di sepanjang jalan, tetapi akan mewujudkan asas untuk masa hadapan yang akan membolehkan kami memperhalusinya secara telus tanpa memfaktorkan semula dan menskalakannya dari segi kefungsian. Juga pada permulaan, pengguna mempunyai model peranan untuk akses kepada perkhidmatan (RBAC pusat, kawalan akses berasaskan peranan) dan beberapa perkara kecil lain.

Tugas itu ternyata tidak remeh: python dan perl, beberapa bahagian belakang, perkhidmatan bertulis bebas, beberapa pasukan pembangunan dan pentadbir. Dan yang paling penting, terdapat beribu-ribu pengguna langsung pada sistem pengeluaran pertempuran. Semua ini perlu ditulis dan, yang paling penting, dilancarkan tanpa kemalangan jiwa.

Apa yang akan kita lancarkan?

Secara kasarnya, dalam masa 4 bulan kami menyediakan yang berikut:

Kami mencipta beberapa daemon baharu yang mengagregatkan fungsi yang sebelum ini berfungsi di bahagian infrastruktur yang berlainan. Selebihnya perkhidmatan telah ditetapkan bahagian belakang baharu dalam bentuk syaitan ini.
Kami menulis storan pusat kata laluan dan kunci kami sendiri, tersedia untuk semua perkhidmatan kami, yang boleh diubah suai secara bebas seperti yang kami perlukan.
Kami menulis 4 bahagian belakang baharu untuk Keystone dari awal (pengguna, projek, peranan, penugasan peranan), yang sebenarnya, menggantikan pangkalan datanya dan kini bertindak sebagai satu repositori untuk kata laluan pengguna kami.
Kami mengajar semua perkhidmatan Openstack kami untuk pergi ke perkhidmatan dasar pihak ketiga untuk dasar mereka dan bukannya membaca dasar ini secara setempat daripada setiap pelayan (ya, begitulah cara Openstack berfungsi secara lalai!)

Kerja semula utama sedemikian memerlukan perubahan besar, kompleks dan, paling penting, perubahan segerak dalam beberapa sistem yang ditulis oleh pasukan pembangunan yang berbeza. Setelah dipasang, keseluruhan sistem harus berfungsi.

Bagaimana untuk melancarkan perubahan sedemikian dan tidak merosakkannya? Mula-mula kami memutuskan untuk melihat sedikit masa depan.

Strategi pelancaran

Ia mungkin untuk melancarkan produk dalam beberapa peringkat, tetapi ini akan meningkatkan masa pembangunan sebanyak tiga kali ganda. Di samping itu, untuk beberapa waktu kami akan mempunyai penyahsegerakan lengkap data dalam pangkalan data. Anda perlu menulis alat penyegerakan anda sendiri dan hidup dengan berbilang stor data untuk masa yang lama. Dan ini mewujudkan pelbagai jenis risiko.
Segala-galanya yang boleh disediakan secara telus untuk pengguna telah dilakukan terlebih dahulu. Ia mengambil masa 2 bulan.
Kami membenarkan diri kami berhenti selama beberapa jam - hanya untuk operasi pengguna untuk mencipta dan menukar sumber.
Untuk pengendalian semua sumber yang telah dicipta, masa henti tidak boleh diterima. Kami merancang bahawa semasa pelancaran, sumber harus berfungsi tanpa masa henti dan memberi kesan kepada pelanggan.
Untuk mengurangkan kesan kepada pelanggan kami jika berlaku masalah, kami memutuskan untuk melancarkan pada petang Ahad. Lebih sedikit pelanggan mengurus mesin maya pada waktu malam.
Kami memberi amaran kepada semua pelanggan kami bahawa dalam tempoh yang dipilih untuk pelancaran, pengurusan perkhidmatan tidak akan tersedia.

Penyimpangan: apakah pelancaran?

<berhati-hati, falsafah>

Setiap pakar IT boleh menjawab dengan mudah apa itu pelancaran. Anda memasang CI/CD, dan semuanya dihantar secara automatik ke kedai. 🙂

Sudah tentu ini benar. Tetapi kesukarannya ialah dengan alat automasi penghantaran kod moden, pemahaman tentang pelancaran itu sendiri hilang. Bagaimana anda melupakan kehebatan ciptaan roda apabila melihat pengangkutan moden. Semuanya sangat automatik sehingga pelancaran sering dilakukan tanpa memahami keseluruhan gambaran.

Dan keseluruhan gambar adalah seperti ini. Pelancaran terdiri daripada empat aspek utama:

Penghantaran kod, termasuk pengubahsuaian data. Contohnya, penghijrahan mereka.
Pemulihan kod ialah keupayaan untuk kembali jika berlaku masalah. Contohnya, melalui membuat sandaran.
Masa setiap operasi pelancaran/balik semula. Anda perlu memahami masa mana-mana operasi dua mata pertama.
Kefungsian terjejas. Adalah perlu untuk menilai kedua-dua kesan positif dan kemungkinan negatif yang dijangkakan.

Semua aspek ini mesti diambil kira untuk pelancaran yang berjaya. Biasanya hanya mata pertama, atau paling baik mata kedua, dinilai, dan kemudian pelancaran dianggap berjaya. Tetapi yang ketiga dan keempat adalah lebih penting. Pengguna manakah yang suka jika pelancaran mengambil masa 3 jam dan bukannya seminit? Atau jika sesuatu yang tidak perlu terjejas semasa pelancaran? Atau adakah masa henti bagi satu perkhidmatan membawa kepada akibat yang tidak dapat diramalkan?

Akta 1..n, persediaan untuk pembebasan

Pada mulanya saya terfikir untuk menerangkan secara ringkas pertemuan kami: seluruh pasukan, bahagiannya, timbunan perbincangan di titik kopi, hujah, ujian, sumbang saran. Kemudian saya fikir ia tidak perlu. Empat bulan pembangunan sentiasa terdiri daripada ini, terutamanya apabila anda tidak menulis sesuatu yang boleh dihantar secara berterusan, tetapi satu ciri besar untuk sistem langsung. Yang memberi kesan kepada semua perkhidmatan, tetapi tiada apa yang harus berubah untuk pengguna kecuali "satu butang dalam antara muka web."

Pemahaman kami tentang cara melancarkan berubah daripada setiap mesyuarat baharu, dan agak ketara. Sebagai contoh, kami akan mengemas kini keseluruhan pangkalan data pengebilan kami. Tetapi kami mengira masa dan menyedari bahawa adalah mustahil untuk melakukan ini dalam masa pelancaran yang munasabah. Kami mengambil masa hampir seminggu tambahan untuk memecahkan dan mengarkibkan pangkalan data pengebilan. Dan apabila kelajuan pelancaran yang dijangkakan masih tidak memuaskan, kami memesan perkakasan tambahan yang lebih berkuasa, di mana seluruh pangkalan telah diseret. Bukannya kami tidak mahu melakukannya lebih awal, tetapi keperluan semasa untuk melancarkan menyebabkan kami tiada pilihan.

Apabila salah seorang daripada kami ragu-ragu bahawa pelancaran boleh menjejaskan ketersediaan mesin maya kami, kami menghabiskan masa seminggu menjalankan ujian, eksperimen, analisis kod dan menerima pemahaman yang jelas bahawa ini tidak akan berlaku dalam pengeluaran kami, malah orang yang paling ragu bersetuju dengan ini.

Sementara itu, lelaki daripada sokongan teknikal menjalankan eksperimen bebas mereka sendiri untuk menulis arahan untuk pelanggan tentang kaedah sambungan, yang sepatutnya berubah selepas pelancaran. Mereka bekerja pada UX pengguna, menyediakan arahan dan menyediakan perundingan peribadi.

Kami mengautomasikan semua operasi pelancaran yang mungkin. Setiap operasi telah diskrip, malah yang paling mudah, dan ujian sentiasa dijalankan. Mereka berhujah tentang cara terbaik untuk mematikan perkhidmatan - tinggalkan daemon atau sekat akses kepada perkhidmatan dengan tembok api. Kami membuat senarai semak pasukan untuk setiap peringkat pelancaran dan mengemas kininya secara berterusan. Kami melukis dan sentiasa mengemas kini carta Gantt untuk semua kerja pelancaran, dengan pemasaan.

Dan juga…

Tindakan terakhir, sebelum dilancarkan

... sudah tiba masanya untuk melancarkan.

Seperti yang mereka katakan, karya seni tidak boleh disiapkan, hanya selesai mengerjakannya. Anda perlu berusaha keras, memahami bahawa anda tidak akan menemui segala-galanya, tetapi percaya bahawa anda telah membuat semua andaian yang munasabah, dengan syarat untuk semua kes yang mungkin, menutup semua pepijat kritikal, dan semua peserta melakukan segala yang mereka mampu. Semakin banyak kod yang anda keluarkan, semakin sukar untuk meyakinkan diri anda tentang perkara ini (selain itu, semua orang memahami bahawa adalah mustahil untuk meramalkan segala-galanya).

Kami memutuskan bahawa kami bersedia untuk melancarkan apabila kami yakin bahawa kami telah melakukan segala yang mungkin untuk menampung semua risiko untuk pengguna kami yang berkaitan dengan kesan dan masa henti yang tidak dijangka. Iaitu, apa-apa boleh menjadi salah kecuali:

Mempengaruhi (suci kepada kami, yang paling berharga) infrastruktur pengguna,
Kefungsian: penggunaan perkhidmatan kami selepas pelancaran hendaklah sama seperti sebelum ini.

Melancarkan

Dua gulung, 8 jangan campur

Kami mengambil masa henti untuk semua permintaan daripada pengguna selama 7 jam. Pada masa ini, kami mempunyai pelan pelancaran dan pelan pemulangan semula.

Pelancaran itu sendiri mengambil masa kira-kira 3 jam.
2 jam untuk ujian.
2 jam - rizab untuk kemungkinan pemulangan semula perubahan.

Carta Gantt telah disediakan untuk setiap tindakan, berapa lama masa yang diambil, apa yang berlaku secara berurutan, apa yang dilakukan secara selari.

Sekeping carta Gantt yang dilancarkan, salah satu versi awal (tanpa pelaksanaan selari). Alat Penyegerakan Paling Berharga

Semua peserta mempunyai peranan mereka dalam pelancaran ditentukan, apa tugas yang mereka lakukan dan apa yang mereka bertanggungjawab. Kami cuba membawa setiap peringkat kepada automatik, melancarkannya, melancarkannya kembali, mengumpul maklum balas dan melancarkannya semula.

Chronicle of events

Jadi, 15 orang datang bekerja pada hari Ahad, 29 April, jam 10 malam. Sebagai tambahan kepada peserta utama, ada yang datang semata-mata untuk menyokong pasukan, yang pastinya terima kasih kepada mereka.

Perlu juga dinyatakan bahawa penguji utama kami sedang bercuti. Mustahil untuk melancarkan tanpa ujian, kami sedang meneroka pilihan. Seorang rakan sekerja bersetuju untuk menguji kami dari percutian, yang mana dia menerima ucapan terima kasih yang tidak terhingga daripada seluruh pasukan.

00:00. Berhenti
Kami menghentikan permintaan pengguna, meletakkan papan tanda yang mengatakan kerja teknikal. Pemantauan menjerit, tetapi semuanya normal. Kami menyemak bahawa tiada apa yang jatuh selain daripada yang sepatutnya jatuh. Dan kami mula bekerja pada penghijrahan.

Setiap orang mempunyai pelan pelancaran bercetak titik demi titik, semua orang tahu siapa yang melakukan apa dan pada masa apa. Selepas setiap tindakan, kami menyemak masa untuk memastikan kami tidak melebihinya, dan semuanya berjalan mengikut rancangan. Mereka yang tidak mengambil bahagian dalam pelancaran secara langsung pada peringkat semasa sedang membuat persediaan dengan melancarkan mainan dalam talian (Xonotic, jenis 3 quacks) supaya tidak mengganggu rakan sekerja mereka. 🙂

02:00. Dilancarkan
Kejutan yang menyenangkan - kami menyelesaikan pelancaran sejam lebih awal, disebabkan pengoptimuman pangkalan data dan skrip migrasi kami. Jeritan umum, "dilancarkan!" Semua fungsi baharu sedang dalam pengeluaran, tetapi setakat ini hanya kita yang boleh melihatnya dalam antara muka. Semua orang pergi ke mod ujian, menyusun mereka ke dalam kumpulan, dan mula melihat apa yang berlaku pada akhirnya.

Ia ternyata tidak begitu baik, kami menyedarinya selepas 10 minit, apabila tiada apa-apa yang disambungkan atau bekerja dalam projek ahli pasukan. Penyegerakan pantas, kami menyuarakan masalah kami, menetapkan keutamaan, memecah masuk ke dalam pasukan dan pergi ke penyahpepijatan.

02:30. Dua masalah besar vs empat mata
Kami dapati dua masalah besar. Kami menyedari bahawa pelanggan tidak akan melihat beberapa perkhidmatan yang disambungkan dan masalah akan timbul dengan akaun rakan kongsi. Kedua-duanya disebabkan skrip pemindahan yang tidak sempurna untuk beberapa kes tepi. Kita perlu memperbaikinya sekarang.

Kami menulis pertanyaan yang merekodkan ini, dengan sekurang-kurangnya 4 mata. Kami mengujinya semasa pra-pengeluaran untuk memastikan ia berfungsi dan tidak merosakkan apa-apa. Anda boleh berguling. Pada masa yang sama, kami menjalankan ujian penyepaduan biasa kami, yang mendedahkan beberapa lagi isu. Mereka semua kecil, tetapi mereka juga perlu dibaiki.

03:00. -2 masalah +2 masalah
Dua masalah besar sebelum ini telah diperbaiki, dan hampir semua masalah kecil juga. Semua mereka yang tidak sibuk dalam pembaikan sedang aktif bekerja dalam akaun mereka dan melaporkan perkara yang mereka temui. Kami mengutamakan, mengedarkan antara pasukan, dan meninggalkan item yang tidak kritikal untuk pagi itu.

Kami menjalankan ujian sekali lagi, mereka menemui dua masalah besar baharu. Tidak semua dasar perkhidmatan tiba dengan betul, jadi sesetengah permintaan pengguna tidak lulus kebenaran. Ditambah masalah baharu dengan akaun rakan kongsi. Jom cepat-cepat tengok.

03:20. Penyegerakan kecemasan
Satu isu baharu dibetulkan. Untuk yang kedua, kami menganjurkan penyegerakan kecemasan. Kami memahami perkara yang berlaku: pembetulan sebelumnya membetulkan satu masalah, tetapi mencipta masalah lain. Kami berehat untuk memikirkan cara melakukannya dengan betul dan tanpa akibat.

03:30. Enam mata
Kami memahami keadaan akhir pangkalan itu supaya semuanya berjalan lancar untuk semua rakan kongsi. Kami menulis permintaan dengan 6 mata, melancarkannya dalam pra-pengeluaran, mengujinya, melancarkannya untuk pengeluaran.

04:00. Semuanya berfungsi
Semua ujian lulus, tiada masalah kritikal yang kelihatan. Dari semasa ke semasa, sesuatu dalam pasukan tidak berfungsi untuk seseorang, kami bertindak balas dengan segera. Selalunya penggera adalah palsu. Tetapi kadangkala sesuatu tidak tiba, atau halaman yang berasingan tidak berfungsi. Kami duduk, betulkan, betulkan, betulkan. Pasukan berasingan sedang melancarkan ciri besar terakhir - pengebilan.

04:30. Titik tiada kembali
Titik tiada pulangan semakin hampir, iaitu masa apabila kita mula berguling ke belakang, kita tidak akan memenuhi masa henti yang diberikan kepada kita. Terdapat masalah dengan pengebilan, yang mengetahui dan merekodkan segala-galanya, tetapi dengan keras kepala enggan menghapuskan wang daripada pelanggan. Terdapat beberapa pepijat pada halaman, tindakan dan status individu. Fungsi utama berfungsi, semua ujian lulus dengan jayanya. Kami memutuskan bahawa pelancaran telah berlaku, kami tidak akan berundur.

06:00. Terbuka untuk semua orang dalam UI
Pepijat diperbaiki. Beberapa yang tidak menarik kepada pengguna dibiarkan untuk kemudian. Kami membuka antara muka kepada semua orang. Kami terus mengusahakan pengebilan, menunggu maklum balas pengguna dan hasil pemantauan.

07:00. Masalah dengan beban API
Ia menjadi jelas bahawa kami sedikit tersilap merancang beban pada API kami dan menguji beban ini, yang tidak dapat mengenal pasti masalahnya. Akibatnya, ≈5% permintaan gagal. Mari kita gerakkan dan cari sebabnya.

Pengebilan adalah degil dan tidak mahu bekerja juga. Kami memutuskan untuk menangguhkannya sehingga kemudian untuk melaksanakan perubahan dengan tenang. Iaitu, semua sumber terkumpul di dalamnya, tetapi hapus kira daripada pelanggan tidak diteruskan. Sudah tentu, ini adalah masalah, tetapi jika dibandingkan dengan pelancaran umum nampaknya tidak penting.

08:00. Betulkan API
Kami melancarkan pembaikan untuk beban, kegagalan telah hilang. Kami mula pulang ke rumah.

10:00. Semua
Semuanya sudah ditetapkan. Ia senyap dalam pemantauan dan di tempat pelanggan, pasukan itu beransur-ansur tidur. Pengebilan masih ada, kami akan memulihkannya esok.

Kemudian pada siang hari terdapat pelancaran yang membetulkan log, pemberitahuan, kod pemulangan dan penyesuaian untuk sesetengah pelanggan kami.

Jadi, pelancaran itu berjaya! Sudah tentu, ia boleh menjadi lebih baik, tetapi kami membuat kesimpulan tentang apa yang tidak mencukupi untuk kami mencapai kesempurnaan.

Dalam jumlah

Sepanjang 2 bulan penyediaan aktif untuk pelancaran, 43 tugasan telah diselesaikan, berlangsung dari beberapa jam hingga beberapa hari.

Semasa pelancaran:

syaitan baru dan berubah - 5 keping, menggantikan 2 monolit;
perubahan dalam pangkalan data - kesemua 6 pangkalan data kami dengan data pengguna telah terjejas, muat turun telah dibuat daripada tiga pangkalan data lama kepada satu pangkalan data baharu;
bahagian hadapan yang direka semula sepenuhnya;
jumlah kod yang dimuat turun - 33 ribu baris kod baharu, ≈ 3 ribu baris kod dalam ujian, ≈ 5 ribu baris kod migrasi;
semua data adalah utuh, tiada satu mesin maya pelanggan pun rosak. 🙂

Amalan yang baik untuk pelancaran yang baik

Mereka membimbing kami dalam keadaan yang sukar ini. Tetapi, secara amnya, adalah berguna untuk mengikutinya semasa sebarang pelancaran. Tetapi lebih kompleks pelancaran, lebih besar peranan yang mereka mainkan.

Perkara pertama yang perlu anda lakukan ialah memahami cara pelancaran boleh atau akan menjejaskan pengguna. Adakah terdapat masa rehat? Jika ya, apakah masa hentinya? Bagaimanakah ini akan menjejaskan pengguna? Apakah senario kes terbaik dan terburuk yang mungkin? Dan melindungi risiko.
Rancang segalanya. Pada setiap peringkat, anda perlu memahami semua aspek pelancaran:
- penghantaran kod;
- pemulangan kod;
- masa setiap operasi;
- kefungsian terjejas.
Main melalui senario sehingga semua peringkat pelancaran, serta risiko pada setiap senario, menjadi jelas. Jika anda mempunyai sebarang keraguan, anda boleh berehat dan memeriksa peringkat yang dipersoalkan secara berasingan.
Setiap peringkat boleh dan harus dipertingkatkan jika ia membantu pengguna kami. Contohnya, ia akan mengurangkan masa henti atau mengalih keluar beberapa risiko.
Ujian gulung balik adalah lebih penting daripada ujian penghantaran kod. Adalah perlu untuk menyemak bahawa sebagai hasil daripada pemulangan semula sistem akan kembali ke keadaan asalnya, dan mengesahkannya dengan ujian.
Semua yang boleh diautomasikan hendaklah diautomasikan. Segala sesuatu yang tidak boleh diautomatikkan hendaklah ditulis terlebih dahulu pada helaian tipu.
Catat kriteria kejayaan. Apakah fungsi yang perlu ada dan pada masa berapa? Jika ini tidak berlaku, jalankan pelan rollback.
Dan yang paling penting - orang. Semua orang harus sedar tentang apa yang mereka lakukan, mengapa dan apa yang bergantung pada tindakan mereka dalam proses pelancaran.

Dan dalam satu ayat, dengan perancangan dan perincian yang baik, anda boleh melancarkan apa sahaja yang anda inginkan tanpa akibat untuk jualan. Malah sesuatu yang akan menjejaskan semua perkhidmatan anda dalam pengeluaran.

Sumber: www.habr.com

Cerita pelancaran yang mempengaruhi segala-galanya