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

Как выйти в мидлы СА на "стагнирующем" рынке — без года проб и отказов Валентин Заботин (тимлид Beeline и ментор) упаковал весь свой опыт на рынке и собрал Middle-Pack SA — по сути, полноценный ультимативный гайд получения крупных офферов в 2026 году для джунов и тех, кто застрял на низких грейдах. Пройдя его, ты: ▪️поймешь реальный контекст рынка, узнаешь своих реальных конкурентов в лицо, ▪️заберешь ТОП-3 стратегии карьерного роста, ▪️поймешь, на чем держать фокус в хард-скиллах + референсы, чтобы успешно проходить собесы и быть сильным игроком в работе, ▪️улучшишь свое резюме и больше не будешь редфлагом на рынке, ▪️разберешься, как правильно себя презентовать и эффективно проходить собесы на высокие грейды. 🤩 Также Валентин бонусом бесплатно отдает подробнейший разбор собеса на оффер 250к, чтобы ты не тратил время на хаотичный поиск информации в интернете. Забирай и применяй все инструменты из мидл-пака: ➡️ @lifeinanalytics_bot erid: 2VtzqxYvTf2

❗️ Управляйте командой и будьте системным аналитиком. ❓ Как? 💎 Узнайте про актуальные навыки и инструменты на курсе «Системный аналитик. Team Lead». 📚 Записывайтесь на 3 открытых вебинара — познакомьтесь с программой обучения и преподавателями. Обсуждайте с экспертами и задавайте вопросы 📗 Вебинар 1: «Как системный аналитик снизил технический долг и ускорил разработку без переписывания кода» ⏰ 25 февраля в 20:00 мск. Программа вебинара: 1. Как распознать признаки технического долга и архитектурных проблем на уровне требований и структуры системы. 2. Как читать код и архитектуру «глазами аналитика» и задавать правильные вопросы разработчикам. 3. На практике покажем, как формулировать требования и рекомендации по улучшению системы, которые 100% ускоряют разработку и снижают риски. 📙 Вебинар 2: «Типовая архитектура современной IT-системы» ⏰ 12 марта в 20:00 мск. Программа вебинара: 1. Обзор типовой архитектуры современных систем. 2. Как строить эффективные IT-системы, учитывая ключевые принципы масштабируемости, надежности и безопасности. 3. Границы ответственности и необходимой экспертизы лида системных аналитиков. 📕 Вебинар 3: «Как системный аналитик может использовать ИИ в своей работе» ⏰ 23 марта в 20:00 мск. Программа вебинара: 1. Используем искусственный интеллект для повышения качества аналитических решений, а не только для ускорения рутины. 2. Где проходит граница применимости интеллектуальных инструментов в задачах уровня продукта и архитектуры. 3. Эффективные варианты внедрения искусственного интеллекта в работу аналитика и команды. Записывайтесь ➡️ OTUS.RU Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

🔥 В IT часто горят сроки, потому что бизнес хотел одно, услышали другое, а сделали — третье. В итоге требования плавают, приоритеты спорят между собой, а релиз превращается в испытание. Курс OTUS «Бизнес-аналитик в IT» — для тех, кто хочет управлять смыслом и ожиданиями: выявлять и формализовать потребности стейкхолдеров, связывать бизнес-показатели с целями компании, строить дорожные карты, моделировать процессы в BPMN, работать со сложными заказчиками и фиксировать требования в документации и ТЗ так, чтобы команда разработки могла действовать уверенно. ❓Кому будет полезно: - бизнес- и системным аналитикам — чтобы структурировать инструменты; - продакт-менеджерам — чтобы системно прорабатывать решения; - PM и руководителям — чтобы понимать, как выстроить аналитику в команде; - специалистам из смежных ролей — чтобы сменить карьерный вектор в сторону анализа. ❓Что даст вам этот курс? - Вы освоите все необходимые инструменты для успешного решения задач бизнес-анализа в IT; - Узнаете, какую роль занимает бизнес-аналитик в работе над проектом и почему эта роль не всегда совпадает с позицией специалиста. 🗓 Старт обучения уже совсем скоро - 26 февраля. 👉 Пройдите короткий вступительный тест по ссылке до 22 февраля и получите скидку 10% на обучение Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Как бигтехи кошмарят вас на собеседованиях Успешно пройти секцию по профильным хардам, но смачно опозориться на логической задаче с часами? Классика бигтеха Системный аналитик в этой истории побывал на собесе в ❤️ и рассказал всю правду о клоунаде, которая там происходила Вита Заебумба | Путь корпората — топовый канал про IT, сферу найма, трешовые собесы и работу в корпорациях. Просто кладезь кулстори не только от автора, но и от подписчиков Истории, которые уже успели стать бестселлером: 🟡Поймала дешёвок за руку на собесе в Wildberries 🟡Что будет с рынком найма в 2026 году + полезные материалы 🟡Эффект Писюхи, или как я столкнулась с эйджизмом в найме 🟡Aston, разлогинься, или как продать свою жопу в рабство 🟡Если твой руководитель ведет себя так, беги оттуда Но тут не только про поржать. Подписывайтесь, если хотите: 🔹Продавать резюме так, чтобы вас звали, а не морозили 🔹Понимать, что вообще происходит с рынком 🔹Обойти 90% кандидатов 🔹Не продешевить и не выйти с собеса с чувством, что вас поимели ➡️ @vitazaebymba

