Анализ и проектирование систем *

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

26 февраля на практическом вебинаре «Как предотвратить провал фичи: чек-лист валидации гипотезы до разработки», вы получите готовое решение — структурированный чек-лист для валидации гипотез до старта разработки. Этот инструмент поможет вам сэкономить ресурсы и избежать ошибок, и он применим как в Agile, так и в Waterfall-среде.

Разберем на практике:

➕ Как появляются фичи: от боли бизнеса до решения.

➕ Что такое настоящая потребность и как её выявить.

➕ Ключевые метрики продукта и проекта для оценки.

➕ Факторы, влияющие на грамотную приоритизацию.

➕ Особенности требований в Agile vs Waterfall.

➕ Рабочие методы валидации требований из практики крупных компаний.

Дата: 26 февраля

⏰ Время: 18:00-19:00 (Мск)

👨‍🎓 Спикер: Басова Екатерина — эксперт по бизнес-анализу и управлению продуктами.

➡️ Записаться

Kubernetes: правда такой сложный, каким кажется?

В новом выпуске подкаста «В SREду на кухне» разбираем Kubernetes — честно, по фактам и без лишней теории. Говорим о главном:

• как выбирать между опенсорсным Kubernetes и вендорскими платформами;

• из чего складывается реальная стоимость владения;

• когда команда действительно готова к своим кластерам.

И пытаемся понять, почему Kubernetes постепенно становится стандартом инфраструктуры, но при этом универсального решения до сих пор не существует.

Ведущие:

• Михаил Савин, SRE Community Lead в Авито;

• Андрей Волхонский, руководитель юнита System в Центре разработки инфраструктуры Авито;

• Александр Глухих, TeamLead в юните Incident & Problem Managment в Авито.

Гость:

• Юрий Лосев, технический директор в команде Deckhouse во «Флант».

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Архитектурный минимум для аналитика: 4 вещи, чтобы понимать систему целиком

Иногда кажется, что «архитекторы — это боги»: говорят уверенно, рисуют схемы за 5 минут и будто всегда видят систему насквозь. Но правда проще: архитектор — это роль в команде, а аналитику вполне реально взять от архитектуры необходимый минимум — чтобы не просто передавать требования, а реально влиять на качество решения. 

В статье «Роскошный архитектурный минимум для аналитика: понимать систему в целом и не бояться «богов»-архитекторов» — короткий и прикладной набор, который помогает: видеть продукт как единый организм, а не набор задач в блоге, заранее ловить риски и нефункциональные требования, а также говорить с разработкой на одном языке и задавать точные вопросы.

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

Разбираемся как принимать звонки в браузере. Основы WebRTC\SIP\RTP.

Во многих коммуникационных продуктах возникает потребность работы с голосом. В этой серии постов разберемся как организовать прием звонков непосредственно из вашего web приложения. Какие есть варианты передачи звукового потока и какая может быть архитектура backend приложения, обеспечивающего его работу.

Начнем с самой простой в реализации схемы, в которой передача голоса осуществляется напрямую между браузером пользователя, открывшего ваше web приложение и серверами провайдера "виртуальной телефонии"(aka "виртуальная атс" ).
При этом вся мета информация о поступившем входящем звонке и событиях всего жизненного цикла звонка принимает ваш backend. У разных провайдеров телефонии набор событий и строения api может отличаться, но общая схема работы схожа.

Разберем основную схему организации передачи голоса. Браузер по сути работает как SIP‑телефон: сигнализация через WebSocket, медиа — по RTP.

1. Регистрация в сети

• Оператор открывает страницу в браузере.

• Браузер отправляет SIP REGISTER на SIP‑сервер (WebSocket/TLS).

• SIP‑сервер отвечает 200 OK.

• В интерфейсе показывается «Вы в сети» — оператор готов к звонкам.

2. Звонок

• SIP‑сервер отправляет SIP INVITE в браузер.

• Браузер показывает уведомление «Входящий».

• Оператор нажимает «Принять».

• Браузер запрашивает доступ к микрофону (getUserMedia) — внутреннее действие.

• Браузер отправляет SIP 200 OK + SDP на SIP‑сервер.

