Get best of the week

Kisah burung Dodo dari genus Phoenix. Kejatuhan Besar Dodo ADALAH

Setiap tahun pada tanggal 21 April, kita mengingat sejarah Kejatuhan Besar Dodo IS pada tahun 2018. Masa lalu adalah guru yang kejam tapi adil. Pantas untuk diingat, mengulangi pelajaran, meneruskan akumulasi pengetahuan kepada generasi baru dan memperlakukan dengan penuh syukur siapa kita sekarang. Di bawah potongan, kami ingin menceritakan kepada Anda sebuah kisah tentang bagaimana itu dan membagikan kesimpulan. Anda bahkan tidak bisa berharap situasi seperti itu kepada musuh.




Sejarah Kejatuhan Besar


Hari 1. Kecelakaan yang menelan biaya jutaan rubel


Pada hari Sabtu, 21 April 2018, sistem Dodo IS jatuh. Jatuh sangat buruk. Selama beberapa jam, pelanggan kami tidak dapat melakukan pemesanan baik melalui situs atau melalui aplikasi seluler. Jalur panggilan ke pusat panggilan telah berkembang sedemikian rupa sehingga suara otomatis dari mesin penjawab mengatakan: "Kami akan menelepon kembali dalam 4 jam."



Hari itu kami mengalami salah satu kejatuhan paling serius dari Dodo IS. Yang terburuk adalah sehari sebelum kami meluncurkan kampanye iklan TV federal pertama dengan anggaran 100 juta rubel. Itu adalah acara yang hebat untuk Dodo Pizza. Tim TI juga dipersiapkan dengan baik untuk kampanye. Kami mengotomatiskan dan menyederhanakan penyebaran - sekarang dengan bantuan satu tombol di TeamCity kami dapat menyebarkan monolit di 12 negara. Kami tidak melakukan segala yang mungkin dan karena itu mengacaukannya.

Kampanye iklan sangat mengagumkan. Kami menerima 100-150 pesanan per menit. Itu berita bagus. Berita buruknya: Dodo IS tidak bisa menahan beban seperti itu dan mati. Kami mencapai batas skala vertikal dan tidak dapat lagi memproses pesanan. Sistem tidak stabil selama sekitar tiga jam, pulih secara berkala, tetapi segera jatuh lagi. Setiap menit downtime menghabiskan puluhan ribu rubel, tidak termasuk hilangnya rasa hormat dari pelanggan yang marah. Tim pengembangan mengecewakan semua orang: pelanggan, mitra, orang-orang di restoran pizza dan pusat panggilan.



Kami tidak punya pilihan selain menyingsingkan lengan baju kami dan duduk untuk memperbaiki situasi. Sejak Minggu (22 April), kami bekerja dalam mode keras, kami tidak punya hak untuk melakukan kesalahan.

Berikut ini adalah ringkasan pengalaman kami tentang bagaimana menemukan diri kami dalam situasi seperti itu dan bagaimana keluar dari situ nanti. Teman-teman, jangan membuat kesalahan kami.

Dua Kegagalan Yang Meluncurkan Efek Domino


Layak dimulai dengan bagaimana semuanya dimulai dan di mana kita mengacau.



Pada hari Sabtu, 04/21/2018 sekitar pukul 5:00 malam, kami perhatikan bahwa jumlah kunci dalam basis data mulai bertambah - pertanda masalah. Kami memiliki runbook yang siap untuk dipecahkan, karena kami mengerti dari mana kunci-kunci ini berasal.

Semuanya beres setelah runbook gagal dua kali. Selama beberapa menit, pangkalan kembali normal, dan sekali lagi mulai tersedak kunci. Sayangnya, rollback_on_timeout database master memiliki 600 detik, itulah sebabnya semua kunci terakumulasi. Ini adalah file penting pertama dalam cerita ini. Pengaturan sederhana dapat menyimpan semuanya.

Kemudian ada upaya untuk menghidupkan kembali sistem dengan banyak cara, tidak ada yang berhasil. Hingga kami menyadari bahwa ada perbedaan dalam skema penerimaan pesanan di aplikasi seluler dan di situs baru. Memotong mereka pada gilirannya, kami bisa memahami di mana lubang dalam skema pengambilan pesanan lama.

