Содержание статьи
- Проблематика крупной ИТ-структуры
- Преимущества облачных решений
- Что такое мультиоблако
- Проектирование облачной структуры для 1000 пользователей 1С
- Пример архитектуры и ориентировочный бюджет
- Выводы статьи
Проблематика крупной ИТ-структуры
Существует убеждение — крупные ИТ-структуры должны быть построены на собственных мощностях компании и обслуживаться собственным штатом ИТ-специалистов, исходя из многих факторов:- Регулирование доступа к конфиденциальным данным (ФЗ-152);
- Контроль утечки корпоративной информации;
- Особенности кадровой политики;
- Расчеты экономического отдела;
- Разветвленная структура ИТ-департамента;
- Убеждения ТОП-менеджмента и собственников.
- Крупные капитальные затраты на закупку и модернизацию оборудования, программного обеспечения, системы кондиционирования, пожаротушения и т.д.;
- Регулярные затраты на электроэнергию, систему охлаждения, техническое обслуживание;
- Расширение серверных ресурсов занимает определенное время;
- Отсутствие высокой доступности ресурсов в компании с множеством филиалов;
- Стихийные бедствия, физическое проникновение, противоправные действия третьих лиц;
- Высокая стоимость внедрения катастрофоустойчивости.
Структура подвержена экономическим, техническим, юридическим и физическим рискам, что является ощутимой проблемой в стратегическом плане развития.
Преимущества облачных решений
Облаком принято называть ряд сервисов и информационных ресурсов, расположенных в центрах обработки данных, которые имеют определенный уровень защищенности, отказоустойчивости и безопасности.Преимущества размещения своей структуры в облаке:
- С помощью кластерных технологий достигается высокий уровень отказоустойчивости сервисов;
- Клиентам предоставляются финансовые и юридические гарантии SLA;
- Операционные затраты легко прогнозируемы, а капитальные практически отсутствуют;
- Техническая поддержка работает в круглосуточном режиме. Используется система постановки задач с приоритезацией и отчетностью;
- В штате собрана команда сертифицированных ИТ-специалистов, с опытом решения задач разной сложности;
- Сохранность и конфиденциальность данных, продвинутая система резервного копирования с уведомлением клиента.
Что такое мультиоблако
Мультиоблачная структура — это такая концепция ИТ-архитектуры, где сервисы компании располагаются на двух и более облачных провайдерах.Преимущества мультиоблачной архитектуры очевидны:
- Высокий уровень отказоустойчивости структуры, возможен полноценный кластер с онлайн-синхронизацией и автоматическим переключением;
- Распределение рисков. При форс-мажоре у одного провайдера — остальные продолжают быть доступными и работа компании не останавливается;
- Концепция мультиоблака позволяет получить от каждого провайдера его сильные стороны, перекрыв недостатки другими поставщиками услуг;
- Возможность подобрать облачного провайдера, который находится ближе к удаленным филиалам для оптимизации сетевого отклика;
- Возможность предоставить временные мощности разработчикам, подрядчикам и прочим сотрудникам, не входящим в штат компании, при этом соблюдая требования корпоративной ИТ-безопасности.
Проектирование облачной структуры для 1000 пользователей 1С
Рисунок 1 — Проектирование облачной структуры для 1000 пользователей 1С
Сбор требований к структуре
Золотое правило — перед тем, как начинать что-то строить, проект нужно тщательно отрисовать на бумаге. В проектном менеджменте (модель Waterfall) этот этап называется Архитектурирование проекта. Этот этап начинается со сбора требований к будущей архитектуре облака. На наш взгляд, нужно проработать такие ключевые вопросы:- Точное количество пользователей, которые будут работать в облаке;
- Тип конфигураций баз 1С, наличие ключей аппаратной защиты;
- Допустимое время простоя при недоступности сервиса за определенный период;
- Объемы баз данных (включая логи транзакций), которые будут мигрировать в облако;
- Объемы пользовательских данных, необходимых для функционирования сервиса 1С;
- Перечень торгового оборудования, подключенного к 1С — принтеры этикеток, терминалы сбора данных, онлайн-кассы, сканеры и прочее оборудование;
- Наличие прочего программного обеспечения, связанного с 1С. Обмены данных, выгрузки на сайты и интернет-магазины, внешние обработки, интеграция с другими сервисами и SaaS-продуктами;
- Объемы среды разработки и тестовой среды, эту информацию формируют разработчики кода 1С;
- Периодичность резервного копирования и глубина хранения архива;
- Требования к уровню защиты каналов связи с облаком и ограничением сетевого доступа внутри периметра облака (к примеру, между средой разработки, тестирования и производственной средой);
- Прочие нюансы текущей ИТ-структуры, которая обслуживает сервисы программного обеспечения 1С.
Таким образом, при тщательной проработке этого этапа — у команды внедрения и системной интеграции на руках будет четкий и понятный документ, описывающий все ключевые параметры ИТ-структуры, с которым она может приступить к этапу составления ИТ-архитектуры будущего облака.
Имитация нагрузок и ресайзинг для вычисления необходимых ресурсов
В качестве второго этапа подготовки правильной облачной архитектуры, рекомендуем проведение теоретических расчетов требуемых мощностей, выполнение практических тестов по замерам производительности ресурсов на небольшом объеме пользователей и проецирование результатов на необходимые ключевые параметры ИТ-структуры. Для этого, необходимо выполнить ряд нагрузочных тестов совместно со специалистами по технологической платформе и разработчиками кода 1С, базированных на инструментарии 1С:КИП и методике APDEX:На основании имеющихся реестров процессов и контрольных примеров макета базы 1С — необходимо создать матрицу сценариев тестирования должной производительности и объемов ресурсов.
Количественные и целевые показатели операций могут быть усредненно рассчитаны, исходя из данных реальных баз 1С и экспертных оценок. На входе сценария можно заложить количество вводимых документов в день по каждому виду документа, количество пользователей и время тестирования, а система способна сама рассчитать — сколько документов/отчетов должно создаваться и проводиться за указанный промежуток времени и с каким интервалом.
Тесты должны проводиться в рамках нескольких групп пользователей. Группа может состоять из 4 пользователей, у каждого из которых своя роль и перечень последовательных операций, которые выполняет каждый из пользователей:
- количество групп пользователей обычно рассчитывается по формуле N=K/4, где K – количество пользователей (из расчета, что в одной группе 4 пользователя);
- количество цепочек на одну группу обычно рассчитывается исходя из того, что одна группа в день за 8 рабочих часов делает 24 цепочки. Таким образом, за 1 час одна группа делает 24/8=3 цепочки с интервалом 20 минут;
- количество номенклатур в массиве, из которого будет случайным образом подбираться номенклатура в документ поступления, обычно рассчитывается по формуле: P=(K/4)*10*93%, где K – это количество пользователей.
Перед началом тестирования требуется определить эталонные показатели APDEX по нагрузке на систему (на одного пользователя):
- Обращений к диску в секунду;
- Потребляемая оперативная память;
- Потребляемые процессорные мощности.
На основании этих показателей, производится предварительный теоретический расчет требований к параметрам оборудования, к примеру на 50 пользователей баз 1С.
Далее, исходя из этих расчетов, проводится второй ряд тестов на 50 пользователей. Производится сверка теоретических прогнозов с фактическими расчетами, выводится коэффициент погрешности.
Аналогично, производится повторение итераций тестов APDEX на 100, 200 и 500 пользователей. Для каждой итерации обязательно требуется сверка теоретических прогнозов ИТ-архитекторов с фактическими расчетами и выводится допустимый коэффициент погрешности.
В итоге, благодаря практическим тестам и коэффициенту погрешности, архитекторы облачной структуры имеют возможность довольно точно определить пул необходимых ресурсов методом прямой экстраполяции замеров, полученных на меньших объемах. При этом, полученные данные будут максимально приближены к реальности с минимальными затратами на расчеты.
Составление архитектуры, подбор вариантов площадок
Подготовка архитектуры облачной ИТ-структуры — процесс крайне ответственный и важный, имеющий огромное влияние на финальный результат. Говоря простым языком — при плохой архитектуре можно потратить серьезный бюджет, время специалистов и получить в итоге некачественную, тормозящую и падающую ИТ-структуру.Основные принципы при составлении облачной ИТ-архитектуры:
- Определение критериев качественной работы облачной ИТ-структуры, внесение их в SLA;
- Формирование границ бюджета и сроков проекта;
- Гарантирование должного уровня производительности и отклика структуры, который был определен на этапе сбора требований и ресайзинга;
- Определение методов и инструментов обеспечения безопасности на соответствующем уровне;
- Обеспечение доступности и отказоустойчивости согласно утвержденному SLA;
- Описание методов подключения и доступа к интерфейсам структуры;
- Прогнозирование роста структуры на определенный период;
- Распределение ролей и функций (матрица RACI);
- Прогнозирование и анализ рисков (матрицы FMEA и SFIA).
Выбор вариантов облачных площадок и сервисов
Ключевые критерии при выборе поставщиков облачных услуг:- Стоимость пула услуг или оборудования;
- Стек инструментов и технологий, хорошо знакомый команде ИТ-внедрения;
- Четкое и приемлемое Соглашение о качестве услуг (SLA либо в некоторых случаях — OLA);
- Возможность предварительного тестирования услуг на определенный срок;
- Политика обеспечения резервного копирования и мониторинга (в случае модели SaaS);
- Удобный и дружелюбный интерфейс панели управления;
- Наличие персонального менеджера с выделенным контактным номером;
- Отзывы о качестве работы на популярных интернет-ресурсах.
Характеристики дата-центров
Внедрение ядра ИТ-структуры 1С (более 1000 пользователей). Ключевые рекомендации.
В данном разделе мы будем говорить о более традиционном варианте организации масштабной ИТ-структуры, базированной на арендованных облачных выделенных серверах и ресурсах (так называемый PaaS). Ибо вариант создания архитектуры таких масштабов, базированной на микросервисах (Azure Web App, AWS Beanstalk, CloudDB с использованием load-balancer, autoscaling и т.д.) — является темой отдельной статьи.Рекомендуемое программное обеспечение (на момент написания статьи)
Операционная система:
Microsoft Windows Server 2019
Сервис СУБД:
Microsoft SQL Server 2019
Резервное копирование:
Veeam Backup & Replication v11
Система мониторинга:
Zabbix
Серверы распределенных баз данных для структуры 1С
- Не менее двух процессоров серии Intel® Xeon® Gold или AMD EPYC® с рекомендуемой частотой ядра от 2,6 Ghz в базовом режиме и количеством физических ядер — не менее 8 на каждый процессор;
- Объем оперативной памяти — не менее 256 Gb DDR4 с частотой не ниже 2933 MHz;
- Операционную систему рекомендуем размещать на отдельных SSD-дисках или устройствах SataDOM;
- Под базы данных рекомендуем использовать SSD-диски NVME;
- Рекомендуем распределять файлы баз данных, логи транзакций, служебные базы tmp и master по разным логическим томам, в идеале — по разным RAID-массивам;
- Рекомендуем в настройках установить максимально отведенный объем ОЗУ для этого сервера и максимальное кол-во потоков;
- Требуется выполнить базовую настройку серверов СУБД согласно рекомендациям Microsoft;
- Не забывайте также о настройке ключевых регламентных заданий по обслуживанию СУБД.
- Для данной структуры рекомендуем создание дублирующего сервера СУБД с вычислительными мощностями не менее 60% – 70% от характеристик основного;
- Репликацию баз данных рекомендуем делать на базе технологии MS SQL AlwaysON;
- Рекомендуем тип репликации «асинхронный». В таком варианте система не будет замедляться из-за ожидания отклика от резервной структуры.
- Рекомендуем данный сервис оставить во внутренней приватной зоне сети, без прямого доступа извне;
- Провести настройку Firewall, оставить открытыми только необходимые порты MS SQL, доступные только для пула адресов серверов 1С;
- Рекомендуем соблюдать политику конфиденциальности и требования к сложности паролей от Microsoft.
Серверы 1С:Предприятие
- Программа 1С предпочитает высокую частоту многоядерности. Поэтому, рекомендуем не менее двух процессоров серии Intel® Xeon® или AMD EPYC® с рекомендуемой частотой ядра от 3,0 Ghz в базовом режиме и количеством физических ядер — не менее 8 на каждый процессор;
- Поскольку требования к дисковой подсистеме не так высоки, как у серверов СУБД — это может быть как отдельный аппаратный сервер, так и виртуальная машина. Делайте выбор исходя из бюджета и преимуществ определенного решения;
- Также хорошо себя зарекомендовала методика разделения основных операций 1С, фоновых заданий и тяжелых расчетов по разным экземплярам серверов 1С:Предприятие. Этот функционал доступен в последних версиях платформы 1С:Предприятие версии КОРП;
- В отдельных случаях Вы можете встретить рекомендацию по включению режима SharedMemory. За счет прямого доступа к памяти этот режим действительно ускоряет взаимодействие 1С и СУБД до 20%. Однако он требует, чтобы сервер 1С:Предприятие и СУБД находился в одной операционной системе, что в нашей архитектуре +1000 пользователей сделать практически невозможно из-за высоких нагрузок;
- Рекомендуем выполнить базовую настройку серверов 1С согласно лучшим практикам и рекомендациям производителя.
- Рекомендуем иметь минимум два отдельных сервера 1С:Предприятие с локальным или геозональным разделением;
- Рекомендуется настроить кластер основного и резервного серверов 1С:Предприятие.
- Рекомендуем данный сервис оставить во внутренней приватной зоне сети, без прямого доступа извне;
- Провести настройку Firewall, оставить открытыми только необходимые порты MS SQL, доступные только для пула адресов серверов терминального доступа и web-служб 1С;
- Рекомендуем соблюдать политику конфиденциальности и требования к сложности паролей.
Вариант 1. Серверы WEB-доступа для web-интерфейса 1С
- По нашему опыту, для web-серверов нужно закладывать отдельные экземпляры виртуальных машин, т.к. нагрузка от 1000 одновременных web-соединений будет ощутимая;
- Web-запросы не такие тяжелые, как соединения полноформатных клиентов 1С, поэтому виртуальные машины вполне подойдут для этой роли;
- Для ускорения работы запросов web — можно делать соединения через открытые каналы Интернет, а не по туннелю. Протокол https сам по себе достаточно защищен шифрованием ssl от фишинга и перехвата данных.
- Для обеспечения отказоустойчивости экземпляров web-серверов используется служба кластера виртуальных машин;
- Для обеспечения отказоустойчивости соединений используется прокси сервер (к примеру HAProxy).
- Рекомендуем тщательно настроить правила безопасности web-серверов (IIS или Apache) согласно рекомендациям производителей ПО;
- Рекомендуем закрыть все неиспользуемые порты, а соединение с web-серверами 1С перевести на протокол https (с ssl-шифрованием).
Вариант 2. Серверы терминального доступа для полноформатного клиента 1С
- По нашему опыту, нужно закладывать отдельный сервер терминального доступа на каждые 100 пользователей 1С + один резервный сервер терминалов на всю структуру;
- Поскольку требования к дисковой подсистеме у серверов терминалов не так высоки, как у серверов СУБД — как правило под них арендуют виртуальные машины;
- По нашему опыту, для высоконагруженных конфигураций 1С типа ERP — закладывайте до 1,5-2 Гб ОЗУ на каждого пользователя. Для менее нагруженных (УТ, БУХ) — до 1 Гб;
- Дисковая подсистема — рекомендуем арендовать массивы, базированные на SSD-дисках с пропускной способностью iops не менее 3000. Все таки, серверы терминалов имеют статус интерактивных и обращения к дисковой подсистеме там будут интенсивные;
- Рекомендуем выполнить базовую настройку серверов терминального доступа согласно лучшим практикам и рекомендациям Microsoft.
- Для обеспечения отказоустойчивости рекомендуем использовать службу TS Broker, расположенную на отдельной виртуальной машине. С ее помощью и за счет кластерного сервиса NLB — сеансы пользователей равномерно распределяются по всей ферме серверов терминального доступа и автоматически переключаются при наступлении форс-мажорной ситуации с одним из них;
- Не забывайте persistent-данные вынести за пределы фермы терминального доступа (к примеру, профили, файловые документы и прочие статические данные должны храниться на отдельном сетевом ресурсе). В идеале, серверы терминального доступа должны быть stateless;
- Для создания отказоустойчивой фермы терминалов требуется n+1 количество экземпляров серверов терминального доступа.
- Рекомендуем тщательно настроить групповые политики для регулирования прав пользователей в среде сервера терминалов, чтобы минимизировать их влияние на систему, по максимуму ограничить интерфейс и предоставить только необходимый набор прав;
- Рекомендуем настроить Firewall таким образом, чтобы ограничить доступ из внешней среды Internet к ферме серверов терминального доступа;
- Рекомендуем соблюдать политику конфиденциальности и требования к сложности паролей Microsoft.
- Лицензирование серверов терминалов в Облаке происходит штатно (точно так же, как и находящихся локально) — MS Server, MS RDS CAL, MS CAL;
- Рекомендуем уточнить у провайдера, который предоставляет в аренду данные виртуальные машины насчет аренды программного обеспечения по модели SPLA.
Технические инфраструктурные серверы
- Рекомендуется размещать на отдельных виртуальных машинах. Компания Microsoft не рекомендует совмещать эту роль ни с какой другой;
- Рекомендуется тщательно настроить и отладить групповые политики и перенаправление профилей. Для такого кол-ва пользователей системность и упорядоченность — залог стабильно работающей структуры;
- Мы рекомендуем использовать программное обеспечение Veeam Backup для создания архивов данных с должной глубиной и частотой выполнения. Поскольку часть виртуальных машин предполагается взять в аренду — то есть смысл уточнить у самого дата-центра, какие инструменты резервного копирования и обеспечения архива они предоставляют;
- Параллельно рекомендуем реализовать дублирующий инструмент резервного копирования, для подстраховки. К примеру, для СУБД — это скрипт SQL резервного копирования баз, для файловых данных — утилита, умеющая работать с теневым копированием. Для 100% гарантии наличия резервных копий — дублирующий инструмент должен складывать архив на дублирующий ресурс хранения резервных копий, в идеале — вне пределов дата-центра.
Пример архитектуры и ориентировочный бюджет
Давайте рассмотрим пример прототипа подобной структуры. По условиям, нам требуется организовать облачную структуру для 1000 пользователей системы 1С: Предприятие 8.3, конфигурацией ERP.Техническая реализация
- Ядро системы — сервер управления базами данных 1С будет располагаться на высокопроизводительной аппаратной платформе с процессорами Intel® Xeon® Gold и дисковой подсистемой SSD NVME;
- Дублирующий сервер СУБД также будет базироваться на отдельной аппаратной платформе. Кластеризация СУБД будет реализована по технологии репликации баз AlwaysON;
- Сервер 1С:Предприятие будет состоять из нескольких нод, расположенных на разных виртуальных машинах и соединенных в отказоустойчивый кластер. Виртуальные диски должны располагаться на дисковых массивах Enterprise SSD, т.к. серверы 1С под высокой нагрузкой активно используют cache, а на конфигурации ERP с таким количеством пользователей нагрузка будет реально высокая. Итак, закладываем не менее 3 нод для основных операций + отдельная нода для фоновых заданий и тяжелых отчетов;
- Для клиентской части рассмотрим два варианта:
- Использование web-интерфейса 1С. Этот вариант позволяет сэкономить на ресурсах и программном обеспечении для серверов терминалов, но требует адаптации интерфейсов системы 1С программистами и разработчиками кода;
- Полноценные серверы терминального доступа. Закладываем до 10 виртуальных машин под серверы терминального доступа, объединенные в ферму терминалов. Для каждой отводим не менее 96 ГБ ОЗУ и высокоскоростные диски.
- Арендуем две виртуальные машины для файловых серверов, на которых будет хранилище документов и профиля пользователей 1С;
- Берем две отдельные виртуальные машины для основного и резервного контроллеров домена;
- Закладываем еще две виртуальные машины для доступа к 1С извне:
- В варианте web-интерфейса 1С это будут серверы обработки web-трафика IIS или Apache;
- Во втором варианте — основной и резервный шлюза терминального доступа, по которому пользователя будут попадать в среду терминалов извне.
- На отдельные виртуальные машины установим также основной и резервный Broker-сервисы, которые регулируют распределение пользователей в ферме терминальных серверов для варианта 2;
- Предполагаем, что сервис мониторинга, резервного копирования и место под архивы мы арендуем у дата-центра, т.к. по нашим расчетам — это выгодно экономически.
Рисунок 2 — Схема структуры. Вариант 1 — web-серверы и web-интерфейс 1С
Рисунок 3 — Схема структуры. Вариант 2 — ферма терминальных серверов
Расчет аренды с примерным бюджетом
Аппаратная серверная часть
Вариант 1. Структура на основе web-интерфейса 1С
Bare-Metal Server
- 2 x Intel Xeon Gold 2.8 GHz, 8 cores;
- 256 GB DDR4;
- 2 x 960GB NVMe.
Virtual Machine
- 8 x vCPU 3,6 Ghz;
- 128 GB DDR4;
- 100 GB SSD.
Virtual Machine
- 4 x vCPU 2,6 Ghz;
- 4 GB DDR4;
- 50 GB SSD.
Virtual Machine
- 4 x vCPU 2,6 Ghz;
- 8 GB DDR4;
- 50 GB SSD.
- Система мониторинга;
- Система резервного копирования;
- Объем места под архивы 4 Тб.
Вариант 2. Структура на основе фермы терминальных серверов
Bare-Metal Server
- 2 x Intel Xeon Gold 2.8 GHz, 8 cores;
- 256 GB DDR4;
- 2 x 960GB NVMe.
Virtual Machine
- 8 x vCPU 3,6 Ghz;
- 128 GB DDR4;
- 100 GB SSD.
Virtual Machine
- 8 x vCPU 2,4 Ghz;
- 128 GB DDR4;
- 100 GB SSD.
Virtual Machine
- 4 x vCPU 2,6 Ghz;
- 4 GB DDR4;
- 50 GB SSD.
Virtual Machine
- 4 x vCPU 2,6 Ghz;
- 4 GB DDR4;
- 50 GB SSD.
Virtual Machine
- 4 x vCPU 2,6 Ghz;
- 4 GB DDR4;
- 50 GB SSD.
- Система мониторинга;
- Система резервного копирования;
- Объем места под архивы 4 Тб.
Любой расчет был бы неполноценным без сравнительной составляющей. Предлагаем примерно рассчитать — сколько бы обошлась подобная структура 1С при закупке в собственное владение. Примем за условие бюджетный вариант — пользователи будут работать с серверной структурой со своих ПК по сети и терминальный режим не требуется.
Вариант 3. Закупка в собственное владение
Программная часть — лицензии Microsoft и 1С
Как мы уже говорили в одном из разделов — гораздо выгоднее получить лицензии на программное обеспечение в аренду, переводя их в операционные затраты, чем получить капитальные затраты на солидную даже для крупного бизнеса сумму. Однако с арендой программного обеспечения Microsoft есть нюансы — напрямую его нельзя получить в субаренду. Либо хостинг предоставляет их в рамках аренды оборудования или Облака (PaaS) либо обслуживающая Вас организация по вопросам ИТ — является партнером Microsoft в программе SPLA и укажет данные серверные и виртуальные платформы в договоре на обслуживание ИТ. В нашем примере мы пойдем по второму сценарию — включение ежемесячной аренды лицензий Microsoft и серверной части 1С в договор по информационно-техническому обслуживанию (с небольшой наценкой, к примеру 10% от их себестоимости, для большей реалистичности расчета).Вариант 1. Структура на основе web-интерфейса 1С
Вариант 2. Структура на основе фермы терминальных серверов
Вариант 3. Закупка ПО в собственное владение
Итоговый примерный бюджет
Выводы статьи
- Экосистема относительно крупной ИТ-структуры (от 1000 пользователей 1С:ERP) имеет нетиповое строение и проблематику и не может руководствоваться типовыми правилами ИТ-архитектуры и безликими рекомендациями из Интернет.
- Облачные технологии позволяют решить 4 крупные проблемы с локальной серверной структурой:
- Обеспечение требуемого быстродействия, регулируемого юридическими соглашениями;
- Предоставление высокого уровня стабильности и отказоустойчивости;
- Надежную защиту от киберугроз;
- Быстрое масштабирование и экономию бюджета за счет перевода капитальных затрат в операционные.
При проектировании облачной структуры требуется тщательная информационная подготовка — 50% успеха закладывается еще на бумаге.
Рекомендации:
- Рекомендуется пользоваться выгодами мультиоблачной концепции, чтобы брать от каждого провайдера его преимущества и перекрывать недостатки. Также это прекрасно диверсифицирует риски форс-мажорных ситуаций;
- Сердце системы — серверы баз данных рекомендуется оставлять на мощных аппаратных платформах, а остальные сервисы можно расположить в виртуальной среде;
- Рекомендуется разделять серверы 1С по функциям, снижая общую нагрузку на систему;
- Рекомендуется не экономить на резервировании и дублировании ключевых ролей, иначе бизнес может потерять несоизмеримо больше ресурсов;
- Все ресурсы и услуги, которые можно взять в аренду — лучше арендовать.