HighLoad++, Evgeniy Kuzovlev (EcommPay IT): perkara yang perlu dilakukan apabila satu minit masa henti bernilai $100000

Semua orang bercakap tentang proses pembangunan dan ujian, melatih kakitangan, meningkatkan motivasi, tetapi proses ini tidak mencukupi apabila satu minit masa berhenti perkhidmatan memerlukan sejumlah besar wang. Apa yang perlu dilakukan apabila anda menjalankan transaksi kewangan di bawah SLA yang ketat? Bagaimana untuk meningkatkan kebolehpercayaan dan toleransi kesalahan sistem anda, mengambil pembangunan dan ujian daripada persamaan?

Persidangan HighLoad++ seterusnya akan diadakan pada 6 dan 7 April 2020 di St. Petersburg. Butiran dan tiket untuk pautan. 9 November, 18:00. HighLoad++ Moscow 2018, dewan Delhi + Kolkata. Tesis dan persembahan.

Evgeniy Kuzovlev (selepas ini – EC): - Kawan, hello! Nama saya Kuzovlev Evgeniy. Saya dari syarikat EcommPay, bahagian tertentu ialah EcommPay IT, bahagian IT kumpulan syarikat. Dan hari ini kita akan bercakap tentang masa henti - tentang cara mengelakkannya, tentang cara meminimumkan akibatnya jika ia tidak dapat dielakkan. Topik dinyatakan seperti berikut: "Apa yang perlu dilakukan apabila satu minit masa henti bernilai $100"? Melihat ke hadapan, bilangan kita adalah setanding.

Apakah yang EcommPay IT lakukan?

Siapakah kita? Kenapa saya berdiri di sini di hadapan awak? Mengapa saya mempunyai hak untuk memberitahu anda sesuatu di sini? Dan apa yang akan kita bincangkan di sini dengan lebih terperinci?

Kumpulan syarikat EcommPay ialah pemeroleh antarabangsa. Kami memproses pembayaran di seluruh dunia - di Rusia, Eropah, Asia Tenggara (Seluruh Dunia). Kami mempunyai 9 pejabat, 500 pekerja keseluruhannya, dan kira-kira kurang daripada separuh daripada mereka adalah pakar IT. Semua yang kita buat, semua yang kita buat duit, kita buat sendiri.

Kami menulis semua produk kami (dan kami mempunyai banyak produk - dalam barisan produk IT besar kami, kami mempunyai kira-kira 16 komponen berbeza) sendiri; Kita menulis diri kita, kita membangunkan diri kita sendiri. Dan pada masa ini kami menjalankan kira-kira satu juta transaksi sehari (berjuta-juta mungkin cara yang betul untuk mengatakannya). Kami adalah syarikat yang agak muda - kami baru berumur kira-kira enam tahun.

6 tahun yang lalu ia adalah satu permulaan apabila mereka datang bersama-sama dengan perniagaan. Mereka disatukan oleh idea (tiada apa-apa selain idea), dan kami berlari. Seperti mana-mana permulaan, kami berlari lebih pantas... Bagi kami, kelajuan adalah lebih penting daripada kualiti.

Pada satu ketika kami berhenti: kami menyedari bahawa kami tidak lagi boleh hidup pada kelajuan itu dan dengan kualiti itu dan kami perlu memberi tumpuan kepada kualiti terlebih dahulu. Pada masa ini, kami memutuskan untuk menulis platform baharu yang betul, berskala dan boleh dipercayai. Mereka mula menulis platform ini (mereka mula melabur, membangunkan pembangunan, menguji), tetapi pada satu ketika mereka menyedari bahawa pembangunan dan ujian tidak membenarkan kami mencapai tahap kualiti perkhidmatan yang baharu.

Anda membuat produk baharu, anda memasukkannya ke dalam pengeluaran, tetapi masih ada sesuatu yang tidak kena di suatu tempat. Dan hari ini kita akan bercakap tentang cara untuk mencapai tahap kualiti baharu (bagaimana kami melakukannya, tentang pengalaman kami), mengambil pembangunan dan ujian daripada persamaan; kita akan bercakap tentang apa yang tersedia untuk operasi - apakah operasi boleh lakukan sendiri, apa yang boleh ditawarkan untuk ujian untuk mempengaruhi kualiti.

Masa henti. Perintah operasi.

Sentiasa menjadi asas utama, perkara yang akan kita bincangkan hari ini ialah masa henti. Satu perkataan yang dahsyat. Jika kita mempunyai masa henti, semuanya tidak baik untuk kita. Kami berlari untuk menaikkannya, pentadbir memegang pelayan - Allah melarang ia tidak jatuh, seperti yang mereka katakan dalam lagu itu. Inilah yang akan kita bincangkan hari ini.

Apabila kami mula mengubah pendekatan kami, kami membentuk 4 perintah. Saya telah menyampaikannya pada slaid:

Perintah-perintah ini agak mudah:

• Kenal pasti masalah dengan cepat.
• Menghapuskannya dengan lebih cepat.
• Bantu memahami sebabnya (kemudian, untuk pembangun).
• Dan menyeragamkan pendekatan.

Saya ingin menarik perhatian anda kepada perkara No. 2. Kami sedang menyingkirkan masalah, bukan menyelesaikannya. Membuat keputusan adalah menengah. Bagi kami, perkara utama ialah pengguna dilindungi daripada masalah ini. Ia akan wujud dalam beberapa persekitaran terpencil, tetapi persekitaran ini tidak akan mempunyai sebarang hubungan dengannya. Sebenarnya, kami akan melalui empat kumpulan masalah ini (ada yang lebih terperinci, ada yang kurang terperinci), saya akan memberitahu anda apa yang kami gunakan, pengalaman relevan yang kami ada dalam penyelesaian.

Penyelesaian masalah: Bilakah ia berlaku dan apa yang perlu dilakukan terhadapnya?

Tetapi kita akan mula tidak teratur, kita akan mulakan dengan titik No. 2 - bagaimana dengan cepat menghilangkan masalah itu? Terdapat masalah - kita perlu menyelesaikannya. “Apa yang perlu kita lakukan mengenai perkara ini?” - soalan utama. Dan apabila kami mula berfikir tentang cara menyelesaikan masalah itu, kami membangunkan sendiri beberapa keperluan yang mesti diikuti oleh penyelesaian masalah.

Untuk merumuskan keperluan ini, kami memutuskan untuk bertanya kepada diri sendiri soalan: "Bilakah kami menghadapi masalah"? Dan masalah, ternyata, berlaku dalam empat kes:

• Kegagalan perkakasan.
• Perkhidmatan luar gagal.
• Menukar versi perisian (pengerahan yang sama).
• Pertumbuhan beban letupan.

Kami tidak akan bercakap tentang dua yang pertama. Kerosakan perkakasan boleh diselesaikan dengan mudah: anda mesti mempunyai semua pendua. Jika ini adalah cakera, cakera mesti dipasang dalam RAID; jika ini adalah pelayan, pelayan mesti diduplikasi; jika anda mempunyai infrastruktur rangkaian, anda mesti membekalkan salinan kedua infrastruktur rangkaian, iaitu, anda mengambilnya dan menduplikasinya. Dan jika sesuatu gagal, anda beralih kepada kuasa simpanan. Sukar untuk mengatakan apa-apa lagi di sini.

