Шаблони промптів для налагодження виробничих проблем

Використовуйте ШІ для налагодження у виробничому середовищі як робочий процес від доказів до перевірки: збирайте факти, формуйте гіпотези, перевіряйте їх, вносьте найменше підтверджене виправлення та безпечно перевіряйте результат. Не просіть асистента виправити робочу проблему за розмитим симптомом і не застосовуйте результат сліпо.

Шаблони нижче зберігають розслідування обґрунтованим. Вилучайте секрети, токени доступу, персональні дані та ідентифікатори клієнтів перед передаванням журналів або трасувань.

Послідовність налагодження у виробничому середовищі

докази -> гіпотези -> перевірка -> найменше виправлення -> валідація

Кожен промпт має містити очікувану поведінку, спостережувану поведінку, середовище, відомості для відтворення, відповідні нещодавні зміни та безпечну межу запитуваної роботи.

Шаблон: початкове сортування інциденту

Нам потрібно дослідити проблему у виробничому середовищі. Поки що не пропонуйте зміну коду.

Симптоми: [Що показують користувачі або моніторинг.]
Очікувана поведінка: [Що має відбуватися.]
Спостережувана поведінка: [Що відбувається насправді.]
Вплив: [Кого зачіпає, частота, серйозність і безпечний резервний шлях, якщо відомий.]
Середовище: [Версія, розгортання, браузер/ОС, регіон, прапорці функцій або
деталі середовища виконання.]
Нещодавні зміни: [Відповідні розгортання, міграції, конфігурація або залежності.]
Докази: [Очищені журнали, помилки, метрики, ID трасувань, знімки екрана, команди.]
Відтворення: [Надійні кроки або вкажіть, що проблема періодична.]

Поверніть:
1. стислу часову шкалу підтверджених фактів;
2. основні гіпотези, упорядковані за ймовірністю та впливом;
3. наступне безпечне спостереження або крок відтворення для кожної гіпотези;
4. будь-які відсутні відомості, що суттєво блокують діагностику.

Це дає асистенту достатньо матеріалу для міркування, не створюючи вигляду, ніби він має доступ до ваших виробничих систем.

Шаблон: відтворіть до виправлення

Спробуйте відтворити цю проблему локально або в затвердженому невиробничому
середовищі.

Очікуване: [Очікуваний результат.]
Спостережуване: [Фактичний результат.]
Налаштування: [Фікстура, стан облікового запису, команда, конфігурація або тестові дані.]
Нещодавня зміна для дослідження: [Коміт, випуск або зміна поведінки.]

Не редагуйте виробничий код, доки збій не буде відтворено або ми не матимемо
пояснення, заснованого на доказах, чому відтворення неможливе. Зафіксуйте найменший
тест, що падає, послідовність журналів або вивід команди, які розрізняють
провідні гіпотези.

Якщо відтворення неможливе, вкажіть невизначеність і порекомендуйте безпечне інструментування або рішення про відкат, а не спекулятивний патч коду.

Шаблон: аналіз очищених журналів

Проаналізуйте ці очищені журнали для виробничого збою.

Контекст: [Сервіс/функція та очікуваний потік запиту.]
Часове вікно: [Початок/кінець і часовий пояс.]
Очікувана поведінка: [Очікуваний шлях успіху.]
Спостережувана поведінка: [Помилка або погіршена поведінка.]
Нещодавні зміни: [Зміни розгортання/конфігурації/залежностей.]
Журнали: [Очищені записи в хронологічному порядку.]

Відокремте факти від висновків. Пов’язуйте події лише там, де ID, часові мітки або
причинні докази це підтверджують. Перелічіть правдоподібні гіпотези, журнал або метрику,
що підтвердить кожну з них, і наступне спостереження з найменшим ризиком.

Не дозволяйте асистенту вважати сусідні часові мітки доказом причинності.

Шаблон: дослідження збою команди або скрипту

Дослідіть, чому ця команда обслуговування у виробничому середовищі завершилася невдачею.

