Системный Аналитик
Open in Telegram
Канал для системных аналитиков и не только: подборки полезных материалов на все случаи жизни. Реклама и сотрудничество @radale https://gosuslugi.ru/snet/67b0613c6411ff785396754a
Show more📈 Analytical overview of Telegram channel Системный Аналитик
Channel Системный Аналитик (@sys_sa) in the Russian language segment is an active participant. Currently, the community unites 19 097 subscribers, ranking 6 703 in the Technologies & Applications category and 34 208 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 19 097 subscribers.
According to the latest data from 06 October, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by 17 over the last 30 days and by -13 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 13.42%. Within the first 24 hours after publication, content typically collects 8.29% reactions from the total number of subscribers.
- Post reach: On average, each post receives 2 563 views. Within the first day, a publication typically gains 1 583 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 11.
- Thematic interests: Content is focused on key topics such as api, архитектура, собеседование, транзакция, документация.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“Канал для системных аналитиков и не только: подборки полезных материалов на все случаи жизни.
Реклама и сотрудничество @radale
https://gosuslugi.ru/snet/67b0613c6411ff785396754a”
Thanks to the high frequency of updates (latest data received on 07 October, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
19 097
Subscribers
-1324 hours
-177 days
+1730 days
Data loading in progress...
Similar Channels
Tags Cloud
Incoming and Outgoing Mentions
---
---
---
---
---
---
Attracting Subscribers
October '26Oct '26
October '26
+18
in 0 channels
September '26
+127
in 1 channels
Get PRO
August '26
+102
in 0 channels
Get PRO
July '26
+130
in 1 channels
Get PRO
June '26
+148
in 1 channels
Get PRO
May '26
+105
in 2 channels
Get PRO
April '26
+126
in 0 channels
Get PRO
March '26
+203
in 2 channels
Get PRO
February '26
+226
in 1 channels
Get PRO
January '26
+260
in 2 channels
Get PRO
December '25
+237
in 2 channels
Get PRO
November '25
+252
in 2 channels
Get PRO
October '25
+153
in 3 channels
Get PRO
September '25
+146
in 1 channels
Get PRO
August '25
+239
in 3 channels
Get PRO
July '25
+330
in 2 channels
Get PRO
June '25
+369
in 3 channels
Get PRO
May '25
+488
in 4 channels
Get PRO
April '25
+542
in 2 channels
Get PRO
March '25
+601
in 3 channels
Get PRO
February '25
+659
in 2 channels
Get PRO
January '25
+683
in 1 channels
Get PRO
December '24
+520
in 4 channels
Get PRO
November '24
+611
in 1 channels
Get PRO
October '24
+593
in 4 channels
Get PRO
September '24
+1 517
in 2 channels
Get PRO
August '24
+858
in 1 channels
Get PRO
July '24
+818
in 4 channels
Get PRO
June '24
+769
in 7 channels
Get PRO
May '24
+806
in 3 channels
Get PRO
April '24
+996
in 5 channels
Get PRO
March '24
+804
in 5 channels
Get PRO
February '24
+757
in 3 channels
Get PRO
January '24
+809
in 5 channels
Get PRO
December '23
+802
in 5 channels
Get PRO
November '23
+1 339
in 4 channels
Get PRO
October '23
+1 487
in 6 channels
Get PRO
September '23
+1 839
in 0 channels
| Date | Subscriber Growth | Mentions | Channels | |
| 07 October | +2 | |||
| 06 October | 0 | |||
| 05 October | +3 | |||
| 04 October | 0 | |||
| 03 October | +1 | |||
| 02 October | +8 | |||
| 01 October | +4 |
Channel Posts
😱 Отправили свое резюме на 129 вакансий на хх, а в ответ тишина ..
Думаете, что дело в рынке труда или вашем опыте?
Скорее всего нет. Процесс поиска работы сейчас - это четкий алгоритм действий, это машина, алгоритмы и авто-фильтры, которые меняются каждую неделю. Если опыт упакован неправильно, ваше резюме даже не дойдет до живого человека.
6 октября (вторник) в 18:00 по МСК: бесплатный открытый эфир с живым разбором резюме для проджектов, продактов, аналитиков, разработчиков разных грейдов
На эфире разберем:
🔴почему ваше резюме не доходит до человека
🔴4 типовые стратегические ошибки в позиционировании
🔴откуда взять достижения
🔴почему вас отметают рекруты на скрининге или все-таки сколько просить денег?
🔴Q&A - обсудим именно вашу ситуацию
Кто ведёт
Ольга Романова, руководитель проектных и продуктовых офисов с опытом в IT более 13 лет, основатель «Карьерной группы». По её программе карьерного сопровождения 94% участников за 3–4 месяца получают офферы в Авито, Яндексе, Т-Банке, OZON и других топовых компаниях. Зарплаты от 190 тыс. ₽ у администратора проекта до 1,4 млн ₽ у технического владельца продукта..
👉🏻 Отправить свое резюме на разбор и зарегистрироваться можно по ссылке ниже:
<РЕГИСТРАЦИЯ>
Erid: 2VtzqwzstaZ
| 2 |  Что на самом деле происходит в процессах — и как это увидеть
8–9 октября собираемся в загородном клубе на конференции VK Business Analytics.
Это встреча для тех, кто развивает процессную аналитику и хочет обсуждать не теорию, а реальные процессы и проекты.
В программе:
✈️ «Аэрофлот» разберет свой проект по Process Mining: какие процессы исследовали, что обнаружили в данных и что в итоге изменили.
🔎«Некст» покажет, что часто остается за пределами регламентов: обходные маршруты, ручные операции и решения, которые принимаются вопреки процессу.
🤖 VK AI Space расскажет, как данные об операциях сотрудников становятся основой для AI-агентов и новых сценариев автоматизации.
А после деловой части — бизнес-игра, вечер у озера, гриль, коктейли, караоке и неформальное общение с коллегами по рынку. Можно остаться с ночевкой: у каждого участника отдельный номер. Утром — завтрак и спа, затем возвращаемся в Москву.
Количество мест ограничено, участие по регистрации.
Зарегистрироваться | 2 104 |
| 3 | 🔼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 для профессионалов — Гэвин Рой
#проектирование #интеграции
➿➿➿➿➿➿➿➿➿➿
🧑🎓 Более поробное сравнение в базе знаний по системному анализу | 3 335 |
| 4 |  Как облегчить работу ИТ-аналитика уже сейчас — без долгосрочных перестроек процессов?
Обсудим на IT-analyst Meetup от Сбера! В программе — прикладные доклады:
— Как эффективнее использовать возможности мозга
— Какие навыки развивать аналитику и как выстроить план роста
— SDD на практике: подводные камни внедрения и новые зоны ответственности аналитика
📆 29 сентября
📍 Офис Сбера (Кутузовский пр-т, 32) и трансляция онлайн
Выбирайте удобный формат и регистрируйтесь по ссылке | 2 407 |
| 5 |  ️️️️️️️️📚Курс: «Системный аналитик. Экспертный уровень». За 146 часов обучения получите актуальные навыки и работу над реальными проектами на практике.
🎁 Записывайтесь на 3 бесплатных вебинара — познакомьтесь с программой обучения и преподавателями. Задайте свои вопросы экспертам!
1⃣29 сентября, 20:00 мск — «Зелёные тесты, неверный продукт»: разберём, почему ИИ-агент может пройти тесты, но реализовать не то, что нужно, и как аналитику поймать такую ошибку до релиза.
2⃣14 октября, 20:00 мск — «ИИ-агент как супероружие СА: ТЗ за 10 минут»: соберём пайплайн в n8n, который превращает сырые заметки в структурированный черновик ТЗ без лишних фантазий.
3⃣21 октября, 20:00 мск — «Анатомия сопротивления»: разберём, как распознать скрытый саботаж стейкхолдеров и довести внедрение до релиза без срывов сроков и выгорания.
Записывайтесь ➡ https://otus.pw/8T9w/
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru | 2 559 |
| 6 |  Не отставайте от рынка — учитесь со скидкой 16%
Если чувствуете, что стоите на месте, и хотите освоить востребованную профессию, — сейчас хороший момент начать.
Потому что до 30 сентября на все курсы Практикума действует скидка 16%.
Выбрать курс
Вы сможете:
— получить актуальные навыки;
— освоить ИИ-инструменты для работы;
— перенять опыт экспертов, которые двигают индустрию;
— попасть в сообщество выпускников, где можно попросить совета и, возможно, найти будущих коллег.
Просто выберите курс, начните учиться бесплатно и получите скидку 16% — она автоматически появится в личном кабинете.
Учиться!
Erid: 2SDnje3hmV5
Название: ООО "ЯНДЕКС"
ИНН: 7736207543 | 1 952 |
| 7 |  Пока вы собираете требования в одиночку, кто-то уже руководит целой аналитической командой...
Узнайте, как управлять командой системных аналитиков эффективно за 5 месяцев обучения вместе с OTUS на курсе «Системный аналитик. Управление командой»
🎁 Записывайтесь на 2 бесплатных вебинара — познакомьтесь с программой обучения и преподавателями. Задайте свои вопросы экспертам!
1️⃣ 8 сентября, 20:00 мск — «Системный аналитик и его ценность глазами компании»: разберём, как грамотная работа аналитика повышает эффективность команды и продукта, и почему бизнес готов платить за эту ценность.
2️⃣ 23 сентября, 20:00 мск — «Как проводить архитектурное ревью и находить риски до начала разработки»: научимся находить узкие места и точки отказа до старта разработки, чтобы архитектура не рассыпалась при запуске продукта.
Записывайтесь ➡️ https://otus.pw/my9Z/?erid=2W5zFJ4hi1o
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963. | 1 747 |
| 8 |  100 откликов, 0 собеседований. Знакомо?
Можно конечно продолжать винить рынок, каждые 5 минут обновлять HH, переписывать резюме в десятый раз
Но лучше - наконец разобраться кого в этот период активно нанимают и перестроить маршрут
Сейчас мало знать REST, SQL и прочий инструментарий
На собесы за 250-300к+ зовут тех, кто понимает, как всё это работает вместе и как спроектировать систему
Сильный айти спец сегодня - это человек, который понимает архитектуру решений целиком
4 сентября в 19:00 МСК на бесплатном вебе «Архитектура без кода» покажем, как прокачать этот навык
Веб для джунов и мидлов системной и бизнес-аналитики, QA, дата-аналитиков, разработчиков.
Для всех, кто хочет оставаться в АйТи и нормально зарабатывать
Регистрируйся здесь
Erid: 2SDnjdVJmgX
Название: ООО "СТЕП БАЙ СТЕП"
ИНН: 0800013217 | 2 068 |
| 9 | ❓ 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 — Хизер Адкинс, Бетси Бейер и др.
#инфраструктура
➿➿➿➿➿➿➿➿➿➿
🧑🎓 Более поробное сравнение в базе знаний по системному анализу | 6 270 |
| 10 |  Как аналитику без опыта найти работу❓
Вокруг IT‑рынка сейчас много пугающих слухов. Но по факту вакансии открываются, а компании активно ищут толковых специалистов.
Вопрос не в том, есть ли места. Вопрос — умеешь ли ты правильно анализировать рынок, писать продающее резюме и самопрезентацию.
Про это уже пишет Николай — системный аналитик с 10+ годами опыта в топовых IT-компаниях.
Записки системного аналитика — канал про системный анализ и путь в профессию, где Николай разбирает, как в 2026 году реально устроиться аналитиком.
🔥 Уже в канале:
1) Почему ИИ не заменит профессию СА
2) Как успешно пройти собеседование на 250К и позицию Middle+
3) Авторский гайд по профессии СА в 5 статьях
Подписывайся, чтобы получить получить оффер на позицию системного аналитика и повысить свой доход: t.me/+bJGfbHW8TgEwMWNi | 2 035 |
| 11 |  Сокращения в желтом банке 💳
Системный аналитик из этой истории попал под сокращение в банке и рассказал, как там решили перестроить целый департамент вокруг ИИ
Основная идея: убрать все роли и нанять универсального продуктового инженера, который будет делать всё с помощью ИИ
Спойлер: новые чудо-инженеры приходить не спешат
Вита Заебумба | Путь корпората — топовый канал про IT, сферу найма, трешовые собесы и работу в корпорациях. Просто кладезь кулстори не только от автора, но и от подписчиков
Истории, которые уже успели стать бестселлером:
🔸Как бигтехи кошмарят вас на собеседованиях ❤️
🔸Поймала интервьюеров за руку на собесе в Ягодках 🛍
🔸Мое мнение, что будет с рынком найма в 2026 году + полезные материалы
🔸Эффект Писюхи, или как я столкнулась с эйджизмом в найме
🔸Aston, разлогинься, или как продать себя в рабство
Но тут не только про корпоративный цирк. Подписывайтесь, если хотите:
🔹понимать, что происходит на рынке IT
🔹читать реальные истории найма и собеседований
🔹узнавать внутрянку компаний от людей, которые там работают
🔹следить за тем, как ИИ меняет нашу работу
👉 @vitazaebymba | 3 058 |
| 12 | 🖥 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
➿➿➿➿➿➿➿➿➿➿
🧑🎓 Более поробное сравнение в базе знаний по системному анализу | 6 412 |
| 13 |  Что делать если все скиллы обесценятся через пару лет?
Раньше аналитику хватало умения писать пользовательские сценарии и собирать шаблонное ТЗ. Сегодня простые задачи забирает ИИ, а требования к спецам растут каждый месяц
Мы прошерстили рынок и выделили главный навык, который лишь растет в актуальности на фоне событий - АРХИТЕКТУРА. Но глубоко разбираться в ней хотят далеко не все
А ведь именно эти знания дают:
— Понимание, как устроены микросервисы, REST API и Kafka
— Уверенность на технических собеседованиях и выход на архитектурный чек
— Защиту от сбоев на проде из-за ошибок в логике
— Быстрый рост от СА/БА до фуллстек и арх-уровня
Приходи 13 августа в 19:00 (МСК) на бесплатный онлайн-практикум «Архитектура без кода: как стать аналитиком, которого слушают разработчики и бизнес»
Разберем связку сервисов, базы данных и построение сценариев на чистом инженерном мышлении.
Веб будет полезен джунам и мидлам в аналитике (СА, БА, дата- и фуллстек), а также QA, специалистам поддержки и разработчикам.
Регистрируйся по ссылке
Erid: 2SDnjeTZDxf
Название: ООО "СТЕП БАЙ СТЕП"
ИНН: 0800013217 | 3 084 |
| 14 | Что делать если все скиллы обесценятся через пару лет?
Раньше аналитику хватало умения писать пользовательские сценарии и собирать шаблонное ТЗ. Сегодня простые задачи забирает ИИ, а требования к спецам растут каждый месяц
Мы прошерстили рынок и выделили главный навык, который лишь растет в актуальности на фоне событий - АРХИТЕКТУРА. Но глубоко разбираться в ней хотят далеко не все
А ведь именно эти знания дают:
— Понимание, как устроены микросервисы, REST API и Kafka
— Уверенность на технических собеседованиях и выход на архитектурный чек
— Защиту от сбоев на проде из-за ошибок в логике
— Быстрый рост от СА/БА до фуллстек и арх-уровня
Приходи 13 августа в 19:00 (МСК) на бесплатный онлайн-практикум «Архитектура без кода: как стать аналитиком, которого слушают разработчики и бизнес» (ссылка)
Разберем связку сервисов, базы данных и построение сценариев на чистом инженерном мышлении.
Веб будет полезен джунам и мидлам в аналитике (СА, БА, дата- и фуллстек), а также QA, специалистам поддержки и разработчикам.
Регистрируйся по ссылке
Erid: 2SDnjeTZDxf
Название: ООО "СТЕП БАЙ СТЕП"
ИНН: 0800013217 | 1 |
| 15 |  Карьерный лимб между джуном и мидлом — самая обидная точка на рынке Системного Анализа
Зарплата в диапазоне 80-120к, задачи уже давно вышли за рамки "просто написать ТЗ", но на собеседованиях на 200к+ ты всё равно можешь посыпаться. Знания раскиданы, старые артефакты забыты, и как доказать, что ты уже Middle — непонятно.
Пока твои знания и опыт остаются лоскутным одеялом, а не универсальной системой, приносящей ценность — рынок так и будет видеть в тебе вечного джуна.
Валентин Заботин (тимлид СА в Beeline, провел 40+ аналитиков до офферов 185-280К) собрал Middle-Pack SA — по сути, всё, что нужно знать, чтобы выйти в мидлы на текущем рынке. Не "учи всё подряд", а конкретно: куда бить, на чём фокус, что на собесе спрашивают, а что нет.
Что внутри:
▪️ Контекст рынка 2026: почему аналитики сидят на 120к и где сейчас открытые двери.
▪️ Харды: 5 конкретных тем, вокруг которых нужно строить свою самопрезентацию (и ссылки на их изучение).
▪️ Резюме: как выкинуть "джуновский" мусор и подсветить нужные артефакты, чтобы не вылетать на этапе HR.
▪️ 3 стратегии карьерного роста в СА без воды.
🤩 Бонус — разбор собеса на оффер 250К в двух частях: тех. часть и самопрезентация. Ты своими глазами увидишь, как нужно презентовать свой опыт так, чтобы тебе поверили и предложили работу.
Валентин отдаёт это бесплатно. Сказал, что в будущем может закрыть доступ — так что пока есть, забирайте и применяйте:
👉 @lifeinanalytics_bot | 3 030 |
| 16 | 🔼 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 и зачем он фронтендеру
#архитектура
➿➿➿➿➿➿➿➿➿➿
🧑🎓 Более поробное сравнение в базе знаний по системному анализу | 4 647 |
| 17 | Почему 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 | 2 528 |
| 18 |  📊 Сравнение Баз данных и Хранилищ данных
▫️База данных – оперативное хранилище, где содержится "текущее состояние" бизнес-процессов: активные заказы, остатки на складе, профили пользователей и тд
▫️ OLTP (Online Transaction Processing) — обработка транзакций онлайн, способ эксплуатации этой базы
💙Хранилище данных (DWH)— информационная система, в которой хранятся данные из разных источников. Используется для анализа, составления отчетов и интеграции данных транзакций.
💙OLAP (Online Analytical Processing) — способ доступа и анализа этих данных
🔹 Наши посты
▫️Основные понятия баз данных
▫️Нормальные формы баз данных
▫️Типы связей в БД. Нормализация
▫️Денормализация в БД
▫️Колоночные БД, Cassandra vs PostreSQL
▫️Требования ACID: Краткий обзор
▫️Масштабирование БД. Партиционирование, шардирование и репликация
▫️Требования ACID: Краткий обзор
💙Data Warehouse (DWH)
💙OLTP и OLAP
#инфраструктура #бд
➿➿➿➿➿➿➿➿➿➿
🧑🎓 Более поробное сравнение в базе знаний по системному анализу | 4 874 |
| 19 |  Аналитики, время входить в прайм к осеннему найму 💅 подтянуть тех базу и ухватить сочный оффер на 300+К
И если масштабирование баз данных вызывает пока больше вопросов чем азарта
- приходи 10 июля на наш веб в 19:00 мск
Подтянем твою техничку на реальных рабочих задачах прямо на бесплатном вебинаре - приходи онлайн, записи не будет.
+ ты сможешь получить бесплатный разбор компетенций и персональный план развития от практикующих старших аналитиков, если будешь активно участвовать в программе веба
10 июля ждем тебя на вебе “Масштабирование реляционных БД. На чем сыпятся даже сеньоры”
Ведущий: Сооснователь Академии Системного Анализа StepbyStep Дмитрий Колосов — практикующий техлид в крупном e-com холдинге
Для кого: Для мидлов, которые устали соглашаться на «сотку+-», боятся отказов на System Design и готовы выйти на честные 350к+.
Регистрируйся по ссылке
Erid: 2SDnje3kqna
Название: ООО "СТЕП БАЙ СТЕП"
ИНН: 0800013217 | 2 309 |
| 20 | 🖥 Нашёл канал, который советую всем, кто в айтишке или только заходит в сферу - Listen IT.
Автор выкладывает аудио-версии статей на ИТ-темы в коротком и понятном формате: технологии, роли в ИТ, лучшие практики, инструменты. Идеально, чтобы слушать в дороге или на фоне - за пару минут разбираешь тему, на которую обычно нет времени сесть и почитать.
Для подготовки к собесам по системному анализу - самое оно 👍.
Плюс ребята недавно запустили сайт qomp.club с квизами по каждому выпуску, чтобы закрепить материал, а не просто послушать бездумно. Он сделан в стилистике старой Винды 🪟 (даже звуки кликов по папочкам те самые из детства) - олдскулы сводит моментально) Вспомнил, как играть в Сапёра - залип на 2 часа)
Что из выпусков понравилось:
▪️ Что такое RAG
▪️ 30 ПОЛЕЗНЫХ КОМАНД GIT
▪️ Что такое HTTP/3 за 8 минут
▪️ Что такое ОРКЕСТРАЦИЯ и ХОРЕОГРАФИЯ МИКРОСЕРВИСОВ за 14 минут
▪️ Что такое КЭШ за 16 минут: Проектируем эффективное кэширование
В общем, подписывайся на Listen IT и залетай на Комп - там ещё много чего интересного. | 2 488 |