Встретились как-то раз аналитик с DS-инженером и продактом, и... аналитик задушнил всех цифрами 😁 Типичная ситуация, но в телеграм-канале «Коммуналка аналитиков» всё не так. Мы рассказываем про цифры с юмором и без духоты. А ещё постим мемы и даём вредные советы 😈 Что у нас есть 📌 Посты о жизни: про перерыв в карьере (с возвратом) и проблемы с часовыми поясами 📌 Аналитика, конечно: про парадокс Симпсона и про то, когда случайность работает на продукт 📌 Реальные кейсы: как автоматизировали фидбэк по дашбордам и почему A/B-тесты показывали ерунду (в двух частях) 📌 Лайтовые посты: про 6 типов аналитиков, а ещё про то, как иногда бесят заказчики и сами аналитики 😉 Мы активно общаемся с подписчиками и отвечаем на их вопросы. Присоединяйтесь к «Коммуналке аналитиков».

⬆️Как прокачать ChatGPT в разы совершенно бесплатно Собрали лайфхаки, которые повысят качество ответов любой нейросети. 1️⃣ Запрещаем нейронке врать

​Прежде чем отвечать, оцени уровень неопределённости своего ответа. Если он превышает 0.1, задай мне уточняющие вопросы до тех пор, пока неопределённость не снизится до 0.1 или ниже.

Промпт ломает привычную схему: не «вопрос → ответ», а «вопрос → уточнение → точный ответ». Нейронка будет: 🔘осознавать, когда ей не хватает информации 🔘переспрашивать, а не выдумывать 🔘давать в разы более точный и аргументированный ответ 2️⃣ Пишем промпты правильно Вот универсальный шаблон: Роль + Цель + Контекст + Ограничения + Формат вывода + Уровень качества. Подробнее писали здесь

Роль: Ты - [тренер/редактор/аналитик].
Цель: достичь [конкретного результата].
Контекст: Вот что тебе нужно знать:
- [предыстория]
- [аудитория]
- [что у меня уже есть]
Ограничения:
- Не [добавляй новые предположения / добавляй дополнительные разделы].
- Если чего-то не хватает, [задай до 3 вопросов] ИЛИ [четко сформулируй предположения].
- Ограничься [X предложениями] или [Y пунктами].
Формат вывода:
- Раздел 1: [краткий ответ]
- Раздел 2: [маркированный список/таблица/контрольный список]
- Раздел 3: [следующие шаги]
Уровень качества:
- Используй простой язык.
- Будь конкретным и действенным.
- Если неясно, скажи, что от чего зависит.

3️⃣ Просим саму нейронку написать промпт Перед тем, как поручить нейронке задачу, попробуйте попросить её улучшить ваш промпт:

Ты промпт-инженер. Напиши профессиональный промпт для запроса ниже:
<ваш запрос>

Так вы получите более точный результат, не потратив время на придумывание идеального промпта. Подробнее здесь 4️⃣ Включаем критическое мышление Когда нейронка даст ответ, заставьте её критически проанализировать свой ответ и предложить улучшения.

Проанализируй свой предыдущий ответ. Найди 3 слабых места и предложи более инновационные подходы. Используй критический анализ и добавь неочевидные инсайты.

Так нейронка посмотрит на проблему под другим углом и исправит свои неточности и даже галлюцинации. 5️⃣ Поэтапное размышление для сложных задач Превращаем ИИ в аналитического ассистента, а не просто в генератора текста, за 3 отдельных промпта: 1. Планирование: пишем промпт как в пункте 2 и добавляем в конце:

Составь план решения и перечисли допущения. Не давай ответ сразу

2. Критика и проверка (как в пункте 4):

Проанализируй свой план. Найди 3 слабых места и предложи более инновационные подходы. Используй критический анализ и добавь неочевидные инсайты. В конце предложи улучшенный план

3. Исполнение: только теперь разрешаем нейронке дать ответ

Теперь дай финальный ответ строго по утверждённому плану.

🔖Сохраняем! 💫💫💫 @it_prompt — подписывайтесь, здесь много полезного

📈 Модель Кано Модель Кано — метод классификации и приоритизации функций продукта на основе их влияния на удовлетворенность пользователей Нужна, чтобы отличать «обязательные» функции от «приятных бонусов», грамотно распределять ресурсы команды Где используется В продуктовой и маркетинговой аналитике, управлении требованиями и разработке: ⚪️приоритизация бэклога ⚪️проектирование MVP: определение минимума для выхода на рынок ⚪️стратегия развития продукта: поиск «фишек» Типичные объекты анализа: ✨функциональные и нефункциональные требования ✨элементы пользовательского интерфейса ✨сервисные параметры (поддержка, скорость, доступность) ✨новые продуктовые гипотезы Рассматриваются два независимых показателя: ➡️удовлетворённость пользователя при наличии характеристики ⬅️ неудовлетворённость пользователя при её отсутствии ❗️отсутствие роста удовлетворённости не означает, что характеристика не нужна Обязательные характеристики не повышают удовлетворённость Но их отсутствие приводит к сильному негативу Категории модели Кано 1️⃣ Must-be (обязательные) Характеристики, которые пользователь считает само собой разумеющимися. ▪️их наличие не повышает удовлетворённость ▪️их отсутствие вызывает сильное недовольство 🤩 пример: авторизация в системе; сохранение данных; базовая безопасность. 2️⃣ One-dimensional (линейные) Характеристики, для которых действует прямая зависимость: чем лучше реализовано, тем выше удовлетворённость ▪️улучшение повышает удовлетворённость ↑ ▪️ухудшение повышает неудовлетворённость ↓ 🤩 пример: скорость работы системы; количество поддерживаемых сценариев; точность поиска 3️⃣ Attractive (восхищающие) Характеристики, которых пользователь не ожидает, но которые вызывают положительные эмоции ▪️отсутствие не расстраивает ▪️наличие резко повышает удовлетворённость 🤩 пример: умные рекомендации; автоматизация рутинных действий; нестандартные UX‑решения 4️⃣ Indifferent (безразличные) Характеристики, которые не влияют ни на удовлетворённость, ни на неудовлетворённость. ▪️пользователь не считает их ценными ▪️часто возникают из внутренних гипотез команды 🤩 пример: редко используемые настройки; декоративные элементы без функциональной нагрузки. 5️⃣ Reverse (обратные) Характеристики, наличие которых ухудшает восприятие продукта Пользователь предпочёл бы их отсутствие 🤩 пример: навязчивая автоматизация; избыточные уведомления; усложнение интерфейса. Общий процесс анализа 1. Определить объект анализа. 2. Сформировать список характеристик. 3. Разработать и провести опрос. 5. Проанализировать результаты с помощью вычислений и матрицы Кано 6. Использовать их для принятия решений. Пример Формирование backlog с помощью модели Кано Результаты анализа используются для приоритизации требований ⚪️Обязательные требования Все характеристики категории Must-be включаются в backlog обязательно Имеют высокий приоритет независимо от пользовательского «восторга» ⚪️ Линейные характеристики Характеристики категории One-dimensional приоритизируются по: ➖степени влияния на удовлетворённость ➖частоте упоминаний ➖стратегической важности Эти требования чаще всего становятся основой roadmap ⚪️Восхищающие характеристики Характеристики категории Attractive: ➖используются для дифференциации продукта ➖добавляются в backlog как продуктовые гипотезы ➖часто реализуются итеративно или экспериментально ⚪️ Безразличные и обратные Indifferent исключаются / откладываются из backlog Reverse удаляются или пересматриваются Ограничения модели Кано ➖субъективность ➖зависимость от формулировок вопросов ➖изменение ожиданий со временем 📎 Материалы 1. Модель Кано. Практическое руководство по приоритизации фич 2. Объяснение модели Кано: анализ и примеры 3. Объяснение модели Кано 4. Что такое модель Кано: как построить на примере #требования ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

