HighLoad ++, Evgeniy Kuzovlev (EcommPay IT): naon anu kudu dilakukeun nalika hiji menit downtime ngarugikeun $100000

Sarerea ngobrol ngeunaan prosés pamekaran sareng uji coba, pelatihan staf, ningkatkeun motivasi, tapi prosés ieu henteu cekap nalika hiji menit downtime jasa ngarugikeun artos anu ageung. Naon anu kudu dilakukeun nalika anjeun ngalaksanakeun transaksi kauangan dina SLA anu ketat? Kumaha carana ningkatkeun reliabilitas sareng kasabaran kasalahan sistem anjeun, nyandak pamekaran sareng nguji kaluar tina persamaan?

Konperénsi HighLoad ++ salajengna bakal dilaksanakeun dina 6 sareng 7 April 2020 di St. Rinci jeung tiket keur link. Nopember 9, 18:00. HighLoad ++ Moscow 2018, Cirebon + Kolkata aula. Tésis jeung presentasi.

Evgeniy Kuzovlev (saterusna - EC): - Babaturan, halo! Nami abdi Kuzovlev Evgeniy. Abdi ti perusahaan EcommPay, divisi khusus nyaéta EcommPay IT, divisi IT tina grup perusahaan. Sareng dinten ayeuna urang bakal ngobrol ngeunaan downtimes - ngeunaan kumaha carana ngahindarkeun aranjeunna, ngeunaan kumaha carana ngaleutikan konsékuansi maranéhna lamun teu bisa dihindari. Topik anu dinyatakeun kieu: "Naon anu kudu dipigawé lamun hiji menit downtime ngarugikeun $100"? Ningali payun, jumlah urang tiasa dibandingkeun.

Naon anu dilakukeun ku EcommPay IT?

Saha urang? Naha kuring nangtung di dieu di hareup anjeun? Naha kuring boga hak pikeun ngabejaan Anjeun hal di dieu? Sareng naon anu bakal urang bahas di dieu langkung rinci?

Grup perusahaan EcommPay mangrupakeun acquirer internasional. Kami ngolah pamayaran di sakumna dunya - di Rusia, Eropa, Asia Tenggara (Sakuliah Dunya). Kami ngagaduhan 9 kantor, total 500 karyawan, sareng kirang langkung satengahna mangrupikeun spesialis IT. Sagala anu urang laksanakeun, naon waé anu urang hasilkeun artos, urang laksanakeun sorangan.

Kami nyerat sadaya produk kami (sareng urang gaduh seueur pisan - dina garis produk IT ageung kami gaduh sakitar 16 komponén anu béda) sorangan; Urang nulis sorangan, urang ngamekarkeun diri. Sareng ayeuna urang ngalaksanakeun kira-kira sajuta transaksi sadinten (jutaan sigana mangrupikeun cara anu leres pikeun nyarioskeunana). Kami perusahaan anu cukup ngora - umurna ngan ukur genep taun.

6 sababaraha taun ka pengker éta ngamimitian sapertos nalika para lalaki sumping sareng usaha. Aranjeunna dihijikeun ku hiji gagasan (aya nanaon sejenna tapi hiji gagasan), sarta kami lumpat. Kawas naon ngamimitian, urang lumpat leuwih gancang ... Pikeun urang, speed éta leuwih penting batan kualitas.

Dina sababaraha waktos urang lirén: urang sadar yén urang henteu tiasa deui kumaha waé hirup dina laju éta sareng kualitas éta sareng urang kedah difokuskeun kualitas heula. Dina momen ieu, urang mutuskeun pikeun nulis platform anyar nu bakal bener, scalable, sarta dipercaya. Aranjeunna mimiti nulis platform ieu (aranjeunna mimiti investasi, ngembangkeun ngembangkeun, nguji), tapi di sawatara titik maranéhna sadar yén ngembangkeun sarta nguji teu ngidinan urang pikeun ngahontal tingkat anyar kualitas layanan.

Anjeun ngadamel produk anyar, anjeun nempatkeun kana produksi, tapi tetep aya anu salah dimana waé. Sareng dinten ayeuna urang bakal ngobrol ngeunaan kumaha carana ngahontal tingkat kualitas anyar (kumaha urang ngalakukeun éta, ngeunaan pangalaman urang), nyandak pamekaran sareng nguji kaluar tina persamaan; Kami bakal ngobrol ngeunaan naon anu sayogi pikeun operasi - naon operasi anu tiasa dilakukeun ku sorangan, naon anu tiasa ditawarkeun pikeun nguji pikeun mangaruhan kualitas.

Downtimes. Paréntah operasi.

Salawasna batu pondasi utama, anu bakal urang bahas ayeuna nyaéta downtime. Hiji kecap dahsyat. Lamun urang boga downtime, sagalana goréng pikeun urang. Kami ngajalankeun pikeun ngangkat éta, admins nyekel server - Allah nyaram eta teu ragrag, sabab nyebutkeun dina lagu éta. Ieu naon urang bakal ngobrol ngeunaan kiwari.

Nalika urang mimiti ngarobih pendekatan, urang ngawangun 4 paréntah. Kuring geus aranjeunna dibere dina slides:

Paréntah ieu cukup saderhana:

• Gancang ngaidentipikasi masalah.
• Meunang leupas tina eta malah leuwih gancang.
• Ngabantosan ngartos alesanana (engké, pikeun pamekar).
• Jeung standarisasi pendekatan.

Abdi hoyong ngagambar perhatian Anjeun ka titik No.. 2. Urang lalaki leupas tina masalah, teu ngajawab eta. Mutuskeun téh sekundér. Pikeun urang, hal anu utami nyaéta yén pangguna ditangtayungan tina masalah ieu. Éta bakal aya di sababaraha lingkungan anu terasing, tapi lingkungan ieu moal aya hubunganana sareng éta. Sabenerna, urang bakal ngaliwat opat kelompok masalah ieu (sababaraha langkung rinci, sababaraha langkung rinci), kuring bakal nyarioskeun ka anjeun naon anu kami anggo, naon pangalaman anu relevan dina solusi.

Ngarengsekeun masalah: Iraha kajadian sareng naon anu kudu dilakukeun?

Tapi urang bakal ngamimitian kaluar tina urutan, urang mimitian ku titik No 2 - kumaha gancang meunang leupas tina masalah? Aya masalah - urang kudu ngalereskeun eta. "Naon anu kudu urang pigawé ngeunaan ieu?" - patarosan utama. Sareng nalika urang mimiti mikir ngeunaan kumaha carana ngalereskeun masalah, urang ngembangkeun pikeun diri urang sorangan sababaraha syarat anu kedah diturutan pikeun ngungkulan.

Pikeun ngarumuskeun sarat ieu, urang mutuskeun pikeun nanya ka diri urang sorangan: "Iraha urang gaduh masalah"? Jeung masalah, sakumaha tétéla, lumangsung dina opat kasus:

• Gagalna hardware.
• Ladenan éksternal gagal.
• Ngarobah versi software (deployment sarua).
• Tumuwuhna beban ngabeledug.

Urang moal ngobrol ngeunaan dua munggaran. Karusakan hardware tiasa direngsekeun saderhana: anjeun kedah gaduh sadayana duplikat. Upami ieu mangrupikeun disk, disk kedah dirakit dina RAID; upami ieu mangrupikeun server, server kedah duplikat; upami anjeun gaduh infrastruktur jaringan, anjeun kedah nyayogikeun salinan kadua infrastruktur jaringan, nyaéta, anjeun nyandak sareng duplikat eta. Sareng upami aya anu gagal, anjeun ngalih ka kakuatan cadangan. Hese ngomong nanaon deui di dieu.

