HighLoad++, Evgeniy Kuzovlev (EcommPay IT): mitä tehdä, kun minuutin seisokki maksaa 100000 XNUMX dollaria

Kaikki puhuvat kehitys- ja testausprosesseista, henkilöstön kouluttamisesta, motivaation lisäämisestä, mutta nämä prosessit eivät riitä, kun minuutin huoltoseisokki maksaa valtavia summia. Mitä tehdä, kun suoritat rahoitustapahtumia tiukan SLA:n alaisena? Kuinka lisätä järjestelmien luotettavuutta ja vikasietoisuutta poistamalla kehitys ja testaus yhtälöstä?

Seuraava HighLoad++-konferenssi järjestetään 6. ja 7 Pietarissa. Lisätiedot ja liput linkki. 9. marraskuuta klo 18. HighLoad++ Moskova 00, Delhi + Kolkata-halli. Opinnäytetyöt ja esittely.

Jevgeni Kuzovlev (jäljempänä – EY): - Ystävät, hei! Nimeni on Kuzovlev Evgeniy. Olen EcommPay-yhtiöstä, erityinen divisioona on EcommPay IT, yritysryhmän IT-divisioona. Ja tänään puhumme seisokeista - siitä, kuinka niitä voidaan välttää, kuinka minimoida niiden seuraukset, jos sitä ei voida välttää. Aihe on esitetty seuraavasti: "Mitä tehdä, kun minuutin seisokki maksaa 100 000 dollaria"? Tulevaisuudessa lukumme ovat vertailukelpoisia.

Mitä EcommPay IT tekee?

Keitä me olemme? Miksi seison täällä edessäsi? Miksi minulla on oikeus kertoa sinulle jotain täällä? Ja mistä puhumme täällä tarkemmin?

EcommPay-yritysryhmä on kansainvälinen ostaja. Käsittelemme maksuja kaikkialla maailmassa - Venäjällä, Euroopassa, Kaakkois-Aasiassa (All Around the World). Meillä on 9 toimistoa, yhteensä 500 työntekijää, joista vajaa puolet on IT-asiantuntijoita. Kaikki mitä teemme, kaikki, mistä ansaitsemme rahaa, teimme itse.

Kirjoitimme kaikki tuotteemme (ja meillä on niitä melko paljon - suurissa IT-tuotteissamme on noin 16 eri komponenttia) itse; Kirjoitamme itse, kehitämme itseämme. Ja tällä hetkellä teemme noin miljoona tapahtumaa päivässä (miljoona on luultavasti oikea tapa sanoa se). Olemme melko nuori yritys - olemme vasta noin kuusi vuotta vanhoja.

6 vuotta sitten se oli sellainen startup, kun kaverit tulivat mukaan bisnekselle. Heitä yhdisti idea (ei ollut muuta kuin idea), ja me juoksimme. Kuten kaikki startup-yritykset, juoksimme nopeammin... Meille nopeus oli tärkeämpää kuin laatu.

Jossain vaiheessa pysähdyimme: tajusimme, että emme voi enää jotenkin elää sillä nopeudella ja laadulla, ja meidän piti ensin keskittyä laatuun. Tällä hetkellä päätimme kirjoittaa uuden alustan, joka olisi oikea, skaalautuva ja luotettava. He aloittivat tämän alustan kirjoittamisen (alkoivat investoimisen, kehittämisen kehittämisen, testauksen), mutta jossain vaiheessa he huomasivat, että kehitys ja testaus eivät antaneet meille mahdollisuuden saavuttaa uutta palvelun laadun tasoa.

Teet uuden tuotteen, laitat sen tuotantoon, mutta silti jokin menee pieleen jossain. Ja tänään puhumme siitä, kuinka päästä uudelle laatutasolle (miten teimme sen, kokemuksestamme), poistamalla kehityksen ja testauksen yhtälöstä; puhumme siitä, mikä on toiminnan käytettävissä - mikä toiminta voi tehdä itse, mitä se voi tarjota testaukselle laatuun vaikuttamiseksi.

Seisokit. Toiminnan käskyt.

Aina tärkein kulmakivi, josta puhumme tänään, on seisokit. Kauhea sana. Jos meillä on seisokkeja, kaikki on huonosti meille. Juoksemme nostaa sitä, järjestelmänvalvojat pitävät palvelinta - Jumala varjelkoon, ettei se putoa, kuten tuossa laulussa sanotaan. Tästä puhumme tänään.

Kun aloimme muuttaa lähestymistapaamme, loimme 4 käskyä. Olen esitellyt ne dioissa:

Nämä käskyt ovat melko yksinkertaisia:

• Tunnista ongelma nopeasti.
• Päästä eroon vielä nopeammin.
• Auta ymmärtämään syy (myöhemmin kehittäjille).
• Ja standardisoi lähestymistavat.

Haluaisin kiinnittää huomionne kohtaan 2. Pääsemme eroon ongelmasta, emme ratkaise sitä. Päätös on toissijaista. Meille ensisijainen asia on, että käyttäjä on suojattu tältä ongelmalta. Se tulee olemaan jossain eristetyssä ympäristössä, mutta tällä ympäristöllä ei ole mitään yhteyttä siihen. Itse asiassa käymme läpi nämä neljä ongelmaryhmää (jotkut yksityiskohtaisemmin, jotkut vähemmän), kerron mitä käytämme, mitä relevanttia kokemusta meillä on ratkaisuista.

Vianetsintä: Milloin ne tapahtuvat ja mitä tehdä niille?

Mutta aloitamme epäkunnossa, aloitamme kohdasta nro 2 - kuinka nopeasti päästä eroon ongelmasta? On ongelma - meidän on korjattava se. "Mitä meidän pitäisi tehdä tälle?" - pääkysymys. Ja kun aloimme miettiä, kuinka korjata ongelma, kehitimme itsellemme joitain vaatimuksia, joita vianmäärityksen on noudatettava.

Näiden vaatimusten muotoilemiseksi päätimme esittää itseltämme kysymyksen: "Milloin meillä on ongelmia"? Ja ongelmia, kuten kävi ilmi, esiintyy neljässä tapauksessa:

• Laitteistovika.
• Ulkoiset palvelut epäonnistuivat.
• Ohjelmistoversion muuttaminen (sama käyttöönotto).
• Räjähdysmäinen kuorman kasvu.

Emme puhu kahdesta ensimmäisestä. Laitteiston toimintahäiriö voidaan ratkaista yksinkertaisesti: sinun on kopioitava kaikki. Jos nämä ovat levyjä, levyt on koottava RAIDiin; jos tämä on palvelin, palvelin on monistettava; jos sinulla on verkkoinfrastruktuuri, sinun on toimitettava toinen kopio verkkoinfrastruktuurista, eli ota se ja kopioida se. Ja jos jokin epäonnistuu, vaihdat varavoimaan. Tässä on vaikea sanoa mitään enempää.

Toinen on ulkoisten palvelujen epäonnistuminen. Useimmille järjestelmä ei ole ongelma ollenkaan, mutta ei meille. Koska käsittelemme maksuja, olemme aggregaattori, joka seisoo käyttäjän (joka syöttää korttitietonsa) ja pankkien, maksujärjestelmien (Visa, MasterCard, Mira jne.) väliin. Ulkopuoliset palvelumme (maksujärjestelmät, pankit) yleensä epäonnistuvat. Emme me tai sinä (jos sinulla on tällaisia ​​palveluita) voi vaikuttaa tähän.