Yang kedua ialah kegagalan perkhidmatan luar. Bagi kebanyakan, sistem itu tidak menjadi masalah sama sekali, tetapi bukan untuk kami. Memandangkan kami memproses pembayaran, kami adalah pengagregat yang berdiri di antara pengguna (yang memasukkan data kadnya) dan bank, sistem pembayaran (Visa, MasterCard, Mira, dll.). Perkhidmatan luaran kami (sistem pembayaran, bank) cenderung gagal. Kami mahupun anda (jika anda mempunyai perkhidmatan sedemikian) tidak boleh mempengaruhi perkara ini.

Apa yang perlu dilakukan kemudian? Terdapat dua pilihan di sini. Pertama, jika anda boleh, anda harus menduplikasi perkhidmatan ini dalam beberapa cara. Contohnya, jika boleh, kami memindahkan trafik dari satu perkhidmatan ke perkhidmatan lain: contohnya, kad diproses melalui Sberbank, Sberbank menghadapi masalah - kami memindahkan trafik [bersyarat] ke Raiffeisen. Perkara kedua yang boleh kami lakukan ialah melihat kegagalan perkhidmatan luaran dengan cepat, dan oleh itu kami akan bercakap tentang kelajuan tindak balas dalam bahagian seterusnya laporan.

Malah, daripada empat ini, kami secara khusus boleh mempengaruhi perubahan versi perisian - mengambil tindakan yang akan membawa kepada penambahbaikan dalam situasi dalam konteks penggunaan dan dalam konteks pertumbuhan letupan dalam beban. Sebenarnya, itulah yang kami lakukan. Di sini, sekali lagi, nota kecil...

Daripada empat masalah ini, beberapa masalah diselesaikan dengan segera jika anda mempunyai awan. Jika anda berada dalam Microsoft Azhur, awan Ozon, atau menggunakan awan kami, daripada Yandex atau Mail, maka sekurang-kurangnya kerosakan perkakasan menjadi masalah mereka dan semuanya akan menjadi baik untuk anda dalam konteks kerosakan perkakasan.

Kami adalah syarikat yang sedikit tidak konvensional. Di sini semua orang bercakap tentang "Kubernet", tentang awan - kami tidak mempunyai "Kubernet" mahupun awan. Tetapi kami mempunyai rak perkakasan di banyak pusat data, dan kami terpaksa menggunakan perkakasan ini, kami terpaksa bertanggungjawab untuk semuanya. Oleh itu, kita akan bercakap dalam konteks ini. Jadi, tentang masalah. Dua yang pertama dikeluarkan dari kurungan.

Menukar versi perisian. Pangkalan

Pembangun kami tidak mempunyai akses kepada pengeluaran. Kenapa begitu? Cuma kami diperakui PCI DSS, dan pembangun kami langsung tidak mempunyai hak untuk masuk ke dalam "produk". Itu sahaja, tempoh. sama sekali. Oleh itu, tanggungjawab pembangunan tamat tepat pada masa pembangunan menyerahkan binaan untuk dikeluarkan.

Asas kedua yang kami ada, yang juga banyak membantu kami, ialah ketiadaan pengetahuan unik tanpa dokumen. Saya harap ia sama untuk anda. Kerana jika ini tidak berlaku, anda akan menghadapi masalah. Masalah akan timbul apabila pengetahuan yang unik dan tidak berdokumen ini tidak hadir pada masa yang betul di tempat yang betul. Katakan anda mempunyai seorang yang tahu cara menggunakan komponen tertentu - orang itu tiada di sana, dia sedang bercuti atau sakit - itu sahaja, anda menghadapi masalah.

Dan asas ketiga yang kami datangi. Kami mencapainya melalui kesakitan, darah, air mata - kami membuat kesimpulan bahawa mana-mana binaan kami mengandungi ralat, walaupun ia bebas ralat. Kami memutuskan ini untuk diri kami sendiri: apabila kami menggunakan sesuatu, apabila kami melancarkan sesuatu ke dalam pengeluaran, kami mempunyai binaan dengan ralat. Kami telah membentuk keperluan yang mesti dipenuhi oleh sistem kami.

Keperluan untuk menukar versi perisian

Terdapat tiga keperluan:

