> Что делать первым шагом внутри сервиса создания виртуальной машины (Go)

Короткий ответ

Первым шагом в сервисе создания виртуальной машины должна быть валидация входных данных: проверка формата запроса, обязательных полей, допустимых значений (CPU, RAM, disk) и прав доступа пользователя. Это защищает систему от некорректных запросов и позволяет вернуть понятную ошибку до начала дорогостоящих операций. Валидация выполняется до обращения к внешним API или создания ресурсов, так как это дешевле и безопаснее, чем откатывать частично созданную VM.

Подробное объяснение

Валидация - это первый защитный барьер. Она включает:

• Синтаксическую проверку: корректность JSON/протобуфа, типы полей.
• Семантическую проверку: допустимые диапазоны (например, CPU от 1 до 64, RAM от 512MB до 256GB), наличие обязательных полей (имя, образ, сеть).
• Проверку прав: пользователь имеет роль, позволяющую создавать VM в указанном проекте/регионе.
• Проверку бизнес-ограничений: лимиты квот, доступность образа, существование сети.

Порядок важен: сначала дешёвые проверки (формат, типы), затем более дорогие (квоты, доступность внешних ресурсов). Это позволяет отсечь большинство ошибок без обращения к инфраструктуре.

Если валидация проходит, следующий шаг - создание записи в БД со статусом pending и постановка задачи в очередь (например, через message broker). Это обеспечивает идемпотентность и возможность восстановления после сбоев.

На практике

В Go-сервисе валидация обычно реализуется:

• через структуры с тегами validate (библиотека go-playground/validator);
• через отдельный слой middleware для проверки JWT и ролей;
• через сервисный слой, где проверяются бизнес-правила.

Пример типичного потока:

1. HTTP handler принимает запрос.
2. Middleware проверяет аутентификацию.
3. Handler вызывает метод Validate() на DTO.
4. Если ошибка - возвращается 400 Bad Request с деталями.
5. Если ок - сервис проверяет квоты и доступность ресурсов.
6. Только после этого создаётся сущность VM в БД и отправляется событие в очередь.

Пример кода

GO
type CreateVMRequest struct {
    Name      string `json:"name" validate:"required,min=3,max=64"`
    CPU       int    `json:"cpu" validate:"required,min=1,max=64"`
    RAMMB     int    `json:"ram_mb" validate:"required,min=512,max=262144"`
    ImageID   string `json:"image_id" validate:"required,uuid"`
    NetworkID string `json:"network_id" validate:"required,uuid"`
}

func (s *VMService) Create(ctx context.Context, req CreateVMRequest, user User) (*VM, error) {
    // 1. Базовая валидация формата
    if err := s.validator.Struct(req); err != nil {
        return nil, ErrInvalidRequest{err}
    }

    // 2. Проверка прав
    if !s.auth.CanCreateVM(user, req.NetworkID) {
        return nil, ErrForbidden
    }

    // 3. Проверка квот
    if err := s.quota.Check(user, req.CPU, req.RAMMB); err != nil {
        return nil, ErrQuotaExceeded
    }

    // 4. Проверка доступности образа
    if !s.imageStore.Exists(ctx, req.ImageID) {
        return nil, ErrImageNotFound
    }

    // 5. Создание записи и постановка в очередь
    vm := &VM{ID: uuid.New(), Status: StatusPending, ...}
    if err := s.db.Create(ctx, vm); err != nil {
        return nil, err
    }
    s.queue.Publish(ctx, "vm.create", vm.ID)
    return vm, nil
}

Как отвечать на собеседовании

Начните с короткого ответа: "валидация входных данных". Затем раскройте иерархию проверок: от формата до бизнес-правил. Подчеркните, что это делается до создания ресурсов, чтобы избежать частичных состояний. Упомяните идемпотентность и статус pending как следующий шаг. Если спросят про распределённые системы - добавьте про очередь и компенсационные транзакции. Не углубляйтесь в детали реализации, пока не попросят.

Что проверяет интервьюер

• Понимание важности валидации как первого шага.
• Умение выстраивать порядок проверок по стоимости и критичности.
• Знание, как обрабатывать ошибки на каждом этапе.
• Понимание жизненного цикла создания VM (pending → provisioning → running).
• Способность видеть риски: гонки, дублирование запросов, частичные сбои.

Типичные ошибки

• Сразу создавать VM в БД или вызывать гипервизор без проверок.
• Валидировать только формат, игнорируя права и квоты.
• Возвращать общие ошибки без деталей (плохо для клиентов).
• Не учитывать идемпотентность: повторный запрос создаёт дубликат.
• Проверять доступность внешних ресурсов до базовой валидации (лишние сетевые вызовы).