Mitä sitten tehdä? Tässä on kaksi vaihtoehtoa. Ensinnäkin, jos voit, sinun pitäisi kopioida tämä palvelu jollakin tavalla. Esimerkiksi, jos voimme, siirrämme liikennettä palvelusta toiseen: esimerkiksi kortteja käsiteltiin Sberbankin kautta, Sberbankilla on ongelmia - siirrämme liikennettä [ehdollisesti] Raiffeisenille. Toinen asia, jonka voimme tehdä, on huomata ulkoisten palvelujen epäonnistuminen erittäin nopeasti, ja siksi puhumme vastausnopeudesta raportin seuraavassa osassa.

Itse asiassa näistä neljästä voimme erityisesti vaikuttaa ohjelmistoversioiden muutokseen - ryhtyä toimenpiteisiin, jotka johtavat tilanteen paranemiseen käyttöönottojen ja kuormituksen räjähdysmäisen kasvun yhteydessä. Itse asiassa niin me teimme. Tässä taas pieni huomautus...

Näistä neljästä ongelmasta useat ratkaistaan ​​välittömästi, jos sinulla on pilvi. Jos olet Microsoft Azhur-, Ozone-pilvissä tai käytät pilviämme Yandexista tai Mailista, silloin ainakin laitteiston toimintahäiriö tulee heidän ongelmansa ja kaikki on heti kunnossa laitteistovian yhteydessä.

Olemme hieman epätavallinen yritys. Täällä kaikki puhuvat "Kubernetsistä", pilvistä - meillä ei ole "Kubernets" eikä pilviä. Mutta meillä on laitteistohyllyjä monissa palvelinkeskuksissa, ja meidän on pakko elää tällä laitteistolla, meidän on pakko olla vastuussa kaikesta. Siksi puhumme tässä yhteydessä. Eli ongelmista. Kaksi ensimmäistä otettiin pois suluista.

Ohjelmistoversion muuttaminen. Pohjat

Kehittäjällämme ei ole pääsyä tuotantoon. Miksi niin? Olemme vain PCI DSS -sertifioituja, eikä kehittäjillämme yksinkertaisesti ole oikeutta päästä "tuotteeseen". Siinä se, piste. Ollenkaan. Kehitysvastuu siis päättyy juuri sillä hetkellä, kun kehitys lähettää koontiversion julkaisuun.

Toinen perustamme, joka myös auttaa meitä paljon, on ainutlaatuisen dokumentoimattoman tiedon puuttuminen. Toivon, että se on sama sinulle. Koska jos näin ei ole, sinulla on ongelmia. Ongelmia syntyy, kun tämä ainutlaatuinen, dokumentoimaton tieto ei ole läsnä oikeaan aikaan oikeassa paikassa. Oletetaan, että sinulla on yksi henkilö, joka osaa ottaa tietyn komponentin käyttöön – henkilö ei ole paikalla, hän on lomalla tai sairas – siinä kaikki, sinulla on ongelmia.

Ja kolmas perusta, johon olemme tulleet. Pääsimme siihen kivun, veren ja kyynelten kautta - tulimme siihen tulokseen, että kaikki rakentamisemme sisältävät virheitä, vaikka ne olisivat virheettömiä. Päätimme tämän itse: kun otamme jotain käyttöön, kun otamme jotain tuotantoon, meillä on virheitä sisältävä rakenne. Olemme muodostaneet vaatimukset, jotka järjestelmämme on täytettävä.

Ohjelmistoversion muuttamisen vaatimukset

Vaatimuksia on kolme:

• Meidän on peruutettava käyttöönotto nopeasti.
• Meidän on minimoitava epäonnistuneen käyttöönoton vaikutukset.
• Ja meidän on voitava ottaa nopeasti käyttöön rinnakkain.
  Juuri tuossa järjestyksessä! Miksi? Ensinnäkin, kun uutta versiota otetaan käyttöön, nopeus ei ole tärkeä, mutta on tärkeää, että jos jokin menee pieleen, peruutat nopeasti ja vaikutat mahdollisimman vähän. Mutta jos sinulla on sarja versioita tuotannossa, jolle käy ilmi, että siinä on virhe (älyttömästä, käyttöönottoa ei tapahtunut, mutta siinä on virhe) - myöhemmän käyttöönoton nopeus on sinulle tärkeä. Mitä olemme tehneet täyttääksemme nämä vaatimukset? Käytimme seuraavaa menetelmää:

  
  
  Se on melko tunnettu, emme ole koskaan keksineet sitä - tämä on sininen/vihreä käyttöönotto. Mikä se on? Sinulla on oltava kopio jokaisesta palvelinryhmästä, johon sovelluksesi on asennettu. Kopio on "lämmin": sillä ei ole liikennettä, mutta milloin tahansa tämä liikenne voidaan lähettää tälle kopiolle. Tämä kopio sisältää edellisen version. Ja käyttöönoton yhteydessä julkaiset koodin ei-aktiiviseksi kopioksi. Sitten vaihdat osan liikenteestä (tai koko) uuteen versioon. Siten, jotta voit muuttaa liikennevirran vanhasta versiosta uuteen, sinun on tehtävä vain yksi toimenpide: sinun on vaihdettava tasapainotin ylävirtaan, vaihdettava suunta - yhdestä ylävirtaan toiseen. Tämä on erittäin kätevää ja ratkaisee nopean vaihdon ja nopean palautuksen ongelman.

  Tässä ratkaisu toiseen kysymykseen on minimointi: voit lähettää vain osan liikenteestäsi uudelle riville, riville, jolla on uusi koodi (olkoon se esimerkiksi 2%). Ja nämä 2% eivät ole 100%! Jos menetit 100 % liikenteestäsi epäonnistuneen käyttöönoton vuoksi, se on pelottavaa; jos menetit 2 % liikenteestäsi, se on epämiellyttävää, mutta se ei ole pelottavaa. Lisäksi käyttäjät eivät todennäköisesti edes huomaa tätä, koska joissain tapauksissa (ei kaikissa) sama käyttäjä, joka painaa F5, siirtyy toiseen, toimivaan versioon.

  Sininen/vihreä käyttöönotto. Reititys

  Kaikki ei kuitenkaan ole niin yksinkertaista "Blue/Green deploy"... Kaikki osamme voidaan jakaa kolmeen ryhmään:

  • tämä on käyttöliittymä (asiakkaamme näkevät maksusivut);
  • käsittely ydin;
  • sovitin maksujärjestelmien kanssa työskentelyyn (pankit, MasterCard, Visa...).

  Ja tässä on vivahde - vivahde on rivien välisessä reitityksessä. Jos vaihdat vain 100 % liikenteestä, sinulla ei ole näitä ongelmia. Mutta jos haluat vaihtaa 2%, alat kysyä kysymyksiä: "Kuinka tämä tehdään?" Yksinkertaisin asia on suoraan eteenpäin: voit määrittää Round Robinin nginxissä satunnaisella valinnalla, ja sinulla on 2% vasemmalla ja 98% oikealla. Mutta tämä ei aina sovi.

  Esimerkiksi meidän tapauksessamme käyttäjä on vuorovaikutuksessa järjestelmän kanssa useammalla kuin yhdellä pyynnöllä. Tämä on normaalia: 2, 3, 4, 5 pyyntöä - järjestelmäsi voivat olla samat. Ja jos sinulle on tärkeää, että kaikki käyttäjän pyynnöt tulevat samalle riville, jolla ensimmäinen pyyntö tuli, tai (toinen kohta) kaikki käyttäjän pyynnöt tulevat uudelle riville vaihdon jälkeen (hän ​​olisi voinut aloittaa työskentelyn aiemmin järjestelmä, ennen vaihtoa), - silloin tämä satunnaisjakauma ei sovi sinulle. Sitten on seuraavat vaihtoehdot:

  
  
  Ensimmäinen vaihtoehto, yksinkertaisin, perustuu asiakkaan perusparametreihin (IP Hash). Sinulla on IP, ja jaat sen oikealta vasemmalle IP-osoitteella. Sitten toinen kuvaamani tapaus toimii sinulle, kun käyttöönotto tapahtui, käyttäjä voi jo aloittaa työskentelyn järjestelmäsi kanssa, ja käyttöönoton hetkestä lähtien kaikki pyynnöt siirtyvät uudelle riville (samaan, vaikkapa).

  Jos tämä ei jostain syystä sovi sinulle ja sinun on lähetettävä pyynnöt sille riville, jolla käyttäjän ensimmäinen, ensimmäinen pyyntö tuli, sinulla on kaksi vaihtoehtoa...
  Ensimmäinen vaihtoehto: voit ostaa maksetun nginx+:n. Käytössä on Sticky sessions -mekanismi, joka käyttäjän alkuperäisestä pyynnöstä määrittää käyttäjälle istunnon ja sitoo sen johonkin ylävirtaan. Kaikki myöhemmät käyttäjien pyynnöt istunnon aikana lähetetään samaan ylävirtaan, jossa istunto lähetettiin.

  Tämä ei sopinut meille, koska meillä oli jo tavallinen nginx. Vaihtaminen nginx+:aan ei ole kallista, vaan se oli meille hieman tuskallista eikä oikein. Esimerkiksi "Sticks Sessions" ei toiminut meillä siitä yksinkertaisesta syystä, että "Sticks Sessions" ei salli reititystä "joko-tai"-perusteisesti. Siellä voit määrittää, mitä "Sticks Sessions" tekee, esimerkiksi IP-osoitteen tai IP-osoitteen ja evästeiden tai jälkiparametrien perusteella, mutta "joko-tai" on siellä monimutkaisempi.

  Siksi päädyimme neljänteen vaihtoehtoon. Otimme nginxiä steroideilla (tämä on openresty) - tämä on sama nginx, joka tukee lisäksi viimeisten skriptien sisällyttämistä. Voit kirjoittaa viimeisen skriptin, antaa sille "avoimen levon", ja tämä viimeinen komentosarja suoritetaan, kun käyttäjän pyyntö tulee.

  Ja itse asiassa kirjoitimme sellaisen käsikirjoituksen, asetimme itsellemme "openresti" ja tässä skriptissä lajittelemme 6 eri parametria ketjuttamalla "Tai". Riippuen yhden tai toisen parametrin olemassaolosta, tiedämme, että käyttäjä tuli yhdelle tai toiselle sivulle, riville tai toiselle.

  Sininen/vihreä käyttöönotto. Hyödyt ja haitat

  Tietysti oli mahdollista tehdä siitä hieman yksinkertaisempi (käytä samoja ”Sticky Sessions”), mutta meillä on myös sellainen vivahde, että käyttäjä ei ole vuorovaikutuksessa kanssamme yhden tapahtuman yhden käsittelyn puitteissa... Mutta myös maksujärjestelmät ovat vuorovaikutuksessa kanssamme: Kun olemme käsitelleet tapahtuman (lähettämällä pyynnön maksujärjestelmään), saamme palautuksen.
  Ja sanotaan, että jos piirimme sisällä voimme välittää käyttäjän IP-osoitteen kaikissa pyynnöissä ja jakaa käyttäjät IP-osoitteen perusteella, niin emme kerro samaa "Visaa": "Kaveri, me olemme niin retroyritys, näytämme. olla kansainvälinen (sivustolla ja Venäjällä)... Anna meille käyttäjän IP-osoite lisäkenttään, protokollasi on standardoitu”! On selvää, että he eivät ole samaa mieltä.

  
  
  Siksi tämä ei toiminut meille - teimme openrestyä. Vastaavasti reitityksellä saimme jotain tällaista:

  Blue/Green Deploymentilla on vastaavasti mainitsemani edut ja haitat.

  Kaksi haittaa:

  • sinun on vaivauduttava reitittämiseen;
  • toinen suurin haittapuoli on kustannukset.

  Tarvitset kaksi kertaa enemmän palvelimia, tarvitset kaksi kertaa enemmän toimintaresursseja, sinun on käytettävä kaksi kertaa enemmän vaivaa koko tämän eläintarhan ylläpitämiseen.

  Muuten, etujen joukossa on vielä yksi asia, jota en ole aiemmin maininnut: sinulla on varaus kuormituksen kasvun varalta. Jos kuormitus kasvaa räjähdysmäisesti, käyttäjiä on paljon, sisällytät vain toisen rivin 50–50-jakeluun - ja sinulla on heti x2-palvelinta klusterissasi, kunnes ratkaiset palvelinten lisäämisen ongelman.

  Kuinka tehdä nopea käyttöönotto?

  Puhuimme minimoinnin ja nopean palautuksen ongelman ratkaisemisesta, mutta kysymys jää: "Kuinka ottaa käyttöön nopeasti?"

  
  
  Se on lyhyt ja yksinkertainen tässä.

  • Sinulla on oltava CD-järjestelmä (Continuous Delivery) - et voi elää ilman sitä. Jos sinulla on yksi palvelin, voit ottaa käyttöön manuaalisesti. Meillä on tietysti noin puolitoista tuhatta palvelinta ja puolitoista tuhatta kahvoja - voimme istuttaa tämän huoneen kokoisen osaston vain käyttöön.
  • Käyttöönoton on oltava rinnakkainen. Jos käyttöönotto on peräkkäistä, kaikki on huonosti. Yksi palvelin on normaali, otat käyttöön puolitoista tuhatta palvelinta koko päivän.
  • Jälleen, kiihdytystä varten tämä ei todennäköisesti ole enää tarpeen. Käyttöönoton aikana projekti yleensä rakennetaan. Sinulla on verkkoprojekti, siinä on etuosa (teet web-paketin, käännät npm - jotain sellaista), ja tämä prosessi on periaatteessa lyhytikäinen - 5 minuuttia, mutta nämä 5 minuuttia voi olla kriittinen. Siksi esimerkiksi emme tee sitä: poistimme nämä 5 minuuttia, otamme käyttöön artefakteja.

    Mikä on artefakti? Artefakti on koottu rakennelma, jossa kaikki kokoonpanon osat on jo valmisteltu. Tallennamme tämän esineen artefaktivarastoon. Aikoinaan käytimme kahta tällaista tallennustilaa - se oli Nexus ja nyt jFrog Artifactory. Käytimme aluksi "Nexusta", koska aloimme harjoittaa tätä lähestymistapaa java-sovelluksissa (se sopi hyvin). Sitten he laittoivat sinne joitakin PHP:llä kirjoitettuja sovelluksia; ja "Nexus" ei enää sopinut, ja siksi valitsimme jFrog Artefactoryn, joka pystyy artifaktoimaan melkein kaiken. Olemme jopa tulleet siihen pisteeseen, että tähän artefaktivarastoon tallennamme omia binääripakettejamme, joita keräämme palvelimia varten.

  Räjähdysmäinen kuorman kasvu

  Puhuimme ohjelmistoversion muuttamisesta. Seuraava asia meillä on räjähdysmäinen kuormituksen kasvu. Tarkoitan tässä luultavasti kuorman räjähdysmäisellä kasvulla, joka ei ole aivan oikea asia...

  Kirjoitimme uuden järjestelmän - se on palvelukeskeinen, muodikas, kaunis, työntekijöitä kaikkialla, jonoja kaikkialla, asynkroninen kaikkialla. Ja tällaisissa järjestelmissä data voi virrata eri virtojen kautta. Ensimmäisessä tapahtumassa voidaan käyttää 1., 3., 10. työntekijää, toisessa tapahtumassa - 2., 4., 5. Ja tänään, sanotaan, että sinulla on aamulla tietovirta, joka käyttää kolmea ensimmäistä työntekijää, ja illalla se muuttuu dramaattisesti, ja kaikki käyttää kolmea muuta työntekijää.

  Ja tässä käy ilmi, että sinun täytyy jotenkin skaalata työntekijöitä, sinun täytyy jotenkin skaalata palvelujasi, mutta samalla estää resurssien turvotus.

  
  
  Olemme määrittäneet vaatimuksemme. Nämä vaatimukset ovat melko yksinkertaisia: Palvelun löytäminen, parametrointi - kaikki on vakiona tällaisten skaalautuvien järjestelmien rakentamisessa, paitsi yksi piste - resurssien poisto. Sanoimme, että emme ole valmiita kuolettamaan resursseja niin, että palvelimet lämmittävät ilmaa. Otimme "Consulin", otimme "Nomadin", joka hoitaa työntekijöitämme.

  Miksi tämä on meille ongelma? Palataanpa hieman taaksepäin. Meillä on nyt takanamme noin 70 maksujärjestelmää. Aamulla liikenne kulkee Sberbankin kautta, sitten esimerkiksi Sberbank putosi ja siirrymme toiseen maksujärjestelmään. Meillä oli 100 työntekijää ennen Sberbankia, ja sen jälkeen meidän on lisättävä jyrkästi 100 työntekijää toiseen maksujärjestelmään. Ja on toivottavaa, että tämä kaikki tapahtuu ilman ihmisen osallistumista. Koska jos on ihmisten osallistumista, siellä pitäisi istua 24/7 insinööri, jonka pitäisi vain tehdä tätä, koska sellaisia ​​vikoja, kun 70 järjestelmää on takana, tapahtuu säännöllisesti.

  Siksi tarkastelimme Nomadia, jolla on avoin IP, ja kirjoitimme oman juttumme, Scale-Nomad - ScaleNo, joka tekee suunnilleen seuraavaa: se seuraa jonon kasvua ja vähentää tai lisää työntekijöiden määrää dynamiikasta riippuen. jonosta. Kun teimme sen, ajattelimme: "Ehkä voimme avata sen?" Sitten he katsoivat häntä - hän oli yksinkertainen kuin kaksi kopeikkoa.

  Emme ole toistaiseksi avoimen lähdekoodin käyttäneet, mutta jos yhtäkkiä raportin jälkeen, kun tajuat tarvitsevasi sellaista, tarvitset sitä, yhteystietoni ovat viimeisessä diassa - kirjoita minulle. Jos osallistujia on vähintään 3-5, sponsoroimme sitä.

  
  
  Kuinka se toimii? Katsotaanpa! Katse eteenpäin: vasemmalla on pala seurantaamme: tämä on yksi rivi, ylhäällä tapahtuman käsittelyaika, keskellä tapahtumien määrä, alareunassa työntekijöiden määrä.

  Jos katsot, tässä kuvassa on virhe. Yläkaaviossa yksi kaavioista kaatui 45 sekunnissa - yksi maksujärjestelmistä meni alas. Heti liikenne tuotiin 2 minuutissa ja jono alkoi kasvaa toiseen maksujärjestelmään, jossa ei ollut työntekijöitä (emme käyttäneet resursseja - päinvastoin, hävitimme resurssin oikein). Emme halunneet lämmittää - työntekijöitä oli minimaalinen, noin 5-10, mutta he eivät jaksaneet.

  Viimeisessä kaaviossa näkyy "kyhmy", mikä tarkoittaa vain, että "Skaleno" kaksinkertaisti tämän määrän. Ja sitten, kun kaavio putosi hieman, hän pienensi sitä hieman - työntekijöiden määrä muuttui automaattisesti. Näin tämä homma toimii. Puhuimme kohdasta numero 2 - "Kuinka päästä nopeasti eroon syistä."

  Valvonta. Kuinka tunnistaa ongelma nopeasti?

  Nyt ensimmäinen kohta on "Kuinka tunnistaa ongelma nopeasti?" Valvonta! Meidän on ymmärrettävä tietyt asiat nopeasti. Mitä asioita meidän pitäisi ymmärtää nopeasti?

  
  
  Kolme asiaa!

  • Meidän on ymmärrettävä ja ymmärrettävä nopeasti omien resurssiemme suorituskyky.
  • Meidän on nopeasti ymmärrettävä viat ja seurattava ulkopuolisten järjestelmien suorituskykyä.
  • Kolmas kohta on loogisten virheiden tunnistaminen. Tällöin järjestelmä toimii puolestasi, kaikki on normaalia kaikkien indikaattorien mukaan, mutta jokin menee pieleen.

  En luultavasti kerro sinulle mitään hienoa tässä. Minusta tulee Captain Obvious. Etsimme mitä markkinoilla oli. Meillä on "hauska eläintarha". Tällainen eläintarha meillä on nyt:

  
  
  Käytämme Zabbixia laitteiston valvontaan, palvelimien pääindikaattoreiden seuraamiseen. Käytämme tietokantoihin Okmeteriä. Käytämme "Grafana" ja "Prometheus" kaikille muille indikaattoreille, jotka eivät sovi kahteen ensimmäiseen, joista osa on "Grafana" ja "Prometheus" ja toiset "Grafana" ja "Influx" ja Telegraf.

  Vuosi sitten halusimme käyttää New Reliciä. Hieno juttu, sillä voi tehdä kaiken. Mutta niin paljon kuin hän voi tehdä kaikkea, hän on niin kallis. Kun kasvoimme 1,5 tuhannen palvelimen volyymiksi, toimittaja tuli luoksemme ja sanoi: "Tehdään sopimus ensi vuodelle." Katsoimme hintaa ja sanoimme, että ei, emme tee sitä. Nyt hylkäämme New Relicin, meillä on noin 15 palvelinta jäljellä New Relicin seurannassa. Hinta osoittautui aivan hurjaksi.

  Ja on yksi työkalu, jonka toteutimme itse - tämä on Debugger. Aluksi kutsuimme sitä "Baggeriksi", mutta sitten englannin opettaja kulki ohi, nauroi villisti ja nimesi sen uudelleen "Debaggeriksi". Mikä se on? Tämä on työkalu, joka itse asiassa testaa komponentin yleistä suorituskykyä 15-30 sekunnissa jokaisessa komponentissa, kuten järjestelmän "musta laatikko".

  Jos esimerkiksi on olemassa ulkoinen sivu (maksusivu), hän yksinkertaisesti avaa sen ja katsoo, miltä sen pitäisi näyttää. Jos tämä on käsittelyssä, hän lähettää testi "tapahtuman" ja varmistaa, että tämä "tapahtuma" saapuu. Jos kyseessä on yhteys maksujärjestelmiin, käynnistämme mahdollisuuksien mukaan testipyynnön ja katsomme, että meillä on kaikki hyvin.

  Mitkä indikaattorit ovat tärkeitä seurannan kannalta?

  Mitä valvomme pääasiassa? Mitkä indikaattorit ovat meille tärkeitä?

  
  

  • Reaktioaika / RPS rintamalla on erittäin tärkeä indikaattori. Hän vastaa välittömästi, että sinussa on jotain vialla.
  • Käsiteltyjen viestien määrä kaikissa jonoissa.
  • Työntekijöiden määrä.
  • Perusoikeusmittarit.

  Viimeinen kohta on "liiketoiminta", "liiketoiminta" -mittari. Jos haluat seurata samaa asiaa, sinun on määritettävä yksi tai kaksi mittaria, jotka ovat sinulle tärkeimpiä indikaattoreita. Mittarimme on läpimeno (tämä on onnistuneiden tapahtumien määrän suhde tapahtuman kokonaisvirtaan). Jos siinä jotain muuttuu 5-10-15 minuutin välein, se tarkoittaa, että meillä on ongelmia (jos se muuttuu radikaalisti).

  Miltä se näyttää meille, on esimerkki yhdestä laudoistamme:

  
  
  Vasemmalla puolella on 6 kaaviota, tämä on rivien mukaan - työntekijöiden lukumäärä ja viestien määrä jonoissa. Oikealla puolella – RPS, RTS. Alla on sama "liiketoiminta"-mittari. Ja "liiketoiminnan" metriikassa näemme heti, että kahdessa keskimmäisessä kaaviossa jotain meni pieleen... Tämä on vain yksi takanamme oleva järjestelmä, joka on pudonnut.

  Toinen asia, jota meidän piti tehdä, oli seurata ulkoisten maksujärjestelmien romahtamista. Tässä otettiin OpenTracing - mekanismi, standardi, paradigma, jonka avulla voit jäljittää hajautettuja järjestelmiä; ja sitä vähän muutettiin. Vakio OpenTracing-paradigma sanoo, että rakennamme jäljen jokaiselle yksittäiselle pyynnölle. Emme tarvinneet tätä, ja käärimme sen yhteenvetoon, aggregaatiojäljitykseen. Teimme työkalun, jonka avulla voimme seurata takana olevien järjestelmien nopeutta.

  
  
  Kaavio näyttää meille, että yksi maksujärjestelmistä alkoi vastata 3 sekunnissa - meillä on ongelmia. Lisäksi tämä asia reagoi ongelmien alkaessa 20-30 sekunnin välein.

  Ja kolmas olemassa olevien valvontavirheiden luokka on looginen valvonta.

  Rehellisesti sanottuna en tiennyt mitä piirtäisin tälle dialle, koska olimme pitkään etsineet markkinoilta jotain, joka sopisi meille. Emme löytäneet mitään, joten meidän piti tehdä se itse.

  
  
  Mitä tarkoitan loogisella seurannalla? Kuvittele: teet itsellesi järjestelmän (esimerkiksi Tinder-kloonin); teit sen, käynnistit sen. Menestyvä johtaja Vasya Pupkin laittoi sen puhelimeensa, näkee siellä tytön, pitää hänestä... ja vastaava ei mene tytölle - samanlainen menee samasta bisneskeskuksesta olevalle vartijalle Mikhalychille. Johtaja menee alakertaan ja ihmettelee sitten: "Miksi tämä vartija Mikhalych hymyilee hänelle niin miellyttävästi?"

  Tällaisissa tilanteissa... Meille tämä tilanne kuulostaa hieman erilaiselta, koska (kirjoitin) tämä on maineen menetys, joka johtaa epäsuorasti taloudellisiin menetyksiin. Tilanteemme on päinvastainen: voimme kärsiä suoria taloudellisia tappioita - esimerkiksi jos suoritimme kaupan onnistuneesti, mutta se epäonnistui (tai päinvastoin). Minun piti kirjoittaa oma työkaluni, joka seuraa onnistuneiden tapahtumien määrää ajan mittaan liiketoiminnan indikaattoreiden avulla. Markkinoilta ei löytynyt mitään! Juuri tämän idean halusin välittää. Markkinoilla ei ole mitään, joka ratkaisee tämänkaltaisen ongelman.

  Tässä oli kysymys siitä, kuinka nopeasti tunnistaa ongelma.

  Kuinka selvittää käyttöönoton syyt

  Kolmas ongelmaryhmä, jonka ratkaisemme, on ongelman tunnistamisen jälkeen, kun siitä on päästy eroon, olisi hyvä ymmärtää kehittämisen, testauksen syy ja tehdä asialle jotain. Siksi meidän on tutkittava, meidän on nostettava lokit.

  
  
  Jos puhumme hirsistä (pääsyy on hirsi), suurin osa tukistamme on ELK Stackissa - melkein kaikilla on sama. Joillekin se ei ehkä ole ELK:ssa, mutta jos kirjoitat lokit gigatavuina, tulet ennemmin tai myöhemmin ELK: lle. Kirjoitamme ne teratavuina.

  
  
  Tässä on ongelma. Korjasimme sen, korjasimme virheen käyttäjälle, aloimme kaivaa esiin mitä siellä oli, kiipesimme Kibanaan, syötimme tapahtumatunnuksen sinne ja saimme tällaisen jalkaliinan (näyttää paljon). Eikä tässä jalkakankaassa mikään ole selvää. Miksi? Kyllä, koska ei ole selvää, mikä osa kuuluu mille työntekijälle, mikä osa kuuluu mille komponentille. Ja sillä hetkellä tajusimme, että tarvitsemme jäljitystä - samaa OpenTracingia, josta puhuin.

  Ajattelimme tätä vuosi sitten, käänsimme huomiomme markkinoihin, ja siellä oli kaksi työkalua - "Zipkin" ja "Jaeger". "Jager" on itse asiassa sellainen ideologinen perillinen, "Zipkinin" ideologinen seuraaja. Zipkinissä on kaikki hyvin, paitsi että se ei osaa aggregoida, se ei osaa sisällyttää lokit jäljitykseen, vain aikajäljitystä. Ja "Jager" tuki tätä.

  Katselimme "Jageria": voit instrumentoida sovelluksia, voit kirjoittaa Apilla (APi-standardia PHP:lle tuolloin ei kuitenkaan hyväksytty - tämä oli vuosi sitten, mutta nyt se on jo hyväksytty), mutta siellä ei ollut ollenkaan asiakas. "Okei", ajattelimme ja kirjoitimme omalle asiakkaallemme. Mitä saimme? Suunnilleen tältä se näyttää:

  
  
  Jaegerissa kullekin viestille luodaan jänteet. Eli kun käyttäjä avaa järjestelmän, hän näkee yhden tai kaksi lohkoa jokaiselle saapuvalle pyynnölle (1-2-3 - käyttäjältä saapuvien pyyntöjen määrä, lohkojen lukumäärä). Käyttäjien helpottamiseksi lisäsimme tunnisteita lokeihin ja aikajäljitykseen. Vastaavasti virheen sattuessa sovelluksemme merkitsee lokiin sopivalla Error tagilla. Voit suodattaa virhetunnisteen mukaan, ja vain sellaiset jaksot, jotka sisältävät tämän virheen sisältävän lohkon, näytetään. Tältä se näyttää, jos laajennamme aluetta:

  
  
  Alan sisällä on joukko jälkiä. Tässä tapauksessa nämä ovat kolme testijälkeä, ja kolmas jälki kertoo, että tapahtui virhe. Samalla tässä näemme aikajäljen: meillä on aika-asteikko ylhäällä, ja näemme, millä aikavälillä tämä tai tuo loki on tallennettu.

  Näin ollen asiat sujuivat meillä hyvin. Kirjoitimme oman laajennuksen ja ostimme sen avoimen lähdekoodin. Jos haluat työskennellä jäljittämisen kanssa, jos haluat työskennellä "Jagerin" kanssa PHP:ssä, meillä on laajennus, tervetuloa käyttämään, kuten sanotaan:

  
  
  Meillä on tämä laajennus - se on OpenTracing Api -asiakas, se on tehty php-laajennukseksi, eli sinun on koottava se ja asennettava järjestelmään. Vuosi sitten ei ollut mitään muuta. Nyt on muita asiakkaita, jotka ovat kuin komponentteja. Tässä se riippuu sinusta: joko pumppaatko komponentit säveltäjän avulla tai käytät laajennusta.

  Yritysstandardit

  Puhuimme kolmesta käskystä. Neljäs käsky on standardisoida lähestymistavat. Mitä tämä on? Kyse on tästä:

  
  
  Miksi tässä on sana "yritys"? Ei siksi, että olisimme iso tai byrokraattinen yritys, ei! Halusin käyttää sanaa "yritys" tässä yhteydessä, että jokaisella yrityksellä, jokaisella tuotteella tulee olla omat standardinsa, myös sinulla. Mitä standardeja meillä on?

  
  

  • Meillä on käyttöönottosäännöt. Emme liiku minnekään ilman häntä, emme voi. Otamme käyttöön noin 60 kertaa viikossa, eli käytämme lähes jatkuvasti. Samaan aikaan meillä on esimerkiksi käyttöönottosäännöissä tabu perjantain käyttöönotoista - periaatteessa emme ota käyttöön.
  • Vaadimme asiakirjoja. Yksikään uusi komponentti ei pääse tuotantoon, jos siitä ei ole dokumentaatiota, vaikka se olisi syntynyt RnD-asiantuntijoidemme kynän alla. Vaadimme heiltä käyttöönotto-ohjeet, valvontakartan ja karkean kuvauksen (no, kuten ohjelmoijat voivat kirjoittaa) kuinka tämä komponentti toimii, kuinka se korjataan.
  • Emme ratkaise ongelman syytä, vaan ongelman - mitä jo sanoin. Meille on tärkeää suojata käyttäjää ongelmilta.
  • Meillä on luvat. Emme esimerkiksi pidä seisokkeina, jos menetimme 2 % liikenteestä kahdessa minuutissa. Tämä ei periaatteessa sisälly tilastoihimme. Jos se on enemmän prosentteina tai väliaikainen, laskemme jo.
  • Ja kirjoitamme aina post mortemia. Tapahtuipa meille mitä tahansa, jokainen tilanne, jossa joku käyttäytyi epänormaalisti tuotannossa, heijastuu kuolemaan. Postmortem on asiakirja, johon kirjoitat, mitä sinulle tapahtui, yksityiskohtaisen ajoituksen, mitä teit asian korjaamiseksi ja (tämä on pakollinen lohko!) mitä aiot tehdä estääksesi tämän tapahtuman tulevaisuudessa. Tämä on pakollista ja välttämätöntä myöhempää analyysiä varten.

  Mitä pidetään seisokkeina?

  
  
  Mihin tämä kaikki johti?

  Tämä johti siihen, että (meillä oli tiettyjä vakauden ongelmia, tämä ei sopinut asiakkaille eikä meille) viimeisen 6 kuukauden aikana vakausindikaattorimme oli 99,97. Voimme sanoa, että tämä ei ole kovin paljon. Kyllä meillä on jotain, mihin pyrkiä. Tästä indikaattorista noin puolet on ikään kuin meidän, vaan meidän verkkosovellusten palomuurimme vakaus, joka seisoo edessämme ja jota käytetään palveluna, mutta asiakkaat eivät siitä välitä.

  Opimme nukkumaan yöllä. vihdoinkin! Kuusi kuukautta sitten emme voineet. Ja tähän muistiinpanoon tulosten kanssa haluaisin tehdä yhden huomautuksen. Eilen illalla tuli upea raportti ydinreaktorin ohjausjärjestelmästä. Jos tämän järjestelmän kirjoittaneet ihmiset kuulevat minut, unohda se, mitä sanoin aiheesta "2% ei ole seisokkeja". Sinulle 2 % on seisokkiaikaa, vaikka kahdeksi minuutiksi!

  Siinä kaikki! Sinun kysymyksesi.

  
  

  Tietoja tasapainottajista ja tietokantojen siirrosta

  Kysymys yleisöltä (jäljempänä – B): – Hyvää iltaa. Lämmin kiitos tällaisesta järjestelmänvalvojan raportista! Lyhyt kysymys tasapainottimistasi. Mainitsit, että sinulla on WAF, eli käytät ymmärtääkseni jonkinlaista ulkoista tasapainotinta...

  EK: – Ei, käytämme palveluitamme tasapainottajana. Tässä tapauksessa WAF on meille yksinomaan DDoS-suojaustyökalu.

  in: – Voitko sanoa muutaman sanan tasapainottajista?

  EK: – Kuten jo sanoin, tämä on ryhmä palvelimia avoimessa tilassa. Meillä on nyt 5 vararyhmää, jotka vastaavat yksinomaan... eli palvelin, joka käyttää yksinomaan openrestyä, se vain välittää liikennettä. Näin ollen, jotta ymmärrämme, kuinka paljon meillä on hallussamme: meillä on nyt säännöllinen useiden satojen megabittien liikennevirta. He selviävät, heillä on hyvä olo, he eivät edes rasita itseään.

  in: – Myös yksinkertainen kysymys. Tässä on sininen/vihreä käyttöönotto. Mitä teet esimerkiksi tietokantojen migraatioiden kanssa?

  EK: - Hyvä kysymys! Katso, sinisen/vihreän käyttöönotossa meillä on erilliset jonot jokaiselle riville. Eli jos puhumme tapahtumajonoista, jotka välitetään työntekijältä työntekijälle, siniselle ja vihreälle viivalle on erilliset jonot. Jos puhumme itse tietokannasta, niin olemme tietoisesti kaventuneet niin paljon kuin pystyimme, siirsimme kaiken käytännössä jonoihin, tietokantaan tallennetaan vain pino tapahtumia. Ja tapahtumapinomme on sama kaikilla linjoilla. Tietokannan kanssa tässä yhteydessä: emme erottele sitä siniseen ja vihreään, koska molempien koodiversioiden on tiedettävä, mitä tapahtumalle tapahtuu.

  Ystävät, minulla on myös pieni palkinto kannustavana teitä - kirja. Ja minun pitäisi saada se parhaasta kysymyksestä.

  in: - Hei. Kiitos raportista. Kysymys on tämä. Valvot maksuja, seuraat palveluita, joiden kanssa kommunikoit... Mutta miten valvot, että joku tuli jotenkin maksusivullesi, suoritti maksun ja projekti hyvitti hänelle rahaa? Eli miten valvot, että marssi on tavoitettavissa ja on hyväksynyt takaisinsoittosi?

  EK: – ”Kauppias” on meille tässä tapauksessa täsmälleen sama ulkoinen palvelu kuin maksujärjestelmä. Valvomme kauppiaan vastausnopeutta.

  Tietokannan salauksesta

  in: - Hei. Minulla on hieman asiaan liittyvä kysymys. Sinulla on arkaluonteisia PCI DSS -tietoja. Halusin tietää, kuinka tallennat PAN-numeroita jonoihin, joihin sinun on siirrettävä? Käytätkö jotain salausta? Ja tämä johtaa toiseen kysymykseen: PCI DSS:n mukaan tietokanta on ajoittain salattava uudelleen muutosten sattuessa (järjestelmänvalvojien irtisanominen jne.) - mitä tapahtuu saavutettavuudelle tässä tapauksessa?

  
  
  EK: -Ihana kysymys! Ensinnäkin emme tallenna PAN-tiedostoja jonoihin. Meillä ei periaatteessa ole oikeutta tallentaa PAN:ia minnekään selkeässä muodossa, joten käytämme erikoispalvelua (kutsumme sitä "Kademoniksi") - tämä on palvelu, joka tekee vain yhtä asiaa: se vastaanottaa viestin syötteenä ja lähettää lähettää salatun viestin. Ja tallennamme kaiken tämän salatun viestin kanssa. Näin ollen avaimemme pituus on alle kilotavu, joten tämä on vakavaa ja luotettavaa.

  in: – Tarvitsetko nyt 2 kilotavua?

  EK: – Tuntuu kuin eilen se oli 256... No missä muualla?!

  Näin ollen tämä on ensimmäinen. Ja toiseksi, olemassa oleva ratkaisu tukee uudelleensalausmenettelyä - on olemassa kaksi paria "keksiä" (avaimia), jotka antavat "pakkoja", jotka salaavat (avain ovat avaimia, dek ovat salaavien avainten johdannaisia) . Ja jos menettely aloitetaan (se tapahtuu säännöllisesti, 3 kuukaudesta ± noin), lataamme uuden parin "kakkuja" ja salaamme tiedot uudelleen. Meillä on erilliset palvelut, jotka repivät pois kaiken tiedon ja salaavat sen uudella tavalla; Tiedot tallennetaan sen avaimen tunnisteen viereen, jolla se on salattu. Vastaavasti, heti kun salaamme tiedot uusilla avaimilla, poistamme vanhan avaimen.

  Joskus maksut on suoritettava manuaalisesti...

  in: – Eli jos jostain operaatiosta on saapunut hyvitys, niin puratko sen silti vanhalla avaimella?

  EK: - Joo.

  in: – Sitten vielä yksi pieni kysymys. Kun jonkinlainen vika, kaatuminen tai vaaratilanne tapahtuu, tapahtuma on suoritettava manuaalisesti. Tällainen tilanne on olemassa.

  EK: - Kyllä joskus.

  in: – Mistä saat nämä tiedot? Vai käytkö itse tähän varastoon?

  EK: – Ei, no, tietysti meillä on jonkinlainen back-office-järjestelmä, joka sisältää käyttöliittymän tukeamme varten. Jos emme tiedä, missä tilassa tapahtuma on (esimerkiksi kunnes maksujärjestelmä vastasi aikakatkaisulla), emme tiedä etukäteen, eli annamme lopullisen tilan vain täydellä varmuudella. Tässä tapauksessa määritämme tapahtuman erityistilaan manuaalista käsittelyä varten. Aamulla, seuraavana päivänä, heti kun tuki saa tiedon, että tällaisia ​​tai sellaisia ​​tapahtumia jää maksujärjestelmään, he käsittelevät ne manuaalisesti tässä käyttöliittymässä.

  
  
  in: – Minulla on pari kysymystä. Yksi niistä on PCI DSS -vyöhykkeen jatko: miten kirjataan heidän piirinsä? Tämä kysymys johtuu siitä, että kehittäjä olisi voinut laittaa lokeihin mitä tahansa! Toinen kysymys: miten hotfix-korjaukset otetaan käyttöön? Kahvojen käyttäminen tietokannassa on yksi vaihtoehto, mutta ilmaisia ​​​​hot-fix-korjauksia voi olla - mikä menettely siellä on? Ja kolmas kysymys liittyy todennäköisesti RTO:han, RPO:han. Saatavuus oli 99,97, melkein neljä yhdeksää, mutta ymmärtääkseni sinulla on toinen palvelinkeskus, kolmas palvelinkeskus ja viides palvelinkeskus... Kuinka synkronoit ne, kopioit ne ja kaikki muu?

  EK: - Aloitetaan ensimmäisestä. Oliko ensimmäinen kysymys lokeista? Kun kirjoitamme lokeja, meillä on kerros, joka peittää kaikki arkaluontoiset tiedot. Hän katsoo maskia ja muita kenttiä. Vastaavasti lokeissamme on jo peitetty data ja PCI DSS -piiri. Tämä on yksi testausosaston säännöllisistä tehtävistä. Heidän on tarkistettava jokainen tehtävä, mukaan lukien kirjoittamansa lokit, ja tämä on yksi säännöllisistä tehtävistä koodin tarkistusten aikana, jotta voidaan valvoa, ettei kehittäjä ole kirjoittanut jotain. Tämän myöhemmät tarkastukset tehdään tietoturvaosastolla säännöllisesti noin kerran viikossa: viimeisen päivän lokit otetaan valikoivasti ja ne ajetaan testipalvelimista erityisen skanneri-analysaattorin läpi tarkastamaan kaikki.
  Tietoja hot-fix-korjauksista. Tämä sisältyy käyttöönottosääntöihimme. Meillä on erillinen kohta hotfix-korjauksista. Uskomme, että otamme hotfix-korjauksia käyttöön kellon ympäri, kun tarvitsemme niitä. Heti kun versio on koottu, heti kun se ajetaan, heti kun meillä on artefakti, meillä on järjestelmänvalvoja päivystävä tuen kutsussa, ja hän ottaa sen käyttöön silloin, kun se on tarpeen.

  Noin "neljä yhdeksän". Nyt saamamme luku on todella saavutettu, ja pyrimme siihen toisessa palvelinkeskuksessa. Nyt meillä on toinen datakeskus, ja alamme reitittää niiden välillä, ja tietokeskusten välinen replikointi on todellakin ei-triviaali kysymys. Yritimme ratkaista sen kerralla eri keinoin: yritimme käyttää samaa "Tarantulaa" - se ei toiminut meille, kerron sinulle heti. Siksi päädyimme tilaamaan "sens" manuaalisesti. Itse asiassa jokainen järjestelmämme sovellus suorittaa tarvittavan "muutos tehty" -synkronoinnin datakeskusten välillä asynkronisesti.

  in: – Jos sait toisen, miksi et saanut kolmatta? Koska kenelläkään ei ole vielä aivot jakautuneet...

  EK: – Mutta meillä ei ole Split Brainia. Koska jokaista sovellusta ohjaa multimaster, meille ei ole väliä mihin keskukseen pyyntö tuli. Olemme valmiita siihen, että jos jokin palvelinkeskuksistamme epäonnistuu (luottaudumme tähän) ja keskellä käyttäjän pyyntöä vaihtaa toiseen palvelinkeskukseen, olemme valmiita menettämään tämän käyttäjän. mutta nämä ovat yksiköitä, absoluuttisia yksiköitä.

  in: - Hyvää iltaa. Kiitos raportista. Puhuit debuggeristasi, joka suorittaa joitain testitapahtumia tuotannossa. Mutta kerro meille testitapahtumista! Kuinka syvälle se menee?

  EK: – Se käy läpi koko komponentin täyden syklin. Komponentin osalta testitapahtuman ja tuotantotapahtuman välillä ei ole eroa. Mutta loogisesta näkökulmasta katsottuna tämä on yksinkertaisesti erillinen projekti järjestelmässä, jossa suoritetaan vain testitapahtumia.

  in: - Mistä katkaiset sen? Täällä Core lähetti...

  EK: – Olemme tässä tapauksessa "Kor":n takana testitapahtumissa... Meillä on sellainen asia kuin reititys: "Kor" tietää mihin maksujärjestelmään lähettää - lähetämme väärennetylle maksujärjestelmälle, joka antaa yksinkertaisesti http-signaalin ja siinä kaikki.

  in: – Kerro, kirjoitettiinko hakemuksesi yhdeksi suureksi monoliitiksi vai leikkasitko sen joihinkin palveluihin tai jopa mikropalveluihin?

  EK: – Meillä ei tietenkään ole monoliittia, meillä on palvelukeskeinen sovellus. Vitsailemme, että palvelumme on tehty monoliitteista - ne ovat todella suuria. Sitä on vaikea kutsua mikropalveluiksi, mutta nämä ovat palveluita, joissa hajautettujen koneiden työntekijät toimivat.

  Jos palvelimen palvelu vaarantuu...

  in: – Sitten minulla on seuraava kysymys. Vaikka se olisikin monoliitti, sanoit silti, että sinulla on monia näitä pikapalvelimia, ne kaikki käsittelevät periaatteessa tietoja, ja kysymys kuuluu: "Jos jokin pikapalvelimista tai sovelluksesta vaarantuu, mikä tahansa yksittäinen linkki , onko niissä jonkinlainen kulunvalvonta? Kuka heistä voi tehdä mitä? Mihin minun pitäisi ottaa yhteyttä saadakseni tietoja?

  
  
  EK: - Kyllä ehdottomasti. Turvallisuusvaatimukset ovat varsin vakavat. Ensinnäkin meillä on avoimet dataliikkeet, ja portit ovat vain niitä, joiden kautta ennakoimme liikenteen liikkeen etukäteen. Jos komponentti kommunikoi tietokannan kanssa (esim. Muskulin kanssa) 5-4-3-2:n kautta, vain 5-4-3-2 on sille avoinna, eivätkä muut portit ja muut liikennesuunnat ole käytettävissä. Lisäksi sinun on ymmärrettävä, että tuotannossamme on noin 10 erilaista turvasilmukkaa. Ja vaikka sovellus olisi jotenkin vaarantunut, Jumala varjelkoon, hyökkääjä ei pääse käsiksi palvelimen hallintakonsoliin, koska tämä on eri verkon suojavyöhyke.

  in: – Ja tässä yhteydessä minua kiinnostaa enemmän se, että teillä on tiettyjä sopimuksia palveluiden kanssa - mitä he voivat tehdä, millä "toimilla" he voivat ottaa yhteyttä toisiinsa... Ja normaalissa liikenteessä jotkut tietyt palvelut vaativat joitain rivillä, luettelo "toimista" toisella. He eivät näytä kääntyvän muiden puoleen normaalitilanteessa, ja heillä on muita vastuualueita. Jos jokin niistä vaarantuu, voiko se häiritä kyseisen palvelun "toimintaa"?...

  EK: - Ymmärrän. Jos normaalitilanteessa kommunikointi toisen palvelimen kanssa ylipäänsä sallittiin, niin kyllä. SLA-sopimuksen mukaan emme valvo, että sinulla on vain 3 ensimmäistä "toimintoa" ja 4 "toimintoa". Tämä on todennäköisesti meille tarpeetonta, koska meillä on jo periaatteessa 4-tasoinen suojausjärjestelmä piireille. Puolustamme itseämme mieluummin ääriviivojen avulla kuin sisäpuolen tasolla.

  Kuinka Visa, MasterCard ja Sberbank toimivat

  in: – Haluan selventää kohtaa käyttäjän vaihtamisesta konesalista toiseen. Sikäli kuin tiedän, Visa ja MasterCard käyttävät binäärisynkronista 8583-protokollaa, ja siellä on sekoituksia. Ja halusin tietää, tarkoitammeko nyt vaihtamista – onko se suoraan "Visa" ja "MasterCard" vai ennen maksujärjestelmiä, ennen käsittelyä?

  EK: - Tämä on ennen sekoituksia. Seosemme sijaitsevat samassa palvelinkeskuksessa.

  in: – Onko teillä karkeasti sanottuna yksi yhteyspiste?

  EK: – “Visa” ja “MasterCard” – kyllä. Yksinkertaisesti siksi, että Visa ja MasterCard vaativat varsin vakavia investointeja infrastruktuuriin tehdäkseen erilliset sopimukset esimerkiksi toisen sekoitusparin hankkimiseksi. Ne on varattu yhden konesalin sisällä, mutta jos, Jumala varjelkoon, datakeskuksemme, jossa on sekoituksia Visa- ja MasterCard-yhteyttä varten, kuolee, niin yhteys Visan ja MasterCardin kanssa katkeaa...

  in: – Miten niitä voi varata? Tiedän, että Visa sallii periaatteessa vain yhden yhteyden!

  EK: – He toimittavat laitteet itse. Joka tapauksessa saimme laitteet, jotka ovat sisällä täysin redundantteja.

  in: – Teline on siis heidän Connects Orangestaan?

  EK: - Joo.

  in: – Mutta entä tämä tapaus: jos palvelinkeskuksesi katoaa, miten voit jatkaa sen käyttöä? Vai pysähtyykö liikenne?

  EK: - Ei. Tällöin yksinkertaisesti siirrämme liikenteen toiselle kanavalle, mikä luonnollisesti tulee kalliimmaksi meille ja asiakkaillemme kalliimmaksi. Mutta liikenne ei kulje suoran yhteytemme kautta Visalle, MasterCardille, vaan ehdollisen Sberbankin kautta (erittäin liioiteltu).

  Pyydän villisti anteeksi, jos loukkasin Sberbankin työntekijöitä. Mutta tilastojemme mukaan venäläisten pankkien joukossa Sberbank putoaa useimmiten. Ei mene kuukauttakaan ilman, että jotain putoaisi Sberbankissa.

  
  
  

  Muutamia mainoksia 🙂

  Kiitos, että pysyt kanssamme. Pidätkö artikkeleistamme? Haluatko nähdä mielenkiintoisempaa sisältöä? Tue meitä tekemällä tilauksen tai suosittelemalla ystäville, pilvi VPS kehittäjille alkaen 4.99 dollaria, ainutlaatuinen lähtötason palvelimien analogi, jonka me keksimme sinulle: Koko totuus VPS (KVM) E5-2697 v3 (6 ydintä) 10 Gt DDR4 480 Gt SSD 1 Gbps alkaen 19 dollarista tai kuinka jakaa palvelin? (saatavana RAID1:n ja RAID10:n kanssa, jopa 24 ydintä ja jopa 40 Gt DDR4-muistia).

  Dell R730xd 2 kertaa halvempi Equinix Tier IV -palvelinkeskuksessa Amsterdamissa? Vain täällä 2 x Intel TetraDeca-Core Xeon 2 x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV alkaen 199 dollaria Alankomaissa! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - alkaen 99 dollaria! Lukea Kuinka rakentaa infrastruktuuriyritys. luokkaa Dell R730xd E5-2650 v4 -palvelimilla 9000 euron arvosta penniä vastaan?

Lähde: will.com