AI-промты для поиска и исправления ошибок в коде

Роль: Ты SRE-инженер с 8 лет опыта в построении систем наблюдаемости и отладке распределённых приложений. Экспертиза: OpenTelemetry, Grafana Loki, Sentry, structured logging, correlation IDs.

Контекст: Я [роль разработчика] в [тип компании]. Сервис: [название и назначение сервиса] на [язык программирования и фреймворк]. Текущие инструменты наблюдаемости: [стек логирования и APM]. Частые инциденты: [типичный класс ошибок — например, race condition или memory leak]. Объём трафика: [RPS и SLA].

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

Формат вывода: (1) Таблица: область → текущее состояние → риск → приоритет (High/Med/Low). (2) Чек-лист из 10 пунктов по структурированным логам, корреляции и метрикам. (3) Дорожная карта внедрения на 30/60/90 дней с ответственными ролями.

Детали: Опирайся на принципы four golden signals и RED. Избегай рекомендаций, ломающих GDPR и требования [регламент безопасности]. Учитывай бюджет [месячный лимит на observability].

Роль: Ты инженер по надёжности с 7 лет опыта в разборе инцидентов и построении blameless post-mortem. Экспертиза: 5 Whys, Ishikawa, timeline reconstruction, Google SRE Workbook.

Контекст: Я [уровень разработчика] в команде [название продукта]. Инцидент: [краткое описание бага и затронутого модуля] на [язык программирования]. Длительность: [время простоя], затронутые пользователи: [процент или число]. Логи и метрики: [ключевые сигналы и ошибки]. Первичная гипотеза: [подозреваемая причина].

Задача: Подготовить структурированный post-mortem и список action items для устранения корневой причины без повторения.

Формат вывода: (1) Timeline инцидента по минутам с ролями участников. (2) Анализ 5 Whys до корневой причины. (3) Таблица action items: действие → владелец → срок → тип (detect/prevent/mitigate).

Детали: Стиль blameless, без персональных обвинений. Учитывай регламент [SLA и escalation policy]. Отметь, какие сигналы мониторинга отсутствовали и как их добавить.

Роль: Ты Principal Engineer с 12 лет опыта в рефакторинге легаси и снижении технического долга. Экспертиза: Michael Feathers 'Working Effectively with Legacy Code', strangler fig, characterisation tests.

Контекст: Я [уровень разработчика] в [тип организации]. Модуль: [название и назначение модуля] на [язык программирования], возраст [сколько лет]. Метрики: [покрытие тестами], [цикломатическая сложность], [число багов за квартал]. Бизнес-ограничения: [дедлайны и release train].

Задача: Составить пошаговый план рефакторинга, который снизит плотность ошибок и подготовит код к дальнейшему развитию без заморозки фич.

Формат вывода: (1) Матрица риск/ценность по подсистемам модуля. (2) Последовательность шагов strangler fig с точками отката. (3) Набор characterisation-тестов и метрик успеха (дефекты, MTTR, сложность).

Детали: Избегай big bang rewrite. Учитывай [текущий CI/CD pipeline] и [политику code review]. Укажи, где нужны feature flags.

Роль: Ты Tech Lead с 10 лет опыта в многопоточных и асинхронных системах. Экспертиза: Go race detector, Java jstack, ThreadSanitizer, happens-before модель памяти.

Контекст: Я [роль — лид или ментор] в команде из [число разработчиков] на [язык программирования]. Уровень команды: [преобладающий seniority]. Частая боль: [описание повторяющихся race condition-багов и затронутых сервисов]. Стек тестирования: [используемые инструменты].

Задача: Подготовить обучающий воркшоп на 2 часа по диагностике и исправлению race condition с практикой на реальном коде.

Формат вывода: (1) Структура воркшопа: таймлайн по блокам с целями обучения. (2) 5 практических кейсов с кодом до/после и ожидаемым выводом детектора. (3) Итоговый чек-лист ревью для выявления race condition в PR.

Детали: Опирайся на happens-before и memory model выбранного языка. Избегай абстрактных примеров — используй паттерны из [тип продукта, например платёжный сервис]. Учитывай [политика CI], где race detector должен запускаться.