Промпты для системного инженера. 24 готовых примера для генерации

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

В этой статье собраны 24 готовых примера запросов к нейросети – для диагностики, документирования, проектирования инфраструктуры, написания скриптов и многого другого. Каждый промпт проверен на практичность: никакой воды, только рабочие формулировки с переменными под вашу ситуацию.

Что найдете внутри:

• Промпты для анализа инцидентов и поиска первопричин сбоев
• Запросы для проектирования сетевой и серверной инфраструктуры
• Шаблоны для написания технической документации и регламентов
• Инструкции для автоматизации рутинных задач и написания скриптов
• Запросы для подготовки к аудитам и оценке рисков безопасности
• Типичные ошибки при работе с нейросетью в технической среде
• Таблица слабых и сильных формулировок с примерами из практики

24 промпта для системного инженера: готовые примеры

1. Анализ инцидента и поиск первопричины

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

Решение:
Промпт заставляет нейросеть выступить в роли опытного аналитика инцидентов и выстроить структурированное расследование по описанию симптомов.

Текст промпта:

*****

Ты – опытный инженер по анализу инцидентов [укажите специализацию, например, “в области серверной инфраструктуры Linux” или “в области сетевого оборудования Cisco”]. Твоя задача – провести структурированный анализ инцидента и выявить вероятные первопричины.

Контекст инцидента: [опишите, что произошло, например, “в 03:14 по московскому времени упал веб-сервер, пользователи получали ошибку 502, сервис не отвечал 47 минут”].

Симптомы и наблюдения: [перечислите все, что было замечено, например, “высокая нагрузка на CPU за 10 минут до падения, в логах nginx повторяющаяся ошибка upstream timed out, диск был заполнен на 98%”].

Проведи анализ по следующей структуре:

1. Хронология событий на основе описанных симптомов
2. Список вероятных первопричин (от наиболее к наименее вероятной) с объяснением логики
3. Какие данные еще нужно собрать для подтверждения каждой версии
4. Немедленные действия для стабилизации системы
5. Долгосрочные меры для предотвращения повторения

Избегай общих фраз. Давай конкретные команды и проверки для каждого пункта. Тон – технический, деловой, без лишних вступлений.

*****

Почему это работает:
Структура из пяти блоков не дает нейросети уйти в абстракцию – каждый блок требует конкретного действия. Запрос на дополнительные данные особенно ценен: он показывает, что расследование еще не завершено, и не позволяет выдать первую попавшуюся версию за истину.

2. Проектирование сетевой топологии

Проблема:
Нужно спроектировать или пересмотреть сетевую архитектуру, но сформулировать требования так, чтобы получить действительно применимую схему, а не общие советы – задача нетривиальная.

Решение:
Промпт задает четкие параметры инфраструктуры и вынуждает нейросеть предложить конкретную топологию с обоснованием каждого решения.

Текст промпта:

*****

Ты – сетевой архитектор [укажите уровень, например, “с опытом проектирования корпоративных сетей среднего бизнеса” или “специализирующийся на отказоустойчивых распределенных системах”]. Твоя задача – разработать сетевую топологию на основе следующих требований.

Описание организации: [укажите, например, “производственное предприятие, 3 площадки в разных городах, головной офис в Москве, 200 рабочих мест суммарно”].

Требования к доступности: [укажите, например, “критичные системы – не менее 99,9% uptime, плановые окна обслуживания допускаются в ночное время”].

Существующая инфраструктура: [опишите, что уже есть, например, “два канала интернет-провайдеров в головном офисе, коммутаторы Cisco Catalyst 2960 на площадках”].

Бюджетные ограничения: [укажите, например, “замена оборудования на всех трех площадках, бюджет до 2 млн рублей”].

Предложи:

1. Схему топологии с описанием каждого уровня (ядро, распределение, доступ)
2. Рекомендуемое оборудование с обоснованием выбора
3. Схему резервирования каналов и оборудования
4. Сегментацию сети (VLAN) с назначением каждого сегмента
5. Риски предложенного решения и способы их снижения

Используй только оборудование, доступное на российском рынке. Тон – профессиональный, без маркетинговых клише.

*****

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

3. Написание технического регламента

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

Решение:
Промпт создает структурированный регламент под конкретный процесс с учетом уровня аудитории и требований к оформлению.

Текст промпта:

*****

Ты – технический писатель с опытом разработки эксплуатационной документации для ИТ-инфраструктуры. Твоя задача – написать технический регламент для следующего процесса.

Процесс: [укажите, например, “резервное копирование данных на серверах под управлением Windows Server 2019” или “плановое обслуживание сетевого оборудования”].

Целевая аудитория документа: [укажите, например, “системные администраторы уровня junior и middle, не обязательно знакомые с конкретным программным обеспечением”].

Используемые инструменты и системы: [перечислите, например, “Veeam Backup & Replication, хранилище на базе Synology NAS, Active Directory”].

Требования к документу: [укажите особые требования, например, “документ должен соответствовать внутреннему стандарту оформления, содержать блок-схему процесса и таблицу ответственных”].

Структура регламента:

1. Назначение и область применения
2. Термины и определения
3. Описание процесса (пошагово, с указанием ответственных и сроков)
4. Действия в нештатных ситуациях
5. Контроль исполнения
6. Лист согласования (шаблон)

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

*****

Почему это работает:
Указание целевой аудитории принципиально меняет уровень детализации и язык документа. Нейросеть перестает писать “для всех” и начинает писать для конкретного человека – это главное условие документа, который действительно используют.

4. Создание скрипта для автоматизации задачи

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

Решение:
Промпт формулирует техническое задание на скрипт с указанием среды, входных данных и ожидаемого поведения.

Текст промпта:

*****

Ты – опытный системный администратор и разработчик скриптов автоматизации [укажите специализацию, например, “для Windows PowerShell” или “для Linux Bash”]. Твоя задача – написать скрипт для автоматизации следующей задачи.

Задача: [опишите, что должен делать скрипт, например, “проверять свободное место на дисках всех серверов домена, и если оно ниже 15%, отправлять письмо на адрес администратора с указанием имени сервера, диска и текущего процента заполненности”].

Среда выполнения: [укажите, например, “Windows Server 2019, PowerShell 5.1, SMTP-сервер внутренний”].

