AI по делу: как отличить must-have от маркетинговой наклейки

Сейчас AI добавляют почти везде.

🔮 AI-поиск.
🔮 AI-ассистент.
🔮 AI-аналитика.
🔮 AI-генератор.
🔮 AI-рекомендации.
🔮 AI-что-нибудь-еще.

Иногда это действительно сильная фича.
А иногда - обычная кнопка с модным названием.

Главный вопрос не в том, есть ли в продукте AI
❓Главный вопрос - какую реальную проблему он решает.

AI - это must-have, если он:

🚀 Экономит время на повторяющихся задачах. Например, помогает быстрее разбирать заявки, документы, логи, резюме, тикеты или обращения клиентов.

🏰 Работает с большим объёмом информации. Там, где человеку сложно быстро найти нужное, сравнить, обобщить или заметить закономерность.

✅ Улучшает качество решения. Не просто генерирует текст, а помогает снизить ошибки, подсветить риски, найти пропущенные детали.

🦩 Встроен в процесс, а не живёт отдельной игрушкой. Хороший AI не заставляет пользователя менять привычный workflow. Он аккуратно ускоряет его внутри уже существующей работы.

А вот AI как маркетинговый ход обычно выглядит иначе:

🚫 непонятно, что именно он улучшает;
🚫 результат нельзя измерить;
🚫 пользователь всё равно перепроверяет всё вручную;
🚫 фича добавлена, потому что у конкурентов есть;
🚫 без AI продукт работал бы почти так же.

👌 Простой тест: если убрать AI из продукта и ценность почти не изменится - скорее всего, это наклейка.
Если убрать AI и процесс сразу станет дольше, дороже или неудобнее - это уже реальная польза.

AI сам по себе не делает продукт современным. Современным продукт делает не технология, а точное понимание боли пользователя.

👎 Поэтому зрелый вопрос звучит не так: где нам добавить AI?
👍 А так: где у пользователя слишком много рутины, данных, ошибок или ожидания - и может ли AI реально это сократить?

Вот там AI становится не хайпом, а инструментом.

🤖 Codex vs Claude Code: что выбрать разработчику

Сравнивать Codex и Claude Code в формате кто умнее - не совсем правильно.

🔥 В разработке важнее другой вопрос: какой инструмент лучше подходит под вашу задачу?

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

Он удобен, когда хочется не просто "поговорить с AI", а дать ему конкретную инженерную задачу.

Claude Code сильнее ощущается там, где нужно глубже разобраться в кодовой базе: понять архитектуру, объяснить сложный модуль, найти причину бага, аккуратно отрефакторить легаси.

Он хорош, когда задача требует больше контекста, рассуждения и осторожности.

🚨 Главный вывод:

Codex - для быстрого выполнения задач.
Claude Code - для глубокого погружения в код.

Но ни один из них не отменяет ревью.

AI может написать код, предложить решение и даже запустить тесты.
Но ответственность за merge всё равно остаётся у человека.

Самый честный способ выбрать инструмент - протестировать оба на своих задачах:

🔘 небольшой баг;
🔘 простая фича;
🔘 тесты;
🔘 рефакторинг;
🔘 разбор сложного модуля.

И смотреть не на то, кто звучит увереннее, а на результат:

✅ понял ли инструмент контекст,
✅ не добавил ли лишнего,
✅ сохранил ли стиль проекта,
✅ написал ли осмысленные тесты,
✅ сколько пришлось исправлять руками.

В 2026 году вопрос уже не в том, нужен ли разработчику AI-инструмент.

❓ Вопрос в том, какой из них лучше вписывается в ваш workflow.

📱 Пароли уходят. Но не так быстро, как хотелось бы

Мы привыкли думать, что главная проблема паролей - их забывают.

На самом деле хуже другое:
⚡️ их воруют, переиспользуют, сливают, подбирают и вводят на фишинговых сайтах.

