Автоматизация, мониторинг, развертывание, безопасность инфраструктуры – все это ежедневная реальность DevOps-инженера. Промпты для DevOps-инженера, собранные в этой статье, помогут делегировать нейросети рутинные и сложные задачи: от написания конфигурационных файлов до разбора инцидентов.
Здесь нет абстрактных советов «используйте ИИ эффективнее». Только 27 готовых запросов под конкретные ситуации – с объяснением, почему каждый из них устроен именно так.
Статья будет полезна, если перед вами стоят задачи вроде:
- Написать или проверить конфигурацию для систем оркестрации контейнеров
- Разобраться в причинах инцидента и составить отчет
- Автоматизировать рутину через сценарии и конвейеры
- Подготовить документацию по инфраструктуре
- Провести аудит безопасности конфигураций
- Оптимизировать процессы непрерывной интеграции и доставки
Каждый промпт можно скопировать, подставить свои данные и получить рабочий результат. Без магии, только структура.
27 промптов для DevOps-инженера: готовые запросы для реальных задач
1. Написание конфигурации для оркестрации контейнеров
Проблема: Написать корректный конфигурационный файл для развертывания приложения с нуля – задача, где одна опечатка стоит часа отладки. Особенно когда нужно учесть лимиты ресурсов, переменные окружения и политики перезапуска.
Решение: Промпт генерирует готовый конфигурационный файл для развертывания контейнера с учетом заданных параметров и типичных требований производственной среды.
Текст промпта:
*****
Ты – [укажите роль, например, «опытный DevOps-инженер с опытом работы с Kubernetes от 5 лет»]. Создай конфигурационный файл для развертывания приложения в кластере оркестрации контейнеров.
Контекст: приложение – [опишите приложение, например, «веб-сервис на Node.js, обслуживающий REST API»]. Среда: [укажите среду, например, «производственная среда с требованием высокой доступности»]. Используемая система оркестрации: [укажите систему, например, «Kubernetes версии 1.28»].
Требования к конфигурации:
– Количество реплик: [укажите, например, «3»]
– Лимиты CPU и памяти: [укажите, например, «CPU: 500m/1000m, память: 256Mi/512Mi»]
– Переменные окружения: [перечислите, например, «NODE_ENV=production, PORT=3000, DB_HOST из секрета»]
– Политика перезапуска: [укажите, например, «Always»]
– Проверки готовности и работоспособности: включи readinessProbe и livenessProbe с разумными параметрами для данного типа приложения
Формат ответа: готовый YAML-файл с подробными комментариями к каждому блоку. После файла – короткий абзац с объяснением ключевых решений.
Ограничения: не используй устаревшие версии API, избегай привилегированного режима контейнера без явной необходимости, не включай секреты в открытом виде.
*****
Почему это работает: Явное указание версии системы оркестрации и конкретных числовых параметров исключает универсальные шаблоны – нейросеть генерирует конфигурацию под реальные ограничения, а блок комментариев делает файл понятным для команды.
2. Анализ и оптимизация конвейера непрерывной интеграции
Проблема: Конвейер сборки работает медленно или нестабильно, но непонятно, где именно теряется время и что именно вызывает сбои. Смотреть на логи вручную – занятие медитативное, но малопродуктивное.
Решение: Промпт анализирует текущую конфигурацию конвейера, выявляет узкие места и предлагает конкретные улучшения с объяснением причин.
Текст промпта:
*****
Ты – [укажите роль, например, «DevOps-инженер, специализирующийся на оптимизации процессов непрерывной интеграции и доставки»]. Проанализируй конфигурацию конвейера и предложи улучшения.
Контекст: используемая платформа – [укажите, например, «GitLab CI/CD»]. Текущее время выполнения полного конвейера: [укажите, например, «18 минут»]. Целевое время: [укажите, например, «не более 8 минут»].
Текущая конфигурация конвейера:
[вставьте текущий конфигурационный файл или опишите этапы, например, «этап 1: установка зависимостей – 4 мин, этап 2: запуск тестов – 9 мин, этап 3: сборка образа – 3 мин, этап 4: публикация – 2 мин»]
Известные проблемы: [опишите, например, «тесты иногда падают без видимой причины, кэш зависимостей не всегда применяется»]
Проведи анализ по следующей структуре:
- Выявленные узкие места с объяснением причин
- Конкретные изменения конфигурации с примерами кода
- Оценка ожидаемого эффекта от каждого изменения
Ограничения: предлагай только изменения, совместимые с указанной платформой; не предлагай переход на другую платформу как решение.
*****
Почему это работает: Указание текущего и целевого времени задает измеримый критерий успеха, а структурированный формат ответа с оценкой эффекта превращает общие советы в конкретный план действий.
3. Составление плана реагирования на инцидент
Проблема: Инцидент случился, сервис лежит, все смотрят на дежурного инженера – а четкого плана действий нет, и каждый раз все начинается заново с чистого листа и нервного листания документации.
Решение: Промпт создает структурированный план реагирования на конкретный тип инцидента с распределением ролей и временными ориентирами.
Текст промпта:
*****
Ты – [укажите роль, например, «старший инженер по надежности сервисов с опытом управления крупными инцидентами»]. Составь план реагирования на инцидент.
Описание инцидента: [опишите ситуацию, например, «база данных PostgreSQL перестала принимать новые подключения, ошибка ‘too many connections’, сервис деградирует»]. Уровень критичности: [укажите, например, «P1 – полная недоступность основного сервиса»]. Размер команды дежурных: [укажите, например, «3 человека»].
Стек технологий: [перечислите, например, «PostgreSQL 15, PgBouncer, Kubernetes, Grafana для мониторинга»].
Составь план по структуре:
- Немедленные действия первых 5 минут (стабилизация)
- Диагностика: конкретные команды и метрики для проверки
- Возможные причины в порядке вероятности
- Варианты устранения для каждой причины
- Коммуникация: что и когда сообщать заинтересованным сторонам
- Критерии восстановления сервиса
Тон: четкий, без лишних слов, пригодный для использования в момент стресса. Формат: нумерованные шаги с конкретными командами там, где это применимо.
*****
Почему это работает: Разбивка на временные фазы и требование конкретных команд превращает абстрактный план в операционную инструкцию, которую можно выполнять механически даже в состоянии высокого стресса.
4. Написание сценария автоматизации резервного копирования
Проблема: Резервное копирование делается вручную или работает по сценарию, написанному «временно» три года назад – без проверки целостности, уведомлений об ошибках и ротации старых копий.
Решение: Промпт генерирует полноценный сценарий резервного копирования с обработкой ошибок, проверкой целостности и системой уведомлений.
Текст промпта:
*****
Ты – [укажите роль, например, «DevOps-инженер, специализирующийся на автоматизации и надежности инфраструктуры»]. Напиши производственный сценарий автоматизации резервного копирования.
Контекст:
– Что резервируем: [опишите, например, «база данных PostgreSQL 15, объем около 50 ГБ»]
– Куда сохраняем: [укажите, например, «объектное хранилище Яндекс Cloud S3»]
– Расписание: [укажите, например, «ежедневно в 02:00 по московскому времени»]
– Срок хранения: [укажите, например, «ежедневные копии – 7 дней, еженедельные – 4 недели»]
– Язык сценария: [укажите, например, «Bash»]
Обязательные требования:
– Проверка успешности создания резервной копии
– Проверка целостности загруженного файла через контрольную сумму
– Автоматическое удаление устаревших копий согласно политике хранения
– Уведомление о результате: [укажите канал, например, «отправка сообщения в Telegram через бот»]
– Подробное журналирование с временными метками
Ограничения: сценарий должен корректно обрабатывать ошибки на каждом этапе и завершаться с ненулевым кодом при сбое. Избегай хранения учетных данных в теле сценария – используй переменные окружения.
*****
Почему это работает: Явное требование обработки ошибок и ненулевого кода завершения при сбое гарантирует, что сценарий будет корректно интегрироваться с системами мониторинга и планировщиком задач, а не молча «успешно» завершаться при реальном сбое.
5. Аудит безопасности конфигурации инфраструктуры
Проблема: Конфигурация развертывалась итерационно, и где-то в процессе появились небезопасные настройки – открытые порты, избыточные права доступа, отсутствие шифрования. Найти все это вручную – значит потратить день и все равно что-то пропустить.
Решение: Промпт проводит структурированный аудит безопасности конфигурации с приоритизацией проблем и конкретными рекомендациями по исправлению.
Текст промпта:
*****
Ты – [укажите роль, например, «инженер по безопасности инфраструктуры с опытом проведения технических аудитов»]. Проведи аудит безопасности предоставленной конфигурации.
Конфигурация для проверки:
[вставьте конфигурационный файл или описание инфраструктуры, например, «конфигурация Terraform для VPC в Яндекс Cloud с группами безопасности и настройками доступа»]
Контекст: [опишите среду, например, «производственная среда, обрабатывающая персональные данные пользователей, требования 152-ФЗ»]
Проверь по следующим категориям:
- Сетевой доступ: открытые порты, избыточные правила групп безопасности
- Управление доступом: принцип минимальных привилегий, сервисные учетные записи
- Шифрование: данные в покое и при передаче
- Журналирование и аудит: полнота логирования критических событий
- Управление секретами: наличие секретов в конфигурации в открытом виде
Формат ответа: для каждой найденной проблемы – уровень критичности (критический / высокий / средний / низкий), описание риска, конкретный пример исправления. В конце – сводная таблица с количеством проблем по уровням.
*****
Почему это работает: Разбивка по категориям безопасности и требование уровня критичности для каждой проблемы позволяет сразу получить приоритизированный список действий, а не равномерный поток замечаний, из которого непонятно, за что браться первым.
6. Создание политики управления ресурсами кластера
Проблема: Один неправильно настроенный под съедает ресурсы всего узла, остальные сервисы начинают деградировать, и найти виновника можно только постфактум – когда пользователи уже написали в поддержку.
Решение: Промпт разрабатывает политику управления ресурсами с квотами, лимитами и правилами приоритизации под конкретную структуру кластера.
Текст промпта:
*****
Ты – [укажите роль, например, «платформенный инженер с глубокой экспертизой в управлении ресурсами Kubernetes»]. Разработай политику управления ресурсами кластера.
Описание кластера:
– Количество узлов: [укажите, например, «10 рабочих узлов по 16 CPU и 64 ГБ RAM каждый»]
– Типы нагрузок: [перечислите, например, «продуктовые сервисы (критические), фоновые задачи (некритические), инструменты разработки (низкий приоритет)»]
– Текущие проблемы: [опишите, например, «фоновые задачи периодически занимают все ресурсы узла, вытесняя продуктовые сервисы»]
Разработай:
- Структуру пространств имен с обоснованием
- Конфигурации ResourceQuota для каждого типа нагрузки
- Конфигурации LimitRange с разумными значениями по умолчанию
- Классы приоритетов подов (PriorityClass) с объяснением логики
- Рекомендации по мониторингу использования ресурсов
Формат: готовые YAML-манифесты с комментариями + пояснительный текст с обоснованием каждого решения. Ограничения: все значения должны быть реалистичными для указанного размера кластера, не предлагай теоретически идеальные, но практически неудобные схемы.
*****
Почему это работает: Описание реальной проблемы (фоновые задачи вытесняют продуктовые) направляет нейросеть на решение конкретной боли, а не на генерацию академически правильной, но оторванной от жизни архитектуры.
7. Разработка стратегии мониторинга и оповещения
Проблема: Мониторинг либо молчит, когда все плохо, либо шлет уведомления каждые пять минут по поводу метрик, которые никого не волнуют – и в итоге команда начинает игнорировать все оповещения, включая важные.
Решение: Промпт создает продуманную стратегию мониторинга с правилами оповещения, разделенными по уровням критичности и каналам доставки.
Текст промпта:
*****
Ты – [укажите роль, например, «инженер по надежности сервисов с опытом построения систем мониторинга для высоконагруженных приложений»]. Разработай стратегию мониторинга и оповещения.
Описание системы:
– Приложение: [опишите, например, «микросервисная архитектура из 12 сервисов, обрабатывающая платежные транзакции»]
– Инфраструктура: [укажите, например, «Kubernetes в Яндекс Cloud, база данных PostgreSQL, очередь сообщений Kafka»]
– Инструменты мониторинга: [укажите, например, «Prometheus, Grafana, Alertmanager»]
– Текущие проблемы с оповещениями: [опишите, например, «слишком много ложных срабатываний, команда игнорирует уведомления»]
Разработай:
- Ключевые метрики для каждого уровня (инфраструктура, приложение, бизнес)
- Правила оповещения с конкретными порогами и условиями для каждого уровня критичности
- Маршрутизацию оповещений по каналам (что идет в Telegram, что будит ночью)
- Правила подавления ложных срабатываний
- Готовые конфигурации правил для Alertmanager
Ограничения: оповещения должны быть действенными – каждое оповещение должно требовать конкретного действия. Избегай метрик, на которые невозможно повлиять оперативно.
*****
Почему это работает: Принцип «каждое оповещение требует конкретного действия» встроен в ограничения, что заставляет нейросеть генерировать правила, соответствующие лучшим практикам управления инцидентами, а не просто технически корректные пороговые значения.
8. Написание документации по архитектуре инфраструктуры
Проблема: Документация по инфраструктуре либо отсутствует, либо написана в стиле «и так понятно» – что не понятно никому, включая автора, вернувшегося к ней через полгода.
Решение: Промпт создает структурированную архитектурную документацию на основе описания инфраструктуры, пригодную для передачи знаний внутри команды.
Текст промпта:
*****
Ты – [укажите роль, например, «технический писатель с экспертизой в DevOps и облачных архитектурах»]. Напиши архитектурную документацию по инфраструктуре.
Описание инфраструктуры:
[опишите инфраструктуру, например, «три среды (разработка, тестирование, производство), кластер Kubernetes в Яндекс Cloud, база данных PostgreSQL с репликой для чтения, Redis для кэширования сессий, Nginx как балансировщик нагрузки, хранилище объектов для статики»]
Аудитория документации: [укажите, например, «новые DevOps-инженеры команды и разработчики, которым нужно понимать инфраструктуру»]
Структура документации:
- Обзор архитектуры: назначение, ключевые принципы
- Описание компонентов: роль каждого элемента и его связи
- Схема взаимодействия компонентов (текстовое описание для последующего создания диаграммы)
- Среды и их различия
- Ключевые операционные процедуры: развертывание, откат, масштабирование
- Известные ограничения и технический долг
Требования к стилю: технически точно, без воды, с конкретными именами компонентов. Там, где уместно – примеры команд. Ограничения: не делай предположений о том, что не описано – задавай уточняющие вопросы в конце, если информации недостаточно.
*****
Почему это работает: Указание целевой аудитории (новые инженеры vs. опытные разработчики) кардинально меняет уровень детализации и стиль документа – нейросеть адаптирует объяснения под реального читателя, а не пишет в вакуум.
9. Оптимизация образа контейнера
Проблема: Образ контейнера весит полтора гигабайта, собирается восемь минут и содержит инструменты разработки, которые в производственной среде нужны примерно никогда – зато создают отличную поверхность атаки.
Решение: Промпт анализирует текущий файл сборки контейнера и предлагает оптимизированную версию с объяснением каждого изменения.
Текст промпта:
*****
Ты – [укажите роль, например, «DevOps-инженер, специализирующийся на оптимизации контейнеров и безопасности образов»]. Оптимизируй файл сборки контейнера.
Текущий файл сборки:
[вставьте текущий Dockerfile или его описание, например, «используется образ ubuntu:latest, устанавливается Node.js через apt, копируются все файлы проекта включая node_modules, запускается npm start»]
Параметры приложения:
– Технология: [укажите, например, «Node.js 20, приложение Express»]
– Текущий размер образа: [укажите, например, «1.4 ГБ»]
– Время сборки: [укажите, например, «8 минут»]
– Целевые показатели: [укажите, например, «размер менее 200 МБ, время сборки менее 3 минут»]
Проведи оптимизацию по направлениям:
- Выбор базового образа
- Многоэтапная сборка
- Оптимизация кэширования слоев
- Минимизация поверхности атаки
- Запуск от непривилегированного пользователя
Формат: сначала анализ проблем текущего файла, затем оптимизированная версия с подробными комментариями, затем – ожидаемые результаты по каждому показателю.
*****
Почему это работает: Указание конкретных целевых показателей (размер, время сборки) создает измеримые критерии, по которым можно оценить результат, а разбивка по направлениям оптимизации гарантирует комплексный подход.
10. Проектирование стратегии управления секретами
Проблема: Пароли и токены хранятся в переменных окружения, которые прописаны прямо в конфигурационных файлах репозитория – или, еще лучше, в истории коммитов, откуда их не убрать без хирургического вмешательства.
Решение: Промпт проектирует комплексную стратегию управления секретами с учетом конкретного стека технологий и требований безопасности.
Текст промпта:
*****
Ты – [укажите роль, например, «инженер по безопасности инфраструктуры с опытом внедрения систем управления секретами»]. Спроектируй стратегию управления секретами для указанной среды.
Контекст:
– Инфраструктура: [опишите, например, «Kubernetes-кластер, несколько микросервисов, конвейер GitLab CI/CD»]
– Типы секретов: [перечислите, например, «пароли баз данных, API-ключи внешних сервисов, TLS-сертификаты, токены сервисных учетных записей»]
– Текущее состояние: [опишите, например, «секреты хранятся как переменные окружения в конфигурации Kubernetes, часть захардкожена в конфигурационных файлах»]
– Требования: [укажите, например, «ротация секретов без перезапуска сервисов, аудит доступа к секретам, разграничение по средам»]
Разработай стратегию, включающую:
- Выбор и обоснование инструментов для российской инфраструктуры
- Схему организации и именования секретов
- Процесс ротации с минимальным временем недоступности
- Интеграцию с конвейером и Kubernetes
- Аудит и журналирование доступа
- План миграции от текущего состояния
Ограничения: предлагай решения, работающие без зависимости от недоступных западных облачных сервисов.
*****
Почему это работает: Ограничение на западные облачные сервисы направляет нейросеть к решениям, реально применимым в российской инфраструктуре – Vault, встроенные механизмы Kubernetes, отечественные хранилища – вместо стандартного списка из AWS Secrets Manager и HashiCorp Cloud.
11. Разработка процедуры аварийного восстановления
Проблема: Процедура аварийного восстановления существует в виде намерения написать ее когда-нибудь – или в виде документа, который никто не проверял и который наверняка устарел еще в момент написания.
Решение: Промпт создает практическую процедуру аварийного восстановления с конкретными шагами, проверками и целевыми показателями восстановления.
Текст промпта:
*****
Ты – [укажите роль, например, «инженер по надежности с опытом разработки и тестирования процедур аварийного восстановления»]. Разработай процедуру аварийного восстановления для указанной системы.
Описание системы:
– Компоненты: [перечислите, например, «кластер Kubernetes из 5 узлов, база данных PostgreSQL с ежедневными резервными копиями в Яндекс Cloud S3, Redis, балансировщик нагрузки»]
– Целевое время восстановления: [укажите, например, «не более 2 часов»]
– Целевая точка восстановления: [укажите, например, «потеря данных не более чем за 1 час»]
– Сценарии сбоев: [перечислите, например, «отказ одного узла, отказ всего кластера, потеря базы данных, компрометация среды»]
Разработай для каждого сценария:
- Признаки обнаружения инцидента
- Пошаговую процедуру восстановления с конкретными командами
- Проверки успешности восстановления
- Ожидаемое время каждого этапа
Дополнительно: разработай план тестирования процедуры (учения по аварийному восстановлению) и чек-лист для проверки готовности к восстановлению.
Ограничения: все команды должны быть конкретными и выполнимыми, избегай шагов типа «восстановите систему» без детализации.
*****
Почему это работает: Требование конкретных команд для каждого шага и ожидаемого времени этапов превращает документ из декларации намерений в реально используемую инструкцию, которую можно проверить на практике.
12. Настройка политики сетевой безопасности кластера
Проблема: По умолчанию в Kubernetes все поды могут общаться со всеми подами – что удобно для разработки и катастрофично для безопасности производственной среды, где компрометация одного сервиса не должна автоматически открывать доступ ко всем остальным.
Решение: Промпт разрабатывает набор сетевых политик для изоляции компонентов с учетом реальных потребностей в коммуникации между сервисами.
Текст промпта:
*****
Ты – [укажите роль, например, «инженер по сетевой безопасности с экспертизой в Kubernetes NetworkPolicy»]. Разработай сетевые политики для изоляции компонентов кластера.
Описание архитектуры:
[опишите компоненты и их взаимодействие, например, «три пространства имен: frontend (Nginx, React), backend (API на Go, 3 сервиса), data (PostgreSQL, Redis). Frontend должен обращаться только к API-шлюзу backend. Сервисы backend общаются между собой и с data. Прямой доступ frontend к data запрещен.»]
Внешний трафик: [опишите, например, «входящий трафик только через Ingress-контроллер в пространстве имен ingress-nginx»]
Разработай:
- Базовую политику запрета всего трафика по умолчанию
- Политики для каждого пространства имен с разрешением только необходимых взаимодействий
- Политику для системных компонентов (мониторинг, DNS)
- Процедуру проверки корректности примененных политик
Формат: готовые YAML-манифесты с подробными комментариями. После каждой политики – краткое объяснение логики. В конце – схема разрешенных взаимодействий в текстовом виде.
Ограничения: политики должны быть минималистичными – разрешать ровно столько, сколько нужно, не больше.
*****
Почему это работает: Детальное описание архитектуры и требуемых взаимодействий позволяет нейросети генерировать точные политики, а не шаблонные примеры – результат сразу применим к конкретной инфраструктуре.
13. Создание шаблона для анализа первопричин инцидента
Проблема: После инцидента нужно написать разбор, но каждый раз это выглядит по-разному, фокусируется на разных аспектах и в итоге не позволяет накапливать системные знания о повторяющихся проблемах.
Решение: Промпт создает структурированный анализ конкретного инцидента по методологии поиска первопричин с выводами и системными улучшениями.
Текст промпта:
*****
Ты – [укажите роль, например, «старший инженер по надежности, ведущий разбор производственного инцидента»]. Проведи анализ первопричин инцидента и составь структурированный отчет.
Данные об инциденте:
– Описание: [опишите, что произошло, например, «API-сервис был недоступен 47 минут, ошибки 503 для 100% запросов»]
– Временная шкала: [перечислите события с временными метками, например, «14:23 – первые ошибки в мониторинге, 14:31 – получено оповещение, 14:45 – обнаружена причина, 15:10 – восстановление»]
– Затронутые системы: [укажите, например, «API-шлюз, мобильное приложение, интеграции с партнерами»]
– Предварительная причина: [опишите, например, «исчерпание пула соединений с базой данных после деплоя новой версии»]
Проведи анализ:
- Восстановление полной хронологии событий
- Применение метода «5 почему» для поиска первопричины
- Выявление факторов, усиливших инцидент
- Оценка эффективности обнаружения и реагирования
- Конкретные системные улучшения с ответственными и сроками
Тон отчета: без обвинений, фокус на системных проблемах, а не на ошибках людей. Формат: профессиональный документ, пригодный для обмена с руководством и командой.
*****
Почему это работает: Явное указание тона «без обвинений» направляет нейросеть к культуре психологической безопасности, которая является основой эффективного разбора инцидентов – без нее люди скрывают информацию, и первопричины так и не находятся.
14. Разработка стратегии управления конфигурацией через код
Проблема: Инфраструктура создавалась вручную через веб-консоль, никто точно не знает, что именно настроено и почему – а воспроизвести среду с нуля означает потратить неделю на восстановление по памяти и логам.
Решение: Промпт разрабатывает стратегию перевода инфраструктуры под управление кодом с планом миграции и структурой репозитория.
Текст промпта:
*****
Ты – [укажите роль, например, «платформенный инженер с опытом внедрения подхода управления инфраструктурой через код в крупных организациях»]. Разработай стратегию перевода инфраструктуры под управление кодом.
Текущее состояние:
– Инфраструктура: [опишите, например, «50+ виртуальных машин в Яндекс Cloud, созданных вручную, несколько Kubernetes-кластеров, базы данных»]
– Текущий подход: [опишите, например, «ручное создание через веб-консоль, некоторые серверы настроены вручную без документации»]
– Команда: [укажите, например, «5 DevOps-инженеров, опыт работы с Terraform есть у двоих»]
– Инструменты: [укажите предпочтительные инструменты, например, «Terraform для инфраструктуры, Ansible для конфигурации серверов»]
Разработай:
- Структуру репозитория для кода инфраструктуры
- Стандарты именования и организации ресурсов
- Стратегию управления состоянием Terraform
- Рабочий процесс для внесения изменений (ветки, проверки, применение)
- Поэтапный план миграции существующей инфраструктуры
- Процесс обучения команды
Ограничения: план миграции должен предусматривать нулевое время простоя для производственных систем. Учитывай реальный уровень навыков команды.
*****
Почему это работает: Указание реального уровня навыков команды предотвращает генерацию идеального, но нереализуемого плана – нейросеть адаптирует подход к тому, что команда реально способна внедрить.
15. Написание правил проверки кода инфраструктуры
Проблема: Код инфраструктуры проверяется по тем же критериям, что и код приложений – или не проверяется вообще, потому что непонятно, на что смотреть. В результате в производство уходят конфигурации с очевидными проблемами безопасности и надежности.
Решение: Промпт создает конкретные правила проверки кода инфраструктуры с чек-листом для проверяющего и автоматическими проверками для конвейера.
Текст промпта:
*****
Ты – [укажите роль, например, «старший DevOps-инженер, устанавливающий стандарты качества для кода инфраструктуры»]. Разработай правила проверки кода инфраструктуры.
Контекст:
– Используемые инструменты: [перечислите, например, «Terraform, Helm-чарты, Kubernetes YAML-манифесты, Ansible-роли»]
– Текущий процесс: [опишите, например, «проверка кода есть, но нет четкого понимания что именно проверять для кода инфраструктуры»]
– Размер команды: [укажите, например, «8 человек, смешанный опыт»]
Разработай:
- Чек-лист проверки для каждого типа артефакта (Terraform, Helm, Kubernetes-манифесты)
- Категории проверок: безопасность, надежность, удобство сопровождения, производительность
- Автоматические проверки для конвейера (конкретные инструменты и команды)
- Критерии блокировки (что обязательно должно быть исправлено) vs. рекомендации
- Шаблон комментария для типичных проблем
Формат: практичный документ для ежедневного использования. Ограничения: правила должны быть конкретными и однозначными – «безопасный код» не подходит, «отсутствие секретов в открытом виде» – подходит.
*****
Почему это работает: Требование конкретности в формулировках правил устраняет главную проблему расплывчатых стандартов – когда каждый проверяющий интерпретирует их по-своему и в итоге проверка зависит от настроения, а не от критериев.
16. Проектирование архитектуры журналирования
Проблема: Логи есть везде, но найти нужное событие занимает полчаса ручного поиска по нескольким системам – потому что форматы разные, нет единой точки сбора, и вопрос «что происходило с этим запросом» требует детективных навыков.
Решение: Промпт проектирует централизованную архитектуру журналирования с едиными стандартами формата и эффективным поиском.
Текст промпта:
*****
Ты – [укажите роль, например, «архитектор наблюдаемости с опытом построения систем журналирования для распределенных приложений»]. Спроектируй архитектуру централизованного журналирования.
Описание среды:
– Источники логов: [перечислите, например, «15 микросервисов в Kubernetes, системные компоненты кластера, база данных, балансировщик нагрузки, конвейер»]
– Объем: [укажите, например, «ориентировочно 50 ГБ логов в сутки»]
– Требования к хранению: [укажите, например, «оперативный доступ к логам за 7 дней, архив за 90 дней»]
– Текущие инструменты: [укажите, например, «логи пишутся в stdout, централизованного сбора нет»]
Спроектируй:
- Схему сбора и доставки логов
- Стандарт формата логов для всех сервисов (с примерами)
- Стратегию структурированного журналирования и обязательные поля
- Архитектуру хранения с учетом требований
- Типовые запросы для диагностики частых проблем
- Оценку ресурсов, необходимых для системы журналирования
Ограничения: предпочтение решениям с открытым исходным кодом, совместимым с российской инфраструктурой. Учитывай стоимость хранения при проектировании стратегии.
*****
Почему это работает: Включение оценки ресурсов и стоимости хранения в требования к ответу предотвращает проектирование красивой архитектуры, которую невозможно реализовать в рамках реального бюджета.
17. Настройка автоматического масштабирования
Проблема: Сервис либо постоянно перегружен в пиковые часы, либо работает на избыточных ресурсах в остальное время – потому что масштабирование настроено статически или не настроено вообще.
Решение: Промпт разрабатывает стратегию автоматического масштабирования с конкретными параметрами, адаптированными к профилю нагрузки приложения.
Текст промпта:
*****
Ты – [укажите роль, например, «платформенный инженер с экспертизой в настройке автоматического масштабирования для высоконагруженных систем»]. Разработай стратегию автоматического масштабирования.
Характеристики нагрузки:
– Приложение: [опишите, например, «API-сервис для мобильного приложения»]
– Профиль нагрузки: [опишите, например, «пиковая нагрузка утром 8-10 и вечером 18-21, в ночное время нагрузка минимальна, возможны внезапные пики при маркетинговых акциях»]
– Текущая конфигурация: [укажите, например, «статически 5 реплик, CPU-запрос 500m, лимит 1000m»]
– Метрики для масштабирования: [укажите, например, «CPU, время ответа API, количество запросов в секунду»]
Разработай:
- Конфигурацию горизонтального автомасштабирования подов с обоснованием параметров
- Конфигурацию масштабирования узлов кластера
- Настройку масштабирования на основе пользовательских метрик (не только CPU)
- Стратегию предварительного масштабирования перед прогнозируемыми пиками
- Политику масштабирования вниз без влияния на доступность
Формат: готовые конфигурационные файлы с детальными комментариями. Ограничения: учитывай время запуска нового экземпляра приложения при расчете параметров масштабирования.
*****
Почему это работает: Требование учитывать время запуска нового экземпляра при расчете параметров – это тот самый нюанс, который упускают при стандартной настройке и из-за которого масштабирование «срабатывает слишком поздно».
18. Разработка процесса управления изменениями
Проблема: Изменения в производственной среде вносятся либо слишком хаотично (кто что успел), либо слишком бюрократично (согласование занимает больше времени, чем само изменение) – и в обоих случаях что-то идет не так.
Решение: Промпт создает практичный процесс управления изменениями, балансирующий между скоростью и контролем риска.
Текст промпта:
*****
Ты – [укажите роль, например, «DevOps-консультант с опытом выстраивания процессов управления изменениями в технических командах»]. Разработай процесс управления изменениями инфраструктуры.
Контекст организации:
– Размер команды: [укажите, например, «15 инженеров: 5 DevOps, 10 разработчиков»]
– Частота изменений: [укажите, например, «20-30 деплоев в неделю, 5-10 изменений инфраструктуры»]
– Текущие проблемы: [опишите, например, «2-3 инцидента в месяц из-за несогласованных изменений, размытая ответственность»]
– Требования к доступности: [укажите, например, «SLA 99.9% для производственных сервисов»]
Разработай процесс, включающий:
- Классификацию изменений по уровню риска с примерами для каждой категории
- Процедуру для каждого класса изменений (что нужно, кто согласует, сколько времени)
- Шаблон заявки на изменение (только необходимые поля, без бюрократии)
- Процедуру экстренных изменений
- Метрики для оценки эффективности процесса
Принцип: процесс должен снижать риск, а не создавать препятствия для работы. Ограничения: процедура для изменений низкого риска не должна занимать более 15 минут.
*****
Почему это работает: Жесткое ограничение времени для изменений низкого риска (15 минут) заставляет нейросеть проектировать реально легкий процесс, а не добавлять шаги «на всякий случай», которые убивают скорость.
19. Оптимизация затрат на облачную инфраструктуру
Проблема: Счет за облако каждый месяц вызывает вопросы, но никто точно не знает, что именно его генерирует – потому что ресурсы создавались итерационно и часть из них давно не нужна, но продолжает работать по инерции.
Решение: Промпт проводит анализ затрат и создает конкретный план оптимизации с ожидаемой экономией по каждому направлению.
Текст промпта:
*****
Ты – [укажите роль, например, «инженер по оптимизации облачной инфраструктуры с опытом снижения затрат без потери производительности»]. Проведи анализ и разработай план оптимизации затрат на облачную инфраструктуру.
Текущая инфраструктура:
[опишите компоненты и их примерную стоимость, например, «виртуальные машины: 15 инстансов разного размера, общая стоимость 200 000 руб/мес; хранилище объектов: 50 ТБ, 80 000 руб/мес; трафик: 100 000 руб/мес; базы данных: 3 управляемых экземпляра PostgreSQL, 120 000 руб/мес»]
Дополнительный контекст:
– Профиль использования: [опишите, например, «75% нагрузки в рабочее время, часть сред разработки работает круглосуточно»]
– Ограничения: [укажите, например, «нельзя снижать производительность производственных сервисов, возможен кратковременный риск при изменениях в непроизводственных средах»]
Проведи анализ по направлениям:
- Неиспользуемые или избыточные ресурсы
- Оптимизация типов инстансов (зарезервированные vs. по требованию)
- Оптимизация хранилища и политик жизненного цикла данных
- Автоматическое выключение непроизводственных сред
- Архитектурные изменения для снижения затрат
Для каждого направления: конкретные действия, ожидаемая экономия, риски, приоритет внедрения.
*****
Почему это работает: Структурированный запрос с реальными цифрами затрат позволяет нейросети рассчитать конкретную ожидаемую экономию, а не дать абстрактные советы «используйте зарезервированные инстансы».
20. Создание процедуры управления сертификатами
Проблема: Сертификат истекает в самый неподходящий момент – обычно в пятницу вечером или в праздник – потому что ротация производится вручную и о ней помнят только тогда, когда браузер начинает показывать предупреждение.
Решение: Промпт разрабатывает автоматизированный процесс управления сертификатами с мониторингом сроков и автоматической ротацией.
Текст промпта:
*****
Ты – [укажите роль, например, «DevOps-инженер, специализирующийся на автоматизации управления TLS-сертификатами»]. Разработай процедуру автоматизированного управления сертификатами.
Контекст:
– Среда: [опишите, например, «Kubernetes-кластер, 30+ доменов, внутренние и внешние сервисы»]
– Текущий процесс: [опишите, например, «сертификаты обновляются вручную, нет централизованного отслеживания сроков истечения»]
– Инфраструктура: [укажите, например, «Kubernetes, Nginx Ingress, часть сертификатов от публичного удостоверяющего центра, часть – внутренний корпоративный»]
Разработай:
- Архитектуру автоматического управления сертификатами (инструменты, схема)
- Конфигурацию для автоматического выпуска и обновления сертификатов
- Мониторинг сроков истечения с оповещениями за 30, 14 и 7 дней
- Процедуру для сертификатов, которые нельзя автоматизировать
- Аварийную процедуру при истечении критического сертификата
Ограничения: решение должно работать для обоих типов сертификатов (публичных и корпоративных). Предусмотри обработку случая, когда автоматическое обновление не сработало.
*****
Почему это работает: Явное требование обработки ситуации, когда автоматика не сработала, – это именно тот сценарий, который обычно упускают при проектировании, а потом вспоминают о нем в пятницу вечером.
21. Проектирование стратегии развертывания без простоя
Проблема: Деплой новой версии означает кратковременную недоступность сервиса или рост ошибок – потому что стратегия развертывания не соответствует требованиям доступности и особенностям приложения.
Решение: Промпт проектирует стратегию развертывания с нулевым временем простоя, адаптированную к конкретному приложению и инфраструктуре.
Текст промпта:
*****
Ты – [укажите роль, например, «DevOps-архитектор с опытом реализации стратегий развертывания для критически важных сервисов»]. Спроектируй стратегию развертывания без простоя.
Характеристики приложения:
– Тип: [опишите, например, «монолитное приложение на Java, переходящее к микросервисной архитектуре»]
– Особенности: [опишите, например, «длительные сессии пользователей, изменения схемы базы данных при каждом крупном релизе»]
– Частота деплоев: [укажите, например, «1-2 раза в неделю»]
– Требования к доступности: [укажите, например, «не более 0.1% ошибок во время деплоя»]
Инфраструктура: [опишите, например, «Kubernetes, база данных PostgreSQL, Redis для сессий»]
Разработай:
- Рекомендуемую стратегию с обоснованием (сине-зеленая, канареечная, скользящее обновление)
- Процедуру обработки изменений схемы базы данных без простоя
- Конфигурацию для выбранной стратегии
- Критерии автоматического отката и процедуру отката
- Метрики для оценки успешности деплоя в реальном времени
Ограничения: учитывай особенность с длительными сессиями при выборе стратегии. Процедура отката должна быть выполнима за 5 минут.
*****
Почему это работает: Указание конкретной особенности (длительные сессии) и ограничения на время отката заставляет нейросеть выбирать стратегию с учетом реальных ограничений, а не просто рекомендовать канареечное развертывание как универсальный ответ.
22. Написание политики управления доступом к инфраструктуре
Проблема: Доступ к производственной инфраструктуре есть у всех, кто когда-либо попросил, – потому что давать удобнее, чем разбираться с уровнями доступа. В результате принцип минимальных привилегий существует только в теории.
Решение: Промпт разрабатывает практичную политику управления доступом с ролевой моделью, процедурами выдачи и отзыва прав.
Текст промпта:
*****
Ты – [укажите роль, например, «инженер по информационной безопасности с опытом построения систем управления доступом для технических команд»]. Разработай политику управления доступом к инфраструктуре.
Контекст организации:
– Состав команды: [опишите, например, «разработчики (20 чел.), DevOps-инженеры (5 чел.), тестировщики (10 чел.), менеджеры проектов (5 чел.)»]
– Инфраструктура: [перечислите, например, «Kubernetes-кластеры (разработка/тестирование/производство), облачная консоль Яндекс Cloud, репозитории GitLab, системы мониторинга»]
– Текущие проблемы: [опишите, например, «нет разграничения доступа к средам, уволившиеся сотрудники не всегда лишаются доступа своевременно»]
Разработай:
- Ролевую модель доступа с описанием каждой роли
- Матрицу доступа: роль × ресурс × уровень доступа
- Процедуру запроса и выдачи доступа (с временными рамками)
- Процедуру отзыва доступа при увольнении или смене роли
- Процесс регулярного аудита прав доступа (периодичность, ответственные)
- Требования к использованию привилегированного доступа
Формат: практичный документ для внедрения. Ограничения: процедура выдачи стандартного доступа не должна занимать более одного рабочего дня.
*****
Почему это работает: Включение в контекст реальной проблемы (уволившиеся сотрудники с активным доступом) фокусирует нейросеть на самых критичных аспектах политики, а не на академически правильных, но практически редких сценариях.
23. Разработка стратегии тестирования инфраструктурного кода
Проблема: Код инфраструктуры не тестируется – «это же не приложение». В результате ошибки обнаруживаются только в производственной среде, когда Terraform уже применил конфигурацию и часть ресурсов успела пересоздаться.
Решение: Промпт создает стратегию тестирования инфраструктурного кода с конкретными инструментами и примерами тестов для основных сценариев.
Текст промпта:
*****
Ты – [укажите роль, например, «DevOps-инженер, внедряющий практики тестирования для инфраструктурного кода»]. Разработай стратегию тестирования инфраструктурного кода.
Контекст:
– Используемые инструменты: [перечислите, например, «Terraform для инфраструктуры, Helm для Kubernetes-приложений, Ansible для конфигурации серверов»]
– Объем кода: [укажите, например, «30+ Terraform-модулей, 15 Helm-чартов»]
– Текущее состояние: [опишите, например, «тестирования нет, проверка только через ручное применение в среде разработки»]
Разработай стратегию, включающую:
- Уровни тестирования (статический анализ, модульные тесты, интеграционные тесты) с примерами для каждого уровня
- Конкретные инструменты для каждого уровня и типа кода
- Примеры тестов для типичных сценариев (создание сети, развертывание сервиса)
- Интеграцию тестов в конвейер с разумным временем выполнения
- Стратегию изолированных тестовых сред
Ограничения: тесты статического анализа должны выполняться менее 2 минут. Предлагай только инструменты с открытым исходным кодом или бесплатным уровнем использования.
*****
Почему это работает: Ограничение времени выполнения статического анализа (2 минуты) – ключевой фактор принятия тестов командой: если проверка занимает 15 минут, ее начинают пропускать, и весь смысл теряется.
24. Создание системы управления конфигурацией приложений
Проблема: Конфигурация приложения в разных средах отличается, но управляется хаотично: где-то переменные окружения, где-то конфигурационные файлы в репозитории, где-то значения жестко прописаны в коде – и воспроизвести поведение производственной среды в тестовой невозможно.
Решение: Промпт проектирует единую систему управления конфигурацией приложений с четким разделением по средам и типам данных.
Текст промпта:
*****
Ты – [укажите роль, например, «DevOps-инженер, стандартизирующий управление конфигурацией в организации»]. Спроектируй систему управления конфигурацией приложений.
Контекст:
– Количество сервисов: [укажите, например, «20 микросервисов на разных технологиях»]
– Среды: [перечислите, например, «разработка, тестирование, предпроизводственная, производственная»]
– Текущие проблемы: [опишите, например, «конфигурация разбросана по разным местам, нет единого стандарта, часть настроек продублирована и рассинхронизирована»]
– Типы конфигурации: [перечислите, например, «параметры подключения к базам данных, URL внешних сервисов, флаги функций, параметры производительности»]
Спроектируй систему:
- Классификация конфигурации по типам и уровням чувствительности
- Стандарт именования и организации конфигурационных параметров
- Инструменты и архитектура хранения для каждого типа
- Процесс изменения конфигурации (версионирование, аудит, применение)
- Стандарт для разработчиков: как добавить новый параметр конфигурации
- Механизм горячего обновления конфигурации без перезапуска сервисов
Ограничения: система должна поддерживать сервисы на разных технологиях без специфичных для каждого языка решений.
*****
Почему это работает: Требование поддержки разнородных технологий без специфичных решений для каждого языка – это реальное ограничение, которое исключает рекомендации типа «используйте Spring Cloud Config» для всего стека.
25. Разработка плана обеспечения соответствия требованиям безопасности
Проблема: Требования безопасности и регуляторные нормы существуют в виде документов, которые никто не читал, а их выполнение проверяется только во время аудита – когда исправлять что-либо уже поздно и дорого.
Решение: Промпт создает практичный план обеспечения соответствия требованиям с конкретными техническими мерами и автоматизированными проверками.
Текст промпта:
*****
Ты – [укажите роль, например, «инженер по безопасности инфраструктуры с опытом обеспечения соответствия регуляторным требованиям»]. Разработай план технического обеспечения соответствия требованиям безопасности.
Контекст:
– Тип данных: [опишите, например, «персональные данные пользователей, платежная информация»]
– Применимые требования: [укажите, например, «152-ФЗ о персональных данных, требования платежных систем»]
– Инфраструктура: [опишите, например, «облачная инфраструктура в Яндекс Cloud, Kubernetes, PostgreSQL»]
– Текущий статус: [опишите, например, «базовые меры есть, но нет систематического подхода и документирования»]
Разработай план по блокам:
- Технические меры защиты данных (шифрование, разграничение доступа, маскирование)
- Журналирование и аудит для соответствия требованиям
- Автоматизированные проверки соответствия в конвейере
- Процедуры реагирования на утечку данных
- Документация для подтверждения соответствия при аудите
Для каждой меры: конкретная техническая реализация, инструменты, приоритет внедрения. Ограничения: фокус на технической реализации, не на юридических аспектах. Не предлагай западные облачные сервисы.
*****
Почему это работает: Разделение технической реализации и юридических аспектов фокусирует ответ на том, что DevOps-инженер реально может сделать, а не на пересказе законодательных норм, которые он уже знает.
26. Проектирование системы управления версиями инфраструктуры
Проблема: Непонятно, что именно изменилось в инфраструктуре за последние три месяца, кто это сделал и почему – потому что изменения применяются напрямую без версионирования и осмысленных описаний.
Решение: Промпт проектирует систему версионирования и отслеживания изменений инфраструктуры с интеграцией в существующий рабочий процесс.
Текст промпта:
*****
Ты – [укажите роль, например, «DevOps-инженер, выстраивающий процессы управления изменениями инфраструктуры»]. Спроектируй систему версионирования и отслеживания изменений инфраструктуры.
Контекст:
– Инструменты инфраструктуры: [перечислите, например, «Terraform, Helm, Ansible, конфигурационные файлы Kubernetes»]
– Система контроля версий: [укажите, например, «GitLab»]
– Текущий процесс: [опишите, например, «код хранится в репозитории, но нет стандарта оформления коммитов, изменения часто применяются напрямую без запросов на слияние»]
– Размер команды: [укажите, например, «6 инженеров»]
Разработай систему:
- Стандарт оформления коммитов для инфраструктурных изменений
- Процесс обязательного прохождения через запросы на слияние с автоматическими проверками
- Стратегию ветвления для инфраструктурного кода
- Автоматическое ведение журнала изменений
- Связь изменений инфраструктуры с задачами в системе управления проектами
- Механизм просмотра истории изменений конкретного ресурса
Ограничения: система должна быть достаточно легкой, чтобы команда из 6 человек ее реально соблюдала. Избегай излишней бюрократии.
*****
Почему это работает: Ограничение «достаточно легкая для команды из 6 человек» – это не банальная оговорка, а ключевой критерий: процессы, которые не соблюдаются, хуже отсутствия процессов, потому что создают иллюзию контроля.
27. Разработка программы обучения для новых DevOps-инженеров
Проблема: Новый инженер приходит в команду и несколько месяцев «плавает» – потому что нет структурированной программы адаптации, а знания передаются через вопросы в мессенджере и случайные разговоры у кофемашины.
Решение: Промпт создает структурированную программу адаптации нового DevOps-инженера с конкретными задачами, ресурсами и критериями готовности к самостоятельной работе.
Текст промпта:
*****
Ты – [укажите роль, например, «опытный DevOps-инженер, разрабатывающий программу адаптации для новых членов команды»]. Разработай программу обучения и адаптации для нового DevOps-инженера.
Контекст:
– Стек технологий команды: [перечислите, например, «Kubernetes, Terraform, GitLab CI/CD, Prometheus/Grafana, Ansible, Яндекс Cloud»]
– Профиль нового инженера: [опишите, например, «2-3 года опыта в системном администрировании, базовое знакомство с Docker, без опыта Kubernetes»]
– Срок адаптации: [укажите, например, «3 месяца до самостоятельной работы»]
– Доступность ментора: [укажите, например, «1 час в день»]
Разработай программу по месяцам:
– Месяц 1: ориентация и базовые навыки (конкретные задачи и ресурсы)
– Месяц 2: углубленное изучение и практика (реальные задачи нарастающей сложности)
– Месяц 3: самостоятельная работа под наблюдением
Для каждого этапа: конкретные темы, практические задания, критерии завершения этапа. В конце – итоговые критерии готовности к полностью самостоятельной работе.
Ограничения: программа должна быть реалистичной при занятости ментора 1 час в день. Не включай темы, которые новый инженер не сможет освоить без реального опыта.
*****
Почему это работает: Ограничение по занятости ментора (1 час в день) – это реальное условие большинства команд, и его учет заставляет нейросеть строить программу, где новый инженер действительно учится самостоятельно, а не ждет объяснений.
Типичные ошибки при составлении запросов для нейросети в DevOps-задачах
- Запрашивать конфигурацию без указания версий используемых инструментов. Kubernetes 1.25 и 1.28 имеют разные API, и конфигурация, правильная для одной версии, может не работать или содержать устаревшие поля в другой.
- Описывать желаемый результат вместо текущей проблемы. «Сделай мне хороший мониторинг» дает универсальный шаблон, а «у нас 40% ложных срабатываний из-за кратковременных пиков CPU» направляет к конкретному решению конкретной боли.
- Не указывать ограничения среды при запросе инструментов. Нейросеть по умолчанию предложит AWS CloudWatch, HashiCorp Cloud и прочие сервисы, недоступные в российской инфраструктуре – и весь ответ придется переделывать.
- Запрашивать сразу весь проект одним запросом без разбивки на компоненты. Запрос «спроектируй всю инфраструктуру для нашего стартапа» дает поверхностный обзор вместо глубокой проработки – лучше разбить на отдельные компоненты и проработать каждый.
- Не указывать размер команды и уровень навыков при запросе процессов и стандартов. Процесс, идеальный для команды из 30 инженеров, может быть неподъемной бюрократией для команды из 5 – и в реальности не будет соблюдаться.
- Принимать сгенерированные конфигурации без проверки в изолированной среде. Нейросеть может генерировать синтаксически корректные, но логически ошибочные конфигурации – особенно в нюансах взаимодействия компонентов.
- Запрашивать исправление проблемы без предоставления полного контекста симптомов. «Почему падает мой под» без логов, описания событий и временной шкалы – это гадание на кофейной гуще, а не диагностика.
- Не указывать требования к обратной совместимости при запросе изменений схем или API. Красивое решение, ломающее существующих клиентов, – это не решение, а новый инцидент с красивым кодом.
- Использовать сгенерированные сценарии в производственной среде без тестирования на реальных данных. Логика работы с граничными случаями – пустые результаты, недоступные ресурсы, превышение прав – требует проверки на реальных условиях, а не только на синтетических примерах.
Сравнение слабых и сильных запросов для DevOps-задач
| Задача | Слабый запрос | Сильный запрос | Почему важна разница |
| Оптимизация конвейера | Как ускорить GitLab CI? | Конвейер выполняется 18 минут (установка зависимостей – 4 мин, тесты – 9 мин, сборка – 3 мин, публикация – 2 мин). Цель – 8 минут. Предложи конкретные изменения конфигурации с оценкой эффекта. | Слабый запрос дает общие советы про кэш. Сильный – конкретный план под реальные цифры. |
| Написание конфигурации | Напиши Kubernetes Deployment для Node.js | Напиши Deployment для Node.js 20 в Kubernetes 1.28: 3 реплики, CPU 500m/1000m, память 256Mi/512Mi, переменные окружения NODE_ENV и DB_HOST из секрета, readinessProbe и livenessProbe. Добавь комментарии к каждому блоку. | Слабый запрос дает минимальный шаблон. Сильный – готовую конфигурацию под конкретные требования. |
| Диагностика инцидента | Почему база данных не работает? | PostgreSQL 15 перестал принимать подключения, ошибка «too many connections». PgBouncer настроен, максимум соединений – 200. Нагрузка не изменилась. Что проверить в первую очередь и какие команды использовать? | Слабый запрос невозможно ответить конкретно. Сильный дает четкую диагностическую последовательность. |
| Аудит безопасности | Проверь мою конфигурацию на безопасность | Проверь конфигурацию Terraform [вставить] на соответствие требованиям 152-ФЗ. Для каждой проблемы: уровень критичности, описание риска, конкретный пример исправления. | Слабый запрос дает общий список рекомендаций. Сильный – приоритизированный список с готовыми исправлениями. |
| Написание сценария | Напиши скрипт резервного копирования PostgreSQL | Напиши Bash-сценарий резервного копирования PostgreSQL 15 в Яндекс Cloud S3: проверка целостности через контрольную сумму, ротация копий (7 дней ежедневных, 4 недели еженедельных), уведомление в Telegram, ненулевой код завершения при любой ошибке, учетные данные только через переменные окружения. | Слабый запрос дает базовый pg_dump. Сильный – производственный сценарий с обработкой всех граничных случаев. |
| Документация | Напиши документацию по инфраструктуре | Напиши архитектурную документацию по [описание инфраструктуры] для аудитории: новые DevOps-инженеры и разработчики. Включи: схему взаимодействий, различия сред, процедуры деплоя и отката. Если информации недостаточно – задай уточняющие вопросы. | Слабый запрос дает универсальный шаблон. Сильный – документ под конкретную аудиторию и реальную инфраструктуру. |
Советы по работе с нейросетью для DevOps-задач
- Вставляйте реальные фрагменты конфигурации вместо их описания. Нейросеть анализирует конкретный YAML или Terraform-код на порядок точнее, чем текстовое описание «у меня настроен Deployment с тремя репликами» – детали, которые кажутся очевидными при описании, часто оказываются ключевыми.
- Просите нейросеть задавать уточняющие вопросы перед генерацией сложных конфигураций. Это переключает режим работы с «дать что-нибудь подходящее» на «выяснить, что именно нужно» – и итоговый результат требует значительно меньше правок.
- Используйте нейросеть для генерации нескольких альтернативных подходов с компромиссами. Вместо «напиши стратегию развертывания» запрашивайте «предложи три варианта стратегии развертывания с указанием компромиссов между скоростью, надежностью и сложностью» – это дает материал для осознанного выбора, а не навязанное решение.
- Сохраняйте удачные промпты с конкретными параметрами вашей инфраструктуры в отдельный файл команды. Промпт с уже заполненными версиями инструментов, размерами кластера и требованиями к доступности работает без подготовки – его можно использовать повторно при каждом новом инциденте или задаче того же типа.
- Просите нейросеть явно перечислить допущения, которые она сделала при генерации конфигурации. Нейросеть всегда делает допущения о среде, версиях и требованиях – и большинство ошибок в сгенерированных конфигурациях связаны именно с неверными допущениями, которые остались скрытыми.
- Для диагностики инцидентов давайте временную шкалу событий, а не только описание симптома. «Ошибка 503» – это симптом. «Ошибки начались через 3 минуты после деплоя, пиковая нагрузка в это время была штатной, предыдущий деплой прошел успешно» – это информация для диагностики, которая в разы сужает пространство возможных причин.
- После получения ответа запрашивайте «какие риски и ограничения у этого решения, о которых стоит знать». Нейросеть по умолчанию отвечает на вопрос, а не предупреждает о подводных камнях – отдельный вопрос о рисках часто выявляет критические нюансы, которые меняют решение о применении.
