Mindenki beszél a fejlesztési és tesztelési folyamatokról, a személyzet képzéséről, a motiváció növeléséről, de ezek a folyamatok nem elegendőek, ha egy percnyi szervizleállás óriási pénzbe kerül. Mi a teendő, ha szigorú SLA keretében hajt végre pénzügyi tranzakciókat? Hogyan lehet növelni rendszerei megbízhatóságát és hibatűrését, a fejlesztést és a tesztelést kivonva az egyenletből?
A következő HighLoad++ konferenciát 6. április 7-án és 2020-én tartják Szentpéterváron. Részletek és jegyek erre . november 9., 18:00. HighLoad++ Moszkva 2018, Delhi + Kolkata csarnok. Tézisek és .
Jevgenyij Kuzovlev (a továbbiakban – EB): - Barátaim, sziasztok! A nevem Kuzovlev Evgeniy. Az EcommPay cégtől származom, konkrét divízió az EcommPay IT, a cégcsoport informatikai részlege. Ma pedig a leállásokról fogunk beszélni – arról, hogyan kerüljük el őket, hogyan minimalizáljuk a következményeket, ha nem lehet elkerülni. A téma a következő: „Mi a teendő, ha egy perc állásidő 100 000 dollárba kerül”? A jövőre nézve a számaink összehasonlíthatók.
Mit csinál az EcommPay IT?
Kik vagyunk mi? Miért állok itt előtted? Miért van jogom itt elmondani neked valamit? És miről fogunk itt részletesebben beszélni?
Az EcommPay cégcsoport nemzetközi felvásárló. A fizetéseket a világ minden táján dolgozzuk fel - Oroszországban, Európában, Délkelet-Ázsiában (A világ minden táján). 9 irodánk van, összesen 500 dolgozónk van, akiknek hozzávetőlegesen kevesebb, mint fele informatikus. Mindent, amit csinálunk, mindent, amiből pénzt keresünk, magunk csináltuk.
Minden termékünket (és elég sok van belőlük - a nagy informatikai termékeink sorában körülbelül 16 különböző komponens található) magunk írtuk; Önmagunkat írjuk, fejlesztjük magunkat. És jelenleg körülbelül egymillió tranzakciót hajtunk végre naponta (ez valószínűleg a milliók a helyes kifejezés). Meglehetősen fiatal cég vagyunk – még csak körülbelül hat évesek vagyunk.
6 évvel ezelőtt ez egy ilyen startup volt, amikor a srácok együtt jöttek az üzlettel. Ötlet egyesítette őket (nem volt más, csak egy ötlet), és futottunk. Mint minden induló, mi is gyorsabban futottunk... Számunkra a sebesség fontosabb volt, mint a minőség.
Valamikor abbahagytuk: rájöttünk, hogy már valahogy nem tudunk ilyen sebességgel és minőséggel élni, és először a minőségre kell koncentrálnunk. Ebben a pillanatban úgy döntöttünk, hogy új platformot írunk, amely helyes, méretezhető és megbízható. Elkezdték írni ezt a platformot (beruházásba, fejlesztésbe, tesztelésbe kezdtek), de egy ponton rájöttek, hogy a fejlesztés és a tesztelés nem teszi lehetővé, hogy a szolgáltatás minőségének új szintjét elérjük.
Új terméket készítesz, gyártásba helyezed, de valahol mégis elromlik valami. Ma pedig arról fogunk beszélni, hogyan érhetünk el egy új minőségi szintet (hogyan csináltuk, tapasztalatainkról), a fejlesztést és a tesztelést kiemelve az egyenletből; beszélni fogunk arról, hogy mi áll rendelkezésre az üzemeltetéshez – milyen működésre képes önmagát, mit tud nyújtani a tesztelésnek a minőség befolyásolása érdekében.
Leállások. Működési parancsok.
Mindig a fő sarokkő, amiről ma valójában beszélni fogunk, az az állásidő. Szörnyű szó. Ha leállásunk van, minden rossz nekünk. Futunk, hogy emeljük, az adminok tartják a szervert - Isten ments, hogy ne essen le, ahogy abban a dalban mondják. Erről fogunk ma beszélni.
Amikor elkezdtük megváltoztatni a megközelítésünket, 4 parancsolatot alkottunk. Bemutatom őket a diákon:
Ezek a parancsolatok meglehetősen egyszerűek:
- Gyorsan azonosítsa a problémát.
- Még gyorsabban szabadulj meg tőle.
- Segítsen megérteni az okot (később a fejlesztőknek).
- És szabványosítsa a megközelítéseket.
Felhívnám a figyelmet a 2. pontra. Megszabadulunk a problémától, nem oldjuk meg. A döntés másodlagos. Számunkra az elsődleges, hogy a felhasználó védve legyen ettől a problémától. Valamilyen elszigetelt környezetben fog létezni, de ez a környezet nem érintkezik vele. Tulajdonképpen ezt a négy problémacsoportot fogjuk végigjárni (hol részletesebben, hol kevésbé), elmondom mit használunk, milyen releváns tapasztalataink vannak a megoldások terén.
Hibaelhárítás: Mikor fordulnak elő, és mit tegyünk ellenük?
De renden kívül kezdjük, a 2. ponttal kezdjük – hogyan lehet gyorsan megszabadulni a problémától? Probléma van – meg kell javítanunk. – Mit tegyünk ez ügyben? - a fő kérdés. És amikor elkezdtünk gondolkodni a probléma megoldásán, kidolgoztunk magunknak néhány követelményt, amelyeket a hibaelhárításnak követnie kell.
E követelmények megfogalmazásához úgy döntöttünk, hogy feltesszük magunknak a kérdést: „Mikor vannak problémáink”? És a problémák, mint kiderült, négy esetben fordulnak elő:
- Hardverhiba.
- A külső szolgáltatások meghiúsultak.
- A szoftver verziójának módosítása (ugyanaz a telepítés).
- Robbanásveszélyes terhelésnövekedés.
Az első kettőről nem fogunk beszélni. A hardver meghibásodása egyszerűen megoldható: mindent meg kell duplikálni. Ha ezek lemezek, akkor a lemezeket RAID-ben kell összeállítani; ha ez egy szerver, akkor a szervert meg kell duplikálni; ha van hálózati infrastruktúrája, akkor biztosítania kell a hálózati infrastruktúra egy második példányát, vagyis el kell fogadnia és sokszorosítsa meg. És ha valami nem sikerül, akkor tartalék áramra kapcsol. Itt nehéz ennél többet mondani.
A második a külső szolgáltatások kudarca. A legtöbb számára a rendszer egyáltalán nem jelent problémát, de nekünk nem. Mivel a fizetéseket feldolgozzuk, egy aggregátor vagyunk, amely a felhasználó (aki megadja a kártyaadatait) és a bankok, fizetési rendszerek (Visa, MasterCard, Mira stb.) között áll. Külső szolgáltatásaink (fizetési rendszerek, bankok) általában kudarcot vallanak. Ezt sem mi, sem Ön (ha van ilyen szolgáltatása) nem tudjuk befolyásolni.
Mit kell ilyenkor tenni? Itt két lehetőség van. Először is, ha teheti, valamilyen módon meg kell másolnia ezt a szolgáltatást. Például, ha tehetjük, egyik szolgáltatásról a másikra helyezzük át a forgalmat: például a Sberbankon keresztül dolgoztak fel kártyákat, a Sberbanknak problémái vannak - a forgalmat [feltételesen] a Raiffeisenhez továbbítjuk. A második, amit tehetünk, hogy nagyon gyorsan észrevesszük a külső szolgáltatások meghibásodását, ezért a válaszadási sebességről a jelentés következő részében fogunk beszélni.
Valójában ebből a négyből kifejezetten a szoftververziók változását tudjuk befolyásolni – olyan intézkedéseket kell tenni, amelyek a helyzet javulásához vezetnek a telepítésekkel és a terhelés robbanásszerű növekedésével összefüggésben. Tulajdonképpen ezt csináltuk. Ismét egy kis megjegyzés...
E négy probléma közül több azonnal megoldódik, ha van felhője. Ha a Microsoft Azhur, Ozone felhőkben tartózkodik, vagy a mi felhőinket használja a Yandex vagy Mail kínálatából, akkor legalább a hardver meghibásodása lesz a probléma, és minden azonnal rendben lesz a hardver meghibásodása esetén.
Kicsit nem mindennapi cég vagyunk. Itt mindenki a „Kubernetekről”, a felhőkről beszél – nálunk nincs sem „Kubernet”, sem felhő. De sok adatközpontban van hardver állványunk, és kénytelenek vagyunk ezen a hardveren élni, kénytelenek vagyunk felelősek mindenért. Ezért ebben az összefüggésben fogunk beszélni. Szóval a problémákról. Az első kettőt kivették a zárójelből.
A szoftver verziójának módosítása. Alapok
Fejlesztőink nem férnek hozzá a termeléshez. Miert van az? Csak arról van szó, hogy PCI DSS-tanúsítvánnyal rendelkezünk, és a fejlesztőinknek egyszerűen nincs joguk belépni a „termékbe”. Ennyi, pont. Egyáltalán. Ezért a fejlesztési felelősség pontosan abban a pillanatban ér véget, amikor a fejlesztés benyújtja a buildet kiadásra.
A második alapunk, ami szintén sokat segít nekünk, az egyedi, dokumentálatlan tudás hiánya. Remélem neked is így lesz. Mert ha ez nem így van, akkor gondjai lesznek. Problémák akkor merülnek fel, ha ez az egyedi, dokumentálatlan tudás nincs jelen a megfelelő időben a megfelelő helyen. Tegyük fel, hogy van egy személy, aki tudja, hogyan kell behelyezni egy adott komponenst – az illető nincs ott, nyaral, vagy beteg – ez van, problémái vannak.
És a harmadik alap, amelyhez eljutottunk. Fájdalmon, véren, könnyeken keresztül jutottunk el hozzá - arra a következtetésre jutottunk, hogy bármelyik buildünk tartalmaz hibákat, még ha hibamentes is. Ezt magunk határoztuk meg: amikor telepítünk valamit, amikor gyártásba helyezünk, akkor hibákat tartalmazó buildet kapunk. Kialakítottuk azokat a követelményeket, amelyeknek rendszerünknek meg kell felelnie.
A szoftververzió módosításának követelményei
Három követelmény van:
- Gyorsan vissza kell állítani a bevetést.
- Minimálisra kell csökkentenünk a sikertelen telepítés hatását.
- És tudnunk kell gyorsan párhuzamosan telepíteni.
Pontosan ebben a sorrendben! Miért? Mert először is egy új verzió üzembe helyezésekor nem a sebesség a fontos, hanem fontos, hogy ha valami elromlik, gyorsan visszaguruljon és minimális hatást érjen el. De ha éles verzióban van egy sor, amelynél kiderül, hogy hiba történt (a hirtelenjében nem történt üzembe helyezés, de hiba van), akkor fontos Önnek a későbbi telepítés sebessége. Mit tettünk, hogy megfeleljünk ezeknek az igényeknek? A következő módszertant alkalmaztuk:
Elég jól ismert, soha nem találtuk fel - ez a kék/zöld telepítés. Ami? Minden kiszolgálócsoporthoz, amelyre az alkalmazásai telepítve vannak, rendelkeznie kell egy másolattal. A másolat „meleg”: nincs rajta forgalom, de ez a forgalom bármikor elküldhető erre a példányra. Ez a példány az előző verziót tartalmazza. Az üzembe helyezéskor pedig a kódot egy inaktív példányra kell kihelyezni. Ezután átállítja a forgalom egy részét (vagy az egészet) az új verzióra. Így ahhoz, hogy a forgalom áramlását a régi verzióról az újra változtassa, csak egy műveletet kell végrehajtania: meg kell változtatnia a kiegyenlítőt az upstreamben, meg kell változtatnia az irányt - egyik felfelé irányuló áramlási irányból a másikba. Ez nagyon kényelmes, és megoldja a gyors váltás és a gyors visszaállítás problémáját.Itt a megoldás a második kérdésre a minimalizálás: a forgalomnak csak egy részét küldheti új sorra, új kódú sorra (legyen ez pl. 2%). És ez a 2% nem 100%! Ha a forgalom 100%-át elvesztette egy sikertelen telepítés miatt, az ijesztő; ha a forgalom 2%-át, az kellemetlen, de nem ijesztő. Ráadásul a felhasználók ezt nagy valószínűséggel észre sem veszik, mert bizonyos esetekben (nem minden esetben) ugyanaz a felhasználó az F5 lenyomásával egy másik, működő verzióba kerül.
Kék/zöld bevetés. útvonalválasztás
Azonban nem minden ilyen egyszerű „Kék/Zöld bevetés”... Minden komponensünk három csoportba osztható:
- ez a frontend (fizetési oldalak, amelyeket ügyfeleink látnak);
- feldolgozó mag;
- adapter fizetési rendszerekkel való munkához (bankok, MasterCard, Visa...).
És van itt egy árnyalat – az árnyalat a sorok közötti útvonalválasztásban rejlik. Ha csak a forgalom 100%-át váltja át, akkor nincs ilyen probléma. De ha 2%-ot szeretne váltani, akkor elkezd kérdéseket feltenni: „Hogyan kell ezt csinálni?” A legegyszerűbb dolog egyenesen előre: véletlenszerű választással beállíthatod a Round Robint az nginxben, és 2% van balra, 98% jobbra. De ez nem mindig megfelelő.
Például esetünkben egy felhasználó egynél több kéréssel lép kapcsolatba a rendszerrel. Ez normális: 2, 3, 4, 5 kérés – előfordulhat, hogy a rendszerei megegyeznek. És ha Önnek fontos, hogy a felhasználó összes kérése ugyanarra a sorra érkezzen, amelyen az első kérés érkezett, vagy (második pont) a felhasználó összes kérése a váltás után az új sorba érkezzen (elkezdhetett volna korábban dolgozni a rendszer, a váltás előtt), - akkor ez a véletlenszerű eloszlás nem megfelelő az Ön számára. Ezután a következő lehetőségek vannak:
Az első lehetőség, a legegyszerűbb, az ügyfél alapvető paraméterein (IP Hash) alapul. Van egy IP-címe, és azt jobbról balra osztja IP-címmel. Akkor neked az általam leírt második eset fog működni, amikor a telepítés megtörtént, a felhasználó már elkezdhetett dolgozni a rendszereddel, és a telepítés pillanatától minden kérés új sorba kerül (mondjuk ugyanarra).Ha ez valamilyen oknál fogva nem felel meg Önnek, és arra a sorra kell kérést küldenie, ahol a felhasználó kezdeti, kezdeti kérése érkezett, akkor két lehetősége van...
Első lehetőség: fizetős nginx+-t vásárolhat. Létezik egy Sticky sessions mechanizmus, amely a felhasználó kezdeti kérésére hozzárendel egy munkamenetet a felhasználóhoz, és egy vagy másik upstreamhez köti. A munkamenet élettartamán belüli összes további felhasználói kérés ugyanarra az upstream címre kerül elküldésre, ahol a munkamenetet közzétették.Ez nem felelt meg nekünk, mert már volt rendes nginxünk. Az nginx+-ra való váltás nem drága, csak azért, mert kissé fájdalmas volt számunkra, és nem túl helyes. A „Sticks Sessions” például nem működött nálunk azon egyszerű oknál fogva, hogy a „Sticks Sessions” nem teszi lehetővé a „Vagy-vagy” alapú útválasztást. Itt megadhatja, hogy a „Sticks Sessions” mit csináljunk, például IP-cím vagy IP-cím és cookie-k vagy utóparaméterek alapján, de az „Vagy-vagy” itt bonyolultabb.
Ezért a negyedik lehetőséghez jutottunk. Az nginx-et szteroidokon vettük (ez az openresty) - ez ugyanaz az nginx, amely emellett támogatja az utolsó szkriptek felvételét. Írhat egy utolsó szkriptet, adhat neki egy „nyílt pihenőt”, és ez az utolsó szkript végrehajtásra kerül, amikor megérkezik a felhasználói kérés.
És tulajdonképpen egy ilyen szkriptet írtunk, beállítottuk magunknak az „openresti”-t, és ebben a szkriptben 6 különböző paramétert rendezünk az „Or” összefűzés alapján. Egyik vagy másik paraméter meglététől függően tudjuk, hogy a felhasználó egy vagy másik oldalra, egy vagy másik sorra érkezett.
Kék/zöld bevetés. Előnyök és hátrányok
Persze valószínűleg lehetett egy kicsit egyszerűbbé tenni (ugyanazt a „Sticky Sessions”-t használjuk), de van egy olyan árnyalatunk is, hogy nem csak a felhasználó lép kapcsolatba velünk egy tranzakció egy feldolgozása keretein belül... De a fizetési rendszerek is kapcsolatba lépnek velünk: A tranzakció feldolgozása után (a fizetési rendszer felé kéréssel) visszajelzést kapunk.
És mondjuk, ha az áramkörünkön belül minden kérésben továbbíthatjuk a felhasználó IP-címét, és az IP-cím alapján oszthatjuk fel a felhasználókat, akkor nem ugyanazt a „Visát” mondjuk: „Haver, mi egy ilyen retro cég vagyunk, úgy tűnik hogy nemzetközi legyen (a weboldalon és Oroszországban)... Kérjük, egy további mezőben adja meg a felhasználó IP-címét, protokollja szabványos”! Egyértelmű, hogy nem fognak egyetérteni.
Ezért ez nem működött nekünk – nyitottunk. Ennek megfelelően az útválasztással valami ilyesmit kaptunk:A kék/zöld telepítés ennek megfelelően rendelkezik az általam említett előnyökkel és hátrányokkal.
Két hátránya:
- bajlódnia kell az útválasztással;
- a második fő hátrány a költség.
Kétszer annyi szerverre van szüksége, kétszer annyi működési erőforrásra van szüksége, kétszer annyi erőfeszítést kell költenie az egész állatkert fenntartására.
Egyébként az előnyök között van még egy dolog, amit korábban nem említettem: van tartalékod terhelésnövekedés esetére. Ha robbanásszerűen növekszik a terhelés, sok a felhasználó, akkor egyszerűen beilleszti a második sort az 50–50-es disztribúcióba – és azonnal x2 szerverek lesznek a fürtben, amíg meg nem oldja a több szerverrel kapcsolatos problémát.
Hogyan lehet gyorsan telepíteni?
Beszéltünk arról, hogyan lehet megoldani a minimalizálás és a gyors visszaállítás problémáját, de a kérdés továbbra is fennáll: „Hogyan telepítsünk gyorsan?”
Itt rövid és egyszerű.- Rendelkeznie kell CD-rendszerrel (folyamatos kézbesítés) – nem tud nélküle élni. Ha egy szerverrel rendelkezik, manuálisan telepítheti. Körülbelül másfél ezer szerverünk és másfél ezer kilincsünk van természetesen – egy ekkora részleget is telepíthetünk, mint a telepítés.
- A telepítésnek párhuzamosnak kell lennie. Ha a telepítés szekvenciális, akkor minden rossz. Egy szerver normális, egész nap másfél ezer szervert fog telepíteni.
- Ismétlem, a gyorsításhoz ez valószínűleg már nem szükséges. A telepítés során a projekt általában megépül. Van egy webprojekted, van egy front-end rész (ott csinálsz egy webcsomagot, lefordítod az npm-et - valami ilyesmi), és ez a folyamat elvileg rövid életű - 5 perc, de ez az 5 perc legyen kritikus. Ezért például nem tesszük ezt: eltávolítottuk ezt az 5 percet, és telepítettük a műtermékeket.
Mi az a műtárgy? A műtárgy olyan összeszerelt összeállítás, amelyben az összes összeszerelési alkatrész már elkészült. Ezt a műterméket a műterméktárolóban tároljuk. Valamikor két ilyen tárolót használtunk – ez volt a Nexus, most pedig a jFrog Artifactory. Kezdetben a „Nexust” használtuk, mert elkezdtük gyakorolni ezt a megközelítést a java alkalmazásokban (jól megfelelt neki). Aztán beraktak néhány PHP-ben írt alkalmazást oda; és a „Nexus” már nem volt megfelelő, ezért a jFrog Artefactory-t választottuk, amely szinte mindent képes artifakálni. Eljutottunk odáig, hogy ebben a műterméktárban a saját bináris csomagjainkat tároljuk, amelyeket a szerverek számára gyűjtünk.
Robbanásveszélyes terhelésnövekedés
Beszéltünk a szoftververzió megváltoztatásáról. A következő dolog a terhelés robbanásszerű növekedése. Itt valószínűleg a terhelés robbanásszerű növekedése alatt nem egészen helyes dolgot értem...
Új rendszert írtunk - szolgáltatásorientált, divatos, szép, mindenhol dolgozók, mindenhol sorok, mindenhol aszinkron. És az ilyen rendszerekben az adatok különböző áramlásokon keresztül áramolhatnak. Az első tranzakcióhoz az 1., 3., 10. munkavállaló használható, a második tranzakcióhoz - a 2., 4., 5. És ma, mondjuk, reggel van egy adatfolyam, amely az első három dolgozót használja, este pedig drámaian megváltozik, és minden a másik három dolgozót használja.
És itt kiderül, hogy valahogyan bővíteni kell a dolgozókat, valahogy bővíteni kell a szolgáltatásokat, ugyanakkor meg kell akadályozni az erőforrások felduzzadását.
Meghatároztuk követelményeinket. Ezek a követelmények meglehetősen egyszerűek: legyen szolgáltatás felfedezés, paraméterezés - minden szabvány az ilyen skálázható rendszerek felépítéséhez, egy pont kivételével - erőforrás amortizáció. Azt mondtuk, hogy nem állunk készen az erőforrások amortizálására, hogy a szerverek melegítsék a levegőt. Elvettük a „Consul”-t, a „Nomádot”, amely a munkásainkat kezeli.Miért jelent ez problémát nekünk? Hátráljunk egy kicsit. Jelenleg mintegy 70 fizetési rendszer áll mögöttünk. Reggel a Sberbankon keresztül megy a forgalom, majd a Sberbank például bukott, és átállítjuk egy másik fizetési rendszerre. A Sberbank előtt 100 dolgozónk volt, utána pedig egy másik fizetési rendszerhez drasztikusan növelnünk kell a 100 dolgozót. És kívánatos, hogy mindez emberi részvétel nélkül történjen. Mert ha van emberi részvétel, akkor 24/7 mérnök üljön, aki csak ezt csinálja, mert az ilyen meghibásodások, amikor 70 rendszer van mögötte, rendszeresen előfordulnak.
Ezért megnéztük a nyitott IP-vel rendelkező Nomad-ot, és megírtuk a saját dolgunkat, a Scale-Nomad - ScaleNo-t, ami megközelítőleg a következőt teszi: figyeli a sor növekedését és a dinamikától függően csökkenti vagy növeli a dolgozók számát. a sorból. Amikor megcsináltuk, arra gondoltunk: "Talán megnyithatnánk a forráskódot?" Aztán ránéztek – olyan egyszerű volt, mint két kopejka.
Eddig még nem nyílt forráskódú, de ha a bejelentés után hirtelen, miután rájött, hogy ilyenre van szüksége, szüksége van rá, akkor az utolsó dián vannak az elérhetőségeim - kérem írjon nekem. Ha legalább 3-5 fő lesz, akkor szponzoráljuk.
Hogyan működik? Nézzük meg! Előretekintve: bal oldalon a monitorozásunk egy darabja: ez egy sor, felül az eseményfeldolgozás ideje, középen a tranzakciók száma, alul a dolgozók száma.Ha megnézed, van egy hiba a képen. A felső grafikonon az egyik grafikon 45 másodperc alatt összeomlott – az egyik fizetési rendszer leállt. Azonnal 2 perc alatt behozták a forgalmat, és a sor növekedni kezdett egy másik fizetési rendszeren, ahol nem voltak dolgozók (nem használtuk fel az erőforrásokat - ellenkezőleg, helyesen ártalmatlanítottuk az erőforrást). Nem akartunk fűteni - minimális létszám volt, körülbelül 5-10 munkás, de nem tudtak megbirkózni.
Az utolsó grafikonon egy „púp” látható, ami csak azt jelenti, hogy „Skaleno” megduplázta ezt az összeget. Aztán amikor a grafikon kissé leesett, egy kicsit csökkentette – a dolgozók száma automatikusan megváltozott. Ez a dolog így működik. A 2-es pontról beszéltünk – „Hogyan lehet gyorsan megszabadulni az okoktól.”
Monitoring. Hogyan lehet gyorsan azonosítani a problémát?
Most az első pont a „Hogyan lehet gyorsan azonosítani a problémát?” Monitoring! Bizonyos dolgokat gyorsan meg kell értenünk. Milyen dolgokat kell gyorsan megértenünk?
Három dolog!- Gyorsan meg kell értenünk és meg kell értenünk saját erőforrásaink teljesítményét.
- Gyorsan meg kell értenünk a hibákat, és figyelemmel kell kísérnünk a rajtunk kívül álló rendszerek teljesítményét.
- A harmadik pont a logikai hibák azonosítása. Ilyenkor neked működik a rendszer, minden mutató szerint minden normális, de valami elromlik.
Valószínűleg nem mondok itt semmi olyan jót. Én leszek nyilvánvaló kapitány. Megnéztük, mi van a piacon. Van egy „mulatságos állatkertünk”. Nálunk most ilyen állatkert van:
Hardverfigyelésre, a szerverek főbb mutatóinak figyelésére Zabbixot használunk. Adatbázisokhoz az Okmetert használjuk. A „Grafana”-t és a „Prometheus”-t használjuk az összes többi mutatóhoz, amelyek nem illenek az első kettőhöz, egyesek „Grafana” és „Prometheus”, illetve „Grafana” az „Influx” és a Telegraf.Egy éve szerettük volna használni a New Relic-et. Klassz dolog, mindenre képes. De amennyire mindenre képes, olyan drága. Amikor 1,5 ezer szerverre nőttünk, odajött hozzánk egy eladó, és azt mondta: Kössünk megállapodást a következő évre. Megnéztük az árat, és azt mondtuk, hogy nem, ezt nem tesszük. Most elhagyjuk a New Relic-et, körülbelül 15 szerverünk maradt a New Relic felügyelete alatt. Az ár teljesen vadnak bizonyult.
És van egy eszköz, amelyet magunk implementáltunk – ez a Debugger. Eleinte „Bagger”-nek hívtuk, de aztán egy angoltanár elhaladt mellette, vadul nevetett, és átnevezte „Debagger”-nek. Ami? Ez egy olyan eszköz, amely valójában 15-30 másodperc alatt minden egyes komponensen, mint a rendszer „fekete doboza”, lefuttatja az összetevő általános teljesítményét.
Például, ha van egy külső oldal (fizetési oldal), egyszerűen megnyitja, és megnézi, hogyan kell kinéznie. Ha ez feldolgozás alatt áll, akkor teszt „tranzakciót” küld, és gondoskodik arról, hogy ez a „tranzakció” megérkezzen. Ha ez a fizetési rendszerekkel való kapcsolat, akkor ennek megfelelően indítunk el egy tesztkérést, ahol tudunk, és megnézzük, hogy minden rendben van-e velünk.
Milyen mutatók fontosak a monitorozáshoz?
Mire figyelünk elsősorban? Milyen mutatók fontosak számunkra?
- A válaszidő / RPS a frontokon nagyon fontos mutató. Azonnal válaszol, hogy valami nincs rendben veled.
- A feldolgozott üzenetek száma az összes sorban.
- Dolgozók száma.
- Alapvető helyességi mérőszámok.
Az utolsó pont az „üzleti”, „üzleti” mérőszám. Ha ugyanazt szeretné figyelni, meg kell határoznia egy vagy két mérőszámot, amelyek a fő mutatók az Ön számára. A mérőszámunk az áteresztőképesség (ez a sikeres tranzakciók számának a teljes tranzakciós áramláshoz viszonyított aránya). Ha 5-10-15 perces időközönként változik benne valami, az azt jelenti, hogy problémáink vannak (ha gyökeresen megváltozik).
Hogy néz ki számunkra, az az egyik táblánk példája:
A bal oldalon 6 grafikon található, a sorok szerint - a dolgozók száma és a sorokban lévő üzenetek száma. A jobb oldalon - RPS, RTS. Az alábbiakban ugyanaz az „üzleti” mutató látható. Az „üzleti” mérőszámban pedig rögtön láthatjuk, hogy a két középső grafikonon valami elromlott... Ez csak egy újabb rendszer, ami mögöttünk áll, és leesett.A második, amit tennünk kellett, az volt, hogy figyelemmel kísérjük a külső fizetési rendszerek bukását. Itt vettük az OpenTracinget – egy olyan szabványos, paradigmát, amely lehetővé teszi az elosztott rendszerek nyomon követését; és egy kicsit megváltozott. A standard OpenTracing paradigma azt mondja, hogy minden egyes kérelemhez nyomkövetést készítünk. Erre nem volt szükségünk, és egy összefoglaló, összesítő nyomba csomagoltuk. Készítettünk egy eszközt, amellyel nyomon követhetjük a mögöttünk lévő rendszerek sebességét.
A grafikon azt mutatja, hogy az egyik fizetési rendszer 3 másodpercen belül válaszolni kezdett - problémáink vannak. Sőt, ez a dolog 20-30 másodperces időközönként reagál a problémák kezdetére.A megfigyelési hibák harmadik osztálya pedig a logikai megfigyelés.
Őszintén szólva nem tudtam, mit rajzoljak erre a diára, mert régóta kerestük a piacon azt, ami megfelelne nekünk. Nem találtunk semmit, így magunknak kellett megcsinálnunk.
Mit értek logikai megfigyelés alatt? Nos, képzeld el: csinálsz magadnak egy rendszert (például egy Tinder klónt); megcsináltad, elindítottad. A sikeres menedzser, Vasya Pupkin feltette a telefonjára, meglát ott egy lányt, megkedveli... és a hasonló nem jár a lánynak - a hasonló pedig ugyanabból az üzletközpontból, Mikhalych biztonsági őrhöz érkezik. A menedzser lemegy a lépcsőn, majd csodálkozik: „Miért mosolyog rá ilyen kellemesen ez a biztonsági őr Mihalic?”Ilyen helyzetekben... Nálunk ez a szituáció kicsit másképp hangzik, mert (írtam) ez egy hírnévvesztés, ami közvetve anyagi veszteségekhez vezet. Nálunk a helyzet fordított: közvetlen anyagi veszteségeket szenvedhetünk el - például ha sikeresen bonyolítottunk le egy tranzakciót, de az sikertelen volt (vagy fordítva). Meg kellett írnom egy saját eszközt, amely üzleti mutatók segítségével követi nyomon a sikeres tranzakciók számát az idő múlásával. Nem találtam semmit a piacon! Pontosan ezt az ötletet szerettem volna átadni. A piacon semmi sem oldja meg ezt a fajta problémát.
Ez arról szólt, hogyan lehet gyorsan azonosítani a problémát.
Hogyan lehet meghatározni a telepítés okait
A harmadik problémacsoport, amit megoldunk, miután azonosítottuk a problémát, miután megszabadultunk tőle, jó lenne megérteni a fejlesztés, a tesztelés okát, és tenni ellene. Ennek megfelelően ki kell vizsgálnunk, fel kell emelnünk a rönköket.
Ha a rönkökről beszélünk (a fő ok a rönk), akkor a rönkeink nagy része az ELK Stack-ben található - szinte mindenkinek ugyanaz van. Lehet, hogy egyeseknek nincs ELK-ban, de ha gigabyte-ban írod a naplókat, akkor előbb-utóbb eljön az ELK. Terabájtban írjuk őket.
Van itt egy probléma. Kijavítottuk, kijavítottuk a hibát a felhasználónak, elkezdtük kiásni, hogy mi van, bemásztunk a Kibanába, ott beírtuk a tranzakciós azonosítót és kaptunk egy ilyen lábtörlőt (sokat mutat). És ebben a lábtörlőben semmi sem világos. Miért? Igen, mert nem világos, hogy melyik rész melyik dolgozóhoz, melyik rész melyik komponenshez tartozik. És abban a pillanatban rájöttünk, hogy nyomkövetésre van szükségünk – ugyanaz az OpenTracing, amiről beszéltem.Egy éve ezt gondoltuk, figyelmünket a piac felé fordítottuk, és ott két eszköz volt: a „Zipkin” és a „Jaeger”. „Jager” valójában egy ilyen ideológiai örökös, „Zipkin” ideológiai utódja. A Zipkinben minden jó, kivéve azt, hogy nem tudja, hogyan kell összesíteni, nem tudja, hogyan kell bevenni a naplókat a nyomkövetésbe, csak az időnyomot. És „Jager” támogatta ezt.
Megnéztük a „Jagert”: lehet alkalmazásokat műszerezni, lehet Api-ban írni (a PHP akkori Api szabványát azonban nem hagyták jóvá - ez egy éve volt, de most már jóváhagyták), de ott egyáltalán nem volt ügyfél. „Rendben” – gondoltuk, és írtunk saját ügyfelünknek. Mit kaptunk? Nagyjából így néz ki:
A Jaegerben minden üzenethez span jön létre. Azaz, amikor egy felhasználó megnyitja a rendszert, minden bejövő kéréshez egy vagy két blokkot lát (1-2-3 - a felhasználótól érkező kérések száma, blokkok száma). A felhasználók megkönnyítése érdekében címkéket adtunk a naplókhoz és az időkövetéshez. Ennek megfelelően alkalmazásunk hiba esetén a megfelelő Error címkével jelöli meg a naplót. Hibacímke szerint szűrhet, és csak azok a szakaszok jelennek meg, amelyek ezt a hibás blokkot tartalmazzák. Így néz ki, ha kiterjesztjük a tartományt:
A fesztávon belül egy sor nyom található. Ebben az esetben ez három tesztnyom, a harmadik pedig azt jelzi, hogy hiba történt. Ugyanakkor itt egy időnyomot látunk: felül van egy időskálánk, és azt látjuk, hogy ez vagy az a napló milyen időintervallumban került rögzítésre.Ennek megfelelően nálunk jól alakultak a dolgok. Saját kiterjesztést írtunk, és nyílt forráskódú. Ha nyomkövetéssel akarsz dolgozni, ha a „Jagerrel” akarsz dolgozni PHP-ben, akkor ott van a bővítményünk, szívesen használod, ahogy mondják:
Megvan ez a bővítmény - ez az OpenTracing Api kliense, php-kiterjesztésként készült, vagyis össze kell szerelnie és telepítenie kell a rendszerre. Egy évvel ezelőtt semmi más nem volt. Most vannak más ügyfelek, amelyek olyanok, mint a komponensek. Itt csak rajtad múlik: vagy kipumpálod a komponenseket egy zeneszerzővel, vagy használod a kiterjesztést.Vállalati szabványok
A három parancsolatról beszélgettünk. A negyedik parancsolat a megközelítések egységesítése. Ez miről szól? Erről van szó:
Miért van itt a „vállalati” szó? Nem azért, mert nagy vagy bürokratikus cég vagyunk, nem! A „vállalati” szót itt abban az összefüggésben szerettem volna használni, hogy minden cégnek, minden terméknek saját szabványa legyen, beleértve Önt is. Milyen szabványaink vannak?
- Vannak telepítési szabályzataink. Nem mozdulunk nélküle sehova, nem is tudunk. Hetente körülbelül 60 alkalommal, azaz szinte folyamatosan telepítünk. Ugyanakkor például a bevetési szabályzatban a pénteki bevetésekre tabutírunk - elvileg nem telepítünk.
- Dokumentációt kérünk. Egyetlen új alkatrész sem kerül gyártásba, ha nincs hozzá dokumentáció, még akkor sem, ha az RnD szakembereink tolla alatt született. Kérünk tőlük telepítési utasításokat, felügyeleti térképet és hozzávetőleges leírást (na jó, ahogy a programozók írják), hogy hogyan működik ez a komponens, hogyan lehet hibaelhárítást végezni.
- Nem a probléma okát oldjuk meg, hanem a problémát – amit már mondtam. Fontos számunkra, hogy megvédjük a felhasználót a problémáktól.
- Vannak engedélyeink. Például nem tekintjük leállásnak, ha két percen belül a forgalom 2%-át elveszítjük. Ez alapvetően nem szerepel a statisztikánkban. Ha inkább százalékos vagy ideiglenes, akkor már számolunk.
- És mindig postmortemeket írunk. Bármi is történik velünk, minden olyan helyzet, amikor valaki abnormálisan viselkedett a gyártás során, visszatükröződik az utókorban. A postmortem egy olyan dokumentum, amelyben leírod, hogy mi történt veled, részletes időzítést, mit tettél a javítás érdekében, és (ez egy kötelező blokk!) mit fogsz tenni, hogy ez a jövőben ne fordulhasson elő. Ez kötelező és szükséges a későbbi elemzéshez.
Mi számít leállásnak?
Mihez vezetett mindez?Ez oda vezetett, hogy (bizonyos stabilitási problémáink voltak, ez sem ügyfeleinknek, sem nekünk nem tetszett) az elmúlt 6 hónapban 99,97 volt a stabilitási mutatónk. Mondhatjuk, hogy ez nem túl sok. Igen, van mire törekednünk. Ennek a mutatónak körülbelül a fele a stabilitás, mondjuk nem a miénk, hanem az előttünk álló, szolgáltatásként használt webalkalmazásunk tűzfalának a stabilitása, de az ügyfeleket ez nem érdekli.
Megtanultunk éjszaka aludni. Végül! Hat hónappal ezelőtt nem tudtuk. És ehhez az eredményhez kapcsolódó megjegyzéshez szeretnék egy megjegyzést tenni. Tegnap este csodálatos jelentés érkezett egy atomreaktor vezérlőrendszeréről. Ha az emberek, akik ezt a rendszert írták, hallanak, kérem, felejtse el, amit mondtam, hogy „a 2% nem leállás”. Neked 2% az állásidő, még ha két percre is!
Ez minden! A kérdéseid.
A kiegyensúlyozókról és az adatbázis-migrációról
A hallgatóság kérdése (továbbiakban – B): – Jó estét. Nagyon köszönöm az ilyen adminisztrációs jelentést! Egy rövid kérdés az egyensúlyozóidról. Említetted, hogy WAF-od van, vagyis ha jól értem valami külső egyensúlyozót használsz...
EK: – Nem, szolgáltatásainkat kiegyensúlyozóként használjuk. Ebben az esetben a WAF kizárólag egy DDoS védelmi eszköz számunkra.
BAN BEN: – Mondana néhány szót az egyensúlyozókról?
EK: – Ahogy már mondtam, ez egy nyílt rendszerű szervercsoport. Most már van 5 tartalék csoportunk, ami kizárólagosan válaszol... vagyis egy szerver, ami kizárólag openresty-t futtat, csak a forgalmat proxyzza. Ennek megfelelően, hogy megértsük, mennyit tartunk: immár több száz megabites rendszeres forgalommal rendelkezünk. Megbirkóznak, jól érzik magukat, még csak nem is erőltetik magukat.
BAN BEN: – Szintén egyszerű kérdés. Itt a kék/zöld bevetés. Mit csinálsz például az adatbázis-migrációkkal?
EK: - Jó kérdés! Nézze, a kék/zöld telepítésben minden sorhoz külön sor van. Ez azt jelenti, hogy ha olyan eseménysorokról beszélünk, amelyeket a munkástól a dolgozóig továbbítanak, akkor külön sor van a kék és a zöld vonal számára. Ha már magáról az adatbázisról beszélünk, akkor szándékosan leszűkítettük, amennyire csak tudtuk, gyakorlatilag mindent sorokba helyeztünk, az adatbázisban csak egy köteg tranzakciót tárolunk. A tranzakciós stackünk pedig minden sornál azonos. Az adatbázissal ebben az összefüggésben: nem osztjuk kékre és zöldre, mert a kód mindkét verziójának tudnia kell, hogy mi történik a tranzakcióval.
Barátaim, van egy kis nyereményem is, amivel buzdítalak benneteket: egy könyvet. És a legjobb kérdésért díjaznám.
BAN BEN: - Helló. Köszönöm a beszámolót. A kérdés ez. Figyelemmel kíséri a kifizetéseket, figyeli a szolgáltatásokat, amelyekkel kommunikál... De hogyan figyelheti meg, hogy valaki valahogyan a fizetési oldalára érkezzen, befizetett, és a projekt jóváírt neki pénzt? Vagyis hogyan figyeli, hogy a marchan elérhető-e, és elfogadta-e a visszahívását?
EK: – A „Kereskedő” számunkra ebben az esetben pontosan ugyanaz a külső szolgáltatás, mint a fizetési rendszer. Figyeljük a kereskedő reakciósebességét.
Az adatbázis titkosításáról
BAN BEN: - Helló. Lenne egy kicsit kapcsolódó kérdésem. Érzékeny PCI DSS adatai vannak. Azt szeretném tudni, hogyan tárolja a PAN-okat olyan sorokban, amelyekbe át kell töltenie? Használsz valamilyen titkosítást? És ez elvezet a második kérdéshez: a PCI DSS szerint változás esetén (adminisztrátorok elbocsátása stb.) időnként újra kell titkosítani az adatbázist - mi történik ebben az esetben az akadálymentesítéssel?
EK: - Csodálatos kérdés! Először is, nem tároljuk a PAN-okat sorokban. Elvileg nincs jogunk a PAN-t bárhol áttekinthető formában tárolni, ezért egy speciális szolgáltatást használunk (úgy hívjuk, hogy „Kademon”) - ez egy olyan szolgáltatás, amely egyetlen dolgot tesz: üzenetet fogad bemenetként és küld. kiad egy titkosított üzenetet. És mindent eltárolunk ezzel a titkosított üzenettel. Ennek megfelelően a kulcsunk egy kilobájt alatt van, tehát ez komoly és megbízható.BAN BEN: – Kell most 2 kilobájt?
EK: – Úgy tűnik, tegnap még 256 volt... Na, hol máshol?!
Ennek megfelelően ez az első. Másodszor, a létező megoldás támogatja az újratitkosítási eljárást - két „keks” (kulcs) pár van, amelyek titkosító „deckeket” adnak (a kulcs a kulcsok, a dek a titkosító kulcsok származékai) . Ha pedig megindul az eljárás (rendszeresen, 3 hónapos kortól ± néhányig megtörténik), letöltünk egy új pár „tortát”, és újratitkosítjuk az adatokat. Külön szolgáltatásaink vannak, amelyek minden adatot kimásolnak és új módon titkosítanak; Az adatok a titkosításhoz használt kulcs azonosítója mellett kerülnek tárolásra. Ennek megfelelően, amint új kulcsokkal titkosítjuk az adatokat, a régi kulcsot töröljük.
Néha manuálisan kell fizetni...
BAN BEN: – Vagyis ha valamilyen műveletre visszatérítés érkezett, akkor is visszafejti a régi kulccsal?
EK: - Igen.
BAN BEN: – Akkor még egy apró kérdés. Ha valamilyen meghibásodás, esés vagy incidens történik, a tranzakciót manuálisan kell végrehajtani. Van ilyen helyzet.
EK: - Igen, néha.
BAN BEN: – Honnan veszi ezeket az adatokat? Vagy te magad jársz ebbe a tárolóba?
EK: – Nem, nos, persze, van valami back-office rendszerünk, amely tartalmaz egy felületet a támogatásunkhoz. Ha nem tudjuk, hogy a tranzakció milyen állapotban van (például amíg a fizetési rendszer nem válaszolt időtúllépéssel), akkor eleve nem tudjuk, vagyis csak teljes bizalommal rendeljük hozzá a végleges állapotot. Ebben az esetben a tranzakciót speciális státuszba rendeljük kézi feldolgozás céljából. Reggel, másnap, amint a support tájékoztatást kap arról, hogy ilyen-olyan tranzakciók a fizetési rendszerben maradnak, ezen a felületen manuálisan feldolgozzák azokat.
BAN BEN: – Lenne pár kérdésem. Az egyik a PCI DSS zóna folytatása: hogyan lehet naplózni az áramkörüket? Ez a kérdés azért van, mert a fejlesztő bármit beírhatott volna a naplóba! Második kérdés: hogyan lehet gyorsjavításokat kihelyezni? Az egyik lehetőség a fogantyúk használata az adatbázisban, de lehetnek ingyenes gyorsjavítások – mi az eljárás? A harmadik kérdés pedig valószínűleg az RTO-val, az RPO-val kapcsolatos. Az Ön elérhetősége 99,97 volt, majdnem négy kilenc, de ha jól értem, van egy második adatközpontja, egy harmadik adatközpontja és egy ötödik adatközpontja... Hogyan lehet ezeket szinkronizálni, replikálni és minden mást?EK: - Kezdjük az elsővel. Az első kérdés a naplókkal kapcsolatos volt? Amikor naplókat írunk, van egy rétegünk, amely elrejti az összes érzékeny adatot. Nézi a maszkot és a további mezőket. Ennek megfelelően a naplóink már maszkolt adatokkal és egy PCI DSS áramkörrel jelennek meg. Ez a tesztelési osztályra háruló rendszeres feladatok egyike. Minden feladatot ellenőrizniük kell, beleértve az általuk írt naplókat is, és ez az egyik rendszeres feladat a kódellenőrzés során, annak ellenőrzésére, hogy a fejlesztő nem írt-e le valamit. Ennek utólagos ellenőrzését az információbiztonsági osztály rendszeresen, körülbelül hetente egyszer elvégzi: az utolsó napra vonatkozó naplókat szelektíven veszik, és a tesztszerverekről egy speciális szkenner-analizátoron futtatják át, hogy mindent ellenőrizzenek.
A gyorsjavításokról. Ezt a telepítési szabályzatunk tartalmazza. Külön záradékunk van a gyorsjavításokról. Úgy gondoljuk, hogy a gyorsjavításokat éjjel-nappal telepítjük, amikor szükségünk van rá. Amint összeállítják a verziót, amint lefut, amint van műtermékünk, egy rendszergazdánk van ügyeletben a support hívására, aki akkor telepíti, amikor szükséges.Körülbelül "négy kilenc". A mostani számot valóban elértük, erre egy másik adatközpontban törekedtünk. Most van egy második adatközpontunk, és elkezdünk közöttük útvonalat vezetni, és az adatközpontok közötti replikáció kérdése valóban nem triviális kérdés. Egyszerre különböző eszközökkel próbáltuk megoldani: megpróbáltuk ugyanazt a „Tarantula”-t használni - nekünk nem jött be, azonnal megmondom. Ezért végül manuálisan rendeltük meg a "szenzeket". Valójában a rendszerünk minden egyes alkalmazása aszinkron módon futtatja a szükséges „módosítás – kész” szinkronizálást az adatközpontok között.
BAN BEN: - Ha kapott egy másodikat, miért nem kapott egy harmadikat? Mert még senkinek nem hasadt az agya...
EK: – De nekünk nincs megosztott agyunk. Tekintettel arra, hogy minden alkalmazást egy multimaster hajt meg, számunkra nem mindegy, hogy melyik központba érkezett a kérés. Készen állunk arra, hogy ha valamelyik adatközpontunk meghibásodik (ezre támaszkodunk), és egy felhasználói kérés közepette átvált a második adatközpontra, akkor készek vagyunk elveszíteni ezt a felhasználót, sőt; de ezek egységek, abszolút egységek lesznek.
BAN BEN: - Jó estét. Köszönöm a beszámolót. Ön beszélt a hibakeresőről, amely éles környezetben futtat néhány teszttranzakciót. De meséljen a teszttranzakciókról! Milyen mélyre megy?
EK: – A teljes komponens teljes ciklusán megy keresztül. Egy komponens esetében nincs különbség a teszttranzakció és az éles tranzakció között. De logikai szempontból ez egyszerűen egy külön projekt a rendszerben, amelyen csak teszttranzakciók futnak.
BAN BEN: -Hol vágod le? Itt Core küldte...
EK: – A teszttranzakcióknál jelen esetben a „Kor” mögé állunk... Van olyan, hogy routing: a „Kor” tudja, melyik fizetési rendszerre kell küldeni – hamis fizetési rendszerre küldünk, ami egyszerűen http jelet ad, és ez minden.
BAN BEN: – Mondja, kérem, egy hatalmas monolitban íródott a pályázata, vagy valami szolgáltatásra, esetleg mikroszolgáltatásra vágta?
EK: – Természetesen nincs monolitunk, hanem szolgáltatás-orientált alkalmazásunk. Viccelődünk, hogy szolgáltatásunk monolitokból áll – ezek tényleg elég nagyok. Nehéz mikroszolgáltatásnak nevezni, de ezek olyan szolgáltatások, amelyeken belül az elosztott gépek dolgozói működnek.
Ha a szerveren lévő szolgáltatás veszélybe kerül...
BAN BEN: – Akkor lenne a következő kérdésem. Még ha monolitról lenne is szó, akkor is azt mondtad, hogy sok ilyen azonnali szervered van, ezek alapvetően mind adatokat dolgoznak fel, és a kérdés a következő: „Az egyik azonnali szerver vagy egy alkalmazás kompromittálódása esetén bármely egyedi link , van bennük valamilyen beléptetés? Melyikük mit tehet? Kihez milyen információért forduljak?
EK: - Igen határozottan. A biztonsági követelmények meglehetősen komolyak. Először is nyílt adatmozgással rendelkezünk, és a portok csak azok, amelyeken keresztül előre előre látjuk a forgalom mozgását. Ha egy komponens kommunikál az adatbázissal (mondjuk a Muskullal) az 5-4-3-2-n keresztül, akkor csak az 5-4-3-2 lesz nyitva számára, és más portok és egyéb forgalmi irányok nem lesznek elérhetők. Ezenkívül meg kell értenie, hogy gyártásunkban körülbelül 10 különböző biztonsági hurok található. És még ha az alkalmazást valamilyen módon kompromittálták is, ne adj isten, a támadó nem tud hozzáférni a szerverkezelő konzolhoz, mert ez egy másik hálózati biztonsági zóna.BAN BEN: – És ebben a kontextusban számomra az az érdekes, hogy bizonyos szerződéseket köt a szolgáltatásokkal – mit tehetnek, milyen „cselekvések” révén léphetnek kapcsolatba egymással... És normális folyamatban egyes konkrét szolgáltatások kérnek néhányat. sor, a másikon a „műveletek” listája. Úgy tűnik, normális helyzetben nem fordulnak mások felé, és más felelősségi területeik is vannak. Ha valamelyikük veszélybe kerül, képes lesz-e megzavarni az adott szolgáltatás „műveleteit”?
EK: - Megértem. Ha normál helyzetben egy másik szerverrel egyáltalán engedélyezték a kommunikációt, akkor igen. Az SLA szerződés értelmében nem figyeljük, hogy csak az első 3 „művelet” legyen engedélyezett, és a 4 „művelet” ne legyen engedélyezett. Ez nálunk valószínűleg felesleges, mert már van 4 fokozatú védelmi rendszerünk elvileg az áramkörökre. Inkább a kontúrokkal védekezünk, mint a belső szinttel.
Hogyan működik a Visa, a MasterCard és a Sberbank
BAN BEN: – Szeretnék egy pontot tisztázni a felhasználó egyik adatközpontból a másikba való átállításával kapcsolatban. Tudomásom szerint a Visa és a MasterCard a 8583-as bináris szinkron protokollt használja, és ott vannak keverések. És azt szerettem volna tudni, hogy most a váltásra gondolunk – közvetlenül „Visa” és „MasterCard” vagy fizetési rendszerek előtt, feldolgozás előtt?
EK: - Ez a mixek előtt van. Mixeink ugyanabban az adatközpontban találhatók.
BAN BEN: – Nagyjából, van egy kapcsolódási pontja?
EK: – „Visa” és „MasterCard” – igen. Egyszerűen azért, mert a Visa és a MasterCard meglehetősen komoly infrastrukturális beruházásokat igényel, hogy külön szerződéseket kössön például egy második mixpár beszerzéséhez. Egy adatközponton belül vannak lefoglalva, de ha ne adj isten, az adatközpontunk, ahol a Visa és a MasterCard csatlakozási keverékei vannak, elpusztul, akkor megszakad a kapcsolatunk a Visa és a MasterCard között...
BAN BEN: – Hogyan lehet lefoglalni? Tudom, hogy a Visa elvileg csak egy csatlakozást engedélyez!
EK: – A felszerelést maguk szállítják. Mindenesetre olyan felszerelést kaptunk, ami belül teljesen redundáns.
BAN BEN: – Tehát az állvány a Connects Orange-juktól származik?
EK: - Igen.
BAN BEN: – De mi a helyzet ezzel az esettel: ha eltűnik az adatközpontja, hogyan tudja tovább használni? Vagy csak megáll a forgalom?
EK: - Nem. Ebben az esetben egyszerűen átkapcsoljuk a forgalmat egy másik csatornára, ami természetesen nekünk drágább, ügyfeleinknek pedig drágább lesz. De a forgalom nem a Visa, MasterCard közvetlen kapcsolatunkon, hanem a feltételes Sberbankon (nagyon eltúlzottan) keresztül fog menni.
Nagyon elnézést kérek, ha megbántottam a Sberbank alkalmazottait. Statisztikáink szerint azonban az orosz bankok közül a Sberbank esik leggyakrabban. Nem telik el úgy hónap, hogy ne essen le valami a Sberbankban.
Néhány hirdetés 🙂
Köszönjük, hogy velünk tartott. Tetszenek cikkeink? További érdekes tartalmakat szeretne látni? Támogass minket rendeléssel vagy ajánlj ismerőseidnek, , a belépő szintű szerverek egyedülálló analógja, amelyet mi találtunk ki Önnek: (RAID1 és RAID10, akár 24 maggal és akár 40 GB DDR4-gyel is elérhető).
A Dell R730xd kétszer olcsóbb az amszterdami Equinix Tier IV adatközpontban? Csak itt Hollandiában! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollártól! Olvasni valamiről
Forrás: will.com