Входные данные: [опишите, например, “список серверов берется из Active Directory, группа ‘Servers'”].

Ожидаемое поведение при ошибках: [укажите, например, “если сервер недоступен – записывать в лог-файл с временной меткой, продолжать проверку остальных”].

Требования к коду:
– Комментарии на русском языке к каждому блоку
– Параметры (порог, адрес почты, путь к логу) вынести в переменные в начале скрипта
– Скрипт должен корректно работать при запуске через планировщик задач Windows

Предоставь готовый код и краткое описание, как его настроить и запустить.

*****

Почему это работает:
Требование вынести параметры в переменные – это не прихоть, а инженерная культура: скрипт становится переиспользуемым без правки кода. Блок поведения при ошибках заставляет нейросеть написать не “счастливый путь”, а реальный рабочий инструмент.

5. Оценка рисков безопасности инфраструктуры

Проблема:
Аудит безопасности – процесс, который многие откладывают до первого серьезного инцидента. Получить структурированную оценку рисков без привлечения дорогостоящих консультантов – задача вполне решаемая с помощью нейросети.

Решение:
Промпт запускает анализ рисков по описанию инфраструктуры и формирует приоритизированный список уязвимостей с рекомендациями.

Текст промпта:

*****

Ты – специалист по информационной безопасности [укажите специализацию, например, “с фокусом на корпоративные сети и серверную инфраструктуру”]. Твоя задача – провести оценку рисков безопасности на основе описания инфраструктуры.

Описание инфраструктуры: [опишите подробно, например, “20 серверов Windows Server 2016-2019, Active Directory, почтовый сервер на базе Яндекс 360 для бизнеса, удаленный доступ через VPN на MikroTik, антивирус Kaspersky Endpoint Security на всех рабочих станциях”].

Известные проблемы и уязвимости: [укажите, что уже известно, например, “часть серверов не обновлялась более 6 месяцев, несколько сотрудников используют одинаковые пароли”].

Контекст организации: [укажите, например, “финансовая компания, обрабатывающая персональные данные клиентов, требования ФЗ-152”].

Проведи оценку по следующей структуре:

1. Критические риски (требуют немедленного устранения) – с описанием последствий
2. Высокие риски (устранить в течение 30 дней)
3. Средние риски (устранить в течение квартала)
4. Рекомендации по каждому риску с конкретными мерами
5. Что проверить дополнительно для полной оценки

Ссылайся на актуальные российские нормативные требования там, где это применимо. Тон – профессиональный, без алармизма.

*****

Почему это работает:
Приоритизация по срокам устранения – это то, что превращает список проблем в план работы. Без нее любой аудит превращается в документ, который кладут в стол и забывают.

6. Подготовка плана восстановления после сбоя

Проблема:
Планы восстановления существуют в двух состояниях: либо их нет совсем, либо они написаны так давно, что описывают уже несуществующую инфраструктуру. Составить актуальный и реалистичный план – задача, которую постоянно откладывают.

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

Текст промпта:

*****

Ты – инженер по обеспечению непрерывности бизнеса [укажите специализацию, например, “с опытом разработки планов восстановления для производственных предприятий”]. Твоя задача – разработать план восстановления после сбоя для конкретного сценария.

Сценарий сбоя: [опишите, например, “полный отказ основного сервера баз данных 1С:Предприятие в рабочее время” или “потеря основного канала связи с интернет-провайдером”].

Критичные системы и сервисы: [перечислите, например, “1С:Бухгалтерия, электронный документооборот, IP-телефония”].

Доступные резервные ресурсы: [опишите, например, “резервный сервер с актуальной репликой БД, резервный канал через мобильного оператора”].

Допустимое время простоя: [укажите, например, “не более 2 часов для критичных систем, не более 4 часов для остальных”].

Разработай план со следующей структурой:

1. Немедленные действия (первые 15 минут): кто, что, в каком порядке
2. Диагностика и оценка ущерба (15–60 минут)
3. Восстановление по шагам с временными метками
4. Проверка работоспособности после восстановления
5. Уведомление заинтересованных сторон (шаблоны сообщений)
6. Документирование инцидента

Каждый шаг должен содержать: ответственного, конкретное действие, ожидаемый результат.

*****

Почему это работает:
Временные метки в плане – это не формальность, а инструмент управления паникой: когда знаешь, что через 15 минут должно произойти конкретное действие, мозг переключается из режима тревоги в режим выполнения задачи.

7. Описание архитектуры системы для внутренней документации

Проблема:
Системный инженер, который все держит в голове, – это не актив компании, а риск. Когда такой человек уходит в отпуск или увольняется, оказывается, что документации нет, и никто не понимает, как все устроено.

Решение:
Промпт помогает структурировать описание архитектуры системы в формате, понятном коллегам с разным уровнем технической подготовки.

Текст промпта:

*****

Ты – технический архитектор и опытный технический писатель [укажите специализацию, например, “с опытом документирования корпоративных информационных систем”]. Твоя задача – составить описание архитектуры системы для внутренней документации.

Система: [опишите, например, “корпоративный портал на базе 1С-Битрикс, развернутый на трех серверах: веб-сервер Nginx, сервер приложений, сервер баз данных MySQL”].

Аудитория документа: [укажите, например, “новые системные администраторы и разработчики, которые будут поддерживать систему”].

Что нужно описать: [перечислите, например, “взаимодействие компонентов, точки отказа, порядок запуска и остановки, зависимости между сервисами”].

Составь документ со следующей структурой:

1. Краткое описание системы и ее назначение
2. Схема компонентов и их взаимодействие (в текстовом виде, если схему нельзя нарисовать)
3. Описание каждого компонента: роль, конфигурация, зависимости
4. Точки отказа и их последствия
5. Порядок запуска и корректной остановки
6. Типичные проблемы и их решения
7. Контакты ответственных за каждый компонент (шаблон таблицы)

Стиль – технический, но доступный. Избегай избыточных сокращений без расшифровки.

*****

Почему это работает:
Раздел “типичные проблемы и их решения” – это то, что превращает документ из описания в реальный инструмент поддержки. Именно его открывают первым, когда что-то пошло не так.

8. Планирование миграции на новую инфраструктуру

Проблема:
Миграция инфраструктуры – один из самых рискованных проектов в ИТ. Недооценить сложность, забыть зависимость, не предусмотреть откат – и то, что планировалось как плановое обновление, превращается в многодневный марафон по тушению пожаров.

Решение:
Промпт создает детальный план миграции с этапами, рисками и критериями успеха для конкретного сценария.

Текст промпта:

*****

Ты – инженер по миграции инфраструктуры [укажите специализацию, например, “с опытом переноса корпоративных систем с физических серверов на виртуализацию” или “с опытом миграции между площадками”]. Твоя задача – разработать план миграции.

Что мигрируем: [опишите, например, “перенос 15 виртуальных машин с VMware vSphere 6.5 на Proxmox VE 8.0”].

Текущая среда: [опишите подробно, например, “три физических хоста Dell PowerEdge R730, общий объем данных 8 ТБ, среди ВМ – контроллер домена, файловый сервер, сервер 1С”].

Ограничения: [укажите, например, “миграция должна быть выполнена в выходные дни, допустимый простой – не более 4 часов для некритичных систем и 30 минут для контроллера домена”].

Разработай план со следующей структурой:

1. Подготовительный этап (что сделать до начала миграции)
2. Порядок миграции ВМ с обоснованием последовательности
3. Процедура тестирования каждой ВМ после переноса
4. Критерии успешного завершения миграции
5. План отката (что делать, если что-то пошло не так)
6. Коммуникационный план (кого уведомить и когда)

Укажи временные оценки для каждого этапа. Выдели риски красным флагом там, где они наиболее высоки.

*****

Почему это работает:
Требование обосновать последовательность миграции ВМ – ключевое: нейросеть объясняет, почему контроллер домена мигрирует последним, а не первым, и это знание предотвращает классическую ошибку, которую совершают при первой самостоятельной миграции.

9. Настройка системы мониторинга

Проблема:
Мониторинг, который просто есть – бесполезен. Мониторинг, который генерирует сотни алертов в день – вреден. Настроить систему так, чтобы она предупреждала о реальных проблемах и не шумела по пустякам, – задача, требующая четкой логики.

Решение:
Промпт помогает спроектировать систему мониторинга с правильными порогами, каналами уведомлений и логикой эскалации.

Текст промпта:

*****

Ты – инженер по мониторингу и эксплуатации инфраструктуры [укажите специализацию, например, “с опытом настройки Zabbix для корпоративных сред” или “специализирующийся на системах оповещения и дежурных процессах”]. Твоя задача – разработать конфигурацию системы мониторинга.

Инструмент мониторинга: [укажите, например, “Zabbix 6.4” или “Prometheus + Grafana”].

Объекты мониторинга: [перечислите, например, “20 серверов Windows Server, 5 серверов Linux Ubuntu, 3 коммутатора Cisco, 2 межсетевых экрана”].

Критичность систем: [опишите, например, “сервер 1С и контроллер домена – критичные, файловые серверы – высокая, рабочие станции – низкая”].

Команда дежурных: [опишите, например, “2 системных администратора в рабочее время, один дежурный в нерабочее”].

Разработай конфигурацию мониторинга:

1. Перечень метрик для каждого типа объектов с обоснованием
2. Пороговые значения для предупреждений и критических алертов
3. Логика подавления алертов (чтобы не спамить при каскадных сбоях)
4. Каналы уведомлений и логика эскалации
5. Расписание проверок с учетом нагрузки на сеть
6. Метрики, которые большинство игнорирует, но они критически важны

Тон – технический. Приводи конкретные числа там, где это возможно.

*****

Почему это работает:
Запрос метрик, которые обычно игнорируют, – это прием, который вытаскивает из нейросети нестандартные, но ценные рекомендации. Именно такие вещи отличают зрелую систему мониторинга от базовой.

10. Написание постмортема по инциденту

Проблема:
Постмортем – документ, который должен учить, а не наказывать. Но написать его так, чтобы он был честным, структурированным и при этом не превращался в поиск виноватых – умение, которое приходит с опытом.

Решение:
Промпт создает структурированный постмортем в культуре “без обвинений” с акцентом на системные причины и конкретные меры.

Текст промпта:

*****

Ты – старший инженер по надежности систем [укажите специализацию, например, “с опытом ведения постмортемов в командах DevOps и SRE”]. Твоя задача – написать постмортем по произошедшему инциденту.

Описание инцидента: [опишите подробно, например, “14 марта с 09:23 до 11:47 был недоступен корпоративный портал для 350 пользователей. Причина – переполнение диска на сервере приложений из-за неконтролируемого роста лог-файлов”].

Хронология: [перечислите события с временными метками, например, “09:23 – первые жалобы пользователей, 09:41 – инцидент зафиксирован дежурным, 10:15 – определена причина, 11:47 – сервис восстановлен”].

Участники инцидента: [укажите роли, например, “дежурный администратор, руководитель ИТ-отдела, представитель бизнеса”].

Напиши постмортем по следующей структуре:

1. Краткое резюме (3–5 предложений)
2. Хронология событий
3. Первопричина (не симптом, а системная причина)
4. Что сработало хорошо
5. Что можно улучшить
6. Меры по предотвращению повторения (конкретные задачи с ответственными и сроками)

Стиль – культура без обвинений. Фокус на системах и процессах, не на людях. Формат – деловой документ.

*****

Почему это работает:
Явное указание “культура без обвинений” программирует тон всего документа. Без этого нейросеть склонна писать постмортемы в духе протокола расследования, что убивает желание команды быть честной в следующий раз.

11. Разработка политики резервного копирования

Проблема:
Резервные копии есть у всех. Проверенные резервные копии – у единиц. Политика резервного копирования, которая реально выполняется и регулярно тестируется, – редкость, заслуживающая уважения.

Решение:
Промпт создает комплексную политику резервного копирования с расписанием, хранилищами и обязательной процедурой проверки.

Текст промпта:

*****

Ты – инженер по защите данных и обеспечению непрерывности бизнеса [укажите специализацию, например, “с опытом проектирования систем резервного копирования для предприятий среднего размера”]. Твоя задача – разработать политику резервного копирования.

Что нужно защитить: [перечислите, например, “базы данных 1С (объем 500 ГБ), файловый сервер (2 ТБ), конфигурации сетевого оборудования, виртуальные машины (15 ВМ)”].

Инструменты резервного копирования: [укажите, например, “Veeam Backup & Replication, встроенные средства Windows Server Backup”].

Доступные хранилища: [опишите, например, “локальный NAS Synology 20 ТБ, удаленное хранилище в дата-центре 10 ТБ”].

Требования бизнеса: [укажите, например, “максимально допустимая потеря данных – 4 часа, максимальное время восстановления – 8 часов для критичных систем”].

Разработай политику, включающую:

1. Расписание резервного копирования по типам данных (полное, инкрементное, дифференциальное)
2. Правило хранения копий (сколько хранить, где, как ротировать)
3. Процедуру проверки целостности резервных копий
4. Процедуру тестового восстановления (периодичность, порядок)
5. Мониторинг и алертинг по задачам резервного копирования
6. Ответственных и их обязанности

Укажи конкретные числа: сроки хранения, частоту проверок, допустимые показатели.

*****

Почему это работает:
Требование указать конкретные числа – это защита от документа-декларации, который красиво выглядит, но ничего не измеряет. Политика без цифр – не политика, а пожелание.

12. Анализ производительности сервера

Проблема:
Сервер “тормозит” – это не диагноз. Выяснить, что именно является узким местом: процессор, память, диск или сеть – и почему это происходит именно сейчас – требует системного подхода.

Решение:
Промпт создает методологию анализа производительности по описанным симптомам с конкретными командами диагностики.

Текст промпта:

*****

Ты – инженер по производительности серверных систем [укажите специализацию, например, “специализирующийся на оптимизации Linux-серверов” или “с опытом настройки Windows Server под высоконагруженные приложения”]. Твоя задача – провести анализ производительности сервера.

Описание симптомов: [опишите подробно, например, “сервер баз данных начинает тормозить каждый день с 10:00 до 12:00, время отклика запросов увеличивается с 200 мс до 3–5 секунд, жалобы от пользователей 1С”].

Характеристики сервера: [укажите, например, “Dell PowerEdge R740, 2 x Intel Xeon Gold 6230, 256 ГБ RAM, дисковый массив SAS 10k на RAID 10, Windows Server 2019, SQL Server 2019”].

Уже проверено: [укажите, что уже смотрели, например, “нагрузка на CPU в момент тормозов не превышает 40%, свободная память – около 80 ГБ”].

Проведи анализ по следующей структуре:

1. Гипотезы о причинах на основе описания (от наиболее вероятной)
2. Диагностические команды и инструменты для проверки каждой гипотезы
3. Что искать в результатах каждой проверки
4. Неочевидные причины, которые часто упускают при похожих симптомах
5. Рекомендации по оптимизации после подтверждения причины

Приводи конкретные команды. Тон – технический, без общих слов.

*****

Почему это работает:
Блок “неочевидные причины” – это самая ценная часть ответа. Именно туда нейросеть помещает то, что обычно находят только после нескольких часов безуспешной диагностики по очевидным версиям.

13. Подготовка технического задания для подрядчика

Проблема:
Размытое техническое задание – это деньги, выброшенные на ветер, и бесконечные споры о том, что именно должно было быть сделано. Написать ТЗ так, чтобы подрядчик понял все правильно с первого раза, – отдельный навык.

Решение:
Промпт создает структурированное техническое задание с однозначными требованиями, критериями приемки и условиями работы.

Текст промпта:

*****

Ты – опытный системный архитектор и технический менеджер [укажите специализацию, например, “с опытом управления проектами по внедрению ИТ-инфраструктуры”]. Твоя задача – составить техническое задание для внешнего подрядчика.

Задача для подрядчика: [опишите, например, “внедрение системы видеонаблюдения на производственном объекте: 40 камер, серверная часть, интеграция с системой контроля доступа”].

Требования к результату: [опишите, например, “запись 30 дней, разрешение не менее 2 МП, удаленный доступ через мобильное приложение, хранение на локальном сервере”].

Ограничения: [укажите, например, “бюджет до 1,5 млн рублей, срок внедрения – 45 рабочих дней, работа в действующем производстве без остановки”].

Составь техническое задание со следующей структурой:

1. Общее описание проекта и цели
2. Технические требования (детально, с конкретными параметрами)
3. Требования к документации, которую должен предоставить подрядчик
4. Порядок сдачи-приемки работ и критерии успешного завершения
5. Гарантийные обязательства и условия технической поддержки
6. Ответственность сторон за нарушение сроков

Стиль – официально-деловой. Каждое требование должно быть однозначным и проверяемым.

*****

Почему это работает:
Требование “однозначным и проверяемым” – это критерий, который нейросеть применяет к каждому пункту и автоматически убирает формулировки вроде “качественная настройка” и “современное оборудование”, которые невозможно принять или отклонить на приемке.

14. Разработка процедуры управления изменениями

Проблема:
Большинство инцидентов в ИТ происходит не из-за отказа оборудования, а из-за несогласованных изменений. “Я просто обновил конфигурацию” – фраза, предшествующая многим ночным дежурствам.

Решение:
Промпт создает процедуру управления изменениями, которая защищает от непродуманных действий и при этом не превращается в бюрократический барьер.

Текст промпта:

*****

Ты – процессный инженер и специалист по ITSM [укажите специализацию, например, “с опытом внедрения процессов управления изменениями в ИТ-отделах среднего бизнеса”]. Твоя задача – разработать процедуру управления изменениями в ИТ-инфраструктуре.

Описание организации: [опишите, например, “ИТ-отдел из 5 человек, инфраструктура 50 серверов и 300 рабочих мест, критичные системы – 1С, CRM, электронный документооборот”].

Текущая ситуация: [опишите, например, “изменения вносятся без формальной процедуры, несколько инцидентов за последний год были вызваны несогласованными изменениями”].

Требования к процедуре: [укажите, например, “процедура должна быть простой, не создавать лишней бюрократии, но при этом обеспечивать контроль над рискованными изменениями”].

Разработай процедуру, включающую:

1. Классификацию изменений по уровню риска (с примерами для каждого класса)
2. Процесс согласования для каждого класса (кто согласует, в какие сроки)
3. Шаблон запроса на изменение (минимально необходимые поля)
4. Обязательные элементы плана отката
5. Правила планирования окон обслуживания
6. Анализ изменений после внедрения

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

*****

Почему это работает:
Указание “реально выполняться, а не существовать на бумаге” задает нейросети правильный критерий оценки каждого предложения. Без этого получается идеальная процедура для идеального мира, которую в реальном ИТ-отделе никто не соблюдает.

15. Оптимизация конфигурации межсетевого экрана

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

Решение:
Промпт помогает провести аудит существующих правил и разработать оптимизированную конфигурацию с обоснованием каждого решения.

Текст промпта:

*****

Ты – инженер по сетевой безопасности [укажите специализацию, например, “с опытом настройки межсетевых экранов UserGate и Континент” или “специализирующийся на аудите сетевых политик”]. Твоя задача – провести аудит и оптимизацию конфигурации межсетевого экрана.

Используемое оборудование: [укажите, например, “UserGate UTM версии 6.1”].

Описание текущей ситуации: [опишите, например, “в конфигурации около 200 правил, добавлявшихся в течение 7 лет. Часть правил дублирует друг друга, часть устарела. Правила не документированы”].

Сетевые сегменты: [опишите, например, “корпоративная сеть, DMZ с веб-сервером, гостевая сеть Wi-Fi, сеть управления инфраструктурой”].

Проведи аудит и предложи:

1. Методологию анализа существующих правил (как выявить дубли и устаревшие)
2. Принципы группировки и упорядочивания правил
3. Базовый набор правил для каждого сегмента с обоснованием
4. Правила, которые чаще всего настраивают небезопасно (с примерами)
5. Процедуру документирования правил (формат комментариев, соглашения об именовании)
6. Как тестировать изменения без риска блокировки критичного трафика

Тон – технический. Приводи конкретные примеры правил там, где это уместно.

*****

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

16. Составление плана обучения нового сотрудника

Проблема:
Новый системный администратор, брошенный в бой без нормального введения в курс дела, – это источник ошибок и потенциальных инцидентов. Онбординг “смотри, как я делаю, и повторяй” работает плохо и не масштабируется.

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

Текст промпта:

*****

Ты – руководитель ИТ-отдела и опытный наставник [укажите специализацию, например, “с опытом адаптации системных администраторов в корпоративной среде”]. Твоя задача – разработать план обучения нового сотрудника.

Должность: [укажите, например, “системный администратор” или “инженер технической поддержки второй линии”].

Уровень нового сотрудника: [опишите, например, “junior с базовыми знаниями Windows Server и Active Directory, без опыта работы в корпоративной среде”].

Инфраструктура, с которой будет работать: [опишите, например, “Active Directory, Exchange Server, VMware vSphere, Zabbix, система резервного копирования Veeam”].

Срок адаптации: [укажите, например, “3 месяца до самостоятельной работы”].

Разработай план обучения:

1. Первая неделя: знакомство с инфраструктурой и процессами
2. Первый месяц: освоение основных задач под наблюдением
3. Второй месяц: самостоятельное выполнение задач с проверкой
4. Третий месяц: полная самостоятельность и оценка готовности
5. Критерии оценки готовности к самостоятельной работе
6. Типичные ошибки новичков в данной среде (что особо контролировать)

Для каждого этапа укажи: конкретные задачи, ресурсы для изучения, способ проверки знаний.

*****

Почему это работает:
Блок типичных ошибок новичков позволяет руководителю знать, где именно нужно усилить контроль в первые месяцы, – вместо того чтобы узнавать об этом после первого инцидента.

17. Проектирование системы хранения данных

Проблема:
Выбор системы хранения данных – это решение, с последствиями которого придется жить несколько лет. Ошибиться с архитектурой или производительностью на этапе проектирования дороже, чем кажется.

Решение:
Промпт помогает спроектировать систему хранения под конкретные требования с обоснованием архитектурных решений и оценкой роста.

Текст промпта:

*****

Ты – инженер по системам хранения данных [укажите специализацию, например, “с опытом проектирования СХД для корпоративных и производственных сред”]. Твоя задача – спроектировать систему хранения данных.

Требования к объему: [укажите, например, “начальный объем 50 ТБ, прогнозируемый рост 20% в год, горизонт планирования 5 лет”].

Профиль нагрузки: [опишите, например, “смешанная нагрузка: 60% случайные операции чтения/записи (базы данных 1С), 40% последовательное чтение/запись (резервные копии и архивы)”].

Требования к доступности: [укажите, например, “для баз данных – не менее 99,9% uptime, для архивов – 99%”].

Бюджет: [укажите, например, “до 3 млн рублей на первоначальное внедрение”].

Разработай проект системы хранения:

1. Рекомендуемая архитектура с обоснованием (тип СХД, протоколы подключения)
2. Конкретное оборудование, доступное на российском рынке
3. Конфигурация дисковых групп и уровни RAID с обоснованием
4. Схема резервирования и обеспечения отказоустойчивости
5. Прогноз роста емкости и точки расширения
6. Типичные ошибки при проектировании СХД данного класса

Приводи расчеты там, где это возможно. Тон – технический, с обоснованием каждого решения.

*****

Почему это работает:
Запрос прогноза роста и точек расширения переводит проектирование из режима “закрыть текущую потребность” в режим стратегического планирования – именно это отличает хорошую архитектуру от той, которую придется переделывать через два года.

18. Настройка Active Directory и групповых политик

Проблема:
Active Directory – это система, которую легко настроить “как-нибудь” и очень сложно потом привести в порядок. Групповые политики, добавлявшиеся хаотично в течение лет, превращаются в минное поле, где никто не знает, что на что влияет.

Решение:
Промпт создает структурированный подход к проектированию или ревизии Active Directory с правильной иерархией и логикой групповых политик.

Текст промпта:

*****

Ты – специалист по Microsoft Active Directory [укажите специализацию, например, “с опытом проектирования и администрирования доменных инфраструктур для предприятий от 100 до 1000 пользователей”]. Твоя задача – разработать структуру Active Directory и групповых политик.

Описание организации: [опишите, например, “производственное предприятие, 400 пользователей, 3 площадки, подразделения: производство, бухгалтерия, ИТ, руководство, склад”].

Текущая ситуация: [опишите, например, “существующий домен создан 8 лет назад, структура OU не соответствует реальной организации, групповых политик 47 штук, половина не документирована”].

Требования к безопасности: [укажите, например, “разграничение прав по подразделениям, ограничение USB-накопителей для производства и склада, централизованное управление обновлениями”].

Разработай:

1. Рекомендуемую структуру OU с обоснованием логики
2. Стратегию делегирования прав администрирования
3. Базовый набор групповых политик с назначением каждой
4. Порядок применения политик и разрешение конфликтов
5. Типичные ошибки в архитектуре AD, которые создают проблемы безопасности
6. Подход к документированию структуры и политик

Тон – технический. Приводи конкретные примеры настроек там, где это уместно.

*****

Почему это работает:
Запрос на типичные ошибки архитектуры AD, влияющие на безопасность, – это способ получить от нейросети знания, которые обычно передаются только на продвинутых курсах или после болезненного личного опыта.

19. Планирование емкости и масштабирования инфраструктуры

Проблема:
Инфраструктура, которой начинает не хватать ресурсов в самый неподходящий момент – перед отчетным периодом или в пиковый сезон – это классика жанра. Планирование емкости кажется излишеством ровно до того момента, пока не становится срочной необходимостью.

Решение:
Промпт создает модель планирования емкости на основе исторических данных и прогнозов роста с конкретными пороговыми значениями для принятия решений.

Текст промпта:

*****

Ты – инженер по планированию емкости и производительности инфраструктуры [укажите специализацию, например, “с опытом работы в средних и крупных корпоративных средах”]. Твоя задача – разработать модель планирования емкости.

Текущие ресурсы: [опишите, например, “кластер VMware: 4 хоста по 512 ГБ RAM и 40 ядер, текущее использование: RAM 65%, CPU 45%, хранилище 70% от 100 ТБ”].

Исторические данные роста: [укажите, например, “за последние 2 года потребление RAM выросло на 30%, CPU – на 20%, хранилище – на 40% в год”].

Планируемые изменения бизнеса: [опишите, например, “в следующем году планируется открытие нового филиала на 100 сотрудников и внедрение новой ERP-системы”].

Горизонт планирования: [укажите, например, “3 года”].

Разработай модель планирования:

1. Прогноз потребления ресурсов по годам (с расчетами)
2. Пороговые значения для начала планирования расширения
3. Варианты масштабирования с оценкой стоимости и сроков реализации
4. Риски недооценки роста и способы их снижения
5. Метрики, которые нужно отслеживать для актуализации прогноза
6. Шаблон отчета по планированию емкости для руководства

Приводи расчеты и конкретные числа. Тон – аналитический, с обоснованием каждого вывода.

*****

Почему это работает:
Запрос шаблона отчета для руководства – это часть, которую обычно забывают, но именно она позволяет превратить технический анализ в управленческое решение о выделении бюджета.

20. Разработка процедуры управления инцидентами

Проблема:
Когда инцидент уже происходит – не лучшее время изобретать процедуру реагирования. Отсутствие четкого порядка действий превращает технический сбой в организационный хаос.

Решение:
Промпт создает практичную процедуру управления инцидентами с четкими ролями, эскалацией и критериями приоритизации.

Текст промпта:

*****

Ты – специалист по процессам управления ИТ-услугами [укажите специализацию, например, “с опытом внедрения процессов управления инцидентами в ИТ-отделах среднего бизнеса”]. Твоя задача – разработать процедуру управления инцидентами.

Описание ИТ-команды: [опишите, например, “служба поддержки из 4 человек первой линии, 3 системных администратора второй линии, 1 руководитель ИТ-отдела”].

Критичные системы: [перечислите, например, “1С:Предприятие, корпоративная почта, система видеоконференций, файловый сервер”].

Текущая ситуация: [опишите, например, “инциденты фиксируются в общем чате, нет четкой приоритизации, часть обращений теряется”].

Разработай процедуру, включающую:

1. Классификацию инцидентов по приоритету (с критериями и примерами)
2. Матрицу эскалации (кто, когда, как)
3. Временные нормативы реагирования и решения для каждого приоритета
4. Шаблон регистрации инцидента (минимально необходимые поля)
5. Порядок коммуникации с пользователями во время инцидента
6. Процедуру закрытия инцидента и верификации решения

Процедура должна быть выполнимой с учетом размера команды. Избегай избыточной бюрократии.

*****

Почему это работает:
Указание размера команды как ограничения заставляет нейросеть проектировать реалистичную процедуру, а не идеальную модель из учебника, рассчитанную на ИТ-отдел из ста человек.

21. Написание инструкции по устранению типичных неисправностей

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

Решение:
Промпт создает набор инструкций по устранению неисправностей в формате, доступном для первой линии поддержки без глубоких технических знаний.

Текст промпта:

*****

Ты – опытный системный администратор и технический писатель [укажите специализацию, например, “с опытом разработки базы знаний для служб технической поддержки”]. Твоя задача – написать инструкцию по устранению типичных неисправностей.

Тип неисправности: [опишите, например, “пользователь не может подключиться к корпоративному VPN” или “принтер не печатает с рабочей станции под Windows 10”].

Целевая аудитория: [укажите, например, “операторы первой линии технической поддержки без глубоких технических знаний”].

Доступные инструменты: [укажите, например, “только стандартные средства Windows, удаленный рабочий стол через RDP”].

Напиши инструкцию по следующей структуре:

1. Краткое описание проблемы и ее типичные симптомы
2. Что уточнить у пользователя перед началом диагностики (чеклист вопросов)
3. Пошаговая диагностика (дерево решений: если А – делай Б, если В – делай Г)
4. Действия для каждого варианта причины
5. Когда эскалировать на вторую линию (четкие критерии)
6. Что зафиксировать в системе заявок при закрытии

Язык – простой, без технического жаргона. Каждый шаг должен быть действием, а не описанием.

*****

Почему это работает:
Формат дерева решений (“если А – делай Б”) принципиально важен: он превращает инструкцию из текста для чтения в инструмент для использования в реальном времени, когда пользователь ждет решения на другом конце провода.

22. Анализ логов для выявления аномалий

Проблема:
Логи содержат ответы на большинство вопросов о состоянии системы. Проблема в том, что их объем делает ручной анализ практически невозможным, а без правильного подхода – бесполезным.

Решение:
Промпт помогает разработать методологию анализа логов для выявления аномалий с конкретными паттернами и инструментами.

Текст промпта:

*****

Ты – инженер по анализу данных и безопасности инфраструктуры [укажите специализацию, например, “специализирующийся на анализе системных и сетевых журналов событий”]. Твоя задача – разработать подход к анализу логов для выявления аномалий.

Источники логов: [перечислите, например, “журналы событий Windows Server (Security, System, Application), логи межсетевого экрана UserGate, логи Nginx”].

Цель анализа: [укажите, например, “выявление попыток несанкционированного доступа, обнаружение аномального поведения учетных записей, поиск признаков компрометации”].

Доступные инструменты: [укажите, например, “PowerShell, встроенные средства Windows Event Viewer, возможность установки дополнительного ПО”].

Разработай методологию анализа:

1. Ключевые идентификаторы событий Windows для мониторинга безопасности (с описанием каждого)
2. Паттерны аномального поведения (что искать и почему это опасно)
3. Скрипты или команды для автоматизации сбора и фильтрации
4. Порядок приоритизации найденных аномалий
5. Признаки, которые большинство упускает при анализе логов безопасности
6. Как организовать регулярный анализ без значительных временных затрат

Приводи конкретные идентификаторы событий и примеры аномальных паттернов. Тон – технический.

*****

Почему это работает:
Запрос конкретных идентификаторов событий Windows – это то, что превращает абстрактный совет “анализируйте логи безопасности” в конкретный список того, что именно искать. Это разница между пониманием и действием.

23. Подготовка к сертификационному экзамену или технической аттестации

Проблема:
Технические знания системного инженера имеют свойство накапливаться хаотично: что-то знаешь глубоко, что-то поверхностно, а что-то – только “слышал краем уха”. Структурировать подготовку к экзамену или аттестации без четкого плана – значит готовиться неэффективно.

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

Текст промпта:

*****

Ты – опытный технический наставник и методист [укажите специализацию, например, “специализирующийся на подготовке к техническим сертификациям в области сетей и инфраструктуры”]. Твоя задача – разработать план подготовки к экзамену или аттестации.

Экзамен или аттестация: [укажите, например, “внутренняя аттестация на должность старшего системного администратора” или “сертификационный экзамен по администрированию Astra Linux”].

Текущий уровень знаний: [опишите честно, например, “3 года опыта администрирования Linux, хорошо знаю сетевые технологии, слабее – вопросы безопасности и скриптование”].

Доступное время на подготовку: [укажите, например, “2 месяца, 1–1,5 часа в день”].

Разработай план подготовки:

1. Анализ тем экзамена и их приоритизация по весу
2. Выявление вероятных пробелов на основе описанного уровня
3. Недельный план с конкретными темами и задачами
4. Ресурсы для изучения каждой темы (российские источники в приоритете)
5. Практические задания для закрепления теоретических знаний
6. Типичные ошибки при подготовке к данному типу экзамена
7. Критерии готовности к сдаче

Будь конкретным: не “изучи сети”, а “разберись с маршрутизацией OSPF на практическом стенде”.

*****

Почему это работает:
Требование конкретности (“не ‘изучи сети’, а ‘разберись с OSPF на стенде'”) программирует нейросеть выдавать задачи, которые можно выполнить, а не цели, которые можно бесконечно откладывать.

24. Разработка стратегии перехода на отечественное программное обеспечение

Проблема:
Импортозамещение в ИТ – это не просто замена логотипа на экране входа. Это проект, требующий анализа совместимости, переобучения сотрудников и тщательного планирования, чтобы не парализовать работу организации в процессе перехода.

Решение:
Промпт создает стратегию импортозамещения с анализом рисков, приоритизацией систем и реалистичным планом перехода.

Текст промпта:

*****

Ты – ИТ-стратег и системный архитектор [укажите специализацию, например, “с опытом реализации проектов импортозамещения в государственных и коммерческих организациях”]. Твоя задача – разработать стратегию перехода на отечественное программное обеспечение.

Текущий стек технологий: [перечислите, например, “Windows Server 2019, VMware vSphere 7, Microsoft Office 365, Active Directory, SQL Server 2019, 1С:Предприятие”].

Требования к импортозамещению: [укажите, например, “организация попадает под требования ФЗ-187 о критической информационной инфраструктуре, переход на отечественное ПО обязателен до конца следующего года”].

Описание организации: [опишите, например, “производственное предприятие, 500 пользователей, критичные процессы: производственное планирование, бухгалтерский учет, документооборот”].

Разработай стратегию:

1. Анализ каждой системы: риск замены, доступные отечественные альтернативы, сложность миграции
2. Приоритизация систем для замены (что менять первым и почему)
3. Поэтапный план перехода с временными рамками
4. Риски каждого этапа и меры по их снижению
5. Требования к переобучению персонала
6. Подводные камни импортозамещения, о которых редко говорят заранее

Фокус на российские решения: Astra Linux, РЕД ОС, МойОфис, Р7-Офис, Базальт СПО, Postgres Pro. Тон – стратегический, с практическими выводами.

*****

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

Типичные ошибки при использовании нейросети системным инженером

1. Описывать симптом вместо задачи. Фраза “сервер тормозит – помоги разобраться” приводит к общим советам, которые бесполезны без контекста. Нейросеть не телепат: чем точнее описана ситуация с параметрами, тем конкретнее и полезнее ответ.
2. Не указывать версии и конкретное оборудование. Совет для VMware vSphere 6.5 и vSphere 8.0 может принципиально различаться. Без версии программного обеспечения и модели оборудования нейросеть дает усредненные рекомендации, которые могут не подходить именно к вашей среде.
3. Принимать сгенерированный код без проверки. Скрипт, написанный нейросетью, может содержать ошибки, устаревшие командлеты или логические просчеты. Каждый скрипт требует тестирования в изолированной среде до применения в продуктивной.
4. Не указывать целевую аудиторию документа. Инструкция для первой линии поддержки и регламент для системного администратора – принципиально разные документы по уровню детализации и языку. Без указания аудитории нейросеть пишет “для среднего технического специалиста”, что не подходит ни тем, ни другим.
5. Игнорировать российский контекст при запросе рекомендаций. Нейросеть по умолчанию ориентируется на западный рынок и может предложить решения, недоступные или юридически проблематичные в России. Всегда уточняйте, что рекомендации должны учитывать российский рынок и действующее законодательство.
6. Задавать слишком широкий вопрос без ограничений. “Как настроить безопасность сети?” – запрос на книгу, а не на ответ. Чем больше ограничений задано (оборудование, бюджет, размер команды, срок), тем более применимым будет результат.
7. Не просить объяснить логику рекомендаций. Получить список рекомендаций – это половина пользы. Понять, почему именно такое решение, какие альтернативы существуют и при каких условиях рекомендация перестает быть верной – вот что делает ответ по-настоящему ценным.
8. Копировать конфигурационные файлы из ответа без адаптации. Конфигурация, предложенная нейросетью, – это шаблон, а не готовое решение. IP-адреса, имена хостов, пути к файлам и параметры производительности всегда требуют адаптации под конкретную среду.
9. Не уточнять запрос при неудовлетворительном первом ответе. Если первый ответ не попал в цель, большинство пользователей либо принимают его, либо начинают заново. Правильное решение – уточнить: “Ответ слишком общий. Сфокусируйся на [конкретный аспект] с учетом [ограничение]”.

Сравнение слабых и сильных формулировок запросов для системного инженера

Задача	Слабая формулировка	Сильная формулировка	Почему слабая не работает
Диагностика сбоя	Помоги найти причину падения сервера	Сервер баз данных 1С на Windows Server 2019 упал в 03:14. В логах – ошибка 1450 (недостаточно системных ресурсов). CPU 15%, RAM 4 ГБ свободно. Диск C: заполнен на 99%. Что проверить?	Без симптомов и параметров нейросеть перечисляет все возможные причины вместо конкретной диагностики
Написание скрипта	Напиши скрипт для мониторинга дисков	Напиши PowerShell-скрипт для Windows Server 2019: проверяет диски всех серверов из группы AD “Servers”, если заполненность выше 85% – отправляет письмо на адрес [адрес] через SMTP-сервер [адрес]. При недоступности сервера – запись в лог C:Logsdisk_monitor.log	Без среды выполнения, источника данных и поведения при ошибках код будет нерабочим или потребует переписывания
Проектирование сети	Как лучше настроить сеть для офиса?	Спроектируй сеть для офиса 150 человек, 3 этажа. Требования: сегментация по отделам (финансы, производство, гости), резервирование интернет-канала, централизованное управление Wi-Fi. Бюджет на активное оборудование – до 800 тыс. рублей. Оборудование – только из реестра российского ПО или с поддержкой в РФ	Без параметров масштаба, требований и ограничений ответ будет либо слишком общим, либо нереализуемым
Оценка безопасности	Проверь мою инфраструктуру на безопасность	Оцени риски безопасности: Active Directory на Windows Server 2019, VPN на MikroTik RouterOS 7.x, 80 рабочих станций Windows 10/11, антивирус Kaspersky. Известные проблемы: обновления не устанавливались 4 месяца, несколько сотрудников имеют права локального администратора. Организация обрабатывает персональные данные (ФЗ-152)	Без описания среды и известных проблем нейросеть дает универсальный список рекомендаций, не учитывающий реальную ситуацию
Создание документации	Напиши инструкцию по резервному копированию	Напиши регламент резервного копирования для аудитории: системные администраторы junior-уровня. Система: Veeam Backup 12, источники – 10 ВМ на Proxmox, хранилище – Synology DS1823xs+. Включи: расписание, порядок проверки резервных копий, действия при ошибке задания, ежемесячное тестовое восстановление	Без целевой аудитории и конкретных систем документ получается либо слишком сложным, либо слишком поверхностным
Анализ производительности	Почему медленно работает сервер?	Сервер SQL Server 2019 на Windows Server 2022, Dell R740, 256 ГБ RAM, SSD-массив. С 10:00 до 12:00 время выполнения запросов растет с 0,3 до 8 секунд. CPU не превышает 35%, RAM свободно 120 ГБ. Что проверить в первую очередь? Дай конкретные запросы к DMV для диагностики	Без параметров сервера и описания симптомов невозможно сузить область поиска до конкретных версий причин

Неочевидные советы по работе с нейросетью для системных инженеров

1. Используйте нейросеть как второго инженера при планировании изменений. Перед внедрением любого изменения опишите план и попросите найти слабые места, упущенные зависимости и сценарии, при которых план может провалиться. Это занимает 5 минут, но работает как полноценное ревью кода – только для архитектурных решений.
2. Просите нейросеть играть роль скептика, а не помощника. Вместо “как реализовать X” иногда полезнее спросить “почему реализация X может быть плохой идеей в моей ситуации”. Такой подход вытаскивает на поверхность риски, которые оптимистичный план обычно игнорирует.
3. Создавайте контекстный “паспорт инфраструктуры” для вставки в начало сложных запросов. Заранее подготовьте текстовый блок с описанием вашей среды (версии ОС, оборудование, ключевые системы, ограничения) и вставляйте его в начало запросов. Это избавляет от необходимости каждый раз объяснять контекст и повышает качество ответов.
4. Используйте нейросеть для перевода технического языка в управленческий. Написать объяснение для руководителя, почему нужно срочно обновить серверы, – задача, с которой технические специалисты справляются хуже, чем с самим обновлением. Нейросеть переводит “устаревшее ядро с незакрытыми CVE” в “конкретный финансовый и репутационный риск для бизнеса” быстро и убедительно.
5. Просите генерировать не одно решение, а три – с разными компромиссами. Формулировка “предложи три варианта решения: быстрый но дорогой, дешевый но трудоемкий, и сбалансированный” дает набор альтернатив, из которых можно выбрать подходящую под текущие ограничения. Это особенно ценно при защите решения перед руководством.
6. Используйте нейросеть для создания тестовых сценариев перед внедрением. После разработки любой процедуры или конфигурации попросите нейросеть составить список сценариев для тестирования: “что нужно проверить, чтобы убедиться, что это работает корректно”. Это выявляет граничные случаи, которые легко упустить при самостоятельном тестировании.
7. Сохраняйте удачные промпты с результатами в базу знаний отдела. Промпт, который дал качественный результат для конкретной задачи в вашей среде, – это актив. Через полгода аналогичная задача возникнет снова, и готовый промпт сэкономит время не только вам, но и коллеге, который столкнется с этим впервые.