Команда: [Точна команда з вилученими секретами.]
Очікуваний вивід: [Очікуваний сигнал успіху.]
Спостережуваний вивід: [Точні очищені stderr/stdout і код виходу.]
Середовище: [Оболонка, робочий каталог, версія ОС/середовища виконання, відповідні файли.]
Нещодавні зміни: [Зміни скрипту або розгортання.]

Спершу поясніть, що команда насправді робить, і визначте найраніший крок збою.
Запропонуйте безпечні діагностичні команди, які не змінюють дані. Лише після
розуміння збою запропонуйте найменше виправлення та спосіб перевірити його у
невиробничому середовищі.

Для збоїв у терміналі точні введення та виведення часто цінніші за прозовий підсумок.

Шаблон: дослідження регресії після розгортання

Оцініть, чи пов’язана ця регресія з нещодавнім розгортанням.

Базове значення: [Поведінка/версія до розгортання.]
Зміна: [Реліз, прапорець, міграція або відмінність конфігурації.]
Спостережувана регресія: [Кого зачіпає та як.]
Докази: [Метрики, журнали, трасування, знімки екрана або відтворення.]
Обмеження: Не змінюйте розгортання й не мігруйте дані, доки докази не
підтримають рішення. Збережіть шлях відкату.

Порівняйте базовий і змінений шляхи. Визначте найменший експеримент,
перевірку прапорця функції або невиробничий тест, який може підтвердити причинність.
Порекомендуйте відкат, пом’якшення або дослідження коду з рівнем упевненості та
компромісами для кожного.

Правильною відповіддю може бути відкат або налаштування прапорця функції, а не зміна коду.

Шаблон: запит на безпечне виправлення

Використовуйте це лише після того, як докази підтверджують причину:

Підтверджена причина: [Першопричина, підтверджена доказами.]
Межі завдання: [Файли, модуль або конфігурація для зміни.]
Поведінка, яку слід зберегти: [Наявний шлях успіху, публічний контракт, дозволи,
дані, локаль, продуктивність або поведінка відкату.]

Запропонуйте найменше виправлення. Додайте:
- чому воно усуває підтверджену причину;
- регресійний тест або відтворювану перевірку;
- перевірку в затвердженому невиробничому середовищі;
- міркування щодо розгортання, моніторингу та відкату;
- поведінку, що лишається невизначеною.

Не додавайте до цієї зміни не пов’язаний із завданням рефакторинг.

Промпт не дає реальному інциденту перетворитися на нагоду для переписування, яке неможливо перевірити.

Шаблон: перевірка після виправлення

Перевірте виправлення щодо початкового інциденту.

Перевірте:
1. початкове відтворення або тест, що падав, тепер проходить;
2. звичайний шлях успіху лишається без змін;
3. відповідні шляхи помилок і крайні випадки й далі поводяться безпечно;
4. сигнали розгортання або моніторингу показують очікуване відновлення;
5. умова відкату лишається доступною.

Наведіть докази для кожної перевірки та явно назвіть усе, що не було перевірено.

Перевірка має відповідати на початкове питання інциденту, а не лише підтверджувати, що новий шлях коду виконався.

Використовуйте ШІ як дисциплінованого дослідника

ШІ може допомогти організувати докази, генерувати гіпотези, пояснювати незнайомий код і пропонувати тести. Він не може замінити контроль доступу, володіння інцидентом, захист виробничого середовища або людське рев’ю.

Почніть із матеріалу як писати кращі промпти для ШІ, щоб отримати загальну структуру. Використовуйте помилки ШІ-асистентів для програмування та як їх уникати, щоб розпізнати небезпечні скорочення, а шаблони промптів для рефакторингу коду — лише після розуміння інциденту.

Якщо докази містять команди оболонки, безпечно відтворіть робочий процес до його зміни. Практикуйте сценарії командного рядка в браузері, щоб виробити звичку перевіряти введення, виведення та сигнали збою.