• SIP‑сервер отправляет SIP ACK в браузер.

• SIP‑сервер даёт команду RTP/SRTP‑шлюзу установить медиа‑сессию.

• Медиа (RTP/SRTP по UDP) передаётся между браузером и RTP‑шлюзом.

• Начинается разговор.

3. Завершение звонка

• Оператор нажимает «Завершить».

• Браузер отправляет SIP BYE на SIP‑сервер.

• SIP‑сервер отвечает 200 OK.

• Передача RTP/SRTP прекращается.

Если тема будет интересна, то далее обсудим схему работы backend'а и варианты развития общей схемы передачи голоса с плюсами, минусами и ограничениями.

В своем канале в Telegram и канале в Max о разработке в стартапах рассказываю еще больше интересного и делюсь опытом, заходите, буду рад!

Спокойных вам релизов и захватывающих решений !

Зима в разгаре, а мы нанимаем: новые вакансии в SSP SOFT

Кто мы и чем занимаемся? Лидеры («одни из», конечно) найма ИТ-специалистов на российском рынке — за прошлый год мы наняли 179 сотрудников, и уже в январе 2026 к нам присоединились 11 новых гуру!
Занимаемся заказной разработкой ПО и предоставляем крупным клиентам выделенные команды на ИТ-аутсорсинг.

У нас новый московский офис, который открылся в 2025 году у самой Красной площади! А еще есть вакансии в офис в Томске и на удаленку из любой точки России.

Команда в SSP SOFT — это реальные проекты, дружная атмосфера, где работать — продуктивно, без выноса мозга и микро-менеджмента. В январе 2026 ищем опытных спецов, кто готов в новое профессиональное будущее вместе с нами.

Самые горячие вакансии прямо сейчас:
(а всего их 11 на начало февраля 2026 - см. ссылку ниже на ХХ-ру)
1️⃣ Fullstack QA Engineer (Node.js)
2️⃣ Java-разработчик
3️⃣ Системный аналитик (ритейл)
4️⃣ Data Разработчик (Oracle, Greenplum)

Что предоставляет экосистема SSP SOFT:
✅ Мы пишем код, который формирует завтрашний день. Никакой скучной рутины.
✅ Центр компетенций и личное менторство ускорят развитие до максимума.
✅ Офис, гибрид или фулл-удаленка? Есть все варианты.
✅ Время — ваш ресурс. Мы его уважаем.

Подробности о вакансиях читайте на нашей странице ХХ.ру, но туда откликаться необязательно. Ждем резюме в ЛС нашей HR Lead Алине (https://t.me/AONikitina).
Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».

Желаем всем хабровцам успешной карьеры в 2026 году 🚀)

💥 Новое в Gramax 💥

• Модуль метрик в Gramax Enterprise Server. Появились отчеты с метриками просмотров, визитов и посетителей на портале документации. А также статистика поисковых запросов. Отчеты можно фильтровать по дате и пользователям, выбирать период (день, неделя, месяц).

• Поддержка Git LFS . Добавили возможность работать большими бинарными файлами (изображения, архивы, PDF и др.) через спецификацию Git LFS. 

• Превью файлов. На портале для читателей доступно превью файлов PDF и DOCX по клику. Читателю не обязательно скачивать файл на компьютер — он может просмотреть его прямо в браузере.

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

• Ссылки между каталогами. Добавили возможность добавлять относительные ссылки на статьи в других каталогах. 

• Удаление запроса на слияние. Теперь можно закрыть запрос на слияние в интерфейсе Gramax — он будет удален для всех пользователей после публикации изменений.

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

Подробнее об изменениях читайте в статье — https://gram.ax/resources/docs/whats-new

Работающий продукт невозможен без документации

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

Мой путь в IT привел меня к системному анализу: до этого я пробовал себя и в роли проектного менеджера, и бизнес-аналитика, и даже частично тестировщика. И главная проблема каждого проекта, в разработке которого я участвовал — отсутствие документации.

Не снимаю с себя ответственности: зачастую объем документации зависел от моей работы, однако времени на нее было недостаточно — приходилось совмещать несколько ролей одновременно. Это, конечно же, приводило к путанице и большим проблемам в будущем. Отсутствие покрытия ключевых элементов системы приводит к багам и заваленной вопросами поддержке.

