Меня зовут Сергей Москалев, я основатель небольшой студии. Мы делаем сайты, приложения и дизайн. Команда — восемь человек: четверо разработчиков, проджект-менеджер, тестировщик, дизайнер и я. Год назад мы оказались в точке, которую многие владельцы аутсорс- и продакшн-студий, думаю, узнают с полувзгляда.
За год мы не выросли вообще. Совсем.
Современные S3-хранилища давно перестали быть «черным ящиком»: от их архитектуры напрямую зависят отказоустойчивость, производительность и экономика сервисов, которые на них опираются. Но за внешне простым API скрывается интересная, сложная, промышленная система — от железа в стойках до многослойного распределенного приложения.
В этой статье разберем, как устроено промышленное объектное хранилище на практике: какие архитектурные решения лежат в основе, как достигается масштабируемость и где проходят реальные технические компромиссы.
Меня зовут Александр Гришин, я руковожу направлением хранения и обработки данных в Selectel. Отвечаю за развитие облачных баз данных, S3-хранилища, аппаратных СХД и сервисов для построения DLH. Материал будет полезен CTO, CIO и архитекторам, которые выбирают или проектируют собственное S3-совместимое хранилище. Или инженерам которые хотят просто лучше понимать, что же происходит у нашего сервиса под капотом. Погнали!
Я, Ирина Чекулаева, обожаю BI и с удовольствием разоблачаю мифы и ищу ошибки в системах бизнес-аналитики.
Здесь хочу порассуждать на тему CRM аналитики по результатам реального проекта. Чем дальше, тем очевиднее становится один парадокс, что CRM фиксирует звонки, письма, сделки, статусы, но она не отвечает на главный вопрос: почему продажи происходят или не происходят.
Сегодня у компаний данных больше, чем когда-либо. Проблема уже не в их отсутствии, а в том, что они не собираются в управляемую картину. Метрики существуют, отчёты строятся, дашборды обновляются, при этом контекст бизнес-ситуации теряется.
В итоге СЕО компании управляет не системой, а её отражением в отчётах. Или просто вынужден доверять собственным ощущениям. Продавцы активны, лиды поступают, сделки двигаются по воронке, и формально всё выглядит корректно. Но в конце месяца происходит знакомая ситуация: план не выполняется, прогнозы не сходятся, а объяснения звучат одинаково — «не дожали», «почти закрыли», «в следующем месяце точно догоним».
С похожей ситуацией столкнулся собственник небольшой консалтинговой компании. Вроде бы все учитывается и под контролем, при этом на уровне управления остались без ответа базовые вопросы:
• где теряются сделки;
• сколько времени они проводят на этапах;
• какая часть воронки реально конвертирует, а какая существует формально.
В момент, когда уходит руководитель отдела продаж, это становится критичным - вместе с ним исчезает «интерпретатор данных».
Почему обычная воронка — уже недостаточна, но ещё нужна
Самые интересные новости финансов и технологий в России и мире за неделю: заявка на новую пандемию, кибердружины из студентов, национализация Русагро, параллельный импорт заменят на отечественные компы, Пентагон публикует фотки НЛО, срок португальских гражданств удлинили, а также альтманофон от OpenAI.
Navisworks хорошо находит BIM‑коллизии, а Revit — инструмент для исправления. Но между ними часто остаётся хаос: XML и HTML‑отчёты, Excel, переписки, ручной поиск ID и вопросы руководителей в стиле «ну как там с коллизиями?».
Я расскажу, как из этой боли вырос внутренний web‑сервис Clash Analytics: импорт XML‑отчётов Navisworks, аналитика по проектам, история коллизий, статусы, комментарии, назначение отделам и локальный Revit Bridge, который открывает проблемное место в модели за один клик.
У нас было 2 телефонии от разных вендоров, одна речевая аналитика и 300 тысяч звонков в месяц. И задача: сделать сквозную аналитику по звонкам сотрудников.
Привет! Я Никита, инженер системного проектирования в компании Передовые Платежные Решения. Расскажу, как мы использовали единый идентификатор через службу каталогов Active Directory (AD), и стали точно определять, кому из сотрудников принадлежит звонок. Независимо от того, из какой телефонии он исходит.
Наш опыт может быть полезен архитекторам, инженерам и техническим лидерам команд, которым предстоит интеграция разнородных систем телефонии.
Обычно те, кто выбирает направление разработки в IT, идут учить Python, Java или JavaScript. 1С в этот список не попадает: платформа и профессия, связанные с ней, часто воспринимаются менее «модными», хотя по сложности и масштабу задач это не всегда справедливо.
Но в 2026 году есть несколько обстоятельств, которые влияют на восприятие 1С. На российском рынке у 1С очень сильные позиции, особенно в учёте и ERP (Enterprise Resource Planning — система планирования ресурсов предприятия). Зарплаты 1С-специалистов в 2025–2026 годах заметно выросли, а на уровнях мидл и сеньор они стали сопоставимы с доходами в других популярных IT-направлениях.
В этой статье мы делаем честный обзор того, как сегодня обстоят дела в 1С-разработке, какие преимущества и недостатки есть у этого направления и стоит ли учиться на программиста 1С.
Ракету не отправляют в космос только потому, что её двигатель и насос успешно прошли стендовые испытания по отдельности. Перед стартом инженеры рассчитывают траекторию, моделируют режимы работы и анализируют сценарии отказов. Расчёт не заменяет реальные тесты, но задаёт для них осмысленную рамку.
В софте всё обычно иначе. Распределённый пользовательский путь — например, оформление заказа — собирается из десятков микросервисов, баз и очередей. Разработчики добавляют новую зависимость, видят зелёные тесты, проверяют локальные метрики и выкатывают релиз. Считается, что если при сбое что-то пойдёт не так, настроенная система наблюдаемости обязательно это покажет.
Она, конечно, покажет. Но почему при проектировании микросервисов мы так спокойно относимся к тому, что узнаём о хрупкости архитектуры в основном по факту инцидента?
Эта статья о том, как получить грубый расчёт деградации системы ещё до релиза. Без отказа от хаос-инжиниринга или мониторинга, а как шаг перед ними. Я расскажу о двух экспериментах, в которых топологическая модель автоматически извлекалась из распределённых трейсов, после чего на ней просчитывались сценарии отказов методом Монте-Карло. Результаты моделирования я затем сравнивал с реальными инъекциями отказов на стендах DeathStarBench и OpenTelemetry Demo.
Представьте себе классическую ситуацию: финансовый директор смотрит на два отчета по выручке за прошлый год. Один отчет, построенный в старой системе, показывает 150 миллионов рублей, другой — в новой корпоративной CRM — демонстрирует 145 миллионов. Разница в 5 миллионов, а вместе с ней и ощущение, что новая система «врет» и вводит всех в заблуждение. Начинается поиск виноватых, и, как это часто бывает, крайними оказываются ИТ-специалисты, якобы «неправильно настроившие миграцию».
Но проблема гораздо глубже. Дело не в кривых скриптах и не в саботаже данных. Причина кроется в «Иллюзии темпоральности» — коварном и широко распространенном заблуждении, что изменчивостью данных во времени можно пренебречь, и достаточно хранить лишь последнее известное состояние. В то время как реальный бизнес находится в бесконечной динамике: клиенты переезжают, меняют паспортные данные и сегменты лояльности; товары проходят через ребрендинг и смену классификаций; сотрудники переходят из отдела в отдел. Если система фиксирует лишь последний известный срез, прошлое в отчетах неизбежно исказится, что и приводит к тем самым «пропавшим» или нестыкующимся суммам.
Современные методологии управления данными, в частности Slowly Changing Dimensions (SCD) или «Медленно меняющиеся измерения», предлагают элегантный и проверенный способ справиться с этой иллюзией, превратив хаос непрерывных изменений в стройную, аналитически ценную картину.
Представьте: ваш первый день в офисе, вам дали доступы ко всем 15 репозиториям проекта, рассказали где что лежит, и теперь ждут от вас великих дел. Тем временем вы едва можете вспомнить, какой карточкой открывается этаж и где стоит кофемашина.
Добро пожаловать в 50% IT-компаний во вторую статью цикла про онбординг в сложную систему!
В этой статье превратим плоский список репозиториев в рабочую onboarding-map: сначала определить роли, потом соберем dependency matrix, а затем получим relationship diagram.
Привет, Хабр! На связи Илья Амосов из команды поддержки Lakehouse-платформы данных Data Ocean Nova вендора Data Sapience. В сегодняшней публикации я раскрою тему влияния динамического сокрытия чувствительных данных на производительность SQL-запросов. Мы сравним различные методики маскирования, узнаем, как работает оптимизатор и движок со скрытыми полями, происходит ли деградация пропускной способности платформы, как влияет на производительность выбранный метод сокрытия чувствительных данных в случаях, если вы используете компонент на базе Apache Ranger.
Почему Agile‑команды скатываются в неконтролируемый хаос, а проекты на Waterfall годами пилят никому не нужный продукт? Спойлер: проблема не в методологиях, а в нас самих. Вы узнаете, как сильные команды совмещают лучшие практики обоих миров, почему Contract‑First и Trunk‑based Development спасают даже в Agile.
В работе аналитика данные часто говорят одно, интуиция — другое, а неопределенность сопровождает на каждом шагу. Важно уметь применять ее в свою пользу и не бояться.
В этой статье хочу поделиться, как работать с неопределенностью: какие у нее есть виды, как она обманывает мозг и какие есть способы сделать ее понятнее.
Привет, Хабр! Я Ирина Хабенская, руководитель направления аналитики в Авито. Хочу поделиться прикладными пошаговыми советами по развитию ключевых софт-скиллов. Статья будет полезна мидл-аналитикам, которые хотят дорасти до синьора.
Часто я сталкиваюсь с таким запросом от ребят-мидлов: «харды уже ого-го, но лычки синьора почему-то не дают». На основании своего опыта я хочу поделиться в этой статье наиболее распространёнными софтовыми навыками, которых и не хватает сильному мидл-аналитику, чтобы сделать последний рывок до синьорства.
Я также часто рассказывала этот материал и встречала комментарии уровня «Да, чертовски полезно, со всем согласен!», но также в глазах аналитиков читалось «А делать-то что?». Поэтому я добавила в статью прикладные пошаговые советы, которые помогут не просто получить полезную информацию «на подумать», но и начать реально расти.
Всем привет! Меня зовут Владимир Зуев, я руководитель разработки JAVA-практики в компании Axenix. Сегодня я хочу рассказать о нотации ArchiMate, используемой для разработки и моделирования информационных систем. Несмотря на свои уникальные возможности, нотация ArchiMate не получила широкого распространения. Даже среди практикующих архитекторов распространенность нотации не превышает 25%. Отчасти это связано со скудным описанием в официальной документации и отсутствием практических руководств. Я хочу исправить эту ужасную несправедливость и показать сильные стороны ArchiMate, подробно разобрав ее использование на практическом примере, а так же показать как применение ИИ может помочь архитектору.
Идея этого продукта родилась дома. Моя жена работает врачом в клинике Фомина (известная московская клиника), и однажды она рассказала мне вещь, к которой я был не готов: российские клинические рекомендации (КР) в среднем отстают от международных гайдлайнов на два года. Это не просто задержка во времени — это отставание в методиках, дозировках и качестве ухода за пациентом.
И дотянуться до свежих международных гайдов российскому врачу сейчас почти негде: UpToDate отрезан, обходы через зарубежные SIM-карты прикрыли (разве что опытные айтишники знают пути обхода), Notion ушёл — а вместе с ним разлетелись по чатам и заметкам рабочие шаблоны, которые врачи годами в нём вели.
Когда жена это рассказала, мы взяли тему в работу как обычную задачу: гипотеза, интервью с врачами, валидация, MVP на нашей платформе. Так получился МедБро — бесплатный справочник, который рядом с международной рекомендацией сразу показывает соответствующую позицию из российского КР. Работает на medbro.pro, есть Android-сборка, iOS на модерации App Store. Сейчас продукт в режиме альфа-тестирования: загружено около 80 гайдлайнов, к 30 мая планируем закрыть основные специальности и выкатить личный кабинет врача с закладками.
В статье разберу четыре конкретные боли врача, ту самую функцию, ради которой во многом и затевался продукт, и то, как мы построили под неё граф клинических знаний.
Как вы знаете, мы в Humathèq помогаем создавать новые продукты, а каждый наш проект стартует с погружения в ассортиментную матрицу клиента, чтобы найти в ней место для этого продукта.
С каждым погружением мы видим, что практически все исследуемые матрицы похожи на одну из 8 метафор:
Если вы работали с API Ozon, то наверняка испытывали смешанные чувства, поняв, что отчет по транзакциям формируется по отправлениям. а не по товарам, как в WB. И проблема в том, что в одной строке ответа API метода v3/finance/transaction/list мы имеем данные по отправлению, в котором может быть несколько товаров. При этом указанная сумма покупки (accruals_for_sale), комиссии, логистики и других начислений в отчете указана одна, то есть на все отправление в целом. А значит встает задача, посчитать сколько из общей суммы приходится на единицу товара.
В этом статья поделюсь, как я решил эту проблему в своей системе аналитики продаж через Wildberries и Ozon. Напомню, небольшой обзор своей системы WBOZYA‑dash я делал в первой статье. А как получать данные из API маркетплейсов без ошибок 429 и 50x описал во второй статье.
Олег Линьков, Webformula-Agro
Компания с оборотом 300 млн рублей, хорошим продуктом и конкурентной ценой не попадает в шорт-лист крупного агрохолдинга. Причина — несоответствие адреса в ЕГРЮЛ и на сайте. Для алгоритма скоринга это «красный флаг». Для закупщика — достаточный повод не продолжать.
Всем привет! Я Ольга Матушевич, преподаватель курса «Нейросети для бизнеса», а в прошлом наставница на курсе «Аналитик данных». В этой статье я подробно расскажу про грейд «мидл аналитик данных»: кто такой мидл (сравнение с джуном и синьором); зачем повышать грейд — зарплата и конкуренция; что нужно знать и уметь — хардскилы; как прокачаться — пять способов.