Поэтому всё больше сервисов двигаются в сторону passkeys - входа без привычного пароля.

📌 Идея простая: вместо того чтобы помнить секретную строку, пользователь подтверждает вход через устройство - например, отпечатком, Face ID или PIN-кодом.

Для пользователя это выглядит проще.
Для продукта - безопаснее.

🛜 Почему это важно для IT-команд?

Потому что авторизация - это не просто "экран входа".
Это точка, где встречаются безопасность, UX и доверие.

🚩 Но есть нюанс: passkeys не стоит внедрять "ради моды"

Перед этим нужно подумать:

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

🎙 Итог: будущее без паролей уже близко, но хороший login - это не только технология.
Это сценарий, в котором пользователю безопасно, понятно и не страшно потерять доступ к своему аккаунту.

Расширение браузера - это не просто кнопка рядом с адресной строкой

Мы часто ставим расширения почти не думая.

✅ Скриншоты удобнее делать.
✅ Переводить страницы быстрее.
✅ Пароли подставляются сами.
✅ AI-помощник всегда под рукой.

🚩 Но у браузерного расширения может быть доступ к гораздо большему, чем кажется: вкладкам, страницам, данным, cookies, истории, введённому тексту или содержимому сайтов.

И проблема не только во вредоносных расширениях.

🚨 Даже нормальное расширение может стать риском, если его забросили, продали другому владельцу или взломали аккаунт разработчика.

Простой чек перед установкой:

❓ точно ли оно нужно;
❓ кто разработчик;
❓ когда было обновление;
❓ какие разрешения запрашивает;
❓ можно ли обойтись без него.

📌 Помни!

Расширение - это маленькое приложение внутри самого чувствительного места: вашего браузера.

🔥 А значит, чем меньше случайных расширений - тем меньше невидимых рисков.

Ваши данные в облаке. Но чьём именно?

Раньше облачный сервис выбирали по трём критериям:

🔘 цена;
🔘 скорость;
🔘 удобство.

Теперь всё чаще появляется четвёртый:

▫️ кто на самом деле контролирует инфраструктуру и данные?

Отсюда растущий интерес к digital sovereignty - цифровому суверенитету.

Это не означает "отказаться от всего иностранного".
Речь о более практичных вопросах:

📎 в какой стране хранятся данные;
📎 каким законам подчиняется провайдер;
📎 можно ли перенести систему в другое облако;
📎 что произойдёт при блокировке сервиса;
📎 насколько бизнес зависит от одного поставщика.

Для разработчиков это тоже важно.

Vendor lock-in часто начинается незаметно: с удобной авторизации, очереди, базы или serverless-функции. А через несколько лет оказывается, что миграция стоит дороже самой разработки.

☀️ Важно!

Хорошая архитектура сегодня - это не только масштабируемость.

Это ещё и возможность сохранить контроль: над данными, инфраструктурой и правом выбрать другого поставщика.

🌧️ Облако должно давать свободу. А не превращаться в очень удобную клетку.

Упс! AI внезапно сделал технический долг проблемой бизнеса

Последние годы компании запускали чат-ботов, покупали AI-лицензии и проводили пилоты.

А теперь выясняется неприятное: AI не может нормально автоматизировать процессы, которых не понимает сама компания.