Нужны актуальные вопросы с собеседований ? SA | Собеседования - твой незаменимый помощник в подготовке к собеседованиям. 🔊Обзоры собеседований c вилками на позиции: 🔵Системных аналитиков (Junior, Middle, Senior, Lead). 🔵Solution Архитекторов. 🔵С комментариями автора - как человека, который активно собеседует кандидатов. 🔊А ещё на Boosty ты найдёшь: 🔵Записи собеседований: В хорошем качестве - с тайм-кодами и названиями компаний. 🔵Статистику вопросов в разрезе каждой конкретной компании. 🔵При наличии подписки - обратную связь по твоим собеседованиям и рекомендации по их прохождению от человека, который провёл более 100 интервью в 2023–2025 годах. ➡️ Подписаться

Как писать промпты к ChatGPT. Выжимка из гайда от OpenAI GPT-5.2 даёт максимальное качество, когда в промпте явно задана структура. Промпт стоит рассматривать не как вопрос, а как краткую спецификацию, которой модель должна следовать. Универсальный шаблон: Роль + Цель + Контекст + Ограничения + Формат вывода + Уровень качества.

Роль: Ты - [тренер/редактор/аналитик].
Цель: достичь [конкретного результата].
Контекст: Вот что тебе нужно знать:
- [предыстория]
- [аудитория]
- [что у меня уже есть]
Ограничения:
- Не [добавляй новые предположения / добавляй дополнительные разделы].
- Если чего-то не хватает, [задай до 3 вопросов] ИЛИ [четко сформулируй предположения].
- Ограничься [X предложениями] или [Y пунктами].
Формат вывода:
- Раздел 1: [краткий ответ]
- Раздел 2: [маркированный список/таблица/контрольный список]
- Раздел 3: [следующие шаги]
Уровень качества:
- Используй простой язык.
- Будь конкретным и действенным.
- Если неясно, скажи, что от чего зависит.

5 рекомендаций от OpenAI 1️⃣ Контролируйте длину ответа Если не задать ограничение, модель сама решает, что значит достаточно. GPT-5.2 обычно пишет компактно, но лучше задавать конкретную длину. Пример:

- 1 короткий абзац (не более 4 предложений) - Затем до 5 пунктов: «Что важно», «Почему», «Что делать дальше», „Риски“, «Открытые вопросы» Без лишних комментариев.

2️⃣ Жёстко ограничивайте объём GPT-5.2 может делать больше, чем вы просили. Чтобы этого избежать, явно укажите рамки: выполнять только запрошенное, всё остальное считать необязательным. Используйте это правило, когда важно строго придерживаться задачи — в письмах, планах, конспектах и предложениях. Пример:

Делай только то, что я просил, и ничего больше. - Не добавляй лишних разделов, функций или «приятных мелочей». - Если ты заметил улучшения, перечисли их в разделе «Дополнительные идеи», но не применяй их. - Выбирай самое простое правильное толкование, если что-то неоднозначно.

3️⃣ Если текст длинный, попросите ChatGPT повторить главное При работе с длинными текстами ChatGPT часто упускает детали и резюмирует не то, что нужно. Для GPT-5.2 рекомендуется жёсткая схема: 1. кратко сформулировать суть задачи, 2. повторить ограничения, 3. дать ответ с опорой на конкретные фрагменты текста. Инструкции и исходный текст нужно явно разделять метками, например: «ИНСТРУКЦИИ» и «ИСТОЧНИК ТЕКСТА», чтобы модель их не смешивала. Пример:

Перед ответом: 1) Перечисли 5-8 наиболее значимых пунктов из моего загруженного текста (коротким списком). 2) Перефразируй мои ограничения своими словами (1-2 предложения). 3) Затем ответь, указав, откуда взято каждое ключевое утверждение (например, «из раздела „Ценообразование“ / из параграфа об X»). Если чего-то не хватает, не гадай - задай до 3 вопросов.

4️⃣ Запрещаем уверенно врать ChatGPT умеет уверенно отвечать даже на расплывчатые запросы, из-за чего появляются галлюцинации. Руководство по GPT-5.2 рекомендует в таких случаях не отвечать напрямую, а действовать одним из двух способов: – задать уточняющие вопросы; – предложить несколько интерпретаций запроса с явно обозначенными предположениями. Это снижает риск самоуверенных, но неверных выводов. Пример:

Если мой запрос неоднозначен или в нем отсутствует ключевая информация: - Назови, чего не хватает, в 1 предложении. - Затем сделай ОДНО из следующих действий: А) Задай до 3 уточняющих вопросов, ИЛИ Б) Предложи 2-3 правдоподобные интерпретации, каждая из которых должна содержать обозначенные предположения. Никогда не придумывай точные цифры, цитаты или ссылки, если не уверен.

5️⃣ Просите модель проверить саму себя Если цена ошибки высока, не принимайте первый ответ. Попросите модель проверить себя: указать допущения, сомнительные места и возможные ошибки. Пример:

Перед завершением работы: - Проверь свой ответ на наличие конкретных цифр, дат или утверждений, которые не основаны на том, что я предоставил. - Выяви все необоснованные предположения. - Замени излишне абсолютные формулировки на квалифицированные, если это уместно. Возвращай окончательный вариант ответа только после этой проверки.

📄 Гайд от OpenAI

Наш новый канал — Библиотека ИТ-промптов. Здесь будет только полезные промтпы для повседневных задач IT-шников. Подписывайтесь!

📌 Систематизация знаний на проекте Все зависит от статуса проекта, но вот примерный план: 🤩собрать и зафиксировать текущее знание 🤩структурировать 🤩убрать противоречия 🤩поддерживать актуальность Ключевая задача на входе не «написать документацию», а собрать, структурировать и зафиксировать текущую инфу о системе: 🔣что система делает сейчас 🔣почему она делает это именно так 🔣где находятся основные источники информации 🔣какие есть ограничения, долги и договорённости С чего начинать Где хранится информация: составить список всех мест Формальные: ⚪️ Confluence / Notion ⚪️ репозиторий (README, ADR, comments) ⚪️ ТЗ, договоры ⚪️ API-спецификации (Swagger, Postman) ⚪️ BPMN / схемы / презентации Неформальные: ⚪️знания разработчиков ⚪️чаты ⚪️комментарии в тасках ⚪️личные файлы коллег Определение границ системы ❓ что является нашей системой, а что — внешним контуром ❓ кто основные пользователи ❓ какие внешние системы интегрированы ❓ где начинается и где заканчивается ответственность команды Это основа будущей контекстной диаграммы (C4) Пример структуры проекта 📌 Лучше разделять бизнес и системную аналитику Важно для масштабируемости Пример верхнеуровневой структуры

/Проект
  /00_Общее
  /01_Бизнес-аналитика
  /02_Системная_аналитика
  /03_Архитектура
  /04_Интеграции
  /05_Данные
  /06_API
  /07_НФТ
  /08_Решения_и_долги

Подробнее по разделам ✨ 00. Общее Дать понимание проекта за короткий срок Описание проекта (1–2 страницы): ➖зачем система существует, для кого ➖какую бизнес-проблему решает ➖глоссарий ➖участники ➖актуальные источники: где документация, код, API ✨ 01. Бизнес-аналитика Фиксирует что и зачем делает система, без привязки к реализации Пример структуры

/01_Бизнес-аналитика
  /01_Цели_и_метрики
  /02_Бизнес-процессы
  /03_Роли_и_пользователи
  /04_Бизнес-правила
  /05_Сценарии_использования

Бизнес-процессы: ⚪️AS-IS (как есть сейчас) ⚪️TO-BE (если планируется развитие) ⚪️BPMN или текст + диаграммы Use Cases / User Stories: без технических деталей ✨ 02. Системная аналитика (ядро) Как именно система работает сейчас Пример структуры

/02_Системная_аналитика
  /01_Функциональные_требования
  /02_Сценарии_и_алгоритмы
  /03_Состояния_и_статусы
  /04_Валидации_и_ошибки

Что важно ➖детальные сценарии ➖условия, ветвления ➖бизнес-правила в формализованном виде ➖краевые кейсы ✨03. Архитектура ➖C4 диаграмма ➖описание основных компонентов ➖ответственность сервисов ➖очереди, кэши, БД ✨ 04. Интеграции Для каждой интеграции: ➖назначение ➖инициатор ➖формат данных ➖синхрон / асинхрон ➖ошибки и ретраи ✨05. Данные (крайне важен) ➖ER-диаграммы ➖описание ключевых сущностей ➖статусы и их жизненный цикл ➖источники данных ✨ 06. API ➖Swagger / OpenAPI ➖описание эндпоинтов в бизнес-терминах ➖примеры сценариев ✨07. Нефункциональные требования ➖производительность ➖безопасность ➖SLA ➖логирование ✨08. Решения и долги ➖известные ограничения ➖технический долг ➖компромиссы Как вести документацию дальше ⚪️ документируется текущее состояние, а не желаемое ⚪️ один раздел → один тип знаний ⚪️ любое изменение → обновление документа ⚪️ лучше «плохо, но есть», чем «идеально, но никогда» Практика ⚪️вводить шаблоны ⚪️привязывать документы к задачам ⚪️делать ревью документации с командой 🔹 Подборка шаблонов документации ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