Sistem penerimaan pesanan telah ditulis sejak lama. Pada saat itu, sudah diproses, dan diluncurkan di situs baru dodopizza.ru. Itu tidak digunakan dalam aplikasi seluler. Awalnya, alasan untuk membuat skema pemesanan baru terkait dengan aturan bisnis murni, masalah kinerja bahkan tidak ada dalam agenda. Ini adalah file penting kedua - kami tidak tahu batas sistem kami.

Hari 2. Eliminasi Kecelakaan


Tanggapan tim sangat terbuka. Stasiun layanan kami menulis posting di Slack, dan semua orang datang keesokan harinya - pada 22 April, pekerjaan dimulai pukul 8:30 pagi. Tidak ada yang perlu dibujuk atau diminta datang pada hari libur mereka. Semua orang mengerti segalanya: apa yang perlu didukung, dibantu, dengan tangannya, dengan kepalanya, dalam pengujian, optimisasi kueri, infrastruktur. Beberapa bahkan datang dengan seluruh keluarga! Orang-orang dari tim tetangga, tidak terkait dengan IT, datang ke kantor dengan makanan, dan pusat panggilan membawa pasukan tambahan untuk berjaga-jaga. Semua tim bersatu dalam satu tujuan - untuk bangkit!



Penerimaan baru pesanan adalah tujuan utama pada hari Minggu, 22 April. Kami memahami bahwa puncak pesanan akan sebanding dengan hari Sabtu. Kami memiliki tenggat waktu paling parah - pukul 17.00, pesanan baru akan jatuh.

Pada hari ini, kami bertindak sesuai dengan rencana "untuk memastikan bahwa itu tidak jatuh", yang kami kerjakan pada malam hari ke-21 di malam hari, ketika kami telah meningkatkan sistem dan memahami apa yang telah terjadi. Rencana itu secara kondisional dibagi menjadi 2 bagian:

  1. Implementasi skema dengan tatanan baru dalam aplikasi mobile.
  2. Optimalisasi proses pembuatan pesanan.

Dengan menerapkan hal-hal ini, kita dapat yakin bahwa Dodo IS tidak akan jatuh.

Kami menentukan bagian depan pekerjaan dan pekerjaan


Implementasi skema dengan tatanan baru dalam aplikasi mobile adalah prioritas tertinggi. Kami tidak memiliki angka pasti untuk keseluruhan skema, tetapi di beberapa bagian, jumlah dan kualitas kueri ke database, kami dengan ahli memahami bahwa itu akan memberikan peningkatan produktivitas. Tim yang terdiri dari 15 orang bekerja pada tugas itu hari demi hari.

Meskipun sebenarnya pengenalan skema pemesanan baru, kami mulai sebelum musim gugur 04,21., Tapi tidak menyelesaikan kesepakatan. Masih ada bug aktif dan tugas digantung dalam keadaan semi-aktif.

Tim membagi regresi menjadi beberapa bagian: regresi dari dua platform seluler, ditambah manajemen pizzeria. Kami menghabiskan banyak waktu secara manual untuk menyiapkan pizza pengujian, tetapi pemisahan yang jelas membantu memparalelkan regresi manual.

Segera setelah beberapa perubahan diperkenalkan, segera dikerahkan ke lingkungan pra-produksi dan langsung diuji. Tim selalu berhubungan satu sama lain, mereka benar-benar hanya duduk di sebuah ruangan besar dengan hangout. Orang-orang dari Nizhny Novgorod dan Syktyvkar juga selalu berhubungan. Jika ada colokan, dia langsung memutuskan.

Biasanya kami menghadirkan fungsionalitas baru secara bertahap: 1 pizza, 5 pizza, 10 pizza, 20 pizza, dan seterusnya ke seluruh jaringan secara bertahap. Waktu itu kami perlu bertindak lebih tegas. Kami tidak punya waktu - pada pukul 5 malam, puncak baru dimulai. Kami tidak bisa gagal menangkapnya.

Sekitar pukul 15:00 pembaruan diluncurkan ke setengah jaringan (ini adalah sekitar 200 pizza). Pukul 15:30 kami memastikan semuanya bekerja dengan baik dan menyalakan seluruh jaringan. Matikan fitur, penyebaran cepat, regresi dipecah menjadi beberapa bagian dan API diperbaiki membantu melakukan semua ini.

