Привет, я Сергей, DevOps-инженер в KTS. Перейду сразу к делу.

К отказу отдельной виртуалки вы наверняка готовы. Но не все готовы к другому классу аварии: к потере площадки, на которой находятся почти все ВМ проекта.

Именно с такой ситуацией столкнулся один из наших заказчиков после серии атак на дата-центры Яндекса в октябре 2026 года. Компания сообщила, что дата-центр в Сасово был серьезно поврежден и полностью остановлен, часть инфраструктуры площадки в Калуге вышла из строя, а позднее остановилась работа дата-центра во Владимире.

Авария затронула инфраструктуру Yandex Cloud, где работали сервисы нашего заказчика. Восстановить работу системы на прежней площадке в тот момент было невозможно, а очередь за новыми ресурсами обрабатывалась несколько дней.

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

Мы прошли долгий путь от пересылки ТЗ в Word по электронной почте до автоматической генерации документации нейросетями прямо из Merge Request разработчика. Зачастую это происходит вообще без участия аналитика вплоть до этапа итогового ревью. Но делает ли автоматизация нашу документацию лучше?

В этой статье я хочу оглянуться на эволюцию того, как мы вели проектную документацию, обсудить одну неочевидную проблему работы с ИИ, о которой мало кто задумывается, и показать, как с этим бороться. А в конце я поделюсь полезными материалами — примером репозитория документации для двух подходов (классический водопад с элементами канбана и чистый скрам) с готовым ИИ‑скиллом для анализа изменений в коде.