❓Работа в IT доступна только математическим гениям, пишущим код на черном экране? 📊Компании уже сейчас ищут специалистов в системном анализе, а ваши навыки работы с документами и логика — это уже 80% необходимого фундамента. Осталось освоить инструменты, и вы в IT. 🔥Записывайтесь на 3 бесплатных вебинара курса «Системный аналитик» и узнайте подробнее о профессии от преподавателей-практиков. 📕Вебинар 1: «Топ ошибок начинающего системного аналитика при описании REST API» 28 января в 20:00 мск На вебинаре разберём: 1. Типовые ошибки при описании REST API: структура, контракты и форматы данных 2. Где чаще всего возникает недопонимание между аналитиком и разработкой 3. Как оформлять описание REST API так, чтобы его было удобно реализовывать и тестировать 📙Вебинар 2: «Стейкхолдеры: как превратить хаос интересов в управляемую систему» 2 февраля в 20:00 мск На вебинаре разберём: 1. Кто такие стейкхолдеры 2. Как выделить группы стейкхолдеров, чтобы принести пользу проекту 3. Способы и методы работы со стейкхолдерами на разных этапах проекта 📗Вебинар 3: «Техническое собеседование системного аналитика» 10 февраля в 20:00 мск ✅На вебинаре вы узнаете, как эффективнее подготовиться к собеседованиям на позицию системного аналитика уровня Junior Записывайтесь ➡️ OTUS.RU Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

🟢 Стратегии деплоя Деплой (deployment) / развертывание — процесс доставки новой версии приложения в продакшн и её ввода в эксплуатацию. Стратегия деплоя определяет - как именно новая версия попадает в прод, - какая часть пользователей её увидит - что произойдёт в случае ошибки 🔵 Big Bang / Replace/ Recreate Deployment (полная замена) Как работает 1. Старая версия приложения полностью останавливается 2. Обновляется код и конфигурации 3. Запуск новой версии Плюсы и минусы ➕ просто реализовать ➕ минимальные требования к инфраструктуре ➖ длительный простой ➖ изменения затрагивают пользователей полностью ➖ откат требует повторного деплоя старой версии Где применяется 🔹 внутренние системы, где простой допустим 🔹 низкокритичные сервисы 🔹 редкие релизы 🔹 на ранних этапах проекта / в условиях ограниченных ресурсов 🟢 Rolling Deployment (постепенное обновление) Как работает - новая версия разворачивается постепенно, по экземплярам (ноды, поды, контейнеры) приложения - балансировщик исключает обновляемые узлы из трафика - без полной остановки сервиса ➕ нет полного простоя ➕ не требует дублирования окружений ➖ старая и новая версии работают одновременно (получение неактуальных данных) ➖ требуется обратная совместимость ➖ откат происходит постепенно, занимает время Где применяется 🔹 микросервисная архитектура 🔹контейнеризированные приложения (Kubernetes, облачные платформы) 🔵 Blue-Green Deployment (Сине-зеленое развертывание) Используются идентичные production-окружения: - Blue — текущая версия - Green — новая версия Процесс деплоя: 1. Разворачивание новой версии в Green 2. Проверка работоспособности 3. Переключение всего трафика с Blue на Green 4. Среда Blue становится standby ➕ мгновенный откат. При обнаружении проблем после переключения трафик возвращается на Blue ➕ нет простоя. Релиз — перенаправление трафика ➕ чёткий контроль версии. Новую версию можно проверить в проде под реальной нагрузкой перед переключением ➖ удвоенные ресурсы ➖ сложность работы с БД , кэшами, файловыми хранилищами, чтобы обе версии могли работать с общим состоянием или его миграция была управляемой Где применяется 🔹критичные пользовательские системы 🔹сервисы с высокими SLA 🟢 Canary Release (канареечное развертывание) - новая версия выкатывается на небольшую часть пользователей - доля увеличивается поэтапно Применяется для высоконагруженных / критически важных приложений ➕ минимизация рисков ➕ раннее обнаружение проблем ➖ сложность настройки ➖ повышенные требования к наблюдаемости 🔵 Shadow Deployment (теневое развертывание) - новая версия развертывается параллельно со старой - пользовательские запросы дублируются и отправляются в новую версию, но ответы от новой версии игнорируются Применение Тестирование новой версии под реальной нагрузкой, но без риска для пользователей После анализа логов и метрик теневой версии выбирается одна из стратегий (Blue-Green, Canary) 👉 Feature Toggles (флаги) Это не стратегия деплоя, а техника, которая усиливает другие стратегии Новая функциональность «завернута» в оператор (флаг), который можно включать/выключать без деплоя (также только для группы пользователей) 👉 A/B-тестирование Цель — не безопасный деплой, а валидация бизнес-гипотез (какой вариант интерфейса дает большую конверсию) Часто это следующий шаг после успешного Canary-релиза, когда нужно принять решение оставить новую версию или откатить 📎 Материалы 1. Стратегии деплоя в Kubernetes 2. Стратегии развертывания (деплоя) и стратегии кэширования 3. 6 способов деплоя веб-приложений 4. Deploy (деплой) 5. Стратегии деплоя: как мы пришли к использованию Argo CD 📚 Книги 1. Грокаем Continuous Delivery - У. Кристи 2. Continuous delivery. Практика непрерывных апдейтов - Э.Вольф 3. Руководство по DevOps - Д. Ким, П. Дебус, Д.Уиллис, Д.Хамбл С.Д. #инфраструктура ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

