Saat ini, layanan Bitrix24 tidak memiliki lalu lintas ratusan gigabit, juga tidak memiliki armada server yang besar (meskipun, tentu saja, ada beberapa server yang sudah ada). Namun bagi banyak klien, ini adalah alat utama untuk bekerja di perusahaan; ini adalah aplikasi bisnis yang sangat penting. Oleh karena itu, tidak ada cara untuk jatuh. Bagaimana jika kerusakan memang terjadi, tetapi layanan “pulih” begitu cepat sehingga tidak ada yang menyadarinya? Dan bagaimana mungkin menerapkan failover tanpa kehilangan kualitas pekerjaan dan jumlah klien? Alexander Demidov, direktur layanan cloud di Bitrix24, berbicara untuk blog kami tentang bagaimana sistem reservasi telah berkembang selama 7 tahun keberadaan produk.
“Kami meluncurkan Bitrix24 sebagai SaaS 7 tahun lalu. Kesulitan utamanya mungkin adalah sebagai berikut: sebelum diluncurkan ke publik sebagai SaaS, produk ini hanya ada dalam format solusi kotak. Klien membelinya dari kami, menghostingnya di server mereka, menyiapkan portal perusahaan - solusi umum untuk komunikasi karyawan, penyimpanan file, manajemen tugas, CRM, itu saja. Dan pada tahun 2012, kami memutuskan ingin meluncurkannya sebagai SaaS, mengelolanya sendiri, memastikan toleransi kesalahan dan keandalan. Kami memperoleh pengalaman selama ini, karena hingga saat itu kami belum memilikinya - kami hanyalah produsen perangkat lunak, bukan penyedia layanan.
Saat meluncurkan layanan, kami memahami bahwa hal yang paling penting adalah memastikan toleransi kesalahan, keandalan, dan ketersediaan layanan yang konstan, karena jika Anda memiliki situs web biasa yang sederhana, sebuah toko, misalnya, dan itu jatuh ke tangan Anda dan berada di sana selama satu jam, hanya Anda yang menderita, Anda kehilangan pesanan, Anda kehilangan klien, tetapi untuk klien Anda sendiri, ini tidak terlalu penting baginya. Dia kesal, tentu saja, tapi dia pergi dan membelinya di situs lain. Dan jika ini adalah aplikasi yang mengikat semua pekerjaan, komunikasi, pengambilan keputusan di dalam perusahaan, maka hal terpenting adalah mendapatkan kepercayaan pengguna, yaitu tidak mengecewakan dan tidak jatuh. Karena semua pekerjaan bisa terhenti jika sesuatu di dalamnya tidak berfungsi.
Bitrix.24 sebagai SaaS
Kami merakit prototipe pertama setahun sebelum peluncuran publik, pada tahun 2011. Kami merakitnya dalam waktu sekitar seminggu, melihatnya, memutarnya - bahkan berhasil. Artinya, Anda bisa masuk ke formulir, memasukkan nama portal di sana, portal baru akan terbuka, dan basis pengguna akan dibuat. Kami memeriksanya, menilai prinsip produk, membuangnya, dan terus menyempurnakannya selama setahun penuh. Karena kami mempunyai tugas besar: kami tidak ingin membuat dua basis kode yang berbeda, kami tidak ingin mendukung produk paket terpisah, solusi cloud terpisah - kami ingin melakukan semuanya dalam satu kode.
Aplikasi web yang khas pada saat itu adalah satu server tempat beberapa kode PHP dijalankan, database mysql, file diunggah, dokumen, gambar dimasukkan ke dalam folder unggah - semuanya berfungsi. Sayangnya, tidak mungkin meluncurkan layanan web yang sangat stabil menggunakan ini. Di sana, cache terdistribusi tidak didukung, replikasi database tidak didukung.
Kami merumuskan persyaratannya: ini adalah kemampuan untuk ditempatkan di lokasi yang berbeda, mendukung replikasi, dan idealnya ditempatkan di pusat data yang tersebar secara geografis berbeda. Pisahkan logika produk dan, faktanya, penyimpanan data. Mampu menskalakan secara dinamis sesuai dengan beban, dan mentolerir statika secara keseluruhan. Dari pertimbangan tersebut, sebenarnya muncul persyaratan produk yang kami sempurnakan sepanjang tahun. Selama waktu ini, dalam platform, yang ternyata bersatu - untuk solusi kotak, untuk layanan kami sendiri - kami memberikan dukungan untuk hal-hal yang kami perlukan. Dukungan untuk replikasi mysql di tingkat produk itu sendiri: yaitu, pengembang yang menulis kode tidak memikirkan bagaimana permintaannya akan didistribusikan, dia menggunakan api kami, dan kami tahu cara mendistribusikan permintaan tulis dan baca antar master dengan benar dan budak.
Kami telah membuat dukungan di tingkat produk untuk berbagai penyimpanan objek cloud: penyimpanan google, amazon s3, ditambah dukungan untuk open stack swift. Oleh karena itu, hal ini nyaman bagi kami sebagai layanan dan bagi pengembang yang bekerja dengan solusi paket: jika mereka hanya menggunakan API kami untuk bekerja, mereka tidak memikirkan di mana file pada akhirnya akan disimpan, secara lokal di sistem file atau dalam penyimpanan file objek.
Akibatnya, kami segera memutuskan bahwa kami akan melakukan reservasi di tingkat seluruh pusat data. Pada tahun 2012, kami meluncurkan sepenuhnya di Amazon AWS karena kami sudah memiliki pengalaman dengan platform ini - situs web kami dihosting di sana. Kami tertarik dengan fakta bahwa di setiap wilayah Amazon memiliki beberapa zona ketersediaan - pada kenyataannya, (dalam terminologinya) beberapa pusat data yang kurang lebih independen satu sama lain dan memungkinkan kami melakukan reservasi pada tingkat seluruh pusat data: jika tiba-tiba gagal, database direplikasi master-master, server aplikasi web dicadangkan, dan data statis dipindahkan ke penyimpanan objek s3. Bebannya seimbang - pada saat itu oleh Amazon elb, tetapi beberapa saat kemudian kami sampai pada penyeimbang beban kami sendiri, karena kami memerlukan logika yang lebih kompleks.
Apa yang mereka inginkan adalah apa yang mereka dapatkan...
Semua hal dasar yang ingin kami pastikan - toleransi kesalahan pada server itu sendiri, aplikasi web, database - semuanya bekerja dengan baik. Skenario paling sederhana: jika salah satu aplikasi web kita gagal, maka semuanya sederhana - aplikasi tersebut dinonaktifkan dari penyeimbangan.
Penyeimbang (pada saat itu adalah elb Amazon) menandai mesin yang rusak sebagai tidak sehat dan mematikan distribusi beban pada mesin tersebut. Penskalaan otomatis Amazon berfungsi: ketika beban bertambah, mesin baru ditambahkan ke grup penskalaan otomatis, beban didistribusikan ke mesin baru - semuanya baik-baik saja. Dengan penyeimbang kami, logikanya kira-kira sama: jika sesuatu terjadi pada server aplikasi, kami menghapus permintaan dari server tersebut, membuang mesin ini, memulai yang baru, dan terus bekerja. Skema ini telah sedikit berubah selama bertahun-tahun, tetapi terus berfungsi: sederhana, dapat dimengerti, dan tidak ada kesulitan dengannya.
Kami bekerja di seluruh dunia, puncak beban pelanggan sangat berbeda, dan, dengan cara yang bersahabat, kami harus dapat melakukan pekerjaan layanan tertentu pada komponen mana pun di sistem kami kapan saja - tanpa diketahui oleh pelanggan. Oleh karena itu, kami memiliki kesempatan untuk mematikan database dari operasi, mendistribusikan kembali beban ke pusat data kedua.
Bagaimana cara kerjanya? — Kami mengalihkan lalu lintas ke pusat data yang berfungsi - jika ada kecelakaan di pusat data, maka sepenuhnya, jika ini adalah pekerjaan yang kami rencanakan dengan satu database, maka kami mengalihkan sebagian lalu lintas yang melayani klien ini ke pusat data kedua, menangguhkan itu replikasi. Jika mesin baru diperlukan untuk aplikasi web karena beban pada pusat data kedua meningkat, mesin tersebut akan mulai secara otomatis. Kami menyelesaikan pekerjaan, replikasi dipulihkan, dan kami mengembalikan seluruh beban. Jika kita perlu mencerminkan beberapa pekerjaan di DC kedua, misalnya, menginstal pembaruan sistem atau mengubah pengaturan di database kedua, maka, secara umum, kita mengulangi hal yang sama, hanya ke arah lain. Dan jika ini kecelakaan, maka kami melakukan semuanya dengan sepele: kami menggunakan mekanisme event-handler dalam sistem pemantauan. Jika beberapa pemeriksaan dipicu dan statusnya menjadi kritis, maka kami menjalankan penangan ini, penangan yang dapat menjalankan logika ini atau itu. Untuk setiap database, kami menentukan server mana yang menjadi failovernya, dan ke mana lalu lintas perlu dialihkan jika tidak tersedia. Secara historis, kami menggunakan nagios atau beberapa garpunya dalam satu atau lain bentuk. Pada prinsipnya, mekanisme serupa ada di hampir semua sistem pemantauan; kami belum menggunakan sistem yang lebih rumit, namun mungkin suatu hari nanti kami akan menggunakannya. Sekarang pemantauan dipicu oleh tidak tersedianya dan memiliki kemampuan untuk mengalihkan sesuatu.
Sudahkah kita memesan semuanya?
Kami mempunyai banyak klien dari Amerika, banyak klien dari Eropa, banyak klien yang lebih dekat ke Timur - Jepang, Singapura dan sebagainya. Tentu saja, sebagian besar kliennya berada di Rusia. Artinya, pekerjaan tidak berada pada satu wilayah. Pengguna menginginkan respons yang cepat, ada persyaratan untuk mematuhi berbagai undang-undang setempat, dan di setiap wilayah kami mencadangkan dua pusat data, ditambah ada beberapa layanan tambahan, yang, sekali lagi, nyaman untuk ditempatkan dalam satu wilayah - untuk klien yang berada di wilayah ini berfungsi. Penangan REST, server otorisasi, mereka kurang penting untuk pengoperasian klien secara keseluruhan, Anda dapat beralih melalui mereka dengan sedikit penundaan yang dapat diterima, tetapi Anda tidak ingin menemukan kembali cara memantaunya dan apa yang harus dilakukan dengan mereka. Oleh karena itu, kami berusaha memanfaatkan solusi yang ada secara maksimal, dan tidak mengembangkan kompetensi pada produk tambahan. Dan di suatu tempat kami dengan mudah menggunakan peralihan di tingkat DNS, dan kami menentukan keaktifan layanan dengan DNS yang sama. Amazon memiliki layanan Route 53, tetapi ini bukan hanya DNS tempat Anda dapat membuat entri dan hanya itu—ini jauh lebih fleksibel dan nyaman. Melalui itu Anda dapat membangun layanan terdistribusi secara geografis dengan geolokasi, ketika Anda menggunakannya untuk menentukan dari mana klien berasal dan memberinya catatan tertentu - dengan bantuannya Anda dapat membangun arsitektur failover. Pemeriksaan kesehatan yang sama dikonfigurasikan di Route 53 itu sendiri, Anda mengatur titik akhir yang dipantau, mengatur metrik, mengatur protokol mana untuk menentukan "keaktifan" layanan - tcp, http, https; mengatur frekuensi pemeriksaan yang menentukan apakah layanan hidup atau tidak. Dan di DNS itu sendiri, Anda menentukan apa yang akan menjadi primer, apa yang akan menjadi sekunder, ke mana harus beralih jika pemeriksaan kesehatan dipicu di dalam rute 53. Semua ini dapat dilakukan dengan beberapa alat lain, tetapi mengapa nyaman - kami mengaturnya naik sekali dan kemudian tidak memikirkannya sama sekali bagaimana kita melakukan pemeriksaan, bagaimana kita beralih: semuanya bekerja dengan sendirinya.
Yang pertama "tetapi": bagaimana dan dengan apa memesan rute 53 itu sendiri? Siapa tahu, bagaimana jika terjadi sesuatu padanya? Untungnya, kami tidak pernah menginjak penggaruk ini, tapi sekali lagi, saya akan punya cerita sebelumnya mengapa kami berpikir bahwa kami masih perlu melakukan reservasi. Di sini kami menyiapkan sedotan untuk diri kami sendiri terlebih dahulu. Beberapa kali dalam sehari kami melakukan pembongkaran total seluruh zona yang kami miliki di rute 53. API Amazon memungkinkan Anda mengirimnya dengan mudah dalam JSON, dan kami memiliki beberapa server cadangan tempat kami mengonversinya, mengunggahnya dalam bentuk konfigurasi, dan secara kasar memiliki konfigurasi cadangan. Jika terjadi sesuatu, kita dapat dengan cepat menerapkannya secara manual tanpa kehilangan data pengaturan DNS.
Kedua "tetapi": Apa yang ada di gambar ini yang belum dipesan? Penyeimbang itu sendiri! Distribusi klien kami berdasarkan wilayah dibuat sangat sederhana. Kami memiliki domain bitrix24.ru, bitrix24.com, .de - sekarang ada 13 domain berbeda, yang beroperasi di berbagai zona. Kami sampai pada hal berikut: setiap daerah memiliki penyeimbangnya sendiri. Hal ini membuatnya lebih mudah untuk didistribusikan ke seluruh wilayah, tergantung di mana beban puncak pada jaringan berada. Jika ini merupakan kegagalan pada tingkat penyeimbang tunggal, maka ia akan dikeluarkan dari layanan dan dihapus dari dns. Jika ada masalah dengan sekelompok penyeimbang, maka mereka dicadangkan di situs lain, dan peralihan antar penyeimbang dilakukan menggunakan rute yang sama53, karena karena TTL yang pendek, peralihan terjadi dalam waktu maksimal 2, 3, 5 menit .
Ketiga "tetapi": Apa yang belum dipesan? S3, benar. Saat kami menempatkan file yang kami simpan untuk pengguna di s3, kami dengan tulus yakin bahwa file tersebut sangat menusuk dan tidak perlu menyimpan apa pun di sana. Namun sejarah menunjukkan bahwa segala sesuatunya terjadi secara berbeda. Secara umum, Amazon menggambarkan S3 sebagai layanan mendasar, karena Amazon sendiri menggunakan S3 untuk menyimpan gambar mesin, konfigurasi, gambar AMI, snapshot... Dan jika s3 mogok, seperti yang terjadi sekali selama 7 tahun ini, selama kita telah menggunakan bitrix24, ia mengikutinya seperti kipas. Ada banyak hal yang muncul – ketidakmampuan untuk memulai mesin virtual, kegagalan api, dan sebagainya.
Dan S3 bisa jatuh - itu terjadi sekali. Oleh karena itu, kami sampai pada skema berikut: beberapa tahun yang lalu tidak ada fasilitas penyimpanan benda umum yang serius di Rusia, dan kami mempertimbangkan pilihan untuk melakukan sesuatu sendiri... Untungnya, kami tidak mulai melakukan ini, karena kami akan melakukannya telah menggali keahlian yang belum kita miliki, dan mungkin akan membuat kesalahan. Kini Mail.ru memiliki penyimpanan yang kompatibel dengan s3, Yandex memilikinya, dan sejumlah penyedia lain memilikinya. Kami akhirnya sampai pada gagasan bahwa kami ingin memiliki, pertama, cadangan, dan kedua, kemampuan untuk bekerja dengan salinan lokal. Khusus untuk wilayah Rusia, kami menggunakan layanan Hotbox Mail.ru, yang kompatibel dengan API dengan s3. Kami tidak memerlukan modifikasi besar apa pun pada kode di dalam aplikasi, dan kami membuat mekanisme berikut: di s3 ada pemicu yang memicu pembuatan/penghapusan objek, Amazon memiliki layanan bernama Lambda - ini adalah peluncuran kode tanpa server yang akan dieksekusi tepat ketika pemicu tertentu dipicu.
Kami melakukannya dengan sangat sederhana: jika pemicu kami diaktifkan, kami menjalankan kode yang akan menyalin objek ke penyimpanan Mail.ru. Untuk meluncurkan sepenuhnya pekerjaan dengan salinan data lokal, kami juga memerlukan sinkronisasi terbalik sehingga klien yang berada di segmen Rusia dapat bekerja dengan penyimpanan yang lebih dekat dengan mereka. Mail akan menyelesaikan pemicu dalam penyimpanannya - sinkronisasi terbalik dapat dilakukan pada tingkat infrastruktur, tetapi untuk saat ini kami melakukan ini pada tingkat kode kami sendiri. Jika kita melihat klien telah memposting file, maka pada tingkat kode kita menempatkan acara tersebut dalam antrian, memprosesnya dan melakukan replikasi terbalik. Mengapa ini buruk: jika kami melakukan beberapa jenis pekerjaan dengan objek kami di luar produk kami, yaitu dengan cara eksternal, kami tidak akan memperhitungkannya. Oleh karena itu, kami menunggu hingga akhir, ketika pemicu muncul di tingkat penyimpanan, sehingga dari mana pun kami mengeksekusi kode, objek yang datang kepada kami akan disalin ke arah lain.
Pada tingkat kode, kami mendaftarkan kedua penyimpanan untuk setiap klien: satu dianggap sebagai penyimpanan utama, yang lain dianggap sebagai penyimpanan cadangan. Jika semuanya baik-baik saja, kami bekerja dengan penyimpanan yang lebih dekat dengan kami: yaitu, klien kami yang berada di Amazon, mereka bekerja dengan S3, dan mereka yang bekerja di Rusia, mereka bekerja dengan Hotbox. Jika tanda dipicu, maka failover harus dihubungkan, dan kami mengalihkan klien ke penyimpanan lain. Kami dapat mencentang kotak ini secara mandiri berdasarkan wilayah dan dapat menggantinya bolak-balik. Kami belum menggunakan ini dalam praktiknya, tetapi kami telah menyediakan mekanisme ini dan kami pikir suatu hari nanti kami akan membutuhkan peralihan ini dan berguna. Ini sudah terjadi satu kali.
Oh, dan Amazon melarikan diri...
Bulan April ini menandai peringatan dimulainya pemblokiran Telegram di Rusia. Penyedia yang paling terkena dampaknya adalah Amazon. Dan sayangnya, perusahaan-perusahaan Rusia yang bekerja di seluruh dunia lebih menderita.
Jika perusahaannya berskala global dan Rusia merupakan segmen yang sangat kecil, 3-5% - ya, dengan satu atau lain cara, Anda dapat mengorbankan mereka.
Jika ini adalah perusahaan murni Rusia - saya yakin perusahaan itu perlu berlokasi secara lokal - ya, itu akan nyaman bagi pengguna itu sendiri, nyaman, dan risikonya akan lebih sedikit.
Bagaimana jika ini adalah perusahaan yang beroperasi secara global dan memiliki jumlah klien yang kira-kira sama dari Rusia dan seluruh dunia? Konektivitas segmen-segmen itu penting, dan mereka harus bekerja sama satu sama lain dengan cara apa pun.
Pada akhir Maret 2018, Roskomnadzor mengirimkan surat kepada operator terbesar yang menyatakan bahwa mereka berencana memblokir beberapa juta IP Amazon untuk memblokir... Zello messenger. Berkat penyedia yang sama - mereka berhasil membocorkan surat tersebut kepada semua orang, dan ada pemahaman bahwa hubungan dengan Amazon bisa berantakan. Saat itu hari Jumat, kami berlari dengan panik ke rekan-rekan kami dari server.ru, dengan kata-kata: "Teman-teman, kami memerlukan beberapa server yang berlokasi bukan di Rusia, bukan di Amazon, tetapi, misalnya, di suatu tempat di Amsterdam," agar setidaknya dapat menginstal VPN dan proxy kami sendiri di sana untuk beberapa titik akhir yang tidak dapat kami pengaruhi dengan cara apa pun, misalnya endpont dari s3 yang sama - kami tidak dapat mencoba meningkatkan layanan baru dan mendapatkan yang berbeda ip, kami, kamu masih harus sampai di sana. Hanya dalam beberapa hari, kami menyiapkan server ini, menyiapkan dan menjalankannya, dan, secara umum, bersiap untuk saat pemblokiran dimulai. Anehnya, RKN, melihat keributan dan kepanikan, berkata: “Tidak, kami tidak akan memblokir apa pun sekarang.” (Tetapi ini persis sampai saat Telegram mulai diblokir.) Setelah mengatur kemampuan bypass dan menyadari bahwa pemblokiran belum dilakukan, namun kami tidak mulai menyelesaikan masalah secara keseluruhan. Ya, untuk berjaga-jaga.
Dan di tahun 2019 ini kita masih hidup dalam kondisi pemblokiran. Saya melihat tadi malam: sekitar satu juta IP terus diblokir. Benar, Amazon hampir sepenuhnya terbuka blokirnya, pada puncaknya mencapai 20 juta alamat... Secara umum, kenyataannya mungkin tidak ada koherensi, koherensi yang baik. Tiba-tiba. Mungkin tidak ada karena alasan teknis - kebakaran, ekskavator, dan sebagainya. Atau, seperti yang telah kita lihat, tidak sepenuhnya bersifat teknis. Oleh karena itu, seseorang yang besar dan besar, dengan ASnya sendiri, mungkin dapat mengaturnya dengan cara lain - koneksi langsung dan hal-hal lain sudah berada di level l2. Namun dalam versi sederhana, seperti milik kami atau bahkan lebih kecil, Anda dapat, untuk berjaga-jaga, memiliki redundansi pada tingkat server yang dinaikkan di tempat lain, dikonfigurasi terlebih dahulu vpn, proxy, dengan kemampuan untuk dengan cepat mengalihkan konfigurasi ke mereka di segmen tersebut yang penting untuk konektivitas Anda. Ini berguna bagi kami lebih dari sekali, ketika pemblokiran Amazon dimulai; dalam skenario terburuk, kami hanya mengizinkan lalu lintas S3 melaluinya, namun secara bertahap semua ini teratasi.
Bagaimana cara memesan... seluruh penyedia?
Saat ini kami tidak memiliki skenario jika seluruh Amazon mati. Kami memiliki skenario serupa untuk Rusia. Di Rusia, kami dihosting oleh satu penyedia, yang darinya kami memilih untuk memiliki beberapa situs. Dan setahun yang lalu kami menghadapi masalah: meskipun ini adalah dua pusat data, mungkin ada masalah pada tingkat konfigurasi jaringan penyedia yang masih akan mempengaruhi kedua pusat data tersebut. Dan kami mungkin tidak tersedia di kedua situs. Tentu saja itulah yang terjadi. Kami akhirnya mempertimbangkan kembali arsitektur di dalamnya. Tidak banyak berubah, namun untuk Rusia kini kami memiliki dua situs, yang bukan berasal dari penyedia yang sama, melainkan dari dua penyedia berbeda. Jika salah satu gagal, kita dapat beralih ke yang lain.
Secara hipotetis, untuk Amazon kami sedang mempertimbangkan kemungkinan reservasi di tingkat penyedia lain; mungkin Google, mungkin orang lain... Namun sejauh ini kami telah mengamati dalam praktiknya bahwa meskipun Amazon mengalami kecelakaan di satu zona ketersediaan, kecelakaan di tingkat seluruh wilayah cukup jarang terjadi. Oleh karena itu, secara teoritis kami mempunyai gagasan bahwa kami mungkin membuat reservasi “Amazon bukan Amazon”, namun dalam praktiknya hal ini belum terjadi.
Beberapa kata tentang otomatisasi
Apakah otomatisasi selalu diperlukan? Di sini pantas untuk mengingat kembali efek Dunning-Kruger. Pada sumbu “x” adalah pengetahuan dan pengalaman yang kita peroleh, dan pada sumbu “y” adalah keyakinan atas tindakan kita. Awalnya kita tidak tahu apa-apa dan sama sekali tidak yakin. Kemudian kita mengetahui sedikit dan menjadi sangat percaya diri - inilah yang disebut “puncak kebodohan”, diilustrasikan dengan baik oleh gambar “demensia dan keberanian”. Kemudian kami telah belajar sedikit dan siap berperang. Kemudian kita melakukan beberapa kesalahan yang sangat serius dan mendapati diri kita berada di lembah keputusasaan, ketika kita tampaknya mengetahui sesuatu, namun kenyataannya kita tidak mengetahui banyak. Kemudian, seiring bertambahnya pengalaman, kita menjadi lebih percaya diri.
Logika kita tentang berbagai peralihan otomatis ke kecelakaan tertentu dijelaskan dengan sangat baik oleh grafik ini. Kami memulainya - kami tidak tahu bagaimana melakukan apa pun, hampir semua pekerjaan dilakukan dengan tangan. Kemudian kami menyadari bahwa kami dapat menerapkan otomatisasi pada segala hal dan, seperti, tidur dengan nyenyak. Dan tiba-tiba kita mengalami mega-rake: positif palsu dipicu, dan kita mengalihkan lalu lintas bolak-balik padahal, dalam cara yang baik, kita seharusnya tidak melakukan ini. Akibatnya, replikasi gagal atau terjadi hal lain—inilah lembah keputusasaan. Dan kemudian kita sampai pada pemahaman bahwa kita harus menyikapi segala sesuatunya dengan bijak. Artinya, masuk akal untuk mengandalkan otomatisasi, yang menyediakan kemungkinan alarm palsu. Tetapi! jika akibatnya bisa parah, maka lebih baik serahkan saja pada shift tugas, kepada teknisi yang bertugas, yang akan memastikan dan memantau bahwa memang ada kecelakaan, dan akan melakukan tindakan yang diperlukan secara manual...
Kesimpulan
Selama 7 tahun, kami beralih dari fakta bahwa ketika sesuatu jatuh, ada kepanikan-panik, menjadi pemahaman bahwa masalah tidak ada, yang ada hanyalah tugas, mereka harus - dan bisa - diselesaikan. Saat Anda sedang membangun suatu layanan, lihatlah dari atas, nilai semua risiko yang mungkin terjadi. Jika Anda langsung melihatnya, perkirakan redundansi terlebih dahulu dan kemungkinan membangun infrastruktur yang toleran terhadap kesalahan, karena titik mana pun yang dapat gagal dan menyebabkan tidak dapat dioperasikannya layanan pasti akan menyebabkan kegagalan. Dan meskipun menurut Anda beberapa elemen infrastruktur pasti tidak akan gagal - seperti s3 yang sama, ingatlah bahwa mereka bisa. Dan setidaknya secara teori, miliki gambaran tentang apa yang akan Anda lakukan terhadap mereka jika sesuatu terjadi. Miliki rencana manajemen risiko. Saat Anda berpikir untuk melakukan segala sesuatu secara otomatis atau manual, pertimbangkan risikonya: apa yang akan terjadi jika otomatisasi mulai mengalihkan segalanya - bukankah hal ini akan menyebabkan situasi yang lebih buruk dibandingkan dengan kecelakaan? Mungkin di suatu tempat perlu untuk menggunakan kompromi yang masuk akal antara penggunaan otomatisasi dan reaksi insinyur yang bertugas, yang akan mengevaluasi gambaran sebenarnya dan memahami apakah sesuatu perlu segera dialihkan atau “ya, tetapi tidak sekarang.”
Kompromi yang masuk akal antara perfeksionisme dan upaya nyata, waktu, uang yang dapat Anda keluarkan untuk skema yang pada akhirnya akan Anda miliki.
Teks ini adalah versi terbaru dan diperluas dari laporan Alexander Demidov di konferensi tersebut .
Sumber: www.habr.com