• Kita mesti segera melancarkan semula penempatan.
• Kita mesti meminimumkan kesan penempatan yang tidak berjaya.
• Dan kita mesti dapat menggunakan pantas secara selari.
  Tepat dalam susunan itu! kenapa? Kerana, pertama sekali, apabila menggunakan versi baharu, kelajuan tidak penting, tetapi adalah penting untuk anda, jika berlaku masalah, untuk cepat berpatah balik dan mempunyai impak yang minimum. Tetapi jika anda mempunyai satu set versi dalam pengeluaran, yang ternyata terdapat ralat (secara tiba-tiba, tidak ada penggunaan, tetapi terdapat ralat) - kelajuan penggunaan berikutnya adalah penting untuk anda. Apakah yang telah kita lakukan untuk memenuhi tuntutan ini? Kami menggunakan kaedah berikut:

  
  
  Ia agak terkenal, kami tidak pernah menciptanya - ini adalah penggunaan Biru/Hijau. Apa ini? Anda mesti mempunyai salinan untuk setiap kumpulan pelayan yang mana aplikasi anda dipasang. Salinan adalah "hangat": tiada trafik padanya, tetapi pada bila-bila masa trafik ini boleh dihantar ke salinan ini. Salinan ini mengandungi versi sebelumnya. Dan pada masa penggunaan, anda melancarkan kod kepada salinan yang tidak aktif. Kemudian anda menukar sebahagian daripada trafik (atau semua) kepada versi baharu. Oleh itu, untuk menukar aliran trafik dari versi lama kepada yang baharu, anda hanya perlu melakukan satu tindakan: anda perlu menukar pengimbang di hulu, menukar arah - dari satu hulu ke yang lain. Ini sangat mudah dan menyelesaikan masalah pensuisan pantas dan pemulangan pantas.

  Di sini penyelesaian kepada soalan kedua ialah meminimumkan: anda boleh menghantar hanya sebahagian daripada trafik anda ke baris baharu, ke baris dengan kod baharu (biarlah, sebagai contoh, 2%). Dan 2% ini bukan 100%! Jika anda kehilangan 100% daripada trafik anda kerana penempatan yang tidak berjaya, itu menakutkan; jika anda kehilangan 2% daripada trafik anda, itu tidak menyenangkan, tetapi ia tidak menakutkan. Lebih-lebih lagi, pengguna kemungkinan besar tidak akan menyedari ini, kerana dalam beberapa kes (tidak dalam semua) pengguna yang sama, menekan F5, akan dibawa ke versi lain yang berfungsi.

  Penggunaan Biru/Hijau. Penghalaan

  Walau bagaimanapun, tidak semuanya begitu mudah "Kerahan Biru/Hijau"... Semua komponen kami boleh dibahagikan kepada tiga kumpulan:

  • ini ialah bahagian hadapan (halaman pembayaran yang dilihat oleh pelanggan kami);
  • teras pemprosesan;
  • penyesuai untuk bekerja dengan sistem pembayaran (bank, MasterCard, Visa...).

  Dan ada nuansa di sini - nuansa terletak pada laluan antara baris. Jika anda hanya menukar 100% trafik, anda tidak menghadapi masalah ini. Tetapi jika anda ingin menukar 2%, anda mula bertanya soalan: "Bagaimana untuk melakukan ini?" Perkara yang paling mudah ialah lurus ke hadapan: anda boleh menyediakan Round Robin dalam nginx dengan pilihan rawak, dan anda mempunyai 2% ke kiri, 98% ke kanan. Tetapi ini tidak selalu sesuai.

  Sebagai contoh, dalam kes kami, pengguna berinteraksi dengan sistem dengan lebih daripada satu permintaan. Ini adalah perkara biasa: 2, 3, 4, 5 permintaan - sistem anda mungkin sama. Dan jika penting bagi anda bahawa semua permintaan pengguna datang ke baris yang sama di mana permintaan pertama datang, atau (titik kedua) semua permintaan pengguna datang ke baris baharu selepas suis (dia boleh mula bekerja lebih awal dengan sistem, sebelum suis), - maka pengedaran rawak ini tidak sesuai untuk anda. Kemudian terdapat pilihan berikut:

  
  
  Pilihan pertama, yang paling mudah, adalah berdasarkan parameter asas klien (IP Hash). Anda mempunyai IP, dan anda membahagikannya dari kanan ke kiri dengan alamat IP. Kemudian kes kedua yang saya terangkan akan berfungsi untuk anda, apabila penggunaan berlaku, pengguna sudah boleh mula bekerja dengan sistem anda, dan dari saat penggunaan semua permintaan akan pergi ke baris baharu (kepada yang sama, katakan).

  Jika atas sebab tertentu ini tidak sesuai dengan anda dan anda mesti menghantar permintaan ke baris di mana permintaan awal dan awal pengguna datang, maka anda mempunyai dua pilihan...
  Pilihan pertama: anda boleh membeli nginx+ berbayar. Terdapat mekanisme sesi Sticky, yang, atas permintaan awal pengguna, menetapkan sesi kepada pengguna dan mengikatnya kepada satu atau satu lagi huluan. Semua permintaan pengguna seterusnya dalam jangka hayat sesi akan dihantar ke huluan yang sama di mana sesi itu disiarkan.

  Ini tidak sesuai dengan kami kerana kami sudah mempunyai nginx biasa. Beralih kepada nginx+ bukanlah mahal, cuma ia agak menyakitkan bagi kami dan tidak betul. Sebagai contoh, "Sticks Sessions", tidak berfungsi untuk kami atas sebab mudah "Sticks Sessions" tidak membenarkan penghalaan berdasarkan "Either-or". Di sana anda boleh menentukan perkara yang kami lakukan "Stick Sessions", contohnya, dengan alamat IP atau dengan alamat IP dan kuki atau mengikut postparameter, tetapi "Stick Sessions" adalah lebih rumit di sana.

  Oleh itu, kami datang kepada pilihan keempat. Kami mengambil nginx pada steroid (ini adalah openresty) - ini adalah nginx yang sama, yang juga menyokong kemasukan skrip terakhir. Anda boleh menulis skrip terakhir, memberikannya "rehat terbuka", dan skrip terakhir ini akan dilaksanakan apabila permintaan pengguna datang.

  Dan kami menulis, sebenarnya, skrip sedemikian, menetapkan diri kami "openresti" dan dalam skrip ini kami menyusun 6 parameter yang berbeza mengikut gabungan "Atau". Bergantung pada kehadiran satu atau parameter lain, kita tahu bahawa pengguna datang ke satu halaman atau yang lain, satu baris atau yang lain.

  Penggunaan Biru/Hijau. Kelebihan dan kekurangan

  Sudah tentu, mungkin untuk menjadikannya lebih mudah (menggunakan "Sesi Melekit" yang sama), tetapi kami juga mempunyai nuansa sedemikian yang bukan sahaja pengguna berinteraksi dengan kami dalam rangka satu pemprosesan satu transaksi... Tetapi sistem pembayaran juga berinteraksi dengan kami: Selepas kami memproses transaksi (dengan menghantar permintaan kepada sistem pembayaran), kami menerima coolback.
  Dan katakan, jika di dalam litar kami, kami boleh memajukan alamat IP pengguna dalam semua permintaan dan membahagikan pengguna berdasarkan alamat IP, maka kami tidak akan memberitahu "Visa" yang sama: "Kawan, kami adalah syarikat retro, kami nampaknya untuk menjadi antarabangsa (di laman web dan di Rusia)... Sila berikan kami alamat IP pengguna dalam medan tambahan, protokol anda diseragamkan”! Jelas mereka tidak akan bersetuju.

  
  
  Oleh itu, ini tidak berkesan untuk kami - kami melakukan keterbukaan. Oleh itu, dengan penghalaan kami mendapat sesuatu seperti ini:

  Penggunaan Biru/Hijau mempunyai, oleh itu, kelebihan dan keburukan yang saya nyatakan.

  Dua kelemahan:

  • anda perlu bersusah payah dengan penghalaan;
  • kelemahan utama kedua ialah perbelanjaan.

  Anda memerlukan dua kali lebih banyak pelayan, anda memerlukan dua kali lebih banyak sumber operasi, anda perlu menghabiskan dua kali lebih banyak usaha untuk mengekalkan keseluruhan zoo ini.

  Ngomong-ngomong, antara kelebihan ada satu lagi perkara yang saya tidak nyatakan sebelum ini: anda mempunyai rizab sekiranya berlaku peningkatan beban. Jika anda mempunyai pertumbuhan yang meletup dalam beban, anda mempunyai bilangan pengguna yang ramai, maka anda hanya memasukkan baris kedua dalam pengedaran 50 hingga 50 - dan anda serta-merta mempunyai pelayan x2 dalam kluster anda sehingga anda menyelesaikan masalah mempunyai lebih banyak pelayan.

  Bagaimana untuk membuat penempatan yang cepat?

  Kami bercakap tentang cara menyelesaikan masalah pengecilan dan pengembalian pantas, tetapi persoalannya tetap: "Bagaimana untuk menggunakan dengan cepat?"

  
  
  Ia ringkas dan ringkas di sini.

  • Anda mesti mempunyai sistem CD (Penghantaran Berterusan) - anda tidak boleh hidup tanpanya. Jika anda mempunyai satu pelayan, anda boleh menggunakan secara manual. Kami mempunyai kira-kira satu setengah ribu pelayan dan satu setengah ribu pemegang, sudah tentu - kami boleh menanam jabatan sebesar bilik ini hanya untuk digunakan.
  • Penyebaran mestilah selari. Jika penempatan anda berurutan, maka semuanya buruk. Satu pelayan adalah perkara biasa, anda akan menggunakan satu setengah ribu pelayan sepanjang hari.
  • Sekali lagi, untuk pecutan, ini mungkin tidak lagi diperlukan. Semasa penggunaan, projek biasanya dibina. Anda mempunyai projek web, terdapat bahagian hadapan (anda membuat pek web di sana, anda menyusun npm - sesuatu seperti itu), dan proses ini, pada dasarnya, jangka pendek - 5 minit, tetapi 5 minit ini boleh bersikap kritis. Itulah sebabnya, sebagai contoh, kami tidak berbuat demikian: kami mengalih keluar 5 minit ini, kami menggunakan artifak.

    Apakah artifak? Artifak ialah binaan yang dipasang di mana semua bahagian pemasangan telah pun siap. Kami menyimpan artifak ini dalam simpanan artifak. Pada satu masa kami menggunakan dua storan sedemikian - ia adalah Nexus dan kini jFrog Artifactory). Kami pada mulanya menggunakan "Nexus" kerana kami mula mempraktikkan pendekatan ini dalam aplikasi java (ia sesuai dengannya). Kemudian mereka meletakkan beberapa aplikasi yang ditulis dalam PHP di sana; dan "Nexus" tidak lagi sesuai, dan oleh itu kami memilih jFrog Artefactory, yang boleh mengartifaktorkan hampir segala-galanya. Kami juga telah sampai ke tahap bahawa dalam repositori artifak ini kami menyimpan pakej binari kami sendiri yang kami kumpulkan untuk pelayan.

  Pertumbuhan beban letupan

  Kami bercakap tentang menukar versi perisian. Perkara seterusnya yang kita ada ialah peningkatan beban yang meletup. Di sini, saya mungkin maksudkan dengan pertumbuhan letupan beban bukan perkara yang betul...

  Kami menulis sistem baharu - ia berorientasikan perkhidmatan, bergaya, cantik, pekerja di mana-mana, beratur di mana-mana, tidak segerak di mana-mana. Dan dalam sistem sedemikian, data boleh mengalir melalui aliran yang berbeza. Untuk transaksi pertama, pekerja ke-1, ke-3, ke-10 boleh digunakan, untuk transaksi kedua - ke-2, ke-4, ke-5. Dan hari ini, katakan, pada waktu pagi anda mempunyai aliran data yang menggunakan tiga pekerja pertama, dan pada waktu petang ia berubah secara mendadak, dan semuanya menggunakan tiga pekerja yang lain.

  Dan di sini ternyata anda perlu mengukur pekerja, entah bagaimana anda perlu meningkatkan perkhidmatan anda, tetapi pada masa yang sama menghalang kembung sumber.

  
  
  Kami telah menentukan keperluan kami. Keperluan ini agak mudah: terdapat penemuan Perkhidmatan, parameterisasi - semuanya adalah standard untuk membina sistem berskala sedemikian, kecuali satu mata - susut nilai sumber. Kami berkata bahawa kami tidak bersedia untuk melunaskan sumber supaya pelayan memanaskan udara. Kami mengambil "Konsul", kami mengambil "Nomad", yang menguruskan pekerja kami.

  Mengapa ini menjadi masalah kepada kita? Mari kita mundur sedikit. Kami kini mempunyai kira-kira 70 sistem pembayaran di belakang kami. Pada waktu pagi, lalu lintas melalui Sberbank, kemudian Sberbank jatuh, sebagai contoh, dan kami menukarnya ke sistem pembayaran lain. Kami mempunyai 100 pekerja sebelum Sberbank, dan selepas itu kami perlu meningkatkan secara mendadak 100 pekerja untuk sistem pembayaran lain. Dan adalah wajar semua ini berlaku tanpa penyertaan manusia. Kerana jika ada penyertaan manusia, harus ada seorang jurutera yang duduk di sana 24/7, yang hanya perlu melakukan ini, kerana kegagalan seperti itu, apabila 70 sistem berada di belakang anda, berlaku secara teratur.

  Oleh itu, kami melihat Nomad, yang mempunyai IP terbuka, dan menulis perkara kami sendiri, Scale-Nomad - ScaleNo, yang melakukan kira-kira seperti berikut: ia memantau pertumbuhan baris gilir dan mengurangkan atau meningkatkan bilangan pekerja bergantung pada dinamik daripada barisan. Apabila kami melakukannya, kami berfikir: "Mungkin kami boleh membuka sumbernya?" Kemudian mereka memandangnya - dia semudah dua kopecks.

  Setakat ini kami tidak membuka sumbernya, tetapi jika tiba-tiba selepas laporan itu, selepas menyedari bahawa anda memerlukan perkara sedemikian, anda memerlukannya, kenalan saya berada di slaid terakhir - sila tulis kepada saya. Jika ada sekurang-kurangnya 3-5 orang, kami akan menajanya.

  
  
  Bagaimana ia berfungsi? Jom tengok! Memandang ke hadapan: di sebelah kiri terdapat sekeping pemantauan kami: ini adalah satu baris, di bahagian atas ialah masa pemprosesan acara, di tengah ialah bilangan transaksi, di bahagian bawah ialah bilangan pekerja.

  Kalau tengok, ada glitch dalam gambar ni. Pada carta teratas, salah satu carta ranap dalam masa 45 saat - salah satu sistem pembayaran menurun. Serta-merta, trafik dibawa masuk dalam masa 2 minit dan baris gilir mula berkembang pada sistem pembayaran lain, di mana tiada pekerja (kami tidak menggunakan sumber - sebaliknya, kami melupuskan sumber itu dengan betul). Kami tidak mahu memanaskan - terdapat bilangan minimum, kira-kira 5-10 pekerja, tetapi mereka tidak dapat mengatasinya.

  Graf terakhir menunjukkan "bonggol", yang bermaksud "Skaleno" menggandakan jumlah ini. Dan kemudian, apabila graf turun sedikit, dia mengurangkannya sedikit - bilangan pekerja ditukar secara automatik. Begitulah cara perkara ini berfungsi. Kami bercakap tentang perkara nombor 2 - "Bagaimana untuk menghilangkan alasan dengan cepat."

  Pemantauan. Bagaimana untuk mengenal pasti masalah dengan cepat?

  Sekarang perkara pertama ialah "Bagaimana untuk mengenal pasti masalah dengan cepat?" Pemantauan! Kita mesti memahami perkara-perkara tertentu dengan cepat. Apakah perkara yang perlu kita fahami dengan cepat?

  
  
  Tiga perkara!

  • Kita mesti memahami dan memahami dengan cepat prestasi sumber kita sendiri.
  • Kita mesti cepat memahami kegagalan dan memantau prestasi sistem yang berada di luar kita.
  • Perkara ketiga ialah mengenal pasti ralat logik. Ini adalah apabila sistem berfungsi untuk anda, semuanya normal mengikut semua penunjuk, tetapi ada masalah.

  Saya mungkin tidak akan memberitahu anda apa-apa yang menarik di sini. Saya akan menjadi Kapten Obvious. Kami mencari apa yang ada di pasaran. Kami mempunyai "zoo yang menyeronokkan". Inilah jenis zoo yang kita ada sekarang:

  
  
  Kami menggunakan Zabbix untuk memantau perkakasan, untuk memantau penunjuk utama pelayan. Kami menggunakan Okmeter untuk pangkalan data. Kami menggunakan "Grafana" dan "Prometheus" untuk semua penunjuk lain yang tidak sesuai dengan dua yang pertama, beberapa dengan "Grafana" dan "Prometheus", dan beberapa dengan "Grafana" dengan "Influx" dan Telegraf.

  Setahun yang lalu kami mahu menggunakan New Relic. Perkara yang menarik, ia boleh melakukan segala-galanya. Tetapi setakat yang dia boleh melakukan segala-galanya, dia sangat mahal. Apabila kami meningkat kepada jumlah 1,5 ribu pelayan, seorang vendor datang kepada kami dan berkata: "Mari kita buat perjanjian untuk tahun depan." Kami melihat harga dan berkata tidak, kami tidak akan melakukannya. Kini kami meninggalkan New Relic, kami mempunyai kira-kira 15 pelayan yang tinggal di bawah pemantauan New Relic. Harga ternyata sangat liar.

  Dan terdapat satu alat yang kami laksanakan sendiri - ini ialah Debugger. Pada mulanya kami memanggilnya "Bagger," tetapi kemudian seorang guru bahasa Inggeris berlalu, ketawa besar, dan menamakannya "Debagger." Apa ini? Ini ialah alat yang, sebenarnya, dalam 15-30 saat pada setiap komponen, seperti "kotak hitam" sistem, menjalankan ujian ke atas prestasi keseluruhan komponen.

  Sebagai contoh, jika terdapat halaman luaran (halaman pembayaran), dia hanya membukanya dan melihat bagaimana ia sepatutnya kelihatan. Jika ini sedang diproses, dia menghantar "urus niaga" ujian dan memastikan bahawa "urus niaga" ini tiba. Jika ini adalah sambungan dengan sistem pembayaran, kami melancarkan permintaan ujian dengan sewajarnya, di mana kami boleh, dan memastikan semuanya baik-baik saja dengan kami.

  Apakah penunjuk yang penting untuk pemantauan?

  Apa yang terutama kita pantau? Apakah penunjuk yang penting kepada kami?

  
  

  • Masa tindak balas / RPS di hadapan adalah penunjuk yang sangat penting. Dia segera menjawab bahawa ada sesuatu yang tidak kena dengan anda.
  • Bilangan mesej yang diproses dalam semua baris gilir.
  • Bilangan pekerja.
  • Metrik ketepatan asas.

  Perkara terakhir ialah metrik "perniagaan", "perniagaan". Jika anda ingin memantau perkara yang sama, anda perlu menentukan satu atau dua metrik yang menjadi penunjuk utama untuk anda. Metrik kami ialah throughput (ini ialah nisbah bilangan transaksi yang berjaya kepada jumlah aliran transaksi). Jika sesuatu berubah di dalamnya pada selang 5-10-15 minit, itu bermakna kita mempunyai masalah (jika ia berubah secara radikal).

  Apa yang kelihatan bagi kami ialah contoh salah satu papan kami:

  
  
  Di sebelah kiri terdapat 6 graf, ini mengikut garisan - bilangan pekerja dan bilangan mesej dalam baris gilir. Di sebelah kanan - RPS, RTS. Di bawah ialah metrik "perniagaan" yang sama. Dan dalam metrik "perniagaan" kita dapat melihat dengan serta-merta bahawa sesuatu telah berlaku dalam dua graf tengah... Ini hanyalah satu lagi sistem yang berdiri di belakang kita yang telah jatuh.

  Perkara kedua yang perlu kami lakukan ialah memantau kejatuhan sistem pembayaran luar. Di sini kami mengambil OpenTracing - mekanisme, standard, paradigma yang membolehkan anda mengesan sistem teragih; dan ia telah diubah sedikit. Paradigma OpenTracing standard mengatakan bahawa kami membina jejak untuk setiap permintaan individu. Kami tidak memerlukan ini, dan kami membungkusnya dalam ringkasan, jejak pengagregatan. Kami membuat alat yang membolehkan kami menjejaki kelajuan sistem di belakang kami.

  
  
  Graf menunjukkan kepada kami bahawa salah satu sistem pembayaran mula bertindak balas dalam masa 3 saat - kami menghadapi masalah. Lebih-lebih lagi, perkara ini akan bertindak balas apabila masalah bermula, pada selang 20-30 saat.

  Dan ralat pemantauan kelas ketiga yang wujud ialah pemantauan logik.

  Sejujurnya, saya tidak tahu apa yang hendak dilukis pada slaid ini, kerana kami telah lama mencari di pasaran untuk sesuatu yang sesuai dengan kami. Kami tidak menemui apa-apa, jadi kami terpaksa melakukannya sendiri.

  
  
  Apakah yang saya maksudkan dengan pemantauan logik? Nah, bayangkan: anda menjadikan diri anda sebuah sistem (contohnya, klon Tinder); anda berjaya, melancarkannya. Pengurus yang berjaya Vasya Pupkin meletakkannya di telefonnya, melihat seorang gadis di sana, menyukainya... dan sejenisnya tidak pergi ke gadis itu - yang serupa pergi ke pengawal keselamatan Mikhalych dari pusat perniagaan yang sama. Pengurus itu turun ke bawah, dan kemudian tertanya-tanya: "Mengapa pengawal keselamatan ini Mikhalych tersenyum dengan begitu menyenangkan kepadanya?"

  Dalam situasi sebegini... Bagi kami, situasi ini kedengaran sedikit berbeza, kerana (saya tulis) ini adalah kerugian reputasi yang secara tidak langsung membawa kepada kerugian kewangan. Keadaan kami adalah sebaliknya: kami mungkin mengalami kerugian kewangan langsung - contohnya, jika kami menjalankan transaksi sebagai berjaya, tetapi ia tidak berjaya (atau sebaliknya). Saya terpaksa menulis alat saya sendiri yang memantau bilangan transaksi yang berjaya dari semasa ke semasa menggunakan penunjuk perniagaan. Tidak menjumpai apa-apa di pasaran! Inilah sebenarnya idea yang ingin saya sampaikan. Tiada apa-apa di pasaran untuk menyelesaikan masalah seperti ini.

  Ini mengenai cara mengenal pasti masalah dengan cepat.

  Bagaimana untuk menentukan sebab untuk penempatan

  Kumpulan ketiga masalah yang kami selesaikan ialah selepas kami mengenal pasti masalah itu, selepas kami menyingkirkannya, adalah baik untuk memahami sebab pembangunan, untuk menguji, dan melakukan sesuatu mengenainya. Sehubungan itu, kita perlu menyiasat, kita perlu menaikkan balak.

  
  
  Jika kita bercakap tentang log (sebab utama ialah log), sebahagian besar log kita berada dalam ELK Stack - hampir semua orang mempunyai perkara yang sama. Bagi sesetengah orang, ia mungkin bukan dalam ELK, tetapi jika anda menulis log dalam gigabait, maka lambat laun anda akan datang ke ELK. Kami menulisnya dalam terabait.

  
  
  Ada masalah di sini. Kami membetulkannya, membetulkan ralat untuk pengguna, mula mencungkil apa yang ada di sana, memanjat ke Kibana, memasukkan id transaksi di sana dan mendapat alas kaki seperti ini (menunjukkan banyak). Dan sama sekali tiada yang jelas dalam alas kaki ini. kenapa? Ya, kerana tidak jelas bahagian mana kepunyaan pekerja mana, bahagian mana kepunyaan komponen mana. Dan pada masa itu kami menyedari bahawa kami memerlukan pengesanan - OpenTracing yang sama yang saya perkatakan.

  Kami fikir ini setahun yang lalu, mengalihkan perhatian kami ke arah pasaran, dan terdapat dua alat di sana - "Zipkin" dan "Jaeger". "Jager" sebenarnya adalah pewaris ideologi, pengganti ideologi "Zipkin". Segala-galanya bagus dalam Zipkin, kecuali ia tidak tahu cara mengagregat, ia tidak tahu cara memasukkan log dalam jejak, hanya jejak masa. Dan "Jager" menyokong ini.

  Kami melihat "Jager": anda boleh aplikasi instrumen, anda boleh menulis dalam Api (standard Api untuk PHP pada masa itu, bagaimanapun, tidak diluluskan - ini setahun yang lalu, tetapi sekarang ia telah diluluskan), tetapi ada langsung tiada pelanggan. "Baiklah," kami berfikir, dan menulis pelanggan kami sendiri. Apa yang kami dapat? Ini kira-kira rupanya:

  
  
  Dalam Jaeger, rentang dicipta untuk setiap mesej. Iaitu, apabila pengguna membuka sistem, dia melihat satu atau dua blok untuk setiap permintaan masuk (1-2-3 - bilangan permintaan masuk daripada pengguna, bilangan blok). Untuk memudahkan pengguna, kami menambahkan tag pada log dan jejak masa. Sehubungan itu, sekiranya berlaku ralat, aplikasi kami akan menandakan log dengan tag Ralat yang sesuai. Anda boleh menapis mengikut teg Ralat dan hanya rentang yang mengandungi blok ini dengan ralat akan dipaparkan. Beginilah rupanya jika kita mengembangkan rentang:

  
  
  Di dalam rentang terdapat satu set jejak. Dalam kes ini, ini adalah tiga jejak ujian, dan jejak ketiga memberitahu kami bahawa ralat telah berlaku. Pada masa yang sama, di sini kita melihat jejak masa: kita mempunyai skala masa di bahagian atas, dan kita melihat pada selang masa log ini atau itu direkodkan.

  Sehubungan itu, keadaan berjalan lancar untuk kami. Kami menulis sambungan kami sendiri dan kami menggunakan sumber terbuka. Jika anda ingin bekerja dengan pengesanan, jika anda ingin bekerja dengan "Jager" dalam PHP, terdapat sambungan kami, dialu-alukan untuk digunakan, seperti yang mereka katakan:

  
  
  Kami mempunyai sambungan ini - ia adalah pelanggan untuk OpenTracing Api, ia dibuat sebagai sambungan php, iaitu, anda perlu memasangnya dan memasangnya pada sistem. Setahun yang lalu tidak ada yang berbeza. Kini terdapat pelanggan lain yang seperti komponen. Ini terpulang kepada anda: sama ada anda mengepam keluar komponen dengan komposer, atau anda menggunakan sambungan terpulang kepada anda.

  Piawaian korporat

  Kami bercakap tentang tiga perintah. Perintah keempat ialah menyeragamkan pendekatan. tentang apa ini? Ia mengenai ini:

  
  
  Mengapa perkataan "korporat" di sini? Bukan kerana kita syarikat besar atau birokratik, tidak! Saya ingin menggunakan perkataan "korporat" di sini dalam konteks bahawa setiap syarikat, setiap produk harus mempunyai standardnya sendiri, termasuk anda. Apakah piawaian yang kita ada?

  
  

  • Kami mempunyai peraturan penempatan. Kami tidak bergerak ke mana-mana tanpa dia, kami tidak boleh. Kami menggunakan kira-kira 60 kali seminggu, iaitu, kami menggunakan hampir sentiasa. Pada masa yang sama, kami mempunyai, sebagai contoh, dalam peraturan penempatan satu pantang larang mengenai penempatan pada hari Jumaat - pada dasarnya, kami tidak menggunakan.
  • Kami memerlukan dokumentasi. Tiada satu pun komponen baharu yang akan dikeluarkan jika tiada dokumentasi untuknya, walaupun ia dilahirkan di bawah kawalan pakar RnD kami. Kami memerlukan daripada mereka arahan penggunaan, peta pemantauan dan penerangan kasar (baik, seperti yang boleh ditulis oleh pengaturcara) tentang cara komponen ini berfungsi, cara menyelesaikan masalahnya.
  • Kami menyelesaikan bukan punca masalah, tetapi masalah - apa yang telah saya katakan. Adalah penting bagi kami untuk melindungi pengguna daripada masalah.
  • Kami mempunyai pelepasan. Sebagai contoh, kami tidak menganggapnya masa henti jika kami kehilangan 2% trafik dalam masa dua minit. Ini pada asasnya tidak termasuk dalam statistik kami. Jika lebih dari segi peratusan atau sementara, kita sudah kira.
  • Dan kami sentiasa menulis postmortem. Walau apa pun yang berlaku kepada kami, sebarang situasi di mana seseorang berkelakuan tidak normal dalam pengeluaran akan ditunjukkan dalam bedah siasat. Postmortem ialah dokumen di mana anda menulis apa yang berlaku kepada anda, masa yang terperinci, perkara yang anda lakukan untuk membetulkannya dan (ini adalah blok wajib!) perkara yang anda akan lakukan untuk mengelakkan perkara ini daripada berlaku pada masa hadapan. Ini adalah wajib dan perlu untuk analisis seterusnya.

  Apakah yang dianggap masa henti?

  
  
  Apa yang menyebabkan semua ini?

  Ini membawa kepada fakta bahawa (kami mempunyai masalah tertentu dengan kestabilan, ini tidak sesuai dengan pelanggan atau kami) sepanjang 6 bulan lalu penunjuk kestabilan kami ialah 99,97. Kita boleh mengatakan bahawa ini tidak terlalu banyak. Ya, kita ada sesuatu untuk diusahakan. Daripada penunjuk ini, kira-kira separuh adalah kestabilan, seolah-olah, bukan milik kami, tetapi tembok api aplikasi web kami, yang berdiri di hadapan kami dan digunakan sebagai perkhidmatan, tetapi pelanggan tidak mengambil berat tentang perkara ini.

  Kami belajar tidur pada waktu malam. Akhirnya! Enam bulan lalu kami tidak dapat. Dan pada nota ini dengan hasilnya, saya ingin membuat satu nota. Malam tadi ada laporan menarik tentang sistem kawalan untuk reaktor nuklear. Jika orang yang menulis sistem ini boleh mendengar saya, sila lupakan apa yang saya katakan tentang "2% bukan masa henti." Bagi anda, 2% ialah masa henti, walaupun selama dua minit!

  Itu sahaja! Soalan anda.

  
  

  Mengenai pengimbang dan penghijrahan pangkalan data

  Soalan daripada hadirin (selepas ini – B): – Selamat malam. Terima kasih banyak atas laporan admin sebegini! Soalan ringkas tentang pengimbang anda. Anda menyebut bahawa anda mempunyai WAF, iaitu, seperti yang saya faham, anda menggunakan sejenis pengimbang luaran...

  EK: – Tidak, kami menggunakan perkhidmatan kami sebagai pengimbang. Dalam kes ini, WAF ialah alat perlindungan DDoS secara eksklusif untuk kami.

  V: – Bolehkah anda menyebut beberapa perkataan tentang pengimbang?

  EK: – Seperti yang telah saya katakan, ini adalah sekumpulan pelayan dalam openresty. Kami kini mempunyai 5 kumpulan simpanan yang bertindak balas secara eksklusif... iaitu pelayan yang menjalankan secara eksklusif openresty, ia hanya proksi trafik. Sehubungan itu, untuk memahami jumlah yang kami pegang: kami kini mempunyai aliran trafik tetap beberapa ratus megabit. Mereka mengatasi, mereka berasa baik, mereka tidak membebankan diri mereka sendiri.

  V: - Juga soalan mudah. Berikut ialah penempatan Biru/Hijau. Apa yang anda lakukan, sebagai contoh, dengan migrasi pangkalan data?

  EK: - Soalan yang baik! Lihat, dalam penggunaan Biru/Hijau kita mempunyai baris gilir yang berasingan untuk setiap baris. Iaitu, jika kita bercakap tentang baris gilir acara yang dihantar dari pekerja ke pekerja, terdapat baris gilir berasingan untuk garis biru dan garis hijau. Jika kita bercakap tentang pangkalan data itu sendiri, maka kita sengaja mengecilkannya seberapa banyak yang kita boleh, memindahkan semuanya secara praktikal ke dalam baris gilir; dalam pangkalan data kita hanya menyimpan timbunan transaksi. Dan tindanan transaksi kami adalah sama untuk semua baris. Dengan pangkalan data dalam konteks ini: kami tidak membahagikannya kepada biru dan hijau, kerana kedua-dua versi kod mesti tahu apa yang berlaku dengan transaksi.

  Rakan-rakan, saya juga mempunyai sedikit hadiah untuk merangsang anda - sebuah buku. Dan saya sepatutnya dianugerahkan untuk soalan terbaik.

  V: - Hello. Terima kasih atas laporan itu. Soalannya begini. Anda memantau pembayaran, anda memantau perkhidmatan yang anda berkomunikasi... Tetapi bagaimanakah anda memantau supaya seseorang entah bagaimana datang ke halaman pembayaran anda, membuat pembayaran, dan projek itu mengkreditkannya dengan wang? Iaitu, bagaimana anda memantau bahawa perarakan tersedia dan telah menerima panggilan balik anda?

  EK: – “Pedagang” bagi kami dalam kes ini adalah perkhidmatan luaran yang sama seperti sistem pembayaran. Kami memantau kelajuan tindak balas pedagang.

  Mengenai penyulitan pangkalan data

  V: - Hello. Saya ada soalan yang berkaitan sedikit. Anda mempunyai data sensitif PCI DSS. Saya ingin tahu cara anda menyimpan PAN dalam baris gilir yang perlu anda pindahkan? Adakah anda menggunakan sebarang penyulitan? Dan ini membawa kepada soalan kedua: menurut PCI DSS, adalah perlu untuk menyulitkan semula pangkalan data secara berkala sekiranya berlaku perubahan (pemecatan pentadbir, dll.) - apa yang berlaku kepada kebolehaksesan dalam kes ini?

  
  
  EK: - Soalan yang menarik! Pertama, kami tidak menyimpan PAN dalam baris gilir. Kami tidak mempunyai hak untuk menyimpan PAN di mana-mana sahaja dalam bentuk yang jelas, pada dasarnya, jadi kami menggunakan perkhidmatan khas (kami memanggilnya "Kademon") - ini adalah perkhidmatan yang hanya melakukan satu perkara: ia menerima mesej sebagai input dan menghantar keluar mesej yang disulitkan. Dan kami menyimpan segala-galanya dengan mesej yang disulitkan ini. Oleh itu, panjang kunci kami adalah di bawah satu kilobait, supaya ini serius dan boleh dipercayai.

  V: – Adakah anda memerlukan 2 kilobait sekarang?

  EK: – Nampaknya baru semalam 256... Nah, di mana lagi?!

  Sehubungan itu, ini adalah yang pertama. Dan kedua, penyelesaian yang wujud, ia menyokong prosedur penyulitan semula - terdapat dua pasang "keks" (kunci), yang memberikan "dek" yang menyulitkan (kunci adalah kunci, dek adalah derivatif daripada kunci yang menyulitkan) . Dan jika prosedur itu dimulakan (ia berlaku secara teratur, dari 3 bulan hingga ± beberapa), kami memuat turun sepasang "kek" baru, dan kami menyulitkan semula data. Kami mempunyai perkhidmatan berasingan yang merobek semua data dan menyulitkannya dengan cara baharu; Data disimpan di sebelah pengecam kunci yang digunakan untuk menyulitkan. Sehubungan itu, sebaik sahaja kami menyulitkan data dengan kunci baharu, kami memadamkan kunci lama.

  Kadangkala pembayaran perlu dibuat secara manual...

  V: – Iaitu, jika bayaran balik telah tiba untuk beberapa operasi, adakah anda masih akan menyahsulitnya dengan kunci lama?

  EK: - Ya.

  V: – Kemudian satu lagi soalan kecil. Apabila beberapa jenis kegagalan, kejatuhan atau insiden berlaku, adalah perlu untuk meneruskan transaksi secara manual. Terdapat keadaan sedemikian.

  EK: - Ya kadangkala.

  V: – Dari manakah anda mendapatkan data ini? Atau adakah anda pergi ke kemudahan penyimpanan ini sendiri?

  EK: – Tidak, sudah tentu, kami mempunyai beberapa jenis sistem pejabat belakang yang mengandungi antara muka untuk sokongan kami. Jika kami tidak tahu status transaksi tersebut (contohnya, sehingga sistem pembayaran bertindak balas dengan tamat masa), kami tidak tahu apriori, iaitu kami menetapkan status akhir hanya dengan penuh keyakinan. Dalam kes ini, kami menetapkan urus niaga kepada status khas untuk pemprosesan manual. Pada waktu pagi, keesokan harinya, sebaik sahaja sokongan menerima maklumat bahawa transaksi sedemikian dan sedemikian kekal dalam sistem pembayaran, mereka memprosesnya secara manual dalam antara muka ini.

  
  
  V: - Saya mempunyai beberapa soalan. Salah satunya ialah penerusan zon PCI DSS: bagaimana anda log litar mereka? Soalan ini adalah kerana pembangun boleh meletakkan apa sahaja dalam log! Soalan kedua: bagaimana anda melancarkan perbaikan terbaru? Menggunakan pemegang dalam pangkalan data adalah satu pilihan, tetapi mungkin terdapat hot-fix percuma - apakah prosedur di sana? Dan soalan ketiga mungkin berkaitan dengan RTO, RPO. Ketersediaan anda ialah 99,97, hampir empat sembilan, tetapi seperti yang saya faham, anda mempunyai pusat data kedua, pusat data ketiga dan pusat data kelima... Bagaimanakah anda menyegerakkannya, menirunya dan segala-galanya?

  EK: - Mari kita mulakan dengan yang pertama. Adakah soalan pertama tentang log? Apabila kami menulis log, kami mempunyai lapisan yang menutup semua data sensitif. Dia melihat topeng dan medan tambahan. Sehubungan itu, log kami keluar dengan data yang telah bertopeng dan litar PCI DSS. Ini adalah salah satu tugas biasa yang diberikan kepada jabatan ujian. Mereka dikehendaki menyemak setiap tugas, termasuk log yang mereka tulis, dan ini adalah salah satu tugas biasa semasa semakan kod, untuk mengawal bahawa pembangun tidak menulis sesuatu. Pemeriksaan seterusnya mengenai perkara ini dilakukan secara berkala oleh jabatan keselamatan maklumat kira-kira sekali seminggu: log untuk hari terakhir diambil secara selektif dan ia dijalankan melalui penganalisis pengimbas khas dari pelayan ujian untuk menyemak segala-galanya.
  Mengenai pembaikan panas. Ini termasuk dalam peraturan penempatan kami. Kami mempunyai klausa yang berasingan tentang perbaikan terbaru. Kami percaya bahawa kami menggunakan pembaikan terkini sepanjang masa apabila kami memerlukannya. Sebaik sahaja versi dipasang, sebaik sahaja ia dijalankan, sebaik sahaja kami mempunyai artifak, kami mempunyai pentadbir sistem yang bertugas atas panggilan daripada sokongan, dan dia menggunakan ia pada masa yang diperlukan.

  Kira-kira "empat sembilan". Angka yang kami miliki sekarang telah benar-benar dicapai, dan kami berusaha untuk mendapatkannya di pusat data yang lain. Kini kami mempunyai pusat data kedua, dan kami mula membuat laluan di antara mereka, dan isu replikasi pusat data merentas adalah persoalan yang tidak remeh. Kami cuba menyelesaikannya pada satu masa menggunakan cara yang berbeza: kami cuba menggunakan "Tarantula" yang sama - ia tidak berjaya untuk kami, saya akan memberitahu anda dengan segera. Itulah sebabnya kami akhirnya memesan "sens" secara manual. Malah, setiap aplikasi dalam sistem kami menjalankan penyegerakan "perubahan - selesai" yang diperlukan antara pusat data secara tidak segerak.

  V: – Jika anda mendapat yang kedua, mengapa anda tidak mendapat yang ketiga? Kerana belum ada sesiapa yang mempunyai otak berpecah...

  EK: – Tetapi kami tidak mempunyai Split Brain. Disebabkan fakta bahawa setiap aplikasi didorong oleh multimaster, tidak kira kami pusat mana permintaan itu datang. Kami bersedia untuk fakta bahawa jika salah satu pusat data kami gagal (kami bergantung pada ini) dan di tengah-tengah permintaan pengguna beralih ke pusat data kedua, kami sudah bersedia untuk kehilangan pengguna ini, sesungguhnya; tetapi ini akan menjadi unit, unit mutlak.

  V: - Selamat petang. Terima kasih atas laporan itu. Anda bercakap tentang penyahpepijat anda, yang menjalankan beberapa transaksi ujian dalam pengeluaran. Tetapi beritahu kami tentang transaksi ujian! Sejauh mana ia pergi?

  EK: – Ia melalui kitaran penuh keseluruhan komponen. Untuk komponen, tiada perbezaan antara transaksi ujian dan transaksi pengeluaran. Tetapi dari sudut pandangan logik, ini hanyalah projek berasingan dalam sistem, di mana hanya transaksi ujian dijalankan.

  V: -Di manakah anda memotongnya? Di sini Core menghantar...

  EK: – Kami berada di belakang “Kor” dalam kes ini untuk urus niaga ujian... Kami mempunyai perkara seperti penghalaan: “Kor” mengetahui sistem pembayaran mana yang hendak dihantar - kami menghantar ke sistem pembayaran palsu, yang hanya memberikan isyarat http dan itu sahaja.

  V: – Tolong beritahu saya, adakah aplikasi anda ditulis dalam satu monolit besar, atau adakah anda memotongnya kepada beberapa perkhidmatan atau perkhidmatan mikro?

  EK: – Kami tidak mempunyai monolit, sudah tentu, kami mempunyai aplikasi berorientasikan perkhidmatan. Kami bergurau bahawa perkhidmatan kami diperbuat daripada monolit - ia benar-benar agak besar. Sukar untuk memanggilnya perkhidmatan mikro, tetapi ini adalah perkhidmatan di mana pekerja mesin teragih beroperasi.

  Jika perkhidmatan pada pelayan terjejas...

  V: - Kemudian saya mempunyai soalan seterusnya. Walaupun ia adalah monolit, anda masih mengatakan bahawa anda mempunyai banyak pelayan segera ini, semuanya pada asasnya memproses data, dan persoalannya ialah: "Sekiranya berlaku kompromi salah satu pelayan segera atau aplikasi, mana-mana pautan individu , adakah mereka mempunyai sejenis kawalan akses? Yang mana antara mereka boleh buat apa? Siapa yang harus saya hubungi untuk maklumat apa?

  
  
  EK: - Ya sememangnya. Keperluan keselamatan agak serius. Pertama, kami mempunyai pergerakan data terbuka, dan pelabuhan hanyalah yang melaluinya kami menjangka pergerakan trafik lebih awal. Jika komponen berkomunikasi dengan pangkalan data (katakan, dengan Muskul) melalui 5-4-3-2, hanya 5-4-3-2 akan dibuka kepadanya dan port lain serta arah trafik lain tidak akan tersedia. Di samping itu, anda perlu memahami bahawa dalam pengeluaran kami terdapat kira-kira 10 gelung keselamatan yang berbeza. Dan walaupun aplikasi itu entah bagaimana dikompromi, Allah melarang, penyerang tidak akan dapat mengakses konsol pengurusan pelayan, kerana ini adalah zon keselamatan rangkaian yang berbeza.

  V: – Dan dalam konteks ini, apa yang lebih menarik bagi saya ialah anda mempunyai kontrak tertentu dengan perkhidmatan - perkara yang boleh mereka lakukan, melalui "tindakan" apa yang mereka boleh menghubungi satu sama lain... Dan dalam aliran biasa, beberapa perkhidmatan tertentu meminta beberapa baris, senarai "tindakan" di sebelah yang lain. Mereka nampaknya tidak beralih kepada orang lain dalam situasi biasa, dan mereka mempunyai bidang tanggungjawab lain. Jika salah seorang daripada mereka dikompromi, adakah ia boleh mengganggu "tindakan" perkhidmatan itu?..

  EK: - Saya faham. Jika dalam keadaan biasa dengan komunikasi pelayan lain dibenarkan sama sekali, maka ya. Menurut kontrak SLA, kami tidak memantau bahawa anda hanya dibenarkan 3 "tindakan" pertama dan anda tidak dibenarkan 4 "tindakan". Ini mungkin berlebihan untuk kami, kerana kami sudah mempunyai sistem perlindungan 4 peringkat, pada dasarnya, untuk litar. Kami lebih suka mempertahankan diri dengan kontur, dan bukannya pada tahap bahagian dalam.

  Bagaimana Visa, MasterCard dan Sberbank berfungsi

  V: – Saya ingin menjelaskan satu perkara tentang menukar pengguna dari satu pusat data ke pusat data yang lain. Setahu saya, Visa dan MasterCard beroperasi menggunakan protokol segerak binari 8583, dan terdapat campuran di sana. Dan saya ingin tahu, sekarang yang kami maksudkan adalah menukar - adakah ia terus "Visa" dan "MasterCard" atau sebelum sistem pembayaran, sebelum diproses?

  EK: - Ini sebelum adunan. Campuran kami terletak di pusat data yang sama.

  V: – Secara kasarnya, adakah anda mempunyai satu titik sambungan?

  EK: – “Visa” dan “MasterCard” - ya. Semata-mata kerana Visa dan MasterCard memerlukan pelaburan yang agak serius dalam infrastruktur untuk memuktamadkan kontrak berasingan untuk mendapatkan pasangan campuran kedua, sebagai contoh. Mereka dikhaskan dalam satu pusat data, tetapi jika, Allah melarang, pusat data kami, di mana terdapat campuran untuk menyambung ke Visa dan MasterCard, mati, maka kami akan mempunyai sambungan dengan Visa dan MasterCard hilang...

  V: – Bagaimanakah mereka boleh ditempah? Saya tahu bahawa Visa membenarkan hanya satu sambungan pada dasarnya!

  EK: – Mereka membekalkan peralatan itu sendiri. Walau apa pun, kami menerima peralatan yang berlebihan sepenuhnya di dalamnya.

  V: – Jadi pendirian adalah dari Connects Orange mereka?..

  EK: - Ya.

  V: – Tetapi bagaimana pula dengan kes ini: jika pusat data anda hilang, bagaimana anda boleh terus menggunakannya? Atau adakah lalu lintas berhenti?

  EK: - Tidak. Dalam kes ini, kami hanya akan menukar trafik ke saluran lain, yang, secara semula jadi, akan lebih mahal untuk kami dan lebih mahal untuk pelanggan kami. Tetapi lalu lintas tidak akan melalui sambungan terus kami ke Visa, MasterCard, tetapi melalui Sberbank bersyarat (sangat dibesar-besarkan).

  Saya memohon maaf secara liar jika saya menyinggung perasaan pekerja Sberbank. Tetapi menurut statistik kami, di kalangan bank Rusia, Sberbank paling kerap jatuh. Tidak sebulan berlalu tanpa sesuatu yang jatuh di Sberbank.

  
  
  

  Beberapa iklan 🙂

  Terima kasih kerana tinggal bersama kami. Adakah anda suka artikel kami? Ingin melihat kandungan yang lebih menarik? Sokong kami dengan membuat pesanan atau mengesyorkan kepada rakan, cloud VPS untuk pembangun dari $4.99, analog unik pelayan peringkat permulaan, yang kami cipta untuk anda: Keseluruhan kebenaran tentang VPS (KVM) E5-2697 v3 (6 Teras) 10GB DDR4 480GB SSD 1Gbps daripada $19 atau bagaimana untuk berkongsi pelayan? (tersedia dengan RAID1 dan RAID10, sehingga 24 teras dan sehingga 40GB DDR4).

  Dell R730xd 2 kali lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya disini 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV daripada $199 di Belanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - daripada $99! Baca tentang Bagaimana untuk membina infrastruktur corp. kelas dengan penggunaan pelayan Dell R730xd E5-2650 v4 bernilai 9000 euro untuk satu sen?

Sumber: www.habr.com