📊 Роль бизнес-аналитика в построении архитектуры продукта по C4 На открытом уроке 29 января в 20:00 МСК разберём модель C4, посмотрим примеры её применения и обсудим, какие архитектурные задачи может брать на себя бизнес-аналитик. На вебинаре разберём: - Обзор модели C4 и её место в описании архитектуры продукта - Примеры использования C4 для представления архитектуры системы - Какие задачи в рамках модели C4 может и должен выполнять бизнес-аналитик В результате вебинара вы: - Поймёте, как модель C4 помогает описывать архитектуру продукта на разных уровнях - Узнаете, какую роль бизнес-аналитик играет в архитектурных решениях - Научитесь использовать C4 как инструмент коммуникации между бизнесом, аналитикой и разработкой 👉Для участия зарегистрируйтесь: https://otus.pw/9WCZ/ Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

🔵🗣Вырасти до хардового Middle+ аналитика. Как? Добавьте к своим скилам навыки в проектировании архитектуры и интеграций веб-сервисов! Рассмотрите — авторский курс про архитектуру и интеграции с практикой. ————— По результатам курса вы: ▫️научитесь выбирать стиль интеграции под вашу задачу; ▫️сможете проектировать с нуля и описывать интеграции в современных стилях (API: REST, SOAP, gRPC и др. + брокеры сообщений); ▫️поймете, как правильно собирать требования и моделировать в UML; ▫️подготовитесь к собеседованию, решив более 100 тестов; ▫️разработаете свой API на Python; ————— 🟢Вы получите большую базу фундаментальных знаний, доступ к урокам и обновлениям остается навсегда 💡 • Всю программу и отзывы смотрите в боте курса. • Бонусный модуль про проектирование баз данных — нормализация, транзакции, основы DWH, индексы. • Результат после прохождения курса: 15 рабочих проектов в портфолио. • Доступ к чату учеников (общение, обмен опытом, помощь внутри сообщества) 🔹🔹 С чего начать?🔹🔹 С открытых бесплатных уроков по архитектуре и интеграциям в чат-боте курса. Переходите. 👇 @studyit_help_bot Скидка на курс от канала — 1 500₽ по промокоду SYS до 30 января

Постновогодняя распродажа 🎄 Если откладывали покупку Базы знаний по системному анализу — вот он, знак. 🔥 ВЕЧНЫЙ доступ за 3 000 ₽ вместо 5 000 ₽ ⏰ Акция всего 3 дня — до 10:00 22 января (МСК) Если думали, покупать ли, то сейчас самое время

Постновогодняя распродажа 🎄 Если откладывали покупку Базы знаний — вот он, знак. 🔥 ВЕЧНЫЙ доступ за 3 000 ₽ вместо 5 000 ₽ ⏰ Акция всего 3 дня — до 10:00 22 января (МСК) Если думали, покупать ли, то сейчас самое время

