Semua orang berbicara tentang proses pengembangan dan pengujian, pelatihan staf, peningkatan motivasi, namun proses ini tidak cukup ketika satu menit penghentian layanan menghabiskan banyak uang. Apa yang harus dilakukan saat Anda melakukan transaksi keuangan berdasarkan SLA yang ketat? Bagaimana cara meningkatkan keandalan dan toleransi kesalahan sistem Anda, dengan tidak memperhitungkan pengembangan dan pengujian?
Konferensi HighLoad++ berikutnya akan diadakan pada tanggal 6 dan 7 April 2020 di St. Detail dan tiket untuk . 9 November 18:00. HighLoad++ Moskow 2018, aula Delhi + Kolkata. Tesis dan .
Evgeniy Kuzovlev (selanjutnya – EC): - Teman, halo! Nama saya Kuzovlev Evgeniy. Saya dari perusahaan EcommPay, divisi spesifiknya adalah EcommPay IT, divisi IT dari grup perusahaan. Dan hari ini kita akan berbicara tentang downtime - cara menghindarinya, cara meminimalkan konsekuensinya jika tidak dapat dihindari. Topiknya dinyatakan sebagai berikut: “Apa yang harus dilakukan ketika waktu henti satu menit menghabiskan biaya $100”? Ke depan, jumlah kita sebanding.
Apa yang dilakukan IT EcommPay?
Siapa kita? Mengapa saya berdiri di sini di depan Anda? Mengapa saya berhak memberi tahu Anda sesuatu di sini? Dan apa yang akan kita bicarakan lebih detail di sini?
Grup perusahaan EcommPay adalah pengakuisisi internasional. Kami memproses pembayaran di seluruh dunia - di Rusia, Eropa, Asia Tenggara (Di Seluruh Dunia). Kami memiliki 9 kantor, total 500 karyawan, dan kurang dari setengahnya adalah spesialis IT. Semua yang kami lakukan, semua yang menghasilkan uang, kami lakukan sendiri.
Kami menulis semua produk kami (dan kami memiliki cukup banyak produk - di lini produk TI besar kami, kami memiliki sekitar 16 komponen berbeda) sendiri; Kami menulis diri kami sendiri, kami mengembangkan diri kami sendiri. Dan saat ini kami melakukan sekitar satu juta transaksi setiap hari (jutaan mungkin adalah kata yang tepat untuk mengatakannya). Kami adalah perusahaan yang cukup muda - kami baru berusia sekitar enam tahun.
6 tahun yang lalu itu adalah sebuah startup ketika orang-orang datang dengan bisnisnya. Mereka disatukan oleh sebuah ide (tidak ada yang lain selain sebuah ide), dan kami berlari. Seperti startup lainnya, kami berlari lebih cepat... Bagi kami, kecepatan lebih penting daripada kualitas.
Pada titik tertentu kami berhenti: kami menyadari bahwa kami tidak dapat lagi hidup dengan kecepatan dan kualitas seperti itu dan kami perlu fokus pada kualitas terlebih dahulu. Saat ini, kami memutuskan untuk menulis platform baru yang benar, terukur, dan andal. Mereka mulai menulis platform ini (mereka mulai berinvestasi, mengembangkan pengembangan, pengujian), tetapi pada titik tertentu mereka menyadari bahwa pengembangan dan pengujian tidak memungkinkan kami mencapai tingkat kualitas layanan yang baru.
Anda membuat produk baru, memasukkannya ke dalam produksi, tetapi masih ada yang tidak beres. Dan hari ini kita akan berbicara tentang bagaimana mencapai tingkat kualitas baru (bagaimana kami melakukannya, tentang pengalaman kami), dengan mengesampingkan pengembangan dan pengujian; kita akan berbicara tentang apa yang tersedia untuk operasi - operasi apa yang dapat dilakukan sendiri, apa yang dapat ditawarkan untuk pengujian guna mempengaruhi kualitas.
Waktu henti. Perintah operasi.
Selalu menjadi landasan utama, yang sebenarnya akan kita bicarakan hari ini adalah downtime. Sebuah kata yang buruk. Jika kita mempunyai waktu senggang, semuanya buruk bagi kita. Kami berlari untuk menaikkannya, admin memegang server - insya Allah tidak jatuh, seperti yang mereka katakan di lagu itu. Inilah yang akan kita bicarakan hari ini.
Ketika kami mulai mengubah pendekatan kami, kami membentuk 4 perintah. Saya telah menyajikannya di slide:
Perintah-perintah ini cukup sederhana:
- Identifikasi masalahnya dengan cepat.
- Singkirkan itu lebih cepat.
- Membantu memahami alasannya (nanti, untuk pengembang).
- Dan standarisasi pendekatan.
Saya ingin menarik perhatian Anda pada poin No. 2. Kita sedang menyingkirkan masalah, bukan menyelesaikannya. Memutuskan adalah hal kedua. Bagi kami, hal utama adalah pengguna terlindungi dari masalah ini. Ia akan ada di suatu lingkungan yang terisolasi, tetapi lingkungan ini tidak akan bersentuhan dengannya. Sebenarnya, kita akan membahas empat kelompok masalah ini (sebagian lebih terinci, sebagian kurang terinci), saya akan memberi tahu Anda apa yang kami gunakan, pengalaman relevan apa yang kami miliki dalam solusinya.
Pemecahan masalah: Kapan hal tersebut terjadi dan apa yang harus dilakukan untuk mengatasinya?
Tapi kita akan mulai secara berurutan, kita akan mulai dengan poin No. 2 - bagaimana cara cepat menghilangkan masalah? Ada masalah - kita harus memperbaikinya. “Apa yang harus kita lakukan mengenai hal ini?” - pertanyaan utama. Dan ketika kami mulai memikirkan cara memperbaiki masalah, kami mengembangkan sendiri beberapa persyaratan yang harus diikuti oleh pemecahan masalah.
Untuk merumuskan persyaratan ini, kami memutuskan untuk bertanya pada diri sendiri: “Kapan kami memiliki masalah”? Dan ternyata, masalah terjadi dalam empat kasus:
- Kegagalan perangkat keras.
- Layanan eksternal gagal.
- Mengubah versi perangkat lunak (penyebaran yang sama).
- Pertumbuhan beban eksplosif.
Kami tidak akan membicarakan dua yang pertama. Kerusakan perangkat keras dapat diatasi dengan cukup sederhana: Anda harus menggandakan semuanya. Jika ini adalah disk, disk tersebut harus dirakit dalam RAID; jika ini adalah server, server harus diduplikasi; jika Anda memiliki infrastruktur jaringan, Anda harus menyediakan salinan kedua dari infrastruktur jaringan, yaitu, Anda mengambilnya dan menggandakannya. Dan jika terjadi kegagalan, Anda beralih ke daya cadangan. Sulit untuk mengatakan apa pun lagi di sini.
Yang kedua adalah kegagalan layanan eksternal. Bagi kebanyakan orang, sistem ini tidak menjadi masalah sama sekali, tapi tidak bagi kami. Karena kami memproses pembayaran, kami adalah agregator yang berdiri antara pengguna (yang memasukkan data kartunya) dan bank, sistem pembayaran (Visa, MasterCard, Mira, dll.). Layanan eksternal kami (sistem pembayaran, bank) cenderung gagal. Baik kami maupun Anda (jika Anda memiliki layanan tersebut) tidak dapat mempengaruhi hal ini.
Lalu apa yang harus dilakukan? Ada dua pilihan di sini. Pertama, jika bisa, Anda harus menduplikasi layanan ini dengan cara tertentu. Misalnya, jika memungkinkan, kami mentransfer lalu lintas dari satu layanan ke layanan lainnya: misalnya, kartu diproses melalui Sberbank, Bank Tabungan mengalami masalah - kami mentransfer lalu lintas [secara kondisional] ke Raiffeisen. Hal kedua yang dapat kita lakukan adalah menyadari kegagalan layanan eksternal dengan sangat cepat, oleh karena itu kita akan membicarakan kecepatan respons di bagian laporan selanjutnya.
Faktanya, dari keempat hal ini, kita dapat secara khusus mempengaruhi perubahan versi perangkat lunak - mengambil tindakan yang akan mengarah pada perbaikan situasi dalam konteks penerapan dan dalam konteks pertumbuhan beban yang eksplosif. Sebenarnya, itulah yang kami lakukan. Di sini, sekali lagi, sebuah catatan kecil...
Dari empat masalah ini, beberapa dapat diselesaikan dengan segera jika Anda memiliki cloud. Jika Anda menggunakan Microsoft Azhur, awan Ozon, atau menggunakan awan kami, dari Yandex atau Mail, maka setidaknya kerusakan perangkat keras menjadi masalah mereka dan semuanya segera menjadi baik-baik saja bagi Anda dalam konteks kerusakan perangkat keras.
Kami adalah perusahaan yang sedikit tidak konvensional. Di sini semua orang berbicara tentang “Kubernets”, tentang awan - kami tidak memiliki “Kubernets” maupun awan. Namun kami memiliki rak perangkat keras di banyak pusat data, dan kami terpaksa hidup dengan perangkat keras ini, kami terpaksa bertanggung jawab atas semuanya. Oleh karena itu, kita akan berbicara dalam konteks ini. Jadi, tentang masalahnya. Dua yang pertama dikeluarkan dari tanda kurung.
Mengubah versi perangkat lunak. Pangkalan
Pengembang kami tidak memiliki akses ke produksi. Mengapa demikian? Hanya saja kami bersertifikat PCI DSS, dan pengembang kami tidak memiliki hak untuk masuk ke “produk” tersebut. Itu saja, titik. Sama sekali. Oleh karena itu, tanggung jawab pengembangan berakhir tepat pada saat pengembangan menyerahkan build untuk dirilis.
Landasan kedua yang kami miliki, yang juga banyak membantu kami, adalah tidak adanya pengetahuan unik yang tidak terdokumentasi. Saya harap itu sama untuk Anda. Karena jika tidak, Anda akan mendapat masalah. Masalah akan muncul ketika pengetahuan unik dan tidak terdokumentasi ini tidak hadir pada waktu dan tempat yang tepat. Katakanlah Anda memiliki satu orang yang tahu cara menerapkan komponen tertentu - orang tersebut tidak ada di sana, dia sedang berlibur atau sakit - itu saja, Anda mengalami masalah.
Dan landasan ketiga yang telah kita capai. Kami mencapainya melalui rasa sakit, darah, air mata - kami sampai pada kesimpulan bahwa setiap bangunan kami mengandung kesalahan, meskipun bebas dari kesalahan. Kami memutuskan ini sendiri: saat kami menerapkan sesuatu, saat kami memasukkan sesuatu ke dalam produksi, kami memiliki build yang error. Kami telah membentuk persyaratan yang harus dipenuhi oleh sistem kami.
Persyaratan untuk mengubah versi perangkat lunak
Ada tiga persyaratan:
- Kita harus segera membatalkan penerapannya.
- Kita harus meminimalkan dampak penerapan yang gagal.
- Dan kita harus bisa dengan cepat menerapkannya secara paralel.
Tepat dalam urutan itu! Mengapa? Karena, pertama-tama, saat menerapkan versi baru, kecepatan tidaklah penting, namun penting bagi Anda, jika terjadi kesalahan, untuk segera melakukan rollback dan berdampak minimal. Tetapi jika Anda memiliki serangkaian versi dalam produksi, yang ternyata ada kesalahan (tiba-tiba, tidak ada penerapan, tetapi ada kesalahan) - kecepatan penerapan selanjutnya penting bagi Anda. Apa yang telah kita lakukan untuk memenuhi tuntutan ini? Kami menggunakan metodologi berikut:
Ini cukup terkenal, kami belum pernah menemukannya - ini adalah penerapan Biru/Hijau. Apa itu? Anda harus memiliki salinan untuk setiap grup server tempat aplikasi Anda diinstal. Salinannya "hangat": tidak ada lalu lintas di dalamnya, tetapi kapan saja lalu lintas ini dapat dikirim ke salinan ini. Salinan ini berisi versi sebelumnya. Dan pada saat penerapan, Anda meluncurkan kode ke salinan yang tidak aktif. Kemudian Anda mengalihkan sebagian lalu lintas (atau seluruhnya) ke versi baru. Jadi, untuk mengubah arus lalu lintas dari versi lama ke versi baru, Anda hanya perlu melakukan satu tindakan: Anda perlu mengubah penyeimbang di hulu, mengubah arah - dari satu hulu ke hulu lainnya. Ini sangat nyaman dan memecahkan masalah peralihan cepat dan rollback cepat.Di sini solusi untuk pertanyaan kedua adalah minimalisasi: Anda hanya dapat mengirim sebagian lalu lintas Anda ke baris baru, ke baris dengan kode baru (misalnya, 2%). Dan 2% ini tidak 100%! Jika Anda kehilangan 100% lalu lintas karena penerapan yang gagal, itu menakutkan; jika Anda kehilangan 2% lalu lintas, itu tidak menyenangkan, tetapi tidak menakutkan. Selain itu, pengguna kemungkinan besar tidak akan menyadarinya, karena dalam beberapa kasus (tidak semua) pengguna yang sama, dengan menekan F5, akan dibawa ke versi lain yang berfungsi.
Penyebaran Biru/Hijau. Rute
Namun, tidak semuanya sesederhana itu “Penyebaran Biru/Hijau”... Semua komponen kami dapat dibagi menjadi tiga kelompok:
- ini adalah frontend (halaman pembayaran yang dilihat klien kami);
- inti pemrosesan;
- adaptor untuk bekerja dengan sistem pembayaran (bank, MasterCard, Visa...).
Dan ada nuansa di sini - nuansanya terletak pada rute yang tersirat. Jika Anda hanya mengalihkan 100% lalu lintas, Anda tidak akan mengalami masalah ini. Namun jika Anda ingin beralih 2%, Anda mulai mengajukan pertanyaan: “Bagaimana cara melakukannya?” Hal yang paling sederhana adalah langsung saja: Anda dapat mengatur Round Robin di nginx dengan pilihan acak, dan Anda memiliki 2% ke kiri, 98% ke kanan. Tapi ini tidak selalu cocok.
Misalnya, dalam kasus kami, pengguna berinteraksi dengan sistem dengan lebih dari satu permintaan. Ini normal: 2, 3, 4, 5 permintaan - sistem Anda mungkin sama. Dan jika penting bagi Anda bahwa semua permintaan pengguna datang ke baris yang sama dengan permintaan pertama, atau (poin kedua) semua permintaan pengguna datang ke baris baru setelah peralihan (dia bisa mulai bekerja lebih awal dengan sistem, sebelum peralihan), - maka distribusi acak ini tidak cocok untuk Anda. Lalu ada opsi berikut:
Opsi pertama, yang paling sederhana, didasarkan pada parameter dasar klien (IP Hash). Anda memiliki IP, dan Anda membaginya dari kanan ke kiri berdasarkan alamat IP. Maka kasus kedua yang saya jelaskan akan bekerja untuk Anda, ketika penerapan terjadi, pengguna sudah dapat mulai bekerja dengan sistem Anda, dan sejak penerapan semua permintaan akan masuk ke baris baru (misalnya, ke baris yang sama).Jika karena alasan tertentu hal ini tidak cocok untuk Anda dan Anda harus mengirim permintaan ke baris tempat permintaan awal pengguna datang, maka Anda memiliki dua opsi...
Opsi pertama: Anda dapat membeli nginx+ berbayar. Ada mekanisme sesi Sticky, yang, berdasarkan permintaan awal pengguna, menetapkan sesi kepada pengguna dan mengikatnya ke satu atau beberapa upstream. Semua permintaan pengguna berikutnya dalam masa sesi akan dikirim ke upstream yang sama tempat sesi diposting.Ini tidak cocok untuk kami karena kami sudah memiliki nginx reguler. Beralih ke nginx+ bukan berarti mahal, hanya saja agak menyakitkan bagi kami dan kurang tepat. “Sticks Sessions”, misalnya, tidak berfungsi untuk kami karena alasan sederhana bahwa “Sticks Sessions” tidak mengizinkan perutean berdasarkan “Salah satu atau”. Di sana Anda dapat menentukan apa yang kami lakukan dengan “Sticks Sessions”, misalnya, berdasarkan alamat IP atau berdasarkan alamat IP dan cookie atau berdasarkan parameter pasca, tetapi “Salah satu atau” lebih rumit di sana.
Oleh karena itu, kami sampai pada opsi keempat. Kami menggunakan nginx dengan steroid (ini openresty) - ini adalah nginx yang sama, yang juga mendukung penyertaan skrip terbaru. Anda dapat menulis skrip terakhir, memberinya “istirahat terbuka”, dan skrip terakhir ini akan dieksekusi ketika permintaan pengguna datang.
Dan kami sebenarnya menulis skrip seperti itu, mengatur diri kami sendiri sebagai "openresti" dan dalam skrip ini kami mengurutkan 6 parameter berbeda dengan rangkaian "Atau". Bergantung pada keberadaan parameter tertentu, kita mengetahui bahwa pengguna telah datang ke halaman tertentu, baris tertentu.
Penyebaran Biru/Hijau. Keuntungan dan kerugian
Tentu saja, mungkin bisa membuatnya sedikit lebih sederhana (gunakan "Sesi Lengket" yang sama), tetapi kami juga memiliki nuansa sehingga tidak hanya pengguna yang berinteraksi dengan kami dalam kerangka satu pemrosesan satu transaksi... Namun sistem pembayaran juga berinteraksi dengan kami: Setelah kami memproses transaksi (dengan mengirimkan permintaan ke sistem pembayaran), kami menerima coolback.
Dan katakanlah, jika di dalam sirkuit kita, kita dapat meneruskan alamat IP pengguna di semua permintaan dan membagi pengguna berdasarkan alamat IP, maka kita tidak akan memberi tahu “Visa” yang sama: “Bung, kami adalah perusahaan retro, sepertinya kami menjadi internasional (di situs web dan di Rusia)... Harap berikan kami alamat IP pengguna di bidang tambahan, protokol Anda terstandarisasi”! Jelas mereka tidak akan setuju.
Oleh karena itu, ini tidak berhasil untuk kami - kami melakukan openresty. Oleh karena itu, dengan perutean kami mendapatkan sesuatu seperti ini:Penerapan Biru/Hijau memiliki kelebihan dan kekurangan yang saya sebutkan.
Dua kelemahan:
- Anda perlu repot dengan perutean;
- kelemahan utama kedua adalah biayanya.
Anda memerlukan server dua kali lebih banyak, Anda memerlukan sumber daya operasional dua kali lebih banyak, Anda perlu mengeluarkan upaya dua kali lebih banyak untuk memelihara seluruh kebun binatang ini.
Omong-omong, di antara kelebihannya ada satu hal lagi yang belum saya sebutkan sebelumnya: Anda memiliki cadangan jika terjadi peningkatan beban. Jika Anda memiliki pertumbuhan beban yang eksplosif, Anda memiliki banyak pengguna, maka Anda cukup memasukkan baris kedua dalam distribusi 50 hingga 50 - dan Anda segera memiliki server x2 di cluster Anda hingga Anda menyelesaikan masalah memiliki lebih banyak server.
Bagaimana cara melakukan penerapan cepat?
Kami berbicara tentang cara mengatasi masalah minimalisasi dan rollback cepat, namun pertanyaannya tetap: “Bagaimana cara menerapkan dengan cepat?”
Di sini singkat dan sederhana.- Anda harus memiliki sistem CD (Pengiriman Berkelanjutan) - Anda tidak dapat hidup tanpanya. Jika Anda memiliki satu server, Anda dapat menerapkannya secara manual. Kami memiliki sekitar satu setengah ribu server dan satu setengah ribu pegangan, tentu saja - kami dapat membuat departemen sebesar ruangan ini hanya untuk ditempatkan.
- Penempatan harus paralel. Jika penerapan Anda berurutan, semuanya buruk. Satu server itu normal, Anda akan mengerahkan satu setengah ribu server sepanjang hari.
- Sekali lagi, untuk akselerasi, hal ini mungkin tidak diperlukan lagi. Selama penerapan, proyek biasanya dibangun. Anda memiliki proyek web, ada bagian front-end (Anda membuat paket web di sana, Anda mengkompilasi npm - sesuatu seperti itu), dan proses ini, pada prinsipnya, berumur pendek - 5 menit, tetapi 5 menit ini bisa bersikap kritis. Itu sebabnya, misalnya, kami tidak melakukan itu: kami menghapus 5 menit ini, kami menyebarkan artefak.
Apa itu artefak? Artefak adalah suatu bangunan rakitan yang semua bagian perakitannya telah selesai. Kami menyimpan artefak ini di penyimpanan artefak. Pada suatu waktu kami menggunakan dua penyimpanan seperti itu - Nexus dan sekarang jFrog Artifactory). Awalnya kami menggunakan "Nexus" karena kami mulai mempraktikkan pendekatan ini dalam aplikasi java (sangat cocok). Kemudian mereka menaruh beberapa aplikasi yang ditulis dalam PHP di sana; dan “Nexus” sudah tidak cocok lagi, oleh karena itu kami memilih jFrog Artefactory, yang dapat mengartikulasikan hampir semua hal. Kami bahkan sampai pada titik bahwa dalam repositori artefak ini kami menyimpan paket biner kami sendiri yang kami kumpulkan untuk server.
Pertumbuhan beban eksplosif
Kami berbicara tentang mengubah versi perangkat lunak. Hal berikutnya yang kita alami adalah peningkatan beban secara eksplosif. Di sini, yang saya maksud mungkin dengan pertumbuhan beban yang eksplosif bukanlah hal yang tepat...
Kami menulis sistem baru - berorientasi pada layanan, modis, cantik, pekerja di mana-mana, antrian di mana-mana, asinkron di mana-mana. Dan dalam sistem seperti itu, data dapat mengalir melalui aliran yang berbeda. Untuk transaksi pertama, pekerja ke-1, ke-3, ke-10 dapat digunakan, untuk transaksi kedua - pekerja ke-2, ke-4, ke-5. Dan hari ini, katakanlah, di pagi hari Anda memiliki aliran data yang menggunakan tiga pekerja pertama, dan di malam hari aliran data berubah secara dramatis, dan semuanya menggunakan tiga pekerja lainnya.
Dan di sini ternyata Anda perlu menskalakan pekerja, Anda perlu menskalakan layanan Anda, tetapi pada saat yang sama mencegah pembengkakan sumber daya.
Kami telah menetapkan persyaratan kami. Persyaratan ini cukup sederhana: adanya penemuan Layanan, parameterisasi - semuanya standar untuk membangun sistem yang dapat diskalakan, kecuali satu hal - penyusutan sumber daya. Kami mengatakan bahwa kami belum siap untuk mengamortisasi sumber daya agar server memanaskan udara. Kami mengambil "Konsul", kami mengambil "Nomad", yang mengelola pekerja kami.Mengapa ini menjadi masalah bagi kami? Mari kita mundur sedikit. Kami sekarang memiliki sekitar 70 sistem pembayaran di belakang kami. Di pagi hari, lalu lintas melewati Bank Tabungan, lalu Bank Tabungan turun, misalnya, dan kami mengalihkannya ke sistem pembayaran lain. Kami memiliki 100 pekerja sebelum Bank Tabungan, dan setelah itu kami perlu meningkatkan 100 pekerja secara tajam untuk sistem pembayaran lain. Dan diharapkan semua ini terjadi tanpa campur tangan manusia. Karena jika ada partisipasi manusia, seharusnya ada seorang insinyur yang duduk di sana 24/7, yang seharusnya hanya melakukan hal ini, karena kegagalan seperti itu, ketika 70 sistem berada di belakang Anda, sering terjadi.
Oleh karena itu, kami melihat Nomad, yang memiliki IP terbuka, dan menulis hal kami sendiri, Scale-Nomad - ScaleNo, yang melakukan hal berikut: memantau pertumbuhan antrian dan mengurangi atau menambah jumlah pekerja tergantung pada dinamika dari antrian. Saat kami melakukannya, kami berpikir: “Mungkin kami bisa menjadikannya open source?” Kemudian mereka memandangnya - dia sesederhana dua kopek.
Sejauh ini kami belum membukanya secara open source, tetapi jika tiba-tiba setelah laporan, setelah menyadari bahwa Anda memerlukan hal seperti itu, Anda memerlukannya, kontak saya ada di slide terakhir - silakan tulis kepada saya. Kalau minimal 3-5 orang akan kami sponsori.
Bagaimana itu bekerja? Mari kita lihat! Ke depan: di sebelah kiri ada bagian pemantauan kami: ini satu baris, di atas adalah waktu pemrosesan acara, di tengah adalah jumlah transaksi, di bawah adalah jumlah pekerja.Jika diperhatikan, ada kesalahan pada gambar ini. Di grafik teratas, salah satu grafik mogok dalam 45 detik - salah satu sistem pembayaran mati. Lalu lintas segera dibawa masuk dalam 2 menit dan antrian mulai bertambah di sistem pembayaran lain, di mana tidak ada pekerja (kami tidak menggunakan sumber daya - sebaliknya, kami membuang sumber daya dengan benar). Kami tidak mau kepanasan - jumlah pekerjanya minimal, sekitar 5-10 pekerja, tapi mereka tidak bisa mengatasinya.
Grafik terakhir menunjukkan “punuk”, yang berarti “Skaleno” menggandakan jumlah ini. Dan kemudian, ketika grafiknya turun sedikit, dia menguranginya sedikit - jumlah pekerja berubah secara otomatis. Begitulah cara kerjanya. Kita berbicara tentang poin nomor 2 - “Cara cepat menghilangkan alasan.”
Pemantauan. Bagaimana cara cepat mengidentifikasi masalah?
Sekarang poin pertama adalah “Bagaimana cara cepat mengidentifikasi masalah?” Pemantauan! Kita harus memahami hal-hal tertentu dengan cepat. Hal apa saja yang harus kita pahami dengan cepat?
Tiga hal!- Kita harus memahami dan memahami dengan cepat kinerja sumber daya yang kita miliki.
- Kita harus segera memahami kegagalan dan memantau kinerja sistem di luar diri kita.
- Poin ketiga adalah mengidentifikasi kesalahan logis. Ini adalah saat sistem bekerja untuk Anda, semuanya normal dalam semua hal, tetapi ada yang tidak beres.
Saya mungkin tidak akan memberi tahu Anda hal keren apa pun di sini. Saya akan menjadi Kapten Jelas. Kami mencari apa yang ada di pasaran. Kami memiliki “kebun binatang yang menyenangkan”. Ini adalah jenis kebun binatang yang kami miliki sekarang:
Kami menggunakan Zabbix untuk memonitor perangkat keras, untuk memantau indikator utama server. Kami menggunakan Okmeter untuk database. Kami menggunakan “Grafana” dan “Prometheus” untuk semua indikator lain yang tidak sesuai dengan dua indikator pertama, beberapa dengan “Grafana” dan “Prometheus”, dan beberapa dengan “Grafana” dengan “Influx” dan Telegraf.Setahun yang lalu kami ingin menggunakan New Relic. Kerennya, bisa melakukan segalanya. Tapi meskipun dia bisa melakukan segalanya, dia sangat mahal. Saat kami berkembang hingga volume 1,5 ribu server, seorang vendor mendatangi kami dan berkata: “Mari kita buat kesepakatan untuk tahun depan.” Kami melihat harganya dan berkata tidak, kami tidak akan melakukan itu. Sekarang kami meninggalkan New Relic, kami memiliki sekitar 15 server tersisa di bawah pengawasan New Relic. Harganya ternyata sangat liar.
Dan ada satu alat yang kami implementasikan sendiri - ini adalah Debugger. Awalnya kami menyebutnya “Bagger,” tapi kemudian seorang guru bahasa Inggris lewat, tertawa terbahak-bahak, dan menamainya “Debagger.” Apa itu? Ini adalah alat yang, pada kenyataannya, dalam 15-30 detik pada setiap komponen, seperti “kotak hitam” sistem, menjalankan pengujian terhadap kinerja komponen secara keseluruhan.
Misalnya, jika ada halaman eksternal (halaman pembayaran), dia cukup membukanya dan melihat tampilannya. Jika ini sedang diproses, dia mengirimkan “transaksi” percobaan dan memastikan bahwa “transaksi” ini tiba. Jika ini adalah koneksi dengan sistem pembayaran, kami menjalankan permintaan pengujian yang sesuai, jika kami bisa, dan melihat bahwa semuanya baik-baik saja dengan kami.
Indikator apa yang penting untuk pemantauan?
Apa yang terutama kami pantau? Indikator apa yang penting bagi kami?
- Waktu respons/RPS di bagian depan merupakan indikator yang sangat penting. Dia segera menjawab bahwa ada sesuatu yang salah dengan Anda.
- Jumlah pesan yang diproses di semua antrean.
- Jumlah pekerja.
- Metrik kebenaran dasar.
Poin terakhir adalah metrik “bisnis”, “bisnis”. Jika Anda ingin memantau hal yang sama, Anda perlu menentukan satu atau dua metrik yang menjadi indikator utama Anda. Metrik kami adalah throughput (ini adalah rasio jumlah transaksi yang berhasil terhadap total aliran transaksi). Jika ada yang berubah dalam selang waktu 5-10-15 menit, berarti kita ada masalah (kalau berubah drastis).
Bagi kami, tampilannya adalah contoh dari salah satu papan kami:
Di sebelah kiri ada 6 grafik, sesuai dengan garis - jumlah pekerja dan jumlah pesan dalam antrian. Di sisi kanan – RPS, RTS. Di bawah ini adalah metrik “bisnis” yang sama. Dan dalam metrik “bisnis” kita dapat langsung melihat ada yang tidak beres di dua grafik tengah... Ini hanyalah sistem lain yang berdiri di belakang kita yang telah jatuh.Hal kedua yang harus kami lakukan adalah memantau jatuhnya sistem pembayaran eksternal. Di sini kami mengambil OpenTracing - sebuah mekanisme, standar, paradigma yang memungkinkan Anda melacak sistem terdistribusi; dan itu diubah sedikit. Paradigma OpenTracing standar mengatakan bahwa kami membuat pelacakan untuk setiap permintaan individual. Kami tidak membutuhkan ini, dan kami membungkusnya dalam ringkasan, jejak agregasi. Kami membuat alat yang memungkinkan kami melacak kecepatan sistem di belakang kami.
Grafik menunjukkan kepada kita bahwa salah satu sistem pembayaran mulai merespons dalam 3 detik - kami mengalami masalah. Apalagi benda ini akan bereaksi saat masalah dimulai, dengan selang waktu 20-30 detik.Dan kesalahan pemantauan kelas ketiga yang ada adalah pemantauan logis.
Sejujurnya, saya tidak tahu apa yang harus digambarkan pada slide ini, karena kami sudah lama mencari sesuatu di pasar yang cocok untuk kami. Kami tidak menemukan apa pun, jadi kami harus melakukannya sendiri.
Apa yang saya maksud dengan pemantauan logis? Bayangkan: Anda menjadikan diri Anda sebuah sistem (misalnya, tiruan Tinder); Anda berhasil, meluncurkannya. Manajer sukses Vasya Pupkin menaruhnya di ponselnya, melihat seorang gadis di sana, menyukainya... dan sejenisnya tidak diberikan kepada gadis itu - sejenisnya diberikan kepada penjaga keamanan Mikhalych dari pusat bisnis yang sama. Manajer turun ke bawah, dan kemudian bertanya-tanya: "Mengapa penjaga keamanan Mikhalych ini tersenyum begitu ramah padanya?"Dalam situasi seperti itu... Bagi kami, situasi ini terdengar sedikit berbeda, karena (saya menulis) ini adalah hilangnya reputasi yang secara tidak langsung menyebabkan kerugian finansial. Situasi kita adalah sebaliknya: kita mungkin menderita kerugian finansial langsung - misalnya, jika kita melakukan transaksi yang berhasil, namun tidak berhasil (atau sebaliknya). Saya harus menulis alat saya sendiri yang melacak jumlah transaksi yang berhasil dari waktu ke waktu menggunakan indikator bisnis. Tidak menemukan apa pun di pasaran! Inilah ide yang ingin saya sampaikan. Tidak ada produk di pasaran yang bisa mengatasi masalah seperti ini.
Ini tentang cara mengidentifikasi masalah dengan cepat.
Cara menentukan alasan penerapan
Kelompok masalah ketiga yang kita selesaikan adalah setelah kita mengidentifikasi masalahnya, setelah kita menyingkirkannya, alangkah baiknya jika kita memahami alasan pengembangan, pengujian, dan melakukan sesuatu untuk mengatasinya. Oleh karena itu, kita perlu menyelidikinya, kita perlu mengumpulkan catatan-catatan tersebut.
Jika kita berbicara tentang log (alasan utamanya adalah log), sebagian besar log kita ada di ELK Stack - hampir semua orang memiliki hal yang sama. Bagi sebagian orang, ini mungkin tidak ada di ELK, tetapi jika Anda menulis log dalam gigabyte, cepat atau lambat Anda akan sampai ke ELK. Kami menuliskannya dalam terabyte.
Ada masalah di sini. Kami memperbaikinya, memperbaiki kesalahan pengguna, mulai menggali apa yang ada di sana, naik ke Kibana, memasukkan id transaksi di sana dan mendapatkan alas kaki seperti ini (banyak pertunjukan). Dan sama sekali tidak ada yang jelas dalam alas kaki ini. Mengapa? Ya, karena tidak jelas bagian mana yang menjadi milik pekerja, bagian mana yang menjadi bagian komponen yang mana. Dan pada saat itu kami menyadari bahwa kami memerlukan penelusuran - OpenTracing yang sama yang saya bicarakan.Kami memikirkan hal ini setahun yang lalu, mengalihkan perhatian kami ke pasar, dan ada dua alat di sana - “Zipkin” dan “Jaeger”. “Jager” sebenarnya adalah pewaris ideologis, penerus ideologis “Zipkin”. Semuanya baik-baik saja di Zipkin, kecuali ia tidak tahu cara menggabungkan, tidak tahu cara memasukkan log ke dalam jejak, hanya jejak waktu. Dan “Jager” mendukung hal ini.
Kami melihat "Jager": Anda dapat menginstrumentasikan aplikasi, Anda dapat menulis dalam Api (namun, standar Api untuk PHP pada saat itu belum disetujui - ini setahun yang lalu, tetapi sekarang sudah disetujui), tetapi ada sama sekali bukan klien. “Oke,” pikir kami, dan menulis kepada klien kami sendiri. Apa yang kami dapatkan? Kurang lebih seperti ini tampilannya:
Di Jaeger, rentang dibuat untuk setiap pesan. Artinya, ketika pengguna membuka sistem, dia melihat satu atau dua blok untuk setiap permintaan masuk (1-2-3 - jumlah permintaan masuk dari pengguna, jumlah blok). Untuk memudahkan pengguna, kami menambahkan tag ke log dan jejak waktu. Oleh karena itu, jika terjadi kesalahan, aplikasi kita akan menandai log dengan tag Error yang sesuai. Anda dapat memfilter berdasarkan tag Kesalahan dan hanya rentang yang berisi blok ini dengan kesalahan yang akan ditampilkan. Ini adalah tampilannya jika kita memperluas rentangnya:
Di dalam rentang tersebut terdapat sekumpulan jejak. Dalam hal ini, ini adalah tiga jejak pengujian, dan jejak ketiga memberi tahu kita bahwa telah terjadi kesalahan. Pada saat yang sama, di sini kita melihat jejak waktu: kita memiliki skala waktu di bagian atas, dan kita melihat pada interval waktu berapa log ini atau itu dicatat.Oleh karena itu, segalanya berjalan baik bagi kami. Kami menulis ekstensi kami sendiri dan menjadikannya sumber terbuka. Jika Anda ingin bekerja dengan tracing, jika Anda ingin bekerja dengan "Jager" di PHP, ada ekstensi kami, selamat menggunakan, seperti yang mereka katakan:
Kami memiliki ekstensi ini - ini adalah klien untuk OpenTracing Api, dibuat sebagai ekstensi php, artinya, Anda perlu merakitnya dan menginstalnya di sistem. Setahun yang lalu tidak ada yang berbeda. Sekarang ada klien lain yang seperti komponen. Ini terserah Anda: apakah Anda memompa komponen dengan komposer, atau Anda menggunakan ekstensi terserah Anda.Standar perusahaan
Kami berbicara tentang tiga perintah. Perintah keempat adalah membakukan pendekatan. Tentang apakah ini? Ini tentang ini:
Mengapa ada kata “perusahaan” di sini? Bukan karena kami perusahaan besar atau birokratis, bukan! Saya ingin menggunakan kata “perusahaan” di sini dalam konteks bahwa setiap perusahaan, setiap produk harus memiliki standarnya sendiri, termasuk Anda. Standar apa yang kita miliki?
- Kami memiliki peraturan penempatan. Kami tidak akan bergerak kemana pun tanpa dia, kami tidak bisa. Kami menerapkan sekitar 60 kali seminggu, artinya kami menerapkan hampir secara konstan. Pada saat yang sama, misalnya, kami memiliki peraturan penerapan yang tabu mengenai penerapan pada hari Jumat - pada prinsipnya, kami tidak menerapkannya.
- Kami memerlukan dokumentasi. Tidak ada satu pun komponen baru yang masuk ke produksi jika tidak ada dokumentasinya, meskipun komponen tersebut dibuat di bawah pena spesialis RnD kami. Kami memerlukan instruksi penerapan dari mereka, peta pemantauan, dan deskripsi kasar (seperti yang dapat ditulis oleh pemrogram) tentang cara kerja komponen ini, cara memecahkan masalahnya.
- Kami tidak menyelesaikan penyebab masalahnya, tetapi masalahnya - apa yang sudah saya katakan. Penting bagi kami untuk melindungi pengguna dari masalah.
- Kami punya izin. Misalnya, kami tidak menganggap downtime jika kami kehilangan 2% lalu lintas dalam waktu dua menit. Ini pada dasarnya tidak termasuk dalam statistik kami. Kalau lebih persentase atau sementara, sudah kita hitung.
- Dan kami selalu menulis postmortem. Apapun yang terjadi pada kita, situasi apa pun di mana seseorang berperilaku tidak normal dalam produksi akan tercermin dalam post-mortem. Postmortem adalah dokumen di mana Anda menulis apa yang terjadi pada Anda, waktu yang terperinci, apa yang Anda lakukan untuk memperbaikinya dan (ini adalah blok wajib!) Apa yang akan Anda lakukan untuk mencegah hal ini terjadi di masa depan. Ini wajib dan perlu untuk analisis selanjutnya.
Apa yang dianggap sebagai waktu henti?
Apa yang menyebabkan semua ini?Hal ini mengarah pada fakta bahwa (kami memiliki masalah tertentu dengan stabilitas, ini tidak cocok untuk klien atau kami) selama 6 bulan terakhir, indikator stabilitas kami adalah 99,97. Kita dapat mengatakan bahwa ini tidak terlalu banyak. Ya, kami memiliki sesuatu untuk diperjuangkan. Dari indikator ini, sekitar setengahnya adalah stabilitas, seolah-olah bukan milik kami, tetapi firewall aplikasi web kami, yang berdiri di depan kami dan digunakan sebagai layanan, tetapi klien tidak mempedulikan hal ini.
Kami belajar tidur di malam hari. Akhirnya! Enam bulan lalu kami tidak bisa. Dan pada catatan ini beserta hasilnya, saya ingin membuat satu catatan. Tadi malam ada laporan luar biasa tentang sistem kendali reaktor nuklir. Jika orang yang menulis sistem ini dapat mendengarkan saya, harap lupakan apa yang saya katakan tentang “2% bukanlah waktu henti.” Bagi Anda, 2% adalah waktu henti, meskipun selama dua menit!
Itu saja! Pertanyaan Anda.
Tentang penyeimbang dan migrasi database
Pertanyaan dari penonton (selanjutnya – B): – Selamat malam. Terima kasih banyak atas laporan admin seperti itu! Sebuah pertanyaan singkat tentang penyeimbang Anda. Anda menyebutkan bahwa Anda memiliki WAF, yaitu, seperti yang saya pahami, Anda menggunakan semacam penyeimbang eksternal...
EK: – Tidak, kami menggunakan layanan kami sebagai penyeimbang. Dalam hal ini, WAF secara eksklusif merupakan alat perlindungan DDoS bagi kami.
Dalam: – Bisakah Anda menjelaskan sedikit tentang penyeimbang?
EK: – Seperti yang sudah saya katakan, ini adalah sekelompok server dalam gaya terbuka. Kami sekarang memiliki 5 grup cadangan yang merespons secara eksklusif... yaitu, server yang menjalankan openresty secara eksklusif, hanya mem-proxy lalu lintas. Oleh karena itu, untuk memahami berapa banyak yang kami simpan: kami sekarang memiliki arus lalu lintas reguler beberapa ratus megabit. Mereka mengatasinya, mereka merasa baik, mereka bahkan tidak memaksakan diri.
Dalam: – Juga pertanyaan sederhana. Berikut adalah penerapan Biru/Hijau. Misalnya, apa yang Anda lakukan dengan migrasi basis data?
EK: - Pertanyaan bagus! Lihat, dalam penerapan Biru/Hijau kami memiliki antrian terpisah untuk setiap baris. Artinya, jika kita berbicara tentang antrian acara yang ditransmisikan dari pekerja ke pekerja, maka ada antrian terpisah untuk jalur biru dan jalur hijau. Jika kita berbicara tentang database itu sendiri, maka kami sengaja mempersempitnya sebanyak yang kami bisa, memindahkan semuanya ke dalam antrian, di database kami hanya menyimpan setumpuk transaksi. Dan tumpukan transaksi kami sama untuk semua lini. Dengan database dalam konteks ini: kami tidak membaginya menjadi biru dan hijau, karena kedua versi kode harus mengetahui apa yang terjadi dengan transaksi.
Teman-teman, saya juga punya hadiah kecil untuk memacu Anda - sebuah buku. Dan saya harus diberi penghargaan untuk pertanyaan terbaik.
Dalam: - Halo. Terima kasih atas laporannya. Pertanyaannya adalah ini. Anda memantau pembayaran, Anda memantau layanan yang Anda komunikasikan... Tetapi bagaimana Anda memantau sehingga seseorang entah bagaimana datang ke halaman pembayaran Anda, melakukan pembayaran, dan proyek mengkreditkannya dengan uang? Artinya, bagaimana Anda memantau bahwa marchant tersedia dan telah menerima panggilan balik Anda?
EK: – “Pedagang” bagi kami dalam hal ini adalah layanan eksternal yang sama persis dengan sistem pembayaran. Kami memantau kecepatan respons pedagang.
Tentang enkripsi basis data
Dalam: - Halo. Saya punya pertanyaan yang sedikit terkait. Anda memiliki data sensitif PCI DSS. Saya ingin tahu bagaimana Anda menyimpan PAN dalam antrian yang perlu Anda transfer? Apakah Anda menggunakan enkripsi apa pun? Dan ini mengarah ke pertanyaan kedua: menurut PCI DSS, perlu mengenkripsi ulang database secara berkala jika terjadi perubahan (pemecatan administrator, dll.) - apa yang terjadi dengan aksesibilitas dalam kasus ini?
EK: - Pertanyaan bagus! Pertama, kami tidak menyimpan PAN dalam antrian. Pada prinsipnya, kami tidak berhak menyimpan PAN di mana pun dalam bentuk yang jelas, jadi kami menggunakan layanan khusus (kami menyebutnya "Kademon") - ini adalah layanan yang hanya melakukan satu hal: menerima pesan sebagai masukan dan mengirimkannya mengeluarkan pesan terenkripsi. Dan kami menyimpan semuanya dengan pesan terenkripsi ini. Oleh karena itu, panjang kunci kami di bawah satu kilobyte, sehingga ini serius dan dapat diandalkan.Dalam: – Apakah Anda memerlukan 2 kilobyte sekarang?
EK: – Sepertinya baru kemarin 256... Nah, di mana lagi?!
Oleh karena itu, ini adalah yang pertama. Dan kedua, solusi yang ada, mendukung prosedur enkripsi ulang - ada dua pasang “keks” (kunci), yang memberikan “dek” yang mengenkripsi (kunci adalah kuncinya, dek adalah turunan dari kunci yang mengenkripsi) . Dan jika prosedur dimulai (itu terjadi secara teratur, dari 3 bulan hingga ± beberapa), kami mengunduh sepasang “kue” baru, dan kami mengenkripsi ulang datanya. Kami memiliki layanan terpisah yang mengambil semua data dan mengenkripsinya dengan cara baru; Data disimpan di sebelah pengidentifikasi kunci yang dienkripsi. Oleh karena itu, segera setelah kami mengenkripsi data dengan kunci baru, kami menghapus kunci lama.
Terkadang pembayaran perlu dilakukan secara manual...
Dalam: – Artinya, jika pengembalian dana telah tiba untuk suatu operasi, apakah Anda masih akan mendekripsinya dengan kunci lama?
EK: - Ya.
Dalam: – Lalu satu pertanyaan kecil lagi. Ketika terjadi kegagalan, kejatuhan, atau insiden, transaksi perlu dilakukan secara manual. Ada situasi seperti itu.
EK: - Ya kadang kadang.
Dalam: – Dari mana Anda mendapatkan data ini? Atau apakah Anda sendiri yang pergi ke fasilitas penyimpanan ini?
EK: – Tidak, tentu saja, kami memiliki semacam sistem back-office yang berisi antarmuka untuk dukungan kami. Jika kami tidak mengetahui status transaksi tersebut (misalnya, hingga sistem pembayaran merespons dengan batas waktu), kami tidak mengetahui secara apriori, yaitu kami menetapkan status akhir hanya dengan keyakinan penuh. Dalam hal ini, kami menetapkan transaksi ke status khusus untuk pemrosesan manual. Di pagi hari, keesokan harinya, segera setelah dukungan menerima informasi bahwa transaksi ini dan itu tetap ada dalam sistem pembayaran, mereka memprosesnya secara manual di antarmuka ini.
Dalam: – Saya punya beberapa pertanyaan. Salah satunya adalah kelanjutan dari zona PCI DSS: bagaimana cara mencatat sirkuitnya? Pertanyaan ini karena pengembang bisa saja memasukkan apa saja ke dalam log! Pertanyaan kedua: bagaimana Anda meluncurkan perbaikan terbaru? Menggunakan pegangan dalam database adalah salah satu opsi, tetapi mungkin ada perbaikan terbaru gratis - bagaimana prosedurnya? Dan pertanyaan ketiga mungkin terkait dengan RTO, RPO. Ketersediaan Anda adalah 99,97, hampir empat sembilan, tetapi sejauh yang saya pahami, Anda memiliki pusat data kedua, pusat data ketiga, dan pusat data kelima... Bagaimana Anda menyinkronkannya, mereplikasinya, dan yang lainnya?EK: - Mari kita mulai dengan yang pertama. Apakah pertanyaan pertama tentang log? Saat kami menulis log, kami memiliki lapisan yang menutupi semua data sensitif. Dia melihat topeng dan bidang tambahan. Oleh karena itu, log kami keluar dengan data yang sudah di-mask dan sirkuit PCI DSS. Ini adalah salah satu tugas rutin yang diberikan kepada departemen pengujian. Mereka diharuskan memeriksa setiap tugas, termasuk log yang mereka tulis, dan ini adalah salah satu tugas rutin selama peninjauan kode, untuk mengontrol bahwa pengembang tidak menulis sesuatu. Pemeriksaan selanjutnya dilakukan secara rutin oleh departemen keamanan informasi sekitar seminggu sekali: log untuk hari terakhir diambil secara selektif dan dijalankan melalui pemindai-analisis khusus dari server pengujian untuk memeriksa semuanya.
Tentang perbaikan terbaru. Ini termasuk dalam peraturan penerapan kami. Kami memiliki klausul terpisah tentang perbaikan terbaru. Kami yakin bahwa kami menerapkan perbaikan terbaru sepanjang waktu saat kami membutuhkannya. Segera setelah versi dirakit, segera setelah dijalankan, segera setelah kami memiliki artefak, kami memiliki administrator sistem yang bertugas menelepon dari dukungan, dan dia menyebarkannya pada saat diperlukan.Tentang "empat sembilan". Angka yang kami miliki saat ini memang sudah tercapai, dan kami perjuangkan di data center lain. Sekarang kami memiliki pusat data kedua, dan kami mulai melakukan rute di antara keduanya, dan masalah replikasi lintas pusat data benar-benar merupakan pertanyaan yang tidak sepele. Kami mencoba menyelesaikannya sekaligus dengan menggunakan cara yang berbeda: kami mencoba menggunakan "Tarantula" yang sama - kami tidak berhasil, saya akan segera memberi tahu Anda. Itu sebabnya kami akhirnya memesan "sens" secara manual. Faktanya, setiap aplikasi di sistem kami menjalankan sinkronisasi “perubahan – selesai” yang diperlukan antar pusat data secara asinkron.
Dalam: – Jika Anda mendapat yang kedua, mengapa Anda tidak mendapatkan yang ketiga? Karena belum ada orang yang otaknya terbelah...
EK: – Tapi kami tidak memiliki Split Brain. Karena kenyataan bahwa setiap aplikasi dijalankan oleh multimaster, tidak masalah bagi kami pusat mana permintaan tersebut datang. Kami siap dengan kenyataan bahwa jika salah satu pusat data kami gagal (kami mengandalkan ini) dan di tengah permintaan pengguna beralih ke pusat data kedua, kami siap kehilangan pengguna ini; tapi ini akan menjadi satuan, satuan mutlak.
Dalam: - Selamat malam. Terima kasih atas laporannya. Anda berbicara tentang debugger Anda, yang menjalankan beberapa transaksi pengujian dalam produksi. Tapi beri tahu kami tentang transaksi uji! Seberapa dalam?
EK: – Ini melewati siklus penuh seluruh komponen. Untuk komponen, tidak ada perbedaan antara transaksi pengujian dan transaksi produksi. Namun dari sudut pandang logis, ini hanyalah proyek terpisah dalam sistem, yang hanya menjalankan transaksi uji.
Dalam: -Di mana kamu memotongnya? Di sini Inti mengirim...
EK: – Kami berada di belakang “Kor” dalam hal ini untuk transaksi uji... Kami memiliki yang namanya perutean: “Kor” mengetahui sistem pembayaran mana yang akan dikirim - kami mengirim ke sistem pembayaran palsu, yang hanya memberikan sinyal http dan itu saja.
Dalam: – Tolong beri tahu saya, apakah aplikasi Anda ditulis dalam satu monolit besar, atau apakah Anda memotongnya menjadi beberapa layanan atau bahkan layanan mikro?
EK: – Kami tidak memiliki monolit, tentu saja kami memiliki aplikasi berorientasi layanan. Kami bercanda bahwa layanan kami terbuat dari monolit - ukurannya cukup besar. Sulit untuk menyebutnya layanan mikro, tetapi ini adalah layanan di mana pekerja mesin terdistribusi beroperasi.
Jika layanan di server dikompromikan...
Dalam: – Lalu saya punya pertanyaan berikutnya. Bahkan jika itu adalah sebuah monolit, Anda masih mengatakan bahwa Anda memiliki banyak dari server instan ini, semuanya pada dasarnya memproses data, dan pertanyaannya adalah: “Jika terjadi kompromi pada salah satu server instan atau aplikasi, tautan individual apa pun , apakah mereka memiliki semacam kontrol akses? Siapa di antara mereka yang dapat melakukan apa? Siapa yang harus saya hubungi untuk informasi apa?
EK: - Iya tentu saja. Persyaratan keamanannya cukup serius. Pertama, kami memiliki pergerakan data terbuka, dan port hanyalah tempat kami mengantisipasi pergerakan lalu lintas terlebih dahulu. Jika suatu komponen berkomunikasi dengan database (misalnya, dengan Muskul) melalui 5-4-3-2, hanya 5-4-3-2 yang akan terbuka untuknya, dan port lain serta arah lalu lintas lainnya tidak akan tersedia. Selain itu, Anda perlu memahami bahwa dalam produksi kami ada sekitar 10 loop keamanan yang berbeda. Dan bahkan jika aplikasi tersebut disusupi, amit-amit, penyerang tidak akan dapat mengakses konsol manajemen server, karena ini adalah zona keamanan jaringan yang berbeda.Dalam: – Dan dalam konteks ini, yang lebih menarik bagi saya adalah Anda memiliki kontrak tertentu dengan layanan - apa yang dapat mereka lakukan, melalui “tindakan” apa mereka dapat menghubungi satu sama lain... Dan dalam aliran normal, beberapa layanan tertentu meminta beberapa baris, daftar "tindakan" di sisi lain. Mereka tampaknya tidak berpaling kepada orang lain dalam situasi normal, dan mereka memiliki tanggung jawab lain. Jika salah satunya dikompromikan, apakah dapat mengganggu “tindakan” layanan tersebut?..
EK: - Saya mengerti. Jika dalam situasi normal dengan server lain komunikasi diperbolehkan, maka ya. Menurut kontrak SLA, kami tidak memantau bahwa Anda hanya diperbolehkan melakukan 3 “tindakan” pertama, dan Anda tidak diperbolehkan melakukan 4 “tindakan”. Ini mungkin mubazir bagi kami, karena pada prinsipnya kami sudah memiliki sistem proteksi 4 tingkat untuk sirkuit. Kami lebih suka mempertahankan diri dengan kontur, dibandingkan dengan bagian dalam.
Cara kerja Visa, MasterCard, dan Bank Tabungan
Dalam: – Saya ingin memperjelas suatu hal tentang peralihan pengguna dari satu pusat data ke pusat data lainnya. Sejauh yang saya tahu, Visa dan MasterCard beroperasi menggunakan protokol sinkron biner 8583, dan ada campuran di sana. Dan saya ingin tahu, yang kami maksud sekarang adalah peralihan – apakah langsung “Visa” dan “MasterCard” atau sebelum sistem pembayaran, sebelum diproses?
EK: - Ini sebelum dicampur. Campuran kami terletak di pusat data yang sama.
Dalam: – Secara kasar, apakah Anda memiliki satu titik koneksi?
EK: – “Visa” dan “MasterCard” - ya. Hanya karena Visa dan MasterCard memerlukan investasi infrastruktur yang cukup serius untuk menyelesaikan kontrak terpisah guna mendapatkan pasangan campuran kedua, misalnya. Mereka dicadangkan dalam satu pusat data, tetapi jika, amit-amit, pusat data kami, di mana ada campuran untuk menghubungkan ke Visa dan MasterCard, mati, maka koneksi kami dengan Visa dan MasterCard akan hilang...
Dalam: – Bagaimana cara memesannya? Saya tahu bahwa Visa pada prinsipnya hanya mengizinkan satu koneksi!
EK: – Mereka menyediakan peralatannya sendiri. Bagaimanapun, kami menerima peralatan yang sepenuhnya mubazir di dalamnya.
Dalam: – Jadi standnya dari Connects Orange mereka?..
EK: - Ya.
Dalam: – Namun bagaimana dengan kasus ini: jika pusat data Anda hilang, bagaimana Anda dapat terus menggunakannya? Atau apakah lalu lintas berhenti begitu saja?
EK: - TIDAK. Dalam hal ini, kami hanya akan mengalihkan lalu lintas ke saluran lain, yang tentu saja akan lebih mahal bagi kami dan lebih mahal bagi klien kami. Tetapi lalu lintas tidak akan melalui koneksi langsung kami ke Visa, MasterCard, tetapi melalui kondisional Bank Tabungan (sangat berlebihan).
Saya sangat meminta maaf jika saya menyinggung karyawan Bank Tabungan. Namun menurut statistik kami, di antara bank-bank Rusia, Bank Tabungan paling sering jatuh. Tidak ada satu bulan pun yang berlalu tanpa ada sesuatu yang terjadi di Bank Tabungan.
Beberapa iklan 🙂
Terima kasih untuk tetap bersama kami. Apakah Anda menyukai artikel kami? Ingin melihat konten yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikan kepada teman, , analog unik dari server level awal, yang kami temukan untuk Anda: (tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).
Dell R730xd 2x lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya disini di Belanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mulai $99! Membaca tentang
Sumber: www.habr.com