В моем опыте было несколько раз, когда я подхватывал проект за другим аналитиком. К сожалению, каждый раз мне приходилось либо восстанавливать и актуализировать документацию, либо писать ее с нуля. Так, на одном из проектов, была полностью неработающая ролевая система, на что постоянно жаловались пользователи. Пришлось делать, по сути, реверс-инжиниринг, выявляя текущие процессы, согласуя их с заказчиками, а затем передавая задачи разработчикам. На исследование системы пришлось потратить около недели, а дальше согласования, переработка, постановка задач и разработка архитектуры решения — заняло около двух-трех недель. Как только появилась документация и задачи были реализованы по ней — мы перестали получать по этому поводу какие-либо вопросы.

Целью другого проекта было его “возрождение” после полутора лет простоя. Багов — куча. Тестировщик спустя четыре месяца все еще ежедневно приходит ко мне с ошибками, на часть из которых мне сложно дать ответ: документация с прошлой разработки отсутствует полностью. Мне задают вопрос “Как должно быть?”, а мы не знаем даже того, для чего это вообще было реализовано. Разработка решения для устранения бага занимает меньше времени, чем поиск информации по этому функционалу.

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

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

В дальнейшем планирую поделиться своим опытом ведения документации: процессы, шаблоны, виды артефактов и другое.

Как принять 4 проекта в курирование и не свихнуться?

TL;DR

Руководитель дал 4 новых проекта в архитектурный надзор. Держать всё в голове нереально. Изучил индустриальные практики и подготовил процесс приёмки совместно с Claude Code. Выложил в open-source. Буду рад feedback от вас и ваших агентов.

Как всё началось

Руководитель: "Вот тебе 4 проекта - принимай в работу."

Я: "Окей... А что там?"

Руководитель: "Узнаешь."

Контест:

• 4 проекта

• Где-то есть пересечение функциональности (где именно - неясно)

• Команды разные, стек разный, зрелость разная

• Держать всё это в голове - бесмысленно

Немного поглядел - стало понятно: нужен системный подход.

Что я сделал

1. Изучил индустриальные практики

Посмотрел, как это делают:

• Futurice Project Handover Checklist

• TOGAF Architecture Review

• Harvard EA Checklist

• Практики из книг (Software Architecture in Practice, Building Evolutionary Architectures)

2. Собрал процесс приёмки и аудита

Готовил совместно с Claude Code. Не в чистом виде, конечно с моей конфигурацией (на текущий момент это 3882 строк rules, skills and commands). Безусловно, вычитывал и редактировал.

Что получилось:

Процесс приёмки проекта

6 фаз:

1. Инициация (получить вводную, доступы)

2. Kickoff встреча (PM + Tech Lead)

3. Сбор информации (документация, код, мониторинг)

4. Аудит (анализ архитектуры)

5. Решение о приёмке (принят/с оговорками/не принят)

6. Онбординг в надзор (регулярные встречи, точки контроля)

Файлы:

• project-handover-process.md - детальный процесс

• project-handover.md - чеклист (11 секций, 80+ пунктов)

Шаблоны аудита системы

Ручной аудит (12 разделов):

• Структура системы (C4, bounded contexts)

• Взаимодействие сервисов (sync/async, матрица зависимостей)

• Паттерны и антипаттерны

• Observability (метрики, логи, трейсинг, алерты)

• Устойчивость (SPOF, graceful degradation, DR)

• Безопасность

• План улучшений

Автоматическая валидация (215 метрик):

• Coupling и fan-out

• Layer violations

• God classes

• Топологические метрики

Файлы:

• system-audit.md - ручной аудит

• audit.md - отчет автоматической валидации

На следующей неделе начинаю приёмку. Посмотрим как процесс сработает в реальности.

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

Вопрос к сообществу

Буду рад feedback от вас и ваших агентов:

1. Процесс: Что лишнее? Чего не хватает?

2. Чеклисты: Какие критичные пункты я упустил?

3. Автоматизация: Используете ли инструменты для валидации архитектуры?

4. Агенты: Если вы используете AI-агентов для аудита - какие задачи им даёте? Как проверяете результаты?

Open-source шаблоны:

• Project Handover - процесс и чеклист приёмки

• System Audit - ручной и автоматический аудит

• Specifications - spec-driven development

• ADR - Architecture Decision Records

С удовольствием улучшу на основе вашего опыта.

UPD: Если интересно как процесс сработал на практике - подписывайтесь, расскажу после завершения приёмки.
Поддержать меня: https://t.me/MikeShogin

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

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

А? Ничего не щелкает?

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

Естественно, облака, в отличие от пуховиков, специально никто не раздувает. Нет такого, что кто-то с утра пришел и заявляет — а давайте сегодня сожжем весь бюджет. Просто тут включили какой-то сервис. Там — логи оставили в горячем сторадже. Здесь забыли выключить dev-окружение. Ну, и бэкапы, конечно, куда без них.

То есть с виду-то все выглядит очень безобидно. Но через пару месяцев смотришь на счет и не понимаешь, как он вообще таким стал. В общем, самонадутие в чистом виде. Только не мемное, а финансовое.

Тут-то и нужен FinOps. Только так можно понять, что реально работает, а что просто лежит мертвым грузом. И хорошо еще, если соответствующий инструментарий уже есть. А если нет? Для таких случаев есть FinOps Radar — бесплатный инструмент, который позволит экономить до 30%.

А, если не ясно, как действовать, приходите к нам в комьюнити. Тут мы как раз обсуждаем такие вещи, делимся болью и ищем выходы из разных ситуаций с реальными цифрами и фейспалмами.

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

Новые вакансии в SSP SOFT на конец января

Кто мы? Лидеры («одни из», конечно) найма ИТ-специалистов на российском рынке — за прошлый год мы наняли 179 сотрудников! Занимаемся заказной разработкой ПО и предоставляем крупным клиентам выделенные команды на ИТ-аутсорсинг.

У нас новый московский офис, который открылся в 2025 году у самой Красной площади! А еще есть вакансии в офис в Томске и на удалёнку из любой точки России.

Команда в SSP SOFT — это реальные проекты, дружная атмосфера, где работать — продуктивно, без выноса мозга и микро-менеджмента. В январе 2026 ищем гуру, кто готов в новое профессиональное будущее вместе с нами.

1️⃣ Python AI разработчика
2️⃣ Java Tech Lead
3️⃣ Data Разработчика (Oracle, Greenplum) (https://vk.cc/cTLO9g)
4️⃣ Системного аналитика (ритейл) (https://vk.cc/cTLOcv)

Что вас ждет в SSP SOFT:
✅ Рост: Центр компетенций для максимального апгрейда скиллов.
✅ Свобода геолокации: Возможность работать удаленно, гибрид или офис.
✅ Баланс work-life: Работаем, чтобы жить, а не наоборот.

🎁 Приятные бонусы: ивенты для всей команды, ДМС для штата, обучение и бенефиты.

Подробности о вакансиях читайте на нашей странице ХХ.ру, но туда откликаться необязательно. Ждем резюме в ЛС нашему HR Lead Алине (https://t.me/AONikitina).
Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».

Желаем всем хабровцам успешной карьеры в 2026 году 🚀)

Требования по регистрации событий ИБ часто выглядят формально и обобщенно. Но именно здесь во внедрении возникает больше всего вопросов, рисков и договоренностей, которые важно зафиксировать заранее.

Мы поговорили с Лизой, аналитиком по информационной безопасности, о том, как она работает с этими требованиями и что помогает избежать разночтений с заказчиком.

Почему регистрация событий ИБ — это всегда вызов

Событие ИБ — состояние системы, указывающее на важное с точки зрения безопасности действие, например, нарушение политики ИБ или сбой. 

Звучит просто, но в реальности возникает множество проблем:

• требования часто сформулированы абстрактно — «иные действия пользователей», «события, связанные с безопасностью»;

• невыполнение требований ИБ может заблокировать весь проект;

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

Откуда берутся требования

Во внедрении я сталкиваюсь сразу с несколькими источниками:

• требования по защите персональных данных — например, приказ ФСТЭК № 21;

• документы регуляторов с описанием инцидентов и состава событий;

• отдельные требования финансовых организаций;

• внутренние документы заказчика, к которым не всегда есть доступ;

• особые режимы — государственные информационные системы, требования, которые важно учитывать еще на этапе пресейла.

Недавно в нормативке появились практические ориентиры. ФСТЭК выпустил рекомендации по базовой настройке регистрации событий безопасности — с примерами настройки логирования в ОС.

Как я структурирую требования по событиям ИБ

Чтобы работать с этим массивом, я условно делю требования на четыре группы.

Общие требования

Сроки хранения архивов журналов, источники событий, уровни системы: от ПО до сетевого оборудования.

Общий перечень событий

Самый опасный пункт — «иные действия пользователей». Моя тактика: фиксировать конкретный список событий, показывать демо и добиваться согласования, чтобы исключить разночтения.

Состав полей события безопасности

Важно понимать не только что регистрируется, но и какие атрибуты попадают в лог. Я всегда ставлю себя на место специалиста SOC: хватит ли этих данных, чтобы расследовать инцидент?

Мониторинг и передача в SIEM-систему

Даже здесь возникают сложности — неподдерживаемые протоколы, требования к формату полей и событий, особенности интеграции. Формулировки должны быть максимально точными.

Что я вынесла из практики

1. Требования в ТЗ — это только часть картины, всегда нужно копать глубже.

2. Требования меняются по ходу проекта и это нормально.

3. Все договоренности важно фиксировать письменно.

4. Нужно учитывать не только нормативные документы, но и локальные требования заказчика.

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

6. Важно заранее договориться, кто и сколько хранит логи.

→ Подробнее своим опытом Лиза поделилась в статье.

Данные есть, ясности нет: как принимаются сложные решения в IT

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

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

Когда информации достаточно, но решения всё равно «ломаются»

В сложных проектах и бизнес-ситуациях данные редко бывают идеальными.
Они неполные, противоречивые, запаздывающие. Это нормальное состояние реальности, а не ошибка аналитики.

В инженерных дисциплинах принято проверять модели в приближённых к реальности условиях - через валидацию и эксперименты.
В IT-проектах такой «аэродинамической трубы» чаще всего нет.

Решения приходится принимать в условиях неопределённости, без возможности проверить модель в натуральных условиях заранее.

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

В этот момент формально решение ещё обсуждается, но фактически оно уже принято.

Почему опыт и интеллект не всегда спасают

Парадоксально, но чем выше уровень экспертизы, тем изощрённее могут быть рационализации.

Мозг легко находит логичные объяснения, почему нужно ускориться, почему риски допустимы, почему «потом разберёмся».

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

О паузе как инструменте управления

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

Пауза не даёт готового ответа и не снимает неопределённость. Но она возвращает управление из режима реакции в режим осознанного решения.

Когда паузы нет, решение принимается автоматически: из тревоги, из защиты, из спешки.

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

Почему это важно в IT (и не только)

IT-проекты, как и в других отраслях, редко ломаются из-за одной неверной формулы.
Чаще - из-за цепочки решений, принятых слишком быстро или в состоянии повышенного давления.

Устойчивость систем, команд и бизнесов начинается не с идеальной аналитики, а со способности выдерживать неопределённость и не торопиться «закрыть вопрос» любой ценой.

Иногда лучший ход - это не выбор варианта, а умение вовремя остановиться и дать себе время подумать.

Не лайфхаки, а системный подход

К кому идти за ростом — техлиду, delivery или HR? Системный аналитик в статье «Как я перестала искать карьеру и начала видеть систему: системные законы как компас в хаосе матричной структуры» применяет теорию систем к карьере.

Эта статья — не про лайфхаки. Она про то, как я начала видеть организацию как живую систему, как поняла, что карьера — это не лестница, а путь через слои системы. И как, применяя законы системной динамики, теории систем и элементы бизнес-расстановок, я нашла свою точку опоры.

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

AI не заменяет - AI меняет роль

Спор про скорость - ловушка. Правильный вопрос: что стало узким местом?

55% компаний, которые уволили людей из-за AI, теперь жалеют (Orgvue, 2025). Исследование METR показало странное - разработчики думают что с AI работают на 20% быстрее, а объективно на 19% медленнее (METR, июль 2025).

Хинтон говорит что скоро AI будет делать за минуты работу на месяц. CEO AWS называет отказ от найма джуниоров "одной из самых глупых вещей" (MIT Tech Review).

Кто прав? Мой опыт говорит - оба мимо. AI не заменяет и не замедляет. Он меняет распределение труда.

Что отдал AI

Почти всю черновую аналитику:

• Spec drafts - первые версии спецификаций по сырым требованиям

• C4 диаграммы - контейнеры, компоненты, контекст

• Sequence diagrams - потоки взаимодействия

• Поисковые запросы - сбор контекста из документации и кодовой базы

• Тест-кейсы - acceptance criteria по спецификации

Ручное кодирование сократил до точечных мест: интерфейсы, критичные участки, отладка. Всё остальное - через агента.

Звучит как будто всё отдал. Но нет.

Что не отдам

Здоровье. Доктор может использовать AI - это хорошо. Но это должен быть доктор с образованием и опытом. AI как инструмент - да. AI вместо врача - нет.

То же с психологом и коучем. Всё что связано со здоровьем и осознанностью - только к профессионалам.

В коде аналогично: security-критичные участки, интерфейсы с внешними системами, инварианты бизнес-логики - там доля ручной работы и глубокой экспертизы остаётся выше. AI ускорил черновики и сбор вариантов, но ответственность за модель и критерии - на мне.

Про "парадокс продуктивности"

Подозреваю, что люди измеряют "ощущение скорости", а система измеряет "время до принятого PR".

Не согласен с интерпретацией METR.

Раньше: пробуешь 1-2 варианта, выбираешь, идёшь. Натыкаешься на проблемы - третья версия. Четвёртая. Legacy копится.

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

Микро-кейс: фича интеграции с внешним API. Раньше - 3 дня на реализацию, потом 2 дня на переделку когда выяснились edge cases. Сейчас - 1.5 дня, но 40% времени ушло в спецификацию и тест-контракты. Переделок ноль.

Это не замедление. Это сдвиг: меньше "time-to-code", больше "time-to-confident".

Джуниоры: как меняется обучение

CEO AWS: "Как это будет работать через 10 лет, когда никто ничему не научился?"

Согласен. Передача знаний должна быть. С AI можно делать сайты без образования - но индустрия не только про сайты. Есть вещи где нужна математика и computer science.

Но джуниор теперь не "пишет CRUD". Джуниор учится:

• Формулировать требования так, чтобы агент понял

• Писать тест-контракты до реализации

• Дебажить и верифицировать результат

• Понимать, когда AI галлюцинирует

Сдвиг роли

Меньше клавиатурной работы, больше постановки, проверки и ответственности за инварианты.

Раньше - исполнитель. Теперь - проектировщик и валидатор.

Причём само проектирование тоже с AI - общаешься с агентом, раскладываешь задачу, проверяешь результат. Во многих продуктовых задачах ручное написание кода - не главное узкое место. Узкое место - постановка, проверка, интеграция, риски.

Что стало важнее

Системный подход. "Герой-разработчик" и "пожаротушитель" - уходит. Ценятся люди, которые системно решают задачи.

И новый навык: строить свою систему работы с AI.

Это мой актив. Моя интеллектуальная собственность. Я трачу время не только на задачи, но и на эту систему.

Новый поиск в Gramax!

Мы сделали быстрый офлайн-поиск по всей документации.
Открывается через Cmd/Ctrl+/, навигация стрелками, Enter – переход с подсветкой найденного фрагмента. Подхватывает опечатки и кривую раскладку.

Помогает быстро переключаться между статьями и проектами.
Работает одинаково в приложении и в докпортале.

---
Gramax – это база знаний с хранением контента в Git в Markdown-файлах и с визуальным редактором.
Подробнее о проекте: https://gram.ax/ru

В прошлом году было много разговоров о том, что найти работу в ИТ стало намного сложнее. Мол, количество вакансий уменьшается, а откликов - наоборот, только растёт. Как специалист, который старается чувствовать пульс индустрии (в том числе на рынке труда), я решил не полагаться исключительно на общественное мнение и проверить утверждения на цифрах (правда, исключительно аспект с вакансиями).

Используя API HH, я в течение последних 3,5 месяцев отслеживал изменения в количестве открытых вакансий на позиции "системный аналитик" и "бизнес-аналитик" (в соответствии с моей специализацией). Результаты, впрочем, подтвердили озвучиваемый в постах тренд, и поэтому вряд ли кого-либо должны удивить. Однако я всё же решил поделиться с сообществом накопленной статистикой (пусть и небольшой).

• регион: Россия

• период публикации: 30 дней

• поле для поиска: в названии вакансии

Представлен учебный проект «Числа Python, которые должен знать каждый программист» (Python Numbers Every Programmer Should Know). Проект также доступен на GitHub.

«Существуют цифры\числа\значения, которые должен знать каждый программист на Python. Например, насколько быстро или медленно добавляется элемент в список в Python? А как насчёт открытия файла? Это занимает меньше миллисекунды? Есть ли что‑то, что замедляет этот процесс? Если у вас есть алгоритм, чувствительный к производительности, какую структуру данных следует использовать? Сколько памяти занимает число с плавающей запятой? А как насчёт одного символа или пустой строки? Насколько быстр FastAPI по сравнению с Django? Я хотел бы уделить немного времени и записать показатели производительности, специально ориентированные на разработчиков Python», — сообщил автор проекта Майкл Кеннеди.

Новогодняя аномалия в данных мониторинга.

Воспроизвести достаточно просто

• Скачать и установить Dimension-UI.

• Развернуть локально PostgreSQL.

• Запустить в Dimension-UI мониторинг данных PostgreSQL с помощью запроса с интервалом 3 сек.

WITH params AS (
    SELECT 
        15 AS total_frames,
        20 AS canvas_height,
        3  AS frame_duration_sec
),
animation_state AS (
    SELECT 
        (CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP) AS INTEGER) / frame_duration_sec) % total_frames AS frame_idx
    FROM params
),
tree_definition AS (
    SELECT 
        frame_id, 
        y_pos,
        CASE
            -- ═══════════════════════════════════════
            -- ЗВЕЗДА на верхушке
            -- ═══════════════════════════════════════
            WHEN y_pos = 20 AND frame_id = 7 THEN '*'
            
            -- ═══════════════════════════════════════
            -- ВЕРХУШКА елки (острая)
            -- ═══════════════════════════════════════
            WHEN y_pos = 19 AND frame_id = 7 THEN 'G'
            
            -- ═══════════════════════════════════════
            -- ЯРУС 1 (y=16-18) — расширяется книзу
            -- ═══════════════════════════════════════
            WHEN y_pos = 18 AND frame_id BETWEEN 6 AND 8 THEN 'G'
            WHEN y_pos = 17 AND frame_id BETWEEN 5 AND 9 THEN 'G'
            WHEN y_pos = 16 AND frame_id BETWEEN 4 AND 10 THEN 'G'  -- широкий низ яруса
            
            -- Сужение перед ярусом 2
            WHEN y_pos = 15 AND frame_id BETWEEN 5 AND 9 THEN 'G'
            
            -- ═══════════════════════════════════════
            -- ЯРУС 2 (y=12-14)
            -- ═══════════════════════════════════════
            WHEN y_pos = 14 AND frame_id BETWEEN 4 AND 10 THEN 'G'
            WHEN y_pos = 13 AND frame_id BETWEEN 3 AND 11 THEN 'G'
            WHEN y_pos = 12 AND frame_id BETWEEN 2 AND 12 THEN 'G'  -- широкий низ яруса
            
            -- Сужение перед ярусом 3
            WHEN y_pos = 11 AND frame_id BETWEEN 4 AND 10 THEN 'G'
            
            -- ═══════════════════════════════════════
            -- ЯРУС 3 (y=8-10)
            -- ═══════════════════════════════════════
            WHEN y_pos = 10 AND frame_id BETWEEN 3 AND 11 THEN 'G'
            WHEN y_pos = 9  AND frame_id BETWEEN 2 AND 12 THEN 'G'
            WHEN y_pos = 8  AND frame_id BETWEEN 1 AND 13 THEN 'G'  -- широкий низ яруса
            
            -- Сужение перед ярусом 4
            WHEN y_pos = 7 AND frame_id BETWEEN 3 AND 11 THEN 'G'
            
            -- ═══════════════════════════════════════
            -- ЯРУС 4 — нижний, самый широкий (y=4-6)
            -- ═══════════════════════════════════════
            WHEN y_pos = 6 AND frame_id BETWEEN 2 AND 12 THEN 'G'
            WHEN y_pos = 5 AND frame_id BETWEEN 1 AND 13 THEN 'G'
            WHEN y_pos = 4 AND frame_id BETWEEN 0 AND 14 THEN 'G'  -- во всю ширину!
            
            -- ═══════════════════════════════════════
            -- СТВОЛ (y=1-3)
            -- ═══════════════════════════════════════
            WHEN y_pos BETWEEN 1 AND 3 AND frame_id BETWEEN 6 AND 8 THEN 'T'
            
            -- Всё остальное — фон
            ELSE 'S'
        END AS pixel_char
    FROM generate_series(0, 14) AS frame(frame_id)
    CROSS JOIN generate_series(1, 20) AS y(y_pos)
),
pixel_data AS (
    SELECT td.*
    FROM tree_definition td
    JOIN animation_state ast ON td.frame_id = ast.frame_idx
),
layers_logic AS (
    SELECT 
        y_pos,
        pixel_char,
        MAX(CASE WHEN pixel_char IN ('T', 'G', '*') THEN y_pos ELSE 0 END) OVER () as max_obj_height
    FROM pixel_data
)
SELECT 
    CURRENT_TIMESTAMP as dt,
    CASE 
        WHEN pixel_char = 'T' THEN '4_Trunk'
        WHEN pixel_char = 'G' THEN '3_Tree'
        WHEN pixel_char = '*' THEN '2_Star'
        WHEN pixel_char = 'S' THEN 
            CASE WHEN y_pos > max_obj_height 
    

