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