В данном разделе приведены ориентировочные ежемесячные затраты на инфраструктуру Yandex Cloud для двух сценариев развёртывания DST App на 15 000 пользователей. Расчёты базируются на публичных тарифах платформы и конфигурациях, обоснованных в разделе [6. Сайзинг оборудования для 15,000 клиентов].
Данный сценарий предполагает пиковые нагрузки и максимальную отказоустойчивость всех компонентов.
| Компонент | Конфигурация (одна нода) | Количество | Ориентировочная стоимость единицы, ₽/мес | Итого, ₽/мес |
|---|---|---|---|---|
| Серверы приложений | 16 vCPU, 64 ГБ RAM, 100 ГБ NVMe | 6 | 30 000 | 180 000 |
| Кластер PostgreSQL | 64 vCPU, 256 ГБ RAM, 1 ТБ NVMe | 3 | 110 000 | 330 000 |
| Кластер Redis | 8 vCPU, 32 ГБ RAM | 6 | 16 000 | 96 000 |
| Балансировщики нагрузки | 8 vCPU, 16 ГБ RAM | 2 | 9 000 | 18 000 |
| Объектное хранилище (S3) | 15 ТБ (Standard Storage) | – | 30 000 | 30 000 |
| Мониторинг | 4 vCPU, 8 ГБ RAM | 2 | 4 500 | 9 000 |
| ИТОГО | ≈ 663 000 |
Оптимизированная конфигурация для запуска и постепенного роста нагрузки.
| Компонент | Конфигурация (одна нода) | Количество | Ориентировочная стоимость единицы, ₽/мес | Итого, ₽/мес |
|---|---|---|---|---|
| Серверы приложений | 8 vCPU, 32 ГБ RAM, 100 ГБ SSD | 4 | 14 000 | 56 000 |
| Кластер PostgreSQL | 32 vCPU, 128 ГБ RAM, 500 ГБ NVMe | 3 | 60 000 | 180 000 |
| Кластер Redis (Sentinel) | 4 vCPU, 16 ГБ RAM | 3 | 8 000 | 24 000 |
| Балансировщики нагрузки | 4 vCPU, 8 ГБ RAM | 2 | 4 500 | 9 000 |
| Объектное хранилище (S3) | 8 ТБ (Standard Storage) | – | 16 000 | 16 000 |
| Мониторинг | 2 vCPU, 4 ГБ RAM | 1 | 2 300 | 2 300 |
| ИТОГО | ≈ 287 300 |
- Цены: Указаны по состоянию на март 2026 года для региона
ru-central1(Москва). Все суммы округлены. - Тип ВМ: Для серверов приложений, балансировщиков и мониторинга рассмотрены стандартные виртуальные машины на платформе Intel Ice Lake.
- Управляемые сервисы: Для PostgreSQL и Redis использованы тарифы Managed Service for PostgreSQL и Managed Service for Redis. Стоимость включает лицензию, автоматическое резервное копирование и базовый мониторинг.
- Хранилище: Расчёт для Object Storage исходит из класса Standard Storage. Не включает плату за сетевой трафик и операции.
- Сеть: Затраты на входящий/исходящий трафик и использование Network Load Balancer (при необходимости) в оценку не включены и могут составлять дополнительно 5–15% от общей суммы в зависимости от объёма передаваемых данных.
Для снижения эксплуатационных расходов без ущерба для производительности рекомендуются следующие меры:
- Применение прерываемых ВМ: Для части серверов приложений (например, 2 из 4) возможно использование прерываемых виртуальных машин со скидкой до 60–80%. Это допустимо, так как отказоустойчивость прикладного уровня обеспечивается балансировщиком и автоматическим переподключением клиентов.
- Использование резервных инстансов (CVoS): Для управляемых кластеров PostgreSQL и Redis, работающих в режиме 24/7, целесообразно приобрести обязательства на 1 или 3 года (Committed Volume of Services). Это позволяет зафиксировать скидку в размере 30–40% от стоимости потребляемых ресурсов.
- Настройка автоматического масштабирования: Внедрение политик горизонтального автомасштабирования (например, на базе Kubernetes HPA или метрик Yandex Monitoring) позволит динамически изменять количество серверов приложений в зависимости от фактической нагрузки, сокращая потребление ресурсов в периоды низкой активности (ночные часы, выходные дни).
- Управление жизненным циклом файлов: Настройка политик очистки вложений (
FileSettings.FileCleanupDays) и перемещения редко используемых файлов в холодное хранилище (Object Storage Cold) позволит сократить затраты на объектное хранилище.
В процессе планирования бюджета у заказчиков может возникнуть закономерный вопрос о существенной разнице в стоимости инфраструктуры между коммуникационной платформой DST App и типовыми веб-приложениями с сопоставимой аудиторией (например, корпоративным порталом или маркетплейсом). Ниже представлен анализ факторов, формирующих данное различие.
Разница в затратах обусловлена фундаментальными различиями в архитектуре, характере нагрузки и требованиях к отказоустойчивости.
| Параметр сравнения | Типовое веб-приложение (маркетплейс) | Коммуникационная платформа DST App | Влияние на инфраструктурные затраты |
|---|---|---|---|
| Модель взаимодействия | Короткие сессии, преимущественно чтение данных. HTTP-запросы. | Постоянные соединения (WebSocket), интенсивный обмен сообщениями в реальном времени. | WebSocket требует значительно больше ресурсов CPU и RAM на одного активного пользователя. |
| Нагрузка на БД | Редкие транзакции записи (оформление заказа). Основная нагрузка — чтение, эффективно кэшируемое. | Высокая частота записей (сообщения, статусы, реакции). Требуется высокая производительность дисковой подсистемы (NVMe). | Необходимость в более мощных и дорогих инстансах баз данных с обязательной репликацией для масштабирования чтения. |
| Кэширование и сессии | Сессии могут храниться в быстрой БД или на клиенте (JWT). | Распределённое кэширование обязательно (Redis Cluster) для синхронизации состояния каналов, сессий и пользователей между всеми серверами приложений. | Добавление отдельного высокопроизводительного кластера Redis (до 6 нод в сценарии высокой нагрузки). |
| Хранение контента | Статический контент (изображения товаров), отдаваемый через CDN. | Динамический пользовательский контент (вложения, аватары) с требованиями к версионированию и репликации. | Использование отказоустойчивого S3-совместимого хранилища с георепликацией вместо простого файлового сервера. |
| Отказоустойчивость | Допустим простой на время восстановления из резервной копии (RTO ~ 1–4 часа). | Высокая доступность (High Availability) является критическим требованием. Ожидаемый RTO — минуты, RPO — секунды. | Необходимость дублирования (минимум 2 ноды) всех критических компонентов: балансировщиков, БД, Redis. |
| Сетевые требования | Достаточно канала 100–500 Мбит/с. | Требуется канал 1.5–2 Гбит/с для пикового трафика и выделенная высокоскоростная сеть (10 Гбит/с) между серверами для минимизации задержек БД и кэша. | Более высокие тарифы на сетевую инфраструктуру и каналы связи. |
Таким образом, разница в стоимости между инфраструктурой для маркетплейса (~75 000 ₽/мес) и DST App (~287 000 – 663 000 ₽/мес) является не следствием неэффективности архитектуры последнего, а объективным отражением принципиально иного класса задач, решаемых системой. Коммуникационная платформа уровня предприятия требует выделенных ресурсов для обеспечения мгновенной доставки сообщений, синхронизации состояния тысяч одновременных сессий и гарантированной доступности сервиса в режиме 24/7.
Для контроля затрат на начальном этапе и в процессе эксплуатации рекомендуется:
- Начать со Сценария B: Конфигурация для средней активности является экономически обоснованной стартовой точкой. Её стоимость в 3.8 раза превышает стоимость маркетплейса, что соответствует описанным выше архитектурным различиям, но при этом позволяет избежать избыточного резервирования на старте.
- Внедрить культуру FinOps: Регулярно анализировать утилизацию ресурсов с помощью встроенных инструментов Yandex Cloud и профилировать нагрузку для выявления возможностей дальнейшей оптимизации.
- Провести нагрузочное тестирование: Фактические потребности конкретной организации могут отличаться от усреднённых расчётов. Проведение нагрузочного тестирования на этапе пилотного внедрения позволит точно определить необходимую конфигурацию и избежать переплаты за избыточные ресурсы.
Приведённые в предыдущих разделах конфигурации и расчёты представляют собой целевое состояние инфраструктуры для 15 000 пользователей. Однако путь к этому состоянию должен быть тщательно спланирован с самого начала, чтобы избежать дорогостоящей и рискованной миграции архитектуры в будущем. В данном разделе обобщены ключевые архитектурные принципы, полученные в ходе практических внедрений DST App.
Проблема: Часто встречается подход, при котором внедрение начинается с монолитной установки (один сервер, локальная БД, файлы на диске) с последующей миграцией на масштабируемую архитектуру. Такой переход сопряжён со значительными операционными рисками и простоями.
Рекомендация: Даже при старте с небольшим числом пользователей (например, 1000 человек) необходимо сразу закладывать многослойную архитектуру, включающую:
- Слой балансировки нагрузки (Nginx / HAProxy / ALB);
- Слой серверов приложений (минимум 2 ноды для отказоустойчивости);
- Слой базы данных (мастер + реплика, управляемый сервис или Patroni);
- Слой файлового хранилища (S3-совместимое, а не локальная файловая система).
Это позволяет:
- Избежать болезненной миграции данных и конфигурации в будущем;
- Сразу заложить фундамент для горизонтального масштабирования;
- Обеспечить высокую доступность на ранних этапах, когда доверие пользователей только формируется.
DST App поддерживает интеграцию с внешними серверами видеоконференций (Jitsi, BigBlueButton). При планировании нагрузки на 15 000 пользователей важно учитывать, что видеозвонки создают принципиально иную нагрузку, нежели текстовый чат:
- WebRTC-трафик требует высокой пропускной способности (до 2 Мбит/с на участника) и низкой задержки;
- Геораспределённые звонки создают дополнительные сложности: необходимо либо размещать Jitsi-серверы в каждом регионе, либо использовать каскадное соединение (Jitsi Videobridge) с соответствующими затратами на сеть;
- Горизонтальное масштабирование звонков достигается добавлением дополнительных Jitsi Videobridge нод, которые могут быть развёрнуты отдельно от серверов DST App.
Рекомендация:
- Выделить отдельный слой видеоконференций со своим пулом серверов и сетевыми политиками;
- Для географически распределённых команд рассмотреть размещение Jitsi-серверов в каждом регионе присутствия;
- При планировании пропускной способности каналов учитывать пиковую нагрузку от одновременных звонков.
При объёме сообщений, генерируемых 15 000 активными пользователями, встроенный полнотекстовый поиск PostgreSQL со временем может стать узким местом. В таких случаях DST App поддерживает интеграцию с внешними поисковыми движками:
- Elasticsearch / OpenSearch — для высокопроизводительного полнотекстового поиска по сообщениям и файлам.
Архитектурное решение: поисковый движок следует рассматривать как отдельный слой, который может быть добавлен на более поздних этапах эксплуатации. Благодаря изначальной многослойной архитектуре, интеграция Elasticsearch происходит без перестройки всей системы и без простоя.
Рекомендация:
- На старте заложить возможность подключения внешнего поискового кластера (через соответствующие параметры в
config.json); - Мониторить производительность поиска по мере роста объёма данных и при необходимости развернуть выделенный кластер Elasticsearch/OpenSearch.
Как было отмечено в разделе [2. Географически распределённая инсталляция], построение активной-активной архитектуры между удалёнными ЦОДами сопряжено с серьёзными техническими вызовами:
- Задержки WebSocket-соединений становятся заметны пользователям уже при пинге > 50 мс;
- Репликация базы данных между регионами с высокой задержкой приводит либо к риску потери данных (асинхронная), либо к деградации производительности записи (синхронная);
- Для видеозвонков географическое распределение требует дополнительного инженерного решения (каскад Jitsi или выделенные серверы в каждом регионе).
Рекомендация:
- Начинать с архитектуры активный-пассивный ЦОД с асинхронной репликацией и отработанным планом аварийного переключения (DRP);
- Переход к активной-активной схеме рассматривать только при подтверждённой бизнес-потребности и наличии инженерной экспертизы;
- Для улучшения пользовательского опыта в разных регионах использовать CDN для статических ресурсов и, возможно, географическую маршрутизацию на уровне DNS (Geo-DNS) для направления пользователей к ближайшему серверу приложений (даже при единой базе данных).
С учётом вышеизложенного, рекомендуемая стратегия развития инфраструктуры DST App выглядит следующим образом:
| Этап | Пользователей | Конфигурация | Ключевые изменения |
|---|---|---|---|
| Старт | до 5 000 | Сценарий B (средняя активность) | Закладывается многослойная архитектура: балансировщик, 2+ app-сервера, БД мастер+реплика, S3-хранилище. |
| Рост | 5 000 – 15 000 | Плавное масштабирование в рамках Сценария B → A | Увеличение числа app-серверов, добавление реплик БД, переход на Redis Cluster. |
| Зрелость | 15 000+ | Сценарий A + дополнительные слои | Добавление поискового кластера, выделение слоя видеозвонков, возможно — элементы геораспределения. |
Управление стоимостью эксплуатации является одной из ключевых компетенций при построении масштабируемых корпоративных сервисов. Опыт внедрения крупных веб-проектов (социальных сетей, маркетплейсов, контентных платформ) показывает, что при грамотном инженерном подходе возможно многократное снижение затрат на инфраструктуру без ущерба для пользовательского опыта. В данном разделе обобщены принципы и конкретные технические приёмы, позволяющие достичь экономической эффективности при развёртывании DST App и аналогичных коммуникационных платформ.
Анализ успешных кейсов оптимизации (например, снижение ежемесячных расходов с 90 000 ₽ до 35 000 ₽ при пиковой нагрузке свыше 300 000+ пользователей, в социальной сети "Рутвит" и других крупных проектах) позволяет выделить три фундаментальные стратегии:
- Агрессивное многоуровневое кэширование — минимизация вычислительной нагрузки на серверы приложений и базу данных.
- Вынос статического и медийного контента на CDN — разгрузка каналов связи и снижение платы за исходящий трафик.
- Применение экономичных моделей потребления облачных ресурсов — использование прерываемых инстансов, резервных обязательств и автоматического масштабирования.
Прямое копирование методов, успешно применённых для контент-ориентированных платформ, требует адаптации с учётом специфики коммуникационного сервиса реального времени.
| Метод оптимизации | Применимость к DST App | Технические ограничения |
|---|---|---|
| Полностраничное кэширование | Частично применимо. Статические ресурсы (JavaScript-бандлы, CSS, шрифты, аватары, эмодзи) могут кэшироваться агрессивно. Однако лента сообщений и состояние каналов являются динамическими и уникальными для каждой пользовательской сессии. | Кэширование публичных каналов для неавторизованных посетителей возможно; для авторизованных пользователей требует аккуратной инвалидации. |
| Отдача статики через CDN | Полностью применимо и настоятельно рекомендуется. Интеграция DST App с объектным хранилищем (S3) позволяет настроить CDN-фасад для всех пользовательских вложений и аватаров. | Требуется корректная настройка CORS-заголовков и политик управления кэшем (Cache-Control) на уровне S3 и CDN. |
| Минималистичный бэкенд | Ограниченно применимо. DST App реализован на языке Go, что обеспечивает высокую производительность «из коробки». Основные узкие места связаны не с накладными расходами фреймворка, а с бизнес-логикой: поддержанием тысяч WebSocket-соединений и высокочастотной записью в базу данных. | Оптимизация достигается за счёт тонкой настройки PostgreSQL, пулов соединений, индексов и партиционирования, а не замены технологического стека. |
| Использование прерываемых ВМ | Применимо для stateless-компонентов. Серверы приложений DST App не хранят состояние, поэтому часть пула может быть развёрнута на прерываемых виртуальных машинах. | Необходимо обеспечить минимальное количество «гарантированных» нод для сохранения отказоустойчивости во время остановки прерываемых инстансов. |
Последовательное применение описанных ниже мер позволяет сократить ежемесячные затраты на инфраструктуру DST App на 25–40% относительно базового сценария, сохранив при этом корпоративные требования к доступности и производительности.
Цель: Снижение нагрузки на серверы приложений и минимизация платы за исходящий интернет-трафик.
Техническая реализация:
- Настройка публичного бакета в Yandex Object Storage для хранения пользовательских файлов.
- Активация CDN-ресурса (Yandex Cloud CDN или стороннего провайдера, например, Cloudflare) с origin на Object Storage.
- Конфигурация долгосрочного кэширования: заголовок
Cache-Control: public, max-age=31536000, immutableдля неизменяемых ресурсов (аватары, вложения). - Включение сжатия Brotli или Gzip на уровне CDN для текстовых ответов API и статических ассетов.
Ожидаемый результат: Сокращение исходящего трафика с серверов приложений на 60–80%, снижение общей стоимости сетевых услуг на 20–40%.
Цель: Приведение количества активных серверов приложений в соответствие с фактической нагрузкой.
Техническая реализация:
- Автомасштабирование по расписанию: Настройка правил в Yandex Cloud (или Kubernetes CronHPA) для уменьшения числа реплик серверов приложений в периоды гарантированного спада активности (ночные часы, выходные дни). Например, поддержание 2 реплик в нерабочее время и 4–6 реплик в пиковые часы.
- Использование прерываемых виртуальных машин: Размещение 30–50% пула серверов приложений на прерываемых инстансах Yandex Compute Cloud со скидкой до 80%. Балансировщик нагрузки автоматически исключает остановленную ВМ из маршрутизации; клиенты DST App переподключаются к оставшимся нодам.
Ожидаемый результат: Снижение расходов на вычислительные ресурсы (vCPU/RAM) для серверов приложений на 30–50%.
Цель: Снижение требований к производительности базы данных и уменьшение объёма потребляемой памяти Redis.
Техническая реализация:
- Кэширование в Redis: Активация кэширования часто запрашиваемых сущностей (профили пользователей, метаданные каналов) для снижения нагрузки на PostgreSQL. Это позволяет использовать менее ресурсоёмкие инстансы управляемой БД.
- Партиционирование таблиц PostgreSQL: Для таблицы
Posts(сообщения) рекомендуется настроить декларативное партиционирование по диапазону дат. Данная мера кратно ускоряет операции вставки и выборки, отодвигая необходимость вертикального масштабирования БД. - Применение резервных обязательств (CVoS): Для управляемых сервисов PostgreSQL и Redis, работающих в режиме 24/7, приобретение обязательств на 1 год обеспечивает фиксированную скидку в размере 20–30% от стоимости потребляемых ресурсов.
Ожидаемый результат: Возможность эксплуатации Сценария B (средняя активность) для 15 000 пользователей на протяжении более длительного времени, отсрочка перехода к более дорогому Сценарию A.
Цель: Сокращение затрат на хранение редко запрашиваемых файлов.
Техническая реализация:
- Настройка политик жизненного цикла в Yandex Object Storage для автоматического перемещения объектов из класса
Standardв классCold(илиIce) по истечении заданного периода (например, 30 дней). - Настройка автоматической очистки вложений в DST App (
FileSettings.EnableFileCleanupиFileSettings.FileCleanupDays) для удаления неиспользуемых файлов.
Ожидаемый результат: Снижение стоимости хранения данных на 60–70% для «холодной» части файлового архива.
Применение полного комплекса описанных мер к базовому Сценарию B (средняя активность, ~287 300 ₽/мес) позволяет достичь следующего уровня затрат.
| Статья расхода | Сценарий B (базовый) | Сценарий B (оптимизированный) | Метод оптимизации |
|---|---|---|---|
| Серверы приложений | 56 000 ₽ | 28 000 ₽ | Комбинация постоянных и прерываемых ВМ + масштабирование по расписанию |
| Кластер PostgreSQL | 180 000 ₽ | 140 000 ₽ | Годовое обязательство (CVoS), скидка ~22% |
| Кластер Redis | 24 000 ₽ | 16 000 ₽ | Годовое обязательство (CVoS) + оптимизация потребления памяти |
| Балансировщики нагрузки | 9 000 ₽ | 9 000 ₽ | — |
| Объектное хранилище (S3) | 16 000 ₽ | 8 000 ₽ | Перемещение 70% данных в Cold Storage + политики очистки |
| Сетевой трафик (исходящий) | 10 000 ₽* | 5 000 ₽ | CDN + сжатие |
| ИТОГО (округлённо) | ~295 000 ₽ | ~206 000 ₽ | Снижение на 30% |
* В базовом расчёте Сценария B стоимость исходящего трафика не детализировалась; здесь она добавлена для полноты сравнения.
Важно отметить, что достижение стоимости эксплуатации на уровне 35 000 – 75 000 ₽/мес для 15 000 активных пользователей DST App в публичном облаке при соблюдении корпоративных требований к отказоустойчивости и производительности не представляется возможным. Нижняя граница стоимости одного только управляемого кластера PostgreSQL с репликацией и гарантированной производительностью (NVMe-диски, 32 vCPU) составляет ориентировочно 50 000 – 60 000 ₽/мес — это объективная цена обеспечения целостности и доступности данных.
Приведённые в разделе методы позволяют приблизиться к экономически эффективному минимуму, исключив неоправданное резервирование и оплату неиспользуемых ресурсов. Дальнейшее снижение затрат потребует либо компромиссов в надёжности (например, отказ от репликации БД в пользу регулярных резервных копий), либо переноса части инфраструктуры на собственное оборудование в дата-центре (colocation), где удельная стоимость ресурсов ниже, но возрастают операционные расходы на администрирование и поддержку.
Таким образом, описанный подход представляет собой эталонную инженерную практику управления стоимостью владения высоконагруженными системами и может служить руководством для организаций, стремящихся к рациональному использованию облачных бюджетов.
При ограниченном бюджете или на этапе пилотного внедрения возможен ряд осознанных упрощений архитектуры, позволяющих дополнительно снизить ежемесячные расходы. Каждое такое упрощение представляет собой компромисс между стоимостью и отказоустойчивостью, и должно приниматься с полным пониманием сопутствующих рисков.
| Компонент | Базовая конфигурация (Сценарий B) | Экономичная конфигурация | Снижение стоимости | Сопутствующие риски и ограничения |
|---|---|---|---|---|
| Кластер PostgreSQL | 3 ноды (1 мастер + 2 реплики) | 2 ноды (1 мастер + 1 синхронная реплика) | ~33% | Снижение отказоустойчивости: при одновременном выходе из строя мастера и единственной реплики возможна потеря данных. Рекомендуется усилить резервное копирование (ежечасные WAL-архивы). |
| Серверы приложений | 4 ноды | 3 ноды | ~25% | Уменьшение запаса по пиковой нагрузке. При резком всплеске активности возможна деградация времени отклика. Компенсируется оперативным добавлением нод вручную или автоматически. |
| Балансировщики нагрузки | 2 ноды (активный-активный) | 1 нода | ~50% | Отсутствие резервирования на уровне балансировки. Выход из строя единственной ноды приведёт к полной недоступности сервиса до её восстановления. Восстановление обычно занимает 5–15 минут. |
| Кластер Redis | 3 ноды Sentinel (1 мастер + 2 реплики) | 2 ноды Sentinel (1 мастер + 1 реплика) или уменьшение RAM | ~33% | Аналогично PostgreSQL: потеря отказоустойчивости кэша. При отказе мастера возможна кратковременная потеря сессий до переключения на реплику. |
| Объектное хранилище S3 | Резервирование объёма | Оплата по факту потребления | Переменная | Отсутствие гарантированной квоты. Yandex Cloud по умолчанию устанавливает лимит в 2 ТБ на бакет; при необходимости увеличения требуется обращение в техническую поддержку. |
| Мониторинг | Отдельная ВМ | Совмещение с одной из App-нод | ~100% | Увеличение нагрузки на сервер приложений. При отказе этой ноды мониторинг становится недоступным одновременно с частью сервиса. |
-
Регламент оперативного расширения: Заранее подготовить и задокументировать процедуру добавления ресурсов (увеличение числа реплик БД, добавление серверов приложений). В идеале — автоматизировать её через Infrastructure as Code (Terraform, Ansible). Это позволит при росте нагрузки или инциденте быстро вернуться к целевой отказоустойчивой архитектуре.
-
Усиленное резервное копирование: При снижении числа реплик БД критически важно настроить частое резервное копирование с хранением WAL-логов (например, каждые 15–30 минут) и регулярно тестировать процедуру восстановления.
-
Мониторинг доступности балансировщика: При использовании одной ноды балансировщика настроить внешний мониторинг (например, с помощью стороннего сервиса) и алертинг о его недоступности для минимизации времени реакции.
-
Планирование перехода к целевой архитектуре: Экономичная конфигурация должна рассматриваться как временное решение на период пилотного внедрения или первых месяцев эксплуатации. По мере роста нагрузки и критичности сервиса необходимо предусмотреть бюджет и план перехода к полноценной отказоустойчивой схеме (Сценарий B или A).
Применение всех перечисленных компромиссов к базовому Сценарию B (~287 300 ₽/мес) позволяет снизить ежемесячные расходы до уровня ~180 000 – 200 000 ₽. Это достижимо без потери ключевого функционала DST App, но с пониманием и принятием описанных выше рисков. Такой подход оправдан для старта и валидации гипотез, однако для долгосрочной эксплуатации в корпоративной среде рекомендуется возврат к полной конфигурации, описанной в разделе [6. Сайзинг оборудования для 15,000 клиентов].
DST Global (ООО «ДСТ Глобал», до 2020 года — ООО «Дженерал Офис Технолоджис») — российская, передовая компания-разработчик программного обеспечения, основанная в 2008 году и аккредитованная в Министерстве цифрового развития, связи и массовых коммуникаций Российской Федерации.
| Параметр | Значение |
|---|---|
| Полное наименование | Общество с ограниченной ответственностью «ДСТ Глобал» (ООО «ДСТ Глобал») |
| Год основания | 2008 |
| Адрес | г. Ижевск, ул. Воткинское шоссе, 170Е. Региональный оператор Сколково. Технопарк Нобель |
| Телефон | +7 922 5019164 |
| Аккредитация | ИТ-аккредитация в Минцифры России |
| Портфолио | Свыше 500 реализованных проектов |
| Опыт на рынке | Более 18 лет |
| Официальный сайт | https://dstglobal.ru |
| Официальный репозиторий | github.com/DSTGlobal |
| Центр поддержки | dstglobal.ru/support |
| Почта | info@dstglobal.ru |