Rahasia toleransi kesalahan kantor depan kami

Bagaimana bank modern diatur? Ada kantor di mana berbagai operasi dilakukan, akun dan laporan disimpan. Ada kantor pusat di mana keputusan dibuat dan risiko dinilai, di mana risiko kredit dinilai dan penipu dilawan. Dan ada kantor depan di mana mereka melayani pelanggan dan bertanggung jawab atas interaksi mereka dengan bank melalui berbagai saluran.



Sberbank memiliki ratusan sistem dengan ketersediaan dan keandalan yang beragam. Ini memiliki pengembangan sendiri, dan solusi kotak dengan berbagai tingkat penyesuaian, SLA berbeda. Semua sistem terintegrasi satu sama lain dalam banyak cara. Dalam posting ini, kami akan memberi tahu Anda bagaimana seluruh bukit semut front-end ini dibangun sedemikian rupa untuk menyediakan layanan pelanggan yang berkelanjutan.

Mari kita mulai dengan teorinya. Prinsip-prinsip utama dimana sistem gagal-aman dibangun dapat dipinjam dari kapal selam:

1. Kapal selam ini dibagi menjadi kompartemen independen. Jika satu kompartemen terendam, sisanya masih bertahan.
   
2. Semua komponen penting dicadangkan. Mesin, tangki oksigen. Dan The Beatles juga memesan periskop dengan lubang intip.
   
3. Kapal selam dilindungi dari kondisi kritis di permukaan - jika perlu, itu bisa masuk lebih dalam dan bekerja di sana seolah-olah tidak ada yang terjadi.
   

Kami menggambarkan prinsip pertama dengan contoh dari praktik kami. Kami memiliki sistem cache terdistribusi. Dan begitu dimuat, salah satu node data cache gagal. Tidak apa-apa: untuk mempertahankan replikasi yang tepat, controller mendistribusikan kembali data ke node yang tersisa. Tetapi sebagai akibat dari redistribusi, lalu lintas jaringan melonjak dan paket-paket mulai hilang - termasuk overhead cache. Pada satu titik, controller memutuskan bahwa node data lain gagal, mendistribusikan kembali data lagi, lalu lintas meningkat ... Akibatnya, dalam waktu kurang dari satu menit sistem turun sepenuhnya. Untungnya, itu adalah sirkuit beban dan tidak ada yang terluka. Tapi kami menghabiskan banyak waktu mencari penyebabnya.

Dapat diperdebatkan bahwa ini tidak terjadi dengan database berkerumun dan server high-end - ada redundansi dibangun di tingkat perangkat keras. Mengutip Werner Vogels, CTO Amazon: "Semuanya gagal sepanjang waktu." Kami jatuh dan cluster basis data, dan server kelas atas. Jatuh karena kesalahan konfigurasi, karena masalah dalam perangkat lunak manajemen. Dengan solusi dari setiap masalah, kepercayaan kami pada solusi tersebut menurun. Sebagai hasilnya, kami sampai pada kesimpulan: hanya sistem yang dibagi menjadi beberapa bagian yang independen satu sama lain - terutama independen dalam manajemen - tidak menolak.

Arsitektur multi-blok

Solusi untuk masalah kami adalah arsitektur multi-blok. Di dalamnya, semua komponen perangkat keras, termasuk basis data, dibagi menjadi beberapa blok yang bebas dan hampir bebas. Setiap blok melayani sebagian dari klien, seperti ketika sharding di database. Node dalam setiap blok dicadangkan di semua level, termasuk geo-redundansi. Masalah apa pun dalam satu blok tidak memengaruhi yang lain. Dengan peningkatan jumlah pelanggan, kami dapat dengan mudah menambahkan blok baru dan terus bekerja secara normal.


Arsitektur blok umum. Semua blok dicadangkan sesuai dengan skema 2N. Setiap pusat data memiliki penyeimbang beban perangkat keras yang kuat. Pusat data dihubungkan oleh 2-3 saluran komunikasi independen.

Server didistribusikan dalam blok lima jenis:

• Router - unit kontrol yang mendistribusikan klien ke seluruh unit
  
• Blok klien - blok utama yang melayani hingga 10 juta klien
  