p.s. Данные по запросу любезно предоставлены Claude Opus 4.5.

Готово ли ваше облако к 2026 году? Быстрый FinOps-чек-лист

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

Это бесплатный инструмент в формате гугл-таблицы. Прохождение занимает 5–7 минут.

Что дает чек-лист:

• видно, где процессы уже работают, а где есть пробелы

• понятно, на каких этапах теряется прозрачность расходов

• есть конкретные шаги, что имеет смысл внедрять дальше

Чек-лист можно пройти одному, например CTO или Head of Engineering, либо вместе с командой, инженером, архитектором и финансовым специалистом.

Результат, понятный срез текущего состояния и ориентиры, как корректировать облачные расходы в 2026 году.

👉 Забрать чек-лист

Компания «Форсайт» представляет новый релиз своего флагманского программного продукта - «Форсайт. Аналитическая платформа» 10.10!

Новая версия 10.10 – это STS-релиз для быстрого развития (Short Term Support), промежуточный выпуск, который включает новые функции перед их интеграцией в релиз с долгосрочной поддержкой.
В версии 10.10 много новых возможностей для визуализации данных в веб-приложении.
Мы сделали удобнее инструмент Self-Service BI – информационные панели:
• добавили гибкую настройку элементов управления
• реализовали настройку параметров вложенных объектов
• добавили в табличный визуализатор условное форматирование и закрепление строк

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

Что еще нового в релизе 10.10?
• расширены возможности администрирования приложений
• расширена функциональность менеджера обновлений
• реализован новый API платформы для разработки прикладного приложения в системных сборках: Dashboard, Express, Fore, Metabase, RDS, WebForms

Напоминаем, что начиная с выпуска «Форсайт. Аналитическая платформа» 10.11 LTS (апрель 2026 года):
• в стандартной поставке будут отсутствовать настольное приложение для настройки платформы и Конструктор бизнес-приложения версии 9.x;
• будет прекращена поддержка платформы на Astra Linux SE 1.7 в связи с прекращением её поддержки производителем.
Подробнее о новой версии читайте здесь.