Опубликовано: 03.10.2026 | Источник: SecurityLab (RSS)

SaaSpocalypse в дипломе: обоснование перехода с SaaS на собственную платформу

В марте 2026 года на SecurityLab вышла заметка про «SaaSpocalypse» — ситуацию, когда корпоративные клиенты перестают продлевать дорогие SaaS-подписки и вместо этого собирают внутренние аналоги своими силами, всё чаще с помощью LLM-генерации кода. Datadog и другие облачные вендоры видят в этом прямую угрозу своей бизнес-модели: если заказчик может сгенерировать сервис мониторинга или трекинга задач за пару недель, то годовая подписка на миллионы рублей становится спорным решением.

Почему это важно для выпускника ИТ-специальности? Потому что защита ВКР всё чаще строится вокруг выбора: купить готовое облачное решение или спроектировать своё. И если раньше «делаем свой аналог» звучало как учебное упражнение, то теперь это экономически обоснованный инженерный выбор, который можно подтвердить расчётами TCO, метриками SLO и требованиями к контуру данных. Ниже — как превратить этот тренд в защищаемую работу, а не в абстрактный реферат.

Три темы ВКР, которые вырастают прямо из статьи

Тема 1. Методика оценки «build vs buy» для корпоративных сервисов с учётом LLM-генерации кода

Актуальность: статья прямо описывает мотив отказа от SaaS — стоимость подписки против стоимости собственной разработки. Вендоры боятся, что разрыв сократился, и это поддаётся измерению.

Цель: разработать методику сравнения SaaS и self-hosted решения для сервиса класса «внутренний инструмент» с учётом ускоренной разработки через LLM.

• проанализировать структуру TCO SaaS-подписки (лицензии, места, объём телеметрии, поддержка);
• построить модель стоимости собственного контура (разработка, инфраструктура, эксплуатация, сопровождение);
• учесть риски: vendor lock-in, требования к хранению данных, деградация качества сгенерированного кода;
• апробировать методику на конкретном сервисе и сравнить результат по NPV за 3 года.

Структура: Глава 1 — анализ рынка SaaS и предпосылок SaaSpocalypse; Глава 2 — проектирование методики и модели расчёта; Глава 3 — расчёт на кейсе, проверка чувствительности, экономическое обоснование.

Тема 2. Проектирование self-hosted платформы наблюдаемости на OpenTelemetry и Kubernetes

Актуальность: Datadog — эталонный SaaS в области observability. Замена такого сервиса своим контуром — самый наглядный пример тренда, описанного в статье.

Цель: спроектировать и развернуть платформу сбора метрик, логов и трассировок, сопоставимую по функциональности с коммерческим аналогом.

• обосновать выбор стека (коллектор OpenTelemetry, хранилище временных рядов, визуализация);
• разработать схему развёртывания в Kubernetes с разделением на namespace и политиками ресурсов;
• настроить пайплайн CI/CD для конфигураций и дашбордов;
• провести нагрузочное тестирование и оценить стоимость владения против подписки.

Структура: Глава 1 — теория наблюдаемости и обзор SaaS-аналогов; Глава 2 — архитектура и развёртывание; Глава 3 — тестирование, метрики, экономика внедрения.

Тема 3. Автоматизация миграции с SaaS на собственный контур

Актуальность: сам факт ухода клиентов от подписок порождает отдельную инженерную задачу — перенос данных, интеграций и регламентов без простоя.

Цель: разработать алгоритм и инструментарий поэтапной миграции с минимизацией RTO/RPO.

• классифицировать данные по критичности и определить стратегию переноса для каждого класса;
• спроектировать слой совместимости API (шлюз-адаптер) для периода параллельной работы;
• реализовать план отката и проверку целостности;
• оценить трудозатраты и риски по методике ISO/IEC 25010.

Структура: Глава 1 — анализ подходов к миграции; Глава 2 — проектирование алгоритма и адаптера; Глава 3 — эксперимент, метрики простоя, экономический эффект.

Аналитическая глава: как обосновать стек, а не перечислить технологии