Anggota tim lainnya berurusan dengan opsi pengoptimalan yang berbeda saat membuat pesanan. Skema baru itu tidak sepenuhnya baru, masih menggunakan bagian warisan. Menyimpan alamat, menerapkan kode promosi, menghasilkan nomor pesanan - bagian ini adalah dan tetap umum. Optimalisasi mereka dikurangi menjadi penulisan ulang query SQL sendiri, atau untuk menghilangkan mereka dalam kode, atau untuk mengoptimalkan panggilan mereka. Sesuatu masuk dalam mode asinkron, sesuatu, ternyata, dipanggil beberapa kali, bukan satu.

Tim infrastruktur berkomitmen untuk mengalokasikan bagian dari komponen untuk memisahkan instance hanya agar tidak melintasi beban. Komponen masalah utama kami adalah fasad Legacy, yang pergi ke pangkalan Legacy. Semua pekerjaan dikhususkan untuknya, termasuk pembagian contoh.

Atur prosesnya


Di pagi hari, kami memiliki satu-satunya sinkronisasi hari itu, masuk ke tim dan pergi bekerja.

Pada awalnya, kami menyimpan seluruh log perubahan dan tugas secara langsung di Slack, karena pada awalnya tidak ada begitu banyak tugas. Tetapi jumlah mereka bertambah, jadi kami dengan cepat pindah ke Trello. Integrasi yang dikonfigurasi antara Slack dan Trello diberitahu tentang perubahan status dalam teka-teki.

Selain itu, penting bagi kami untuk melihat seluruh log perubahan produksi. Versi elektronik ada di Trello, versi cadangan ada di papan infrastruktur dalam bentuk kartu. Jika terjadi kesalahan, kami harus segera mencari tahu perubahan apa yang harus dibatalkan. Regresi penuh hanya untuk skema dengan tatanan baru, sisanya dari perubahan diuji lebih loyal.

Tugas terbang ke produksi dengan kecepatan tinggi. Secara total, kami memperbarui sistem 15 kali pada hari itu. Orang-orang dikerahkan stan uji, satu per tim. Pengembangan, pemeriksaan cepat, penyebaran produksi.

Selain proses CTO utama, Sasha Andronov terus berlari ke tim dengan pertanyaan "Bagaimana cara membantu?". Ini membantu meredistribusi upaya dan tidak kehilangan waktu dengan fakta bahwa seseorang tidak berpikir untuk meminta bantuan. Manajemen pengembangan semi-manual, gangguan minimum dan bekerja sampai batas tertentu.

Setelah hari itu, perlu keluar dengan perasaan bahwa kami melakukan semua yang kami bisa. Dan bahkan lebih. Dan kami berhasil! Pada pukul 15:30, skema baru untuk menerima pesanan diluncurkan untuk aplikasi seluler di seluruh jaringan. Mode Hackathon, di bawah 20 penyebaran per produksi per hari!

Malam 22 April tenang dan jelas. Baik jatuh maupun petunjuk tunggal adalah bahwa sistem mungkin buruk.

Sekitar pukul 10 malam, kami berkumpul lagi dan menjabarkan rencana aksi mingguan. Batasan, tes kinerja, urutan asinkron, dan banyak lagi. Itu adalah hari yang panjang, dan ada minggu-minggu panjang ke depan.

Kelahiran kembali


Minggu 23 April adalah neraka. Setelah itu, kami mengatakan pada diri sendiri bahwa kami telah melakukan yang terbaik 200% dan melakukan segala yang kami bisa.

Kami harus menyelamatkan Dodo IS dan memutuskan untuk menerapkan analogi medis. Secara umum, ini adalah kasus nyata pertama menggunakan metafora (seperti pada XP asli), yang sangat membantu untuk memahami apa yang terjadi:

  • Resusitasi - saat Anda perlu menyelamatkan pasien yang sedang sekarat.
  • Pengobatan - ketika ada gejala, tetapi pasien masih hidup.




Resusitasi


Tahap pertama resusitasi adalah buku pedoman standar untuk memulihkan sistem jika terjadi kegagalan menurut beberapa parameter. Satu hal telah jatuh - kita melakukannya, satu jatuh - kita melakukannya dan seterusnya. Jika terjadi kerusakan, kami dengan cepat menemukan runbook yang diinginkan, semuanya terletak di GitHub dan terstruktur oleh masalah.

