<\/a><\/noindex>Ao lan\u00e7ar o servi\u00e7o, entend\u00edamos que o mais importante era garantir a confiabilidade, continuidade e disponibilidade constante do servi\u00e7o, porque se voc\u00ea tiver um site comum, uma loja, por exemplo, e ela cair por uma hora \u2014 voc\u00ea s\u00f3 sofre por isso, perde pedidos, perde clientes, mas para o seu cliente \u2014 isso n\u00e3o \u00e9 t\u00e3o cr\u00edtico. Ele fica triste, claro, mas vai e compra em outro site. Mas se for um aplicativo que \u00e9 vital para o funcionamento da empresa, comunica\u00e7\u00e3o e decis\u00f5es, o mais importante \u00e9 conquistar a confian\u00e7a dos usu\u00e1rios, ou seja, n\u00e3o deix\u00e1-los na m\u00e3o e n\u00e3o falhar. Porque todo o trabalho pode parar se algo interno n\u00e3o funcionar.<\/p>\n
Bitrix24 como SaaS<\/h4>\n \nO primeiro prot\u00f3tipo foi montado um ano antes do lan\u00e7amento p\u00fablico, em 2011. Levou cerca de uma semana, testamos e rodamos \u2014 ele funcionava. Ou seja, era poss\u00edvel entrar no formul\u00e1rio, inserir o nome do portal e um novo portal era criado, com uma base de usu\u00e1rios estabelecida. Analisamos o produto em si, avaliamos e, em seguida, passamos um ano aprimorando. Porque t\u00ednhamos uma grande tarefa: n\u00e3o quer\u00edamos criar duas bases de c\u00f3digo diferentes, n\u00e3o quer\u00edamos manter um produto de caixa separado de solu\u00e7\u00f5es em nuvem \u2014 quer\u00edamos fazer tudo isso dentro de um \u00fanico c\u00f3digo. <\/p>\n
Formulamos os requisitos: a capacidade de se posicionar em diferentes locais, suportar replica\u00e7\u00e3o, idealmente ser distribu\u00eddo em diferentes data centers geograficamente. Separar a l\u00f3gica do produto do armazenamento de dados. Ser capaz de escalar dinamicamente, levando em conta a carga, e retirar a parte est\u00e1tica completamente. Com base nesses princ\u00edpios, foram elaborados os requisitos para o produto, que aprimoramos durante um ano. Nesse tempo, na plataforma que resultou \u00fanica \u2014 para solu\u00e7\u00f5es de caixa e para nosso pr\u00f3prio servi\u00e7o \u2014 implementamos o suporte para as ferramentas necess\u00e1rias. O suporte \u00e0 replica\u00e7\u00e3o MySQL foi integrado ao n\u00edvel do pr\u00f3prio produto: ou seja, o desenvolvedor, ao escrever o c\u00f3digo, n\u00e3o precisa se preocupar em como suas solicita\u00e7\u00f5es ser\u00e3o distribu\u00eddas, ele usa nossa API, e n\u00f3s sabemos como distribuir corretamente as solicita\u00e7\u00f5es de grava\u00e7\u00e3o e leitura entre mestres e escravos. <\/p>\n
Implementamos o suporte para diferentes armazenamento de objetos em nuvem no n\u00edvel do produto: Google Storage, Amazon S3 \u2014 al\u00e9m disso, suporte ao OpenStack Swift. Portanto, isso foi conveniente tanto para n\u00f3s como servi\u00e7o, quanto para os desenvolvedores que trabalham com a solu\u00e7\u00e3o de caixa: se eles simplesmente utilizam nossa API, n\u00e3o precisam se preocupar com onde o arquivo ser\u00e1 salvo, se localmente no sistema de arquivos ou se ir\u00e1 para um armazenamento de objetos.<\/p>\n
Decidimos imediatamente que far\u00edamos reservas a n\u00edvel de um data center inteiro. Em 2012, come\u00e7amos totalmente na Amazon AWS, pois j\u00e1 t\u00ednhamos experi\u00eancia com essa plataforma \u2014 nosso pr\u00f3prio site estava hospedado l\u00e1. O que nos atra\u00eda era que em cada regi\u00e3o da Amazon existem v\u00e1rias zonas de disponibilidade \u2014 essencialmente, (na terminologia deles) v\u00e1rios data centers que s\u00e3o mais ou menos independentes entre si e nos permitem fazer reservas a n\u00edvel de um data center inteiro: se um deles falhar, os bancos de dados se replicam master-master, os servidores de aplica\u00e7\u00f5es web s\u00e3o reservados, e a est\u00e1tica \u00e9 movida para o armazenamento de objetos S3. A carga \u00e9 balanceada \u2014 naquele momento pelo ELB da Amazon, mas logo depois chegamos a nossos pr\u00f3prios balanceadores, pois precis\u00e1vamos de uma l\u00f3gica mais complexa. <\/p>\n
O que quer\u00edamos, conseguimos\u2026<\/h4>\n \nTodas as coisas b\u00e1sicas que quer\u00edamos garantir \u2014 a resili\u00eancia dos pr\u00f3prios servidores, aplica\u00e7\u00f5es web, bancos de dados \u2014 tudo funcionava bem. O cen\u00e1rio mais simples: se uma das aplica\u00e7\u00f5es web falhasse, era bem simples \u2014 elas eram desligadas do balanceamento. <\/p>\n
N\u00f3s operamos em todo o mundo, com picos de carga muito diferentes entre os clientes, e, idealmente, devemos ter a capacidade de realizar qualquer tipo de manuten\u00e7\u00e3o em qualquer componente de nosso sistema a qualquer momento \u2014 sem que os clientes percebam. Portanto, temos a possibilidade de desligar o banco de dados, redistribuindo a carga para o segundo data center. <\/p>\n
Como tudo isso funciona? \u2014 N\u00f3s redirecionamos o tr\u00e1fego para um data center em funcionamento \u2014 se houver uma falha no data center, redirecionamos completamente; se forem nossas manuten\u00e7\u00f5es programadas em uma base espec\u00edfica, redirecionamos parte do tr\u00e1fego dos clientes desse data center para o segundo, suspendendo a replica\u00e7\u00e3o. Se forem necess\u00e1rias novas m\u00e1quinas para aplicativos da web, devido ao aumento da carga no segundo data center, elas s\u00e3o iniciadas automaticamente. Conclu\u00edmos as opera\u00e7\u00f5es, a replica\u00e7\u00e3o \u00e9 restaurada e retornamos toda a carga. Se precisarmos realizar opera\u00e7\u00f5es sincronizadas no segundo data center, como instalar atualiza\u00e7\u00f5es do sistema ou alterar configura\u00e7\u00f5es na segunda base de dados, repetimos todo o processo, apenas na dire\u00e7\u00e3o oposta. Em caso de falha, fazemos tudo de maneira simples: usamos mecanismos de event-handlers no sistema de monitoramento. Se v\u00e1rias verifica\u00e7\u00f5es falharem e o status mudar para cr\u00edtico, esse handler \u00e9 acionado, executando a l\u00f3gica apropriada. Para cada base, definimos qual servidor \u00e9 o failover e para onde devemos redirecionar o tr\u00e1fego em caso de n\u00e3o disponibilidade. Historicamente, usamos de alguma forma o Nagios ou seus forks. Basicamente, mecanismos semelhantes est\u00e3o dispon\u00edveis em quase todos os sistemas de monitoramento; ainda n\u00e3o utilizamos algo mais complexo, mas \u00e9 poss\u00edvel que o fa\u00e7amos no futuro. Atualmente, o monitoramento \u00e9 acionado pela indisponibilidade e tem a capacidade de redirecionar algo.<\/p>\n
Reservamos tudo?<\/h4>\n \nTemos muitos clientes dos EUA, muitos clientes da Europa, muitos clientes mais pr\u00f3ximos do Oriente \u2014 Jap\u00e3o, Singapura e assim por diante. Naturalmente, uma grande parte dos clientes est\u00e1 na R\u00fassia. Ou seja, o trabalho n\u00e3o se limita a uma \u00fanica regi\u00e3o. Os usu\u00e1rios desejam uma resposta r\u00e1pida, h\u00e1 requisitos para atender a diferentes leis locais, e dentro de cada regi\u00e3o reservamos dois data centers, al\u00e9m de haver alguns servi\u00e7os adicionais que, novamente, s\u00e3o convenientes de localizar em uma \u00fanica regi\u00e3o \u2014 para os clientes que operam nessa regi\u00e3o. Processadores REST, servidores de autoriza\u00e7\u00e3o, s\u00e3o menos cr\u00edticos para a opera\u00e7\u00e3o do cliente como um todo, e \u00e9 poss\u00edvel alternar entre eles com um pequeno atraso aceit\u00e1vel, mas n\u00e3o queremos reinventar a roda em termos de como monitor\u00e1-los e o que fazer com eles. Portanto, sempre que poss\u00edvel, tentamos usar solu\u00e7\u00f5es j\u00e1 existentes, e n\u00e3o desenvolver uma compet\u00eancia para produtos adicionais. Em alguns casos, usamos simplesmente a altern\u00e2ncia a n\u00edvel de DNS, e a vitalidade do servi\u00e7o \u00e9 definida pelo mesmo DNS. No Amazon, existe o servi\u00e7o Route 53, mas n\u00e3o \u00e9 apenas um DNS onde voc\u00ea pode adicionar registros e pronto \u2014 ele \u00e9 muito mais flex\u00edvel e conveniente. Atrav\u00e9s dele, \u00e9 poss\u00edvel construir servi\u00e7os geograficamente distribu\u00eddos com geolocaliza\u00e7\u00f5es, onde voc\u00ea, com a sua ajuda, determina de onde veio o cliente e fornece os registros adequados \u2014 \u00e9 poss\u00edvel construir arquiteturas de failover com ele. Os mesmo health-checks s\u00e3o configurados diretamente no Route 53, onde voc\u00ea define o endpoint que ser\u00e1 monitorado, define as m\u00e9tricas, define quais protocolos usar para determinar a 'vitalidade' do servi\u00e7o \u2014 tcp, http, https; define a periodicidade das verifica\u00e7\u00f5es que determinam se o servi\u00e7o est\u00e1 ativo ou n\u00e3o. E no pr\u00f3prio DNS, voc\u00ea especifica qual ser\u00e1 o prim\u00e1rio, qual ser\u00e1 o secund\u00e1rio, para onde alternar caso um health-check seja acionado dentro do Route 53. Tudo isso pode ser feito com outras ferramentas, mas a vantagem \u00e9 que voc\u00ea configura uma vez e depois n\u00e3o pensa mais em como est\u00e3o as verifica\u00e7\u00f5es, como se d\u00e1 a altern\u00e2ncia: tudo funciona automaticamente.<\/p>\n
A primeira 'mas'<\/b>: como e com o que fazer backup do route 53? Caso algo aconte\u00e7a com ele, o que fazer? Por sorte, nunca passamos por isso, mas, novamente, vou contar por que achamos que \u00e9 preciso fazer backup. Aqui nos precavemos. V\u00e1rias vezes ao dia, fazemos uma exporta\u00e7\u00e3o completa de todas as zonas que temos no route 53. A API da Amazon permite entreg\u00e1-las em JSON, e temos v\u00e1rios servidores de backup que configuramos para onde convertemos isso, exportamos como arquivos de configura\u00e7\u00e3o e, grosso modo, temos uma configura\u00e7\u00e3o de backup. Caso necess\u00e1rio, podemos rapidamente restaur\u00e1-la manualmente, sem perder as configura\u00e7\u00f5es DNS.<\/p>\n
O segundo \"mas\"<\/b>: o que ainda n\u00e3o est\u00e1 reservado nessa situa\u00e7\u00e3o? O pr\u00f3prio balanceador de carga! A distribui\u00e7\u00e3o de clientes por regi\u00f5es foi feita de maneira bastante simples. Temos os dom\u00ednios bitrix24.ru, bitrix24.com, .de \u2014 atualmente s\u00e3o cerca de 13 diferentes, operando em v\u00e1rias zonas. Chegamos \u00e0 seguinte solu\u00e7\u00e3o: em cada regi\u00e3o, temos seus pr\u00f3prios balanceadores. \u00c9 mais conveniente distribuir por regi\u00f5es, dependendo da carga m\u00e1xima de rede em cada uma. Se houver uma falha em um \u00fanico balanceador, ele simplesmente \u00e9 retirado de opera\u00e7\u00e3o e removido do DNS. Se ocorrer um problema com um grupo de balanceadores, eles s\u00e3o reservados em outras localidades, e a troca entre eles \u00e9 feita utilizando o pr\u00f3prio Route 53, pois devido ao TTL curto, a troca acontece no m\u00e1ximo em 2, 3 ou 5 minutos. <\/p>\n
O terceiro \"mas\"<\/b>: o que mais n\u00e3o est\u00e1 reservado? S3, certo. Ao armazenarmos arquivos que temos de usu\u00e1rios no S3, acredit\u00e1vamos sinceramente que ele era \u00e0 prova de balas e que n\u00e3o precisava de reservas. Mas a hist\u00f3ria mostra que as coisas costumam ser diferentes. De fato, a Amazon descreve o S3 como um servi\u00e7o fundamental, porque a pr\u00f3pria Amazon utiliza o S3 para armazenar imagens de m\u00e1quinas, configura\u00e7\u00f5es, imagens AMI, snapshots\u2026 E se o S3 falha, como aconteceu uma vez nos \u00faltimos 7 anos em que utilizamos o Bitrix24, ele acaba arrastando uma s\u00e9rie de problemas \u2014 indisponibilidade de inicializa\u00e7\u00e3o de VMs, falhas no funcionamento da API, e assim por diante. <\/p>\n
E a S3 pode falhar \u2014 isso j\u00e1 aconteceu uma vez. Portanto, chegamos \u00e0 seguinte abordagem: h\u00e1 alguns anos, n\u00e3o havia reposit\u00f3rios p\u00fablicos de objetos s\u00e9rios na R\u00fassia, e consideramos a op\u00e7\u00e3o de criar algo pr\u00f3prio... Felizmente, n\u00e3o come\u00e7amos a faz\u00ea-lo, pois nos ter\u00edamos enredado em uma especializa\u00e7\u00e3o da qual n\u00e3o dispunhamos e, com certeza, ter\u00edamos cometido erros. Agora, h\u00e1 reposit\u00f3rios compat\u00edveis com S3 na Mail.ru, na Yandex e em v\u00e1rios outros provedores. No final, chegamos \u00e0 conclus\u00e3o de que quer\u00edamos ter, em primeiro lugar, redund\u00e2ncia, e em segundo lugar, a possibilidade de trabalhar com c\u00f3pias locais. Para a regi\u00e3o espec\u00edfica da R\u00fassia, usamos o servi\u00e7o Mail.ru Hotbox, que \u00e9 compat\u00edvel com S3 via API. N\u00e3o precis\u00e1vamos de grandes ajustes no c\u00f3digo dentro do aplicativo, e implementamos o seguinte mecanismo: no S3, existem gatilhos que s\u00e3o ativados na cria\u00e7\u00e3o\/removal de objetos; a Amazon tem um servi\u00e7o chamado Lambda \u2014 \u00e9 uma execu\u00e7\u00e3o de c\u00f3digo serverless, que ser\u00e1 realizada exatamente quando certos gatilhos forem acionados.<\/p>\n
No n\u00edvel do c\u00f3digo, temos os dois armaz\u00e9ns configurados para cada cliente: um considerado principal e o outro de backup. Se tudo vai bem, trabalhamos com o armaz\u00e9m que est\u00e1 mais pr\u00f3ximo de n\u00f3s: ou seja, nossos clientes que est\u00e3o na Amazon trabalham com S3, enquanto aqueles que operam na R\u00fassia utilizam Hotbox. Se um sinalizador \u00e9 acionado, devemos ativar o failover, e mudamos os clientes para outro armaz\u00e9m. Podemos ativar esse sinalizador independentemente por regi\u00f5es e podemos altern\u00e1-los. Na pr\u00e1tica, ainda n\u00e3o usamos isso, mas o mecanismo foi previsto e acreditamos que um dia precisaremos dessa troca. Isso j\u00e1 aconteceu uma vez. <\/p>\n
Oh, parece que sua Amazon fugiu...<\/h4>\n \nNeste abril, comemoramos o anivers\u00e1rio do in\u00edcio das limita\u00e7\u00f5es do Telegram na R\u00fassia. O provedor mais afetado por isso foi a Amazon. E, infelizmente, as empresas russas que operavam globalmente sofreram mais. <\/p>\n
Se a empresa \u00e9 global e a R\u00fassia representa apenas uma fra\u00e7\u00e3o pequena, de 3 a 5%, de qualquer forma, elas podem ser sacrificadas. <\/p>\n
Se for uma empresa completamente russa \u2014 estou certo de que \u00e9 necess\u00e1rio operar localmente \u2014 simplesmente ser\u00e1 mais conveniente e confort\u00e1vel para os usu\u00e1rios, e haver\u00e1 menos riscos. <\/p>\n
E se essa empresa operar globalmente e tiver aproximadamente um n\u00famero equilibrado de clientes na R\u00fassia e em outras partes do mundo? A conectividade entre os segmentos \u00e9 importante, e eles precisam trabalhar juntos de alguma forma. <\/p>\n
No final de mar\u00e7o de 2018, a Roskomnadzor enviou uma carta para os maiores provedores, informando que planejavam bloquear milh\u00f5es de IPs da Amazon para bloquear... o mensageiro Zello. Agradecemos a esses pr\u00f3prios provedores \u2014 eles vazaram a carta, e surgiu a compreens\u00e3o de que a conectividade com a Amazon poderia ruir. Era uma sexta-feira, e n\u00f3s, em p\u00e2nico, fomos at\u00e9 os colegas da servers.ru, dizendo: 'Amigos, precisamos de alguns servidores que n\u00e3o fiquem na R\u00fassia, n\u00e3o na Amazon, mas, por exemplo, em algum lugar em Amsterdam', para que possamos, de alguma maneira, ter nossos pr\u00f3prios servi\u00e7os l\u00e1. vpn<\/a> e proxy para alguns endpoints, nos quais n\u00e3o temos como influenciar, como os endpoints do s3 \u2014 n\u00e3o podemos simplesmente criar um novo servi\u00e7o e obter um IP diferente, ainda precisamos acess\u00e1-los. Em poucos dias, configuramos esses servidores, os levantamos e, de modo geral, nos preparamos antes do in\u00edcio das restri\u00e7\u00f5es. Curiosamente, o RKN, ao ver toda a agita\u00e7\u00e3o e p\u00e2nico gerados, disse: 'N\u00e3o, agora n\u00e3o vamos bloquear nada.' (Mas isso foi at\u00e9 o momento em que come\u00e7aram a bloquear o Telegram.) Ap\u00f3s configurar as possibilidades de contorno e perceber que a restri\u00e7\u00e3o n\u00e3o havia sido imposta, decidimos, mesmo assim, n\u00e3o desmontar tudo isso. Assim, apenas por precau\u00e7\u00e3o. <\/p>\n
E como fazer a redund\u00e2ncia... de um provedor inteiro?<\/h4>\n \nAtualmente, n\u00e3o temos um cen\u00e1rio para a falha total da Amazon. Temos um cen\u00e1rio semelhante para a R\u00fassia. Na R\u00fassia, est\u00e1vamos alocados em um provedor que escolhemos para ter v\u00e1rias localiza\u00e7\u00f5es. E h\u00e1 um ano, enfrentamos um problema: mesmo que fossem dois data centers, j\u00e1 no n\u00edvel de configura\u00e7\u00e3o da rede do provedor, podem haver problemas que afetariam ambos os data centers. E podemos acabar enfrentando indisponibilidade em ambas as localiza\u00e7\u00f5es. Claro, isso aconteceu. No final, reconsideramos a arquitetura interna. Ela n\u00e3o mudou muito, mas para a R\u00fassia agora temos duas localiza\u00e7\u00f5es que n\u00e3o est\u00e3o sob um \u00fanico provedor, mas sim em dois diferentes. Se um deles falhar, podemos mudar para o outro.<\/p>\n
Hipoteticamente, para a Amazon, estamos considerando a possibilidade de fazer reservas em n\u00edvel de outro provedor; talvez o Google, talvez algum outro... Mas at\u00e9 agora, observamos na pr\u00e1tica que se ocorrerem falhas na Amazon em uma zona de disponibilidade, falhas em n\u00edvel regional s\u00e3o fen\u00f4menos bastante raros. Portanto, temos uma ideia te\u00f3rica de que talvez possamos fazer uma reserva 'Amazon - n\u00e3o Amazon', mas na pr\u00e1tica isso ainda n\u00e3o existe. <\/p>\n
Algumas palavras sobre automa\u00e7\u00e3o<\/h4>\n \nA automa\u00e7\u00e3o \u00e9 sempre necess\u00e1ria? Aqui \u00e9 pertinente lembrar o efeito Dunning-Kruger. No eixo 'x', temos nosso conhecimento e experi\u00eancia, que adquirimos, e no eixo 'y' \u2014 a confian\u00e7a em nossas a\u00e7\u00f5es. No in\u00edcio, n\u00e3o sabemos nada e n\u00e3o temos confian\u00e7a alguma. Depois, sabemos um pouco e nos tornamos mega-confiantes \u2014 isso \u00e9 o que chamamos de 'pico da ignor\u00e2ncia', bem ilustrado pela imagem 'imbecilidade e bravura'. Em seguida, aprendemos um pouco e estamos prontos para entrar em a\u00e7\u00e3o. Ent\u00e3o, cometemos alguns erros s\u00e9rios, ca\u00edmos no vale da desesperan\u00e7a, onde parece que sabemos algo, mas na verdade sabemos muito pouco. Depois, \u00e0 medida que adquirimos experi\u00eancia, nos tornamos mais confiantes.<\/p>\n
Conclus\u00e3o<\/h4>\n \nEm 7 anos, passamos de momentos de p\u00e2nico quando algo falhava, para uma compreens\u00e3o de que n\u00e3o existem problemas, apenas tarefas que precisam \u2014 e podem \u2014 ser resolvidas. Quando voc\u00ea cria um servi\u00e7o, olhe para ele de uma perspectiva elevada, avalie todos os riscos que podem surgir. Se voc\u00ea os v\u00ea de imediato \u2014 ent\u00e3o, preveja a redund\u00e2ncia e a possibilidade de construir uma infraestrutura tolerante a falhas, porque qualquer ponto que possa falhar e levar \u00e0 inoperabilidade do servi\u00e7o \u2014 definitivamente ir\u00e1 falhar. E mesmo que voc\u00ea ache que alguns elementos da infraestrutura, como o pr\u00f3prio S3, n\u00e3o v\u00e3o falhar, tenha em mente que eles podem falhar. E, pelo menos em teoria, tenha uma ideia do que far\u00e1 com eles se algo realmente acontecer. Tenha um plano para lidar com os riscos. Ao considerar se deve fazer tudo automaticamente ou manualmente, avalie os riscos: o que acontecer\u00e1 se a automa\u00e7\u00e3o come\u00e7ar a fazer todas as altern\u00e2ncias \u2014 isso n\u00e3o levar\u00e1 a uma situa\u00e7\u00e3o pior do que a falha original? Pode ser que, em alguns casos, seja necess\u00e1rio um compromisso razo\u00e1vel entre o uso da automa\u00e7\u00e3o e a rea\u00e7\u00e3o do engenheiro de plant\u00e3o, que avaliar\u00e1 a situa\u00e7\u00e3o real e entender\u00e1 se algo deve ser alternado imediatamente ou \u2018sim, mas n\u00e3o agora\u2019.<\/p>\n
Um compromisso sensato entre o perfeccionismo e os recursos reais, o tempo e o dinheiro que voc\u00ea pode gastar na solu\u00e7\u00e3o que voc\u00ea, no final, ter\u00e1.<\/p>\n
Este texto \u00e9 uma vers\u00e3o aumentada e expandida da apresenta\u00e7\u00e3o de Alexander Demidov na confer\u00eancia. Uptime dia 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\")