Kisah peluncuran yang memengaruhi segalanya

Musuh Realitas pada 12f-2

Pada akhir bulan April, ketika White Walkers mengepung Winterfell, sesuatu yang lebih menarik terjadi pada kami; kami melakukan peluncuran yang tidak biasa. Pada prinsipnya, kami terus meluncurkan fitur-fitur baru ke dalam produksi (seperti orang lain). Tapi yang ini berbeda. Skalanya sedemikian rupa sehingga potensi kesalahan yang kami buat akan memengaruhi semua layanan dan pengguna kami. Hasilnya, kami meluncurkan semuanya sesuai rencana, dalam periode waktu henti yang direncanakan dan diumumkan, tanpa konsekuensi terhadap penjualan. Artikel ini membahas tentang bagaimana kami mencapai hal ini dan bagaimana siapa pun dapat mengulanginya di rumah.

Sekarang saya tidak akan menjelaskan keputusan arsitektural dan teknis yang kami buat atau menceritakan cara kerjanya. Ini hanyalah catatan pinggir tentang bagaimana salah satu peluncuran tersulit terjadi, yang saya amati dan saya terlibat langsung di dalamnya. Saya tidak mengklaim kelengkapan atau detail teknisnya, mungkin akan muncul di artikel lain.

Latar belakang + fungsi apa ini?

Kami sedang membangun platform cloud Solusi Cloud Mail.ru (MCS), tempat saya bekerja sebagai direktur teknis. Dan sekarang saatnya menambahkan IAM (Manajemen Identitas dan Akses) ke platform kami, yang menyediakan manajemen terpadu untuk semua akun pengguna, pengguna, kata sandi, peran, layanan, dan banyak lagi. Mengapa diperlukan di cloud adalah pertanyaan yang jelas: semua informasi pengguna disimpan di dalamnya.

Biasanya hal-hal seperti itu mulai dibangun pada awal proyek apa pun. Namun secara historis, segalanya sedikit berbeda di MCS. MCS dibangun dalam dua bagian:

• Openstack dengan modul otorisasi Keystone sendiri,
• Hotbox (penyimpanan S3) berdasarkan proyek Mail.ru Cloud,

di sekitar tempat layanan baru kemudian muncul.

Pada dasarnya, ini adalah dua jenis otorisasi yang berbeda. Selain itu, kami menggunakan beberapa pengembangan Mail.ru terpisah, misalnya, penyimpanan kata sandi umum Mail.ru, serta konektor openid yang ditulis sendiri, berkat SSO (otorisasi ujung ke ujung) yang disediakan di panel Horizon mesin virtual (UI OpenStack asli).

Membuat IAM bagi kami berarti menghubungkan semuanya ke dalam satu sistem, sepenuhnya milik kami. Pada saat yang sama, kami tidak akan kehilangan fungsionalitas apa pun selama prosesnya, namun akan menciptakan fondasi untuk masa depan yang memungkinkan kami menyempurnakannya secara transparan tanpa melakukan pemfaktoran ulang dan menskalakannya dalam hal fungsionalitas. Juga pada awalnya, pengguna memiliki model peran untuk akses ke layanan (RBAC pusat, kontrol akses berbasis peran) dan beberapa hal kecil lainnya.

Tugasnya ternyata tidak sepele: python dan Perl, beberapa backend, layanan yang ditulis secara independen, beberapa tim pengembangan dan admin. Dan yang paling penting, ada ribuan pengguna langsung di sistem produksi tempur. Semua ini harus ditulis dan, yang paling penting, dilaksanakan tanpa menimbulkan korban jiwa.

Apa yang akan kami luncurkan?

Secara kasar, dalam waktu sekitar 4 bulan kami menyiapkan hal-hal berikut:

• Kami membuat beberapa daemon baru yang menggabungkan fungsi-fungsi yang sebelumnya berfungsi di berbagai bagian infrastruktur. Layanan lainnya diberi backend baru dalam bentuk setan-setan ini.
• Kami menulis pusat penyimpanan kata sandi dan kunci kami sendiri, tersedia untuk semua layanan kami, yang dapat dimodifikasi secara bebas sesuai kebutuhan.
• Kami menulis 4 backend baru untuk Keystone dari awal (pengguna, proyek, peran, penetapan peran), yang sebenarnya menggantikan basis datanya, dan sekarang bertindak sebagai gudang tunggal untuk kata sandi pengguna kami.
• Kami mengajarkan semua layanan Openstack kami untuk pergi ke layanan kebijakan pihak ketiga untuk mengetahui kebijakan mereka daripada membaca kebijakan ini secara lokal dari setiap server (ya, itulah cara kerja Openstack secara default!)

Pengerjaan ulang besar-besaran seperti itu memerlukan perubahan yang besar, kompleks, dan yang paling penting, sinkron dalam beberapa sistem yang ditulis oleh tim pengembangan berbeda. Setelah dirakit, seluruh sistem akan berfungsi.

Bagaimana cara menerapkan perubahan tersebut dan tidak mengacaukannya? Pertama kami memutuskan untuk melihat sedikit ke masa depan.

Strategi peluncuran

• Dimungkinkan untuk meluncurkan produk dalam beberapa tahap, tetapi ini akan meningkatkan waktu pengembangan sebanyak tiga kali lipat. Selain itu, untuk beberapa waktu kami akan melakukan desinkronisasi lengkap data dalam database. Anda harus menulis alat sinkronisasi Anda sendiri dan menggunakan banyak penyimpanan data untuk waktu yang lama. Dan hal ini menimbulkan berbagai macam risiko.
• Segala sesuatu yang dapat dipersiapkan secara transparan untuk pengguna telah dilakukan sebelumnya. Butuh waktu 2 bulan.
• Kami membiarkan diri kami mengalami downtime selama beberapa jam - hanya untuk operasi pengguna dalam membuat dan mengubah sumber daya.
• Untuk pengoperasian semua sumber daya yang sudah dibuat, waktu henti tidak dapat diterima. Kami merencanakan bahwa selama peluncuran, sumber daya harus berfungsi tanpa downtime dan berdampak pada klien.
• Untuk mengurangi dampak terhadap pelanggan kami jika terjadi kesalahan, kami memutuskan untuk meluncurkannya pada Minggu malam. Lebih sedikit pelanggan yang mengelola mesin virtual di malam hari.
• Kami memperingatkan semua klien kami bahwa selama periode yang dipilih untuk peluncuran, manajemen layanan tidak akan tersedia.

Penyimpangan: apa itu peluncuran?

<hati-hati, filosofi>

Setiap spesialis TI dapat dengan mudah menjawab apa itu peluncuran. Anda menginstal CI/CD, dan semuanya secara otomatis dikirimkan ke toko. 🙂

Tentu saja ini benar. Namun kesulitannya adalah dengan alat otomatisasi pengiriman kode modern, pemahaman tentang peluncuran itu sendiri menjadi hilang. Bagaimana Anda melupakan betapa hebatnya penemuan roda ketika melihat transportasi modern. Semuanya sangat otomatis sehingga peluncurannya sering kali dilakukan tanpa memahami gambaran keseluruhannya.

Dan gambaran keseluruhannya seperti ini. Peluncuran terdiri dari empat aspek utama:

1. Pengiriman kode, termasuk modifikasi data. Misalnya saja migrasi mereka.
2. Pengembalian kode adalah kemampuan untuk kembali jika terjadi kesalahan. Misalnya saja melalui pembuatan backup.
3. Waktu setiap operasi peluncuran/kembalikan. Anda perlu memahami waktu pengoperasian apa pun dari dua poin pertama.
4. Fungsionalitas yang terpengaruh. Penting untuk mengevaluasi dampak positif dan dampak negatif yang mungkin terjadi.

Semua aspek ini harus dipertimbangkan agar peluncuran berhasil. Biasanya hanya poin pertama, atau paling baik poin kedua, yang dinilai, dan kemudian peluncuran dianggap berhasil. Namun yang ketiga dan keempat bahkan lebih penting. Pengguna mana yang akan suka jika peluncurannya memakan waktu 3 jam, bukan satu menit? Atau jika sesuatu yang tidak perlu terpengaruh selama peluncuran? Atau akankah downtime suatu layanan menimbulkan konsekuensi yang tidak terduga?

Babak 1..n, persiapan rilis

Awalnya saya berpikir untuk menjelaskan secara singkat pertemuan kami: keseluruhan tim, bagian-bagiannya, banyak diskusi di tempat minum kopi, argumen, tes, bertukar pikiran. Lalu saya pikir itu tidak perlu. Empat bulan pengembangan selalu mencakup hal ini, terutama ketika Anda tidak menulis sesuatu yang dapat disampaikan terus-menerus, tetapi satu fitur besar untuk sistem live. Ini memengaruhi semua layanan, tetapi tidak ada yang berubah bagi pengguna kecuali “satu tombol di antarmuka web”.

Pemahaman kami tentang cara peluncuran berubah dari setiap pertemuan baru, dan cukup signifikan. Misalnya, kami akan memperbarui seluruh database penagihan kami. Namun kami menghitung waktunya dan menyadari bahwa tidak mungkin melakukan hal ini dalam waktu peluncuran yang wajar. Kami membutuhkan waktu hampir satu minggu ekstra untuk melakukan sharding dan mengarsipkan database penagihan. Dan ketika kecepatan peluncuran yang diharapkan masih belum memuaskan, kami memesan perangkat keras tambahan yang lebih kuat, yang seluruh basisnya diseret. Bukannya kami tidak ingin melakukan hal ini lebih cepat, namun kebutuhan untuk meluncurkannya saat ini membuat kami tidak punya pilihan.

Ketika salah satu dari kami ragu bahwa peluncuran dapat memengaruhi ketersediaan mesin virtual kami, kami menghabiskan waktu seminggu untuk melakukan pengujian, eksperimen, analisis kode, dan mendapatkan pemahaman yang jelas bahwa hal ini tidak akan terjadi dalam produksi kami, dan bahkan orang yang paling ragu pun setuju. dengan ini.

Sementara itu, orang-orang dari dukungan teknis melakukan eksperimen independen mereka sendiri untuk menulis instruksi kepada klien tentang metode koneksi, yang seharusnya berubah setelah peluncuran. Mereka mengerjakan UX pengguna, menyiapkan instruksi, dan memberikan konsultasi pribadi.

Kami mengotomatiskan semua operasi peluncuran yang memungkinkan. Setiap operasi telah dituliskan, bahkan yang paling sederhana sekalipun, dan pengujian terus dijalankan. Mereka berdebat tentang cara terbaik untuk mematikan layanan - menghilangkan daemon atau memblokir akses ke layanan dengan firewall. Kami membuat daftar periksa tim untuk setiap tahap peluncuran dan terus memperbaruinya. Kami menggambar dan terus memperbarui diagram Gantt untuk semua pekerjaan peluncuran, beserta waktunya.

Sehingga…

Tindakan terakhir, sebelum diluncurkan

...saatnya untuk diluncurkan.

Seperti kata pepatah, sebuah karya seni tidak bisa diselesaikan, hanya selesai dikerjakan. Anda harus berusaha dengan kemauan, memahami bahwa Anda tidak akan menemukan segalanya, namun percaya bahwa Anda telah membuat semua asumsi yang masuk akal, memperhitungkan semua kasus yang mungkin terjadi, menutup semua bug kritis, dan semua peserta melakukan semua yang mereka bisa. Semakin banyak kode yang Anda luncurkan, semakin sulit meyakinkan diri Anda tentang hal ini (selain itu, semua orang memahami bahwa tidak mungkin untuk meramalkan segalanya).

Kami memutuskan bahwa kami siap untuk meluncurkannya ketika kami yakin bahwa kami telah melakukan segala kemungkinan untuk menutupi semua risiko bagi pengguna kami yang terkait dengan dampak dan waktu henti yang tidak terduga. Artinya, segala sesuatu bisa salah kecuali:

1. Mempengaruhi infrastruktur pengguna (yang sakral bagi kami, paling berharga),
2. Fungsionalitas: penggunaan layanan kami setelah peluncuran harus sama seperti sebelum peluncuran.

Meluncurkan

Dua roll, 8 jangan ikut campur

Kami mengambil downtime untuk semua permintaan dari pengguna selama 7 jam. Saat ini, kami memiliki rencana peluncuran dan rencana pengembalian.

• Peluncurannya sendiri memakan waktu kurang lebih 3 jam.
• 2 jam untuk pengujian.
• 2 jam - cadangan untuk kemungkinan pengembalian perubahan.

Bagan Gantt telah dibuat untuk setiap tindakan, berapa lama waktu yang dibutuhkan, apa yang terjadi secara berurutan, apa yang dilakukan secara paralel.

Sepotong diagram Gantt yang diluncurkan, salah satu versi awal (tanpa eksekusi paralel). Alat Sinkronisasi Paling Berharga

Peran semua peserta dalam peluncuran telah ditentukan, tugas apa yang mereka lakukan, dan apa tanggung jawab mereka. Kami mencoba menjadikan setiap tahapan menjadi otomatis, meluncurkannya, memutarnya kembali, mengumpulkan umpan balik, dan meluncurkannya kembali.

Kronologis kejadian

Jadi, 15 orang masuk kerja pada hari Minggu tanggal 29 April jam 10 malam. Selain para peserta kunci, beberapa datang hanya untuk mendukung tim, dan terima kasih khusus kepada mereka.

Perlu juga disebutkan bahwa penguji utama kami sedang berlibur. Tidak mungkin diluncurkan tanpa pengujian, kami sedang menjajaki opsi. Seorang kolega setuju untuk menguji kami dari liburan, dan dia menerima rasa terima kasih yang sebesar-besarnya dari seluruh tim.

00:00. Berhenti
Kami menghentikan permintaan pengguna, memasang tanda yang bertuliskan pekerjaan teknis. Pengawasannya berteriak, tapi semuanya normal. Kami memeriksa bahwa tidak ada yang jatuh selain yang seharusnya jatuh. Dan kami mulai mengerjakan migrasi.

Setiap orang mempunyai rencana peluncuran yang tercetak poin demi poin, semua orang tahu siapa melakukan apa dan pada saat apa. Setelah setiap tindakan, kami memeriksa waktunya untuk memastikan kami tidak melebihinya, dan semuanya berjalan sesuai rencana. Mereka yang tidak mengikuti peluncuran secara langsung pada tahap saat ini sedang mempersiapkan diri dengan meluncurkan mainan online (Xonotic, tipe 3 quacks) agar tidak mengganggu rekan-rekannya. 🙂

02:00. Diluncurkan
Kejutan yang menyenangkan - kami menyelesaikan peluncuran satu jam lebih awal, karena optimalisasi database dan skrip migrasi kami. Seruan umum, “diluncurkan!” Semua fungsi baru sedang dalam produksi, namun sejauh ini hanya kami yang dapat melihatnya di antarmuka. Semua orang masuk ke mode pengujian, mengurutkannya ke dalam kelompok, dan mulai melihat apa yang terjadi pada akhirnya.

Ternyata tidak terlalu baik, kami menyadarinya setelah 10 menit, ketika tidak ada yang terhubung atau mengerjakan proyek anggota tim. Sinkronisasi cepat, kami menyuarakan masalah kami, menetapkan prioritas, membagi tim dan melakukan debugging.

02:30. Dua masalah besar vs empat mata
Kami menemukan dua masalah besar. Kami menyadari bahwa pelanggan tidak akan melihat beberapa layanan yang terhubung, dan masalah akan muncul dengan akun mitra. Keduanya disebabkan oleh skrip migrasi yang tidak sempurna untuk beberapa kasus edge. Kita perlu memperbaikinya sekarang.

Kami menulis pertanyaan yang mencatat ini, dengan setidaknya 4 mata. Kami mengujinya selama praproduksi untuk memastikannya berfungsi dan tidak merusak apa pun. Anda bisa berguling lebih jauh. Pada saat yang sama, kami menjalankan pengujian integrasi reguler, yang mengungkapkan beberapa masalah lagi. Semuanya kecil, tapi juga perlu diperbaiki.

03:00. -2 masalah +2 masalah
Dua masalah besar sebelumnya telah diperbaiki, dan hampir semua masalah kecil juga telah diperbaiki. Semua yang tidak terlibat dalam perbaikan secara aktif mengerjakan akun mereka dan melaporkan apa yang mereka temukan. Kami memprioritaskan, mendistribusikan antar tim, dan meninggalkan barang-barang yang tidak penting untuk pagi hari.

Kami menjalankan pengujian lagi, mereka menemukan dua masalah besar baru. Tidak semua kebijakan layanan diterima dengan benar, sehingga beberapa permintaan pengguna tidak lolos otorisasi. Ditambah masalah baru pada akun partner. Ayo buruan lihat.

03:20. Sinkronisasi darurat
Satu masalah baru telah diperbaiki. Untuk yang kedua, kami mengatur sinkronisasi darurat. Kami memahami apa yang terjadi: perbaikan sebelumnya memperbaiki satu masalah, namun menimbulkan masalah lain. Kami beristirahat sejenak untuk mencari tahu bagaimana melakukannya dengan benar dan tanpa konsekuensi.

03:30. Enam mata
Kami memahami seperti apa keadaan akhir pangkalan agar semuanya berjalan baik bagi semua mitra. Kami menulis permintaan dengan 6 mata, meluncurkannya di pra-produksi, mengujinya, meluncurkannya untuk produksi.

04:00. Semuanya berfungsi
Semua tes lulus, tidak ada masalah kritis yang terlihat. Dari waktu ke waktu, ada sesuatu dalam tim yang tidak berhasil untuk seseorang, kami segera bereaksi. Seringkali alarmnya salah. Namun terkadang ada sesuatu yang tidak sampai, atau halaman terpisah tidak berfungsi. Kami duduk, memperbaiki, memperbaiki, memperbaiki. Tim terpisah meluncurkan fitur besar terakhir - penagihan.

04:30. Titik tidak bisa kembali
Point of no return semakin dekat, yaitu saat ketika, jika kita mulai melakukan rollback, kita tidak akan memenuhi waktu henti yang diberikan kepada kita. Ada masalah dengan penagihan, yang mengetahui dan mencatat segalanya, tetapi dengan keras kepala menolak untuk menghapus uang dari klien. Ada beberapa bug pada setiap halaman, tindakan, dan status. Fungsi utama berfungsi, semua tes berhasil lulus. Kami memutuskan bahwa peluncuran telah dilakukan, kami tidak akan membatalkannya.

06:00. Terbuka untuk semua orang di UI
Bug diperbaiki. Beberapa yang tidak menarik bagi pengguna dibiarkan untuk nanti. Kami membuka antarmuka untuk semua orang. Kami terus mengerjakan penagihan, menunggu masukan pengguna dan memantau hasil.

07:00. Masalah dengan pemuatan API
Menjadi jelas bahwa kami sedikit salah merencanakan beban pada API kami dan menguji beban ini, yang tidak dapat mengidentifikasi masalahnya. Akibatnya, ≈5% permintaan gagal. Mari kita mobilisasi dan cari alasannya.

Billingnya bandel dan juga tidak mau bekerja. Kami memutuskan untuk menundanya sampai nanti agar perubahan bisa berjalan dengan tenang. Artinya, semua sumber daya diakumulasikan di dalamnya, tetapi penghapusan dari klien tidak dilakukan. Tentu saja, ini merupakan masalah, namun dibandingkan dengan peluncuran secara umum, hal ini tampaknya tidak penting.

08:00. Perbaiki API
Kami meluncurkan perbaikan untuk beban tersebut, kegagalannya hilang. Kami mulai pulang.

10:00. Semua
Semuanya sudah diperbaiki. Suasana sepi dalam pemantauan dan di tempat pelanggan, tim perlahan-lahan tertidur. Tagihannya masih ada, besok akan kami kembalikan.

Kemudian pada siang hari ada peluncuran yang memperbaiki log, notifikasi, kode pengembalian, dan penyesuaian untuk beberapa klien kami.

Jadi, peluncurannya berhasil! Tentu saja bisa lebih baik, tapi kami menarik kesimpulan tentang apa yang tidak cukup bagi kami untuk mencapai kesempurnaan.

Total

Selama 2 bulan persiapan aktif untuk peluncuran, 43 tugas telah diselesaikan, yang berlangsung dari beberapa jam hingga beberapa hari.

Selama peluncuran:

• setan baru dan berubah - 5 buah, menggantikan 2 monolit;
• perubahan dalam database - keenam database kami dengan data pengguna telah terpengaruh, pengunduhan telah dilakukan dari tiga database lama ke satu database baru;
• frontend sepenuhnya didesain ulang;
• jumlah kode yang diunduh - 33 ribu baris kode baru, ≈ 3 ribu baris kode dalam pengujian, ≈ 5 ribu baris kode migrasi;
• semua data utuh, tidak ada satu pun mesin virtual pelanggan yang rusak. 🙂

Praktik yang baik untuk peluncuran yang baik

Mereka membimbing kami dalam situasi sulit ini. Namun, secara umum, ada baiknya untuk mengikutinya selama peluncuran apa pun. Namun semakin kompleks peluncurannya, semakin besar peran yang mereka mainkan.

1. Hal pertama yang perlu Anda lakukan adalah memahami bagaimana peluncuran ini dapat atau akan memengaruhi pengguna. Apakah akan ada waktu henti? Jika ya, apa waktu hentinya? Bagaimana pengaruhnya terhadap pengguna? Apa skenario terbaik dan terburuk yang mungkin terjadi? Dan menutupi risikonya.
2. Rencanakan segalanya. Di setiap tahap, Anda perlu memahami semua aspek peluncuran:
   • pengiriman kode;
   • pengembalian kode;
   • waktu setiap operasi;
   • fungsionalitas yang terpengaruh.
3. Mainkan seluruh skenario hingga seluruh tahapan peluncuran, serta risiko di masing-masing skenario, menjadi jelas. Jika Anda memiliki keraguan terhadap sesuatu, Anda dapat beristirahat sejenak dan memeriksa tahap keraguan tersebut secara terpisah.
4. Setiap tahap dapat dan harus ditingkatkan jika membantu pengguna kami. Misalnya, hal ini akan mengurangi waktu henti atau menghilangkan beberapa risiko.
5. Pengujian rollback jauh lebih penting daripada pengujian pengiriman kode. Penting untuk memeriksa bahwa sebagai hasil dari rollback, sistem akan kembali ke keadaan semula, dan mengonfirmasi hal ini dengan pengujian.
6. Segala sesuatu yang dapat diotomatisasi harus diotomatisasi. Segala sesuatu yang tidak dapat diotomatisasi harus ditulis terlebih dahulu di lembar contekan.
7. Catat kriteria keberhasilannya. Fungsionalitas apa yang harus tersedia dan pada jam berapa? Jika ini tidak terjadi, jalankan rencana rollback.
8. Dan yang paling penting - manusia. Setiap orang harus menyadari apa yang mereka lakukan, mengapa dan apa yang bergantung pada tindakan mereka dalam proses peluncuran.

Dan dalam satu kalimat, dengan perencanaan dan elaborasi yang baik, Anda dapat meluncurkan apa pun yang Anda inginkan tanpa konsekuensi terhadap penjualan. Bahkan sesuatu yang akan mempengaruhi semua layanan Anda dalam produksi.

Sumber: www.habr.com