Untuk berargumen bahwa situs harus selalu dapat diakses adalah perilaku yang buruk dan dangkal, tetapi aksesibilitas 100%, meskipun merupakan prasyarat, paling sering masih merupakan cita-cita yang tidak dapat diakses. Sekarang ada banyak solusi di pasar yang menjanjikan waktu kerja maksimum atau menawarkan solusi untuk meningkatkannya, tetapi aplikasi mereka tidak hanya tidak selalu membantu, dalam beberapa kasus bahkan dapat menyebabkan peningkatan risiko dan mengurangi aksesibilitas proyek. Dalam artikel ini, kita akan membahas kesalahan klasik yang terus-menerus kita temui. Sebagian besar masalahnya adalah dasar, tetapi orang-orang membiarkannya berulang kali.
Pendahuluan yang diperlukan: sebelum mencoba memastikan uptime maksimum proyek, Anda harus mengkorelasikan biaya dan biaya downtime. Biasanya, ini sangat penting bagi perusahaan yang pekerjaannya tergantung pada pekerjaan perusahaan lain - solusi B2B, layanan API, layanan pengiriman. Tidak dapat diaksesnya bahkan beberapa menit akan mengarah, setidaknya pada beban di pusat panggilan dari pelanggan yang tidak puas. Untuk perusahaan dari jenis lain, misalnya, toko online kecil, atau perusahaan yang pelanggannya bekerja dari 9 hingga 18 tahun, tidak dapat diaksesnya bahkan selama beberapa jam bisa lebih murah daripada situs cadangan penuh.
1. Lokalisasi seluruh proyek dalam satu pusat data / satu zona hosting awan
Pemasaran cloud hosting telah dengan tegas memperbaiki konsep yang salah di kepala orang: cloud hosting tidak terikat dengan perangkat keras dan ini berarti infrastruktur cloud tidak akan jatuh. Tiga crash Amazon Web Services 24 jam, crash cloud4y baru-baru ini, dan kehilangan data cloudmouse menunjukkan bahwa melokalkan data dan proyek itu sendiri dalam satu pusat data adalah cara yang dijamin untuk mendapatkan banyak waktu downtime tanpa kemampuan untuk dengan mudah mengangkat proyek ke situs lain. Undang-undang tentang data pribadi, dalam hal ini, menciptakan masalah tambahan. Kami percaya bahwa cloud hosting apa pun harus melalui beberapa kecelakaan besar untuk mempelajari cara mencegahnya (kilat yang menghantam Amazon, masalah konfigurasi jaringan yang terkait dengan faktor manusia, dll.), Dan jika hosting cloud barat mengalami serangkaian bencana ini, maka banyak situs Rusia belum melakukan ini, dan ini harus diperhitungkan.
Situasinya kira-kira sama dengan pusat data "besi". Seringkali kita melihat konfigurasi klien, di mana beberapa server dicadangkan di satu situs, jika salah satu dari mereka gagal, namun, dalam pengalaman kami, ada masalah jaringan ketika beberapa rak di satu pusat data atau seluruh pusat data secara keseluruhan menjadi tidak dapat diakses terjadi jauh lebih sering daripada crash server tunggal, dan ini juga perlu diperhitungkan.
Alur kerja proyek yang direkomendasikan AWS melibatkan penggunaan beberapa zona ketersediaan default untuk mencapai waktu proyek maksimum.
2. Kurangnya duplikasi yang memadai di situs cadangan
Jadi, kami sampai pada kesimpulan biasa tentang perlunya memiliki situs cadangan untuk mencapai uptime maksimum proyek, namun, untuk beralih ke sana, data harus memadai ke lokasi produksi. Yang penting di sini bukanlah penciptaan awal cadangan - ini adalah prosedur yang cukup sederhana dan dapat dimengerti, sinkronisasi dan pemantauan sinkronisasi perubahan lebih lanjut jauh lebih penting. Pertama-tama, kita berbicara tentang:
- Konfigurasi cluster / sinkronisasi data dalam cluster ketika kita berbicara tentang situs yang kompleks
- Sinkronisasi struktur file dan pemantauan lag sinkronisasi
- Lacak perubahan dalam konfigurasi server
- Proses pemantauan dan penambahan debug yang disinkronkan dengan proyek / layanan baru di situs.
- Melacak penambahan layanan sekunder baru (antrian baru, mekanisme pemrosesan dan interaksi, dll.).
- Pemantauan berkelanjutan yang memadai atas semua proses ini.
3. Kurangnya rencana peralihan dan peralihan reguler ke situs cadangan
Apa pun, bahkan pemantauan terbaik, tidak dapat menjamin bahwa situs cadangan akan siap untuk beralih ketika benar-benar diperlukan. Dalam pengalaman kami, kecelakaan akan terjadi pada pergantian pertama ke cadangan, dan ini akan terjadi beberapa kali lagi. Dalam laporan mereka, Stack Overflow mengatakan bahwa mereka membutuhkan sekitar lima peralihan ke cadangan, sebelum mereka yakin bahwa sekarang mereka benar-benar siap menerima lalu lintas setelah kecelakaan itu. Oleh karena itu, dalam rencana kerja untuk meningkatkan waktu proyek, perlu untuk memasukkan sakelar uji ke cadangan, dan memperhitungkan bahwa pemindahan tersebut akan menyebabkan kecelakaan. Setelah berolahraga dan memperbaiki mekanisme switching dalam dokumentasi, Anda perlu terus beralih ke cadangan secara teratur untuk memastikan bahwa semuanya masih berfungsi.
4. Lokalisasi situs cadangan di saluran yang sama / di wilayah cloud yang sama
Jika situs produksi dan cadangan berada dalam perusahaan hosting yang sama, maka sangat mungkin jika terjadi kecelakaan, kedua situs Anda akan segera berhenti bekerja. Beberapa kecelakaan besar di AWS segera memengaruhi semua zona ketersediaan di satu wilayah, Selectel jatuh pada saat yang sama dengan pusat data di St. Petersburg dan Moskow, perusahaan dapat berbicara tentang isolasi lengkap, tetapi kecelakaan cloud4y, yang menyebabkan sepenuhnya tidak dapat diaksesnya Bitrix24 menunjukkan bahwa bahkan dalam kasus-kasus seperti itu ada risiko besar. Ideal, dari sudut pandang kami, adalah konfigurasi di mana satu konfigurasi cadangan terletak di perusahaan hosting yang sama (untuk menggunakan cara biasa beralih ke cadangan, seperti VRRP ), dan platform cadangan sekunder di perusahaan hosting lain.
5. Penempatan versi yang identik di situs utama dan cadangan.
Bahkan penggunaan situs cadangan terverifikasi dan penggunaan situs sekunder di pusat data lain tidak menjamin kesiapan cadangan untuk dengan cepat mengambil alih beban produksi. Ini karena esensi redundansi: versi baru dari kode yang menciptakan beban fatal pada lingkungan produksi akan membuat beban yang persis sama di situs cadangan, dan proyek akan menjadi sepenuhnya tidak dapat diakses. Sebagai solusi sederhana, harus ada mekanisme untuk kembali ke versi sebelumnya, namun, dalam perlombaan bisnis untuk rilis ini tidak selalu mungkin, dan kemudian kami mulai memikirkan situs cadangan lain dengan versi sebelumnya. Kita juga harus berbicara tentang cadangan : penghapusan data yang tidak disengaja di situs utama juga akan memengaruhi situs cadangan, jadi Anda harus memikirkan replikasi yang tertunda (selama 15 menit, per jam) agar dapat beralih ke basis data yang belum terjadi. operasi fatal.
6. Ketergantungan pada layanan eksternal yang diakses proyek.
Tetapi ini tidak cukup. Sejumlah besar proyek sekarang menggunakan layanan eksternal untuk menyediakan layanan mereka sendiri. Sebagian besar dari mereka menggunakan SMS untuk otentikasi ganda, toko online menghitung waktu pengiriman menggunakan layanan pengiriman, pembayaran diterima melalui gateway pembayaran pihak ketiga, dan jika layanan ini jatuh, tidak masalah apakah ada reservasi atau tidak, proyek akan tetap tidak tersedia. Kami jarang melihat memesan layanan eksternal, tetapi, sementara itu, ini adalah proyek yang persis sama yang mungkin memiliki masalah dengan situs cadangan, atau mungkin tidak ada cadangan sama sekali. Dan jika layanan eksternal tidak tersedia, melayani pelanggan Anda juga tidak mungkin. Kami menyarankan Anda menduplikasi semua sistem eksternal yang penting, memantau ketersediaannya dan memiliki rencana untuk mengubahnya jika terjadi kecelakaan.
Ini jauh dari semua, tetapi setidaknya hal-hal mendasar. Kami membahas ini secara lebih rinci di pertemuan komunitas uptime.com , yang berikutnya adalah pada bulan Oktober, tetapi untuk sekarang Anda dapat mengobrol di grup telegram .