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

Что проверяют

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

Как отвечать

Первый шаг это валидация и авторизация запроса, затем запись задачи, и только потом работа с гипервизором. Порядок такой:

1. Проверить вход: параметры (образ, диск, сеть), права вызывающего и квоту проекта. Отказ должен случаться до любых побочных эффектов.
2. Обеспечить идемпотентность: ключ запроса от клиента, повторный вызов с тем же ключом возвращает ту же машину, а не создаёт вторую. Сеть теряет ответы регулярно, и клиент повторит.
3. Зафиксировать намерение: запись со статусом «создаётся» и выданным идентификатором, ответ клиенту сразу, работа асинхронно. Создание идёт минуты и в синхронный ответ не влезает.
4. Дальше вызывать гипервизор, обновляя статус по шагам: диск, сеть, запуск. Внешние идентификаторы сохранять по мере получения.
5. Продумать отмену и уборку. Процесс перезапустится посреди создания, и по записи должно быть понятно, что доделать, а что удалить, чтобы не остались оплачиваемые ресурсы без владельца.

В Go это context с дедлайном на каждый внешний вызов, отдельный воркер поверх очереди задач и безопасная повторная обработка.

Где спотыкаются

Начинают с выбора технологии виртуализации и сборки образов. Спрашивают не об этом: вопрос про первый шаг обработки запроса внутри сервиса, а не про подбор стека.

Делают создание синхронным прямо в обработчике HTTP. Клиент отваливается по таймауту, повторяет запрос, и машины плодятся дублями.

Забывают про квоты и идемпотентность. Без них один нетерпеливый клиент выбирает ресурсы всего проекта, а разгребать зависшие машины приходится руками.