• Blok percontohan - di sini kami menguji versi aplikasi baru pada pelanggan setia (sekitar 300 ribu orang, terutama karyawan Sberbank)
  
• Unit tamu - pengguna yang tidak diauthentikasi dilayani melaluinya; mereka, misalnya, yang datang melalui situs
  
• Blok cadangan - blok pengaman yang cukup kuat untuk menggantikan dua blok klien sekaligus
  

Di dalam setiap blok, server aplikasi dan server web dipisahkan oleh saluran layanan, tetapi basis datanya umum. Jadi kami dapat mengisolasi skenario kegagalan yang paling umum sehingga tidak melampaui batas saluran kami.

Bagaimana cara kerjanya?

Pertama, pengguna memasuki unit router. Blok ini memeriksa di mana klien memblokir orang tersebut dan mengirimkannya ke sana (atau ke blok tamu). Selanjutnya, seseorang dengan tenang bekerja di dalam bloknya. Jika terjadi kegagalan pada unit asli, orang tersebut kembali ke router dan secara otomatis menerima arahan ke unit cadangan untuk pekerjaan lebih lanjut.

Apa yang terjadi pada data selama operasi? Informasi tentang interaksi klien dengan bank terus direplikasi dari blok klien ke database arsip. Setelah bertemu dengan pengguna, unit cadangan mengambil informasi yang diperlukan tentang dia dari database arsip dan, jika perlu, menyediakan data - sehingga pengguna tidak membeku ketika masalah muncul di pihak kami.

Operasi yang dilakukan di unit cadangan disimpan di dalamnya. Ketika blok klien asli pengguna dipulihkan, itu kembali. Operasi yang terakumulasi dalam blok cadangan ditransfer secara tidak sinkron ke blok klien yang diperlukan. Sementara data direduksi menjadi konsistensi, klien melihat pesan yang menyatakan bahwa semua operasi telah diterima dan disimpan, tetapi karena pekerjaan teknis, operasi terbaru mungkin tidak ditampilkan.


Skema umum sistem

Dalam beberapa kasus, beralih ke blok cadangan direncanakan di muka - misalnya, ketika memperbarui di blok klien. Kemudian unit cadangan tidak mengambil sesi klien, tetapi pada saat tertentu hanya memulai semua operasi baru. Jika Anda perlu segera beralih ke unit cadangan, administrator dapat menonaktifkan semua sesi. Dalam hal ini, sesi pengguna akan terganggu, dan ia akan memulai yang baru pada unit cadangan. Unit router, omong-omong, memiliki unit cadangan khusus sendiri. Jadi tidak ada yang tersisa tanpa roda cadangan.

Pembaruan sistem

Versi perangkat lunak baru digunakan terlebih dahulu di blok uji coba dan ditampilkan kepada khalayak terbatas. Kemudian secara bertahap pada blok klien, dan sudah pada akhirnya - pada yang cadangan. Jadi jika ada masalah di blok klien dengan versi baru dari perangkat lunak, kami dapat mentransfer klien ke blok cadangan dari yang lama.

Ketika fungsi baru bergulir ke blok, itu tidak menyala secara otomatis. Administrator melakukan ini menggunakan kotak centang - fitur toggle. Anda dapat mengalihkan klien ke versi baru dengan grup - beginilah cara kami memeriksa reaksi pembaruan terhadap pertumbuhan pemirsa.

Otonomi

Sistem kami sendiri dapat diandalkan, tetapi masih tergantung pada backend yang digunakan untuk operasi. Bagaimana cara melindungi diri dari masalah? Kami menggunakan tiga alat.

1. Permintaan yang tertunda . Klien meminta operasi untuk diselesaikan. Kami menyimpannya di database kami dan mencoba menjalankannya di backend. Jika backend tidak merespons, kami menunjukkan kepada klien pesan bahwa operasi telah diterima dan sedang diproses. Ketika backend naik, "buruh pelabuhan" yang terpisah membaca operasi yang tidak lengkap dari database, dan "mendorong" mereka ke dalam batch dalam sistem backend. Agar tidak membebani tabel utama dengan operasi dengan sejumlah besar kueri efisien rendah, kami juga menggunakan tabel token yang disebut - daftar pengidentifikasi operasi tidak lengkap. Agar tidak menjatuhkan backend yang baru saja naik ratusan ribu operasi, kami menggunakan batching - kami menjatuhkan dua ratus operasi dan menunggu, misalnya, selama beberapa detik.
   
   
   
   Tetapi bagaimana jika perubahan penting terjadi antara permintaan pengguna dan pemulihan backend? Misalnya, sudahkah nilai tukar bergerak? Dalam hal ini, verifikasi ganda dipicu. Operasi-operasi ini disimpan saat masuk, dan kemudian diverifikasi pada saat dieksekusi. Jika sesuatu tidak konvergen, operasi akan disesuaikan atau ditolak.
   