Anu kadua nyaéta gagalna jasa éksternal. Kanggo sabagéan ageung, sistem teu masalah pisan, tapi teu keur urang. Kusabab kami ngolah pangmayaran, kami mangrupikeun agrégator anu nangtung antara pangguna (anu ngalebetkeun data kartuna) sareng bank, sistem pamayaran (Visa, MasterCard, Mira, jsb.). Jasa éksternal kami (sistem pamayaran, bank) condong gagal. Sanes urang atanapi anjeun (upami anjeun gaduh jasa sapertos kitu) tiasa mangaruhan ieu.

Naon anu kudu dipigawé lajeng? Aya dua pilihan di dieu. Mimiti, upami anjeun tiasa, anjeun kedah nyalin jasa ieu dina sababaraha cara. Contona, upami urang tiasa, urang mindahkeun lalulintas ti hiji layanan ka nu sejen: contona, kartu diolah ngaliwatan Sberbank, Sberbank aya masalah - urang mindahkeun lalulintas [sarat] ka Raiffeisen. Hal kadua anu urang tiasa laksanakeun nyaéta perhatikeun kagagalan jasa éksternal gancang pisan, sareng ku kituna urang bakal ngobrol ngeunaan laju réspon dina bagian salajengna laporan.

Nyatana, tina opat ieu, urang tiasa sacara khusus mangaruhan parobihan vérsi parangkat lunak - nyandak tindakan anu bakal nyababkeun paningkatan dina kaayaan dina konteks panyebaran sareng dina kontéks pertumbuhan ngabeledug dina beban. Sabenerna, éta anu urang lakukeun. Ieu, deui, catetan leutik ...

Tina opat masalah ieu, sababaraha direngsekeun langsung upami anjeun gaduh awan. Upami anjeun aya dina Microsoft Azhur, awan Ozon, atanapi nganggo awan kami, tina Yandex atanapi Mail, maka sahenteuna gangguan hardware janten masalahna sareng sadayana langsung janten saé pikeun anjeun dina konteks gangguan hardware.

Kami hiji parusahaan rada unconventional. Di dieu dulur ngobrol ngeunaan "Kubernets", ngeunaan awan - urang teu boga "Kubernets" atawa awan. Tapi kami boga rak hardware dina loba puseur data, sarta kami kapaksa hirup dina hardware ieu, urang kapaksa nanggungjawaban kana sadaya. Ku alatan éta, urang bakal ngobrol dina konteks ieu. Ku kituna, ngeunaan masalah. Dua anu munggaran dikaluarkeun tina kurung.

Ngarobah versi software. Dasar

pamekar urang teu boga aksés ka produksi. Kunaon éta? Ieu ngan éta kami PCI DSS Certified, sarta pamekar urang ngan saukur teu boga hak pikeun meunang kana "produk". Éta éta, titik. Sakabehna. Ku alatan éta, tanggung jawab ngembangkeun ends persis di momen nalika ngembangkeun submits wangunan pikeun release.

Dasar kadua anu urang gaduh, anu ogé ngabantosan urang pisan, nyaéta henteuna pangaweruh anu teu didokumentasikeun unik. Kuring miharep éta sarua keur anjeun. Kusabab lamun ieu teu masalahna, anjeun bakal boga masalah. Masalah bakal timbul nalika pangaweruh anu unik sareng teu didokumentasikeun ieu henteu aya dina waktos anu pas dina tempat anu leres. Anggap anjeun gaduh hiji jalma anu terang kumaha nyebarkeun komponén khusus - jalma éta henteu aya, anjeunna nuju liburan atanapi gering - éta waé, anjeun gaduh masalah.

Jeung dasar katilu nu urang geus datang. Kami dugi ka éta ngalangkungan nyeri, getih, cimata - kami dugi ka kacindekan yén salah sahiji gedong kami ngandung kasalahan, sanaos henteu aya kasalahan. Urang mutuskeun ieu keur diri urang sorangan: lamun urang nyebarkeun hiji hal, nalika urang gulung hal kana produksi, urang boga hiji ngawangun kalawan kasalahan. Kami parantos ngawangun sarat anu kedah dicumponan ku sistem kami.

Sarat pikeun ngarobah versi software

Aya tilu syarat:

