Промпты для администратора сайта помогают быстрее разбирать сбои, готовить технические задания, проверять обновления и отвечать коллегам без многочасового блуждания по журналам событий. Здесь собраны 25 готовых запросов для повседневных задач: от поиска причин медленной загрузки до подготовки плана аварийного восстановления.
Каждый пример можно скопировать, заполнить переменные и передать нейросети. Однако важно помнить: искусственный интеллект не видит сервер, настройки и историю изменений, если Вы их не предоставили. Чем точнее исходные данные, тем меньше вероятность получить уверенный, но бесполезный ответ.
- поиск причин недоступности страниц;
- проверка скорости и нагрузки;
- разбор сообщений об ошибках;
- подготовка технических заданий;
- контроль резервного копирования;
- планирование обновлений;
- составление понятных отчетов.
Главная ценность этих заготовок не в красивых формулировках, а в ограничениях, критериях и проверяемых результатах. Без них нейросеть легко предложит "очистить память и перезагрузить сервер". Совет бессмертный, почти как очередь в техническую поддержку, но далеко не всегда полезный.
Промпты для администратора сайта: 25 рабочих заготовок
1. Поиск причины недоступности сайта
Проблема: Сайт перестал открываться, но причина может находиться на стороне домена, сервера, сертификата, базы данных или приложения. Бессистемная проверка увеличивает время простоя.
Решение: Промпт помогает построить последовательную диагностику и отделить вероятные причины от второстепенных.
Текст промпта:
*****
Ты – [укажите роль, например, "системный администратор с опытом поддержки сайтов"]. Проанализируй недоступность сайта [укажите адрес, например, "магазин.рф"]. Симптомы: [опишите проявление, например, "страница не загружается, браузер сообщает о превышении времени ожидания"]. Сбой начался [укажите время, например, "сегодня в 14:20"]. Перед этим выполнялись изменения: [перечислите действия, например, "обновление системы управления сайтом и перезапуск службы базы данных"]. Доступные сведения: [вставьте сообщения, показатели и выдержки из журналов событий]. Раздели ответ на вероятные причины, порядок безопасных проверок, признаки подтверждения каждой причины и действия после обнаружения источника сбоя. Сначала предложи проверки без изменения настроек. Не придумывай результаты команд и не советуй удалять данные. Пиши кратко, технически точно и понятно.
*****
Почему это работает: Нейросеть получает время сбоя, симптомы и историю изменений, поэтому связывает события, а не перебирает случайные советы. Требование начинать с безопасных проверок снижает риск усугубить аварию.
2. Разбор сообщения об ошибке
Проблема: Одно сообщение об ошибке часто является следствием другой неисправности. Если исправлять только видимый симптом, сбой быстро возвращается.
Решение: Запрос превращает непонятную запись из журнала событий в набор проверяемых предположений.
Текст промпта:
*****
Ты – [укажите роль, например, "специалист по диагностике веб-приложений"]. Разбери сообщение об ошибке: [вставьте точный текст, например, "не удалось установить соединение с базой данных"]. Оно появилось в [укажите источник, например, "журнале приложения"] после действия [опишите действие, например, "открытие страницы оформления заказа"]. Окружение: [укажите систему управления сайтом, версию языка программирования, тип базы данных и операционную систему]. Объясни простыми словами, что означает сообщение, какие причины являются наиболее вероятными и какие сведения нужны для проверки. Представь ответ в виде таблицы с колонками "Причина", "Почему подходит", "Как проверить", "Риск проверки" и "Что делать при подтверждении". Не выдавай предположение за установленный факт и не предлагай необратимые действия без резервной копии.
*****
Почему это работает: Контекст появления ошибки позволяет отличить первичный сбой от сопутствующей записи. Табличный формат помогает сравнивать версии по признакам, а не выбирать ту, которая звучит убедительнее.
3. Диагностика медленной загрузки
Проблема: Медленная страница может задерживаться из-за сервера, изображений, базы данных, внешних служб или неоптимального программного кода. Проверка всего сразу создает много работы и мало ясности.
Решение: Промпт распределяет причины по уровням и помогает найти самое узкое место.
Текст промпта:
*****
Ты – [укажите роль, например, "специалист по производительности сайтов"]. Проанализируй замедление страницы [укажите адрес и назначение, например, "карточка товара интернет-магазина"]. Среднее время загрузки раньше составляло [укажите значение, например, "1,8 секунды"], сейчас – [укажите значение, например, "6,4 секунды"]. Замедление наблюдается [опишите условия, например, "с 18:00 до 22:00 на мобильных устройствах"]. Доступные показатели: [укажите время ответа сервера, размер страницы, число обращений, загрузку процессора, памяти и базы данных]. Раздели анализ на сервер, базу данных, программный код, изображения, внешние службы и сеть. Для каждого уровня укажи признаки проблемы, способ измерения и ожидаемый эффект исправления. Расставь проверки по соотношению пользы и трудозатрат. Не обещай точное ускорение без замеров и не предлагай отключать защитные механизмы.
*****
Почему это работает: Сравнение показателей до и после замедления помогает искать изменившийся фактор. Разделение по уровням не позволяет свалить любую задержку на сервер, который традиционно виноват даже в плохой погоде.
4. Проверка нагрузки на сервер
Проблема: Высокая нагрузка сама по себе ничего не объясняет. Процессор может быть занят полезной обработкой запросов, ошибочным циклом, поисковым роботом или массовой выгрузкой.
Решение: Промпт помогает сопоставить нагрузку с посещаемостью, процессами и недавними изменениями.
Текст промпта:
*****
Ты – [укажите роль, например, "администратор серверов для высоконагруженных сайтов"]. Оцени причину роста нагрузки на сервер сайта [укажите тип проекта, например, "региональный новостной портал"]. Показатели за проблемный период: [укажите загрузку процессора, использование памяти, место на диске, число обращений и время ответа]. Обычные показатели: [вставьте значения для спокойного периода]. В момент роста выполнялись процессы: [перечислите наиболее ресурсоемкие процессы]. Недавние изменения: [укажите обновления, рекламные кампании, выгрузки или новые модули]. Составь три наиболее вероятных сценария, признаки каждого и безопасные способы проверки. Отдельно объясни, как отличить реальный рост аудитории от ошибочного программного процесса и автоматических обращений. Не делай вывод только по одному показателю.
*****
Почему это работает: Сопоставление текущих и обычных значений показывает отклонение, а перечень процессов раскрывает источник потребления ресурсов. Несколько сценариев защищают от поспешного вывода по одному красивому графику.
5. Анализ журналов событий
Проблема: В журнале могут находиться тысячи повторяющихся записей, среди которых действительно важны лишь несколько событий до начала сбоя. Чтение сверху вниз редко спасает рабочий день.
Решение: Запрос помогает сгруппировать записи, восстановить последовательность событий и выделить первопричину.
Текст промпта:
*****
Ты – [укажите роль, например, "специалист по расследованию технических сбоев"]. Проанализируй фрагмент журнала событий сайта: [вставьте записи без паролей, ключей доступа и персональных данных]. Известный симптом: [опишите проблему, например, "часть пользователей не может войти в личный кабинет"]. Период сбоя: [укажите время начала и окончания]. Сгруппируй одинаковые сообщения, расположи значимые события по времени и отдели причину от последствий. Выведи результат в разделах "Цепочка событий", "Вероятная первичная ошибка", "Сопутствующие записи", "Недостающие сведения" и "Безопасные проверки". Для каждого вывода процитируй запись, на которой он основан. Если данных недостаточно, прямо укажи это. Не восстанавливай и не повторяй скрытые секретные значения.
*****
Почему это работает: Временная последовательность часто показывает, какая ошибка появилась первой, а какие возникли вслед за ней. Обязательная ссылка на исходную запись уменьшает количество фантазий нейросети.
6. Проверка срока действия сертификата
Проблема: Просроченный или неправильно установленный сертификат защищенного соединения блокирует вход пользователей и может нарушить обмен данными со сторонними службами.
Решение: Промпт формирует безопасный план проверки сертификата, цепочки доверия и автоматического продления.
Текст промпта:
*****
Ты – [укажите роль, например, "специалист по защищенным соединениям сайтов"]. Подготовь диагностику сертификата для домена [укажите домен, например, "пример.рф"]. Симптом: [опишите сообщение браузера или службы, например, "соединение считается недоверенным"]. Сертификат установлен [укажите способ и дату, например, "автоматически через панель управления три месяца назад"]. У сайта есть дополнительные адреса: [перечислите поддомены, например, "магазин.пример.рф и кабинет.пример.рф"]. Составь перечень проверок срока действия, соответствия имени домена, полноты цепочки доверия, настроек перенаправления и автоматического продления. Для каждой проверки укажи ожидаемый нормальный результат и действие при отклонении. Не проси передавать закрытый ключ и не предлагай отключать проверку сертификата как постоянное решение.
*****
Почему это работает: Проверяется не только дата окончания, но и соответствие домена, цепочка доверия и продление. Именно эти детали часто упускают, после чего новый сертификат установлен, а предупреждение осталось – техника ценит драматические повороты.
7. Диагностика ошибки страницы 404
Проблема: Массовое появление несуществующих страниц ухудшает навигацию и мешает поисковым системам обходить полезные материалы. Простое перенаправление всех адресов на главную скрывает проблему, но не решает ее.
Решение: Запрос разделяет удаленные, ошибочные и измененные адреса и подбирает обработку для каждого типа.
Текст промпта:
*****
Ты – [укажите роль, например, "технический специалист по структуре сайтов"]. Проанализируй список адресов, возвращающих ошибку 404: [вставьте до 100 адресов]. Источник списка: [укажите источник, например, "Яндекс Вебмастер, внутренняя проверка или журнал обращений"]. Для каждого адреса известны переходы и посещаемость: [вставьте доступные сведения]. Раздели адреса на ошибочные ссылки, удаленные материалы, измененную структуру, обращения автоматических программ и случайные запросы. Предложи для каждой группы решение: восстановление страницы, исправление ссылки, точное перенаправление, сохранение ошибки или дополнительное наблюдение. Результат представь таблицей. Не советуй перенаправлять все отсутствующие страницы на главную и не создавай новые адреса без смыслового соответствия.
*****
Почему это работает: Разные причины ошибки требуют разных действий. Группировка не позволяет применить одно универсальное перенаправление и получить десятки страниц, которые формально работают, но ведут пользователя совсем не туда.
8. Проверка перенаправлений
Проблема: Цепочки и циклы перенаправлений замедляют открытие страниц, затрудняют обход сайта и могут оставить посетителя в бесконечном путешествии между двумя адресами.
Решение: Промпт помогает найти лишние переходы и составить карту исправлений без потери конечных страниц.
Текст промпта:
*****
Ты – [укажите роль, например, "специалист по технической структуре сайта"]. Проверь схему перенаправлений для адресов [вставьте исходные и конечные адреса]. Изменения возникли после [укажите событие, например, "переезда на новый домен или изменения каталога"]. Для каждого исходного адреса покажи всю цепочку переходов, количество промежуточных шагов, конечный результат и возможный цикл. Предложи сокращенную схему, в которой старый адрес ведет непосредственно на наиболее подходящую действующую страницу. Отдельно отметь переходы между защищенным и незащищенным соединением, вариантами домена и адресами со служебными добавлениями. Не объединяй страницы с разным смыслом и не предлагай массовое перенаправление без проверки соответствия.
*****
Почему это работает: Полная цепочка делает видимыми лишние промежуточные переходы и циклы. Проверка смыслового соответствия защищает от технически аккуратного, но бесполезного перенаправления.
9. Подготовка плана резервного копирования
Проблема: Наличие файла с названием "резервная копия" еще не означает возможность восстановить сайт. Копия может быть неполной, поврежденной или храниться на том же сервере, который вышел из строя.
Решение: Промпт формирует схему копирования с учетом частоты изменений, срока хранения и проверки восстановления.
Текст промпта:
*****
Ты – [укажите роль, например, "специалист по резервному копированию сайтов"]. Разработай требования к резервному копированию для [опишите проект, например, "интернет-магазин с 1200 заказами в сутки"]. Состав данных: [перечислите базу данных, загруженные файлы, настройки сервера, программный код и почтовые уведомления]. Допустимая потеря данных составляет [укажите период, например, "не более 15 минут"], допустимое время восстановления – [укажите срок, например, "до двух часов"]. Доступные места хранения: [перечислите варианты]. Определи частоту полных и промежуточных копий, сроки хранения, шифрование, раздельное размещение и порядок тестового восстановления. Представь результат таблицей с рисками и критериями успешной проверки. Не считай копию исправной только по факту создания файла.
*****
Почему это работает: Допустимая потеря данных и время восстановления превращают расплывчатое "делать копии регулярно" в измеримые требования. Тестовое восстановление проверяет то, ради чего копия вообще существует.
10. План восстановления после сбоя
Проблема: Во время аварии легко начать менять несколько настроек одновременно и потерять возможность понять, какое действие помогло или навредило.
Решение: Запрос создает управляемый порядок восстановления с точками остановки и возврата.
Текст промпта:
*****
Ты – [укажите роль, например, "руководитель восстановления информационных систем после аварий"]. Составь план восстановления сайта [укажите назначение, например, "сервис записи в медицинский центр"] после сбоя [опишите событие, например, "повреждение базы данных после внезапной остановки сервера"]. Доступные копии: [укажите даты, состав и результаты последних проверок]. Критически важные функции: [перечислите функции в порядке важности]. Ограничения: [укажите доступных специалистов, время и запрет на потерю определенных данных]. Раздели план на сохранение текущего состояния, временное ограничение доступа, проверку копий, восстановление, проверку целостности и возврат пользователей. Для каждого этапа укажи критерий перехода дальше и условие возврата назад. Не предлагай перезаписывать текущие данные до их отдельного сохранения.
*****
Почему это работает: Точки принятия решений не позволяют двигаться дальше при сомнительном результате. Сохранение аварийного состояния оставляет возможность расследовать причину и извлечь более свежие данные.
11. Проверка обновления перед установкой
Проблема: Обновление может закрыть уязвимость и одновременно нарушить работу дополнений, шаблона или обмена с учетной системой. Установка сразу на рабочем сайте превращает полезную процедуру в лотерею.
Решение: Промпт создает перечень рисков и сценарий предварительной проверки совместимости.
Текст промпта:
*****
Ты – [укажите роль, например, "администратор системы управления сайтом"]. Оцени подготовку к обновлению [укажите компонент, например, "основная система сайта с версии 8.2 до 8.4"]. На сайте используются [перечислите дополнения, собственные доработки, тему оформления и внешние обмены]. Критические действия пользователей: [укажите процессы, например, "оформление заказа, оплата, вход в личный кабинет"]. Доступна проверочная копия сайта: [укажите да или нет и ее отличие от рабочего сайта]. Составь перечень несовместимостей, которые нужно исключить, сценарии проверки до установки, условия отмены обновления и признаки успешного завершения. Отдельно укажи, какие сведения сохранить до начала работ. Не считай отсутствие видимой ошибки доказательством полной совместимости.
*****
Почему это работает: Проверяются пользовательские действия и внешние связи, а не только открытие главной страницы. Именно скрытые обмены обычно вспоминают последними – примерно через пять минут после звонка бухгалтерии.
12. Составление сценария проверки сайта
Проблема: После изменений администратор часто проверяет главную страницу и считает работу завершенной. Ошибки в формах, оплате, поиске и личном кабинете обнаруживают уже посетители.
Решение: Запрос формирует сценарии проверки по критическим пользовательским маршрутам.
Текст промпта:
*****
Ты – [укажите роль, например, "специалист по проверке качества сайтов"]. Составь сценарий проверки проекта [опишите сайт, например, "магазин строительных материалов с доставкой по регионам"] после изменения [укажите изменение, например, "обновление формы заказа и расчета доставки"]. Основные группы пользователей: [перечислите группы, например, "новый покупатель, постоянный клиент, сотрудник магазина"]. Критические функции: [перечислите функции]. Для каждого сценария укажи исходные условия, действия пользователя, ожидаемый результат, данные для проверки и признак сбоя. Добавь отрицательные сценарии: неверные данные, повторное нажатие, прерывание оплаты и отсутствие товара. Расставь проверки по критичности. Не ограничивайся визуальным осмотром страниц.
*****
Почему это работает: Сценарии связывают техническое изменение с реальным действием посетителя. Отрицательные проверки выявляют ошибки, которые не проявляются при идеальном и очень вежливом поведении пользователя.
13. Поиск причины ошибок формы
Проблема: Форма может сообщать об успешной отправке, хотя письмо не создано, запись не попала в базу или обращение потерялось между службами.
Решение: Промпт разбивает путь данных формы на отдельные участки и помогает найти место потери.
Текст промпта:
*****
Ты – [укажите роль, например, "специалист по обработке обращений через сайт"]. Найди вероятную причину сбоя формы [укажите форму, например, "заявка на обратный звонок"]. Пользователь видит [опишите результат, например, "сообщение об успешной отправке"], но сотрудники получают [опишите фактический результат, например, "не все заявки доходят на почту"]. Путь данных включает [перечислите этапы, например, "проверка полей, запись в базу, создание письма, отправка, доставка в ящик"]. Доступные записи: [вставьте обезличенные сведения из журналов]. Построй цепочку проверки каждого этапа, укажи контрольный признак прохождения и вероятные причины потери. Отдельно проверь повторные обращения, защиту от автоматических отправок и ограничения почтовой службы. Не проси реальные персональные данные пользователей.
*****
Почему это работает: Разделение пути заявки показывает, где именно исчезают данные. Сообщение на экране подтверждает лишь работу внешней части формы, а не доставку обращения сотруднику.
14. Проверка почтовых уведомлений
Проблема: Уведомления с сайта могут попадать в нежелательную почту, отклоняться принимающим сервером или отправляться с неверным адресом отправителя.
Решение: Запрос помогает проверить всю цепочку доставки и отличить ошибку сайта от ограничений почтовой службы.
Текст промпта:
*****
Ты – [укажите роль, например, "администратор почтовых уведомлений сайта"]. Подготовь диагностику недоставленных писем с сайта [укажите тип сообщений, например, "подтверждения заказов"]. Письма не получают [укажите получателей и частоту проблемы, например, "часть адресатов на корпоративных доменах"]. Способ отправки: [опишите способ без передачи пароля]. Доступные сведения: [вставьте код ответа почтовой службы, время отправки, адрес отправителя и обезличенный заголовок сообщения]. Раздели причины на создание письма, передачу почтовой службе, проверку домена отправителя, ограничения получателя и попадание в нежелательную почту. Для каждого этапа укажи проверку и доказательство успешного прохождения. Не советуй массово повторять отправку до выяснения причины.
*****
Почему это работает: Диагностика рассматривает доставку как цепочку подтверждений. Это предотвращает многократную отправку писем, которая иногда превращает техническую ошибку еще и в репутационную.
15. Анализ подозрительного роста обращений
Проблема: Резкий рост запросов может означать удачную рекламу, активность поисковых систем, автоматический сбор данных или попытку перегрузки сайта.
Решение: Промпт помогает классифицировать источники обращений и выбрать меры без блокировки обычных посетителей.
Текст промпта:
*****
Ты – [укажите роль, например, "специалист по защите и анализу посещаемости сайтов"]. Проанализируй резкий рост обращений к сайту [укажите тип проекта]. Рост начался [укажите время] и составил [укажите обычное и текущее количество обращений]. Чаще всего запрашиваются страницы [перечислите адреса или разделы]. Источники, регионы, программы посетителей и частота повторов: [вставьте обезличенную сводку]. Сопоставь признаки реальных пользователей, поисковых роботов, сбора данных и намеренной перегрузки. Для каждого варианта укажи подтверждающие признаки, дополнительные измерения и безопасную реакцию. Предложи ограничения, которые учитывают частоту, поведение и тип страницы, а не только сетевой адрес. Не советуй блокировать целые регионы без доказательств.
*****
Почему это работает: Поведение посетителя информативнее одного адреса соединения. Ограничение по совокупности признаков снижает риск закрыть сайт для добросовестных клиентов вместе с нарушителями.
16. Проверка прав доступа
Проблема: Избыточные права позволяют случайно изменить или удалить важные данные, а недостаточные мешают работе сотрудников и вызывают обходные решения.
Решение: Запрос помогает сопоставить обязанности пользователей с минимально необходимыми разрешениями.
Текст промпта:
*****
Ты – [укажите роль, например, "специалист по управлению доступом к сайту"]. Проверь распределение прав для [опишите проект, например, "сайт образовательного центра"]. Роли пользователей: [перечислите роли, например, "редактор, оператор заявок, бухгалтер, разработчик"]. Рабочие обязанности каждой роли: [опишите задачи]. Текущие разрешения: [перечислите доступные разделы и действия]. Выяви избыточные, недостающие и конфликтующие права. Представь результат таблицей "Роль", "Необходимые действия", "Лишние разрешения", "Недостающие разрешения", "Риск" и "Предлагаемое изменение". Отдельно отметь общие учетные записи и доступ бывших сотрудников. Не предлагай выдавать полные права ради удобства.
*****
Почему это работает: Права оцениваются через реальные обязанности, а не название должности. Это выявляет ситуации, когда редактор незаметно получил возможность менять системные настройки просто потому, что так было быстрее.
17. Подготовка технического задания разработчику
Проблема: Формулировка "исправить форму, она иногда не работает" заставляет разработчика сначала угадывать условия сбоя. Время уходит на переписку, а результат трудно принять.
Решение: Промпт превращает наблюдение администратора в проверяемое техническое задание.
Текст промпта:
*****
Ты – [укажите роль, например, "технический постановщик задач для разработчиков сайтов"]. Составь техническое задание по проблеме [опишите наблюдаемое поведение, например, "при повторной оплате заказ получает неверное состояние"]. Условия воспроизведения: [укажите устройство, роль пользователя, данные заказа и последовательность действий]. Фактический результат: [опишите результат]. Ожидаемый результат: [опишите правильное поведение]. Известные ограничения: [перечислите связанные службы, сроки и запреты]. Оформи документ в разделах "Цель", "Исходное поведение", "Условия воспроизведения", "Требуемое изменение", "Границы задачи", "Критерии приемки", "Риски" и "Сценарии проверки". Не предлагай способ программной реализации, если для него нет достаточных технических данных.
*****
Почему это работает: Разделение фактического и ожидаемого результата устраняет двусмысленность. Критерии приемки позволяют проверить исправление, а не обсуждать, стало ли "вроде лучше".
18. Подготовка отчета о сбое
Проблема: Технический отчет часто превращается в длинную хронологию действий без ответа на три вопроса: что произошло, почему и как избежать повторения.
Решение: Запрос формирует понятный отчет для руководителя, разработчиков и службы поддержки.
Текст промпта:
*****
Ты – [укажите роль, например, "специалист по разбору последствий технических происшествий"]. Подготовь отчет о сбое сайта на основе данных: [вставьте хронологию, симптомы, действия специалистов и результаты проверок]. Сбой продолжался [укажите период], затронул [укажите функции и группы пользователей], последствия составили [укажите измеримые потери, например, "не оформлено около 80 заказов"]. Раздели отчет на краткое резюме, влияние на пользователей, временную последовательность, подтвержденную причину, сопутствующие факторы, восстановление и меры против повторения. Отдели факты от предположений. Для каждой предупредительной меры укажи ответственного, срок и проверяемый результат. Тон должен быть спокойным и деловым, без поиска виноватых и сокрытия ошибок.
*****
Почему это работает: Отделение фактов от предположений не позволяет превратить отчет в удобную легенду. Ответственные лица и сроки переводят выводы из жанра "учтем в будущем" в рабочие обязательства.
19. План переноса сайта
Проблема: При переносе легко забыть о фоновых заданиях, почтовых уведомлениях, дополнительных доменах, правах на файлы и внешних обменах.
Решение: Промпт помогает учесть зависимости и заранее определить условия возврата на прежнюю площадку.
Текст промпта:
*****
Ты – [укажите роль, например, "специалист по переносу сайтов между серверами"]. Подготовь план переноса [опишите сайт, объем файлов и размер базы данных] с [укажите текущую площадку] на [укажите новую площадку]. Зависимости проекта: [перечислите домены, почту, фоновые задания, внешние службы, обмен с 1С и хранилища файлов]. Допустимый перерыв составляет [укажите время]. Доступна предварительная синхронизация: [укажите да или нет]. Раздели план на обследование, подготовку новой среды, пробный перенос, окончательную синхронизацию, переключение, проверку и наблюдение. Для каждого этапа укажи критерий успеха, риск и условие возврата. Не предлагай менять доменные настройки до проверки сайта на новой площадке.
*****
Почему это работает: Зависимости рассматриваются до переключения посетителей, а не после первых жалоб. Условие возврата особенно важно: оптимизм полезен, но рабочая возможность отступить обычно полезнее.
20. Проверка доменных настроек
Проблема: Ошибка в доменных записях может сделать сайт недоступным только для части пользователей, поэтому проверка с одного устройства создает ложное ощущение исправности.
Решение: Промпт формирует проверку записей, сроков обновления и согласованности разных источников.
Текст промпта:
*****
Ты – [укажите роль, например, "администратор доменных имен"]. Проанализируй проблему домена [укажите домен, например, "пример.рф"]. Симптомы: [опишите, например, "у части пользователей открывается старый сервер"]. Изменения были внесены [укажите время и измененные записи]. Текущие значения у регистратора: [вставьте обезличенные данные], ожидаемые значения: [укажите правильные данные]. Объясни, какие записи влияют на сайт, почту и подтверждение владения. Составь порядок проверки у разных источников, учти время распространения изменений и сохраненные старые ответы. Укажи признаки обычного ожидания и признаки ошибочной настройки. Не советуй многократно менять записи до завершения установленного периода обновления.
*****
Почему это работает: Доменные изменения распространяются не мгновенно, поэтому повторное редактирование способно только усложнить картину. Сравнение нескольких источников показывает, является ли расхождение временным или постоянным.
21. Проверка базы данных
Проблема: Замедление базы данных может быть связано с тяжелыми запросами, блокировками, нехваткой памяти или ростом отдельных таблиц. Без измерений "оптимизация" рискует стать опасной уборкой наугад.
Решение: Запрос помогает выбрать безопасные проверки и определить данные, необходимые специалисту по базе.
Текст промпта:
*****
Ты – [укажите роль, например, "администратор баз данных для сайтов"]. Подготовь анализ замедления базы данных проекта [опишите назначение сайта]. Симптомы: [укажите медленные операции, время появления и частоту]. Доступные показатели: [укажите размер базы, крупнейшие таблицы, число соединений, длительные запросы, блокировки и использование памяти]. Недавние изменения: [перечислите обновления, импорт данных или рост посещаемости]. Раздели возможные причины на запросы, индексы, блокировки, настройки, объем данных и ограничения сервера. Для каждой причины укажи подтверждающий показатель и безопасную проверку. Расставь действия по риску. Не предлагай удаление таблиц, массовое изменение данных или перестроение структуры без проверенной копии и плана возврата.
*****
Почему это работает: Причины связываются с измеримыми показателями, поэтому рекомендации можно проверить. Ограничение на опасные операции защищает от ситуации, когда ускорение достигается самым радикальным способом – исчезновением данных.
22. Анализ места на диске
Проблема: Диск может заполниться журналами, временными файлами, копиями, изображениями или выгрузками. Удаление крупнейшей папки без понимания ее назначения способно остановить сайт.
Решение: Промпт помогает классифицировать потребителей места и выбрать безопасный способ очистки.
Текст промпта:
*****
Ты – [укажите роль, например, "администратор серверного хранилища сайта"]. Проанализируй нехватку места на диске. Общий объем составляет [укажите значение], свободно [укажите значение]. Крупнейшие каталоги и файлы: [вставьте список с размерами и датами изменения]. На сервере размещены [перечислите сайты, базы данных, журналы событий, резервные копии и временные файлы]. Раздели объекты на рабочие данные, временные данные, журналы, копии и неизвестные файлы. Для каждой группы укажи, что можно архивировать, перенести, ограничить по сроку хранения или удалить после проверки. Предложи способ найти источник постоянного роста. Не советуй удалять неизвестный файл только из-за большого размера.
*****
Почему это работает: Размер сопоставляется с назначением и датой изменения. Поиск источника роста устраняет причину, иначе свободное место закончится снова – обычно в пятницу вечером, когда инфраструктура особенно любит внимание.
23. Настройка наблюдения за доступностью
Проблема: Проверка только главной страницы не обнаруживает сбой оформления заказа, входа в кабинет или соединения с базой данных.
Решение: Запрос помогает определить многоуровневые проверки и полезные условия оповещения.
Текст промпта:
*****
Ты – [укажите роль, например, "специалист по наблюдению за работой сайтов"]. Разработай схему наблюдения для [опишите проект, например, "служба доставки еды в трех городах"]. Критические функции: [перечислите страницы и действия, например, "открытие меню, добавление блюда, расчет доставки, оформление заказа"]. Допустимая задержка обнаружения сбоя: [укажите время]. Доступные каналы оповещения: [перечислите, например, "почта и сообщения в российском служебном приложении"]. Предложи проверки доступности, времени ответа, содержимого страницы, срока сертификата, свободного места и выполнения ключевых действий. Для каждой проверки укажи частоту, порог тревоги, повторное подтверждение и получателя уведомления. Исключи оповещения по одиночному кратковременному отклонению, если оно не влияет на пользователей.
*****
Почему это работает: Проверяются бизнес-функции, а не только ответ сервера. Повторное подтверждение снижает шум, из-за которого настоящие предупреждения со временем начинают восприниматься как фон.
24. Подготовка регламента плановых работ
Проблема: Плановые работы без точных границ легко затягиваются, а пользователи и коллеги не понимают, когда сервис вернется и что именно будет недоступно.
Решение: Промпт формирует регламент с ответственными, контрольными точками и правилами прекращения работ.
Текст промпта:
*****
Ты – [укажите роль, например, "координатор плановых технических работ на сайте"]. Подготовь регламент работ [укажите задачу, например, "обновление системы управления сайтом и базы данных"]. Окно работ: [укажите дату и время]. Ожидаемая недоступность: [укажите продолжительность и функции]. Участники: [перечислите роли и зоны ответственности]. Риски: [укажите известные риски]. Раздели регламент на подготовку, уведомление пользователей, создание проверенной копии, выполнение изменений, промежуточные проверки, окончательную приемку и наблюдение. Для каждого этапа укажи ответственного, ожидаемый результат и предел времени. Добавь условия остановки и возврата к прежней версии. Не допускай продолжения работ после истечения окна без отдельного решения ответственного лица.
*****
Почему это работает: Предел времени и условия остановки не позволяют незаметно превратить плановые работы в затяжную аварию. Распределение ответственности устраняет любимую должность любого сбоя – "кто-нибудь должен был проверить".
25. Составление ежемесячного отчета администратора
Проблема: Перечень выполненных действий не показывает состояние сайта и влияние работы администратора. Руководителю важны изменения рисков, доступности и производительности.
Решение: Промпт превращает технические данные в краткий отчет с измеримыми выводами и приоритетами.
Текст промпта:
*****
Ты – [укажите роль, например, "руководитель эксплуатации интернет-проектов"]. Подготовь ежемесячный отчет администратора сайта за [укажите период, например, "февраль 2026 года"]. Исходные данные: [вставьте сведения о доступности, сбоях, скорости, обновлениях, копиях, обращениях пользователей, месте на диске и работах подрядчиков]. Сравни показатели с [укажите предыдущий период или установленную норму]. Представь отчет в разделах "Краткий итог", "Изменение ключевых показателей", "Сбои и причины", "Выполненные работы", "Неустраненные риски" и "Приоритеты следующего периода". Для каждого риска укажи вероятность, последствия и крайний срок решения. Не заполняй отсутствующие показатели вымышленными значениями и не перегружай отчет техническими подробностями без влияния на работу сайта.
*****
Почему это работает: Сравнение с прошлым периодом показывает направление изменений, а не набор разрозненных цифр. Привязка технических событий к последствиям делает отчет полезным для принятия решений.
Типичные ошибки при использовании запросов для нейросети
- 1. Передавать нейросети сообщение "сайт не работает" без времени, симптомов и истории изменений. Такая формулировка не позволяет отличить ошибку домена от сбоя приложения, поэтому ответ будет состоять из общих предположений.
- 2. Вставлять в запрос пароли, закрытые ключи, полные журналы с персональными данными и сведения о доступе. Для диагностики обычно достаточно обезличенных фрагментов, кодов ошибок и временных отметок.
- 3. Просить назвать одну точную причину при недостатке сведений. Нейросеть может выбрать правдоподобную версию и изложить ее уверенно, хотя доказательств для такого вывода нет.
- 4. Выполнять сразу все предложенные изменения. Если после пяти одновременных действий сайт заработает, определить полезное изменение будет невозможно, а скрытая проблема может остаться.
- 5. Копировать команды и настройки без проверки соответствия своей системе. Различия в версиях, правах, расположении файлов и устройстве сервера способны превратить безопасный пример в источник нового сбоя.
- 6. Не указывать нормальные показатели для сравнения. Значение нагрузки или времени ответа становится полезным только рядом с обычным уровнем, периодом измерения и условиями работы.
- 7. Считать объяснение нейросети доказательством причины. Любая версия должна подтверждаться журналом событий, измерением, воспроизведением ошибки или результатом отдельной проверки.
- 8. Использовать один и тот же запрос для аварии, планового изменения и отчета. Эти задачи требуют разных ограничений: при аварии важна безопасность, при изменении – критерии приемки, а в отчете – влияние на пользователей.
Точные формулировки для сложных задач администратора
| Расплывчатый запрос | Что в нем потеряно | Точная формулировка |
| Почему сайт тормозит? | Нет периода, страницы, обычных значений и условий возникновения задержки. | Сравни время ответа карточки товара с 18:00 до 22:00 за последние семь дней с обычным уровнем и выдели причины, подтверждаемые показателями сервера и базы данных. |
| Как почистить сервер? | Неизвестны назначение файлов, источник роста и допустимость удаления. | Раздели крупнейшие каталоги по назначению, отметь безопасные способы освобождения места и укажи, какие данные нельзя удалять без отдельной копии. |
| Проверь резервную копию. | Не определено, что считать исправной копией и какой результат восстановления требуется. | Оцени состав копии, дату, размер и журнал создания, затем составь проверку восстановления базы, файлов и настроек в отдельной среде. |
| Сделай сайт безопаснее. | Нет границ проверки, модели угроз и приоритета рисков. | Проанализируй права сотрудников, открытые служебные разделы, устаревшие компоненты и защиту форм, затем ранжируй риски по вероятности и последствиям. |
| Исправь ошибки 404. | Не различаются удаленные страницы, ошибочные ссылки и автоматические обращения. | Сгруппируй отсутствующие адреса по источнику и посещаемости, затем выбери для каждой группы восстановление, исправление ссылки, точное перенаправление или сохранение ошибки. |
| Подготовь перенос сайта. | Не учтены зависимости, допустимый перерыв и возможность возврата. | Составь план переноса файлов, базы, домена, почты, фоновых заданий и внешних обменов с критериями проверки и условиями возврата на старый сервер. |
| Разбери журнал ошибок. | Нет симптома, времени сбоя и требования подтвердить выводы исходными записями. | Восстанови последовательность событий за десять минут до сбоя, сгруппируй повторы и процитируй записи, подтверждающие вероятную первичную ошибку. |
| Напиши отчет о работе. | Перечень действий не показывает изменение состояния проекта. | Сравни доступность, скорость, число сбоев и состояние резервных копий с прошлым месяцем, затем укажи неустраненные риски и сроки решения. |
Советы по работе с готовыми промптами
- 1. Сохраняйте вместе с удачным запросом обезличенный пример хорошего результата. Через месяц формулировка может выглядеть понятной, но именно образец покажет, какие глубина, структура и доказательства ожидались от нейросети.
- 2. Разделяйте исходные данные на подтвержденные факты и предположения сотрудников. Если смешать их в одном абзаце, нейросеть может принять догадку за установленное обстоятельство и построить на ней весь анализ.
- 3. Добавляйте к каждому техническому совету требование указать риск и способ возврата. Это особенно важно для обновлений, переноса, очистки диска и изменения базы данных, где полезное действие может иметь необратимые последствия.
- 4. Просите назвать сведения, которых не хватает для уверенного вывода. Качественный ответ не обязан немедленно выдавать причину; иногда его главная польза заключается в точном перечне следующих измерений.
- 5. Проверяйте один вывод одним отдельным действием. Последовательная диагностика сохраняет причинно-следственную связь и позволяет остановиться сразу после подтверждения источника проблемы.
- 6. Удаляйте из журналов событий не только пароли, но и адреса почты, телефоны, номера заказов, служебные ключи и значения сеансов. Для анализа обычно достаточно времени, типа события, кода ошибки и обезличенного обозначения пользователя.
- 7. Используйте промпты для администратора сайта как средство подготовки решения, а не как разрешение выполнять изменения автоматически. Итоговый шаг должен подтверждаться измерениями, документацией используемой системы, проверенной резервной копией и возможностью безопасного возврата.