2. Caching data . Ketika seorang pengguna masuk, misalnya, Sberbank Online, semua informasi yang diperlukan tentang dirinya sudah terlihat - tagihan, kartu, pinjaman, dll. Data ini diminta melalui bus layanan dari selusin sistem. Jika respons dikumpulkan dengan cepat, dalam beberapa detik, kami menampilkan data kepada klien dan menyimpannya dalam cache sistem dari basis data kami. Jika tidak, maka kami mencari di dalam database untuk data yang sebelumnya di-cache dan menunjukkannya kepada klien. Tentu saja, untuk ini, cache harus tidak lebih dari usia tertentu. Namun, ketika bus layanan mengumpulkan data yang diperlukan berdasarkan permintaan, bus layanan diperbarui dalam cache database dan dikirim ke klien alih-alih yang lebih lama.
   
   Saat menggunakan aplikasi, ini berarti seseorang akan melihat status akunnya beberapa detik setelah masuk. Meskipun data mungkin agak ketinggalan jaman. Jika ini terjadi, maka setelah beberapa detik, data biasanya diganti dengan yang sebenarnya - yang berarti bahwa service bus telah mengumpulkan semua yang Anda butuhkan.
   
   Selain itu, kami memiliki pra-caching menggunakan replikasi. Sebagian besar untuk data referensi yang berbeda. Kami memasukkan data ini ke backend, klien dengan tenang membuat permintaan untuk operasi, dan kami mengirimkannya. Bahkan jika sistem yang bertanggung jawab untuk menjaga data tidak berfungsi, pengguna tidak harus menunggu lagi.
   
3. Jeda teknis . Jika sistem backend macet atau sedang dalam pemeliharaan, kami menandainya. Dan kemudian operasi yang melewatinya segera dipenuhi oleh penolakan. Jadi kami menyimpan server aplikasi dari meluap dengan permintaan menunggu respons dengan batas waktu. Dalam mode ini, caching operasi dan data yang kami jelaskan sebelumnya dapat digunakan. Istirahat teknis ditetapkan untuk setiap skenario integrasi, secara manual oleh administrator atau secara otomatis, berdasarkan jumlah permintaan.
   

Dalam hal apa pun, kami berupaya meminimalkan ekspektasi pengguna - jika ada masalah, ia segera menerima pesan tentang ketidakmungkinan operasi. Kami mencoba meminimalkan jumlah pesan seperti itu, oleh karena itu kami meningkatkan masa pakai beberapa data yang di-cache - ini memungkinkan kami untuk memperluas interaksi normal dengan layanan bank.

Dalam beberapa skenario, caching tidak boleh dibawa pergi - misalnya, ketika mengeluarkan uang tunai. Mungkin penipuan pada bagian dari klien. Operasi seperti itu di ATM dan cabang tidak di-cache. Di bank Internet, ini lebih mudah - kami menerima aplikasi, lalu memprosesnya atau menolaknya.

Akibatnya, dengan mengamati prinsip-prinsip yang dijelaskan dalam artikel, Anda bisa mendapatkan sistem dengan ketersediaan 99,99% dan lebih tinggi.

Rencana kami

Sekarang rencananya adalah untuk meminimalkan waktu-ke-pasar sistem tunggal kami, untuk memastikan omnichannelity, dengan mempertimbangkan fitur-fitur teknis dan bisnis saluran. Dan juga memigrasi sistem lawas sambil mempertahankan operabilitasnya selama beraktivitas.

Kami berterima kasih kepada Roman Shekhovtsov untuk bantuan aktif dalam persiapan posting