Системный Аналитик
Відкрити в Telegram
Канал для системных аналитиков и не только: подборки полезных материалов на все случаи жизни. Реклама и сотрудничество @radale https://gosuslugi.ru/snet/67b0613c6411ff785396754a
Показати більше📈 Аналітичний огляд Telegram-каналу Системный Аналитик
Канал Системный Аналитик (@sys_sa) у мовному сегменті Російська є активним учасником. На даний момент спільнота об'єднує 19 097 підписників, посідаючи 6 703 місце в категорії Технології та додатки та 34 208 місце у регіоні Росія.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 19 097 підписників.
За останніми даними від 06 жовтня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на 17, а за останні 24 години на -13, загальне охоплення залишається високим.
- Статус верифікації: Не верифікований
- Рівень залученості (ER): Середній показник залученості аудиторії становить 13.42%. Протягом перших 24 годин після публікації контент зазвичай збирає 8.29% реакцій від загальної кількості підписників.
- Охоплення публікацій: В середньому кожен допис отримує 2 563 переглядів. Протягом першої доби публікація в середньому набирає 1 583 переглядів.
- Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 11.
- Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як api, архитектура, собеседование, транзакция, документация.
📝 Опис та контентна політика
Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“Канал для системных аналитиков и не только: подборки полезных материалов на все случаи жизни.
Реклама и сотрудничество @radale
https://gosuslugi.ru/snet/67b0613c6411ff785396754a”
Завдяки високій частоті оновлень (останні дані отримано 07 жовтня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
19 097
Підписники
-1324 години
-177 днів
+1730 днів
Триває завантаження даних...
Схожі канали
Хмара тегів
Вхідні та вихідні згадування
---
---
---
---
---
---
Залучення підписників
жовтень '26жовт '26
жовтень '26
+18
в 0 каналах
вересень '26
+127
в 1 каналах
Get PRO
серпень '26
+102
в 0 каналах
Get PRO
липень '26
+130
в 1 каналах
Get PRO
червень '26
+148
в 1 каналах
Get PRO
травень '26
+105
в 2 каналах
Get PRO
квітень '26
+126
в 0 каналах
Get PRO
березень '26
+203
в 2 каналах
Get PRO
лютий '26
+226
в 1 каналах
Get PRO
січень '26
+260
в 2 каналах
Get PRO
грудень '25
+237
в 2 каналах
Get PRO
листопад '25
+252
в 2 каналах
Get PRO
жовтень '25
+153
в 3 каналах
Get PRO
вересень '25
+146
в 1 каналах
Get PRO
серпень '25
+239
в 3 каналах
Get PRO
липень '25
+330
в 2 каналах
Get PRO
червень '25
+369
в 3 каналах
Get PRO
травень '25
+488
в 4 каналах
Get PRO
квітень '25
+542
в 2 каналах
Get PRO
березень '25
+601
в 3 каналах
Get PRO
лютий '25
+659
в 2 каналах
Get PRO
січень '25
+683
в 1 каналах
Get PRO
грудень '24
+520
в 4 каналах
Get PRO
листопад '24
+611
в 1 каналах
Get PRO
жовтень '24
+593
в 4 каналах
Get PRO
вересень '24
+1 517
в 2 каналах
Get PRO
серпень '24
+858
в 1 каналах
Get PRO
липень '24
+818
в 4 каналах
Get PRO
червень '24
+769
в 7 каналах
Get PRO
травень '24
+806
в 3 каналах
Get PRO
квітень '24
+996
в 5 каналах
Get PRO
березень '24
+804
в 5 каналах
Get PRO
лютий '24
+757
в 3 каналах
Get PRO
січень '24
+809
в 5 каналах
Get PRO
грудень '23
+802
в 5 каналах
Get PRO
листопад '23
+1 339
в 4 каналах
Get PRO
жовтень '23
+1 487
в 6 каналах
Get PRO
вересень '23
+1 839
в 0 каналах
| Дата | Залучення підписників | Згадування | Канали | |
| 07 жовтня | +2 | |||
| 06 жовтня | 0 | |||
| 05 жовтня | +3 | |||
| 04 жовтня | 0 | |||
| 03 жовтня | +1 | |||
| 02 жовтня | +8 | |||
| 01 жовтня | +4 |
Дописи каналу
😱 Отправили свое резюме на 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 |
