Di musim panas, baik aktivitas pembelian maupun intensitas perubahan dalam infrastruktur proyek web secara tradisional menurun, Kapten Evidence memberi tahu kami. Hanya karena bahkan orang IT pun pergi berlibur. Dan CTO juga. Semakin sulit bagi mereka yang tetap di pos, tetapi tidak tentang itu sekarang: mungkin inilah sebabnya musim panas adalah waktu terbaik untuk bergegas melalui skema reservasi yang ada dan membuat rencana untuk perbaikannya. Dan dalam hal ini Anda akan mendapat manfaat dari pengalaman Yegor Andreev dari AdminDivision , yang ia bicarakan di konferensi Uptime Day .Selama pembangunan situs cadangan, selama pemesanan ada beberapa jebakan yang bisa Anda jebak. Dan jatuh ke dalamnya sama sekali tidak mungkin. Dan menghancurkan kita dalam semua ini, serta dalam banyak hal lainnya, perfeksionisme dan ... kemalasan. Kami berusaha melakukan segalanya-semuanya-semuanya sempurna, tetapi Anda tidak harus melakukannya dengan sempurna! Kita hanya perlu melakukan hal-hal tertentu, tetapi untuk melakukannya dengan benar, untuk membawa mereka sampai akhir, sehingga mereka bekerja secara normal.
Failover bukanlah sejenis hal yang “menyenangkan untuk dimiliki”; itu adalah hal yang harus melakukan tepat satu hal - untuk mengurangi downtime sehingga layanan, perusahaan, kehilangan lebih sedikit uang. Dan dalam semua metode reservasi, saya sarankan berpikir dalam konteks berikut: di mana uang itu?
Perangkap pertama : ketika kita membangun sistem besar yang andal dan melakukan backup, kita mengurangi jumlah kecelakaan. Ini adalah kekeliruan yang mengerikan. Saat kami membuat cadangan, kemungkinan besar kami meningkatkan jumlah kecelakaan. Dan jika kita melakukan semuanya dengan benar, maka bersama-sama kita akan mengurangi waktu henti. Akan ada lebih banyak kecelakaan, tetapi akan terjadi dengan biaya lebih rendah. Lagi pula, apa itu redundansi? Merupakan komplikasi dari sistem. Komplikasi apa pun buruk: kami mendapatkan lebih banyak roda gigi, lebih banyak roda gigi, dengan kata lain, lebih banyak elemen - dan, oleh karena itu, peluang kerusakan lebih tinggi. Dan mereka benar-benar hancur. Dan mereka akan lebih sering patah. Contoh sederhana: katakanlah kita memiliki situs web dengan PHP, MySQL. Dan dia sangat perlu dicadangkan.
Shtosh (c) Kami mengambil situs kedua, kami membangun sistem yang identik ... Kompleksitasnya menjadi dua kali lebih besar - kami memiliki dua entitas. Dan kami juga menggulirkan logika transfer data tertentu dari satu platform ke platform lain dari atas - yaitu replikasi data, menyalin statika, dan sebagainya. Jadi, logika replikasi biasanya sangat kompleks, dan oleh karena itu, total kompleksitas sistem mungkin bukan 2, tetapi 3, 5, 10 kali lebih banyak.
Jebakan kedua : ketika kita membangun sistem kompleks yang benar-benar besar, kita membayangkan apa yang ingin kita dapatkan pada akhirnya. Voila: kami ingin mendapatkan sistem yang sangat andal yang berfungsi tanpa downtime sama sekali, beralih dalam setengah detik (atau lebih baik secara umum secara instan), dan mulai mengubah mimpi menjadi kenyataan. Tetapi ada juga nuansa: semakin pendek waktu switching yang diinginkan, semakin kompleks logika sistem ternyata. Semakin sulit kita melakukan logika ini, semakin sering sistem akan rusak. Dan Anda dapat masuk ke dalam situasi yang sangat tidak menyenangkan: kami melakukan yang terbaik untuk mengurangi waktu henti, tetapi sebenarnya kami memperumit masalah, dan ketika terjadi kesalahan, waktu henti akan lebih lama. Di sini Anda sering mendapati diri Anda berpikir: di sini ... akan lebih baik jika mereka tidak dipesan. Akan lebih baik jika bekerja sendiri dengan downtime yang dapat dimengerti.
Bagaimana cara menghadapinya? Kita harus berhenti membohongi diri sendiri, berhenti menyanjung diri sendiri bahwa kita akan membangun pesawat ruang angkasa di sini, tetapi untuk memahami secara memadai seberapa besar proyek itu dapat direbahkan. Dan untuk waktu maksimum ini, kita akan memilih yang mana, pada kenyataannya, metode kita akan meningkatkan keandalan sistem kita.
Sudah waktunya untuk "cerita dari w" ... dari kehidupan, tentu saja.
Contoh nomor satu
Bayangkan kartu situs dari pabrik penggilingan pipa No. 1 di kota N. Ada tertulis dalam huruf besar di atasnya - PIPA PABRIK No. 1. Sedikit lebih rendah - slogan: "Pipa kami adalah pipa paling bulat di N". Dan di bawah nomor telepon CEO dan namanya. Kami memahami bahwa Anda perlu memesan - ini adalah hal yang sangat penting! Kita mulai mengerti apa itu. Html-statika - yaitu, beberapa gambar di mana umum, pada kenyataannya, di meja di kamar mandi dengan pasangannya sedang mendiskusikan beberapa kesepakatan berikutnya. Kami mulai memikirkan downtime. Terlintas dalam pikiran: Anda perlu berbaring di sana selama lima menit, tidak lebih. Dan kemudian pertanyaannya adalah: berapa banyak penjualan dari situs ini secara umum? Berapa banyak? Apa artinya nol? Dan itu berarti: karena sang jenderal melakukan keempat transaksi selama setahun terakhir di meja yang sama, dengan orang yang sama dengan siapa mereka pergi ke pemandian duduk di meja. Dan kami memahami bahwa meskipun situs itu berbaring selama sehari, tidak akan ada yang mengerikan.
Berdasarkan pengantar, ada hari untuk mengangkat cerita ini. Kami mulai berpikir tentang skema cadangan. Dan kami memilih skema pencadangan yang paling ideal untuk contoh ini: kami tidak menggunakan redundansi. Semua ini naik oleh admin mana pun selama setengah jam dengan istirahat asap. Menempatkan server web, meletakkan file adalah segalanya. Itu akan berhasil. Anda tidak harus mengikuti apa pun, Anda tidak perlu memberi perhatian khusus pada apa pun. Artinya, kesimpulan dari contoh nomor satu cukup jelas: layanan yang tidak perlu Anda pesan tidak diperlukan.
Contoh nomor dua
Blog perusahaan: yang terlatih khusus menulis berita di sana, jadi kami berpartisipasi dalam pameran ini dan itu, tapi di sini kami merilis produk baru dan seterusnya. Katakanlah ini adalah PHP standar dengan WordPress, database kecil dan sedikit statis. Tentu saja, terlintas dalam pikiran saya bahwa Anda tidak boleh berbohong - “tidak lebih dari lima menit!”, Itu saja. Tapi mari kita berpikir lebih jauh. Apa yang dilakukan blog ini? Mereka datang ke sana dari Yandex, dari Google atas beberapa permintaan, pada organik. Wow Dan apakah penjualan entah bagaimana terkait dengannya sama sekali? Wawasan: tidak juga. Lalu lintas iklan pergi ke situs utama, yang ada di komputer lain. Kami mulai berpikir tentang skema reservasi buklet. Dalam cara yang baik, perlu diangkat dalam beberapa jam, dan akan menyenangkan untuk mempersiapkan ini. Masuk akal untuk mengambil mesin di pusat data lain, mengarahkan lingkungan ke dalamnya, yaitu server web, PHP, WordPress, MySQL, dan membiarkannya berbaring. Pada saat kita memahami bahwa semuanya rusak, dua hal perlu dilakukan - gulung dump mysql hingga 50 meter, itu akan terbang ke sana dalam satu menit, dan menggulung sejumlah gambar dari cadangan di sana. Ini juga bukan berita baik di sana. Jadi, dalam setengah jam semua ini naik. Tidak ada replikasi, atau Tuhan memaafkan saya, kegagalan otomatis. Kesimpulan: apa yang kita dapat dengan cepat mengeluarkan cadangan tidak perlu cadangan.
Contoh nomor tiga, lebih rumit
Toko online. PhP dengan hati terbuka sedikit diajukan, mysql dengan basis yang kuat. Cukup banyak statis (lagipula, toko online memiliki gambar-HD yang indah dan semua jazz itu), Redis untuk sesi ini, dan Elasticsearch untuk pencarian. Kami mulai memikirkan downtime. Dan di sini, tentu saja, jelas bahwa toko online tidak dapat berkubang tanpa rasa sakit. Lagi pula, semakin lama terletak, semakin banyak uang yang kita hilangkan. Layak dipercepat. Berapa banyak Saya percaya bahwa jika kita berbaring selama satu jam, maka tidak ada yang akan menjadi gila. Ya, kita akan kehilangan sesuatu, tetapi jika kita mulai bersemangat, itu hanya akan bertambah buruk. Kami menentukan waktu idle yang diijinkan per jam.
Bagaimana semua ini bisa dipesan? Bagaimanapun, sebuah mobil diperlukan: satu jam waktu cukup sedikit. Mysql: replikasi, replikasi langsung sudah diperlukan di sini, karena dalam 100 jam dalam dump, kemungkinan besar, tidak akan menuangkan. Statika, gambar: sekali lagi, dalam satu jam 500 GB mungkin tidak punya waktu untuk bergabung. Karena itu, lebih baik untuk menyalin gambar segera. Redis: lebih menarik di sini. Sesi-sesi itu ada di Redis - kita tidak bisa mengambil dan menguburnya. Karena itu tidak akan menjadi sangat baik: semua pengguna akan keluar, keranjang dikosongkan dan sebagainya. Orang-orang akan dipaksa untuk memasukkan kembali nama pengguna dan kata sandi mereka, dan banyak orang mungkin melepaskan diri dan tidak menyelesaikan pembelian. Sekali lagi, konversi akan jatuh. Di sisi lain, Redis secara langsung relevan, dengan pengguna yang masuk terakhir, mungkin, juga tidak diperlukan. Dan kompromi yang baik adalah mengambil Redis dan mengembalikannya dari cadangan kemarin, atau, jika Anda melakukannya setiap jam, - satu jam yang lalu. Manfaat memulihkannya dari cadangan adalah menyalin satu file. Dan kisah yang paling menarik adalah Elasticsearch. Siapa yang pernah mengangkat replikasi MySQL? Siapa yang pernah mengangkat replikasi Elasticsearch? Dan setelah itu dia bekerja dengan siapa? Apa yang saya lakukan: kita melihat entitas tertentu dalam sistem kami. Tampaknya bermanfaat - tetapi rumit.
Kompleks dalam arti bahwa sesama insinyur kami tidak memiliki pengalaman bekerja dengannya. Atau ada pengalaman negatif. Atau kami mengerti bahwa sejauh ini ini adalah teknologi yang cukup baru dengan nuansa atau kelembapan. Kami pikir ... Sial, elastis juga sehat, juga butuh waktu lama untuk mengembalikannya dari cadangan, apa yang harus saya lakukan? Kami memahami bahwa elastis dalam kasus kami digunakan untuk pencarian. Dan bagaimana toko online kami menjual? Kami pergi ke pemasar, bertanya, dari mana orang datang. Mereka menjawab: "90% Pasar Yandex datang langsung ke kartu produk." Dan membeli atau tidak. Karena itu, 10% pengguna perlu pencarian. Dan untuk menjaga replikasi elastis, terutama antara pusat data yang berbeda di zona yang berbeda, benar-benar ada banyak nuansa. Apa jalan keluarnya? Kami mengambil elastis pada situs yang dipesan dan tidak melakukan apa-apa dengannya. Jika case berlarut-larut, maka suatu hari kita mungkin akan menaikkannya, tetapi ini tidak pasti. Sebenarnya, kesimpulan plus atau minus adalah sama: kita, sekali lagi, tidak memesan layanan yang tidak mempengaruhi uang. Agar sirkuit lebih sederhana.
Contoh nomor empat, lebih sulit lagi
Integrator: menjual bunga, menelepon taksi, menjual barang, secara umum, apa saja. Suatu hal serius yang berfungsi 24/7 untuk sejumlah besar pengguna. Dengan tumpukan menarik penuh, di mana ada pangkalan yang menarik, solusi, beban tinggi, dan yang paling penting, itu menyakitkan dia untuk berbaring lebih dari 5 menit. Bukan hanya dan tidak begitu banyak karena orang tidak akan membeli, tetapi karena orang akan melihat bahwa benda ini tidak berfungsi, mereka akan kesal dan mungkin tidak akan kembali untuk yang kedua kalinya.
Baiklah Lima menit. Apa yang akan kita lakukan dengan ini? Dalam hal ini, kita berada dalam cara dewasa, dengan semua uang yang kita buat situs cadangan nyata, dengan replikasi segala sesuatu dan segalanya, dan mungkin bahkan mengotomatiskan pergantian maksimum ke situs ini. Dan di samping itu, seseorang tidak boleh lupa untuk melakukan satu hal penting: pada kenyataannya, tulis jadwal pengalihan. Peraturan, bahkan jika Anda memiliki semuanya otomatis, bisa sangat sederhana. Dari seri "jalankan skrip yang mungkin ini dan itu", "klik ini dan ini di rute 53" dan seterusnya - tetapi ini harus berupa daftar tindakan yang tepat.
Dan semuanya tampak jelas. Berpindah replikasi adalah tugas yang sepele, atau itu akan beralih sendiri. Tulis ulang nama domain dalam dns - dari seri yang sama. Masalahnya adalah bahwa ketika proyek yang sama crash, kepanikan dimulai, dan bahkan admin yang paling kuat dan berjenggot pun bisa rentan terhadapnya. Tanpa instruksi yang jelas "buka terminal, buka di sini, alamat di server kami masih seperti ini", jangka waktu 5 menit yang dialokasikan untuk resusitasi sulit dipertahankan. Nah, ditambah, ketika kita menggunakan peraturan ini, mudah untuk memperbaiki beberapa perubahan dalam infrastruktur, misalnya, dan mengubah peraturan yang sesuai.
Nah, jika sistem cadangan sangat kompleks dan pada beberapa titik kami melakukan kesalahan, maka kami dapat menempatkan situs cadangan kami juga, dan sebagai tambahan, mengubah data menjadi labu di kedua situs - itu akan sangat menyedihkan.
Contoh nomor lima, full hardcore
Layanan internasional dengan ratusan juta pengguna di seluruh dunia. Semua zona waktu, yang hanya ada, memuat tinggi dengan kecepatan maksimum, Anda tidak boleh berbohong sama sekali. Semenit - dan itu akan menyedihkan. Apa yang harus dilakukan Cadangan, sekali lagi, sepenuhnya. Mereka melakukan semua yang disebutkan dalam contoh sebelumnya, dan sedikit lagi. Dunia yang ideal, dan infrastruktur kami - itu dengan semua konsep devopa IaaC. Artinya, semuanya secara umum di git, dan cukup klik tombol.
Apa yang hilang Salah satunya adalah ajarannya. Anda tidak dapat melakukannya tanpa mereka. Tampaknya semuanya sempurna dengan kita, semuanya terkendali secara umum. Kami menekan tombol, semuanya terjadi. Sekalipun demikian - dan kami memahami bahwa ini tidak terjadi - sistem kami berinteraksi dengan beberapa sistem lain. Sebagai contoh, ini adalah dns dari rute 53, penyimpanan s3, integrasi dengan beberapa api. Kami tidak akan dapat melihat segalanya dalam eksperimen spekulatif ini. Dan sampai kami benar-benar menarik sakelar, kami tidak akan tahu apakah itu akan berhasil atau tidak.
Itu mungkin saja. Jangan malas dan jangan berlebihan. Dan mungkin uptime bersamamu!