Tahap kedua resusitasi adalah pembatasan pesanan. Kami mengadopsi praktik ini dari pizzeria kami sendiri. Ketika banyak pesanan dibuang di restoran pizza, dan mereka mengerti bahwa mereka tidak bisa memasaknya dengan cepat, mereka berhenti selama 5 menit, hanya untuk menghapus garis pesanan. Kami membuat skema serupa untuk Dodo IS. Kami memutuskan bahwa jika menjadi sangat buruk, kami akan mengaktifkan batas umum dan akan memberi tahu pelanggan, mereka berkata, kawan, 5 menit dan kami akan menerima pesanan Anda. Kami mengembangkan ukuran ini untuk berjaga-jaga, tetapi sebagai hasilnya, kami tidak pernah menggunakannya. Tidak berguna. Dan bagus.

Pengobatan


Untuk memulai pengobatan, perlu membuat diagnosis, jadi kami fokus pada tes kinerja. Bagian dari tim pergi untuk mengumpulkan profil beban nyata dari produksi menggunakan GoReplay, bagian dari tim yang berfokus pada tes sintetis di Panggung.

Tes sintetis tidak mencerminkan profil beban nyata, tetapi memberikan beberapa perbaikan, menunjukkan beberapa kelemahan dalam sistem. Misalnya, sesaat sebelum itu, kami memindahkan konektor MySQL dari Oracle ke yang baru . Pada versi konektor ada bug dengan sesi pooling, yang menyebabkan fakta bahwa server hanya pergi ke langit-langit pada CPU dan berhenti melayani permintaan. Kami mereproduksi ini dengan tes Panggung, disusun dan diam-diam mulai diproduksi. Ada selusin kasus seperti itu.

Ketika mereka mendiagnosis dan mengidentifikasi penyebab masalah, mereka dikoreksi secara langsung. Kami semakin memahami bahwa cara ideal kami adalah penerimaan pesanan yang tidak sinkron. Kami mulai berupaya memperkenalkannya dalam aplikasi seluler.

Neraka minggu: proses organisasi


Sebuah tim yang terdiri dari 40 orang bekerja pada satu tujuan besar - stabilisasi sistem. Semua tim bekerja bersama. Tidak tahu harus berbuat apa? Bantu tim lain. Fokus pada tujuan tertentu membantu untuk tidak disemprotkan dan tidak terlibat dalam omong kosong yang tidak perlu bagi kami.



Tiga kali sehari ada sinkronisasi, stand-up umum, seperti dalam scrum klasik. Untuk 40 orang. Hanya dua kali dalam tiga minggu (selama hampir 90 sinkronisasi) kami tidak bertemu 30 menit. Sinkronisasi terpanjang berlangsung 57 menit. Meski biasanya mereka butuh 20-30 menit.

Tujuan dari sinkronisasi: untuk memahami di mana bantuan diperlukan dan kapan kami akan membawa tugas-tugas ini atau itu ke produksi. Orang-orang bersatu dalam tim proyek, jika mereka membutuhkan bantuan infrastruktur, seseorang datang ke sana, semua masalah diselesaikan dengan cepat, diskusi kurang lebih masalah.

Di malam hari, untuk mendukung mereka, lab R&D kami menyiapkan makanan untuk para pengembang untuk malam itu. Resep pizza gila, sayap ayam, kentang! Itu benar-benar keren! Dukungan seperti itu memotivasi mereka sebanyak mungkin.



Bekerja dalam mode non-stop sangat sulit. Pada hari Rabu, 25 April, sekitar jam 5 sore, Oleg Blokhin, salah satu pengembang kami, mendekati CTO, yang telah mencari pada hari Sabtu tanpa berhenti. Ada kelelahan yang tidak manusiawi di matanya: "Aku pulang, aku tidak tahan lagi." Dia tidur nyenyak dan hari berikutnya hangat. Jadi Anda bisa menggambarkan kondisi umum banyak pria.