Если данные разбросаны по таблицам, системы не интегрированы, документация устарела, а важные операции держатся на знаниях нескольких сотрудников - агент не решит проблему(

Он просто начнёт ошибаться быстрее.

Поэтому один из главных IT-трендов 2026 года - не очередная модель, а модернизация фундамента:

⚙️ обновление legacy-систем;
🗂 объединение и очистка данных;
🔧создание стабильных API и интеграций;
📝 формализация процессов и правил;
🔐 настройка доступов, контроля и аудита действий AI.

Крупные IT-компании уже отмечают переход от отдельных AI-экспериментов к большим программам модернизации: бизнес понимает, что без качественных данных и совместимых систем масштабировать AI невозможно.

Что это меняет для специалистов?

📺 Разработчикам становится важнее понимать архитектуру целиком, а не только писать отдельные функции.
🔗 Аналитикам - уметь превращать размытые процессы в понятные правила и данные.
🛜 DevOps и platform-командам - строить безопасную среду, где агенты могут работать без доступа «ко всему сразу».
🥇 Менеджерам - оценивать не количество AI-пилотов, а их влияние на скорость, качество и стоимость процессов.

При этом роль разработчика уже смещается от простого написания кода к постановке задач, проверке и исправлению результата AI. Исследования последних месяцев называют это supervisory engineering - инженерной работой через управление и контроль.

Компании, которые хотят внедрять AI всерьёз, вынуждены сначала сделать то, что откладывали годами:

⚡️ разобрать технический долг;
⚡️ привести в порядок данные;
⚡️ описать процессы;
⚡️ определить ответственность.

🚨 AI оказался не волшебной кнопкой.

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

Делимся секретом быстрых команд: они не работают быстрее - они меньше переделывают

Есть миф, что самые продуктивные команды просто быстрее пишут код.

На практике всё часто наоборот.

Сильные команды тратят больше времени до начала разработки, чтобы потом не терять его на переделки.

Они:

⚡️ Уточняют задачу до старта. Не начинают делать “примерно понятно”. Они выясняют: что именно нужно решить и зачем.

🚀 Думают о последствиях. Не выбирают первое рабочее решение, если через месяц оно создаст новый слой проблем.

🔥 Проверяют раньше. Тесты, ревью и обратная связь появляются не в конце, когда уже дорого что-то менять.

👍 Фиксируют знания. Хорошая документация экономит десятки часов вопросов и повторных разборов.

Главный враг скорости - не медленный разработчик.

А цикл: сделали → поняли, что не то → переделали → снова изменили → потеряли время.

Поэтому иногда команда, которая долго думает, выпускает результат быстрее той, которая сразу бросается писать код.

💯 Настоящая скорость в разработке - это не количество строк в день.
Это количество полезных изменений, которые не пришлось потом отменять.

Самые быстрые команды не бегут быстрее. Они просто реже возвращаются назад.

❓А вы знали, что ваш код может быть безопасным, а продукт - нет?

Современное приложение редко состоит только из кода вашей команды. Внутри - библиотеки, npm-пакеты, контейнеры, SDK, плагины, GitHub Actions и ещё десятки компонентов, которые написал кто-то другой.

💣И это создаёт новую проблему: атаковать компанию можно, вообще не атакуя её код напрямую.

Достаточно скомпрометировать одну зависимость, аккаунт мейнтейнера или элемент build-процесса.

Поэтому в 2026 всё больше внимания получает software supply chain security - безопасность всей цепочки, через которую код попадает в продукт.

🏆Один из инструментов здесь - SBOM (Software Bill of Materials).

Если очень просто, это «состав продукта»:

🔖 какие компоненты используются;
🔖 какие у них версии;
🔖 от чего они зависят;
🔖 где появилась уязвимость.

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

👎Вместо: "кажется, мы используем эту библиотеку где-то…"
👍команда может быстро понять, какие продукты действительно затронуты.

💀 Но одного SBOM недостаточно.

Зрелая защита начинается ещё раньше:

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

Главный сдвиг достаточно простой:

🌵раньше безопасность спрашивала: "Есть ли уязвимость в нашем коде?"

Теперь вопрос шире:

📺 "Можем ли мы доверять всему, из чего собран наш продукт?"

💎 Потому что иногда самое слабое место - это код, который ваша команда вообще не писала.

📌 Квантовых компьютеров ещё нет. Почему IT уже меняет шифрование?

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

Но индустрия решила не ждать.

👑 Причина - стратегия Harvest Now, Decrypt Later.

Представьте: злоумышленник перехватывает зашифрованные данные сегодня. Расшифровать их он пока не может - поэтому просто сохраняет.

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

И если это пароль от давно закрытого аккаунта - не страшно.

Но если внутри:

⚡️ финансовые данные;
⚡️ медицинская информация;
⚡️ криптографические ключи;
⚡️ коммерческие секреты;
⚡️ документы, которые должны оставаться конфиденциальными десятилетиями.

Тогда проблема уже не выглядит такой далёкой.

💣 Поэтому появляется PQC - Post-Quantum Cryptography: алгоритмы, рассчитанные на защиту и от классических, и от будущих квантовых атак.

Причём переход - это не просто: старый алгоритм → новый алгоритм

Компаниям сначала приходится выяснить, а где вообще используется криптография: TLS, сертификаты, VPN, подписи, библиотеки, устройства, внутренние сервисы.

И вот здесь начинается самое интересное.

💯 Главный тренд - crypto agility.

Системы стоит проектировать так, чтобы криптографические алгоритмы можно было менять без переписывания половины инфраструктуры.

Потому что хороший security-подход - это не попытка угадать, а какой алгоритм проживёт следующие 20 лет?

Это способность заменить его, когда мир снова изменится.

🔥 Квантовая угроза может быть проблемой будущего.
Но архитектуру под это будущее приходится строить уже сегодня.

WebAssembly выходит из браузера. Docker пора волноваться? 👀

Долгое время Wasm ассоциировался примерно с одним: «Запустим почти нативный код прямо в браузере».

Но в 2026 году Wasm всё интереснее выглядит уже на сервере.

Почему?

📦 Компактность. Wasm-модуль может быть значительно легче полноценного контейнера.

✈️ Быстрый запуск. Это особенно интересно для serverless и edge-задач, где приложение должно стартовать практически мгновенно.

🔒 Изоляция. Код выполняется внутри sandbox с явно заданными возможностями — полезно, например, когда нужно безопасно запускать сторонние плагины.

🔫 Портируемость. Идея простая: собрали компонент один раз → запускаем его в разных совместимых средах.

А в 2026 появился ещё один важный кусочек пазла - WASI 0.3 с нативной поддержкой асинхронных операций.

То есть WebAssembly постепенно превращается из «технологии для браузера» в более универсальный runtime.

Но значит ли это, что пора удалять Docker?

Нет 👎

Контейнеры остаются универсальнее и обладают огромной зрелой экосистемой. Wasm сейчас особенно интересен там, где критичны быстрый старт, небольшой размер, sandboxing и запуск на edge.

💡 Поэтому интереснее другой сценарий: не Wasm vs Docker, а Wasm + containers.

Тяжёлый сервис живёт в контейнере.
Небольшая функция или плагин - в Wasm.

И инфраструктура выбирается уже не по принципу «мы всё запускаем одинаково», а под конкретную нагрузку.

🪩 WebAssembly в 2026 - хороший пример технологии, которая тихо переросла собственное первоначальное предназначение.
И именно за такими технологиями обычно интереснее всего наблюдать.

А что, если интернет снова станет необязательным?

За последние годы мы привыкли к странной норме:
нет интернета → приложение почти бесполезно.

👎 Документ не открывается.
👎 Задача не сохраняется.
👎 Интерфейс показывает вечный спиннер.

Но в разработке снова набирает популярность подход local-first.

💣 Его идея простая: сначала данные живут и меняются на устройстве пользователя, а облако отвечает за синхронизацию.

То есть приложение реагирует мгновенно, продолжает работать без сети, а изменения отправляются на сервер позже.

Звучит как старый добрый desktop?

Не совсем.

⚡️ Главная сложность начинается, когда один документ изменили одновременно на ноутбуке, телефоне и компьютере коллеги.

Кто прав?

📌 Именно поэтому вокруг local-first активно развиваются sync engines и CRDT - технологии, которые помогают синхронизировать параллельные изменения без привычного «последний сохранивший победил».

Почему подход снова интересен:

▫️ Скорость - чтение и запись происходят локально.

▫️ Offline перестаёт быть аварийным режимом - продукт продолжает работать.

▫️ Контроль над данными - локальная копия не зависит полностью от доступности облака.

▫️ Коллаборация - несколько устройств могут работать с данными и синхронизироваться позже.

Но бесплатной магии здесь нет.

🪄 Вместо обычного: клиент → API → база

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

Поэтому local-first нужен далеко не каждому интернет-магазину или лендингу.

💯 Зато для заметок, таск-трекеров, редакторов, полевых приложений и collaborative-инструментов идея выглядит всё интереснее.

🔥 Последние 15 лет индустрия училась переносить всё в облако.
Теперь появляется более интересный вопрос: а действительно ли пользователь должен ждать сервер для каждого действия?

⚡️ Пароль, похоже, всё-таки умирает. На этот раз всерьёз

Мы хороним пароли примерно столько же, сколько JavaScript.
Но сейчас у passwordless наконец появились весомые аргументы.

🔥 В августе WebAuthn Level 3 стал официальным стандартом W3C, а количество используемых passkeys в мире оценивают уже примерно в 5 млрд.

То есть passkey - это уже не экспериментальная кнопка рядом с обычным логином.

📎 Но что там вообще происходит?

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

⭐️ приватный остаётся у пользователя;

⭐️ публичный получает сервис.

При входе сервис отправляет запрос, устройство подписывает его приватным ключом - после Face ID, отпечатка, PIN или другого локального подтверждения и сервер проверяет подпись.

🚫 Пароля, который можно выманить на фишинговой странице, в этой схеме просто нет.

И вот это уже интересно.

🔘 Обычный MFA защищает пароль вторым фактором. Но если первый фактор всё ещё можно украсть, атакующий продолжает пытаться обмануть пользователя.
🔘 Passkey меняет саму механику входа.

🚩 При этом есть нюанс, о котором говорят реже.

Добавить кнопку “Войти с passkey” - лёгкая часть.

Дальше начинаются настоящие продуктовые вопросы:

❓ что делать, если человек потерял устройство?
❓ как устроить восстановление аккаунта и не превратить его в дыру?
❓ как мигрировать существующих пользователей?
❓ как работать с несколькими устройствами?
❓ когда оставить пароль как fallback и не обнулить этим преимущества новой схемы?

Поэтому переход на passkeys - это не только задача security-команды.
Это ещё backend, frontend, UX и нормальная работа с identity lifecycle.

🔖 И статистика здесь показательная: по данным FIDO, 82% опрошенных организаций уже достигли passwordless или называют полный отказ от паролей своей целью.

Похоже, вопрос постепенно меняется.

👎 Уже не «нужны ли нам passkeys?»
👍 А «почему мы всё ещё просим пользователя придумать пароль с большой буквой, цифрой и специальным символом?»

🌵 Кажется, мы немного переборщили с "разработчик должен понимать инфраструктуру"

Открываешь вакансию backend-разработчика, а там кроме языка и фреймворка: Docker, Kubernetes, Helm, Terraform, Kafka, Prometheus, Grafana, CI/CD, облака, секреты, сети...

И желательно ещё понимать, почему вчера упал прод.

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

🔖 Отсюда один из заметных инфраструктурных трендов сейчас - снижение cognitive load разработчика.

Не научить каждого инженера ещё большему количеству инструментов, а сделать так, чтобы часть этих инструментов ему вообще не требовалось трогать.

📎 Например, разработчику нужно развернуть новый сервис. Можно выдать ему документацию на 80 страниц, Terraform, Helm chart и ссылку на Kubernetes.

🔥 А можно дать готовый golden path: создал сервис → выбрал нужные параметры → получил окружение, CI/CD, мониторинг и базовые security-настройки.

Под капотом всё ещё Kubernetes, Terraform и десяток других технологий. Просто теперь знать устройство каждой из них должен не каждый человек в каждой продуктовой команде.

🛜 И вот здесь меняется смысл platform engineering.

👍 Хорошая внутренняя платформа - это не портал, куда собрали все DevOps-инструменты компании.

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

Нормальный критерий гораздо проще: сколько решений человеку приходится принимать, чтобы доставить изменение в production?

✈️ И здесь есть важный баланс.

Спрятать вообще всё тоже плохая идея. Когда абстракция ломается, инженеру всё равно нужно понимать, что происходит под капотом.

Поэтому хороший golden path это не клетка.

🔘 Для типовой задачи есть простой безопасный маршрут.
🔘 Для нетиповой - возможность выйти за его пределы.

И, кажется, это довольно здоровый поворот для индустрии.

⚡️ Мы долго добавляли инструменты, чтобы решить сложность разработки.
Теперь приходится добавлять инженерную работу, чтобы разработчики эту сложность не видели.

🔥 Самая опасная строчка в проекте может быть той, которую вы вообще не писали

npm install

Выглядит безобидно.
📎 Нашёл библиотеку. Посмотрел документацию. Установил. Через пять минут уже используешь.
Только вместе с одной библиотекой в проект иногда приезжают десятки других пакетов, которые она тянет за собой.

💯 И вот тут начинается интересное.

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

👑 Мы доверяем его зависимостям, аккаунту мейнтейнера, registry, CI/CD-процессу и тому, что в очередном обновлении никто не подменил содержимое.

Поэтому supply chain security сейчас всё меньше похожа на паранойю безопасников и всё больше - на обычную инженерную гигиену.

Что можно сделать без отдельного security-отдела:

✅ не обновлять зависимости вслепую;
✅ смотреть, что именно изменилось в новой версии;
✅ фиксировать версии там, где это оправдано;
✅ не хранить долгоживущие publish-токены, если можно использовать OIDC;
✅ регулярно удалять зависимости, которыми проект уже не пользуется;
✅ проверять не только прямые, но и транзитивные зависимости.

🚩 И ещё одна простая привычка: перед установкой очередного пакета спросить себя - он нам вообще нужен?
Иногда ради функции, которую можно написать за 15 строк, в проект добавляется библиотека с целым деревом зависимостей.

Удобство получаем сразу.

🪙 Стоимость этой зависимости - обновления, уязвимости, breaking changes и ещё один кусочек чужой инфраструктуры - приезжает позже.

👌 Поэтому хороший dependency management сегодня - это не "Dependabot когда-нибудь пришлёт PR".
Это понимание того, какой чужой код вы пустили внутрь продукта и зачем он там находится.

Кажется очевидным.

🤡 До первого пакета, которому вы доверяли пять лет.

🚨 ТЫ СЕГОДНЯ ON-CALL

Прод работает. Пользователи недовольны. Твои действия?

Представь: четверг, 16:47. До конца рабочего дня совсем немного.

В чат поддержки начинают приходить жалобы: оформление заказа занимает по 10–15 секунд.

Открываешь мониторинг:

✅ Серверы доступны

✅ CPU - 34%

✅ Ошибок 5xx почти нет

✅ База данных отвечает

🚫 Но p95 latency выросла с 300 мс до 8 секунд

И самое неприятное: последний релиз был три часа назад. До этого жалоб не было.

Что проверишь первым?

А. Откатишь последний релиз. Совпадение подозрительное, рисковать не хочется.

Б. Посмотришь distributed traces и выяснишь, на каком участке запроса возникла задержка.

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

Г. Проверишь медленные запросы к БД. Скорее всего, проблема там.

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

Условия: инцидент учебный, цифры условные. Цель - выбрать первое диагностическое действие, а не угадать причину по четырём метрикам.

🚨 ТЫ СЕГОДНЯ ON-CALL | РАЗБОР ИНЦИДЕНТА #1

Все метрики зелёные. Пользователи ждут по 15 секунд. Что пошло не так?

В прошлой части мы оставили вас с неприятной ситуацией:

✅ CPU — 34%
✅ ошибок 5xx почти нет
✅ база данных отвечает
✅ p95 latency выросла с 300 мс до 8 секунд
✅ три часа назад был релиз

И предложили четыре варианта: откатить релиз, проверить traces, добавить реплики или искать проблему в БД.

Наш выбор - Б. Посмотреть distributed traces.

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

В нашем учебном кейсе предположим, что критического отказа нет, а трассировка уже настроена.

👍 Что ищем в первую очередь?

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

Допустим, один запрос выглядит так:

<escape></escape>
POST /checkout 8 200 мс
├─ Проверка корзины 120 мс
├─ Расчёт стоимости 180 мс
├─ Запрос к платёжному API 7 600 мс
└─ Остальная обработка 300 мс
<escape></escape>

(Цифры условные, это иллюстрация возможной трассировки)

❓ Вот теперь у нас появилась гипотеза: задержка связана с обращением к платёжному сервису.

Но даже это ещё не доказательство причины. Нужно проверить, что происходит внутри этого вызова: ожидание сети, повторные запросы, таймауты или замедление самого провайдера.

Почему остальные варианты не обязательно помогут?

А. Откатить релиз.
Вполне разумно, если есть признаки регрессии и откат безопасен. Но сам факт недавнего релиза ещё не доказывает его вину.

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

Г. Проверить БД.
Тоже нормальная гипотеза. Но «база отвечает» не означает, что каждый SQL-запрос быстрый. Без дополнительных данных мы просто выбираем подозреваемого наугад.

🔥 А теперь главное: почему мониторинг был зелёным?

Потому что доступность сервиса и скорость пользовательского сценария - разные вещи.

HTTP 200 говорит, что запрос завершился успешно. Но если оформление заказа заняло 15 секунд, пользователю от этого не легче.

Поэтому зрелый мониторинг смотрит не только на CPU и количество ошибок, но и на:

→ Latency - сколько времени реально ждут пользователи, особенно на p95/p99.

→ Traffic - сколько запросов приходит и как меняется нагрузка.

→ Errors - не только HTTP 5xx, но и ошибки бизнес-операций.

→ Saturation - очереди, лимиты соединений, исчерпание ресурсов.

Это четыре золотых сигнала мониторинга из практики SRE.

Вывод из инцидента

✈️ Зелёный дашборд не гарантирует здоровый продукт. Он показывает лишь то, что вы решили измерять.
И если мониторинг не видит, что пользователи не могут нормально оформить заказ, возможно, проблема не только в сервисе.

👌 Возможно, проблема ещё и в самом мониторинге.

🐴 HTTP/3 уже здесь. Почему сайты всё ещё тормозят?

В октябре вышло любопытное исследование: среди почти 783 тысяч популярных сайтов 21,6% загружали главную страницу по HTTP/3.

При этом 40,4% сайтов заявляли о поддержке протокола.

Разница приличная. Но ещё интереснее другое: HTTP/3 сам по себе не гарантирует быстрый сайт.

✅ Разбираемся, где здесь маркетинг, а где реальная польза.

🔮 МИФ №1. HTTP/3 - это просто более быстрый HTTP/2

Не совсем.
HTTP/3 работает поверх QUIC, который использует UDP вместо TCP.

💯 Одно из главных преимуществ - устранение блокировки независимых потоков из-за потери TCP-пакета.

Представьте: у пользователя нестабильный мобильный интернет. Один пакет потерялся.

🔘 В HTTP/2 это может задержать передачу данных других потоков в том же TCP-соединении.
🔘 В HTTP/3 независимые потоки QUIC не обязаны ждать восстановления потерянных данных соседнего потока.

🔮 МИФ №2. Включил HTTP/3 - ускорил сайт

Было бы удобно.
Но если страница загружает 8 МБ JavaScript, изображения без оптимизации и десяток сторонних скриптов, новый протокол не исправит эти проблемы.

По данным октябрьского исследования PageSpeed Matters, среди изученных сайтов с данными CrUX проверку Core Web Vitals проходили:

• HTTP/3 - 39,1%
• HTTP/2 - 43,5%
• HTTP/1.1 - 44,8%

Нет, это не значит, что HTTP/1.1 быстрее. Группы сайтов отличаются, поэтому сравнивать эти проценты как результат эксперимента нельзя.

👌 Зато это хорошее напоминание: производительность продукта не сводится к версии протокола.

🔮 МИФ №3. Если сервер поддерживает HTTP/3, браузер обязательно его использует

Тоже нет.

Браузер может сначала подключиться по HTTP/2, узнать о поддержке HTTP/3 через Alt-Svc и использовать новый протокол при следующем соединении.

📎 Поэтому "поддерживается" и "фактически используется" - разные вещи.

🎙️ Что проверить на своём проекте?

1. Откройте DevTools → Network и добавьте колонку Protocol.
2. Посмотрите, используется ли h3, в том числе при повторной загрузке.
3. Проверьте поддержку HTTP/3 на CDN или сервере.
4. Сравните реальную производительность: LCP, INP, TTFB, p75 по пользовательским данным.
5. И только потом решайте, что действительно стоит оптимизировать.

💎 HTTP/3 - полезная технология, особенно при потерях пакетов и нестабильных соединениях.

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

🚨 Кода стало в три раза больше. А качественного софта?

GitHub опубликовал Octoverse 2026 - ежегодный отчёт о том, что происходит в мире разработки.
И цифры там впечатляющие. Но не все из них означают то, что кажется на первый взгляд.

3 факта, которые стоит обсудить 😍

1. 34,3 миллиарда коммитов за год

Два года назад было 10 миллиардов.
Разработчики действительно стали производить гораздо больше изменений. Но коммит - это единица активности, а не пользы.
Можно сделать 20 коммитов, исправляя последствия одного неудачного решения. А можно одним изменением устранить проблему, которая месяцами мешала пользователям.

2. 1,3 миллиарда слитых pull request

Это больше чем втрое превышает показатель двухлетней давности.
На первый взгляд - невероятный рост производительности.
Но у каждого PR есть вторая сторона: его нужно проверить, протестировать и безопасно доставить в production.

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

3. Более 40% PR в сентябре начинались с работы AI-агента

В марте таких было 17%.

Это уже не история про автодополнение отдельных строк. Меняется сам процесс разработки: часть реализации можно делегировать, а человеку всё чаще приходится оценивать готовый результат.

❓ И здесь появляется интересный вопрос: если писать код стало проще, не превращается ли его проверка в новое узкое место?

💣 Что это значит для IT-команд?

Представим две команды.

💎 Первая закрывает 100 задач за спринт, но регулярно возвращается к исправлению багов.
💎 Вторая закрывает 70 задач, зато её изменения редко требуют переделок, а пользователи быстрее получают работающие функции.

🏆 Какая эффективнее?

По количеству задач - первая. По реальной ценности - вполне возможно, вторая.
Поэтому одного подсчёта коммитов, PR и закрытых тикетов уже недостаточно.

Что стоит измерять дополнительно:

⚡️ Change failure rate - какая доля изменений приводит к сбоям и требует вмешательства.
⚡️ Lead time for changes - сколько времени проходит от изменения кода до его доставки пользователям.
⚡️ Время на доработки - сколько ресурсов команда тратит на исправление уже сделанного.
⚡️ Результат для пользователя - улучшилась ли скорость, стабильность или удобство продукта.


✅ Индустрия научилась производить изменения быстрее. Но скорость написания кода и скорость создания ценности - не одно и то же.

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