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

Пару месяцев назад я поймал себя на вопросе, на который не мог ответить внятно: когда открываешь кейс на одном из этих сайтов — тебя обманывают на самом ролле или как-то иначе? Сайтов с кейсами CS2 десятки, деньги там крутятся серьёзные, и при этом ни один не публикует исходники. Снаружи — крутящаяся лента и кнопка «открыть». Внутри — Steam-боты, эмуляция клиента, HMAC, целочисленная бухгалтерия и очень конкретная математика, устроенная так, что в среднем выигрывает сайт.

Чтобы ответить доказательно, а не на уровне «да там все скамеры», я написал такой сайт целиком и выложил под MIT. Не «демку с анимацией», а полный цикл: вход через Steam, открытие кейса с проверяемым роллом, продажа и апгрейд предмета, заявка на вывод, которую реально отправляет торговый бот, и админка, в которой кейс собирается по RTP до того, как уйдёт в прод. И пока я это писал, стало видно главное — оно не про жульничество в ролле, а про то, что жульничать там и не требуется.

Репозиторий: github.com/ialakey/caseforge.

Продолжение разбора 24 миллионов оценок из Rate Me: как средняя оценка зависит от возраста оцениваемого, почему мужчины и женщины по-разному реагируют на разницу в возрасте, и проверка мифа о взаимности - щедрых оценщиков не оценивают щедрее. Три графика, полный массив, без сэмплирования.

Lenovo Tab M11 на моём столе загружается с внутренней памяти в Kubuntu.

KWin работает через DRM/KMS, Mesa рисует через Panfrost, звук идёт через PipeWire, сетью занимается NetworkManager. Bluetooth виден как обычный hci0, сенсоры — как IIO, камеры — как V4L2. Стилус работает с давлением и наклоном.

Камеры тоже завезли: задняя умеет полноценно фотографировать не только в jpg, но и в RAW, и писать видео 1080p/30fps, а еще обе камеры при этом доступны обычным Linux‑приложениям как /dev/video-rear и /dev/video-front.

Android? Отправлен за 101-й километр.

Такого плана в начале у меня не было.

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

Горел. Ещё как.

Это продолжение того же разбора, но на слой выше — про HikariCP, дефолтный пул соединений в Spring Boot. Тот самый, который «просто работает», пока не перестаёт. Проекты те же, что и в статье про миграцию и в статье про PostgreSQL: банковская система после переезда с Oracle (терабайт, 70+ таблиц, 500–3000 RPS на чтение и 50–300 на запись в пике) и enterprise-платформа на Java/Spring, где PostgreSQL жил под Hibernate. Разные команды, разные нагрузки, но сюжет один: сервис встаёт, в логах Connection is not available, и первое, что делает любой человек, — лезет крутить maximumPoolSize. И почти всегда делает хуже.

Это не туториал «как настроить HikariCP за 10 строк». Таких на Хабре хватает, и половина из них сводится к «поставьте пул побольше». Здесь — список мест, где у нас всё ломалось, в порядке от «это все знают, но всё равно наступают» до «поняли только в проде под нагрузкой».

Если вы сейчас живёте на HikariCP — читайте как чеклист. Если уже прошли через это — сверьте, сколько совпало.

Дисклеймер: проекты под NDA, названия, точные объёмы и часть деталей изменены. Порядок величин, конфиги и сами инциденты — настоящие.

В гибких методологиях вроде Scrum и инженерных практиках DevOps / DevSecOps часто используют итеративно-инкрементальную модель SDLC в сочетании с непрерывным тестированием. Применяется концепция вложенных Agile циклов — это архитектурный паттерн, описывающий разработку как систему из множества взаимосвязанных петель обратной связи (feedback loops), которые вложены друг в друга.  Для упорядочения разработки и удобства используют CI/CD конвейеры (pipelines). Для автоматизации рутины всё больше используют ИИ-агентов, работающих в Agile петлях разных уровней. Попробуем описать модель жизненного цикла ПО, включающую эти прогрессивные практики.

Меня зовут Кирилл Манин, я почти шесть лет работаю в команде SQL DBA и занимаюсь развитием платформы баз данных Авито.

Почти всё это время к нам регулярно обращались разработчики микросервисов: «Можно нам читать с реплик?» и «Как подключиться к реплике для чтения?». Мы всегда отвечали одинаково: платформа не поддерживает чтение с реплик, и добавлять такую возможность мы пока не планируем.

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

Какое будущее нас ждет на достаточно продолжительном интрвале времени? Обретет ли ИИ Сознание? Как это повлияет на Социум и место ИИ в нем? И какие еще удивителные умозаключения можно выдвинуть на эту тему?..

Я занимаюсь внедрением и интеграциями CRM уже третий год. За это время у меня было больше 70 интеграций, а около 90% клиентов после внедрения остаются на сопровождении.

И один из вопросов, который я регулярно слышу еще до начала проекта:

«А какая CRM нам лучше подойдет — Битрикс24, amoCRM или что-то другое?»

Иногда вопрос формулируют еще проще:

Мы идём по тёмному цеху, освещение мерцает, где‑то капает вода, пар свистит, вырываясь из небольшого отверстия в трубопроводе. Старые пульты управления, покрытые пылью, копотью и паутиной. Проходя мимо пультовой, улавливаешь запах сигарет и кофе — верные, вечные спутники оперативной смены. Слева, на высоте метров десяти, работают котлы, издавая звук, схожий с рёвом Роковой горы в самом сердце Мордора. Весь путь пропитан хтоническим ужасом — не хватает только своего Фредди Крюгера или Джейсона Вурхиза. Хотя кто знает, что тут по ночам происходит.

И вот мы приходим к нашему месту «жертвоприношений» — тренажёрному классу для обучения операторов ТЭЦ. За стеной — цех с четырьмя энергетическими котлами БКЗ, за окном — минус 35, а впереди — две недели установки софта, наладки, ввода в эксплуатацию и обучения инструкторов. Хоть и кажется, что вся эта компьютерная техника с красивыми картинками здесь чужеродна…

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

Теперь значительную часть работы делают Codex, Claude Code, Gemini и другие ИИ-агенты, а моя работа всё больше похожа на проектирование среды, в которой они могут безопасно работать.

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

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

Что, если два небольших автоматизированных процесса возвращают компании больше 160 рабочих часов в месяц?

В одном из проектов я связал внутреннюю Excel-систему компании с маркетплейсами и добавил AI-черновики ответов на обращения покупателей — при этом финальное решение всегда остаётся за сотрудником.

Разобрал, где именно терялось время, что автоматизировал и почему эффект получился примерно на 100 тысяч рублей рабочего времени в месяц на 5 сотрудников.

В статье — цифры, архитектура и экономика внедрения.

Когда много работаешь с ИТ‑проектами, быстро понимаешь, какие инструменты действительно экономят время команды. Я работаю аналитиком и архитектором систем в компании интеграторе, где а мы помогаем компаниям автоматизировать передачу данных из 1С в BI‑системы (системы аналитики). Проще говоря — настраиваем обмен между 1С и BI так, чтобы нужные данные автоматически поступали в контур аналитики и обновлялись по расписанию, без регулярной ручной загрузки.

Со временем мы заметили, что нашим заказчикам не хватает быстрого и удобного способа собирать витрины данных для BI — без сложного кода, с понятной логикой и простым обслуживанием. Да, есть конечно Apache AirFlow, есть DBT — но все это для технарей, для искущенных в Python и SQL.

И в какой‑то момент возникла мысль о своем ETL‑решении, но дружелюбном к нормальным бизнес‑пользователям. Так появился DVT — low‑code ETL‑сервис, который мы сначала развивали в собственных проектах, а теперь решили сделать общедоступным, выпустив его в Open Source. 

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

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

Разбираем анатомию утечки, математику позиционного теста для её детекции и делимся сниппетом защиты от подобных ошибок.

Идея была простая: смотреть аниме с друзьями так, чтобы пауза у одного означала паузу у всех. Не Discord Go Live с его артефактами и мылом, не «на счёт три жмём пробел», а честный общий плеер: кто угодно нажал — у всех перемоталось.

Я думал, это вечер работы. Получилось четыре нетривиальных проблемы, три из которых я не нашёл описанными нигде, и одна ночь отладки того, почему hls.js молча ничего не делает.

Под катом: почему прямая ссылка на видео бесполезна в браузере, как выглядит прокси с подписанными токенами и переписыванием HLS-плейлистов на лету, как синхронизировать плеер без вечного эха событий, и почему preload="none" ломает Media Source Extensions.

Одна уязвимость, дюжина названий, 321 запись и стенд, за которым конкуренты договорились “дружить”. История создания самого известного идентификатора в кибербезопасности по первоисточникам 1999 года.

Одной из сильных сторон Kafka Streams является возможность хранить состояние приложения локально. По умолчанию в качестве локального хранилища используется RocksDB — встроенная key-value база данных, расположенная на диске.

Но есть одна особенность, о которой редко задумываются в начале проекта. State Store отлично умеет хранить данные, но совершенно не знает, когда их пора удалить. Если приложение однажды записало объект в Store, он останется там до тех пор, пока приложение самостоятельно его не удалит. Никакого встроенного TTL для обычного State Store в Kafka Streams нет. На небольших объёмах это практически незаметно.

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

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

Привет, Хабр! Я — Иван Нещадин, работаю тимлидом в компании Авито. Сейчас я руковожу двумя командами Arch и Bridge. В этой статье по мотивам доклада для TeamLeadConf я расскажу, как в Авито мы создали SWAT-команду, которая быстро решает самые проблемные задачи и живёт между миров платформы и продукта. Также подробно опишу, как снижаем хаос в архитектуре и улучшаем надёжность.

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

Переход строительной отрасли на отечественные ТИМ/BIM-решения поставил перед застройщиками, техническими заказчиками и проектными организациями практический вопрос: способны ли российские программные продукты обеспечить полноценное информационное моделирование без использования зарубежного программного обеспечения и сохранить привычные процессы взаимодействия участников проекта?

В статье представлен практический опыт реализации одного из первых в России проектов по комплексной разработке всех основных разделов проектной документации многоквартирного жилого комплекса с использованием отечественной ТИМ/BIM-платформы nanoCAD BIM Строительство и nanoCAD Инженерный BIM¹ (далее – nanoCAD BIM). На момент подготовки статьи проект успешно прошел экспертизу и получил разрешение на строительство.

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

На практике до дашборда было ещё далеко.

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

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

Всё началось со странной потери скорости решения задач.

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

Насчёт лимитов я особо не переживал. Подход моей AI-команды позволяет параллельно работать над несколькими крупными проектами на подписке Claude Code стоимостью 100 долларов. Команда разделена на роли, у каждой роли собственная рабочая область, задачи декомпозируются, а большие исследования можно выносить в отдельные сессии. Система была рассчитана именно на то, чтобы не складывать весь проект в голову одному агенту.

Но затем мой AI-архитектор продукта дважды ушёл в сжатие контекста.

Он работал на Opus с контекстным окном в один миллион токенов.

Первый раз можно списать на случайность. Второй — уже закономерность.

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

Началось расследование.

Тогда я ещё не знал, что системная проблема всей AI-команды началась, скорее всего, с одной моей ошибки в терминале.