Промпт-инжиниринг больше не в моде. Что делать вместо него?

Буквально позавчера мы рассказывали вам, как создать идеальный промпт для ИИ. Тем временем топовые эксперты по ИИ говорят: важен не только запрос, а весь контекст вокруг него. Первым про контекст-инжиниринг заговорил CEO Spotify, и дальше эту машину уже было не остановить.

Чем отличается промпт-инжиниринг от контекст-инжиниринга?

🔵 Промпт-инжиниринг — это когда вы ювелирно формулируете один запрос.
🔵 Контекст-инжиниринг — это управление всей беседой: предыстория, тон, примеры ответов, скрытые правила.

Как это работает?

1️⃣ Память диалога — ИИ учитывает предыдущие сообщения, а не только последний промпт.
2️⃣ Примеры в контексте — вместо «пиши как Хемингуэй» можно вставить реальный отрывок его текста и сказать: «Вот так надо».
3️⃣ Невидимые инструкции — можно заранее загрузить в чат правила («Избегай клише», «Ссылайся на научные статьи»).

❌ «Напиши Terraform конфиг для AWS» → получите generic-шаблон, который придётся переделывать
✅ Контекстный подход:

1. «Вот наш стандартный шаблон модуля VPC»
2. «Нужно аналогичное решение для GCP с такими требованиями:
- Поддержка Shared VPC
- Логирование flow-логов в BigQuery
- Firewall rules по принципу least privilege»
3. «Используй только ресурсы google_compute_ без deprecated-параметров»

➡️ На выходе получите готовый к использованию конфиг, соответствующий вашим стандартам

Значит ли это, что качественные промпты больше не нужны? Скорее нет, чем да. Сочетание подходов дает возможность получить наиболее четкий результат и сделать ИИ своим постоянным помощником.

Узнать больше про использование ИИ для решения рабочих задач — на воркшопе «AI в DevOps» 5 июля.

Throttling: механизм защиты сервисов от перегрузки

В современном цифровом мире, где сервисы обрабатывают миллионы запросов ежесекундно, критически важно обеспечивать их стабильную работу.

➡️ Одним из ключевых механизмов защиты от перегрузки является throttling (троттлинг) — технология регулирования нагрузки на систему.

В статье рассказываем, почему throttling — не просто инструмент, а необходимость для современных высоконагруженных систем и как он позволяет сохранять работоспособность сервиса даже в условиях экстремальной нагрузки.

⭐️ Читать в блоге Слёрма

Как пайплайны спасают бизнес?

Многие думают, что CI/CD нужен только для ускорения выпуска фич. На самом деле, правильно настроенные пайплайны предотвращают критические ошибки, экономят сотни часов разработки и защищают продакшен от падений.

Рассмотрим 3 реальные ситуации, где CI/CD спасает проект

1️⃣ Человеческий фактор: забытые файлы и сломанный прод

🔹 Что происходит:

Разработчик вручную выкатывает хотфикс, но забывает скопировать статические файлы или обновить зависимости. Прод падает, пользователи видят ошибки, команда в панике ищет причину.

🟢 Как CI/CD решает проблему:

Билды собираются автоматически и одинаково каждый раз
Никаких «забыл добавить файл» — если сборка прошла в CI, она гарантированно рабочая
Rollback на предыдущую версию занимает секунды

2️⃣ Ночные сборки: рутина, которая съедает время

🔹 Что происходит:

Менеджер просит делать nightly-билды для тестирования. Разработчики собирают их вручную, тратят время, иногда что-то упускают. В итоге — нестабильные сборки и лишние часы работы.

🟢 Как CI/CD решает проблему:

Настроенный cron-триггер запускает сборки по расписанию
Пайплайн всегда работает одинаково, без «ой, я забыл включить эту опцию»
Можно сразу развернуть тестовое окружение и отправить отчёт

3️⃣ Новый разработчик + staging = катастрофа?

🔹 Что происходит:

Новичок в команде пытается развернуть staging, но неправильно настраивает окружение. Всё ломается, тестировщики не могут работать, дедлайны срываются.

🟢 Как CI/CD решает проблему:

Staging автоматически разворачивается из ветки
Окружения изолированы и создаются по шаблону
Если что-то пошло не так — можно быстро откатиться.


