Ang bawat tao'y nagsasalita tungkol sa mga proseso ng pag-unlad at pagsubok, pagsasanay sa mga kawani, pagtaas ng pagganyak, ngunit ang mga prosesong ito ay hindi sapat kapag ang isang minuto ng downtime ng serbisyo ay nagkakahalaga ng napakalaking halaga ng pera. Ano ang gagawin kapag nagsasagawa ka ng mga transaksyong pinansyal sa ilalim ng mahigpit na SLA? Paano pataasin ang pagiging maaasahan at fault tolerance ng iyong mga system, pagkuha ng pag-unlad at pagsubok sa labas ng equation?
Ang susunod na HighLoad++ conference ay gaganapin sa Abril 6 at 7, 2020 sa St. Petersburg. Mga detalye at tiket para sa . Nobyembre 9, 18:00. HighLoad++ Moscow 2018, Delhi + Kolkata hall. Mga tesis at .
Evgeniy Kuzovlev (pagkatapos nito - EC): - Mga kaibigan, kumusta! Ang pangalan ko ay Kuzovlev Evgeniy. Ako ay mula sa kumpanyang EcommPay, isang partikular na dibisyon ang EcommPay IT, ang IT division ng grupo ng mga kumpanya. At ngayon ay pag-uusapan natin ang tungkol sa mga downtime - tungkol sa kung paano maiiwasan ang mga ito, tungkol sa kung paano mabawasan ang kanilang mga kahihinatnan kung hindi ito maiiwasan. Ang paksa ay nakasaad tulad ng sumusunod: "Ano ang gagawin kapag ang isang minuto ng downtime ay nagkakahalaga ng $100"? Sa hinaharap, ang aming mga numero ay maihahambing.
Ano ang ginagawa ng EcommPay IT?
Sino tayo? Bakit ako nakatayo dito sa harap mo? Bakit may karapatan akong sabihin sa iyo ang isang bagay dito? At ano ang pag-uusapan natin dito nang mas detalyado?
Ang pangkat ng mga kumpanya ng EcommPay ay isang international acquirer. Pinoproseso namin ang mga pagbabayad sa buong mundo - sa Russia, Europe, Southeast Asia (All Around the World). Mayroon kaming 9 na opisina, 500 empleyado sa kabuuan, at humigit-kumulang kulang sa kalahati sa kanila ay mga espesyalista sa IT. Lahat ng ginagawa natin, lahat ng pinagkakakitaan natin, ginawa natin mismo.
Isinulat namin ang lahat ng aming mga produkto (at mayroon kaming medyo marami sa kanila - sa aming linya ng malalaking produkto ng IT mayroon kaming humigit-kumulang 16 na iba't ibang bahagi) sa aming sarili; Sinusulat natin ang ating sarili, pinaunlad natin ang ating sarili. At sa ngayon ay nagsasagawa kami ng halos isang milyong mga transaksyon sa isang araw (milyon-milyon marahil ang tamang paraan upang sabihin ito). Kami ay isang medyo batang kumpanya - kami ay halos anim na taong gulang lamang.
6 na taon na ang nakalilipas ito ay tulad ng isang startup kapag ang mga lalaki ay dumating kasama ang negosyo. Pinag-isa sila ng isang ideya (walang iba kundi isang ideya), at tumakbo kami. Tulad ng anumang startup, tumakbo kami nang mas mabilis... Para sa amin, ang bilis ay mas mahalaga kaysa sa kalidad.
Sa isang punto huminto kami: napagtanto namin na hindi na kami mabubuhay sa ganoong bilis at sa kalidad na iyon at kailangan muna naming tumuon sa kalidad. Sa sandaling ito, nagpasya kaming magsulat ng bagong platform na magiging tama, nasusukat, at maaasahan. Sinimulan nilang isulat ang platform na ito (nagsimula silang mamuhunan, bumuo ng pag-unlad, pagsubok), ngunit sa isang punto napagtanto nila na ang pag-unlad at pagsubok ay hindi nagpapahintulot sa amin na maabot ang isang bagong antas ng kalidad ng serbisyo.
Gumagawa ka ng isang bagong produkto, inilagay mo ito sa produksyon, ngunit mayroon pa ring mali sa isang lugar. At ngayon ay pag-uusapan natin kung paano maabot ang isang bagong antas ng kalidad (kung paano namin ito ginawa, tungkol sa aming karanasan), pagkuha ng pag-unlad at pagsubok sa labas ng equation; pag-uusapan natin kung ano ang magagamit sa operasyon - kung ano ang maaaring gawin mismo ng operasyon, kung ano ang maiaalok nito sa pagsubok upang maimpluwensyahan ang kalidad.
Mga downtime. Mga utos ng operasyon.
Palaging ang pangunahing pundasyon, ang talagang pag-uusapan natin ngayon ay downtime. Isang nakakatakot na salita. Kung mayroon kaming downtime, lahat ay masama para sa amin. Kami ay tumatakbo upang itaas ito, ang mga admin ay may hawak na server - ipinagbabawal ng Diyos na hindi ito mahulog, tulad ng sinasabi nila sa kantang iyon. Ito ang pag-uusapan natin ngayon.
Nang magsimula kaming magbago ng aming mga diskarte, bumuo kami ng 4 na utos. Ipinakita ko ang mga ito sa mga slide:
Ang mga utos na ito ay medyo simple:
- Mabilis na tukuyin ang problema.
- Alisin mo ito nang mas mabilis.
- Tumulong na maunawaan ang dahilan (sa ibang pagkakataon, para sa mga developer).
- At i-standardize ang mga diskarte.
Nais kong iguhit ang iyong pansin sa punto Blg. 2. Inaalis natin ang problema, hindi nilulutas ito. Ang pagpapasya ay pangalawa. Para sa amin, ang pangunahing bagay ay ang gumagamit ay protektado mula sa problemang ito. Ito ay iiral sa ilang nakahiwalay na kapaligiran, ngunit ang kapaligirang ito ay walang anumang kontak dito. Sa totoo lang, dadaan tayo sa apat na grupo ng mga problemang ito (ang iba ay mas detalyado, ang iba ay hindi gaanong detalye), sasabihin ko sa iyo kung ano ang ginagamit namin, kung ano ang nauugnay na karanasan namin sa mga solusyon.
Pag-troubleshoot: Kailan nangyayari ang mga ito at ano ang gagawin sa mga ito?
Ngunit magsisimula tayo nang wala sa pagkakasunud-sunod, magsisimula tayo sa punto No. 2 - kung paano mabilis na mapupuksa ang problema? May problema - kailangan nating ayusin ito. "Ano ang dapat nating gawin tungkol dito?" - ang pangunahing tanong. At nang magsimula kaming mag-isip tungkol sa kung paano ayusin ang problema, binuo namin para sa aming sarili ang ilang mga kinakailangan na dapat sundin ng pag-troubleshoot.
Upang mabuo ang mga kinakailangang ito, nagpasya kaming tanungin ang aming sarili ang tanong: "Kailan tayo may mga problema"? At ang mga problema, tulad ng nangyari, ay nangyayari sa apat na kaso:
- Kabiguan ng hardware.
- Nabigo ang mga panlabas na serbisyo.
- Pagbabago ng bersyon ng software (parehong deployment).
- Paglago ng paputok na pagkarga.
Hindi natin pag-uusapan ang unang dalawa. Ang isang madepektong paggawa ng hardware ay maaaring malutas nang simple: dapat na nadoble mo ang lahat. Kung ito ay mga disk, ang mga disk ay dapat na tipunin sa RAID; kung ito ay isang server, ang server ay dapat na doblehin; kung mayroon kang imprastraktura ng network, dapat kang magbigay ng pangalawang kopya ng imprastraktura ng network, iyon ay, kunin mo ito at duplicate ito. At kung may mabibigo, lumipat ka sa reserbang kapangyarihan. Mahirap magsabi ng kahit ano dito.
Ang pangalawa ay ang pagkabigo ng mga panlabas na serbisyo. Para sa karamihan, ang sistema ay hindi isang problema sa lahat, ngunit hindi para sa amin. Dahil pinoproseso namin ang mga pagbabayad, kami ay isang aggregator na nakatayo sa pagitan ng user (na nagpasok ng data ng kanyang card) at mga bangko, mga sistema ng pagbabayad (Visa, MasterCard, Mira, atbp.). Ang aming mga panlabas na serbisyo (mga sistema ng pagbabayad, mga bangko) ay may posibilidad na mabigo. Hindi kami o ikaw (kung mayroon kang ganitong mga serbisyo) ang makakaimpluwensya dito.
Ano ang gagawin pagkatapos? Mayroong dalawang mga pagpipilian dito. Una, kung magagawa mo, dapat mong i-duplicate ang serbisyong ito sa ilang paraan. Halimbawa, kung magagawa namin, inililipat namin ang trapiko mula sa isang serbisyo patungo sa isa pa: halimbawa, ang mga card ay naproseso sa pamamagitan ng Sberbank, nagkakaroon ng mga problema ang Sberbank - naglilipat kami ng trapiko [kondisyon] sa Raiffeisen. Ang pangalawang bagay na maaari nating gawin ay mapansin ang pagkabigo ng mga panlabas na serbisyo nang napakabilis, at samakatuwid ay pag-uusapan natin ang tungkol sa bilis ng pagtugon sa susunod na bahagi ng ulat.
Sa katunayan, sa apat na ito, maaari naming partikular na maimpluwensyahan ang pagbabago ng mga bersyon ng software - gumawa ng mga aksyon na hahantong sa isang pagpapabuti sa sitwasyon sa konteksto ng mga deployment at sa konteksto ng paputok na paglaki ng load. Actually, yun ang ginawa namin. Narito, muli, isang maliit na tala...
Sa apat na problemang ito, ang ilan ay nalutas kaagad kung mayroon kang ulap. Kung ikaw ay nasa Microsoft Azhur, Ozone cloud, o ginagamit ang aming mga cloud, mula sa Yandex o Mail, kung gayon kahit isang hardware na malfunction ang magiging problema nila at lahat ay agad na magiging maayos para sa iyo sa konteksto ng isang hardware na malfunction.
Kami ay isang bahagyang hindi kinaugalian na kumpanya. Dito pinag-uusapan ng lahat ang tungkol sa "Kubernets", tungkol sa mga ulap - wala kaming "Kubernets" o ulap. Ngunit mayroon kaming mga rack ng hardware sa maraming data center, at napipilitan kaming manirahan sa hardware na ito, napipilitan kaming maging responsable para sa lahat ng ito. Samakatuwid, pag-uusapan natin ang kontekstong ito. Kaya, tungkol sa mga problema. Ang unang dalawa ay inalis sa mga bracket.
Pagbabago ng bersyon ng software. Mga base
Ang aming mga developer ay walang access sa produksyon. Bakit ganon? Kaya lang, kami ay sertipikado ng PCI DSS, at ang aming mga developer ay walang karapatan na makapasok sa "produkto". Ayan, period. Sa lahat. Samakatuwid, ang responsibilidad sa pag-unlad ay nagtatapos nang eksakto sa sandaling isumite ng development ang build para ilabas.
Ang ating pangalawang batayan na mayroon tayo, na malaki rin ang naitutulong sa atin, ay ang kawalan ng kakaibang undocumented na kaalaman. Sana ganun din sayo. Dahil kung hindi ito ang kaso, magkakaroon ka ng mga problema. Ang mga problema ay lilitaw kapag ang natatanging, hindi dokumentadong kaalaman na ito ay wala sa tamang oras sa tamang lugar. Let's say you have one person who knows how to deploy a specific component - wala doon ang tao, nagbabakasyon o may sakit - yun lang, may mga problema ka.
At ang ikatlong batayan kung saan tayo napunta. Narating namin ito sa pamamagitan ng sakit, dugo, luha - dumating kami sa konklusyon na ang alinman sa aming mga build ay naglalaman ng mga error, kahit na ito ay walang error. Napagpasyahan namin ito para sa aming sarili: kapag nag-deploy kami ng isang bagay, kapag nag-roll kami ng isang bagay sa produksyon, mayroon kaming build na may mga error. Nabuo namin ang mga kinakailangan na dapat matugunan ng aming system.
Mga kinakailangan para sa pagbabago ng bersyon ng software
Mayroong tatlong mga kinakailangan:
- Dapat nating mabilis na ibalik ang deployment.
- Dapat nating bawasan ang epekto ng hindi matagumpay na pag-deploy.
- At kailangan nating mabilis na mag-deploy nang magkatulad.
Eksakto sa ayos na iyon! Bakit? Dahil, una sa lahat, kapag nagde-deploy ng bagong bersyon, ang bilis ay hindi mahalaga, ngunit ito ay mahalaga para sa iyo, kung may mali, upang mabilis na bumalik at magkaroon ng kaunting epekto. Ngunit kung mayroon kang isang hanay ng mga bersyon sa produksyon, kung saan lumalabas na mayroong isang error (sa labas ng asul, walang pag-deploy, ngunit mayroong isang error) - ang bilis ng kasunod na pag-deploy ay mahalaga sa iyo. Ano ang ginawa natin upang matugunan ang mga kahilingang ito? Ginamit namin ang sumusunod na pamamaraan:
Ito ay lubos na kilala, hindi pa namin ito naimbento - ito ay Blue/Green deploy. Ano ito? Dapat ay mayroon kang kopya para sa bawat pangkat ng mga server kung saan naka-install ang iyong mga application. Ang kopya ay "mainit": walang trapiko dito, ngunit anumang oras ang trapikong ito ay maaaring ipadala sa kopyang ito. Ang kopyang ito ay naglalaman ng nakaraang bersyon. At sa oras ng pag-deploy, ilalabas mo ang code sa isang hindi aktibong kopya. Pagkatapos ay inilipat mo ang bahagi ng trapiko (o lahat) sa bagong bersyon. Kaya, upang mabago ang daloy ng trapiko mula sa lumang bersyon patungo sa bago, kailangan mong gawin lamang ang isang aksyon: kailangan mong baguhin ang balancer sa upstream, baguhin ang direksyon - mula sa isang upstream patungo sa isa pa. Ito ay napaka-maginhawa at nalulutas ang problema ng mabilis na paglipat at mabilis na rollback.Narito ang solusyon sa pangalawang tanong ay minimization: maaari kang magpadala lamang ng bahagi ng iyong trapiko sa isang bagong linya, sa isang linya na may bagong code (hayaan ito, halimbawa, 2%). At ang 2% na ito ay hindi 100%! Kung nawala mo ang 100% ng iyong trapiko dahil sa hindi matagumpay na pag-deploy, nakakatakot iyon; kung nawala mo ang 2% ng iyong trapiko, hindi iyon kasiya-siya, ngunit hindi ito nakakatakot. Bukod dito, malamang na hindi ito mapapansin ng mga gumagamit, dahil sa ilang mga kaso (hindi sa lahat) ang parehong gumagamit, pagpindot sa F5, ay dadalhin sa isa pang gumaganang bersyon.
Asul/Berde deploy. Pagruruta
Gayunpaman, hindi lahat ay napakasimpleng "Blue/Green deploy"... Ang lahat ng aming mga bahagi ay maaaring hatiin sa tatlong grupo:
- ito ang frontend (mga pahina ng pagbabayad na nakikita ng aming mga kliyente);
- pagpoproseso ng core;
- adaptor para sa pagtatrabaho sa mga sistema ng pagbabayad (mga bangko, MasterCard, Visa...).
At mayroong isang nuance dito - ang nuance ay nakasalalay sa pagruruta sa pagitan ng mga linya. Kung lilipat ka lang ng 100% ng trapiko, wala kang mga problemang ito. Ngunit kung gusto mong lumipat ng 2%, magsisimula kang magtanong: "Paano ito gagawin?" Ang pinakasimpleng bagay ay straight forward: maaari mong i-set up ang Round Robin sa nginx sa pamamagitan ng random na pagpipilian, at mayroon kang 2% sa kaliwa, 98% sa kanan. Ngunit hindi ito palaging angkop.
Halimbawa, sa aming kaso, ang isang user ay nakikipag-ugnayan sa system na may higit sa isang kahilingan. Normal ito: 2, 3, 4, 5 na kahilingan - maaaring pareho ang iyong mga system. At kung mahalaga para sa iyo na ang lahat ng kahilingan ng user ay napupunta sa parehong linya kung saan dumating ang unang kahilingan, o (pangalawang punto) ang lahat ng kahilingan ng user ay napupunta sa bagong linya pagkatapos ng switch (maaaring nagsimula siyang magtrabaho nang mas maaga sa system, bago ang switch), - kung gayon ang random na pamamahagi na ito ay hindi angkop para sa iyo. Pagkatapos ay mayroong mga sumusunod na pagpipilian:
Ang unang pagpipilian, ang pinakasimpleng, ay batay sa mga pangunahing parameter ng kliyente (IP Hash). Mayroon kang IP, at hinati mo ito mula kanan pakaliwa sa IP address. Pagkatapos ang pangalawang kaso na inilarawan ko ay gagana para sa iyo, kapag naganap ang pag-deploy, maaaring magsimulang magtrabaho ang user sa iyong system, at mula sa sandali ng pag-deploy ang lahat ng mga kahilingan ay mapupunta sa isang bagong linya (sa parehong linya, sabihin).Kung sa ilang kadahilanan ay hindi ito nababagay sa iyo at dapat kang magpadala ng mga kahilingan sa linya kung saan dumating ang paunang kahilingan ng user, pagkatapos ay mayroon kang dalawang pagpipilian...
Unang pagpipilian: maaari kang bumili ng bayad na nginx+. Mayroong isang mekanismo ng Sticky session, na, sa unang kahilingan ng user, ay nagtatalaga ng session sa user at nagbibigkis nito sa isa o isa pang upstream. Ang lahat ng kasunod na kahilingan ng user sa loob ng buhay ng session ay ipapadala sa parehong upstream kung saan nai-post ang session.Hindi ito nababagay sa amin dahil mayroon na kaming regular na nginx. Ang paglipat sa nginx+ ay hindi ito mahal, ngunit ito ay medyo masakit para sa amin at hindi masyadong tama. Ang "Sticks Sessions", halimbawa, ay hindi gumana para sa amin sa simpleng dahilan na ang "Sticks Sessions" ay hindi pinapayagan ang pagruruta batay sa "Either-or". Doon maaari mong tukuyin kung ano ang ginagawa namin ng "Sticks Sessions", halimbawa, sa pamamagitan ng IP address o sa pamamagitan ng IP address at cookies o sa pamamagitan ng postparameter, ngunit ang "Either-o" ay mas kumplikado doon.
Samakatuwid, dumating kami sa ikaapat na pagpipilian. Kumuha kami ng nginx sa mga steroid (ito ay openresty) - ito ang parehong nginx, na karagdagang sumusuporta sa pagsasama ng mga huling script. Maaari kang magsulat ng huling script, bigyan ito ng "open rest", at ang huling script na ito ay isasagawa kapag dumating ang kahilingan ng user.
At isinulat namin, sa katunayan, ang gayong script, itinakda ang aming sarili na "openresti" at sa script na ito ay pinag-uuri namin ang 6 na magkakaibang mga parameter sa pamamagitan ng pagsasama-sama ng "O". Depende sa pagkakaroon ng isa o isa pang parameter, alam namin na ang user ay dumating sa isang pahina o isa pa, isang linya o iba pa.
Asul/Berde deploy. Mga kalamangan at kahinaan
Siyempre, posibleng gawing mas simple ito ng kaunti (gamitin ang parehong "Sticky Sessions"), ngunit mayroon din kaming isang nuance na hindi lamang ang user ang nakikipag-ugnayan sa amin sa loob ng balangkas ng isang pagproseso ng isang transaksyon... Ngunit nakikipag-ugnayan din sa amin ang mga sistema ng pagbabayad: Pagkatapos naming iproseso ang transaksyon (sa pamamagitan ng pagpapadala ng kahilingan sa sistema ng pagbabayad), nakakatanggap kami ng coolback.
At sabihin natin, kung sa loob ng aming circuit ay maipapasa namin ang IP address ng gumagamit sa lahat ng mga kahilingan at hatiin ang mga gumagamit batay sa IP address, kung gayon hindi namin sasabihin ang parehong "Visa": "Dude, kami ay isang retro na kumpanya, tila kami upang maging internasyonal (sa website at sa Russia)... Mangyaring ibigay sa amin ang IP address ng user sa isang karagdagang field, ang iyong protocol ay na-standardize”! Malinaw na hindi sila papayag.
Samakatuwid, hindi ito gumana para sa amin - ginawa namin ang openresty. Alinsunod dito, sa pagruruta nakakuha kami ng ganito:Ang Blue/Green Deployment ay may, nang naaayon, ang mga pakinabang na aking nabanggit at mga disadvantage.
Dalawang disadvantages:
- kailangan mong mag-abala sa pagruruta;
- ang pangalawang pangunahing kawalan ay ang gastos.
Kailangan mo ng dalawang beses sa maraming mga server, kailangan mo ng dalawang beses sa maraming mga mapagkukunan sa pagpapatakbo, kailangan mong gumastos ng dalawang beses na mas maraming pagsisikap upang mapanatili ang buong zoo na ito.
Sa pamamagitan ng paraan, kabilang sa mga pakinabang ay may isa pang bagay na hindi ko nabanggit bago: mayroon kang reserba kung sakaling lumaki ang pag-load. Kung mayroon kang isang sumasabog na paglaki sa pag-load, mayroon kang isang malaking bilang ng mga gumagamit, pagkatapos ay isama mo lang ang pangalawang linya sa 50 hanggang 50 na pamamahagi - at agad kang magkaroon ng x2 server sa iyong cluster hanggang sa malutas mo ang problema ng pagkakaroon ng mas maraming mga server.
Paano gumawa ng mabilis na pag-deploy?
Napag-usapan namin kung paano lutasin ang problema ng pag-minimize at mabilis na pag-rollback, ngunit nananatili ang tanong: "Paano mabilis na mag-deploy?"
Ito ay maikli at simple dito.- Dapat ay mayroon kang CD system (Continuous Delivery) - hindi ka mabubuhay kung wala ito. Kung mayroon kang isang server, maaari kang mag-deploy nang manu-mano. Mayroon kaming humigit-kumulang isa at kalahating libong mga server at isa at kalahating libong mga hawakan, siyempre - maaari kaming magtanim ng isang departamento na kasing laki ng kwartong ito para lang mag-deploy.
- Ang deployment ay dapat na parallel. Kung ang iyong deployment ay sunud-sunod, kung gayon ang lahat ay masama. Normal ang isang server, magde-deploy ka ng isa at kalahating libong server sa buong araw.
- Muli, para sa acceleration, malamang na hindi na ito kailangan. Sa panahon ng pag-deploy, ang proyekto ay karaniwang itinatayo. Mayroon kang isang proyekto sa web, mayroong isang front-end na bahagi (gumawa ka ng isang web pack doon, nag-compile ka ng npm - isang bagay na ganoon), at ang prosesong ito ay karaniwang maikli ang buhay - 5 minuto, ngunit ang 5 minutong ito ay maaaring maging kritikal. Kaya naman, halimbawa, hindi namin ginagawa ito: inalis namin ang 5 minutong ito, nag-deploy kami ng mga artifact.
Ano ang isang artifact? Ang artifact ay isang binuong build kung saan ang lahat ng mga bahagi ng pagpupulong ay nakumpleto na. Iniimbak namin ang artifact na ito sa imbakan ng artifact. Sa isang pagkakataon gumamit kami ng dalawang ganoong storage - ito ay Nexus at ngayon ay jFrog Artifactory). Una naming ginamit ang "Nexus" dahil sinimulan naming isagawa ang diskarteng ito sa mga java application (nababagay ito nang husto). Pagkatapos ay inilagay nila ang ilan sa mga application na nakasulat sa PHP doon; at ang "Nexus" ay hindi na angkop, at samakatuwid ay pinili namin ang jFrog Artefactory, na maaaring gawing artifactorize ang halos lahat. Dumating pa kami sa punto na sa artifact repository na ito ay iniimbak namin ang sarili naming binary packages na kinokolekta namin para sa mga server.
Paglago ng pasabog na pagkarga
Napag-usapan namin ang tungkol sa pagpapalit ng bersyon ng software. Ang susunod na bagay na mayroon kami ay isang paputok na pagtaas sa pagkarga. Dito, malamang na ang ibig kong sabihin ay ang sumasabog na paglaki ng load ay hindi tamang bagay...
Sumulat kami ng isang bagong sistema - ito ay nakatuon sa serbisyo, sunod sa moda, maganda, manggagawa sa lahat ng dako, pila sa lahat ng dako, asynchrony sa lahat ng dako. At sa mga ganitong sistema, maaaring dumaloy ang data sa iba't ibang daloy. Para sa unang transaksyon, maaaring gamitin ang 1st, 3rd, 10th worker, para sa pangalawang transaksyon - ang 2nd, 4th, 5th. At ngayon, sabihin natin, sa umaga mayroon kang daloy ng data na gumagamit ng unang tatlong manggagawa, at sa gabi ay kapansin-pansing nagbabago ito, at ginagamit ng lahat ang iba pang tatlong manggagawa.
At dito lumalabas na kailangan mo kahit papaano sukatin ang mga manggagawa, kailangan mong kahit papaano ay sukatin ang iyong mga serbisyo, ngunit sa parehong oras ay maiwasan ang paglaki ng mapagkukunan.
Tinukoy namin ang aming mga kinakailangan. Ang mga kinakailangang ito ay medyo simple: na mayroong pagtuklas ng Serbisyo, parameterization - lahat ay pamantayan para sa pagbuo ng mga naturang scalable system, maliban sa isang punto - pagbaba ng halaga ng mapagkukunan. Sinabi namin na hindi kami handa na mag-amortize ng mga mapagkukunan upang ang mga server ay magpainit ng hangin. Kinuha namin ang "Consul", kinuha namin ang "Nomad", na namamahala sa aming mga manggagawa.Bakit problema natin ito? Bumalik tayo ng kaunti. Mayroon na kaming humigit-kumulang 70 sistema ng pagbabayad sa likod namin. Sa umaga, dumaan ang trapiko sa Sberbank, pagkatapos ay nahulog ang Sberbank, halimbawa, at inilipat namin ito sa ibang sistema ng pagbabayad. Nagkaroon kami ng 100 manggagawa bago ang Sberbank, at pagkatapos nito kailangan naming dagdagan ang 100 manggagawa para sa isa pang sistema ng pagbabayad. At kanais-nais na mangyari ang lahat ng ito nang walang pakikilahok ng tao. Dahil kung may partisipasyon ng tao, dapat mayroong engineer na nakaupo 24/7, na dapat lang na gumagawa nito, dahil ang mga ganoong kabiguan, kapag 70 system ang nasa likod mo, nangyayari nang regular.
Samakatuwid, tiningnan namin ang Nomad, na may bukas na IP, at isinulat ang aming sariling bagay, Scale-Nomad - ScaleNo, na gumagawa ng humigit-kumulang sa mga sumusunod: sinusubaybayan nito ang paglaki ng pila at binabawasan o pinapataas ang bilang ng mga manggagawa depende sa dynamics ng pila. Kapag ginawa namin ito, naisip namin: "Siguro maaari naming i-open source ito?" Pagkatapos ay tumingin sila sa kanya - siya ay kasing simple ng dalawang kopecks.
Sa ngayon ay hindi pa namin ito open source, ngunit kung biglang pagkatapos ng ulat, pagkatapos na malaman na kailangan mo ng ganoong bagay, kailangan mo ito, ang aking mga contact ay nasa huling slide - mangyaring sumulat sa akin. Kung mayroong kahit 3-5 na tao, i-sponsor namin ito.
Paano ito gumagana? Tingnan natin! Pagtingin sa unahan: sa kaliwang bahagi ay mayroong isang piraso ng aming pagsubaybay: ito ay isang linya, sa itaas ay ang oras ng pagproseso ng kaganapan, sa gitna ay ang bilang ng mga transaksyon, sa ibaba ay ang bilang ng mga manggagawa.Kung titingnan mo, may glitch sa picture na ito. Sa itaas na chart, nag-crash ang isa sa mga chart sa loob ng 45 segundo - bumaba ang isa sa mga sistema ng pagbabayad. Kaagad, dinala ang trapiko sa loob ng 2 minuto at nagsimulang lumaki ang pila sa isa pang sistema ng pagbabayad, kung saan walang mga manggagawa (hindi kami gumamit ng mga mapagkukunan - sa kabaligtaran, itinapon namin nang tama ang mapagkukunan). Hindi namin nais na magpainit - may kaunting bilang, mga 5-10 manggagawa, ngunit hindi nila nakayanan.
Ang huling graph ay nagpapakita ng isang "umbok", na nangangahulugan lamang na ang "Skaleno" ay nadoble ang halagang ito. At pagkatapos, nang medyo bumaba ang graph, binawasan niya ito ng kaunti - ang bilang ng mga manggagawa ay awtomatikong binago. Ganyan gumagana ang bagay na ito. Napag-usapan namin ang tungkol sa point number 2 - "Paano mabilis na mapupuksa ang mga dahilan."
Pagsubaybay. Paano mabilis na matukoy ang problema?
Ngayon ang unang punto ay "Paano mabilis na matukoy ang problema?" Pagsubaybay! Dapat nating maunawaan ang ilang mga bagay nang mabilis. Anong mga bagay ang dapat nating maunawaan nang mabilis?
Tatlong bagay!- Dapat nating maunawaan at maunawaan nang mabilis ang pagganap ng ating sariling mga mapagkukunan.
- Dapat nating mabilis na maunawaan ang mga pagkabigo at subaybayan ang pagganap ng mga system na panlabas sa atin.
- Ang ikatlong punto ay ang pagtukoy ng mga lohikal na pagkakamali. Ito ay kapag ang sistema ay gumagana para sa iyo, ang lahat ay normal ayon sa lahat ng mga tagapagpahiwatig, ngunit may mali.
Marahil ay hindi ko sasabihin sa iyo ang anumang bagay na cool dito. Magiging Captain Obvious ako. Hinanap namin kung ano ang nasa market. Mayroon kaming "fun zoo". Ito ang uri ng zoo na mayroon tayo ngayon:
Ginagamit namin ang Zabbix upang subaybayan ang hardware, upang subaybayan ang mga pangunahing tagapagpahiwatig ng mga server. Ginagamit namin ang Okmeter para sa mga database. Ginagamit namin ang "Grafana" at "Prometheus" para sa lahat ng iba pang indicator na hindi akma sa unang dalawa, ang ilan ay may "Grafana" at "Prometheus", at ang ilan ay may "Grafana" na may "Influx" at Telegraf.Isang taon na ang nakalipas gusto naming gamitin ang New Relic. Ang cool na bagay, magagawa nito ang lahat. Pero hangga't kaya niya ang lahat, sobrang mahal niya. Nang lumaki kami sa dami ng 1,5 libong mga server, isang vendor ang lumapit sa amin at nagsabi: "Magtapos tayo ng isang kasunduan para sa susunod na taon." Tiningnan namin ang presyo at sinabing hindi, hindi namin gagawin iyon. Ngayon ay abandonahin na namin ang New Relic, mayroon kaming humigit-kumulang 15 server na natitira sa ilalim ng pagsubaybay ng New Relic. Ang presyo ay naging ganap na ligaw.
At mayroong isang tool na ipinatupad namin sa aming sarili - ito ay Debugger. Noong una ay tinawag namin itong "Bagger," ngunit pagkatapos ay isang guro sa Ingles ang dumaan, tumawa ng malakas, at pinalitan ito ng pangalan na "Debagger." Ano ito? Ito ay isang tool na, sa katunayan, sa loob ng 15-30 segundo sa bawat bahagi, tulad ng isang "itim na kahon" ng system, ay nagpapatakbo ng mga pagsubok sa pangkalahatang pagganap ng bahagi.
Halimbawa, kung mayroong isang panlabas na pahina (pahina ng pagbabayad), binubuksan lang niya ito at tinitingnan kung ano ang hitsura nito. Kung pinoproseso ito, nagpapadala siya ng pagsubok na "transaksyon" at tinitiyak na darating ang "transaksyon" na ito. Kung ito ay isang koneksyon sa mga sistema ng pagbabayad, nagpapatupad kami ng isang kahilingan sa pagsubok nang naaayon, kung saan namin magagawa, at tinitiyak na maayos ang lahat sa amin.
Anong mga tagapagpahiwatig ang mahalaga para sa pagsubaybay?
Ano ang pangunahing sinusubaybayan natin? Anong mga tagapagpahiwatig ang mahalaga sa atin?
- Ang oras ng pagtugon / RPS sa mga harapan ay isang napakahalagang tagapagpahiwatig. Sinasagot niya agad na may mali sa iyo.
- Ang bilang ng mga naprosesong mensahe sa lahat ng pila.
- Bilang ng mga manggagawa.
- Mga pangunahing sukatan ng kawastuhan.
Ang huling punto ay "negosyo", "negosyo" na sukatan. Kung gusto mong subaybayan ang parehong bagay, kailangan mong tukuyin ang isa o dalawang sukatan na pangunahing tagapagpahiwatig para sa iyo. Ang aming sukatan ay throughput (ito ang ratio ng bilang ng mga matagumpay na transaksyon sa kabuuang daloy ng transaksyon). Kung ang isang bagay ay nagbabago sa loob nito sa pagitan ng 5-10-15 minuto, nangangahulugan ito na mayroon kaming mga problema (kung ito ay nagbabago nang radikal).
Ang hitsura nito para sa amin ay isang halimbawa ng isa sa aming mga board:
Sa kaliwang bahagi ay mayroong 6 na mga graph, ito ay ayon sa mga linya - ang bilang ng mga manggagawa at ang bilang ng mga mensahe sa mga pila. Sa kanang bahagi - RPS, RTS. Nasa ibaba ang parehong sukatan ng "negosyo." At sa sukatan ng "negosyo" makikita natin kaagad na may nangyaring mali sa dalawang gitnang graph... Isa lang itong sistemang nakatayo sa likod natin na bumagsak.Ang pangalawang bagay na kailangan naming gawin ay subaybayan ang pagbagsak ng mga panlabas na sistema ng pagbabayad. Dito kinuha namin ang OpenTracing - isang mekanismo, pamantayan, paradigm na nagbibigay-daan sa iyo upang masubaybayan ang mga distributed system; at binago ito ng kaunti. Sinasabi ng karaniwang paradigm ng OpenTracing na bumubuo kami ng isang bakas para sa bawat indibidwal na kahilingan. Hindi namin ito kailangan, at binalot namin ito sa isang buod, bakas ng pagsasama-sama. Gumawa kami ng tool na nagbibigay-daan sa amin na subaybayan ang bilis ng mga system sa likod namin.
Ipinapakita sa amin ng graph na nagsimulang tumugon ang isa sa mga sistema ng pagbabayad sa loob ng 3 segundo - mayroon kaming mga problema. Bukod dito, ang bagay na ito ay tutugon kapag nagsimula ang mga problema, sa pagitan ng 20-30 segundo.At ang ikatlong klase ng mga error sa pagsubaybay na umiiral ay ang lohikal na pagsubaybay.
Sa totoo lang, hindi ko alam kung ano ang iguguhit sa slide na ito, dahil matagal na kaming naghahanap sa merkado para sa isang bagay na babagay sa amin. Wala kaming nahanap, kaya kinailangan naming gawin ito sa aming sarili.
Ano ang ibig kong sabihin sa lohikal na pagsubaybay? Buweno, isipin: ginagawa mo ang iyong sarili ng isang sistema (halimbawa, isang Tinder clone); ginawa mo ito, inilunsad ito. Ang matagumpay na manager na si Vasya Pupkin ay inilagay ito sa kanyang telepono, nakakita ng isang batang babae doon, nagustuhan siya ... at ang katulad ay hindi napupunta sa batang babae - ang katulad ay napupunta sa security guard na si Mikhalych mula sa parehong sentro ng negosyo. Bumaba ang manager, at pagkatapos ay nagtataka: "Bakit ang security guard na ito na si Mikhalych ay ngumiti nang napakasaya sa kanya?"Sa ganitong mga sitwasyon... Para sa amin, ang sitwasyong ito ay medyo naiiba, dahil (isinulat ko) ito ay isang pagkawala ng reputasyon na hindi direktang humahantong sa mga pagkalugi sa pananalapi. Ang aming sitwasyon ay kabaligtaran: maaari kaming magdusa ng direktang pagkalugi sa pananalapi - halimbawa, kung nagsagawa kami ng isang transaksyon bilang matagumpay, ngunit ito ay hindi matagumpay (o kabaliktaran). Kinailangan kong magsulat ng sarili kong tool na sumusubaybay sa bilang ng mga matagumpay na transaksyon sa paglipas ng panahon gamit ang mga indicator ng negosyo. Wala akong nakitang anuman sa merkado! Ito mismo ang ideyang nais kong iparating. Walang anuman sa merkado upang malutas ang ganitong uri ng problema.
Ito ay tungkol sa kung paano mabilis na matukoy ang problema.
Paano matukoy ang mga dahilan para sa pag-deploy
Ang pangatlong pangkat ng mga problema na ating nalutas ay pagkatapos nating matukoy ang problema, pagkatapos nating maalis ito, makabubuting maunawaan ang dahilan ng pag-unlad, para sa pagsubok, at gumawa ng isang bagay tungkol dito. Alinsunod dito, kailangan nating mag-imbestiga, kailangan nating itaas ang mga log.
Kung pinag-uusapan natin ang tungkol sa mga log (ang pangunahing dahilan ay mga log), ang karamihan sa ating mga log ay nasa ELK Stack - halos lahat ay may pareho. Para sa ilan, maaaring wala ito sa ELK, ngunit kung magsusulat ka ng mga log sa gigabytes, sa lalong madaling panahon mapupunta ka sa ELK. Sinusulat namin ang mga ito sa terabytes.
May problema dito. Inayos namin ito, itinama ang error para sa gumagamit, nagsimulang maghukay kung ano ang naroroon, umakyat sa Kibana, ipinasok ang id ng transaksyon doon at nakakuha ng footcloth na tulad nito (nagpapakita ng maraming). At talagang walang malinaw sa footcloth na ito. Bakit? Oo, dahil hindi malinaw kung aling bahagi ang nabibilang sa kung aling manggagawa, kung aling bahagi ang nabibilang sa kung aling bahagi. At sa sandaling iyon napagtanto namin na kailangan namin ang pagsubaybay - ang parehong OpenTracing na binanggit ko.Naisip namin ito noong isang taon, ibinaling ang aming pansin sa merkado, at mayroong dalawang tool doon - "Zipkin" at "Jaeger". "Jager" ay sa katunayan tulad ng isang ideological tagapagmana, isang ideological kahalili ng "Zipkin". Ang lahat ay mabuti sa Zipkin, maliban na hindi ito alam kung paano pinagsama-sama, hindi ito alam kung paano isama ang mga log sa bakas, tanging oras na bakas. At sinuportahan ito ni "Jager".
Tiningnan namin ang "Jager": maaari kang mag-instrumento ng mga aplikasyon, maaari kang sumulat sa Api (ang pamantayan ng Api para sa PHP sa oras na iyon, gayunpaman, ay hindi naaprubahan - ito ay isang taon na ang nakakaraan, ngunit ngayon ay naaprubahan na ito), ngunit doon ay talagang walang kliyente. "Okay," naisip namin, at nagsulat ng sarili naming kliyente. Ano ang nakuha namin? Ito ay halos kung ano ang hitsura nito:
Sa Jaeger, ginagawa ang mga span para sa bawat mensahe. Iyon ay, kapag binuksan ng isang gumagamit ang system, nakikita niya ang isa o dalawang bloke para sa bawat papasok na kahilingan (1-2-3 - ang bilang ng mga papasok na kahilingan mula sa gumagamit, ang bilang ng mga bloke). Upang gawing mas madali para sa mga user, nagdagdag kami ng mga tag sa mga log at time traces. Alinsunod dito, sa kaso ng isang error, markahan ng aming application ang log ng naaangkop na tag ng Error. Maaari kang mag-filter ayon sa Error tag at tanging mga span na naglalaman ng block na ito na may error ang ipapakita. Ganito ang hitsura kung palawakin natin ang span:
Sa loob ng span ay may isang hanay ng mga bakas. Sa kasong ito, ito ay tatlong pagsubok na bakas, at ang ikatlong bakas ay nagsasabi sa amin na may naganap na error. Kasabay nito, narito ang isang bakas ng oras: mayroon kaming sukat ng oras sa itaas, at nakikita namin kung anong agwat ng oras ito o ang log na iyon ay naitala.Alinsunod dito, naging maayos ang mga bagay para sa amin. Nagsulat kami ng sarili naming extension at open sourced namin ito. Kung gusto mong magtrabaho kasama ang pagsubaybay, kung gusto mong magtrabaho kasama ang "Jager" sa PHP, nandiyan ang aming extension, malugod na gamitin, tulad ng sinasabi nila:
Mayroon kaming extension na ito - ito ay isang kliyente para sa OpenTracing Api, ito ay ginawa bilang php-extention, iyon ay, kakailanganin mong tipunin ito at i-install ito sa system. Isang taon na ang nakalipas ay walang pinagkaiba. Ngayon ay may iba pang mga kliyente na tulad ng mga sangkap. Ito ang bahala sa iyo: maaari mong i-pump out ang mga bahagi gamit ang isang kompositor, o gagamit ka ng extension na nasa iyo.Mga pamantayan ng korporasyon
Napag-usapan namin ang tungkol sa tatlong utos. Ang ikaapat na utos ay i-standardize ang mga diskarte. Tungkol saan ito? Ito ay tungkol dito:
Bakit nandito ang salitang "corporate"? Hindi dahil malaki o bureaucratic company tayo, hindi! Nais kong gamitin ang salitang "corporate" dito sa konteksto na ang bawat kumpanya, bawat produkto ay dapat magkaroon ng sarili nitong mga pamantayan, kasama ka. Anong mga pamantayan ang mayroon tayo?
- Mayroon kaming mga regulasyon sa pag-deploy. Hindi kami gumagalaw kung saan wala siya, hindi namin magagawa. Nag-deploy kami ng humigit-kumulang 60 beses sa isang linggo, ibig sabihin, halos palagi kaming nagde-deploy. Kasabay nito, mayroon kaming, halimbawa, sa mga regulasyon sa pag-deploy ng isang bawal sa pag-deploy sa Biyernes - sa prinsipyo, hindi kami nagde-deploy.
- Nangangailangan kami ng dokumentasyon. Wala ni isang bagong bahagi ang nakapasok sa produksyon kung walang dokumentasyon para dito, kahit na ipinanganak ito sa ilalim ng panulat ng aming mga RnD specialist. Nangangailangan kami mula sa kanila ng mga tagubilin sa pag-deploy, isang mapa ng pagsubaybay at isang magaspang na paglalarawan (na rin, tulad ng maaaring isulat ng mga programmer) kung paano gumagana ang bahaging ito, kung paano ito i-troubleshoot.
- Hindi namin nalutas ang sanhi ng problema, ngunit ang problema - kung ano ang nasabi ko na. Mahalaga para sa amin na protektahan ang gumagamit mula sa mga problema.
- May clearances kami. Halimbawa, hindi namin ito itinuturing na downtime kung nawalan kami ng 2% ng trapiko sa loob ng dalawang minuto. Ito ay karaniwang hindi kasama sa aming mga istatistika. Kung ito ay higit pa sa porsyento o pansamantala, binibilang na natin.
- At palagi kaming nagsusulat ng mga postmortem. Anuman ang mangyari sa atin, ang anumang sitwasyon kung saan ang isang tao ay hindi kumilos nang abnormal sa produksyon ay makikita sa post-mortem. Ang postmortem ay isang dokumento kung saan isinusulat mo kung ano ang nangyari sa iyo, isang detalyadong timing, kung ano ang ginawa mo para iwasto ito at (ito ay isang mandatoryong block!) kung ano ang iyong gagawin upang maiwasan itong mangyari sa hinaharap. Ito ay sapilitan at kinakailangan para sa kasunod na pagsusuri.
Ano ang itinuturing na downtime?
Ano ang humantong sa lahat ng ito?Ito ay humantong sa katotohanan na (mayroon kaming ilang mga problema sa katatagan, hindi ito angkop sa alinman sa mga kliyente o sa amin) sa nakalipas na 6 na buwan ang aming tagapagpahiwatig ng katatagan ay 99,97. Maaari nating sabihin na ito ay hindi masyadong marami. Oo, mayroon tayong dapat pagsikapan. Sa tagapagpahiwatig na ito, humigit-kumulang kalahati ay ang katatagan, na parang, hindi sa amin, ngunit sa aming web application firewall, na nakatayo sa harap namin at ginagamit bilang isang serbisyo, ngunit ang mga kliyente ay walang pakialam tungkol dito.
Natuto kaming matulog sa gabi. Sa wakas! Anim na buwan na ang nakalipas hindi namin magawa. At sa talang ito kasama ang mga resulta, nais kong gumawa ng isang tala. Kagabi nagkaroon ng magandang ulat tungkol sa control system para sa isang nuclear reactor. Kung maririnig ako ng mga taong sumulat ng system na ito, mangyaring kalimutan ang tungkol sa sinabi ko tungkol sa "2% ay hindi downtime." Para sa iyo, ang 2% ay downtime, kahit na dalawang minuto!
Iyon lang! Ang mga tanong mo.
Tungkol sa mga balancer at paglipat ng database
Tanong mula sa madla (simula dito – B): – Magandang gabi. Maraming salamat sa ganitong ulat ng admin! Isang maikling tanong tungkol sa iyong mga tagabalanse. Nabanggit mo na mayroon kang WAF, ibig sabihin, sa pagkakaintindi ko, gumagamit ka ng ilang uri ng external balancer...
EK: – Hindi, ginagamit namin ang aming mga serbisyo bilang balancer. Sa kasong ito, ang WAF ay eksklusibong isang tool sa proteksyon ng DDoS para sa amin.
SA: – Maaari ka bang magsabi ng ilang salita tungkol sa mga tagabalanse?
EK: – Tulad ng sinabi ko na, ito ay isang grupo ng mga server sa openresty. Mayroon na tayong 5 reserbang grupo na eksklusibong tumutugon... ibig sabihin, isang server na eksklusibong nagpapatakbo ng openresty, ito ay nag-proxy lamang ng trapiko. Alinsunod dito, upang maunawaan kung gaano kalaki ang hawak natin: mayroon na tayong regular na daloy ng trapiko na ilang daang megabits. Nakayanan nila, maganda ang pakiramdam nila, hindi nila pinipilit ang kanilang sarili.
SA: - Isang simpleng tanong din. Narito ang Blue/Green deployment. Ano ang ginagawa mo, halimbawa, sa mga paglilipat ng database?
EK: - Magandang tanong! Tingnan, sa Blue/Green deployment mayroon kaming hiwalay na mga pila para sa bawat linya. Iyon ay, kung pinag-uusapan natin ang tungkol sa mga queues ng kaganapan na ipinapadala mula sa manggagawa patungo sa manggagawa, mayroong magkahiwalay na pila para sa asul na linya at para sa berdeng linya. Kung pinag-uusapan natin ang tungkol sa database mismo, pagkatapos ay sadyang pinaliit namin ito hangga't maaari, inilipat ang lahat sa halos mga pila; sa database ay nag-iimbak lamang kami ng isang stack ng mga transaksyon. At ang aming stack ng transaksyon ay pareho para sa lahat ng mga linya. Gamit ang database sa kontekstong ito: hindi namin ito hinahati sa asul at berde, dahil dapat alam ng parehong bersyon ng code kung ano ang nangyayari sa transaksyon.
Mga kaibigan, mayroon din akong kaunting premyo na mag-uudyok sa inyo - isang libro. At ako ay dapat na iginawad para sa pinakamahusay na tanong.
SA: - Kamusta. Salamat sa ulat. Ang tanong ay ito. Sinusubaybayan mo ang mga pagbabayad, sinusubaybayan mo ang mga serbisyo kung saan ka nakikipag-usap... Ngunit paano mo sinusubaybayan upang kahit papaano ay dumating ang isang tao sa iyong pahina ng pagbabayad, nagbayad, at na-kredito siya ng proyekto ng pera? Ibig sabihin, paano mo masusubaybayan na available ang marchant at tinanggap ang iyong callback?
EK: – Ang "Merchant" para sa amin sa kasong ito ay eksaktong parehong panlabas na serbisyo gaya ng sistema ng pagbabayad. Sinusubaybayan namin ang bilis ng pagtugon ng merchant.
Tungkol sa pag-encrypt ng database
SA: - Kamusta. Mayroon akong bahagyang nauugnay na tanong. Mayroon kang PCI DSS na sensitibong data. Nais kong malaman kung paano ka nag-iimbak ng mga PAN sa mga pila na kailangan mong ilipat? Gumagamit ka ba ng anumang pag-encrypt? At ito ay humahantong sa pangalawang tanong: ayon sa PCI DSS, kinakailangan na pana-panahong muling i-encrypt ang database sa kaso ng mga pagbabago (pag-alis ng mga administrator, atbp.) - ano ang mangyayari sa accessibility sa kasong ito?
EK: - Kahanga-hangang tanong! Una, hindi kami nag-iimbak ng mga PAN sa mga pila. Wala kaming karapatang mag-imbak ng PAN kahit saan sa malinaw na anyo, sa prinsipyo, kaya gumagamit kami ng isang espesyal na serbisyo (tinatawag namin itong "Kademon") - ito ay isang serbisyo na gumagawa lamang ng isang bagay: tumatanggap ito ng isang mensahe bilang input at nagpapadala out ng isang naka-encrypt na mensahe. At iniimbak namin ang lahat gamit ang naka-encrypt na mensaheng ito. Alinsunod dito, ang haba ng aming key ay mas mababa sa isang kilobyte, upang ito ay seryoso at maaasahan.SA: – Kailangan mo ba ng 2 kilobytes ngayon?
EK: – Parang kahapon lang 256... Eh saan pa?!
Alinsunod dito, ito ang una. At pangalawa, ang solusyon na umiiral, sinusuportahan nito ang pamamaraan ng muling pag-encrypt - mayroong dalawang pares ng "keks" (mga susi), na nagbibigay ng "deck" na naka-encrypt (ang susi ay ang mga susi, ang dek ay mga derivatives ng mga susi na naka-encrypt) . At kung sinimulan ang pamamaraan (regular itong nangyayari, mula 3 buwan hanggang ± ilan), nagda-download kami ng bagong pares ng "mga cake", at muling ini-encrypt namin ang data. Mayroon kaming hiwalay na mga serbisyo na kumukuha ng lahat ng data at i-encrypt ito sa isang bagong paraan; Ang data ay naka-imbak sa tabi ng identifier ng key kung saan ito naka-encrypt. Alinsunod dito, sa sandaling i-encrypt namin ang data gamit ang mga bagong key, tatanggalin namin ang lumang key.
Kung minsan ang mga pagbabayad ay kailangang gawin nang manu-mano...
SA: – Ibig sabihin, kung may dumating na refund para sa ilang operasyon, ide-decrypt mo pa rin ba ito gamit ang lumang key?
EK: - Oo.
SA: - Pagkatapos ng isa pang maliit na tanong. Kapag naganap ang ilang uri ng kabiguan, pagkahulog, o insidente, kinakailangang manu-manong itulak ang transaksyon. May ganoong sitwasyon.
EK: - Oo minsan.
SA: – Saan mo nakukuha ang data na ito? O ikaw ba mismo ang pumupunta sa storage facility na ito?
EK: – Hindi, siyempre, mayroon kaming ilang uri ng back-office system na naglalaman ng interface para sa aming suporta. Kung hindi namin alam kung anong status ang transaksyon (halimbawa, hanggang sa tumugon ang sistema ng pagbabayad nang may timeout), hindi namin alam ang priori, ibig sabihin, itinatalaga namin ang panghuling status nang buong kumpiyansa. Sa kasong ito, itinatalaga namin ang transaksyon sa isang espesyal na katayuan para sa manu-manong pagproseso. Sa umaga, sa susunod na araw, sa sandaling matanggap ng suporta ang impormasyon na nananatili ang ganoon at ganoong mga transaksyon sa sistema ng pagbabayad, manu-mano nilang pinoproseso ang mga ito sa interface na ito.
SA: - Mayroon akong ilang mga katanungan. Isa sa mga ito ay ang pagpapatuloy ng PCI DSS zone: paano mo i-log ang kanilang circuit? Ang tanong na ito ay dahil maaaring ilagay ng developer ang anumang bagay sa mga log! Pangalawang tanong: paano mo ilalabas ang mga hotfix? Ang paggamit ng mga hawakan sa database ay isang opsyon, ngunit maaaring may mga libreng hot-fix - ano ang pamamaraan doon? At ang pangatlong tanong ay malamang na may kaugnayan sa RTO, RPO. Ang iyong availability ay 99,97, halos apat na siyam, ngunit sa pagkakaintindi ko, mayroon kang pangalawang data center, pangatlong data center, at ikalimang data center... Paano mo isi-synchronize ang mga ito, ginagaya ang mga ito, at lahat ng iba pa?EK: - Magsimula tayo sa una. Ang unang tanong ba ay tungkol sa mga log? Kapag nagsusulat kami ng mga log, mayroon kaming layer na nagtatakip sa lahat ng sensitibong data. Tinitingnan niya ang maskara at ang mga karagdagang field. Alinsunod dito, ang aming mga log ay lumalabas na may naka-mask na data at isang PCI DSS circuit. Ito ay isa sa mga regular na gawain na itinalaga sa testing department. Kinakailangan nilang suriin ang bawat gawain, kabilang ang mga log na kanilang isinusulat, at ito ay isa sa mga regular na gawain sa panahon ng mga pagsusuri ng code, upang makontrol na ang developer ay hindi sumulat ng isang bagay. Ang mga kasunod na pagsusuri nito ay regular na isinasagawa ng departamento ng seguridad ng impormasyon tungkol sa isang beses sa isang linggo: ang mga log para sa huling araw ay piling kinuha at sila ay pinapatakbo sa pamamagitan ng isang espesyal na scanner-analyzer mula sa mga server ng pagsubok upang suriin ang lahat.
Tungkol sa mga hot-fix. Kasama ito sa aming mga regulasyon sa pag-deploy. Mayroon kaming hiwalay na sugnay tungkol sa mga hotfix. Naniniwala kami na naglalagay kami ng mga hotfix sa buong orasan kapag kailangan namin ito. Sa sandaling ma-assemble ang bersyon, sa sandaling ito ay tumakbo, sa sandaling mayroon kaming artifact, mayroon kaming isang administrator ng system na naka-duty sa isang tawag mula sa suporta, at ini-deploy niya ito sa sandaling ito ay kinakailangan.Tungkol sa "apat na siyam". Ang figure na mayroon kami ngayon ay tunay na nakamit, at sinikap namin ito sa isa pang data center. Ngayon ay mayroon na kaming pangalawang data center, at nagsisimula na kaming mag-ruta sa pagitan nila, at ang isyu ng cross-data center replication ay talagang isang hindi maliit na tanong. Sinubukan naming lutasin ito sa isang pagkakataon gamit ang iba't ibang paraan: sinubukan naming gamitin ang parehong "Tarantula" - hindi ito gumana para sa amin, sasabihin ko sa iyo kaagad. Iyon ang dahilan kung bakit namin natapos ang pag-order ng "sens" nang manu-mano. Sa katunayan, ang bawat application sa aming system ay nagpapatakbo ng kinakailangang "pagbabago - tapos na" na pag-synchronize sa pagitan ng mga data center nang asynchronous.
SA: - Kung nakakuha ka ng pangalawa, bakit hindi ka nakakuha ng pangatlo? Dahil wala pang may split-brain...
EK: – Ngunit wala kaming Split Brain. Dahil sa katotohanan na ang bawat aplikasyon ay hinihimok ng isang multimaster, hindi mahalaga sa amin kung saang sentro napunta ang kahilingan. Handa kami sa katotohanan na kung mabigo ang isa sa aming mga data center (umaasa kami dito) at sa gitna ng isang kahilingan ng user ay lumipat sa pangalawang data center, handa kaming mawala ang user na ito, sa katunayan; ngunit ang mga ito ay magiging mga yunit, ganap na mga yunit.
SA: - Magandang gabi. Salamat sa ulat. Napag-usapan mo ang tungkol sa iyong debugger, na nagpapatakbo ng ilang pagsubok na transaksyon sa produksyon. Ngunit sabihin sa amin ang tungkol sa mga pagsubok na transaksyon! Gaano ito kalalim?
EK: – Dumadaan ito sa buong cycle ng buong component. Para sa isang bahagi, walang pagkakaiba sa pagitan ng isang pagsubok na transaksyon at isang transaksyon sa produksyon. Ngunit mula sa isang lohikal na pananaw, ito ay isang hiwalay na proyekto lamang sa system, kung saan ang mga pagsubok na transaksyon lamang ang pinapatakbo.
SA: -Saan mo ito puputulin? Dito ipinadala ni Core...
EK: – Nasa likod namin si “Kor” sa kasong ito para sa mga pagsubok na transaksyon... Mayroon kaming isang bagay tulad ng pagruruta: Alam ng “Kor” kung saang sistema ng pagbabayad ipapadala - ipinapadala namin sa isang pekeng sistema ng pagbabayad, na nagbibigay lamang ng signal ng http at yun lang.
SA: – Sabihin sa akin, mangyaring, ang iyong aplikasyon ay nakasulat sa isang malaking monolith, o pinutol mo ba ito sa ilang mga serbisyo o kahit na mga microservice?
EK: – Wala kaming monolith, siyempre, mayroon kaming service-oriented na application. Biro namin na ang aming serbisyo ay gawa sa mga monolith - sila ay talagang medyo malaki. Mahirap tawagan itong mga microservice, ngunit ito ay mga serbisyo kung saan gumagana ang mga manggagawa ng mga distributed machine.
Kung nakompromiso ang serbisyo sa server...
SA: - Pagkatapos ay mayroon akong susunod na tanong. Kahit na ito ay isang monolith, sinabi mo pa rin na mayroon kang marami sa mga instant server na ito, lahat sila ay karaniwang nagpoproseso ng data, at ang tanong ay: "Sa kaganapan ng isang kompromiso ng isa sa mga instant server o isang application, anumang indibidwal na link , mayroon ba silang ilang uri ng access control? Sino sa kanila ang kayang gawin? Sino ang dapat kong kontakin para sa anong impormasyon?
EK: - Oo, tiyak. Ang mga kinakailangan sa seguridad ay medyo seryoso. Una, mayroon kaming mga bukas na paggalaw ng data, at ang mga port ay ang mga daan lamang kung saan inaasahan namin ang paggalaw ng trapiko nang maaga. Kung ang isang bahagi ay nakikipag-ugnayan sa database (sabihin, sa Muskul) sa pamamagitan ng 5-4-3-2, 5-4-3-2 lamang ang magbubukas dito, at ang iba pang mga port at iba pang direksyon ng trapiko ay hindi magagamit. Bilang karagdagan, kailangan mong maunawaan na sa aming produksyon mayroong mga 10 iba't ibang mga loop ng seguridad. At kahit na ang application ay sa paanuman ay nakompromiso, ipinagbawal ng Diyos, ang umaatake ay hindi ma-access ang server management console, dahil ito ay ibang network security zone.SA: – At sa kontekstong ito, ang mas kawili-wili sa akin ay mayroon kang ilang partikular na kontrata sa mga serbisyo - kung ano ang magagawa nila, sa pamamagitan ng kung anong "mga aksyon" ang maaari nilang kontakin ang isa't isa... At sa isang normal na daloy, humihiling ang ilang partikular na serbisyo ng ilang row, isang listahan ng "mga aksyon" sa kabilang linya. Mukhang hindi sila bumaling sa iba sa isang normal na sitwasyon, at mayroon silang iba pang mga lugar ng responsibilidad. Kung ang isa sa kanila ay nakompromiso, magagawa ba nitong makagambala sa "mga aksyon" ng serbisyong iyon?..
EK: - Naiintindihan ko. Kung sa isang normal na sitwasyon sa isa pang server komunikasyon ay pinahihintulutan sa lahat, pagkatapos ay oo. Ayon sa kontrata ng SLA, hindi namin sinusubaybayan na pinapayagan ka lamang sa unang 3 "pagkilos", at hindi ka pinapayagan sa 4 na "pagkilos". Ito ay malamang na kalabisan para sa amin, dahil mayroon na kaming 4-level na sistema ng proteksyon, sa prinsipyo, para sa mga circuit. Mas gusto naming ipagtanggol ang aming sarili sa mga contour, kaysa sa antas ng insides.
Paano gumagana ang Visa, MasterCard at Sberbank
SA: – Gusto kong linawin ang isang punto tungkol sa paglipat ng user mula sa isang data center patungo sa isa pa. Sa pagkakaalam ko, gumagana ang Visa at MasterCard gamit ang 8583 binary synchronous protocol, at may mga halo doon. At gusto kong malaman, ngayon ang ibig naming sabihin ay paglipat - direkta ba itong "Visa" at "MasterCard" o bago ang mga sistema ng pagbabayad, bago iproseso?
EK: - Ito ay bago ang mga halo. Ang aming mga mix ay matatagpuan sa parehong data center.
SA: – Sa halos pagsasalita, mayroon ka bang isang punto ng koneksyon?
EK: – “Visa” at “MasterCard” - oo. Dahil lang sa Visa at MasterCard ay nangangailangan ng medyo seryosong pamumuhunan sa imprastraktura upang tapusin ang magkahiwalay na kontrata para makakuha ng pangalawang pares ng mga mix, halimbawa. Ang mga ito ay nakalaan sa loob ng isang data center, ngunit kung, huwag sana, ang aming data center, kung saan may mga halo para sa pagkonekta sa Visa at MasterCard, ay namatay, pagkatapos ay magkakaroon kami ng koneksyon sa Visa at MasterCard na nawala...
SA: – Paano sila maipareserba? Alam ko na pinapayagan lamang ng Visa ang isang koneksyon sa prinsipyo!
EK: – Sila mismo ang nagbibigay ng kagamitan. Sa anumang kaso, nakatanggap kami ng kagamitan na ganap na kalabisan sa loob.
SA: – Kaya ang stand ay mula sa kanilang Connects Orange?..
EK: - Oo.
SA: – Ngunit ano ang tungkol sa kasong ito: kung mawala ang iyong data center, paano mo ito patuloy na magagamit? O huminto lang ang traffic?
EK: - Hindi. Sa kasong ito, ililipat lang namin ang trapiko sa ibang channel, na natural, magiging mas mahal para sa amin at mas mahal para sa aming mga kliyente. Ngunit ang trapiko ay hindi dadaan sa aming direktang koneksyon sa Visa, MasterCard, ngunit sa pamamagitan ng kondisyon na Sberbank (napaka-exaggerated).
Humihingi ako ng paumanhin kung nasaktan ko ang mga empleyado ng Sberbank. Ngunit ayon sa aming mga istatistika, kabilang sa mga bangko ng Russia, ang Sberbank ay madalas na bumabagsak. Hindi lumilipas ang isang buwan nang walang nahuhulog sa Sberbank.
Ilang ad 🙂
Salamat sa pananatili sa amin. Gusto mo ba ang aming mga artikulo? Gustong makakita ng mas kawili-wiling nilalaman? Suportahan kami sa pamamagitan ng pag-order o pagrekomenda sa mga kaibigan, , isang natatanging analogue ng mga entry-level na server, na inimbento namin para sa iyo: (magagamit sa RAID1 at RAID10, hanggang 24 na core at hanggang 40GB DDR4).
Dell R730xd 2x na mas mura sa Equinix Tier IV data center sa Amsterdam? Dito lang sa Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mula $99! Basahin ang tungkol sa
Pinagmulan: www.habr.com