Карго-культ DevOps: чек-лист самопроверки
Карго-культ DevOps: чек-лист самопроверки
«Я управляю оркестром» В прошлой статье я говорил о том (Методология Projex), что суть Projex — не в создании процесса ради процесса, а в адаптации этого процесса под людей. Но для начала давайте разберемся: что вообще такое процесс? Вот как его описывает Википедия (Wiki): повторяемая последовательность действий, направленная на достижение поставленной цели. Определений много, но […]
Привет, Хаброжители! Сегодня мы хотим рассказать вам побольше о новом предзаказе: «Метрики программной архитектуры. Кейсы, повышающие качество ПО». Это не монография, а сборник из десяти самостоятельных глав от десяти архитекторов (Форд, Фарли, Лилиенталь, Вудс, Роза и другие), объединённых темой измерения качества архитектуры. Единой теории в книге нет, но есть рабочий код, формулы и параметры оценки, […]
Предыстория В данный момент я работаю над проектом ServeHub-2
Привет, меня зовут Дарья, я ИТ-бизнес-партнёр в БКС Банке. Часто при внедрении ИИ возникает вопрос: а нужно ли сначала стандартизировать процессы? Какой эффект это даст? В моей статье ниже мы подробно разберем, почему при отсутствии единых правил агент вынужден восстанавливать контекст, а не контролировать результат. На примере агента, анализирующего квартальную отчётность, мы убедимся: хаотичная декомпозиция […]
Хочу рассказать вам историю об одной хронической проблеме у каждого хостинга.
В работе с AI‑кодерами постепенно меняется формат задачи. Одного промпта часто недостаточно: агенту нужно не только выполнить разовую команду, но и повторять действия до понятного результата. Например: проверить CI, прочитать лог, внести минимальное исправление, снова запустить тест, остановиться при выполнении условий.
Несколько месяцев назад в публичном пространстве появилась история, которую в engineering-сообществе стали называть поучительной. Команда AWS использовала внутренний AI-инструмент Kira для ускорения работы. Kira предложила джуниорам сценарий: переразверни продакшн-слой. Инженеры согласились. Следующие шесть часов весь AWS не работал. После разбора полётов компания объявила новое правило: финальный апрув на изменения, предложенные агентом, должен давать сениор-инженер.
После большого падения собрали постмортем. Красивый: таймлайн поминутно, five whys, список action items, ответственные напротив каждого пункта, всё разослали по всем спискам рассылки. Команда поскорбела, поучилась на ошибках, разошлась с чувством выполненного долга. Через полгода — то же падение. По той же причине. Открываем тот постмортем. А там — те же action items. Все до […]