<\/a><\/noindex>Teenuse k\u00e4ivitamisel m\u00f5istsime, et k\u00f5ige t\u00e4htsam on tagada talitlush\u00e4ired, usaldusv\u00e4\u00e4rsus ja teenuse pidev k\u00e4ttesaadavus, sest kui teil on lihtsalt tavaline veebisait, n\u00e4iteks pood, ja see kukub tunni ajaks maha \u2013 kannatate ainult teie ise, kaotate tellimusi, kliente, kuid teie kliendi jaoks ei ole see v\u00e4ga kriitiline. Ta on k\u00fcll pettunud, kuid l\u00e4heb ja ostab teiselt veebilehelt. Kui aga see on rakendus, millega on seotud kogu t\u00f6\u00f6 ettev\u00f5ttes, suhtlemine, lahendused, siis on k\u00f5ige olulisem v\u00f5ita kasutajate usaldus, see t\u00e4hendab mitte alt vedada ja mitte kokku kukkuda. Sest kogu t\u00f6\u00f6 v\u00f5ib seiskuda, kui midagi seestpoolt ei toimi.<\/p>\n
Bitrix24 kui SaaS<\/h4>\n \nEsimese protot\u00fc\u00fcbi kokku panime aasta enne avalikku k\u00e4ivitamist, 2011. aastal. Koondasime selle umbes n\u00e4dalaga, vaatasime, keerutasime \u2014 see oli isegi t\u00f6\u00f6tav. See t\u00e4hendab, et oli v\u00f5imalik minna vormi, sisestada portaalinimi, luua uus portaal, genereerida kasutajate andmebaas. Vaatasime seda, hindasime tegelikult toodet, sulgesime selle ja terve aasta t\u00f6\u00f6tasime edasi. Sest meil oli suur \u00fclesanne: me ei tahtnud teha kahte erinevat koodibaasi, me ei tahtnud toetada eraldi pakendi toodet ja eraldi pilvelahendusi \u2014 tahtsime k\u00f5ike teha \u00fche koodi raames. <\/p>\n
Me m\u00e4\u00e4ratlesime n\u00f5uded: see peab suutma paikneda erinevates asukohtades, toetama replikatsiooni, ideaaljuhul paikneda erinevates geograafiliselt jaotatud andmekeskustes. Eraldada toote loogika ja andmete salvestamine. Dynaamiliselt suutma koormuse j\u00e4rgi skaleeruda, staatika t\u00e4iesti eraldi v\u00e4lja viia. Nendest kaalutlustest tekkisidki n\u00f5udmised tootele, mida me t\u00e4pselt aasta jooksul t\u00e4iustasime. Selle aja jooksul, platvormis, mis kujunes \u00fcheks \u2014 pakendilahenduste jaoks, meie enda teenuse jaoks \u2014 tegime toetuse nendele asjadele, mis meile vajalikud olid. Toetuse replikatsiooni mysql tasemel tootest: see t\u00e4hendab, et arendaja, kes kirjutab koodi \u2014 ei pea m\u00f5tlema, kuidas tema p\u00e4ringud jaotatakse, ta kasutab meie api-d ja meie oskame \u00f5igesti jaotada kirjutamise ja lugemise p\u00e4ringud masterite ja slave'ide vahel. <\/p>\n
Oleme teinud toote tasemel mitmesuguste pilvep\u00f5histe objektide salvestuslahenduste toetuse: Google Storage, Amazon S3 \u2014 pluss, OpenStack Swift toetus. Seega oli see mugav nii meie teenuse jaoks kui ka arendajatele, kes t\u00f6\u00f6tavad pakendilahendusega: kui nad kasutavad lihtsalt meie API-d, siis ei pea nad m\u00f5tlema, kuhu fail l\u00f5ppkokkuv\u00f5ttes salvestatakse, kas kohalikule failis\u00fcsteemile v\u00f5i satub objektide salvestuslahendusse.<\/p>\n
Kokkuv\u00f5ttes otsustasime kohe, et broneerime tervet andmekeskust. 2012. aastal alustasime t\u00e4ielikult Amazon AWS-is, kuna meil oli juba kogemus selle platvormiga \u2014 meie enda veebisait oli seal hostitud. Meid k\u00f6itis see, et igas Amazon'i regioonis on mitu saadavuse tsooni \u2014 sisuliselt (nende terminoloogias) mitu andmekeskust, mis on enam-v\u00e4hem \u00fcksteisest s\u00f5ltumatud ja v\u00f5imaldavad meil broneerida tervet andmekeskust: kui see peaks rikkis olema, replikeeruvad andmebaasid master-master re\u017eiimis, veebirakenduste serverid on broneeritud ning staatika on v\u00e4ljastatud objektide hoidjasse s3. Koormus jaotub \u2014 tol ajal Amazoni elb kaudu, kuid hiljem l\u00e4ksime oma koormuse tasakaalustajate juurde, kuna vajasime keerukamat loogikat. <\/p>\n
Mida soovisime, selle ka saime...<\/h4>\n \nK\u00f5ik p\u00f5hiasjad, mida soovisime tagada \u2014 serverite, veebirakenduste ja andmebaaside talitlush\u00e4ired \u2014 t\u00f6\u00f6tasid h\u00e4sti. K\u00f5ige lihtsam stsenaarium: kui m\u00f5ni meie veebirakendus rikneb, on k\u00f5ik lihtne \u2014 need l\u00fclitatakse v\u00e4lja koormuse tasakaalustamisest. <\/p>\n
Me t\u00f6\u00f6tame \u00fcle kogu maailma, klientide koormuspiigid on t\u00e4iesti erinevad ja \u00f5igupoolest peaksime olema v\u00f5imelised teostama teenindust\u00f6id meie s\u00fcsteemi mis tahes komponentidega igal ajal \u2013 klientidele m\u00e4rkamatult. Seet\u00f5ttu on meil v\u00f5imalus andmebaas v\u00e4lja l\u00fclitada, jagades koormuse teise andmekeskusesse. <\/p>\n
Kuidas see k\u00f5ik t\u00f6\u00f6tab? \u2014 Me suuname liikluse t\u00f6\u00f6tavale andmekeskusele \u2014 kui seal on rike, siis t\u00e4ielikult, kui see on meie kavandatud t\u00f6\u00f6 m\u00f5nes konkreetses andmebaasis, siis suuname osa liiklusest, mis teenindab neid kliente, teise andmekeskusesse, koopiat\u00f6\u00f6 peatatakse. Kui me vajame uusi masinaid veebirakenduste jaoks, kuna teises andmekeskuses on koormus suurenenud, then need k\u00e4ivituvad automaatselt. L\u00f5petame t\u00f6\u00f6d, koopiat\u00f6\u00f6 taastatakse ja suuname kogu koormuse tagasi. Kui meil on vaja teha midagi sarnast teises DC-s, n\u00e4iteks installida s\u00fcsteemiuuendusi v\u00f5i muuta seadeid teises andmebaasis, siis kordame sisuliselt k\u00f5ike sama, lihtsalt teises suunas. Ja kui see on rike, siis teeme k\u00f5ike \u00fcsna lihtsasti: j\u00e4lgimiss\u00fcsteemis kasutame mehhanismi event-handlers. Kui meil aktiveerub mitu kontrolli ja staatus muutub kriitiliseks, siis aktiveerub see k\u00e4itleja, mis v\u00f5ib teostada teatud loogikat. Meil on iga andmebaasi jaoks kirjas, millisest serverist tuleb teha failover ja kuhu liiklus suunata, kui see on k\u00e4ttesaamatu. Me \u2014 nii see ajalooliselt on v\u00e4lja kujunenud \u2014 kasutame mingit vormi nagiosest v\u00f5i selle hargnemistest. \u00dcldiselt on sarnased mehhanismid praktiliselt igas j\u00e4lgimiss\u00fcsteemis, midagi keerulisemat me hetkel ei kasuta, kuid v\u00f5ib-olla kunagi hakkame. Praegu aktiveerub j\u00e4lgimine, kui teenus on puudulik ja tal on v\u00f5imalus midagi suunata.<\/p>\n
Kas me oleme k\u00f5ik kinni pannud?<\/h4>\n \nMeil on palju kliente Ameerikast, palju kliente Euroopast, palju kliente, kes on l\u00e4hemal idas \u2014 Jaapan, Singapur ja nii edasi. Loomulikult on suur osa kliente Venemaalt. See t\u00e4hendab, et t\u00f6\u00f6 ei k\u00e4i ainult \u00fches regioonis. Kasutajad soovivad kiiret reageerimist, kohalikke seadusi tuleb j\u00e4rgida, ja igas regioonis reservime kaks andmekeskust, lisaks on veel m\u00f5ned teenused, mida on mugav paigutada \u00fchte regioonis \u2014 klientide jaoks, kes selles regioonis t\u00f6\u00f6tavad. REST-i t\u00f6\u00f6tlejad, autoriseerimiserverid on kliendi t\u00f6\u00f6 jaoks v\u00e4hem kriitilised, nende pealt on v\u00f5imalik l\u00fclituda v\u00e4ikese vastuse viivitusega, kuid ei soovi leiutada jalgratast, kuidas neid j\u00e4lgida ja mida nendega teha. Seet\u00f5ttu p\u00fc\u00fcame maksimaalselt kasutada juba olemasolevaid lahendusi, mitte arendada mingit kompetentsi t\u00e4iendavate toodete osas. Ja m\u00f5nel juhul kasutame lihtsalt DNS-i tasemel vahetust, kusjuures teenuse eluj\u00f5udlust m\u00e4\u00e4rame sama DNS-iga. Amazonis on teenus Route 53, kuid see ei ole lihtsalt DNS, kuhu v\u00f5ib salvestusi lisada ja k\u00f5ik \u2014 see on palju paindlikum ja mugavam. Selle kaudu saab luua geo-jaotatud teenuseid geolokatsioonidega, kui te tema abil m\u00e4\u00e4rate, kust klient tuli, ja annate talle vastavad salvestused \u2014 selle abil saab luua failover-arhitektuure. Samad health-check-id seadistatakse Route 53-s, te m\u00e4\u00e4rate endpoint\u2019id, mida j\u00e4lgitakse, m\u00e4\u00e4rate m\u00f5\u00f5dikud, m\u00e4\u00e4rate, milliste protokollide alusel m\u00e4\u00e4rata teenuse \u201eeluj\u00f5ud\u201c \u2014 tcp, http, https; m\u00e4\u00e4rate kontrollide sageduse, mis m\u00e4\u00e4ravad, kas teenus on elus v\u00f5i mitte. Ja DNS-is m\u00e4\u00e4rate, mis on peamine, mis on sekundaarne, kuhu vahetada, kui Route 53 sees toimib health-check. K\u00f5ike seda saab teha m\u00f5ne teise t\u00f6\u00f6riistaga, kuid mugavus seisneb selles, et seadistate selle \u00fche korra ja siis ei pea me \u00fcldse m\u00f5tlema, kuidas meie kontrollid toimuvad, kuidas vahetus toimub: k\u00f5ik t\u00f6\u00f6tab iseenesest.<\/p>\n
Esimene 'aga'<\/b>: kuidas ja millega reserveerida ise Route 53? Isegi kui juhtub midagi, siis kuidas toimida? Meie oleme \u00f5nneks kunagi sellistele karidele peale astunud, kuid siiski, mul on ees lugu, miks me m\u00f5tleme sellele, et reserveerimine on vajalik. Siin valmistame end ette. Kord p\u00e4evas teeme t\u00e4ieliku v\u00e4ljundi k\u00f5igist tsoonidest, mis meil Route 53-s on. Amazon API v\u00f5imaldab neid rahulikult edastada JSON-formaadis, ja meil on \u00fcles seatud mitu varuserverit, kuhu me selle konverteerime, laadime v\u00e4lja konfigureeringutena ja omame, \u00fctleme nii, varukoopia konfiguratsiooni. Kui midagi juhtub, saame selle kiiresti k\u00e4sitsi taastada, kaotamata DNS-seadeid.<\/p>\n
Teine \u201eaga\u201c<\/b>: mida selles pildis pole veel reserveeritud? Balansseerija! Meie klientide jaotus regioonide vahel on tehtud v\u00e4ga lihtsalt. Meil on domeenid bitrix24.ru, bitrix24.com, .de \u2014 hetkel on neid umbes 13 erinevat, mis t\u00f6\u00f6tavad erinevates tsoonides. Oleme j\u00f5udnud j\u00e4rgmisele: igas regioonis on oma balansseerijad. Niimoodi on mugavam jaotada regioonide vahel, s\u00f5ltuvalt k\u00f5rgeimast koormusest v\u00f5rgu kaudu. Kui \u00fche balansseerija tasemel toimub rike, siis see lihtsalt eemaldatakse kasutusest ja DNS-ist. Kui tekib probleem balansseerijate grupiga, siis need reserveeritakse teistel platvormidel ning vahetus nende vahel toimub sama Route 53 abil, kuna l\u00fchikese TTL t\u00f5ttu toimub vahetus maksimaalselt 2, 3, 5 minuti jooksul. <\/p>\n
Kolmas \u201eaga\u201c<\/b>: mida veel ei ole reserveeritud? S3, \u00f5ige. Me, kui salvestame faile, mida hoiame kasutajatel S3-s, \u2013 uskusime siiralt, et see on muutumatult t\u00f6\u00f6kindel ja seal ei pea midagi reserveerima. Kuid ajalugu n\u00e4itab, et asjad ei l\u00e4he alati nii. \u00dcldiselt kirjeldab Amazon S3-d kui p\u00f5hilist teenust, kuna Amazon kasutab S3-d masinapiltide, konfiguratsioonide, AMI-piltide, hetkeseisude salvestamiseks\u2026 Ja kui S3 t\u00f5rkeb, nagu see kord meie seitsme Bitrix24 aasta jooksul juhtus, t\u00f5mbab see kaasa kogu hulga asju \u2014 virtuaalmasinate k\u00e4ivitamise k\u00e4tte saamata j\u00e4\u00e4mine, API t\u00f5rked ja nii edasi. <\/p>\n
Ja s3 v\u00f5ib kokku kukkuda - see juhtus kunagi. Seet\u00f5ttu j\u00f5udsime j\u00e4rgmisele skeemile: m\u00f5ned aastad tagasi ei olnud Venemaal t\u00f5siseid objekti avalikke salvestusruume ja me kaalusime, et teha midagi enda oma\u2026 \u00d5nneks me seda ei alustanud, sest oleksime kadunud sellesse ekspertiisi, mis meil puudus, ja kindlasti oleksime midagi valesti teinud. Praegu on s3-\u00fchilduvaid salvestusi Mail.ru, Yandexil ja veel mitmel teenusepakkujal. L\u00f5puks j\u00f5udsime m\u00f5ttele, et tahame, esiteks, varundust ja teiseks, v\u00f5imalust t\u00f6\u00f6tada kohalike koopiatega. Konkreetse Venemaa regiooni jaoks kasutame Mail.ru Hotboxi teenust, mis on api poolest s3-\u00fchilduv. Me ei pidanud rakenduse sisekoodis tegema t\u00f5siseid muudatusi ja tegime j\u00e4rgmise mehhanismi: s3-s on k\u00e4ivitajad, mis aktiveeruvad objektide loomisel\/mahimise ajal, Amazonil on selline teenus nagu Lambda - see on serverless koodi k\u00e4itamise teenus, mis k\u00e4ivitub just nende k\u00e4ivitajate aktiveerimisel.<\/p>\n
Kooditasandil m\u00e4\u00e4rame iga kliendi jaoks kaks salvestusruumi: \u00fcks peamine ja teine varus. Kui k\u00f5ik on h\u00e4sti, kasutame seda salvestusruumi, mis on meile l\u00e4hedasem: see t\u00e4hendab, et meie kliendid, kes on Amazonis, t\u00f6\u00f6tavad S3-ga, ja need, kes t\u00f6\u00f6tavad Venemaal, t\u00f6\u00f6tavad Hotboxiga. Kui l\u00fcliti aktiveeritakse, peab meil olema failover ja me suuname kliendid teise salvestusruumi. Saame seda l\u00fclitit s\u00f5ltumatult piirkondade kaupa seada ja neid vahetada. Praktiliselt pole me seda veel kasutanud, kuid mehhanism on ette n\u00e4htud, ja me arvame, et mingil hetkel on see vahetus vajalik. \u00dcks kord on see juba juhtunud. <\/p>\n
Oh, Amazon on teid pettnud\u2026<\/h4>\n \nSel aprillil on m\u00f6\u00f6dunud aasta, mil Venemaal blokeeriti Telegram. K\u00f5ige enam kannatanud teenusepakkuja, kes sellesse sattus, on Amazon. Kahjuks on rohkem kannatanud Vene ettev\u00f5tted, kes tegutsesid kogu maailmas. <\/p>\n
Kui ettev\u00f5te on globaalne ja Venemaa on selle jaoks vaid v\u00e4ga v\u00e4ike segment, 3-5% \u2014 siis on mingil m\u00e4\u00e4ral neid v\u00f5imalik ohverdada. <\/p>\n
Kui see on puhtalt Vene ettev\u00f5te \u2014 olen kindel, et see peaks paiknema kohalikes serverites \u2014 lihtsalt kasutajatele on nii mugavam ja riskid on v\u00e4iksemad. <\/p>\n
Aga kui see on ettev\u00f5te, mis tegutseb globaalselt ja tal on umbes sama palju kliente Venemaalt kui ka mujalt maailmast? Segmentide omavaheline seos on oluline, ja nad peavad \u00fcksteisega t\u00f6\u00f6tama. <\/p>\n
Juba m\u00e4rtsi l\u00f5pus 2018 saatis Roskomnadzor suurematele operaatoritele kirja, et nad kavatsevad blokeerida mitu miljonit Amazon'i IP aadressi, et blokeerida... s\u00f5numiteenus Zello. T\u00e4nu nendele teenusepakkujatele levis kiri kiiresti ning tekkis arusaam, et seos Amazoniga v\u00f5ib kaduda. See oli reede, me jooksime paanika t\u00f5ttu kolleegide juurde servers.ru, \u00f6eldes: \"S\u00f5brad, meil on vaja mitmeid servereid, mis ei oleks Venemaal, mitte Amazonis, vaid n\u00e4iteks kuskil Amsterdamis,\" et meil oleks v\u00f5imalus seal v\u00e4hemalt mingil moel oma servereid paigaldada. vpn<\/a> ja proxy nende endpoint'ide jaoks, millele me ei saa kuidagi m\u00f5ju avaldada, n\u00e4iteks s3 endpoint'id - ei saa proovida luua uut teenust ja saada teist IP-d, me peame ikka sinna ligi saama. M\u00f5ne p\u00e4evaga saime need serverid seadistatud ja valmis, ning \u00fcldiselt, kui blokeeringud algasid, olime juba ette valmistunud. Huvi \u00e4ratas see, et RKON, n\u00e4hes segadust ja tekitatud paanikat, \u00fctles: \u201eEi, me praegu midagi blokeerima ei hakka.\u201d (Aga see oli just kuni hetkeni, mil hakkasid blokeerima Telegram'i.) Seadistasime \u00fcmbers\u00f5idu v\u00f5imalused ja m\u00f5istsime, et blokeeringut ei kehtestatud, kuid samas ei hakanud me sellega tegelema. Igaks juhuks. <\/p>\n
Kuidas varundada... terve teenusepakkuja?<\/h4>\n \nPraegu pole meil stsenaariumi, et kogu Amazoni s\u00fcsteem v\u00f5ib eba\u00f5nnestuda. Meil on sarnane stsenaarium Venemaa jaoks. Oleme Venemaal paiknenud \u00fches teenusepakkujas, kelle puhul valisime mitmeid platvorme. Aasta tagasi kohtasime probleemi: isegi kui need on kaks andmekeskust, v\u00f5ivad teenusepakkuja v\u00f5rgu konfigureerimise tasemel esineda t\u00f5rkeid, mis m\u00f5jutavad siiski m\u00f5lemat andmekeskust. Ja me v\u00f5ime kogeda juurdep\u00e4\u00e4smatus m\u00f5lemal platvormil. Loomulikult nii juhtuski. L\u00f5puks \u00fclevaatasime oma arhitektuuri sisemiselt. See ei muutunud palju, kuid Venemaal on meil n\u00fc\u00fcd kaks platvormi, mis ei asu \u00fches teenusepakkujas, vaid kahes erinevas. Kui \u00fches midagi l\u00e4heb katki, saame l\u00fclituda teisele.<\/p>\n
H\u00fcpoteetiliselt kaalume Amazoni jaoks v\u00f5imalust reserveerida teise teenusepakkuja tasemel; v\u00f5ib-olla Google, v\u00f5ib-olla keegi teine... Kuid seni oleme praktikas t\u00e4heldanud, et kui Amazoni k\u00e4itumises esinevad \u00f5nnetused \u00fche saadavuse tsoonis, siis \u00f5nnetused kogu piirkonnas on piisavalt haruldased. Seet\u00f5ttu on meil teoreetiline ettekujutus, et v\u00f5ib-olla teeme reserveeringu \u201eAmazon - mitte Amazon\u201c, kuid praktikas pole me seda veel teinud. <\/p>\n
M\u00f5ned s\u00f5nad automatiseerimisest<\/h4>\n \nKas automatiseerimine on alati vajalik? Siin on paslik meenutada Dunning-Krugeri efekti. X-teljel on meie teadmised ja kogemused, mida me omandame, ja Y-teljel - meie enesekindlus. Esiteks ei tea me midagi ja oleme t\u00e4ielikult ebakindlad. Siis teame veidi ja muutume \u00fcliusutavaks - see on nn \u201erumaluse tipp\u201c, mida illustreerib h\u00e4sti pilt \u201elollus ja julgus\u201c. Edasi liikudes oleme juba natuke \u00f5ppinud ja oleme valmis lahingusse minema. Siis astume mingitele \u00fcliseriousetele vitsadele ja satume meeleheite orgu, kus n\u00e4ib, et teame midagi, aga tegelikult ei tea me palju. Siis, kogemuste t\u00f5ttu, saame juba kindlamaks.<\/p>\n
Kokkuv\u00f5te<\/h4>\n \nSeitsme aasta jooksul oleme l\u00e4binud tee sellest, et kui midagi kukkus, valitses paanika, arusaamiseni, et probleeme ei eksisteeri, on ainult \u00fclesanded, mida tuleb lahendada. Kui ehitate m\u00f5nd teenust, vaadake seda k\u00f5rvalt, hinnake k\u00f5iki riske, mis v\u00f5ivad tekkida. Kui n\u00e4ete neid kohe, siis planeerige ette varundamine ja v\u00f5imalus \u00fcles ehitada t\u00f5rkekindel infrastruktuur, sest iga punkt, mis v\u00f5ib rikki minna ja viia teenuse t\u00f6\u00f6v\u00f5imetuseni \u2014 see kindlasti ka juhtub. Ja isegi kui teile tundub, et m\u00f5ned infrastruktuuri elemendid ei l\u00e4he kindlasti rikki \u2014 n\u00e4iteks s3, pidage siiski meeles, et nad v\u00f5ivad. Ja v\u00e4hemalt teoreetiliselt pidage silmas, mida te nendega teete, kui midagi ikkagi juhtub. Olge valmis riskide haldamiseks. Kui m\u00f5tlete, kas teha k\u00f5ik automaatika abil v\u00f5i k\u00e4sitsi \u2014 hinnake riske: mis juhtub, kui automaatika hakkab k\u00f5ike vahetama \u2014 kas see toob kaasa veel halvemad tagaj\u00e4rjed v\u00f5rreldes h\u00e4irega? V\u00f5ib-olla on m\u00f5nes kohas m\u00f5istlik kompromiss automaatika ja vahetusinseneri reageerimise vahel, kes hindab olukorda ja m\u00f5istab, kas on vaja kohe midagi vahetada v\u00f5i \"jah, aga mitte praegu\".<\/p>\n
M\u00f5istlik kompromiss perfektsionismi ja teie rahaliselt ning ajaliselt k\u00e4ttesaadavate v\u00f5imaluste vahel, mis v\u00f5imaldab teil l\u00f5puks saavutada soovitud tulemuse.<\/p>\n
See tekst on Aleksandr Demidovi ettekande t\u00e4iendatud ja laiendatud versioon konverentsil. Uptime p\u00e4ev 4<\/a><\/noindex>.<\/i> habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u041d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0439 \u0434\u0435\u043d\u044c \u0443 \u0441\u0435\u0440\u0432\u0438\u0441\u0430 \u00ab\u0411\u0438\u0442\u0440\u0438\u043a\u044124\u00bb \u043d\u0435\u0442 \u0441\u043e\u0442\u0435\u043d \u0433\u0438\u0433\u0430\u0431\u0438\u0442 \u0442\u0440\u0430\u0444\u0438\u043a\u0430, \u043d\u0435\u0442 \u043e\u0433\u0440\u043e\u043c\u043d\u043e\u0433\u043e \u043f\u0430\u0440\u043a\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 (\u0445\u043e\u0442\u044f \u0438 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445, \u043a\u043e\u043d\u0435\u0447\u043d\u043e, \u043d\u0435\u043c\u0430\u043b\u043e). \u041d\u043e \u0434\u043b\u044f \u043c\u043d\u043e\u0433\u0438\u0445 \u043a\u043b\u0438\u0435\u043d\u0442\u043e\u0432 \u043e\u043d \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u043c \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u043e\u043c \u0440\u0430\u0431\u043e\u0442\u044b \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u044d\u0442\u043e \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0435 business-critical \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u043f\u0430\u0434\u0430\u0442\u044c \u2014 \u043d\u0443, \u043d\u0438\u043a\u0430\u043a \u043d\u0435\u043b\u044c\u0437\u044f. \u0410 \u0447\u0442\u043e \u0435\u0441\u043b\u0438 \u043f\u0430\u0434\u0435\u043d\u0438\u0435 \u0432\u0441\u0435-\u0442\u0430\u043a\u0438 \u0441\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c, \u043d\u043e \u00ab\u0432\u043e\u0441\u0441\u0442\u0430\u043b\u00bb \u0441\u0435\u0440\u0432\u0438\u0441 \u0442\u0430\u043a \u0431\u044b\u0441\u0442\u0440\u043e, \u0447\u0442\u043e \u043d\u0438\u043a\u0442\u043e \u043d\u0438\u0447\u0435\u0433\u043e \u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26389,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35092","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"\u00abBitrix24\u00bb:](\"\/wp-content\/uploads\/2019\/06\/973fa076fc654237aa869d0ecb0dae9a.jpeg\")