Системный Аналитик

😱 Отправили свое резюме на 129 вакансий на хх, а в ответ тишина .. Думаете, что дело в рынке труда или вашем опыте? Скорее всего нет. Процесс поиска работы сейчас - это четкий алгоритм действий, это машина, алгоритмы и авто-фильтры, которые меняются каждую неделю. Если опыт упакован неправильно, ваше резюме даже не дойдет до живого человека. 6 октября (вторник) в 18:00 по МСК: бесплатный открытый эфир с живым разбором резюме для проджектов, продактов, аналитиков, разработчиков разных грейдов На эфире разберем: 🔴почему ваше резюме не доходит до человека 🔴4 типовые стратегические ошибки в позиционировании 🔴откуда взять достижения 🔴почему вас отметают рекруты на скрининге или все-таки сколько просить денег? 🔴Q&A - обсудим именно вашу ситуацию Кто ведёт Ольга Романова, руководитель проектных и продуктовых офисов с опытом в IT более 13 лет, основатель «Карьерной группы». По её программе карьерного сопровождения 94% участников за 3–4 месяца получают офферы в Авито, Яндексе, Т-Банке, OZON и других топовых компаниях. Зарплаты от 190 тыс. ₽ у администратора проекта до 1,4 млн ₽ у технического владельца продукта.. 👉🏻 Отправить свое резюме на разбор и зарегистрироваться можно по ссылке ниже: <РЕГИСТРАЦИЯ> Erid: 2VtzqwzstaZ

Что на самом деле происходит в процессах — и как это увидеть 8–9 октября собираемся в загородном клубе на конференции VK Business Analytics. Это встреча для тех, кто развивает процессную аналитику и хочет обсуждать не теорию, а реальные процессы и проекты. В программе: ✈️ «Аэрофлот» разберет свой проект по Process Mining: какие процессы исследовали, что обнаружили в данных и что в итоге изменили. 🔎«Некст» покажет, что часто остается за пределами регламентов: обходные маршруты, ручные операции и решения, которые принимаются вопреки процессу. 🤖 VK AI Space расскажет, как данные об операциях сотрудников становятся основой для AI-агентов и новых сценариев автоматизации. А после деловой части — бизнес-игра, вечер у озера, гриль, коктейли, караоке и неформальное общение с коллегами по рынку. Можно остаться с ночевкой: у каждого участника отдельный номер. Утром — завтрак и спа, затем возвращаемся в Москву. Количество мест ограничено, участие по регистрации. Зарегистрироваться

🔼AMQP, MQTT и STOMP: протоколы обмена сообщениями AMQP, MQTT и STOMP — независимые протоколы прикладного уровня Приложения используют их, чтобы общаться с брокером сообщений поверх TCP ✖️ это не версии одного протокола и не преемники друг друга ✔️ каждый создавался под свою задачу: 🟣 AMQP — надёжная корпоративная интеграция и гибкая маршрутизация 🟣 MQTT — лёгкий обмен с устройствами в нестабильной сети 🟣 STOMP — простой текстовый обмен Что общего 🟣 все решают одну задачу: асинхронный обмен сообщениями через брокера 🟣 работают поверх TCP. Могут подниматься поверх WebSocket — так браузерный клиент общается с брокером через любой из трёх протоколов 🟣 мультипротокольные брокеры: 🟡RabbitMQ поддерживает AMQP 0-9-1 и AMQP 1.0 нативно 🟡MQTT и STOMP — через плагины поверх внутренней AMQP-модели 🟡ActiveMQ тоже понимает все три. AMQP AMQP (Advanced Message Queuing Protocol) — открытый бинарный протокол прикладного уровня 🟣Используется для передачи сообщений между компонентами через брокера. 🟣Это wire-level протокол: стандарт описывает точный формат данных, которые клиент и брокер передают по сети. 🟣Клиент на любом языке, реализующий этот формат, совместим с любым брокером той же версии — без фирменных SDK и «мостов» 👇 Стандартный порт — 5672 Модель AMQP 0-9-1 На этой версии построен RabbitMQ, и чаще всего под «AMQP» в интеграциях понимают именно её. Протокол описывает сущности брокера — топологию, которую стороны создают командами: 🔘Exchange (обменник): принимает сообщения от продюсеров и распределяет по очередям. Сам ничего не хранит 🔘Queue (очередь): именованный буфер, где сообщения хранятся, пока их не заберут потребители 🔘Binding (привязка): правило, связывающее exchange с queue. Может включать binding key 🔘Routing key: метка, которую продюсер прикладывает к сообщению, а exchange учитывает при маршрутизации Тип exchange задаёт правило маршрутизации: 🟣direct: точное совпадение routing key и binding key — сообщение попадает в конкретную очередь. 🟣fanout: ключ игнорируется, копия уходит во все привязанные очереди — рассылка всем подписчикам. 🟣topic: сопоставление по маске. Ключ — слова через точку (orders.europe.created). * заменяет ровно одно слово, # — ноль и более слов. 🟣headers: маршрутизация по заголовкам сообщения, без routing key. AMQP 1.0 AMQP 1.0 — не следующая версия 0-9-1, а другой протокол ✖️ С 0-9-1 его не связывает ничего, кроме имени 👇 1.0 описывает только передачу и не навязывает модель брокера: гарантии доставки настраиваются на каждом канале отдельно Гарантии доставки в AMQP 0-9-1 Базовая публикация не подтверждается брокером: без дополнительных механизмов это «отправил и забыл» (at most once) Надёжность собирается из частей: 🔘publisher confirms: брокер подтверждает приём каждого сообщения (расширение RabbitMQ) 🔘consumer acknowledgements: сообщение считается обработанным только после подтверждения потребителем. Без подтверждения брокер доставит его повторно 🔘persistent-сообщения и durable-очереди: защита от потери при перезагрузке брокера 👇 Комбинация даёт семантику at least once (как минимум один раз) Её цена — дубликаты, поэтому потребитель должен быть идемпотентным Когда использовать AMQP - корпоративная интеграция и микросервисы: сложная маршрутизация, разделение и слияние потоков событий - приоритизация, транзакционность (несколько публикаций «всё или ничего») - гарантии доставки Брокеры 🔘RabbitMQ 🔘Azure Service Bus (основной протокол — AMQP 1.0) 🔘ActiveMQ MQTT MQTT — лёгкий бинарный протокол публикации/подписки для устройств с ограниченными ресурсами и нестабильной сетью 👇 Стандартные порты — 1883 (TCP) и 8883 (TLS) Архитектура Издатель ➡️ брокер ➡️ подписчики 🟣 У клиентов нет адресов: издатель публикует сообщение брокеру, тот фильтрует по топикам и рассылает подписчикам 🟣 Издатель и подписчик не знают друг о друге. Топики Данные адресуются топиками — иерархическими метками Уровни разделяются слэшем: 🟣factory/line2/temperature — топик датчика температуры второй линии цеха. 🟣Подписка — на точный топик или маску: 🟣factory/+/temperature — датчики температуры всех линий (+ заменяет ровно один уровень); 🟣factory/# — всё производство (# заменяет ноль и более уровней, включая сам factory). Формат payload (JSON, бинарные данные) стандарт не описывает — это договорённость сторон Гарантии QoS (Quality of Service) действует на каждом участке отдельно Итоговый QoS для подписчика — минимальный из QoS публикации и QoS подписки Поэтому идемпотентность потребителя остаётся актуальной даже при QoS 2 («ровно один раз»). Механизмы MQTT 🟣Retained-сообщения: брокер хранит последнее сообщение топика и выдаёт его каждому новому подписчику Подключился — сразу получил актуальное состояние 🟣LWT (Last Will and Testament, «завещание»): при подключении клиент оставляет брокеру сообщение, которое тот опубликует при нештатном обрыве связи Типовой паттерн — топик статуса устройства со значениями online/offline 🟣 Persistent-сессии: брокер помнит подписки офлайн-клиента и накапливает для него сообщения QoS 1/2. Когда использовать MQTT 🟡 IoT и телеметрия: датчики, телематика, умные здания и производства 🟡 Мобильные приложения, где важны расход трафика 🟣Если устройство на сетевом питании отправляет данные раз в час, HTTP может оказаться проще Брокеры Eclipse Mosquitto, EMQX, HiveMQ STOMP STOMP (Streaming Text Oriented Messaging Protocol) — простой текстовый фреймовый протокол по мотивам HTTP Единственный из тройки, которым можно пользоваться вручную: сессию с брокером можно открыть даже через telnet 🟣Общение идёт фреймами: команда, заголовки вида «ключ: значение», тело 🟣Ключевое отличие: у STOMP нет собственной модели маршрутизации. Destination — непрозрачная строка, семантику которой задаёт брокер: - в RabbitMQ /queue/имя — разделяемая очередь - /topic/ключ — публикация в topic-exchange - /exchange/имя/ключ — произвольный exchange ✅ Есть подтверждения (ACK/NACK) и транзакции (BEGIN/COMMIT/ABORT) — группа отправок «всё или ничего» ✖️ Уровней QoS, как в MQTT, нет Когда использовать STOMP 🟣Браузерные клиенты поверх WebSocket: чаты, уведомления, обновления в реальном времени 🟣Скриптовые языки, быстрые прототипы, ручная отладка 🟡Для высоконагруженных прод-интеграций бинарные AMQP и MQTT эффективнее Реализации 👇 Плагин RabbitMQ (TCP-порт 61613, для браузеров — Web STOMP), 👇 Apache ActiveMQ и Artemis 👇 встроенный брокер Spring Типичные ошибки ✖️ «Это конкуренты Kafka» → это протоколы, а Kafka — платформа потоковой обработки со своим бинарным протоколом. Сравнивать надо брокеров: Kafka vs RabbitMQ ✖️ «AMQP — это брокер» → AMQP — протокол; брокеры (RabbitMQ, Qpid, ActiveMQ) — его реализации ✖️ «MQTT — это очередь» → нет: это pub/sub «многие ко многим», а не очередь точка-точка ✖️ «AMQP 1.0 — развитие 0-9-1» → два разных протокола под одним именем 📎 Материалы 1. Протокол MQTT: концептуальное погружение 2. AMQP vs. MQTT: 9 ключевых различий 3. Краткий обзор протокола AMQP 4. Сравнение популярных брокеров MQTT с открытым исходным кодом 📚 Книги RabbitMQ для профессионалов — Гэвин Рой #проектирование #интеграции ➿➿➿➿➿➿➿➿➿➿ 🧑‍🎓 Более поробное сравнение в базе знаний по системному анализу

Как облегчить работу ИТ-аналитика уже сейчас — без долгосрочных перестроек процессов? Обсудим на IT-analyst Meetup от Сбера! В программе — прикладные доклады: — Как эффективнее использовать возможности мозга — Какие навыки развивать аналитику и как выстроить план роста — SDD на практике: подводные камни внедрения и новые зоны ответственности аналитика 📆 29 сентября 📍 Офис Сбера (Кутузовский пр-т, 32) и трансляция онлайн Выбирайте удобный формат и регистрируйтесь по ссылке

️️️️️️️️📚Курс: «Системный аналитик. Экспертный уровень». За 146 часов обучения получите актуальные навыки и работу над реальными проектами на практике. 🎁 Записывайтесь на 3 бесплатных вебинара — познакомьтесь с программой обучения и преподавателями. Задайте свои вопросы экспертам! 1⃣29 сентября, 20:00 мск — «Зелёные тесты, неверный продукт»: разберём, почему ИИ-агент может пройти тесты, но реализовать не то, что нужно, и как аналитику поймать такую ошибку до релиза. 2⃣14 октября, 20:00 мск — «ИИ-агент как супероружие СА: ТЗ за 10 минут»: соберём пайплайн в n8n, который превращает сырые заметки в структурированный черновик ТЗ без лишних фантазий. 3⃣21 октября, 20:00 мск — «Анатомия сопротивления»: разберём, как распознать скрытый саботаж стейкхолдеров и довести внедрение до релиза без срывов сроков и выгорания. Записывайтесь ➡ https://otus.pw/8T9w/ Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Не отставайте от рынка — учитесь со скидкой 16% Если чувствуете, что стоите на месте, и хотите освоить востребованную профессию, — сейчас хороший момент начать. Потому что до 30 сентября на все курсы Практикума действует скидка 16%.  Выбрать курс Вы сможете: — получить актуальные навыки; — освоить ИИ-инструменты для работы; — перенять опыт экспертов, которые двигают индустрию; — попасть в сообщество выпускников, где можно попросить совета и, возможно, найти будущих коллег. Просто выберите курс, начните учиться бесплатно и получите скидку 16% — она автоматически появится в личном кабинете.  Учиться! Erid: 2SDnje3hmV5 Название: ООО "ЯНДЕКС" ИНН: 7736207543

Пока вы собираете требования в одиночку, кто-то уже руководит целой аналитической командой... Узнайте, как управлять командой системных аналитиков эффективно за 5 месяцев обучения вместе с OTUS на курсе «Системный аналитик. Управление командой» 🎁 Записывайтесь на 2 бесплатных вебинара — познакомьтесь с программой обучения и преподавателями. Задайте свои вопросы экспертам! 1️⃣ 8 сентября, 20:00 мск — «Системный аналитик и его ценность глазами компании»: разберём, как грамотная работа аналитика повышает эффективность команды и продукта, и почему бизнес готов платить за эту ценность. 2️⃣ 23 сентября, 20:00 мск — «Как проводить архитектурное ревью и находить риски до начала разработки»: научимся находить узкие места и точки отказа до старта разработки, чтобы архитектура не рассыпалась при запуске продукта. Записывайтесь ➡️ https://otus.pw/my9Z/?erid=2W5zFJ4hi1o Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

100 откликов, 0 собеседований. Знакомо? Можно конечно продолжать винить рынок, каждые 5 минут обновлять HH, переписывать резюме в десятый раз Но лучше - наконец разобраться кого в этот период активно нанимают и перестроить маршрут Сейчас мало знать REST, SQL и прочий инструментарий На собесы за 250-300к+ зовут тех, кто понимает, как всё это работает вместе и как спроектировать систему Сильный айти спец сегодня - это человек, который понимает архитектуру решений целиком 4 сентября в 19:00 МСК на бесплатном вебе «Архитектура без кода» покажем, как прокачать этот навык Веб для джунов и мидлов системной и бизнес-аналитики, QA, дата-аналитиков, разработчиков. Для всех, кто хочет оставаться в АйТи и нормально зарабатывать Регистрируйся здесь Erid: 2SDnjdVJmgX Название: ООО "СТЕП БАЙ СТЕП" ИНН: 0800013217

❓ ICAM (Incident Cause Analysis Method) ICAM (Incident Cause Analysis Method) — метод разбора инцидентов 💚 ищет системные причины, а не останавливается на ошибке конкретного человека 💚 по итогам разбора формулируют меры, чтобы инцидент не повторился 💚 Ключевой вопрос метода — не «кто виноват?», а «почему система это допустила?» 💚 Подходит для ИТ-инцидентов: сбоев систем, киберинцидентов, отказов бизнес-процессов Зачем нужен ❣ выводит разбор за пределы «человеческой ошибки»: наказание исполнителя не предотвращает следующий инцидент, а изменение системы — предотвращает ❣ выявляет скрытые системные проблемы, существовавшие задолго до инцидента ❣ даёт корректирующие действия, которые меняют барьеры защиты и организационные условия, а не симптомы ❣ создаёт общий язык для подразделений: категории факторов понятны всем Когда применять ✨серьёзные инциденты: существенный ущерб, повреждения, риск для людей или бизнеса ✨повторяющиеся инциденты, когда предыдущие разборы «на глаз» не помогли ✨ситуации, где простой анализ вывел на системную проблему, которую надо разбирать глубже ✨сложные инциденты с участием нескольких подразделений Как работает 🧀 В основе метода — модель «швейцарского сыра»:

Защита системы состоит из нескольких слоёв-барьеров, и в каждом есть слабые места — «отверстия» Инцидент происходит, когда отверстия выстраиваются в одну линию и угроза проходит насквозь.

Отсюда два типа причин: 💠 Активные отказы: действия и ошибки, которые привели к событию 💠 Латентные условия: скрытые системные проблемы организации, которые существовали до инцидента Причины разбираются по факторам: ➡ отсутствующие или несработавшие барьеры: контроли, которые должны были предотвратить или смягчить инцидент, но не справились ➡ действия людей и команд: что сделали или не сделали вовлечённые люди — включая ошибки и нарушения ➡ условия задачи и рабочей среды: состояние оборудования, нехватка времени, нагрузка, факторы среды, сбои коммуникации ➡ организационные факторы: управленческие решения, распределение ресурсов Иногда выделяют пятую группу — человеческие факторы: усталость, стресс, ситуационную осведомлённость. Как работает по шагам: 1⃣ Немедленное реагирование: локализовать инцидент, защитить людей и окружающую среду 2⃣ Сбор доказательств: физические, документальные и свидетельские — документы, логи, интервью. Доказательства быстро теряют качество, поэтому сбор начинается в течение часов; сам анализ — после стабилизации сервиса 3⃣ Хронология: восстановить последовательность событий и условий, в которых они происходили 4⃣ Анализ барьеров: какие контроли должны были предотвратить инцидент, где они отказали или отсутствовали 5⃣ Анализ действий и условий: что делали вовлечённые люди и в каких условиях — задачи, рабочая среда — они работали 6⃣ Анализ организационных факторов: какие решения, политика и культура допустили такие условия 7⃣ Рекомендации и отчёт: сформулировать корректирующие действия по принципу SMART — конкретные, измеримые, достижимые, релевантные, ограниченные по времени — и внести их в отчёт расследования Команда расследования должна быть независимой Пример Ситуация: в финансовой компании произошёл сбой платформы — выставление счетов задержалось на две недели, компания понесла потери Разбор по ICAM выявит: 💚 несработавший барьер: плановое обслуживание платформы было назначено внахлёст с критическими бизнес-операциями 💚 действия людей: инженеры неверно интерпретировали инструкции по перезагрузке системы 💚 латентные условия: реестр рисков устарел и не отражал ИТ-зависимости бизнес-процессов 💚 организационные факторы: ИТ-отдел работал изолированно, интеграция с бизнес-операциями была слабой Итог: перестроили планирование между отделами, усилили управление подрядчиками, руководителям внедрили дашборд, который в реальном времени показывает состояние ИТ-систем. 💚 Все выводы — про изменение системы, а не про поиск виноватых. 📎 Материалы 1. Метод ICAM (Incident Cause Analysis Method) 2. Контрольный список шаблона метода анализа причин инцидента (ICAM) 3. Модель швейцарского сыра 4. Постмортем без наказаний: культура разбора ошибок, которая реально улучшает качество проектов 5. Инцидент-менеджмент с нуля: практический гайд для растущих команд 📚 Книги 1. Безопасные и надежные системы. Лучшие практики проектирования, внедрения и обслуживания как в Google — Хизер Адкинс, Бетси Бейер и др. #инфраструктура ➿➿➿➿➿➿➿➿➿➿ 🧑‍🎓 Более поробное сравнение в базе знаний по системному анализу

Как аналитику без опыта найти работу❓ Вокруг IT‑рынка сейчас много пугающих слухов. Но по факту вакансии открываются, а компании активно ищут толковых специалистов. Вопрос не в том, есть ли места. Вопрос — умеешь ли ты правильно анализировать рынок, писать продающее резюме и самопрезентацию. Про это уже пишет Николай — системный аналитик с 10+ годами опыта в топовых IT-компаниях. Записки системного аналитика — канал про системный анализ и путь в профессию, где Николай разбирает, как в 2026 году реально устроиться аналитиком. 🔥 Уже в канале: 1) Почему ИИ не заменит профессию СА 2) Как успешно пройти собеседование на 250К и позицию Middle+ 3) Авторский гайд по профессии СА в 5 статьях Подписывайся, чтобы получить получить оффер на позицию системного аналитика и повысить свой доход: t.me/+bJGfbHW8TgEwMWNi

Сокращения в желтом банке 💳 Системный аналитик из этой истории попал под сокращение в банке и рассказал, как там решили перестроить целый департамент вокруг ИИ Основная идея: убрать все роли и нанять универсального продуктового инженера, который будет делать всё с помощью ИИ Спойлер: новые чудо-инженеры приходить не спешат Вита Заебумба | Путь корпората — топовый канал про IT, сферу найма, трешовые собесы и работу в корпорациях. Просто кладезь кулстори не только от автора, но и от подписчиков Истории, которые уже успели стать бестселлером: 🔸Как бигтехи кошмарят вас на собеседованиях ❤️ 🔸Поймала интервьюеров за руку на собесе в Ягодках 🛍 🔸Мое мнение, что будет с рынком найма в 2026 году + полезные материалы 🔸Эффект Писюхи, или как я столкнулась с эйджизмом в найме 🔸Aston, разлогинься, или как продать себя в рабство Но тут не только про корпоративный цирк. Подписывайтесь, если хотите: 🔹понимать, что происходит на рынке IT 🔹читать реальные истории найма и собеседований 🔹узнавать внутрянку компаний от людей, которые там работают 🔹следить за тем, как ИИ меняет нашу работу 👉 @vitazaebymba

🖥 NewSQL NewSQL — класс реляционных СУБД, который совмещает привычный SQL и строгие ACID -транзакции классических баз (с горизонтальной масштабируемостью и производительностью, характерными для NoSQL) Попытка убрать главный компромисс хранения данных: ➖ классические реляционные БД надёжны и согласованы, но плохо масштабируются горизонтально ➖ NoSQL отлично масштабируется, но часто жертвует строгой согласованностью ✅ NewSQL пытается дать и то и другое одновременно Зачем нужен 🔸 сохранить совместимость с SQL 🔸 масштабироваться горизонтально. Нагрузка распределяется по нескольким узлам кластера, а не наращивается мощность одного сервера 🔸 не отказываться от строгой согласованности. В отличие от многих NoSQL-решений с конечной согласованностью, NewSQL держит ACID даже при распределении данных по машинам и дата-центрам Как работает ⚡️ Главный вызов NewSQL — удержать ACID, когда данные разнесены по нескольким машинам. Под капотом транзакция проходит несколько этапов: 1️⃣ SQL-слой принимает запрос. Узел-координатор парсит SQL, строит план выполнения и определяет, на каких шардах лежат затронутые строки * Шард — диапазон строк таблицы, вынесенный на отдельную группу узлов; сами таблицы заранее разбиты на такие диапазоны по ключу шардирования 2️⃣ Каждый шард — реплицированная группа. Данные одного шарда хранятся на нескольких узлах (обычно 3–5), между которыми работает алгоритм консенсуса (чаще всего Raft) 🔹один узел — лидер, остальные — ведомые 🔹запись считается подтверждённой, когда её приняло большинство (кворум). 🔹обеспечивается строгая согласованность без единого «главного» сервера на всю базу. 3️⃣ Транзакция в пределах одного шарда заканчивается на шаге 2: лидер коммитит запись после получения кворума 4️⃣ Транзакция через несколько шардов идёт по протоколу распределённого коммита — двухфазному коммиту (2PC): 🔹координатор сначала спрашивает все затронутые шарды «готовы?», 🔹когда все ответили «да», приказывает зафиксировать изменения — иначе откатывает везде. Атомарность сохранена. 5️⃣ Параллельные транзакции не мешают друг другу благодаря MVCC — каждая работает со своим снимком данных на момент старта, читающие не блокируют пишущих. 6️⃣ Глобальное время для согласованности между дата-центрами Например, чтобы упорядочить транзакции по всему миру, Google Spanner использует TrueTime — атомные часы и GPS-приёмники в каждом ЦОД с известной погрешностью. Перед коммитом транзакция ждёт, пока эта неопределённость не станет нулевой ▶️ Плата за распределённость — дополнительные раунды обмена между узлами: чем больше шардов и реплик проходит транзакция, тем выше задержка 👉 NewSQL выгоден там, где нужна именно горизонтальная масштабируемость, а не предельная скорость одиночного сервера Классификация NewSQL-систем Выделяют два подхода к появлению NewSQL-систем: 1️⃣ Созданные с нуля Опираются на оперативную память (in-memory) и быстрые накопители (SSD) для предельной скорости доступа Например, VoltDB (in-memory NewSQL-СУБД для OLTP-нагрузок реального времени), 2️⃣ Модификация существующих движков Расширяют зрелые СУБД (например, MySQL/MariaDB) новыми движками хранения и оптимизациями Например, Percona Server (оптимизированный форк MySQL), ▶️ Отдельная ветка — связующее ПО (middleware), которое делает прозрачное шардирование над обычными одноузловыми СУБД: Apache ShardingSphere, MaxScale. Это не полноценный NewSQL: такие слои маршрутизируют запросы, но не дают распределённого ACID Примеры СУБД 🔹YDB (Яндекс) — open-source распределённая реляционная SQL-СУБД Горизонтальная масштабируемость, строгая согласованность и ACID-транзакции, совмещение OLTP- и OLAP-нагрузок; язык запросов — YQL (диалект SQL) 🔹CockroachDB — распределённая SQL-база, совместимая с диалектом PostgreSQL, с упором на географическое распределение и живучесть 🔹Tarantool (экосистема VK) — in-memory СУБД с хранимыми процедурами на Lua, синхронной репликацией и автоматическими выборами лидера. Не классический NewSQL, а смежное решение для высоконагруженных сценариев: очереди, кэши, мастер-хранилища с высокой пропускной способностью Когда применять 😫 высоконагруженные OLTP-системы, где критична строгая согласованность данных (финтех, биллинг, обработка платежей) 😫 географически распределённые системы. Когда данные и пользователи размазаны по дата-центрам и регионам, а согласованность всё равно нужна 😫 когда вертикальное масштабирование классической реляционной БД упёрлось в потолок, но переходить на NoSQL с конечной согласованностью нельзя по требованиям бизнеса. Когда НЕ стоит использовать ➖ небольшие проекты с предсказуемой нагрузкой. Классической реляционной БД (MySQL, PostgreSQL) хватит ➖ неструктурированные и слабоструктурированные данные. Соцсети, логи, данные датчиков, вложенные документы — для NoSQL (документные, ключ-значение, графовые БД) Плюсы и минусы ➕ горизонтальная масштабируемость без отказа от строгой согласованности и ACID ➕ привычный SQL и совместимость с реляционными инструментами ➕ отказоустойчивость и высокая доступность за счёт распределённой архитектуры и репликации ➕ подходит для систем с большим потоком параллельных транзакций ➖ сложность настройки, обслуживания и диагностики неполадок по сравнению с классическими реляционными БД ➖ ограниченная переносимость между решениями: разные NewSQL используют разные диалекты SQL и архитектуры, миграция между ними не всегда простая ➖ выше задержка на запись из-за раундов согласования между узлами (консенсус, распределённый коммит) 📎 Материалы 1. Кратко про NewSQL 2. Как выбрать NewSQL-СУБД для вашей компании 3. NewSQL: SQL никуда не уходит 4. NewSQL — новый виток в эволюции BigData 5. Сравнение производительности YDB, CockroachDB и YugabyteDB на бенчмарке YCSB 6. Разбираемся в типах баз данных 📚 Книги 1. Высоконагруженные приложения. Программирование, масштабирование, поддержка — Мартин Клеппман #бд #sql ➿➿➿➿➿➿➿➿➿➿ 🧑‍🎓 Более поробное сравнение в базе знаний по системному анализу

Что делать если все скиллы обесценятся через пару лет? Раньше аналитику хватало умения писать пользовательские сценарии и собирать шаблонное ТЗ. Сегодня простые задачи забирает ИИ, а требования к спецам растут каждый месяц Мы прошерстили рынок и выделили главный навык, который лишь растет в актуальности на фоне событий - АРХИТЕКТУРА. Но глубоко разбираться в ней хотят далеко не все А ведь именно эти знания дают: — Понимание, как устроены микросервисы, REST API и Kafka — Уверенность на технических собеседованиях и выход на архитектурный чек — Защиту от сбоев на проде из-за ошибок в логике — Быстрый рост от СА/БА до фуллстек и арх-уровня Приходи 13 августа в 19:00 (МСК) на бесплатный онлайн-практикум «Архитектура без кода: как стать аналитиком, которого слушают разработчики и бизнес» Разберем связку сервисов, базы данных и построение сценариев на чистом инженерном мышлении. Веб будет полезен джунам и мидлам в аналитике (СА, БА, дата- и фуллстек), а также QA, специалистам поддержки и разработчикам. Регистрируйся по ссылке Erid: 2SDnjeTZDxf Название: ООО "СТЕП БАЙ СТЕП" ИНН: 0800013217

Что делать если все скиллы обесценятся через пару лет? Раньше аналитику хватало умения писать пользовательские сценарии и собирать шаблонное ТЗ. Сегодня простые задачи забирает ИИ, а требования к спецам растут каждый месяц Мы прошерстили рынок и выделили главный навык, который лишь растет в актуальности на фоне событий - АРХИТЕКТУРА. Но глубоко разбираться в ней хотят далеко не все А ведь именно эти знания дают: — Понимание, как устроены микросервисы, REST API и Kafka — Уверенность на технических собеседованиях и выход на архитектурный чек — Защиту от сбоев на проде из-за ошибок в логике — Быстрый рост от СА/БА до фуллстек и арх-уровня Приходи 13 августа в 19:00 (МСК) на бесплатный онлайн-практикум «Архитектура без кода: как стать аналитиком, которого слушают разработчики и бизнес» (ссылка) Разберем связку сервисов, базы данных и построение сценариев на чистом инженерном мышлении. Веб будет полезен джунам и мидлам в аналитике (СА, БА, дата- и фуллстек), а также QA, специалистам поддержки и разработчикам. Регистрируйся по ссылке Erid: 2SDnjeTZDxf Название: ООО "СТЕП БАЙ СТЕП" ИНН: 0800013217

Карьерный лимб между джуном и мидлом — самая обидная точка на рынке Системного Анализа Зарплата в диапазоне 80-120к, задачи уже давно вышли за рамки "просто написать ТЗ", но на собеседованиях на 200к+ ты всё равно можешь посыпаться. Знания раскиданы, старые артефакты забыты, и как доказать, что ты уже Middle — непонятно. Пока твои знания и опыт остаются лоскутным одеялом, а не универсальной системой, приносящей ценность — рынок так и будет видеть в тебе вечного джуна. Валентин Заботин (тимлид СА в Beeline, провел 40+ аналитиков до офферов 185-280К) собрал Middle-Pack SA — по сути, всё, что нужно знать, чтобы выйти в мидлы на текущем рынке. Не "учи всё подряд", а конкретно: куда бить, на чём фокус, что на собесе спрашивают, а что нет. Что внутри: ▪️ Контекст рынка 2026: почему аналитики сидят на 120к и где сейчас открытые двери. ▪️ Харды: 5 конкретных тем, вокруг которых нужно строить свою самопрезентацию (и ссылки на их изучение). ▪️ Резюме: как выкинуть "джуновский" мусор и подсветить нужные артефакты, чтобы не вылетать на этапе HR. ▪️ 3 стратегии карьерного роста в СА без воды. 🤩 Бонус — разбор собеса на оффер 250К в двух частях: тех. часть и самопрезентация. Ты своими глазами увидишь, как нужно презентовать свой опыт так, чтобы тебе поверили и предложили работу. Валентин отдаёт это бесплатно. Сказал, что в будущем может закрыть доступ — так что пока есть, забирайте и применяйте: 👉 @lifeinanalytics_bot

🔼 Server Driven UI (SDUI) Server Driven UI (SDUI) — архитектурный подход, при котором сервер определяет не только данные, но и структуру пользовательского интерфейса (какие компоненты, в каком порядке и с какими параметрами отрисовать на клиенте) 🍃В обычном приложении клиент «знает», как показать экран 🍃В SDUI клиент превращается в «движок рендеринга» — он просто отрисовывает то, что пришло с сервера в виде декларативного описания (обычно JSON) Подход также называют BDUI (Backend-Driven UI) ⭕️В традиционной (client-driven) модели сервер отдаёт только данные, а клиент решает, как их показать: Сервер ➡️ отправляет данные ({"price": 1990, "currency": "RUB"}) Клиент ➡️ знает, как отобразить эти данные на конкретной платформе 🟠В SDUI сервер отдаёт описание интерфейса: Сервер ➡️ отправляет компоненты и их свойства ({"type": "price_label", "props": {"text": "1 990 ₽"}}) Клиент ➡️ по описанию собирает экран из готовых нативных компонентов ❗️Ключевое отличие: логика «что и где показать» переезжает с клиента на сервер Как работает Система состоит из трёх частей: 1⃣ UI-кит (компонентная база) — набор реализованных на каждой платформе нативных компонентов (кнопка, карточка, баннер, список). Это «общий язык» между сервером и клиентом. 2⃣ Движок рендеринга — клиентский механизм, который по описанию из JSON собирает экран: находит нужный компонент в UI-ките и передаёт ему свойства. 3⃣ Контракт (директивы) — описание экрана, которое сервер отдаёт клиенту. Типовой поток 1. На сервере формируется описание экрана (какие компоненты, порядок, свойства, действия). 2. Клиент запрашивает конфигурацию и получает JSON 3. Движок рендеринга разбирает JSON, по type находит компоненты в реестре и отрисовывает их 4. Пользователь взаимодействует (например, нажимает кнопку) — клиент выполняет действие (action), пришедшее вместе с компонентом 5. Нужно поменять экран — правка конфигурации на сервере, при следующем открытии приложения пользователи видят новый UI без обновления из стора Принципы SDUI ⭕️ Начинать с экрана, а не с данных. API проектируется под то, что нужно показать, а не под структуру БД (demand-driven подход). ⭕️ Минимум логики на клиенте. Любой if/else про «что показать» — кандидат на переезд на сервер. Иначе логика дублируется на каждой платформе. ⭕️ Отдавать продуктную информацию, а не доменные данные. Вместо price: 1990 + currency сервер сразу отдаёт готовую строку "1 990 ₽". Форматирование, локализация, скругления — на сервере. ⭕️ Единая дизайн-система. Все клиенты используют общий UI-кит, тогда серверная инструкция «отрисуй primary-кнопку» даст одинаковый результат везде. ⭕️ Внедрять инкрементально. Не переписывать всё приложение сразу, а начать с одного экрана или компонента (например, баннера на главной). Плюсы и минусы ✅ мгновенные обновления UI — без релизов в сторах и ожидания обновления у пользователей ✅ кроссплатформенность из коробки — один JSON рендерится на iOS, Android, Web ✅ простой A/B-тестинг и персонализация — разный UI разным сегментам одним изменением на сервере ✅ единообразие платформ — все клиенты синхронны, расхождений почти нет ✅ снижение нагрузки на мобильную разработку — фронт не верстает каждый экран с нуля ➖ без интернета UI не загрузится; нужны кэширование и фолбэки, иначе пустые экраны ➖ сложность старта — нужен UI-кит, движок рендеринга и серверная часть под это ➖ двойная поддержка компонентов — компоненты живут и на клиенте (реализация), и на сервере (описание) ➖сложнее отладка — труднее понять, почему экран выглядит именно так (собрался динамически) ➖ риск «зашить» бизнес-логику в UI — границы между слоями легко размыть Где используется Когда много платформ, а интерфейс меняется часто и под разные сегменты пользователей: 🟠 Travel- и маркетплейс-платформы — быстрые итерации UI в разделах с динамическим контентом 🟠 соцсети и стриминговые сервисы — мгновенный rollout изменений и экспериментов 🟠 e-commerce и маркетплейсы — разные раскладки витрин для разных продавцов (например, блок «Бестселлеры» только для крупных магазинов) 🟠когда нужно обновлять интерфейс с сервера, не зависеть от сторов 📎 Материалы 1. Чем полезен Server Driven UI 2. Яндекс выпускает DivKit — фреймворк для server-driven UI с открытым кодом 3. Server Driven UI в Альфа-Банке 4. Server-Driven UI архитектура: server-driven vs content-driven 5. Как работает Server-Driven UI и зачем он фронтендеру #архитектура ➿➿➿➿➿➿➿➿➿➿ 🧑‍🎓 Более поробное сравнение в базе знаний по системному анализу

Почему ChatGPT заканчивается там, где начинается реальная работа Системному аналитику ChatGPT далеко не всегда можно использовать в рабочих задачах — и это не просто требование службы информационной безопасности. Когда приходится работать с внутренними требованиями, спецификациями, API-документацией, архитектурными схемами или коммерческой информацией, передавать эти данные внешним сервисам нельзя. При этом задачи остаются прежними: искать нужные требования, сопоставлять документы, разбираться в изменениях и быстро находить ответы в корпоративной базе знаний. Ответ рынка — локальные LLM (большие языковые модели) в закрытом контуре с собственным RAG и MCP-интеграциями. Такой ассистент работает с внутренними документами, обращается к корпоративным сервисам через MCP-сервер и не отправляет ни одного токена за пределы инфраструктуры. Первый работающий прототип сегодня можно собрать без программирования. 15 июля в 18:00 мск на бесплатном вебинаре «Прототипирование LLM: как создаются ИИ-ассистенты для реальных задач» Ярослав Шуваев, CEO Panteoꓸai и преподаватель MBA в РАНХиГС, покажет, как такой подход реализуется на практике. На вебинаре вы получите: — понимание, из каких компонентов состоит современный ИИ-ассистент и как они работают вместе; — рабочий прототип Telegram-бота, который отвечает по документации, а не придумывает ответы; — понимание, где no-code действительно закрывает задачу, а где без кода уже не обойтись; — гайд «Почему ваш ИИ пишет не то» с разбором различий между LLM и ИИ-агентом. Всем зарегистрированным придет запись эфира на почту — присоединяйтесь по ссылке: https://clc.to/erid_2W5zFG7go8V Реклама. ООО «КАРПОВ КУРСЫ». ИНН 7811764627. erid: 2W5zFG7go8V

📊 Сравнение Баз данных и Хранилищ данных ▫️База данных – оперативное хранилище, где содержится "текущее состояние" бизнес-процессов: активные заказы, остатки на складе, профили пользователей и тд ▫️ OLTP (Online Transaction Processing) — обработка транзакций онлайн, способ эксплуатации этой базы 💙Хранилище данных (DWH)— информационная система, в которой хранятся данные из разных источников. Используется для анализа, составления отчетов и интеграции данных транзакций. 💙OLAP (Online Analytical Processing) —  способ доступа и анализа этих данных 🔹 Наши посты ▫️Основные понятия баз данных ▫️Нормальные формы баз данных ▫️Типы связей в БД. Нормализация ▫️Денормализация в БД ▫️Колоночные БД, Cassandra vs PostreSQL ▫️Требования ACID: Краткий обзор ▫️Масштабирование БД. Партиционирование, шардирование и репликация ▫️Требования ACID: Краткий обзор 💙Data Warehouse (DWH) 💙OLTP и OLAP #инфраструктура #бд ➿➿➿➿➿➿➿➿➿➿ 🧑‍🎓 Более поробное сравнение в базе знаний по системному анализу

Аналитики, время входить в прайм к осеннему найму 💅 подтянуть тех базу и ухватить сочный оффер на 300+К И если масштабирование баз данных вызывает пока больше вопросов чем азарта - приходи 10 июля на наш веб в 19:00 мск Подтянем твою техничку на реальных рабочих задачах прямо на бесплатном вебинаре - приходи онлайн, записи не будет. + ты сможешь получить бесплатный разбор компетенций и персональный план развития от практикующих старших аналитиков, если будешь активно участвовать в программе веба 10 июля ждем тебя на вебе “Масштабирование реляционных БД. На чем сыпятся даже сеньоры” Ведущий: Сооснователь Академии Системного Анализа StepbyStep Дмитрий Колосов — практикующий техлид в крупном e-com холдинге Для кого: Для мидлов, которые устали соглашаться на «сотку+-», боятся отказов на System Design и готовы выйти на честные 350к+. Регистрируйся по ссылке Erid: 2SDnje3kqna Название: ООО "СТЕП БАЙ СТЕП" ИНН: 0800013217

🖥 Нашёл канал, который советую всем, кто в айтишке или только заходит в сферу - Listen IT. Автор выкладывает аудио-версии статей на ИТ-темы в коротком и понятном формате: технологии, роли в ИТ, лучшие практики, инструменты. Идеально, чтобы слушать в дороге или на фоне - за пару минут разбираешь тему, на которую обычно нет времени сесть и почитать. Для подготовки к собесам по системному анализу - самое оно 👍. Плюс ребята недавно запустили сайт qomp.club с квизами по каждому выпуску, чтобы закрепить материал, а не просто послушать бездумно. Он сделан в стилистике старой Винды 🪟 (даже звуки кликов по папочкам те самые из детства) - олдскулы сводит моментально) Вспомнил, как играть в Сапёра - залип на 2 часа) Что из выпусков понравилось: ▪️ Что такое RAG ▪️ 30 ПОЛЕЗНЫХ КОМАНД GIT ▪️ Что такое HTTP/3 за 8 минут ▪️ Что такое ОРКЕСТРАЦИЯ и ХОРЕОГРАФИЯ МИКРОСЕРВИСОВ за 14 минут ▪️ Что такое КЭШ за 16 минут: Проектируем эффективное кэширование В общем, подписывайся на Listen IT и залетай на Комп - там ещё много чего интересного.