Опубликовано: 17.09.2026 | Источник: TechCrunch

Облачная инфраструктура стартапа в ВКР: от seed-раунда до защищаемых метрик

24 марта 2026 года Accel и Prosus объявили первый индийский набор программы ATOMS: шесть стартапов из более чем 2 000 заявок получили от $500 000 до $2 млн каждый. Для выпускника ИТ-специальности это не новость про венчур, а готовый каркас для дипломной работы. Почему? Потому что 2 000 заявок и шесть победителей — это задача отбора, а чек на полмиллиона долларов — это задача построения инфраструктуры под давлением сроков, ограниченного бюджета и требований инвесторов к метрикам. Ровно то, что проверяется на защите ВКР: умеете ли вы обосновать архитектурный выбор, посчитать стоимость владения и показать работающий прототип, а не просто пересказать три статьи из интернета.

Основная часть: три темы ВКР, которые вырастают из этого кейса

Кейс Accel/Prosus удобен тем, что задаёт чёткие ограничения: маленькая команда, короткий runway, высокие ожидания по надёжности и прозрачности расходов. Ниже — три темы, которые реально защитить. Каждая разложена по главам по ГОСТ 34 и привязана к измеримым метрикам.

Структура любой из трёх работ выглядит одинаково предсказуемо для нормоконтроля: Глава 1 — анализ предметной области, обзор существующих решений и постановка задачи; Глава 2 — проектирование (диаграммы, спецификации, описание стека); Глава 3 — реализация, эксперименты и оценка эффективности. Разница только в том, чем наполнена глава 3: нагрузочными графиками, финансовой моделью или графиками burn rate error budget.

Как встроить кейс в Главу 1: анализ без воды

Не пересказывайте новость. Возьмите из неё только фактуру: конкурс 2 000/6, диапазон инвестиций, отраслевую неопределённость. Дальше стройте анализ по ISO/IEC 25010 — какие характеристики качества критичны для продукта, выходящего на рынок в первые 90 дней. Обычно это производительность, надёжность и сопровождаемость. Зафиксируйте их как требования — потом именно по ним будете сравнивать решения в Главе 3, и это снимет вопрос комиссии «а почему вы выбрали Kubernetes, а не serverless?».

Как встроить кейс в Главу 2: проектирование и диаграммы

Минимальный набор графики, который ждут на защите: C4-диаграмма контейнерного уровня, диаграмма последовательности UML для критичного сценария (например, развёртывание новой версии) и BPMN-схема процесса оптимизации затрат. Вот как может выглядеть контейнерный уровень словами:

[Клиент] --> [Ingress / API Gateway]
                  |
        +---------+---------+
        |                   |
   [Сервис A]          [Сервис B]
        |                   |
   [PostgreSQL]        [Очередь + Worker]
        |                   |
        +------[OpenTelemetry Collector]------> [Prometheus / Grafana / Tempo]
                          |
                    [Модуль FinOps: снимки биллинга]

Инфраструктуру описывайте кодом, а не скриншотами панели. Преподаватель оценит воспроизводимость. Пример фрагмента описания автомасштабирования и целевого SLO:

resource "kubernetes_horizontal_pod_autoscaler_v2" "api" {
  metadata {
    name      = "api-hpa"
    namespace = "prod"
  }
  spec {
    min_replicas = 2
    max_replicas = 20
    scale_target_ref {
      kind = "Deployment"
      name = "api"
    }
    metric {
      type = "Resource"
      resource {
        name = "cpu"
        target { type = "Utilization" average_utilization = 65 }
      }
    }
  }
}

# slo.yaml — декларация целевого уровня сервиса
slos:
  - name: api-availability
    target: 99.9        # %
    window: 30d
    error_budget_burn_rate: 2.0

Обратите внимание: декларативный подход (Terraform + YAML) сам по себе становится аргументом в главе «Эффективность» — его можно сравнить с ручным развёртыванием и показать экономию времени инженера.

Как встроить кейс в Главу 3: метрики, а не ощущения

Именно здесь большинство работ сыпется. «Я настроил Grafana» — это не результат. Результат — таблица «до/после» по метрикам поддомена: время холодного деплоя, p95 задержки, стоимость обработки одной транзакции, процент выполненных SLO за окно 30 дней, динамика облачных расходов. Сравнивайте не абстрактные «стало быстрее», а конкретные значения с указанием методики измерения и нагрузки. Если делаете FinOps-тему, обязательно приложите unit-economics: стоимость обслуживания одного активного пользователя в месяц при разной конфигурации инстансов.

Чему вы научитесь, пока будете делать такую работу

• Проектировать отказоустойчивые схемы развёртывания и обосновывать уровень резервирования под бюджет.
• Описывать инфраструктуру как код и связывать её с CI/CD-пайплайном.
• Определять SLI/SLO и считать error budget — навык, который прямо спрашивают на собеседованиях в продуктовые команды.
• Строить модель TCO и юнит-экономики инфраструктуры вместо «примерной прикидки».
• Оформлять архитектурные решения по ГОСТ 34 и оценивать качество по ISO/IEC 25010.

FAQ: вопросы, которые задают перед защитой

Источник: Accel, Prosus pick six ‘off-the-map’ startups for inaugural India cohort (опубликовано 2026-03-24)