<\/a><\/noindex>Ved lanceringen af tjenesten vidste vi, at det vigtigste var at sikre failover, p\u00e5lidelighed og konstant tilg\u00e6ngelighed, fordi hvis du har en almindelig hjemmeside, en butik for eksempel, og den g\u00e5r ned i en time \u2014 s\u00e5 er det kun dig selv, der lider, du mister ordrer, du mister kunder, men for din kunde \u2014 for ham er det ikke s\u00e5 kritisk. Han bliver naturligvis frustreret, men g\u00e5r hen og k\u00f8ber p\u00e5 en anden hjemmeside. Men hvis det er en applikation, som hele virksomheden, kommunikationen og l\u00f8sningerne er afh\u00e6ngig af, s\u00e5 er det vigtigste at vinde brugernes tillid, alts\u00e5 ikke svigte dem og ikke g\u00e5 ned. Fordi hele arbejdet kan stoppe, hvis noget indeni ikke fungerer.<\/p>\n
Bitrix24 som SaaS<\/h4>\n \nDen f\u00f8rste prototype samlede vi et \u00e5r f\u00f8r den offentlige lancering, i 2011. Den blev samlet p\u00e5 cirka en uge, vi kiggede p\u00e5 den, drejede den \u2014 den fungerede endda. Man kunne tilg\u00e5 formularen, indtaste navnet p\u00e5 portalen, og en ny portal blev oprettet med en brugerbase. Vi s\u00e5 p\u00e5 den, vurderede produktet generelt, lukkede det ned, og arbejdede videre i et helt \u00e5r. Fordi vi havde en stor opgave: vi \u00f8nskede ikke at have to forskellige kodebaser, vi ville ikke st\u00f8tte et kasseprodukt og en cloud-l\u00f8sning separat \u2014 vi \u00f8nskede at lave det hele inden for \u00e9n kode. <\/p>\n
Vi formulerede kravene: evnen til at placere sig i forskellige lokationer, underst\u00f8tte replikation, ideelt set at v\u00e6re placeret i forskellige geografisk fordelte datacentre. At adskille produktlogikken og selve datalagringen. Dynamisk kunne skalere efter belastningen, statikken skulle helt tage ud. Ud fra disse overvejelser blev kravene til produktet, som vi netop arbejdede p\u00e5 i l\u00f8bet af et \u00e5r, dannet. I den platform, som blev enhed \u2014 til kasse-l\u00f8sninger og vores egen service \u2014 implementerede vi st\u00f8tte til de ting, som var n\u00f8dvendige for os. St\u00f8tte til MySQL-replikation p\u00e5 produktniveau: det vil sige, at udvikleren, der skriver koden \u2014 ikke beh\u00f8ver at t\u00e6nke p\u00e5, hvordan hans foresp\u00f8rgsler vil blive fordelt, han bruger vores API, og vi ved, hvordan vi korrekt fordeler skrive- og l\u00e6seforesp\u00f8rgsler mellem mastere og slaver. <\/p>\n
Vi har implementeret st\u00f8tte p\u00e5 produktniveau for forskellige cloud objektlagringssystemer: Google Storage, Amazon S3 \u2014 plus, st\u00f8tte til OpenStack Swift. Derfor var det praktisk b\u00e5de for os som service og for udviklere, der arbejder med kasseproduktet: hvis de blot bruger vores API til arbejdet, beh\u00f8ver de ikke at t\u00e6nke p\u00e5, hvor filen i sidste ende gemmes, lokalt p\u00e5 filsystemet eller om den ender i objektlagringssystemet.<\/p>\n
Som resultat besluttede vi straks, at vi ville have en backup p\u00e5 datacenter-niveau. I 2012 startede vi fuld ud i Amazon AWS, fordi vi allerede havde erfaring med denne platform \u2014 vores egen hjemmeside var hostet der. Det tiltrak os, at der i hver region i Amazon er flere tilg\u00e6ngelighedszoner \u2014 i deres terminologi, flere datacentre, der er mere eller mindre uafh\u00e6ngige af hinanden og tillader os at have en backup p\u00e5 datacenter-niveau: hvis det pludselig fejler, er databaserne replikat master-master, webapplikationsserverne er reserveret, og statikken er flyttet til objektlageret s3. Belastningen balanceres \u2014 p\u00e5 det tidspunkt med Amazons elb, men lidt senere kom vi til vores egne belastningsbalancere, fordi vi havde brug for en mere kompleks logik. <\/p>\n
Hvad vi \u00f8nskede \u2014 fik vi...<\/h4>\n \nAlle de grundl\u00e6ggende ting, som vi \u00f8nskede at sikre \u2014 h\u00f8j tilg\u00e6ngelighed af selve serverne, webapplikationer, databaser \u2014 fungerede alle godt. Den enkleste scenario: hvis en af vores webapplikationer fejler, s\u00e5 er det meget simpelt \u2014 de tages ud af belastningsbalanceringen. <\/p>\n
Vi arbejder over hele verden, og kundernes belastningsspidser er helt forskellige, og ideelt set skal vi have mulighed for at udf\u00f8re servicearbejde p\u00e5 alle komponenter i vores system n\u00e5r som helst \u2013 uden at kunderne l\u00e6gger m\u00e6rke til det. Derfor har vi mulighed for at tage databasen ud af drift og omfordele belastningen til det andet datacenter. <\/p>\n
Hvordan fungerer det hele? \u2014 Vi omdirigerer trafikken til det fungerende datacenter \u2014 hvis det er en nedbrud p\u00e5 datacenteret, s\u00e5 er det helt, hvis det er vores planlagte arbejde med en specifik database, s\u00e5 omdirigerer vi en del af trafikken, der betjener disse kunder, til det andet datacenter, og replikationen stoppes. Hvis vi har brug for nye maskiner til webapplikationer, fordi belastningen er steget i det andet datacenter, starter de automatisk. N\u00e5r arbejdet er f\u00e6rdigt, genoprettes replikationen, og vi returnerer hele belastningen tilbage. Hvis vi skal udf\u00f8re spejlvendt arbejde i det andet datacenter, for eksempel installere systemopdateringer eller \u00e6ndre indstillingerne i den anden database, gentager vi i princippet det samme, blot i den modsatte retning. Men hvis det er en n\u00f8dssituation, g\u00f8r vi det meget enkelt: vi bruger mekanismen event-handlers i overv\u00e5gningssystemet. Hvis flere tjek udl\u00f8ses, og status skifter til kritisk, aktiveres den handler, der kan udf\u00f8re den eller den logik. For hver database har vi specificeret, hvilken server der er dens failover, og hvor trafikken skal omdirigeres, hvis den bliver utilg\u00e6ngelig. Historisk set har vi brugt nagios i en eller anden form eller dens forks. I princippet findes s\u00e5danne mekanismer n\u00e6sten i alle overv\u00e5gningssystemer, men noget mere komplekst bruger vi ikke endnu, men det kan v\u00e6re, vi g\u00f8r det en dag. I \u00f8jeblikket reagerer overv\u00e5gningen p\u00e5 utilg\u00e6ngelighed og har mulighed for at omdirigere noget.<\/p>\n
Har vi reserveret alt?<\/h4>\n \nVi har mange kunder fra USA, mange kunder fra Europa, mange kunder, der er t\u00e6ttere p\u00e5 \u00d8sten \u2014 Japan, Singapore osv. Selvf\u00f8lgelig er en stor del af klienterne i Rusland. Det vil sige, at arbejdet ikke kun foreg\u00e5r i \u00e9n region. Brugerne \u00f8nsker hurtige svartider, der er krav om overholdelse af forskellige lokale love, og inden for hver region reserverer vi os til to datacentre, plus der er nogle ekstra tjenester, som igen er bekvemme at placere inden for \u00e9n region \u2014 for kunder, der arbejder i denne region. REST-handlere, autorisationsservere er mindre kritiske for klientens samlede drift, og de kan skiftes med en acceptabel forsinkelse, men vi \u00f8nsker ikke at opfinde cyklen, hvad ang\u00e5r overv\u00e5gning og h\u00e5ndtering af dem. Derfor fors\u00f8ger vi maksimalt at bruge eksisterende l\u00f8sninger frem for at udvikle kompetencer inden for yderligere produkter. Og nogle gange bruger vi bare skift p\u00e5 dns-niveau, hvorvi ogs\u00e5 bestemmer tjenestens tilg\u00e6ngelighed ved hj\u00e6lp af den samme dns. Amazon har en tjeneste kaldet Route 53, men det er ikke bare dns, hvor man kan tilf\u00f8je poster og s\u00e5 videre \u2014 den er langt mere fleksibel og praktisk. Gennem den kan man opbygge geo-distribuerede tjenester med geolocation, n\u00e5r du ved hj\u00e6lp deraf definerer, hvor kunden kom fra, og giver ham de forskellige poster \u2014 man kan opbygge failover-arkitekturer med den. De samme health-checks indstilles i selve Route 53, hvor du angiver endpoints, der overv\u00e5ges, definerer metrics, og angiver, hvilke protokoller der skal bruges til at bestemme tjenestens 'livlighed' \u2014 tcp, http, https; du angiver hyppigheden af tjek, der bestemmer, om tjenesten er live eller ej. Og i selve dns angiver du, hvad der vil v\u00e6re prim\u00e6rt, hvad der vil v\u00e6re sekund\u00e6rt, og hvor der skal skiftes hen, hvis health-checks indg\u00e5r i Route 53. Alt dette kan g\u00f8res med nogle andre v\u00e6rkt\u00f8jer, men det praktiske er, at man kun skal indstille det \u00e9n gang, og s\u00e5 t\u00e6nker vi slet ikke mere over, hvordan vi laver tjek, og hvordan overgangen finder sted: alt fungerer af sig selv.<\/p>\n
Det f\u00f8rste 'men'<\/b>: hvordan og med hvad skal man sikkerhedskopiere selve Route 53? Man ved aldrig, hvad der kan ske med det. Heldigvis har vi ikke v\u00e6ret ude for det endnu, men jeg vil snart dele, hvorfor vi mente, at det er n\u00f8dvendigt at lave en sikkerhedskopi. Her forbereder vi os p\u00e5 forh\u00e5nd. Flere gange om dagen laver vi en fuld eksport af alle zoner, som vi har i Route 53. Amazons API tillader os at f\u00e5 dem i JSON, og vi har opsat flere backup-servere, hvor vi konverterer dette, eksporterer det i form af konfigurationer og har, groft sagt, en backup-konfiguration. Hvis der er problemer, kan vi hurtigt implementere den manuelt og ikke miste DNS-indstillingsdata.<\/p>\n
Den anden \"men\"<\/b>: hvad er der endnu ikke blevet taget backup af? Selve balanceringssystemet! Vi har fordelt kunderne p\u00e5 regioner p\u00e5 en meget enkel m\u00e5de. Vi har dom\u00e6ner som bitrix24.ru, bitrix24.com, .de \u2014 nu er der omkring 13 forskellige, som arbejder p\u00e5 meget forskellige zoner. Vi er n\u00e5et frem til f\u00f8lgende: i hver region er der egne balanceringssystemer. Det er lettere at fordele efter regioner, alt efter hvor den spidse netbelastning er. Hvis der er en fejl p\u00e5 et enkelt balanceringssystem, s\u00e5 tages det simpelthen ud af drift og fjernes fra DNS. Hvis der opst\u00e5r problemer med gruppen af balanceringssystemer, s\u00e5 tages de backup andre steder, og skiftet mellem dem sker ved hj\u00e6lp af den samme route53, fordi p\u00e5 grund af den korte TTL sker skiftet maksimalt inden for 2, 3, 5 minutter. <\/p>\n
Den tredje \"men\"<\/b>: hvad er der ellers ikke blevet taget backup af? S3, korrekt. Da vi lagrer filer, som vi opbevarer hos brugerne i S3, troede vi oprigtigt, at det var uovervindeligt, og at der ikke var behov for at tage backup der. Men historien viser, at det sker anderledes. Generelt beskriver Amazon S3 som en grundl\u00e6ggende tjeneste, fordi Amazon selv bruger S3 til at opbevare maskinbilleder, konfigurationer, AMI-billeder, snapshots... Og hvis S3 falder, som det engang skete i de 7 \u00e5r, vi har anvendt bitrix24, tr\u00e6kker det en hel del andre problemer med sig \u2014 utilg\u00e6ngelighed af opstart af virtuelle maskiner, fejl i API'en, osv. <\/p>\n
Og S3 kan falde ned \u2013 det skete engang. Derfor kom vi frem til f\u00f8lgende ordning: For flere \u00e5r siden fandtes der ikke seri\u00f8se offentlige objektholdere i Rusland, og vi overvejede at lave noget selv\u2026 Heldigvis begyndte vi ikke p\u00e5 det, for vi ville v\u00e6re blevet begravet i den ekspertise, vi ikke har, og sikkert ville vi have lavet fejl. Nu findes der S3-kompatible opbevaringsl\u00f8sninger fra Mail.ru, fra Yandex, samt fra en r\u00e6kke andre udbydere. Til sidst kom vi frem til, at vi \u00f8nskede, for det f\u00f8rste, redundans, og for det andet, muligheden for at arbejde med lokale kopier. Til den specifikke russiske region bruger vi Mail.ru Hotbox, som er API-kompatibel med S3. Vi havde ikke brug for betydelige modifikationer af koden i applikationen, og vi har lavet f\u00f8lgende mekanisme: i S3 er der triggere, der aktiveres ved oprettelse\/fjernelse af objekter; Amazon har en service kaldet Lambda \u2013 det er serverless k\u00f8rsel af kode, der bliver udf\u00f8rt, n\u00e5r de forskellige triggere aktiveres.<\/p>\n
P\u00e5 kode niveau er der for hver kunde angivet to opbevaringsl\u00f8sninger: en betragtes som prim\u00e6r, den anden som backup. Hvis alt er i orden, arbejder vi med den opbevaringsl\u00f8sning, der er t\u00e6ttest p\u00e5 os: vores kunder, der er i Amazon, arbejder med S3, mens dem, der arbejder i Rusland, bruger Hotbox. Hvis flaget aktiveres, skal vi have en failover tilslutte sig, og vi skifter kunderne til den anden opbevaringsl\u00f8sning. Vi kan s\u00e6tte dette flag uafh\u00e6ngigt efter regioner og kan skifte dem frem og tilbage. I praksis har vi ikke brugt det endnu, men mekanismen er forudset, og vi tror, at vi en dag vil f\u00e5 brug for dette skift. Det er allerede sket \u00e9n gang. <\/p>\n
\u00c5h, er jeres Amazon stukket af\u2026<\/h4>\n \nI april er det \u00e5rsdagen for begyndelsen p\u00e5 blokaderne af Telegram i Rusland. Den mest p\u00e5virkede udbyder, som blev ramt af dette, er Amazon. Og desv\u00e6rre har de russiske virksomheder, der arbejdede globalt, lidt mest. <\/p>\n
Hvis virksomheden er global, og Rusland kun udg\u00f8r en meget lille del, 3-5% \u2014 s\u00e5 kan de p\u00e5 en eller anden m\u00e5de ofres. <\/p>\n
Hvis det er en helt russisk virksomhed \u2014 s\u00e5 er jeg sikker p\u00e5, at de b\u00f8r placere sig lokalt \u2014 det vil simpelthen v\u00e6re mere bekvemt og komfortabelt for brugerne, og risiciene vil v\u00e6re mindre. <\/p>\n
Og hvis dette er en virksomhed, der arbejder globalt, og har nogenlunde lige mange kunder i Rusland som rundt om i verden? Forbindelsen mellem segmenterne er vigtig, og de skal p\u00e5 en eller anden m\u00e5de arbejde sammen. <\/p>\n
Allerede i slutningen af marts 2018 sendte Roskomnadzor et brev til de st\u00f8rste operat\u00f8rer om, at de planl\u00e6gger at blokere flere millioner IP-adresser fra Amazon for at blokere\u2026 beskedapplikationen Zello. Tak til disse udbydere \u2014 de l\u00e6kkede brevet til alle, og der opstod en forst\u00e5else af, at forbindelsen til Amazon kunne bryde sammen. Det var en fredag, og vi l\u00f8b panikslagne hen til kollegerne fra servers.ru og sagde: \u201eVenner, vi har brug for flere servere, der ikke st\u00e5r i Rusland, ikke i Amazon, men for eksempel et eller andet sted i Amsterdam\u201c, for at kunne s\u00e6tte vores egne der. vpn<\/a> og proxyer til nogle endpoints, som vi slet ikke kan p\u00e5virke, for eksempel endpoints til S3 \u2014 vi kan ikke bare fors\u00f8ge at oprette en ny service og f\u00e5 en anden IP; vi skal stadig kunne n\u00e5 det. I l\u00f8bet af nogle dage satte vi disse servere op, og ved tidspunktet for blokeringerne var vi klar. Det er interessant, at Roskomnadzor, efter at have set opstanden og panikken, sagde: \u00abNej, vi vil ikke blokere noget nu.\u00bb (Men det var lige indtil de begyndte at blokere Telegram.) Efter at have indstillet omg\u00e5elsesmulighederne og forst\u00e5et, at blokeringen ikke blev indf\u00f8rt, valgte vi alligevel ikke at nedtage det hele. Bare for en sikkerheds skyld. <\/p>\n
Hvordan kan man reservenere\u2026 en hel udbyder?<\/h4>\n \nVi har i \u00f8jeblikket ikke et scenarie for en total nedbrud af Amazon. Vi har et lignende scenarie for Rusland. I Rusland brugte vi en udbyder, hvor vi valgte at have flere lokaliteter. For et \u00e5r siden st\u00f8dte vi p\u00e5 et problem: selvom det er to datacentre, kan der allerede ved niveauet for udbyderens netv\u00e6rkskonfiguration v\u00e6re problemer, der vil p\u00e5virke begge datacentre. Det kan resultere i nedetid p\u00e5 begge lokaliteter. Og selvf\u00f8lgelig skete det ogs\u00e5. Vi har i sidste ende gennemg\u00e5et vores interne arkitektur. Den har ikke \u00e6ndret sig meget, men i Rusland har vi nu to lokaliteter, som ikke er hos \u00e9n udbyder, men hos to forskellige. Hvis \u00e9n skulle g\u00e5 ned, kan vi skifte over til den anden.<\/p>\n
Hypotetisk set overvejer vi for Amazon at reservere p\u00e5 niveauet for en anden udbyder; m\u00e5ske Google, m\u00e5ske nogen anden\u2026 Men indtil videre har vi observeret, at hvis der sker nedbrud p\u00e5 niveauet for en availability-zone hos Amazon, s\u00e5 er nedbrud p\u00e5 niveauet for en hel region et relativt sj\u00e6ldent f\u00e6nomen. Derfor har vi en teoretisk id\u00e9 om, at vi m\u00e5ske vil implementere en reservel\u00f8sning \u201eAmazon \u2013 ikke Amazon\u201c, men praktisk set har det endnu ikke v\u00e6ret tilf\u00e6ldet. <\/p>\n
Et par ord om automatisering<\/h4>\n \nEr automatisering altid n\u00f8dvendig? Her er det passende at n\u00e6vne Dunning-Kruger-effekten. P\u00e5 x-aksen har vi vores viden og erfaring, som vi opn\u00e5r, og p\u00e5 y-aksen er vores selvtillid i vores handlinger. F\u00f8rst ved vi ikke noget og er slet ikke sikre. Derefter ved vi lidt og bliver mega-sikre \u2014 det er det, man kalder \u201etoppunktet for t\u00e5belighed\u201c, som godt illustreres af billedet \u201ed\u00e5neskab og mod\u201c. Herefter har vi l\u00e6rt lidt og er klar til at g\u00e5 i kamp. S\u00e5 tr\u00e6der vi p\u00e5 nogle mega-seri\u00f8se problemer, falder ind i fortvivlelsens dal, hvor vi ser ud til at vide noget, men i virkeligheden ved vi ikke meget. Derefter, efterh\u00e5nden som vi f\u00e5r mere erfaring, bliver vi mere selvsikre.<\/p>\n
Konklusion<\/h4>\n \nI l\u00f8bet af 7 \u00e5r har vi bev\u00e6get os fra at panikke, n\u00e5r noget gik ned, til at forst\u00e5, at problemer ikke eksisterer; der er kun opgaver, der skal l\u00f8ses \u2014 og som kan l\u00f8ses. N\u00e5r du bygger en service, s\u00e5 se den fra oven, og vurder alle de risici, der kan opst\u00e5. Hvis du straks ser dem \u2014 s\u00e5 forudse reserven og muligheden for at bygge en fejltolerant infrastruktur, for enhver punkt der kan bryde sammen og f\u00f8re til, at servicen ikke fungerer \u2014 det vil helt sikkert ske. Og selv hvis du mener, at visse elementer af infrastrukturen ikke vil bryde sammen \u2014 som for eksempel S3 \u2014 s\u00e5 v\u00e6r klar over, at de kan. Og i det mindste i teorien, hav en id\u00e9 om, hvad du vil g\u00f8re med dem, hvis noget alligevel skulle ske. Hav en plan for risikoh\u00e5ndtering. N\u00e5r du overvejer, om alting skal g\u00f8res automatisk eller manuelt, s\u00e5 vurder risiciene: hvad sker der, hvis automatiseringen begynder at skifte alt \u2014 vil det f\u00f8re til en endnu v\u00e6rre situation sammenlignet med en fejl? M\u00e5ske er der steder, hvor der skal anvendes en fornuftig balance mellem at bruge automatisering og reaktionen fra den vagtholdende ingeni\u00f8r, der vurderer den reelle situation og forst\u00e5r, om noget skal skiftes straks eller \"ja, men ikke nu\".<\/p>\n
En fornuftig balance mellem perfektionisme og de reelle ressourcer, tid og penge, som du kan investere i det resultat, du ender op med.<\/p>\n
Denne tekst er en udvidet version af Alexander Demidovs pr\u00e6sentation p\u00e5 konferencen. Uptime dag 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\")