▶️На CI/CD-практикуме мы разберём, как строить пайплайны, которые:

✅ Запускают тесты перед каждым деплоем
✅ Умеют откатываться при проблемах
✅ Работают с переменными окружения и секретами
✅ Экономят десятки часов ручной работы

Ознакомиться с программой и присоединиться к обучению — на сайте.

В какую ловушку попадает инженер?

Всё просто: вы так хороши в написании кода, что компания не видит смысла ставить вас на другую позицию. Зачем что-то менять, если вы быстро пишете код и всем хорошо? Всем, кроме вас.

Потому что наступает момент, когда рост зависит не от скорости кодирования, а от качества принимаемых решений.

❔ Почему одна система легко масштабируется, а другая трещит по швам при росте нагрузки в 2 раза?
❔ Как сделать так, чтобы добавление новой фичи ускоряло команду, а не замедляло ее вдвое из-за сложной архитектуры?
❔ Как объяснить бизнесу, почему на рефакторинг нужно потратить 3 месяца, и доказать, что это окупится?

➡️ Ответы на эти вопросы лежат в плоскости архитектуры приложений. Переход от мышления кодом к мышлению компонентами, связями, потоками данных и компромиссами (trade-offs) — это и есть ваш step forward.

Именно этому мы и учим на курсе «Архитектура приложений»:

🔵 анализировать требования и ограничения, выявлять то, что действительно важно для бизнеса;

🔵 владеть архитектурными паттернами, понимать, когда нужны микросервисы, когда — событийно-ориентированная архитектура, а когда старый добрый монолит;

🔵 проектировать потоки данных, осознанно выбирать между SQL/NoSQL, Kafka/RabbitMQ, понимать принципы кеширования и репликации;

🔵 защищать свои решения, использовать C4 Model и ADRs, чтобы делать свои идеи понятными и для инженеров, и для менеджеров.

Наш курс не про изучение ещё одного фреймворка (хотя их мы тоже даём). Это про базовые знания, которые позволят вам проектировать надёжные, гибкие и эффективные системы на любой технологии.

🪤 Если вы чувствуете, что застряли в ловушке собственной суперспособности, посмотрите программу курса. Возможно, это именно тот шаг, который вам нужен, чтобы пробить стеклянный потолок.

SRE: когда надёжность становится дорогой ошибкой?

Поговорим об этом 9 июля, в 17:00 МСК на заключительной встрече в рамках проекта по FinOps.

Разберём кейс — как не допустить избыточной работы SRE, и обсудим:

⚫️ как гонка за 100% uptime съедает бюджет;
⚫️ почему стремление к 100% аптайму может навредить бизнесу;
⚫️ как SRE помогает найти баланс между стабильностью и развитием.

Спикер: Кирилл Борисов, SRE-инженер в VK.

⏩ Занять место и получить ссылку на вебинар — в боте-помощнике.

«AI в DevOps» — воркшоп уже завтра!

Вместе с Виктором Чаплыгиным вы:

✨ Настроите локальную среду разработки для продуктивной работы с AI-помощниками — включая конфигурацию подключения, поддержку контекста и оформление подсказок в формате Markdown

✨ Создадите или адаптируете Ansible-роль для настройки инфраструктурного компонента, протестировав результат с мастер-узла

✨ Разработаете или улучшите Helm-чарт, с возможностью последующего деплоя в кластер Kubernetes

✨ Используете AI для анализа ошибочных YAML-манифестов и предложений по их исправлению

✨ Пройдёте мини-челлендж: получите задание с описанием, сгенерируете решения, сравните промпты между собой, доработаете результат и представите его

Начало завтра в 11:00. Занять место на воркшопе ➡️ по ссылке. 

Почему полезно читать постмортемы по утрам

Чтобы стать действительно крутым инженером, недостаточно просто знать, как строить большие системы. Нужно понимать, как они ломаются. В этом смысле публичные постмортемы лучшее, что случилось с интернетом с точки зрения профессионального роста.

Пример подобного постмортема:

🔆 SNAT нам все сломал, или сначала нужно проверить на staging (подробнее — тут).

⚫️ Ключевой симптом: Все сетевое взаимодействие внутри кластера работало, а все запросы наружу из кластера не работали должным образом.

❓ Что пошло не так:

Проблема заключалась в механизме SNAT, реализованном в AWS VPC CNI плагине. По умолчанию, при отправке трафика из подов на адреса за пределами VPC, CNI плагин выполняет SNAT, заменяя исходный IP-адрес пода на основной IP-адрес сетевого интерфейса ноды. Поскольку нужно было обращаться в другой VPC, SNAT приводил к сбоям в сетевом взаимодействии. Включение параметра AWS_VPC_K8S_CNI_EXTERNALSNAT=true отключило этот механизм, позволив трафику из подов выходить напрямую без трансляции, что решило проблему.

‼️ Что следовало сделать по-другому:

Тестирование в staging-среде: перед развертыванием изменений в production необходимо проводить обширное тестирование в изолированной среде, имитирующей production, чтобы выявить потенциальные проблемы.

Больше публичных постмортемов можно найти на этом ресурсе.

⏩ Учиться на чужих ошибках здорово и весело.

В этом смысле публичные постмортемы лучшее, что случилось с интернетом с точки зрения профессионального роста. А ещё классно учиться на курсе «Kubernetes База» — там есть стенды для практики, поэтому даже если система сломается, продакшен не пострадает.

«AI в DevOps» — старт через 2 часа

Делимся с вами подробным расписанием сегодняшнего воркшопа.

⚡️ Остались последние два места на тарифе «Стандарт», специально для тех, кто заработался и все пропустил.

Запрыгнуть в последний вагон — по ссылке.

Отпуск ≠ стоп развитию

Специально для тех, кто хочет провести лето с пользой, мы запустили летнюю распродажу, от которой тают даже DevOps’ы!

🔅 -50% на видеокурсы
🔆 Учёба в комфортном темпе
❣️ Сертификация в конце обучения

Среди курсов — Kafka для разработчиков и аналитиков, DevOps Tools для разработчиков, Мониторинг в Grafana и много других актуальных программ.

Забрать скидку 50% по промокоду LETO2025 ⏩ на сайте

Если пайплайн всегда зелёный — это ещё не значит, что он эффективный.

На что смотрит опытный тимлид:

❗️ Где узкие места?

⚫️ Долгий docker build (15+ минут)?
⚫️ Тесты, которые можно распараллелить?
⚫️ Лишние шаги, тормозящие delivery?

❗️ Как устроены стадии?

⚫️ Сборка и деплой должны быть отделены.
⚫️ Есть ли промежуточные проверки (линтеры, security-сканы)?
⚫️ Можно ли запустить тесты без полного прогона пайплайна?

❗️ Где спрятаны риски?

⚫️ Переменные окружения и секреты не хардкодятся.
⚫️ Есть ли откат (rollback), если деплой сломает prod?
⚫️ А если сломается сам CI (например, кончились лимиты runner'ов)?

❗️ Как сделать пайплайн поддерживаемым?

⚫️ Шаги можно переиспользовать (templates, shared steps).
⚫️ Конфиги читаемы, а не «магия из 1000 строк YAML».
⚫️ Новый разработчик сможет разобраться без месячного онбординга.

⭐️ На CI/CD-практикуме разберём подходы и архитектуру пайплайна — как сделать его поддерживаемым, а процесс — быстрым и предсказуемым.

Старт 21 июля. Подробности — на сайте.

Я сисадмин и у меня... зависимость. У меня слишком много зависимостей.

Если вы хоть раз сталкивались с Dependanсy hell, то знаете, сколько времени можно потерять, разбираясь с версиями библиотек и подбирая нужную.

Забыть про конфликт зависимостей и научиться развёртывать приложения за секунды можно на курсе «Docker для админов и разработчиков». Стартуем через 2 недели!

Покажем, как:

✔️ упаковывать приложения в изолированные контейнеры;
✔️ автоматизировать рутину и CI/CD;
✔️ создавать масштабируемые микросервисы;
✔️ обеспечивать безопасность ваших контейнеров;
✔️ выжимать максимум из ресурсов.

Формат: видеоматериалы, практика на виртуальных стендах, челлендж, обратная связь от экспертов-практиков. Всё лучшее, чтобы запустить ваши навыки в космос.

⚡️ Стать ближе к DevOps-карьере и забронировать место на курсе — по ссылке.