😎 Менторство от создателя канала Если вдруг вы задумывались о менторе, самое время рассмотреть мою кандидатуру. Изучить условия и оставить заявку можно тут

🔼 Слоистая архитектура Слоистая архитектура — подход, при котором система разделяется на логические слои 💚Каждый отвечает за строго определённую группу задач и взаимодействует с другими слоями по правилам Базовые принципы 💚 Разделение ответственности Каждый слой решает 1 категорию задач: 💚взаимодействие с пользователем/внешними клиентами 💚управление бизнес-процессами 💚бизнес-правила 💚работа с данными и внешними системами Слой не должен брать на себя задачи вне его зоны ответственности 💚 Однонаправленные зависимости Зависимости направлены сверху вниз: 💚верхние слои используют нижние 💚нижние не знают о верхних Снижает связанность и упрощает изменение системы 💚 Контракты между слоями Контракт слоя — формальное описание: 💚какие данные слой принимает 💚какие данные возвращает 💚какие ошибки и ограничения возможны ⭕контракт важнее реализации ⭕верхний слой знает контракт, но не реализацию ⭕реализацию можно заменить (другая БД, другой внешний сервис), не меняя вызывающий слой 💚 Изоляция изменений Изменения в одном слое не должны затрагивать другие, если контракт сохранён Пример: 📍смена БД не требует изменений в бизнес-логике 📍смена UI не влияет на доменные правила Типовая структура ⏩ Презентационный слой (Presentation Layer) 🟡принять запрос 🟡проверить формат данных 🟡вернуть результат пользователю или клиенту Включает: ⭕UI (веб, мобильный, desktop) ⭕REST / GraphQL контроллеры ⭕валидацию формата данных Не должно быть: ✖ бизнес-логики, ✖ прямой работы с БД ⏩ Слой приложения (Application / Service Layer) 🟡управлять сценариями использования (use cases) 🟡определять последовательность шагов 🟡управлять транзакциями и безопасностью Включает: ⭕сервисы приложений ⭕оркестрация логики ⭕обработку ошибок сценариев Отвечает на вопрос «что именно нужно сделать», но не содержит бизнес-правил ⏩ Бизнес слой (Domain / Business Layer) 🟡реализация бизнес-правил и ограничений 🟡хранение данных предметной области Включает: ⭕сущности ⭕доменные сервисы ⭕бизнес-инварианты Ключевой слой, ради которого существует система Не должно быть: ✖ логики UI ✖ SQL, HTTP-вызовов ✖ технических деталей хранения данных ⏩ Инфраструктурный слой (Infrastructure Layer) 🟡реализация технических деталей 🟡работа с БД 🟡интеграции с внешними системами 🟡файловые хранилища, очереди, API, кэш Включает: ⭕репозитории ⭕ORM ⭕HTTP-клиенты Типовой поток запроса 1. Presentation Layer принимает запрос 2. Application Layer запускает сценарий 3. Domain Layer выполняет бизнес-логику 4. Infrastructure Layer читает или сохраняет данные 5. Результат возвращается вверх Другие слои 🟡Integration — изоляция внешних API и интеграций 🟡Security — авторизация, аутентификация, ACL 🟡Caching — работа с кэшем (Redis и аналоги) 🟡Messaging / Event — очереди, события, асинхронное взаимодействие Это не обязательные слои Их выделяют, если появляется отдельная ответственность Лишние слои усложняют систему Когда использовать ✅ есть нетривиальная бизнес-логика ✅ система будет развиваться ✅ в проекте несколько команд ✖ система одноразовая ✖ минимальная логика ✖ критична каждая миллисекунда задержки 📎 Материалы 1. Слоистая архитектура приложений: как обеспечить поддерживаемость доменного слоя 2. Трехслойная и трехзвенная: введение в архитектуру ИС для аналитика 3. Слоистая архитектура 4. Архитектура приложения: что это, какие есть виды и как проектировать 📚 Книги 1. Архитектура ПО. Руководство для обучающихся архитектурному мышлению - Ганди Раджу, Ричардс Марк, Форд Нил 2. Идеальная архитектура. Ведущие специалисты о красоте программных архитектур - Диомидис Спинеллис, Георгиос Гусиос 3. Архитектура программного обеспечения на практике - Л. Басс, П. Клементс, Р. Кацман 4. Александр Швец. Погружение в Паттерны Проектирования #архитектура ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу