Sebuah kisah peluncuran yang memengaruhi segalanya

Musuh Realitas oleh 12f-2

Pada akhir April, ketika pejalan kaki putih mengepung Winterfell, sesuatu yang lebih menarik terjadi pada kami, kami melakukan peluncuran yang tidak biasa. Pada prinsipnya, kami terus-menerus memutar fitur-fitur baru di prod (seperti orang lain). Tapi yang ini tidak seperti orang lain. Skalanya sedemikian rupa sehingga potensi kesalahan apa pun yang dapat kami lakukan akan memengaruhi semua layanan dan pengguna kami. Sebagai hasilnya, kami meluncurkan semuanya sesuai rencana, pada waktu henti yang direncanakan dan diumumkan, tanpa konsekuensi untuk penjualan. Artikel ini adalah tentang bagaimana kita mencapai ini dan bagaimana mereka yang berharap dapat mengulanginya di rumah.

Sekarang saya tidak akan menggambarkan keputusan arsitektur dan teknis kami, katakan bagaimana semuanya bekerja. Ini adalah catatan pinggir yang lebih mungkin tentang bagaimana salah satu peluncuran paling sulit terjadi, yang saya amati dan di mana saya mengambil bagian langsung. Saya tidak berpura-pura rincian lengkap atau teknis, mungkin mereka akan muncul di artikel lain.

Latar Belakang + fungsionalitas macam apa ini

Kami sedang membangun platform cloud Mail.ru Cloud Solutions (MCS), tempat saya bekerja sebagai CTO. Dan sekarang - saatnya untuk melampirkan platform IAM kami (Identity and Access Management), yang menyediakan manajemen terpadu dari 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 setiap proyek. Tetapi MCS secara historis sedikit berbeda. MCS dibangun dalam dua bagian:

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

di mana layanan baru kemudian muncul.

Pada dasarnya, ini adalah dua jenis otorisasi. Plus, kami menggunakan beberapa perkembangan Mail.ru terpisah, misalnya, penyimpanan kata sandi Mail.ru umum, serta konektor openid yang ditulis sendiri, yang mengaktifkan SSO (otorisasi pass-through) di panel Horizon mesin virtual (native OpenStack UI).

Melakukan IAM berarti bagi kita untuk menggabungkan semua ini menjadi satu sistem, sepenuhnya milik kita sendiri. Pada saat yang sama, jangan kehilangan fungsionalitas di sepanjang jalan, buat cadangan untuk masa depan, yang akan memungkinkan kita untuk memodifikasinya secara transparan tanpa refactoring, dan skala dalam hal fungsionalitas. Juga pada awalnya, pengguna muncul model peran akses ke layanan (RBAC pusat, kontrol akses berbasis peran) dan beberapa hal kecil lainnya.

Tugas itu ternyata non-sepele: python dan perl, beberapa backend, layanan yang ditulis secara independen, beberapa tim pengembangan dan admin. Dan yang paling penting, ribuan pengguna langsung di sistem produksi tempur. Semua ini harus ditulis dan, yang paling penting, diluncurkan tanpa korban.

Apa yang akan kita mulai

Jika ini sangat kasar, di suatu tempat dalam 4 bulan kami menyiapkan ini:

• Mereka membuat beberapa setan baru yang mengagregasi fungsi-fungsi yang sebelumnya bekerja di berbagai bagian infrastruktur. Layanan lain diresepkan backend baru dalam bentuk setan ini.
• Kami menulis repositori kata sandi dan kunci utama kami sendiri, tersedia untuk semua layanan kami, yang dapat dimodifikasi secara bebas sesuai kebutuhan.
• Dari awal, mereka menulis 4 backend baru untuk Keystone (pengguna, proyek, peran, penetapan peran), yang, pada kenyataannya, menggantikan basisnya, dan sekarang bertindak sebagai repositori tunggal kata sandi pengguna kami.
• Kami mengajarkan semua layanan Openstack kami untuk menjalankan kebijakan mereka ke layanan kebijakan pihak ketiga alih-alih membaca kebijakan ini secara lokal dari setiap server (ya, secara default Openstack berfungsi seperti itu!)

Perubahan besar seperti itu membutuhkan perubahan besar, kompleks, dan yang paling penting, sinkron dalam beberapa sistem yang ditulis oleh tim pengembangan yang berbeda. Setelah perakitan, seluruh sistem harus bekerja.

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

Strategi Peluncuran

• Dimungkinkan untuk diluncurkan dalam beberapa tahap, tetapi ini akan meningkatkan waktu pengembangan sebanyak tiga kali. Selain itu, untuk beberapa waktu kami akan melakukan desinkronisasi data secara lengkap dalam database. Saya harus menulis alat sinkronisasi saya sendiri dan hidup dengan beberapa gudang data untuk waktu yang lama. Dan ini menciptakan berbagai macam risiko.
• Segala sesuatu yang dapat mereka persiapkan secara transparan untuk pengguna telah dilakukan sebelumnya. Butuh 2 bulan.
• Kami membiarkan diri kami downtime selama beberapa jam - hanya untuk operasi pengguna untuk membuat dan memodifikasi sumber daya.
• Untuk pekerjaan semua sumber daya yang sudah dibuat, downtime tidak dapat diterima. Kami merencanakan bahwa ketika meluncurkan sumber daya harus bekerja tanpa downtime dan mempengaruhi pelanggan.
• Untuk mengurangi dampak pada pelanggan kami, jika terjadi kesalahan, kami memutuskan untuk meluncurkannya pada hari Minggu malam. Di malam hari, lebih sedikit pelanggan yang mengelola mesin virtual.
• Kami memperingatkan semua pelanggan kami bahwa selama periode yang dipilih untuk peluncuran, manajemen layanan tidak akan tersedia.

Digresi: apa itu peluncuran?

<filosofi hati-hati>

Setiap spesialis IT akan dengan mudah menjawab apa itu peluncuran. Anda meletakkan CI / CD, dan secara otomatis semuanya dikirimkan ke prod. :)

Tentu saja ini benar. Tetapi kesulitannya adalah bahwa dengan alat-alat modern untuk mengotomatisasi pengiriman kode, pemahaman tentang rolling itu sendiri hilang. Bagaimana Anda melupakan penemuan epik roda, melihat kendaraan modern. Semuanya begitu otomatis sehingga peluncuran sering dilakukan tanpa menyadari keseluruhan gambar.

Dan keseluruhan gambarnya adalah sebagai berikut. Peluncuran terdiri dari empat aspek besar:

1. Pengiriman kode, termasuk modifikasi data. Misalnya, migrasi mereka.
2. Rollback kode - kemampuan untuk mengembalikan jika terjadi kesalahan. Misalnya, melalui pembuatan cadangan.
3. Waktu setiap operasi roll-out / rollback. Seseorang harus memahami waktu dari operasi apa pun dari dua poin pertama.
4. Fungsionalitas yang terpengaruh. Penting untuk mengevaluasi dampak positif dan kemungkinan negatif yang diharapkan.

Semua aspek ini harus diperhitungkan untuk keberhasilan peluncuran. Biasanya mereka hanya mengevaluasi poin pertama, terbaik, poin kedua, dan kemudian peluncuran dianggap berhasil. Tetapi yang ketiga dan keempat bahkan lebih penting. Pengguna mana yang akan menyukainya jika peluncurannya memakan waktu 3 jam, bukan satu menit? Atau jika sesuatu yang berlebihan mempengaruhi peluncuran? Atau downtime satu layanan akan menyebabkan konsekuensi yang tidak terduga?

Act 1..n, persiapan untuk rilis

Pada awalnya, saya berpikir tentang menggambarkan secara singkat pertemuan kami: seluruh tim, bagian-bagiannya, banyak diskusi dalam poin kopi, perselisihan, tes, badai otak. Kemudian saya berpikir bahwa itu akan berlebihan. Empat bulan pengembangan selalu terdiri dari ini, terutama ketika Anda menulis bukan sesuatu yang dapat disampaikan terus-menerus, tetapi satu fitur besar pada sistem kehidupan. Yang memengaruhi semua layanan, tetapi pengguna tidak boleh mengubah apa pun kecuali "satu tombol di antarmuka web."

Pemahaman kami tentang cara meluncurkan, berubah dari setiap pertemuan baru, dan sangat signifikan. Misalnya, kami akan memperbarui seluruh basis penagihan kami. Tetapi mereka menghitung waktu dan menyadari bahwa tidak mungkin untuk melakukan ini dalam waktu peluncuran yang masuk akal. Kami membutuhkan hampir satu minggu tambahan untuk shard dan mengarsipkan database penagihan. Dan ketika kecepatan peluncuran yang diharapkan tidak berhasil setelah itu, mereka memesan setrika tambahan yang lebih kuat, di mana mereka menyeret seluruh pangkalan. Bukannya kami tidak ingin melakukan ini sebelumnya, tetapi kebutuhan saat ini untuk meluncurkan tidak meninggalkan kami pilihan.

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

Sementara itu, orang-orang techsupport melakukan percobaan independen mereka untuk menulis instruksi kepada klien tentang cara menghubungkan, yang harus berubah setelah diluncurkan. Mereka mengerjakan UX yang mudah digunakan, menyiapkan instruksi, dan memberikan saran pribadi.

Kami telah mengotomatiskan semua operasi peluncuran yang dimungkinkan. Setiap operasi ditulis, bahkan yang paling sederhana, terus-menerus mengendarai tes. Mereka berdebat tentang cara terbaik untuk mematikan layanan - menurunkan daemon atau memblokir akses ke layanan dengan firewall. Daftar tim dibuat untuk setiap tahap peluncuran, itu terus diperbarui. Kami menggambar dan terus memperbarui bagan Gantt untuk semua pekerjaan peluncuran, dengan timing.

Jadi ...

Babak terakhir, sebelum diluncurkan

... saatnya untuk memulai.

Seperti kata pepatah, sebuah karya seni tidak dapat diselesaikan, hanya untuk menyelesaikannya. Penting untuk melakukan upaya yang keras, memahami bahwa Anda tidak akan menemukan segalanya, tetapi percaya bahwa Anda membuat semua asumsi yang masuk akal, menyediakan semua kemungkinan kasus, menutup semua bug penting, dan semua peserta melakukan semua yang mereka bisa. Semakin banyak kode yang Anda keluarkan, semakin sulit untuk meyakinkan diri sendiri tentang hal ini (selain itu, siapa pun mengerti bahwa tidak mungkin untuk meramalkan segalanya).

Kami memutuskan bahwa kami siap untuk meluncurkan ketika kami yakin bahwa kami telah melakukan segala yang mungkin untuk menutup semua risiko bagi pengguna kami yang terkait dengan dampak dan waktu henti yang tidak terduga. Artinya - apa pun bisa salah kecuali:

1. Pengaruh (sakral bagi kami, yang paling berharga) dari infrastruktur pengguna,
2. Fungsi: penggunaan layanan kami setelah peluncuran harus sama dengan sebelumnya.

Luncurkan

Dua bergulir, 8 tidak mengganggu

Kami mengambil downtime untuk semua permintaan dari pengguna dalam 7 jam. Saat ini, kami memiliki rencana roll-out dan rollback.

• Peluncuran itu sendiri memakan waktu sekitar 3 jam.
• 2 jam - untuk pengujian.
• 2 jam - cadangan untuk kemungkinan kembalikan perubahan.

Bagan Gantt telah dikompilasi untuk setiap tindakan, berapa banyak waktu yang dibutuhkan, apa yang berjalan secara berurutan, apa yang dilakukan secara paralel.


Sepotong grafik peluncuran Gantt, salah satu versi sebelumnya (tanpa eksekusi paralel). Alat sinkronisasi paling berharga

Semua peserta memiliki peran mereka dalam meluncurkan, tugas apa yang mereka lakukan, yang menjadi tanggung jawab mereka. Kami mencoba menjadikan setiap tahap otomatis, memutar kembali, mengumpulkan umpan balik, dan memutar lagi.

Kronik peristiwa

Jadi, 15 orang datang untuk bekerja pada hari Minggu, 28 April, jam 10 malam. Selain peserta utama, beberapa datang hanya untuk mendukung tim, yang berkat khusus untuk mereka.

Secara terpisah, perlu disebutkan bahwa penguji utama kami sedang berlibur. Tidak mungkin diluncurkan tanpa pengujian, kami sedang mengerjakan opsi. Seorang kolega setuju untuk menguji kami keluar dari liburan, yang karenanya ia memiliki rasa terima kasih yang tak terukur dari seluruh tim.

00:00 Berhenti
Kami menghentikan permintaan pengguna, menutup papan nama, kata mereka, pekerjaan teknis. Pemantauan berteriak, tetapi semuanya normal. Kami memverifikasi bahwa tidak ada yang jatuh, kecuali harus. Dan kami mulai bekerja pada migrasi.

Setiap orang memiliki rencana peluncuran dicetak untuk poin, semua orang tahu siapa yang melakukan apa dan pada titik apa. Setelah setiap tindakan, kami memeriksa dengan waktu yang tidak melebihi mereka, dan semuanya berjalan sesuai rencana. Mereka yang tidak terlibat dalam peluncuran langsung pada tahap saat ini, bersiaplah dengan meluncurkan mainan online (Xonotic, tipe 3 kwaki), agar tidak mengganggu rekan kerja. :)

02:00 pagi Diluncurkan
Kejutan yang menyenangkan - kami selesai meluncurkan satu jam sebelumnya, karena optimalisasi basis data dan skrip migrasi kami. Seruan universal, "diluncurkan!" Semua fungsi baru di prod, tapi sejauh ini hanya kita yang bisa melihat antarmuka. Semua orang masuk ke mode uji coba, disortir menjadi tumpukan, dan mulai melihat apa yang terjadi pada akhirnya.

Itu tidak berhasil dengan baik, kami memahami ini setelah 10 menit, ketika tidak ada yang terhubung dan tidak berfungsi dalam proyek anggota tim. Sinkronisasi cepat, suara masalah kami, prioritaskan, bongkar tim dan masuk ke debug.

2:30 pagi Dua masalah besar vs empat mata
Kami menemukan dua masalah besar. Kami menyadari bahwa pelanggan tidak akan melihat beberapa layanan yang terhubung, dan akan ada masalah dengan akun mitra. Keduanya terkait dengan skrip migrasi yang tidak sempurna untuk beberapa kasus tepi. Kami harus memperbaikinya sekarang.

Kami menulis pertanyaan yang memperbaiki ini, setidaknya 4 mata. Kami menggulung pre-gate untuk memastikan bahwa mereka berfungsi dan tidak merusak apa pun. Anda bisa melanjutkan. Secara paralel, pengujian integrasi biasa kami mulai, yang mendeteksi beberapa masalah lagi. Semuanya kecil, tetapi juga perlu diperbaiki.

03:00 pagi -2 Masalah +2 masalah
Dua masalah besar sebelumnya telah diperbaiki, hampir semua masalah kecil juga. Semua orang yang tidak terlibat dalam perbaikan secara aktif bekerja di akun mereka dan melaporkan apa yang mereka temukan. Kami memprioritaskan, mendistribusikan dengan perintah, meninggalkan tidak kritis di pagi hari.

Menjalankan tes lagi, mereka mengungkapkan dua masalah besar baru. Tidak semua kebijakan layanan tiba dengan benar, sehingga beberapa permintaan pengguna tidak diautentikasi. Ditambah masalah baru dengan akun mitra. Kami bergegas menonton.

03.20. Sinkronisasi darurat
Satu masalah baru diperbaiki. Untuk yang kedua, kami mengatur sinkronisasi darurat. Kami memahami apa yang terjadi: perbaikan sebelumnya memperbaiki satu masalah, tetapi membuat yang lain. Kami mengambil istirahat untuk mencari tahu bagaimana melakukannya dengan benar dan tanpa konsekuensi.

03:30 pagi Enam mata
Kami menyadari apa yang seharusnya menjadi kondisi akhir pangkalan sehingga semuanya baik untuk semua mitra. Kami menulis permintaan di 6 mata, berguling di pra-batang, tes, berguling di prod.

04:00. Semuanya berfungsi
Semua tes lulus, tidak ada masalah kritis yang terlihat. Dari waktu ke waktu, sesuatu tidak berfungsi dalam tim, kami merespons dengan cepat. Paling sering, alarm salah. Tetapi kadang-kadang sesuatu tidak mencapai, di suatu tempat halaman terpisah tidak berfungsi. Kami duduk, memperbaiki, memperbaiki, memperbaiki. Tim terpisah meluncurkan fitur besar terakhir - penagihan.

04:30. Point of no return
Titik tidak bisa kembali mendekati, yaitu, waktu ketika, jika kita mulai memutar kembali, kita tidak akan memenuhi waktu henti yang diberikan kepada kita. Ada masalah dengan penagihan, yang mengetahui segalanya dan menulis, tetapi keras kepala tidak ingin menghapus uang dari pelanggan. Ada beberapa bug pada halaman individu, tindakan, status. Fungsi utama berfungsi, semua tes berhasil lulus. Kami memutuskan bahwa peluncuran berlangsung, kami tidak akan mundur.

06:00 pagi Kami membuka sama sekali di UI
Bug diperbaiki. Beberapa pengguna yang tidak memengaruhi dibiarkan kemudian. Kami membuka antarmuka untuk semua orang. Kami terus menyulap tagihan, menunggu umpan balik pengguna dan hasil pemantauan.

07:00 pagi Masalah pemuatan API
Menjadi jelas bahwa kami memiliki sedikit perencanaan beban yang salah pada API kami dan menguji beban ini, yang tidak dapat mengidentifikasi masalah. Akibatnya, ≈5% dari permintaan gagal. Kami memobilisasi, mencari alasan.

Tagihan keras kepala, tidak mau bekerja juga. Kami memutuskan untuk menundanya nanti untuk membuat perubahan dalam mode tenang. Artinya, semua sumber daya di dalamnya diakumulasikan, tetapi penghapusan dari pelanggan tidak lulus. Tentu saja, ini merupakan masalah, tetapi dibandingkan dengan peluncuran secara umum, hal itu tampaknya tidak mendasar.

08:00. Perbaiki API
Kami meluncurkan perbaikan untuk beban, yang gagal tersisa. Kami mulai pulang.

10 pagi Semua
Semuanya sudah diperbaiki. Dalam pemantauan dan pelanggan diam, tim secara bertahap pergi tidur. Penagihan tetap, kami akan mengembalikannya besok.

Kemudian pada siang hari ada peluncuran yang memperbaiki log, notifikasi, kode pengembalian dan kode kustom dari beberapa pelanggan kami.

Jadi, peluncurannya berhasil! Tentu saja, itu bisa lebih baik, tetapi kami membuat kesimpulan tentang apa yang tidak cukup untuk mencapai kesempurnaan.

Total

Dalam 2 bulan persiapan aktif untuk waktu peluncuran, 43 tugas diselesaikan, berlangsung dari beberapa jam hingga beberapa hari.

Selama peluncuran:

• setan baru dan yang berubah - 5 buah, menggantikan 2 monolit;
• perubahan di dalam basis data - semua 6 dari basis data kami dengan data pengguna terpengaruh, dibongkar dari tiga basis data lama ke satu yang baru selesai;
• frontend sepenuhnya ulang;
• jumlah kode yang diunduh - 33 ribu baris kode baru, ≈ 3 ribu baris kode dalam tes, ≈ 5 ribu baris kode migrasi;
• semua data utuh, tidak ada mesin virtual tunggal dari pelanggan yang menderita. :)

Praktik yang baik untuk peluncuran yang baik

Kami dibimbing oleh mereka dalam situasi yang sulit ini. Tetapi, secara umum, berguna untuk mengamati mereka dalam peluncuran apa pun. Namun semakin sulit peluncurannya, semakin besar peran yang mereka mainkan.

1. Hal pertama yang perlu Anda lakukan adalah memahami bagaimana peluncuran dapat memengaruhi atau memengaruhi pengguna. Akankah ada downtime? Jika demikian, lalu apa itu downtime? Bagaimana ini akan mempengaruhi pengguna? Apa skenario terbaik dan terburuk? Dan tutup risikonya.
2. Rencanakan semuanya. Pada setiap tahap, Anda perlu memahami semua aspek peluncuran:
   
   • pengiriman kode;
   • kembalikan kode;
   • waktu setiap operasi;
   • fungsionalitas yang terpengaruh.
3. Mainkan skenario sampai semua tahap peluncuran jelas, serta risiko pada masing-masing tahap. Jika ragu, Anda dapat beristirahat dan menjelajahi tahap meragukan secara terpisah.
4. Setiap tahap dapat dan harus ditingkatkan jika itu membantu pengguna kami. Misalnya, ini akan mengurangi waktu henti atau menghilangkan beberapa risiko.
5. Menguji rollback jauh lebih penting daripada menguji pengiriman kode. Penting untuk memverifikasi bahwa sebagai akibat dari rollback, sistem akan kembali ke kondisi semula, konfirmasikan ini dengan pengujian.
6. Segala sesuatu yang dapat diotomatisasi harus diotomatisasi. Segala sesuatu yang tidak dapat diotomatisasi harus ditulis sebelumnya pada lembar contekan.
7. Catat kriteria keberhasilan. Fungsi apa yang harus tersedia dan kapan? Jika ini tidak terjadi, mulailah rencana kembalikan.
8. Dan yang paling penting, orang-orang. Setiap orang harus menyadari apa yang dia lakukan, untuk apa dan apa yang tergantung pada tindakannya dalam proses peluncuran.

Dan jika dalam satu kalimat, maka dengan perencanaan dan elaborasi yang baik, Anda dapat meluncurkan apa pun yang Anda inginkan tanpa konsekuensi untuk penjualan. Bahkan itu mempengaruhi semua layanan Anda di prod.