Sabtu berikutnya, 28 April (itu adalah Sabtu yang bekerja untuk semua orang di Rusia) lebih tenang. Kami tidak bisa mengubah apa pun, kami menonton sistem, para pemain beristirahat sedikit dari kecepatan. Semuanya berjalan dengan tenang. Muatannya tidak terlalu besar, tapi memang begitu. Mereka bertahan tanpa masalah, dan ini memberi keyakinan bahwa kami akan menempuh jalan yang benar.

Minggu kedua dan ketiga setelah musim gugur sudah dalam mode yang lebih tenang, langkah neraka sampai larut malam telah hilang, tetapi proses umum darurat militer tetap ada.

Hari Berikutnya X: Tes Kekuatan


Hari berikutnya X pada 9 Mei! Seseorang sedang duduk di rumah dan memantau status sistem. Kami yang berjalan-jalan membawa laptop untuk dipersenjatai sepenuhnya jika terjadi kesalahan. Sasha Andronov, stasiun layanan kami, pergi lebih dekat ke puncak malam ke salah satu restoran pizza untuk melihat semuanya secara langsung jika terjadi masalah.

Hari itu kami menerima 91500 pesanan di Rusia (pada saat itu hasil kedua dalam sejarah Dodo). Bahkan tidak ada sedikit pun masalah. 9 Mei mengkonfirmasi bahwa kami berada di jalur yang benar! Fokus pada stabilitas, kinerja, kualitas. Proses restrukturisasi menunggu kita lebih jauh, tetapi ini adalah kisah yang sama sekali berbeda.

Retro Great Fall dan 6 Praktik


Dalam situasi kritis, praktik yang baik dikembangkan yang dapat dan harus ditransfer ke waktu sunyi. Fokus, bantuan antar tim, penyebaran cepat ke produksi tanpa menunggu regresi penuh. Kami mulai dengan retro dan kemudian mengembangkan kerangka proses.



Dua hari pertama berlalu dalam diskusi praktik. Kami tidak menetapkan tujuan "menempatkan retrospektif pada jam 2". Setelah situasi seperti itu, kami siap meluangkan waktu untuk mengerjakan ide-ide kami dan proses baru kami secara rinci. Semua orang berpartisipasi. Setiap orang yang terlibat dalam pekerjaan restorasi dengan satu atau lain cara.



Hasilnya, ada 6 praktik penting yang ingin saya bicarakan secara lebih rinci.

  1. Top N . , . Product Owners , , , . . , . , , , . , . N – Lead Time .
  2. . . -, , . , , , . .
  3. . , « » . , . , , . , - . Dodo IS. .
  4. Pull Request. , Pull Request, - . . , , , , - . , . , . 15 .
  5. Performance- — . performance- . , . Performance- . baseline , PR . , .
  6. Performance . — . , , -, , , . . , .



1.

21.04.2018 – Dodo IS. ?


(Site Reliability Engineering): . , .

(Site Reliability Engineering, Product Owner Dodo IS): . , , .

auth’, . . , .

, () :



. , .

. , . . -. , , . - , , . , -, , .

. redis, . . - , . .

Dodo IS . . , . , , , , . , — .

. « ». « , » .

- ?


:

– . . . , . . .

:

. , . ( ), - . .

. :

  1. .
  2. .
  3. , .

?



:

, , , .

:

, , . , .

? ?



: , – .

:

  1. — . - - .

    , . 2018 , PerformanceLab, .
  2. , . Less-.
  3. . 2018 -, . , . - 2018 .
  4. async . , 21.04.2018 . , . async.
  5. . , SaveOrder async-await. , . : , LF, 20 . , . , . !

    , , , .

    , , . — -. .
  6. . , (, ). , . «» . nginx , - , .

    : innodb_lock_wait_timeout = 5; innodb_rollback_on_timeout = ON. . , , , , .

, ?


:

  1. , , , . , .
  2. , .
  3. , , , . – .

:

  1. .
  2. . , , -. .
  3. . , - , .

, ?


:

«» , «». , , . .

:

, . , , . .

2. , (Dodo IS Architect)
— , . , — .

, , . , (, , ) .

IT-. Dodo IS, . …

X , . . Dodo IS , , , . , , , . . 146%, . , Dodo IS ?

, . , , . , . , !

, . « »: 11- , , 2 . «» . 3-4 , . , . .

, , . . Dodo IS , « ». ! ( ).

, Dodo IS , . Dodo IS . « », , . ( ), loadtest, , .

More articles:


All Articles