Самая частая слабость первого раздела — список инструментов без критериев. Комиссия читает его как пересказ документации. Работает другая логика: сначала критерии, потом взвешивание, потом вывод. Критерии удобно привязать к ISO/IEC 25010 — функциональная полнота, производительность, сопровождаемость, защищённость, переносимость.

Отдельно стоит разобрать в главе терминологическую ловушку: SaaS, PaaS и IaaS часто смешивают. Если вы пишете про замену подписки собственным контуром в Kubernetes — это уже не SaaS, а self-hosted PaaS поверх IaaS. Зафиксируйте это в глоссарии и ссылайтесь на него по тексту: снимает половину вопросов на защите.

Проектная часть: что показать на схемах

Проектный раздел выигрывает, если в нём видна декомпозиция, а не одна общая картинка «всё связано со всем». Минимальный набор диаграмм по ГОСТ 19.701-90:

• контекстная диаграмма — границы системы и внешние потребители телеметрии;
• диаграмма компонентов — коллектор, буфер, хранилище, слой визуализации, шлюз API;
• диаграмма последовательности — путь одного запроса от агента до дашборда;
• схема развёртывания — узлы Kubernetes, persistent volumes, сетевые политики.

Если в проекте используется генерация кода через LLM (а это прямая отсылка к статье), обязательно опишите контроль качества: статический анализ, ревью, покрытие тестами. Иначе на защите спросят: «А почему сгенерированный код вообще можно пускать в прод?» — и это будет неприятный вопрос.

# Пример фрагмента конфигурации коллектора OpenTelemetry
receivers:
  otlp:
    protocols:
      grpc:
      http:
processors:
  batch:
    timeout: 5s
exporters:
  prometheus:
    endpoint: "0.0.0.0:8889"
service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheus]

Тестирование и метрики: цифры вместо обещаний

Раздел с расчётами отличает работу, которую защищают, от работы, которую пересказывают. Что стоит измерить:

Для нагрузочного тестирования не нужен продакшен: достаточно сгенерировать синтетический поток метрик и постепенно наращивать интенсивность до отказа. Ключевое — зафиксировать точку, в которой система перестаёт укладываться в SLO, и объяснить, почему. Это ровно та причина, по которой компании вообще считают, что «своё выйдет дороже» — и вы эту причину либо подтверждаете, либо опровергаете расчётом.

Чему вы научитесь на такой работе

• Строить аргументацию выбора архитектуры на критериях, а не на вкусовщине.
• Считать TCO и NPV для ИТ-решения — навык, который прямо продаётся на рынке.
• Оформлять техническую документацию по ГОСТ 34.602-89 и ГОСТ 19.701-90.
• Работать с OpenTelemetry, Kubernetes, CI/CD-пайплайнами в реальном, а не учебном режиме.
• Защищать инженерное решение перед комиссией: тезис — критерий — измерение — вывод.

Вопросы, которые задают чаще всего

Обязательно ли писать код для такой ВКР?

Не всегда, но сильно желательно. Если тема — методика оценки, достаточно расчётной модели и её апробации на данных. Если тема про платформу наблюдаемости, наличие работающего прототипа и результатов нагрузочного теста поднимает оценку заметно.

Где брать исходные данные для расчётов и тестов?

Для экономического блока — публичные прайсы вендоров, отчёты об отраслевых затратах на ИТ, внутренние данные организации по согласованию. Для нагрузочного теста — синтетический генератор потока метрик; так вы не зависите от закрытых данных.

Как оформлять UML- и архитектурные диаграммы?

По ГОСТ 19.701-90 для схем алгоритмов и программ, по ГОСТ 34.602-89 для структуры ТЗ. UML допустим, но снабдите диаграммы условными обозначениями и ссылками из текста — иначе они выглядят как вставленные картинки.

Насколько сложно реализовать прототип на OpenTelemetry и Kubernetes?

Базовый контур разворачивается за один-два вечера на локальном кластере. Основное время уходит не на установку, а на настройку конвейеров обработки, хранение и описание архитектуры. Именно эта часть и составляет ценность диплома.

Источник: Что такое SaaSpocalypse и почему облачные гиганты боятся, что клиенты начнут писать код сами? (опубликовано 2026-03-26)