• Urang kudu gancang gulung deui deployment.
• Urang kedah ngaleutikan dampak tina panyebaran anu henteu suksés.
• Sareng urang kedah tiasa gancang nyebarkeun paralel.
  Persis dina urutan éta! Naha? Kusabab, mimiti sagala, nalika deploying versi anyar, speed teu penting, tapi hal anu penting pikeun anjeun, lamun aya nu salah, gancang balik sarta boga dampak minimal. Tapi upami anjeun gaduh sakumpulan versi dina produksi, anu tétéla aya kasalahan (tina bulao, teu aya panyebaran, tapi aya kasalahan) - laju panyebaran salajengna penting pikeun anjeun. Naon anu urang lakukeun pikeun nyumponan tungtutan ieu? Urang resorted kana metodologi handap:

  
  
  Éta cukup dipikanyaho, kami henteu kantos nimukeunana - ieu mangrupikeun penyebaran Biru / Héjo. Naon éta? Anjeun kedah gaduh salinan pikeun tiap grup server dimana aplikasi anjeun dipasang. Salinan "haneut": teu aya patalimarga di dinya, tapi iraha waé lalulintas ieu tiasa dikirim ka salinan ieu. Ieu salinan ngandung versi saméméhna. Sareng dina waktos panyebaran, anjeun ngagulung kodeu kana salinan anu teu aktip. Teras anjeun ngalihkeun bagian tina lalu lintas (atanapi sadayana) kana versi énggal. Ku kituna, dina raraga ngarobah aliran lalulintas ti versi heubeul ka nu anyar, anjeun kudu ngalakukeun ngan hiji aksi: Anjeun kudu ngarobah balancer di hulu, ngarobah arah - ti hiji hulu ka nu sejen. Ieu pisan merenah tur solves masalah switching gancang sarta rollback gancang.

  Di dieu solusi pikeun patarosan kadua ngaminimalkeun: anjeun ngan ukur tiasa ngirim bagian tina lalu lintas anjeun ka jalur énggal, ka garis kalayan kode énggal (nyanggakeun, contona, 2%). Sareng 2% ieu sanés 100%! Upami anjeun kaleungitan 100% lalu lintas anjeun kusabab panyebaran anu henteu suksés, éta pikasieuneun; upami anjeun kaleungitan 2% tina lalu lintas anjeun, éta henteu pikaresepeun, tapi henteu pikasieuneun. Leuwih ti éta, pamaké bakal paling dipikaresep malah moal aya bewara ieu, sabab dina sababaraha kasus (teu sakabehna) pamaké sarua, mencét F5, bakal dibawa ka sejen, versi gawé.

  Bulao / Héjo nyebarkeun. Routing

  Sanajan kitu, teu sagalana geus jadi basajan "Blue/Green deployment"... Sadaya komponén urang bisa dibagi kana tilu grup:

  • ieu frontend (kaca pembayaran nu klien kami ningali);
  • inti ngolah;
  • adaptor pikeun gawé bareng sistem pembayaran (bank, MasterCard, Visa ...).

  Sareng aya nuansa di dieu - nuansana aya dina rute antara jalur. Upami anjeun ngan ukur ngalihkeun 100% lalu lintas, anjeun henteu ngagaduhan masalah ieu. Tapi upami anjeun hoyong ngalihkeun 2%, anjeun mimiti naroskeun patarosan: "Kumaha carana ngalakukeun ieu?" Hal pangbasajanna nyaéta lempeng ka hareup: Anjeun tiasa nyetél Babak Robin di nginx ku pilihan acak, jeung anjeun boga 2% ka kénca, 98% ka katuhu. Tapi ieu teu salawasna cocog.

  Contona, dina kasus urang, pamaké berinteraksi sareng sistem kalawan leuwih ti hiji pamundut. Ieu normal: 2, 3, 4, 5 requests - sistem Anjeun bisa jadi sarua. Sareng upami penting pikeun anjeun yén sadaya pamundut pangguna sumping ka garis anu sami dimana pamundut anu munggaran sumping, atanapi (titik kadua) sadaya pamundut pangguna sumping ka garis énggal saatos saklar (anjeunna tiasa ngamimitian damel sateuacana sareng Sistim, saméméh switch), - lajeng distribusi acak ieu teu cocog pikeun anjeun. Lajeng aya pilihan handap:

  
  
  Pilihan kahiji, pangbasajanna, dumasar kana parameter dasar klien (IP Hash). Anjeun gaduh IP, sareng anjeun ngabagi ti katuhu ka kenca ku alamat IP. Teras kasus kadua anu kuring dijelaskeun bakal tiasa dianggo pikeun anjeun, nalika panyebaran lumangsung, pangguna parantos tiasa ngamimitian damel sareng sistem anjeun, sareng ti momen panyebaran sadaya pamundut bakal angkat ka jalur énggal (ka sami, sebutkeun).

  Upami kusabab sababaraha alesan ieu henteu cocog sareng anjeun sareng anjeun kedah ngirim pamenta ka jalur dimana pamundut awal pangguna sumping, maka anjeun gaduh dua pilihan ...
  Pilihan kahiji: anjeun tiasa mésér nginx + anu mayar. Aya mékanisme sesi Sticky, anu, dumasar kana pamundut awal pangguna, masihan sési ka pangguna sareng ngabeungkeut kana hiji atanapi anu sanés di hulu. Sadaya pamundut pangguna anu salajengna dina waktos sési bakal dikirim ka hulu anu sami dimana sési dipasang.

  Ieu henteu cocog sareng kami sabab kami parantos nginx biasa. Ngalihkeun ka nginx + sanés yén éta mahal, ngan ukur éta rada nyeri pikeun urang sareng henteu leres pisan. "Sticks Sessions", contona, teu dianggo pikeun urang pikeun alesan basajan yén "Stick Sessions" teu ngidinan routing dumasar kana "Boh-atawa". Di dinya anjeun tiasa netepkeun naon anu urang lakukeun "Sticks Sessions", contona, ku alamat IP atanapi ku alamat IP sareng cookies atanapi ku postparameter, tapi "Boh-atawa" langkung rumit di dinya.

  Ku alatan éta, urang datang ka pilihan kaopat. Kami nyandak nginx on stéroid (ieu openresty) - ieu nginx sarua, nu Sajaba ngarojong citakan tina Aksara panungtungan. Anjeun tiasa nulis naskah panungtungan, masihan eta "open sésana", jeung Aksara panungtungan ieu bakal dieksekusi nalika pamundut pamaké datang.

  Sarta kami wrote, dina kanyataanana, naskah misalna, diatur sorangan "openresti" na dina naskah ieu urang nyortir ngaliwatan 6 parameter béda ku concatenation "Atawa". Gumantung kana ayana hiji atawa parameter sejen, urang terang yen pamaké datang ka hiji halaman atawa sejen, hiji garis atawa sejen.

  Bulao / Héjo nyebarkeun. Kaunggulan jeung kalemahan

  Tangtosna, sigana mah tiasa janten langkung saderhana (nganggo "Sesi Sticky" anu sami), tapi urang ogé gaduh nuansa anu henteu ngan ukur pangguna berinteraksi sareng kami dina kerangka hiji ngolah hiji transaksi ... Tapi sistem pembayaran ogé berinteraksi sareng kami: Saatos kami ngolah urus (ku ngirim pamundut ka sistem pembayaran), kami nampi coolback a.
  Sareng anggap, upami di jero sirkuit urang tiasa neraskeun alamat IP pangguna dina sadaya pamundut sareng ngabagi pangguna dumasar kana alamat IP, maka urang moal nyarioskeun "Visa" anu sami: "Sobat, kami mangrupikeun perusahaan retro, sigana sigana. janten internasional (dina ramatloka jeung di Rusia)... Mangga nyadiakeun kami kalawan alamat IP pamaké dina widang tambahan, protokol anjeun standarisasi "! Ieu jelas yén maranéhna moal satuju.

  
  
  Ku alatan éta, ieu teu dianggo pikeun urang - urang ngalakukeun openresty. Sasuai, kalayan routing kami ngagaduhan sapertos kieu:

  Blue / Green Deployment gaduh, sasuai, kaunggulan anu ku kuring disebatkeun sareng kalemahan.

  Dua kalemahan:

  • Anjeun kudu repot jeung routing;
  • disadvantage utama kadua expense nu.

  Anjeun peryogi dua kali saloba server, anjeun peryogi dua kali saloba sumberdaya operasional, anjeun kudu méakkeun dua kali loba usaha pikeun ngajaga sakabeh kebon binatang ieu.

  Ngomong-ngomong, diantara kaunggulan aya hiji deui hal anu kuring henteu nyarios sateuacanna: anjeun gaduh cadangan upami aya paningkatan beban. Upami Anjeun gaduh hiji tumuwuhna ngabeledug dina beban, anjeun boga angka nu gede ngarupakeun pamaké, mangka anjeun ngan saukur kaasup garis kadua dina 50 nepi ka 50 distribusi - jeung anjeun langsung boga x2 server dina kluster anjeun nepi ka anjeun ngajawab masalah ngabogaan leuwih server.

  Kumaha carana ngadamel panyebaran gancang?

  Urang ngobrol ngeunaan kumaha carana ngabéréskeun masalah ngaminimalkeun sareng mundur gancang, tapi patarosan tetep: "Kumaha cara nyebarkeun gancang?"

  
  
  Ieu pondok tur basajan.

  • Anjeun kedah gaduh sistem CD (Pangiriman Terus-terusan) - anjeun moal tiasa hirup tanpa éta. Upami anjeun gaduh hiji server, anjeun tiasa nyebarkeun sacara manual. Simkuring gaduh ngeunaan hiji satengah sarébu server na hiji satengah sarébu handles, tangtosna - urang tiasa melak departemén ukuran kamar ieu ngan pikeun nyebarkeun.
  • Panyebaran kedah paralel. Upami panyebaran anjeun berurutan, maka sadayana goréng. Hiji server normal, anjeun bakal nyebarkeun hiji satengah sarébu server sadinten.
  • Sakali deui, pikeun akselerasi, ieu sigana henteu peryogi deui. Salila deployment, proyék ieu biasana diwangun. Anjeun gaduh proyék wéb, aya bagian hareup (anjeun ngalakukeun pak wéb di dinya, anjeun nyusun npm - sapertos kitu), sareng prosés ieu, prinsipna, pondok-cicing - 5 menit, tapi 5 menit ieu tiasa. jadi kritis. Éta sababna, contona, urang henteu ngalakukeun éta: urang ngahapus 5 menit ieu, urang nyebarkeun artefak.

    Naon ari artefak? Artefak mangrupikeun wangunan anu dirakit dimana sadaya bagian rakitan parantos réngsé. Urang nyimpen artefak ieu dina gudang artefak. Dina hiji waktos kami nganggo dua panyimpen sapertos kitu - éta Nexus sareng ayeuna jFrog Artifactory).Kami mimitina nganggo "Nexus" kusabab urang mimiti ngalaksanakeun pendekatan ieu dina aplikasi java (cocog pisan). Teras aranjeunna nempatkeun sababaraha aplikasi anu ditulis dina PHP di dinya; sarta "Nexus" éta euweuh cocog, sahingga urang milih jFrog Artefactory, nu bisa artifactorize ampir sagalana. Kami malah dugi ka titik yén dina gudang artefak ieu kami nyimpen bungkusan binér sorangan anu kami kumpulkeun pikeun server.

  Tumuwuhna beban ngabeledug

  Urang ngobrol ngeunaan ngarobah versi software. Hal salajengna urang gaduh kanaékan ngabeledug dina beban. Di dieu, kuring sigana hartosna ku pertumbuhan ngabeledug tina beban anu henteu leres-leres ...

  Urang nulis sistem anyar - éta layanan-berorientasi, fashionable, geulis, pagawe madhab, antrian madhab, asynchrony madhab. Sareng dina sistem sapertos kitu, data tiasa ngalir ngaliwatan aliran anu béda. Pikeun transaksi kahiji, pagawe 1st, 3rd, 10th bisa dipaké, pikeun transaksi kadua - nu 2nd, 4th, 5th. Jeung kiwari, hayu urang nyebutkeun, isuk-isuk anjeun gaduh aliran data anu ngagunakeun tilu pagawe munggaran, sarta magrib eta robah nyirorot, sarta sagalana ngagunakeun tilu pagawe sejenna.

  Sareng di dieu tétéla yén anjeun kedah kumaha waé skala pagawé, anjeun kedah kumaha waé skala jasa anjeun, tapi dina waktos anu sami nyegah kembung sumberdaya.

  
  
  Kami parantos netepkeun syarat kami. Sarat ieu cukup basajan: yén aya Service kapanggihna, parameterization - sagalana geus baku pikeun ngawangun sistem scalable misalna, iwal hiji titik - depreciation sumberdaya. Kami nyarios yén kami henteu siap pikeun amortize sumberdaya supados server panas hawa. Kami nyandak "Konsul", kami nyandak "Nomad", anu ngatur pagawé kami.

  Naha ieu masalah keur urang? Hayu urang mundur saeutik. Urang ayeuna gaduh sakitar 70 sistem pamayaran di tukangeun urang. Isuk-isuk, lalu lintas ngalangkungan Sberbank, teras Sberbank murag, contona, sareng urang ngalih ka sistem pembayaran anu sanés. Urang tadi 100 pagawe saméméh Sberbank, sarta sanggeus éta urang kudu sharply ningkatkeun 100 pagawe pikeun sistem pembayaran sejen. Jeung éta desirable pikeun sakabéh ieu lumangsung tanpa partisipasi manusa. Kusabab upami aya partisipasi manusa, kedah aya insinyur linggih di dinya 24/7, anu ngan ukur kedah ngalakukeun ieu, sabab gagal sapertos kitu, nalika 70 sistem aya di tukangeun anjeun, kajantenan rutin.

  Ku alatan éta, urang nempo Nomad, nu boga IP kabuka, jeung nulis hal urang sorangan, Skala-Nomad - ScaleNo, nu ngalakukeun kira-kira di handap ieu: monitor tumuwuhna antrian jeung ngurangan atawa ngaronjatkeun jumlah pagawe gumantung kana dinamika. tina antrian. Nalika urang ngalakukeun éta, urang mikir: "Panginten urang tiasa muka sumberna?" Teras aranjeunna ningali anjeunna - anjeunna sasederhana dua kopecks.

  Sajauh ieu kami geus teu open sourced eta, tapi lamun ujug-ujug sanggeus laporan, sanggeus nyadar yén anjeun peryogi hal saperti, anjeun peryogi eta, kontak abdi aya dina slide panungtungan - mangga nulis ka kuring. Mun aya sahanteuna 3-5 urang, urang bakal sponsor eta.

  
  
  Kumaha gawéna? Hayu urang tingali! Ningali payun: di sisi kénca aya sapotong monitoring kami: ieu hiji baris, di luhur nyaéta waktu ngolah acara, di tengah nyaeta jumlah transaksi, di handap nyaeta jumlah pagawe.

  Upami anjeun ningali, aya glitch dina gambar ieu. Dina bagan luhur, salah sahiji grafik nabrak dina 45 detik - salah sahiji sistem pamayaran turun. Langsung, lalulintas dibawa dina 2 menit sarta antrian mimiti tumuwuh dina sistem pembayaran sejen, dimana aya euweuh pagawe (urang teu ngamangpaatkeun sumberdaya - sabalikna, urang disposed sumberdaya neuleu). Kami henteu hoyong panas - aya sajumlah minimal, sakitar 5-10 pagawé, tapi aranjeunna henteu tiasa ngatasi.

  Grafik panungtungan nembongkeun "punuk", nu ngan hartina "Skaleno" dua kali jumlah ieu. Teras, nalika grafikna turun sakedik, anjeunna ngirangan sakedik - jumlah pagawe sacara otomatis dirobih. Éta kumaha hal ieu jalan. Urang ngobrol ngeunaan titik nomer 2 - "Kumaha gancang ngaleungitkeun alesan."

  Ngawaskeun. Kumaha gancang ngaidentipikasi masalah?

  Ayeuna titik kahiji nyaéta "Kumaha gancang ngaidentipikasi masalahna?" Ngawaskeun! Urang kedah ngartos sababaraha hal gancang. Hal-hal naon anu urang kedah ngartos gancang?

  
  
  Tilu hal!

  • Urang kedah ngartos sareng gancang ngartos kinerja sumber daya urang sorangan.
  • Urang kedah gancang ngartos kagagalan sareng ngawas kinerja sistem anu aya di luar urang.
  • Titik katilu nyaéta ngaidentipikasi kasalahan logis. Ieu nalika sistem berpungsi pikeun anjeun, sagalana geus normal nurutkeun sagala indikator, tapi hal mana anu salah.

  Kuring meureun moal ngabejaan Anjeun nanaon nu tiis di dieu. Abdi bakal janten Kaptén Obvious. Kami milarian naon anu aya di pasar. Urang boga "kebon binatang senang". Ieu mangrupikeun jinis kebon binatang anu ayeuna urang gaduh:

  
  
  Kami nganggo Zabbix pikeun ngawas hardware, pikeun ngawas indikator utama server. Kami nganggo Okmeter pikeun pangkalan data. Kami nganggo "Grafana" sareng "Prometheus" kanggo sadaya indikator sanés anu henteu cocog sareng dua anu munggaran, sababaraha kalayan "Grafana" sareng "Prometheus", sareng sababaraha kalayan "Grafana" kalayan "Influx" sareng Telegraf.

  Sataun ka tukang kami hoyong nganggo New Relic. Hal anu saé, éta tiasa ngalakukeun sadayana. Tapi saloba manéhna bisa ngalakukeun sagalana, manéhna jadi mahal. Nalika kami naék kana volume 1,5 rébu server, hiji vendor sumping ka kami sareng nyarios: "Hayu urang nyimpulkeun perjanjian pikeun taun payun." Kami ningali harga sareng nyarios henteu, kami moal ngalakukeun éta. Ayeuna urang abandoning New Relic, urang boga ngeunaan 15 server ditinggalkeun dina ngawaskeun New Relic. hargana tétéla kacida liar.

  Sareng aya hiji alat anu kami laksanakeun sorangan - ieu Debugger. Mimitina kami nyebatna "Bagger," tapi teras aya guru basa Inggris ngaliwat, seuri liar, sareng namina namina "Debagger." Naon éta? Ieu mangrupikeun alat anu, kanyataanna, dina 15-30 detik dina unggal komponén, sapertos "kotak hideung" sistem, ngajalankeun tés ngeunaan kinerja komponénna.

  Salaku conto, upami aya halaman éksternal (halaman pamayaran), anjeunna ngan saukur muka sareng ningali kumaha éta kedah katingali. Upami ieu ngolah, anjeunna ngirimkeun tés "transaksi" sareng mastikeun yén "transaksi" ieu sumping. Lamun ieu téh sambungan kalawan sistem pamayaran, urang seuneu hiji pamundut test sasuai, dimana urang tiasa, sarta ningali yén sagalana geus rupa kalawan kami.

  Indikator naon anu penting pikeun ngawaskeun?

  Naon utamana urang ngawas? Indikator naon anu penting pikeun urang?

  
  

  • Waktu réspon / RPS di payun mangrupikeun indikator anu penting pisan. Anjeunna langsung ngajawab yén aya anu salah sareng anjeun.
  • Jumlah pesen olahan dina sakabéh antrian.
  • Jumlah pagawe.
  • Métrik kabeneran dasar.

  Titik panungtungan nyaéta "bisnis", "bisnis" métrik. Upami anjeun hoyong ngawas hal anu sami, anjeun kedah netepkeun hiji atanapi dua métrik anu mangrupikeun indikator utama pikeun anjeun. Métrik kami nyaéta throughput (ieu mangrupikeun rasio jumlah transaksi anu suksés kana total aliran transaksi). Upami aya anu robih dina interval 5-10-15 menit, éta hartosna urang gaduh masalah (upami robih sacara radikal).

  Anu katingalina pikeun urang mangrupikeun conto salah sahiji papan kami:

  
  
  Di sisi kénca aya 6 grafik, ieu dumasar kana garis - jumlah pagawe sarta jumlah pesen dina antrian. Di sisi katuhu - RPS, RTS. Di handap ieu sarua "bisnis" métrik. Sarta dina métrik "bisnis" urang langsung bisa nempo yén aya nu salah dina dua grafik tengah ... Ieu ngan sistem sejen nu nangtung tukangeun urang nu geus fallen.

  Hal kadua anu urang kedah laksanakeun nyaéta ngawas ragrag sistem pamayaran éksternal. Di dieu kami nyandak OpenTracing - mékanisme, standar, paradigma anu ngamungkinkeun anjeun ngalacak sistem anu disebarkeun; sarta eta dirobah saeutik. Paradigma OpenTracing baku nyebutkeun yen urang ngawangun renik pikeun tiap pamundut individu. Urang teu kedah ieu, sarta kami dibungkus dina kasimpulan, ngambah aggregation. Kami ngadamel alat anu ngamungkinkeun urang ngalacak laju sistem di tukangeun urang.

  
  
  Grafik nunjukkeun yén salah sahiji sistem pamayaran mimiti ngabales dina 3 detik - urang gaduh masalah. Leuwih ti éta, hal ieu bakal meta lamun masalah dimimitian, dina interval 20-30 detik.

  Sareng kelas katilu kasalahan ngawaskeun anu aya nyaéta ngawaskeun logis.

  Jujur, kuring henteu terang naon anu ngagambar dina slide ieu, sabab kami parantos lami milarian di pasar pikeun hal anu cocog sareng kami. Kami henteu mendakan nanaon, janten kami kedah ngalakukeunana nyalira.

  
  
  Naon anu kuring hartosna ku ngawaskeun logis? Nya, ngabayangkeun: anjeun ngadamel diri anjeun sistem (contona, klon Tinder); Anjeun dijieun, dibuka eta. Manajer suksés Vasya Pupkin nempatkeun éta dina teleponna, ningali awéwé di dinya, resep nya ... jeung kawas teu balik ka gadis - kawas mana anu ka satpam Mikhalych ti puseur bisnis sarua. Pangurus turun ka handap, teras heran: "Naha satpam ieu Mikhalych seuri pisan ka anjeunna?"

  Dina kaayaan kitu ... Pikeun urang, kaayaan ieu hurung saeutik béda, sabab (kuring nulis) ieu leungitna reputasi anu henteu langsung ngabalukarkeun karugian finansial. Kaayaan urang sabalikna: urang tiasa ngalaman karugian finansial langsung - contona, upami urang ngalaksanakeun transaksi anu suksés, tapi éta gagal (atanapi sabalikna). Kuring kungsi nulis alat kuring sorangan nu ngalacak jumlah transaksi suksés ngaliwatan waktu ngagunakeun indikator bisnis. Teu manggihan nanaon di pasar! Ieu persis pamanggih kuring hayang nepikeun. Aya nanaon di pasar pikeun ngajawab masalah nanaon ieu.

  Ieu ngeunaan kumaha gancang ngaidentipikasi masalah.

  Kumaha nangtukeun alesan pikeun deployment

  Grup katilu tina masalah anu urang ngajawab nyaéta sanggeus urang geus ngaidentifikasi masalah, sanggeus urang geus meunang leupas tina eta, eta bakal hadé ngartos alesan pikeun ngembangkeun, pikeun nguji, sarta ngalakukeun hal ngeunaan eta. Sasuai, urang kudu nalungtik, urang kudu ngangkat log.

  
  
  Upami urang ngobrol ngeunaan log (alesan utama nyaéta log), seueur log kami aya dina ELK Stack - ampir sadayana sami. Kanggo sababaraha, éta tiasa henteu aya dina ELK, tapi upami anjeun nyerat log dina gigabyte, maka engké atanapi engké anjeun bakal sumping ka ELK. Urang nulis aranjeunna dina terabytes.

  
  
  Aya masalah di dieu. Kami ngalereskeunana, ngalereskeun kasalahan pikeun pangguna, mimiti ngagali naon anu aya, naék kana Kibana, lebetkeun id transaksi didinya sareng ngagaduhan footcloth sapertos kieu (némbongkeun pisan). Sareng leres pisan henteu aya anu jelas dina footcloth ieu. Naha? Sumuhun, sabab teu jelas bagian mana milik nu worker, bagian mana milik komponén nu. Sareng dina waktos éta urang sadar yén urang peryogi ngalacak - OpenTracing sami anu kuring nyarioskeun.

  Urang panginten ieu sataun katukang, ngancik perhatian urang ka pasar, sarta aya dua parabot - "Zipkin" jeung "Jaeger". "Jager" nyatana ahli waris ideologis sapertos, panerusna ideologis "Zipkin". Sagalana geus alus di Zipkin, iwal ti eta teu nyaho kumaha carana agrégat, teu nyaho kumaha carana kaasup log dina renik, ngan waktu renik. Sareng "Jager" ngadukung ieu.

  Kami ningali "Jager": anjeun tiasa nerapkeun aplikasi, anjeun tiasa nyerat dina Api (standar Api pikeun PHP dina waktos éta, tapi henteu disatujuan - ieu sataun katukang, tapi ayeuna parantos disatujuan), tapi aya. éta pancen euweuh klien. "Oke," pikir urang, sarta nulis klien urang sorangan. Naon anu urang meunang? Ieu kira-kira naon rupana:

  
  
  Dina Jaeger, bentang dijieun pikeun tiap pesen. Nyaéta, nalika pangguna muka sistem, anjeunna ningali hiji atanapi dua blok pikeun tiap pamundut anu asup (1-2-3 - jumlah pamundut anu asup ti pangguna, jumlah blok). Pikeun ngagampangkeun pangguna, kami nambihan tag kana log sareng ngambah waktos. Sasuai, upami aya kasalahan, aplikasi kami bakal nandaan log kalayan tag Kasalahan anu pas. Anjeun tiasa nyaring ku tag Kasalahan sareng ngan ukur bentang anu ngandung blok ieu sareng kasalahan anu bakal ditingalikeun. Ieu kumaha sigana upami urang ngalegaan bentang:

  
  
  Di jero bentang aya sakumpulan tapak. Dina hal ieu, ieu tilu ngambah test, sarta renik katilu ngabejaan urang yen aya kasalahan. Dina waktos anu sami, di dieu urang ningali jejak waktos: urang gaduh skala waktos di luhur, sareng urang ningali dina interval waktos naon ieu atanapi log éta dirékam.

  Sasuai, hal lumangsung ogé pikeun urang. Urang nulis extension urang sorangan jeung urang open sourced eta. Upami anjeun hoyong damel sareng nyukcruk, upami anjeun hoyong damel sareng "Jager" dina PHP, aya ekstensi kami, wilujeng sumping, sakumaha anu aranjeunna nyarios:

  
  
  Kami ngagaduhan ekstensi ieu - éta mangrupikeun klien pikeun OpenTracing Api, didamel salaku php-extention, nyaéta, anjeun kedah ngumpul sareng pasang dina sistem. Sataun katukang teu aya anu béda. Ayeuna aya klien séjén anu kawas komponén. Ieu nepi ka anjeun: boh anjeun ngompa kaluar komponén kalawan komposer a, atawa anjeun make extension nepi ka anjeun.

  Standar perusahaan

  Urang ngobrol ngeunaan tilu parentah. Paréntah kaopat nyaéta pikeun ngabakukeun pendekatan. Naon ieu ngeunaan? Ieu ngeunaan ieu:

  
  
  Naha kecap "perusahaan" di dieu? Henteu sabab kami perusahaan ageung atanapi birokrasi, henteu! Abdi hoyong nganggo kecap "perusahaan" di dieu dina kontéks yén unggal perusahaan, unggal produk kedah gaduh standar sorangan, kalebet anjeun. Standar naon anu urang gaduh?

  
  

  • Kami gaduh peraturan panyebaran. Kami henteu ngalih ka mana waé tanpa anjeunna, kami henteu tiasa. Urang nyebarkeun ngeunaan 60 kali saminggu, nyaeta, urang nyebarkeun ampir terus. Dina waktos anu sami, urang gaduh, contona, dina peraturan panyebaran, tabu dina panyebaran dinten Jumaah - prinsipna, urang henteu nyebarkeun.
  • Urang merlukeun dokuméntasi. Henteu aya komponén énggal anu tiasa diproduksi upami teu aya dokuméntasi pikeun éta, sanaos dilahirkeun dina kalam spesialis RnD kami. Urang merlukeun ti aranjeunna parentah deployment, peta ngawaskeun sarta pedaran kasar (ogé, sakumaha programer bisa nulis) kumaha komponén ieu jalan, kumaha carana troubleshoot eta.
  • Urang ngajawab teu ngabalukarkeun masalah, tapi masalah - naon geus I ceuk. Penting pikeun urang ngajagaan pangguna tina masalah.
  • Simkuring gaduh clearances. Contona, urang teu nganggap downtime lamun urang leungit 2% lalulintas dina dua menit. Ieu dasarna teu kaasup dina statistik urang. Lamun leuwih dina istilah persentase atawa samentara, urang geus diitung.
  • Sarta kami salawasna nulis postmortems. Naon waé anu kajantenan ka urang, naon waé kaayaan dimana jalma anu kalakuanana abnormal dina produksi bakal ditingali dina post-mortem. Postmortem mangrupikeun dokumen dimana anjeun nyerat naon anu kajantenan ka anjeun, waktos anu lengkep, naon anu anjeun lakukeun pikeun ngabenerkeunana sareng (ieu mangrupikeun blok wajib!) Naon anu anjeun laksanakeun pikeun nyegah ieu kajadian di hareup. Ieu wajib jeung diperlukeun pikeun analisis saterusna.

  Naon anu dianggap downtime?

  
  
  Naon anu nyababkeun sadayana ieu?

  Ieu nyababkeun kanyataan yén (urang ngagaduhan masalah anu tangtu sareng stabilitas, ieu henteu cocog sareng klien atanapi kami) salami 6 sasih indikator stabilitas kami nyaéta 99,97. Urang bisa disebutkeun yen ieu teu pisan. Sumuhun, urang boga hal pikeun narékahan pikeun. Tina indikator ieu, kira-kira satengahna mangrupikeun stabilitas, sapertos sanés milik urang, tapi tina firewall aplikasi wéb urang, anu nangtung di payuneun urang sareng dianggo salaku jasa, tapi para klien henteu paduli ngeunaan ieu.

  Urang diajar bobo peuting. Tungtungna! Genep bulan ka tukang urang teu bisa. Sareng dina catetan ieu sareng hasilna, abdi hoyong ngadamel hiji catetan. Tadi peuting aya laporan éndah ngeunaan sistem kontrol pikeun reaktor nuklir. Upami jalma-jalma anu nyerat sistem ieu tiasa ngadangukeun kuring, punten hilap naon anu kuring nyarioskeun ngeunaan "2% sanés waktos lirén." Pikeun anjeun, 2% nyaéta downtime, sanajan dua menit!

  Éta hungkul! Patarosan anjeun.

  
  

  Ngeunaan balancers sarta migrasi database

  Pananya ti hadirin (saterasna – B): – Wilujeng sonten. Hatur nuhun pisan kanggo laporan admin sapertos kitu! Hiji patarosan pondok ngeunaan balancers Anjeun. Anjeun nyebatkeun yén anjeun gaduh WAF, nyaéta, sakumaha anu kuring ngartos, anjeun nganggo sababaraha jinis pangimbang éksternal ...

  EK: - Henteu, kami nganggo jasa kami salaku pangimbang. Dina hal ieu, WAF sacara éksklusif mangrupikeun alat panyalindungan DDoS pikeun urang.

  Dina: – Dupi anjeun nyebutkeun sababaraha kecap ngeunaan balancers?

  EK: - Sakumaha anu kuring parantos nyarios, ieu mangrupikeun grup server di openresty. Ayeuna kami gaduh 5 grup cadangan anu ngabales sacara éksklusif ... nyaéta, server anu ngajalankeun éksklusif openresty, éta ngan ukur proxy lalu lintas. Sasuai, ngartos sabaraha urang tahan: urang ayeuna boga lalulintas biasa sababaraha ratus megabits. Aranjeunna Cope, aranjeunna ngarasa alus, maranéhna malah teu galur sorangan.

  Dina: – Oge pertanyaan basajan. Ieu mangrupikeun panyebaran Biru / Héjo. Naon anu anjeun lakukeun, contona, kalayan migrasi database?

  EK: - Patarosan alus! Tingali, dina panyebaran Biru / Héjo kami gaduh antrian anu misah pikeun unggal jalur. Hartina, lamun urang ngobrol ngeunaan antrian acara anu dikirimkeun ti worker ka worker, aya antrian misah pikeun garis biru jeung garis héjo. Lamun urang ngobrol ngeunaan database sorangan, urang ngahaja narrowed eta saloba mungkin, mindahkeun sagalana praktis kana antrian; dina database urang ngan nyimpen tumpukan transaksi. Sareng tumpukan transaksi kami sami pikeun sadaya jalur. Kalawan database dina konteks ieu: urang teu ngabagi kana bulao jeung héjo, sabab duanana versi kode kudu nyaho naon anu lumangsung kalawan urus.

  Babaturan, kuring ogé gaduh hadiah sakedik pikeun ngadorong anjeun - buku. Sareng kuring kedah dileler pikeun patarosan anu pangsaéna.

  Dina: - Halo. Hatur nuhun kana laporan. Patarosan ieu. Anjeun ngawas pamayaran, anjeun ngawas jasa anu anjeun komunikasikeun... Tapi kumaha anjeun ngawas supados jalma kumaha waé sumping ka halaman pamayaran anjeun, ngadamel pamayaran, sareng proyék éta dikreditkeun ku artos? Nyaeta, kumaha anjeun ngawas yén marchant geus sadia tur geus narima callback anjeun?

  EK: - "Sudagar" pikeun urang dina hal ieu persis layanan éksternal sarua salaku sistem pembayaran. Urang ngawas laju respon padagang urang.

  Ngeunaan enkripsi database

  Dina: - Halo. Kuring boga patarosan rada patali. Anjeun gaduh data sénsitip PCI DSS. Abdi hoyong terang kumaha anjeun nyimpen PAN dina antrian anu anjeun kedah transfer? Naha anjeun nganggo énkripsi naon waé? Sarta ieu ngabalukarkeun sual kadua: nurutkeun PCI DSS, perlu périodik ulang encrypt database bisi aya parobahan (pemecatan pangurus, jsb) - naon anu lumangsung nepi ka aksés dina hal ieu?

  
  
  EK: - Patarosan éndah! Anu mimiti, urang henteu nyimpen PAN dina antrian. Kami henteu ngagaduhan hak pikeun nyimpen PAN di mana waé dina bentuk anu jelas, prinsipna mah, janten kami nganggo jasa khusus (urang nyebatna "Kademon") - ieu mangrupikeun jasa anu ngan ukur ngalakukeun hiji hal: nampi pesen salaku input sareng ngirim. kaluar pesen énkripsi. Sareng urang nyimpen sadayana kalayan pesen énkripsi ieu. Sasuai, panjang konci kami sahandapeun kilobyte, ku kituna ieu serius tur dipercaya.

  Dina: – Naha anjeun peryogi 2 kilobyte ayeuna?

  EK: – Sigana mah kakara kamari 256... Tah, mana deui?!

  Sasuai, ieu kahiji. Sareng kadua, solusi anu aya, éta ngadukung prosedur énkripsi ulang - aya dua pasang "keks" (konci), anu masihan "decks" anu énkripsi (konci mangrupikeun konci, dek mangrupikeun turunan tina konci anu énkripsi) . Tur upami prosedur ieu ngagagas (eta kajadian rutin, ti 3 bulan ka ± sababaraha), urang undeur pasangan anyar "muih", sarta kami ulang encrypt data. Kami ngagaduhan jasa anu misah anu nyopot sadaya data sareng énkripsi ku cara anu énggal; Data disimpen di gigireun identifier konci anu énkripsi. Sasuai, pas urang encrypt data ku konci anyar, urang mupus konci heubeul.

  Kadang-kadang pamayaran kedah dilakukeun sacara manual ...

  Dina: - Nyaéta, upami ngabalikeun duit parantos sumping pikeun sababaraha operasi, naha anjeun masih bakal ngadekrip ku konci anu lami?

  EK: - Sumuhun.

  Dina: – Lajeng hiji deui patarosan leutik. Nalika aya sababaraha jenis kagagalan, ragrag, atanapi kajadian, perlu nyorong transaksi sacara manual. Aya kaayaan kitu.

  EK: - Sumuhun, sakapeung.

  Dina: – Dimana anjeun meunang data ieu? Atanapi anjeun angkat ka fasilitas panyimpen ieu nyalira?

  EK: - No, sumur, tangtosna, urang boga sababaraha jenis sistem back-kantor nu ngandung hiji panganteur pikeun rojongan kami. Lamun urang teu nyaho naon status urus dina (Contona, nepi ka sistem pembayaran direspon jeung timeout a), urang teu nyaho apriori, nyaeta, urang napelkeun status ahir ngan jeung kapercayaan pinuh. Dina hal ieu, urang napelkeun urus ka status husus pikeun ngolah manual. Isuk-isuk, isuk-isuk, pas dukungan nampi inpormasi yén transaksi sapertos kitu tetep dina sistem pamayaran, aranjeunna sacara manual ngolah aranjeunna dina antarmuka ieu.

  
  
  Dina: – Kuring boga sababaraha patarosan. Salah sahijina nyaéta tuluyan tina zona PCI DSS: kumaha anjeun log sirkuit maranéhna? Patarosan ieu kusabab pamekar tiasa nempatkeun naon waé dina log! Patarosan kadua: kumaha anjeun gulung kaluar hotfixes? Ngagunakeun handles dina database mangrupa salah sahiji pilihan, tapi meureun aya bebas panas-fixes - naon prosedur aya? Sareng patarosan katilu sigana aya hubunganana sareng RTO, RPO. kasadiaan anjeun éta 99,97, ampir opat nines, Tapi sakumaha Abdi ngartos eta, anjeun boga puseur data kadua, puseur data katilu, sarta puseur data kalima ... Kumaha anjeun nyingkronkeun aranjeunna, ngayakeun réplikasi, sarta sagalana sejenna?

  EK: - Hayu urang mimitian ku nu kahiji. Éta patarosan kahiji ngeunaan log? Nalika urang nyerat log, urang ngagaduhan lapisan anu masker sadaya data sénsitip. Manéhna nempo topéng jeung widang tambahan. Sasuai, log urang kaluar kalawan data geus masked sarta sirkuit PCI DSS. Ieu mangrupikeun salah sahiji tugas rutin anu ditugaskeun ka departemen tés. Éta diwajibkeun pikeun pariksa unggal tugas, kaasup log anu aranjeunna nyerat, sareng ieu mangrupikeun salah sahiji tugas biasa salami ulasan kode, pikeun ngontrol yén pamekar henteu nyerat. Cék salajengna ieu dilaksanakeun sacara rutin ku departemen kaamanan inpormasi ngeunaan saminggu sakali: log pikeun dinten terakhir sacara selektif dicandak sareng aranjeunna dijalankeun ku scanner-analyzer khusus ti server uji pikeun mariksa sadayana.
  Ngeunaan hot-fixes. Ieu kalebet kana peraturan panyebaran urang. Simkuring gaduh klausa misah ngeunaan hotfixes. Simkuring yakin yén urang nyebarkeun hotfixes sabudeureun jam nalika urang peryogi eta. Pas versi dirakit, pas keur ngajalankeun, pas urang boga artefak, urang boga administrator sistem on tugas dina panggero ti rojongan, sarta anjeunna deploys eta dina momen lamun perlu.

  Ngeunaan "opat salapan". Angka anu ayeuna urang parantos dihontal, sareng urang narékahan pikeun éta di pusat data anu sanés. Ayeuna urang boga puseur data kadua, sarta kami dimimitian jalur antara aranjeunna, sarta masalah réplikasi cross-data puseur sabenerna pertanyaan non-trivial. Kami nyobian ngabéréskeunana dina hiji waktos nganggo cara anu béda: kami nyobian nganggo "Tarantula" anu sami - éta henteu hasil pikeun kami, kuring bakal langsung nyarioskeun ka anjeun. Éta sababna urang tungtungna mesen "sens" sacara manual. Kanyataanna, unggal aplikasi dina sistem urang ngajalankeun perlu "robah - rengse" sinkronisasi antara puseur data asynchronously.

  Dina: - Upami anjeun ngagaduhan anu kadua, naha anjeun henteu nampi anu katilu? Kusabab teu acan aya anu gaduh otak pamisah ...

  EK: - Tapi urang teu boga Split Brain. Alatan kanyataan yén unggal aplikasi disetir ku multimaster a, henteu masalah keur urang nu puseur pamundut sumping ka. Kami siap kanyataan yén lamun salah sahiji puseur data urang gagal (urang ngandelkeun ieu) jeung di tengah hiji pamundut pamaké pindah ka puseur data kadua, kami siap leungit pamaké ieu, saleresna; tapi ieu bakal unit, unit mutlak.

  Dina: - Wilujeng sonten. Hatur nuhun kana laporan. Anjeun ngobrol ngeunaan debugger anjeun, anu ngajalankeun sababaraha transaksi tés dina produksi. Tapi ngabejaan urang ngeunaan transaksi test! Sabaraha jerona?

  EK: – Ieu ngaliwatan siklus pinuh ku sakabéh komponén. Pikeun komponén, teu aya bédana antara transaksi tés sareng produksi. Tapi tina sudut pandang logis, ieu ngan saukur proyék anu misah dina sistem, anu ngan ukur transaksi tés dijalankeun.

  Dina: - Dimana anjeun motong éta? Di dieu Core dikirim ...

  EK: – Kami balik "Kor" dina hal ieu keur transaksi test ... Simkuring boga hal kayaning routing: "Kor" weruh nu sistem pembayaran ngirim ka - urang ngirim ka sistem pembayaran palsu, nu saukur méré sinyal http sarta éta hungkul.

  Dina: - Punten wartosan kuring, naha aplikasi anjeun ditulis dina hiji monolith anu ageung, atanapi anjeun motong kana sababaraha jasa atanapi bahkan jasa mikro?

  EK: - Urang teu boga monolith a, tangtosna, urang boga aplikasi berorientasi jasa. Urang lulucon yén jasa kami dijieunna tina monoliths - aranjeunna bener rada badag. Hésé nyebatna microservices, tapi ieu mangrupikeun jasa dimana pagawé mesin anu disebarkeun beroperasi.

  Upami jasa dina server dikompromi...

  Dina: – Lajeng abdi gaduh patarosan salajengna. Sanaos éta monolit, anjeun tetep nyarios yén anjeun gaduh seueur server instan ieu, aranjeunna sadayana dasarna ngolah data, sareng patarosanna: "Upami kompromi salah sahiji server instan atanapi aplikasi, tautan individu mana waé. , Naha aranjeunna gaduh sababaraha jinis kontrol aksés? Nu di antarana bisa ngalakukeun naon? Saha anu kuring kedah ngahubungi kanggo inpormasi naon?

  
  
  EK: - Sumuhun, pasti. Sarat kaamanan anu cukup serius. Anu mimiti, urang gaduh gerakan data anu kabuka, sareng palabuhan ngan ukur anu ngalangkungan anu urang antisipasi gerakan lalu lintas sateuacanna. Upami komponén komunikasi sareng pangkalan data (sebutkeun, sareng Muskul) ngalangkungan 5-4-3-2, ngan 5-4-3-2 bakal dibuka, sareng palabuhan sanés sareng arah lalu lintas sanés moal sayogi. Salaku tambahan, anjeun kedah ngartos yén dina produksi urang aya sakitar 10 puteran kaamanan anu béda. Komo lamun aplikasi ieu kumaha bae compromised, Allah nyaram, lawan moal bisa ngakses konsol manajemén server, sabab ieu zona kaamanan jaringan béda.

  Dina: - Sareng dina kontéks ieu, anu langkung narik pikeun kuring nyaéta yén anjeun gaduh kontrak anu tangtu sareng jasa - naon anu aranjeunna tiasa laksanakeun, ngalangkungan naon "lampah" aranjeunna tiasa ngahubungi silih... Sareng dina aliran normal, sababaraha jasa khusus nyuhunkeun sababaraha baris, daptar "aksi" dina sejenna. Aranjeunna sigana henteu kéngingkeun batur dina kaayaan normal, sareng aranjeunna ngagaduhan tanggung jawab anu sanés. Upami salah sahijina dikompromi, naha éta tiasa ngaganggu "tindakan" jasa éta?..

  EK: - Abdi ngartos. Lamun dina kaayaan normal jeung komunikasi server sejen ieu diwenangkeun pisan, lajeng enya. Numutkeun kontrak SLA, urang teu ngawas yén anjeun ngan diwenangkeun kahiji 3 "aksi", jeung anjeun teu diwenangkeun dina 4 "aksi". Ieu sigana kaleuleuwihan pikeun urang, sabab urang geus boga sistem panyalindungan 4-tingkat, prinsipna mah, pikeun sirkuit. Kami langkung milih ngabela diri kalayan kontur, tinimbang dina tingkat jero.

  Kumaha Visa, MasterCard jeung Sberbank jalan

  Dina: - Abdi hoyong netelakeun hiji titik ngeunaan pindah pamaké ti hiji puseur data ka nu sejen. Sajauh kuring terang, Visa sareng MasterCard beroperasi nganggo protokol sinkron binér 8583, sareng aya campuran. Sareng kuring hoyong terang, ayeuna urang hartosna gentos - éta langsung "Visa" sareng "MasterCard" atanapi sateuacan sistem pamayaran, sateuacan ngolah?

  EK: - Ieu saméméh mixes. Campuran kami aya di pusat data anu sami.

  Dina: – Sacara kasar, anjeun gaduh hiji titik sambungan?

  EK: - "Visa" sareng "MasterCard" - leres. Kantun sabab Visa na MasterCard merlukeun investasi rada serius dina infrastruktur pikeun nyimpulkeun kontrak misah pikeun ménta pasangan kadua mixes, contona,. Aranjeunna ditangtayungan dina hiji puseur data, tapi lamun, Allah nyaram, puseur data urang, dimana aya mixes pikeun nyambungkeun ka Visa na MasterCard, maot, lajeng urang bakal boga sambungan kalawan Visa na MasterCard leungit ...

  Dina: – Kumaha maranéhanana bisa ditangtayungan? Kuring nyaho yén Visa ngamungkinkeun ngan hiji sambungan prinsipna!

  EK: – Aranjeunna nyadiakeun parabot sorangan. Dina sagala hal, kami nampi alat anu pinuh kaleuleuwihan di jero.

  Dina: – Jadi nangtung téh ti maranéhanana Connects Oranyeu?..

  EK: - Sumuhun.

  Dina: - Tapi kumaha upami hal ieu: upami pusat data anjeun ngaleungit, kumaha anjeun tiasa teras-terasan ngagunakeunana? Atawa lalulintas ngan eureun?

  EK: - Henteu. Dina hal ieu, urang ngan saukur bakal ngalihkeun lalu lintas ka saluran anu sanés, anu, sacara alami, bakal langkung mahal pikeun kami sareng langkung mahal pikeun klien kami. Tapi lalulintas moal ngaliwatan sambungan langsung urang ka Visa, MasterCard, tapi ngaliwatan Sberbank kondisional (pisan exaggerated).

  Hapunten pisan upami kuring nyinggung karyawan Sberbank. Tapi nurutkeun statistik urang, diantara bank Rusia, Sberbank ragrag paling sering. Henteu aya sabulan tanpa aya anu ragrag di Sberbank.

  
  
  

  Sababaraha iklan 🙂

  Hatur nuhun pikeun tetep sareng kami. Naha anjeun resep artikel kami? Hoyong ningali eusi anu langkung narik? Dukung kami ku cara nempatkeun pesenan atanapi nyarankeun ka babaturan, cloud VPS pikeun pamekar ti $4.99, analog unik tina server tingkat éntri, anu diciptakeun ku kami pikeun anjeun: Sakabeh bebeneran ngeunaan VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps ti $ 19 atanapi kumaha babagi server a? (sadia kalawan RAID1 na RAID10, nepi ka 24 cores sarta nepi ka 40GB DDR4).

  Dell R730xd 2 kali langkung mirah dina puseur data Equinix nagara golongan IV di Amsterdam? Ngan di dieu 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV ti $199 di Walanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ti $99! Baca ngeunaan Kumaha ngawangun Infrastruktur Corp. kelas kalawan pamakéan Dell R730xd E5-2650 v4 server patut 9000 euro pikeun Penny a?

sumber: www.habr.com