Kurgan-Telecom Ru | Информационные технологии

Привет! Ну что, мы продолжаем зажигать ваши сердца и совсем недавно снова собрали корпоративных авторов и редакторов уже на четвертую творческую встречу. Она состоялась 24 июня в нашем офисе в Москве, а уже в эту пятницу, 10 июля, в 13.00 проведем сокращенный формат в режиме онлайн по многочисленным просьбам тех, кто находится не в столице или не смог добраться до офиса. 

Наша последняя офлайн-тусовка побила все рекорды. В одном месте встретились 49 авторов из 38 компаний. Мы нашли классных спикеров и обсудили несколько актуальных тем, успели познакомиться и пообщаться, разобрать основные проблемы авторов, а также вечные вопросы, связанные с их блоками и страхами, а ещё вместе мы погенерили классные идеи, которые могут лечь в основу статей в формате сторителлинга. Одним словом, постарались сделать эту встречу максимально насыщенной и полезной. 

Зачем мы это делаем? Кому всё это нужно? Как можно попасть на такую встречу в качестве гостя или спикера? Вопросов к нам стало прилетать немало, и я решила ответить на них, так сказать, оптом. Если ты  корпоративный автор и тебе не хватает опыта, знаний о Хабре, мотивации, поддержки и вдохновения – велкам под кат! Я поведаю историю этого проекта, а также расскажу про наше авторское сообщество, которое появилось как логичное продолжение одной из таких творческих встреч и частью которого ты тоже можешь стать.

Сессионные вычислители — залог успеха аналитики будущего

Всем привет, меня зовут Николай Голов. azathot Всю свою профессиональную жизнь я строю аналитические платформы. Возможно, вы видели мои статьи про Vertica и Snowflake.

[ Vertica+Anchor Modeling = запусти рост своей грибницы (Avito блог??, перед?? ней HP Vertica, проектирование хранилища данных, больших данных ]

- статья, 27 февраля

наша дискуссия с новой командой начиналась с одного и того же «дня сурка»:

— бизнес: «Аналитики работают слишком медленно!»;
— аналитики: «Нам не дают работать с базой напрямую, заставляют ставить задачи дата-инженерам и ждать неделями!»;
— инженеры: «Да как их пустить в центральное DWH? Вы видели их запросы? Один забытый ON в джойне — и база ложится на бок, блокируя и отчеты для CEO, и критические ETL-процессы».

Этот сюжет я наблюдал везде: в классическом on-premise (Greenplum, Vertica), в модных китайских решениях (StarRocks) и даже в open-source Lakehouse-инсталляциях (Spark). Меня окончательно шокировал кейс одной огромной европейской компании по доставке еды: она сидела на Databricks, имела практически неограниченные ресурсы, но всё равно страдала от взаимных блокировок и конкуренции за ресурсы.

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

Фантастика? Нет, Snowflake первым доказал, что это возможно, внедрив архитектуру Multi-cluster Shared Data:

Пять лет назад завершилась моя работа в одном из самых амбициозных, но не завершившихся IT-проектов в истории пассажирских перевозок. Проект для РЖД, который по масштабу и связности экосистемы должен был встать в один ряд со Сбером и обогнать всё, что существовало у мировых перевозчиков. Его убила не кривая архитектура, а пандемия и тектонические сдвиги подковерной борьбы.

Более 15 лет в b2b-разработке приучили меня держать подобные кейсы за контуром публичности. Но сегодня юридические ограничения сняты, и я готов сорвать покровы.

Этот материал – не стандартный кейс формата «мы запилили продукт, хвала нам». Это двухтомный производственный триллер о том, как построить цифровой космолет внутри панциря Левиафана. Как обеспечить безопасность команды, выстроить железобетонную стену по периметру и не поехать при этом «кукухой». Когда ты помещаешь живую инновацию в жернова госкорпорации, ты либо становишься жертвой системы, либо учишься управлять гравитацией.

Серия первая: Архитектура маскировки. Жесткий процессуальный хардкор, анатомия схемы взаимодействия и готовая методичка с Карточками компонентов, которые спасали наши задницы от бесконечных правок.

Серия вторая: Продуктовое мясо и хроники интеграционного ада. Детальный разбор самого цифрового космолета, погружение под капот легаси-экосистемы, курьезные истории из жизни нашего «прода» в жанре «пиу-пиу». И в завершение 10 наших железных правил выживания с госами.

Добро пожаловать на борт. Физика процесса изменена, но внешне мы стоим на ногах.

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

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

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

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

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

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

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

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

В среде ИТ-специалистов сложился устойчивый миф: «Если нужна система управления ИТ-процессами — бери JIRA, она всё потянет». Давайте посмотрим правде в глаза: JIRA — действительно отличный трекер задач. Но только до тех пор, пока вы не пытаетесь построить на её основе CMDB-систему. Здесь и далее под JIRA, с одной стороны, мы понимаем конкретный продукт, а, с другой, объединяем класс подобных развитых ITSM-систем, которые выпустили модули ITAM и на хайпе пытаются автоматизировать процессы управления конфигурациями как в сервис деске.

Под CMDB мы понимаем не просто набор форм и полей, которые администраторы заполняют вручную (если не забудут) или импортируются из других источников, а полноценную CMDB, где каждая конфигурационная единица (CI) имеет актуальные атрибуты, корректные связи и понятное место в ресурсно-сервисной модели. Речь идёт об управлении конфигурациями с правилами поведения объектов — прямыми и косвенными зависимостями, которые система должна отслеживать автоматически. И, наконец, о приоритизации инцидентов, когда сообщение системы мониторинга превращается не в ещё один тикет, а в точное указание: где, что и как сломано и насколько это критично для бизнеса. Перед таким набором требований JIRA как трекер задач пасует: она не просто показывает низкую эффективность — она принципиально не предназначена для этого.

Как только ваш ИТ-ландшафт перешагивает определённую планку сложности, повышаются требования к работе ИТ-специалистов, обеспечивающих оперативное управление ИТ-сервисами, специалистов, которые выполняют задачи администрирования и развития информационных систем. Их деятельность начинает измеряться в количестве изменений, которые они способы реализовать, сроках и качестве таких изменений, скорости реакции и устранения аварий, переход на мероприятия по проактивному предотвращению аварий. И все эти показатели напрямую завязаны на CMDB. Формальное наличие списка серверов никого не устроит. JIRA загрузила из zVirt список виртуалок — это хорошо, осталось понять, что из этого прод и тест, что к какой системе относится и какие сервисы там крутятся. Без этой информации — это просто список виртуалок.

По определению ВОЗ, выгорание - накопление стресса, которое сопровождается усталостью, раздражительностью и цинизмом. Уже здесь термин вводит в заблуждение и прямо противоречит сути проблемы. Выгорание предполагает отсутствие чего-то, пустоту: «выгорело, кончилось». Тогда как расшифровка ВОЗ указывает на накопленное напряжение. Стресс в переводе с английского - это и есть напряжение. Не дефицит. Переизбыток.

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

Грубо говоря, работа психики - это два встречных процесса переработки опыта. Вместе они образуют то, что называют снижением ошибки предсказания (больше можно почитать здесь https://habr.com/ru/articles/1042286/). Первый процесс - информационный метаболизм, описанный польским психиатром Антонием Кемпинским ещё в семидесятых: переработка поступившей информации о мире. Другой, встречный процесс, переработка возбуждения в широком смысле. Обработка моего уникального, специфического отношения, то есть тех чувств, которые возникли в организме в ответ на полученную информацию. Если ошибка предсказания огромна и возбуждение слишком сильное это психологическая травма. Резкое превышение ассимилятивной ёмкости, временный коллапс системы. Скачок напряжения, который сжёг предохранители. Выгорание похоже по сути. Это медленное накопление непереработанного возбуждения. Условные зомби-процессы, которые не делают ничего полезного, но греют процессор. Депрессия - огромное количество накопленного возбуждения, которое не было переработано. (Я не говорю об эндогенных или первично биологических депрессиях).

Маленький дисклеймер на входе

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

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

Спойлер: да, это работает. Реально работает. У меня сейчас на проде живой сервис Бытовые счета, он умеет всё перечисленное выше плюс ещё много чего, и я там написала ровно ноль строк кода руками. Всё — через Claude Code, IDE-расширение от Anthropic.

Спойлер номер два: там, где всё идёт по плану, вайбкодинг — магия. Там, где ломается — оно превращается в очень специфический жанр квеста, в котором тебе сильно помогает базовое аналитическое мышление и мешают розовые очки.

Раскрученный проект nanochat обещает "за $100 обучите свой ChatGPT". В оригинале обучение на 8xH100 80Gb, но никто не мешает обучить его на домашнем и более слабом железе. Попробуем обучить LLM с нуля на статьях Хабра, чтобы посмотреть хватит ли там материала, чтобы модель хотя бы смогла связать пару слов.

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

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

Хотя предстоит ещё проделать работу по доведению этих яйцеклеток до полной зрелости, мы считаем это значительным научным прорывом.

Enterprise Architecture помогает связывать бизнес‑цели, технологии и изменения в компании. Но без правильного подхода она легко превращается в набор диаграмм и бюрократию. Разбираем 10 типовых ошибок внедрения EA и способы их избежать.

Привет, Хабр!

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

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

Вся логика сервиса работает на недавно написанной мною библиотеке, реализующей подход HTML-on-Wire (передача готового HTML от сервера). Это её дебют в проде, и текущая нагрузка (сейчас в базе 20 000+ АЗС и около 5000 отметок в сутки) — будет идеальным стресс-тестом, чтобы понять, как такой подход держит нагрузку.

UI/UX: Как уместить всё на одном экране Одной из главных задач было сделать интерфейс, которым удобно пользоваться за рулем или стоя в очереди, когда интернет ловит только на парковке.

6 июля OpenAI выпустил gpt-realtime — движок «речь в речь», который говорит как человек и держит перебивание. Я делаю голосового ИИ-приёмщика для бизнеса на российском стеке и занервничал: не устарел ли мой подход?

За вечер собрал прототип на OpenAI, откопал, что у Яндекса есть свой Realtime, и замерил задержку у всех трёх подходов одним методом. Цифры честные, с оговоркой про VPN: Яндекс Realtime ~330 мс, OpenAI ~740 мс (под VPN — иначе в РФ никак), старая трёхзвенка ~4,4 секунды.

В статье — грабли обоих движков (400-й эндпоинт у OpenAI, три роли доступа и закрытый обмен OAuth→IAM у Яндекса), почему у OpenAI не лечится акцент в русском, и как я за вечер переписал свой прод на Яндекс Realtime: WebSocket-мост, живой PCM-плеер вместо MP3, перебивание без наушников. С кодом и реальными замерами.

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

До недавнего времени я ходил с Apple Watch S3 в качестве дополнительных смарт-часов, однако две недели назад я сменил их на Cubot GT5 за 4.000 рублей. Зачем? Расскажу в сегодняшнем обзоре!

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

В кейсе разбираем продвижение ЖК «Инсайдер» от РКС Девелопмент, где использовалась связка медийных и перфоманс-инструментов внутри одной рекламной экосистемы, включая решения Авито Рекламы и инструменты продвижения объекта в категории недвижимости.

В прошлый раз я писал про голосового ИИ на Asterisk и Яндексе. Фурора не случилось, но статью открыли семьсот с лишним человек, в ленте её увидели тысячи, а в комментариях нашлись те, кто делает ровно то же — с той же болью и теми же вопросами про задержки и оценку качества ответов. Значит, тема живая, и про свои проекты писать имеет смысл. Сегодня — про другое, с виду куда более скучное: регулятор для руфтопа. Руфтоп — это крышный кондиционер, большой ящик на крыше торгового центра. Логика — по сути термостат с амбициями: держи температуру, включай компрессоры по запросу, не дай им зачастить. Я закладывал пару недель.

Кончилось это системой дифференциальных уравнений с собственным движком, которая пять раз убедила меня, что всё работает, а потом оказывалось — неправильно. А главное — кончилось не регулятором вовсе. Регулятор оказался тривиальным. Настоящая работа была в другом: научить систему честно говорить, что с железом не так, — и не соврать при этом ни одной цифрой.

Голый тезис на весь текст: термостат — это просто, пока не спросишь, что физически происходит внутри. После этого вопроса начинается наука. А приборы, которые показывают «всё в норме», врут убедительнее всего — и заставить их не врать труднее, чем написать сам регулятор.

Как на самом деле квантование ломает вызов инструментов? Собрал бенчмарк QuantMCP, протестировав модели на 4 ГБ VRAM не на синтетике, а на реальных схемах MCP-серверов. Главный инсайт: популярные бенчмарки вроде BFCL систематически врут - корреляция их оценок с реальным падением качества оказалась отрицательной (-0.755). На живых схемах модели ведут себя иначе: Llama-3.2-1B начинает возвращать саму JSON-схему вместо вызова или галлюцинирует имена инструментов, а Qwen3-0.6B выдумывает несуществующие таблицы в SQLite. Также показал, что сложность схемы не гарантирует большую деградацию, а выбор кванта «по таблицам» может привести к обратному эффекту.

Привет, Хабр! На связи Максим Кацал, руководитель направления автоматизированного тестирования в РТЛабс.

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

В статье расскажу, как мы научились генерировать тесты прямо из JSON-схемы услуги. JUnit 5 + @TestFactory + рекурсивный обход графа маршрутов. Фреймворк, который сам прокладывает путь пользователя по приложению-конструктору, а потом проигрывает его в браузере.

Ниже раскрою архитектуру, код, подводные камни, опишу плюсы и минусы такого подхода.

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