🔁 Обеспечение идемпотентности API

Идемпотентная операция — это операция, которая при многократном вызове не меняет состояние ресурса. То есть, если мы повторно вызываем идемпотентный метод API, то не возникнет ошибок, связанных с дублированием одной и той же операции (например, двойных списаний баланса за один и тот же заказ).

По-хорошему, любой API должен быть идемпотентным.


Идемпотентность в REST API

HTTP-методы GET, PUT, DELETE формально считаются идемпотентными, тогда как POST и PATCH нет. Это не означает, что нельзя сделать GET неидемпотентным, а POST идемпотентным.

❗️ Важно: ответ идемпотентного метода может меняться. Например, при повторном вызове идемпотентного API создания заказа — заказ не будет создаваться ещё раз, но API может ответить как 200, так и 400. При обоих кодах ответа API будет идемпотентно с точки зрения состояния сервера (заказ один, с ним ничего не происходит), а с точки зрения клиента поведение существенно разное.


❗️ Проблемы неидемпотентных API

Проблема №1. Дублирование операций.
При сетевых задержках или ошибках одна и та же операция может быть выполнена несколько раз.

Пример с заказом такси:
1️⃣Пользователь вызывает такси в приложении
2️⃣Приложение отправляет запрос на создание заказа на сервер
3️⃣Возникает сбой, и приложение не получает успешный ответ по таймауту
4️⃣Приложение показывает сообщение «произошла ошибка» и делает кнопку заказа снова активной
5️⃣Пользователь снова нажимает кнопку
6️⃣К пользователю может приехать два такси вместо одного

Проблема №2. Неконсистентное состояние.
Неидемпотентные операции затрудняют отслеживание текущего состояния системы, что может привести к ошибкам и неконсистентности данных.

Пример с заказом такси:
1️⃣Пользователь изменяет пункт назначения в активном заказе такси через приложение.
2️⃣Приложение отправляет запрос PATCH /v1/orders/{id} на сервер для обновления заказа
3️⃣Возникает сбой, и приложение не получает подтверждение об успешном обновлении
4️⃣Приложение показывает пользователю сообщение об ошибке и предлагает повторить попытку
5️⃣Пользователь решает изменить пункт назначения на новый и снова отправляет запрос
6️⃣Сервер обрабатывает оба запроса: сначала второй, затем первый. В системе возникает неконсистентность: водитель видит один пункт назначения, а пользователь ожидает, что будет доставлен в другое место.


Идемпотентность создания и изменения

Способы обеспечения идемпотентности методов создания (POST) и частичного изменения (PATCH):
1. Ключ идемпотентности в заголовке запросов
2. Версионирование состояния
3. Блокировка на основе правил

🗝 Ключ идемпотентности

Это уникальный идентификатор операции, который помогает защититься от повторного исполнения операции.

Как это работает:
1. Клиент генерирует уникальный ключ идемпотентности и отправляет его в заголовке запроса. Например, Idempotency-Key: <UUID>
2. Сервер проверяет, был ли уже обработан запрос с таким ключом. Если да, возвращает результат предыдущего запроса, не выполняя операцию повторно. Иначе просто выполняет операцию.


⬇️ Продолжение ниже⬇️

⬆️Начало выше⬆️

✅ Версионирование состояния

Сервер отслеживает версии состояния ресурса и позволяет клиенту указывать, для какой версии предназначен запрос. Если состояние изменилось, сервер отклоняет запрос. Версия может быть как числом (номером последнего изменения), так и хэшом от списка ресурсов.

Как это работает на примере сервиса заказа такси:

Вводные
💩Каждый раз, когда в системе происходит изменение (создание, отмена, редактирование заказа), сервер увеличивает версию списка заказов. Эта версия отражает все изменения, произошедшие с заказами пользователя.
💩Перед созданием нового заказа приложение запрашивает у сервера текущую версию списка заказов через GET /v1/orders.

Процесс
1️⃣При создании заказа приложение включает в запрос заголовок If-Match с версией, которую оно знает.
2️⃣Сервер проверяет, соответствует ли версия в запросе текущему состоянию списка заказов. Если версия не совпадает, сервер отклоняет запрос, предотвращая создание дубликата.
3️⃣Если состояние заказов изменилось (например, заказ был отменен), сервер сообщает об этом приложению, отправляя ошибку с предложением перезагрузить информацию о заказах через GET /v1/orders.


❌Идемпотентность удаления

HTTP-метод удаления DELETE по своей природе идемпотентный, так как повторное удаление уже удаленного ресурса не изменяет состояние системы. После первого успешного все последующие запросы на удаление будут возвращать ошибку 404 (или другой код согласно логике сервера).

Более гибкий способ обеспечить идемпотентность удаления – использовать подход “Soft Delete”. Вместо физического удаления записи из базы данных, запись просто помечается как удаленная с помощью специального флага.

Soft Delete гарантирует, что все последующие запросы на удаление будут успешными и вернут одинаковый результат. Это также позволяет отслеживать удаленные записи и при необходимости восстанавливать их, обеспечивая дополнительный уровень безопасности и контроля.

📎 Статьи

1. Стажёр Вася и его истории об идемпотентности API — очень рекомендуем
2. Кратко об идемпотентности от Yandex Cloud
3. Идемпотентность: больше, чем кажется
4. Идемпотентность при использовании API Mindbox

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


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

Способы обеспечения работы высоконагруженных систем


1️⃣ Инфраструктура

💩Вертикальное масштабирование — увеличение производительности серверов (увеличение RAM, добавление дисков, более мощных СPU и т.д.). Самый простой способ, однако он довольно быстро упирается в потолок
💩Горизонтальное масштабирование — добавление дополнительных серверов (или виртуальных копий сервиса — реплик) для распределения нагрузки между ними. Это работает примерно так же, как в реальной жизни: если один рабочий выкопает яму за 4 часа, то двое рабочих сделают это быстрее (но не факт, что в 2 раза)
💩Балансировка нагрузки — актуально при горизонтальном масштабировании, когда используется несколько серверов или реплик приложения. Балансировка помогает распределить загрузку между сервисами равномерно


2️⃣ Хранение и доступ к данным

💩Кэширование — сохранение часто запрашиваемых данных в памяти для быстрого доступа. Подробнее см. в этом посте
💩Индексы — дополнительная структура данных в реляционных БД для ускорения поиска и обработки записей. Это подобно алфавитному указателю в англо-русском словарике: не нужно листать весь словарь, достаточно лишь открыть страницы с нужным сочетанием букв. Подробнее в этом посте
💩Денормализация — введение избыточности в таблицах и представлениях, чтобы сократить число запросов к БД и тем самым минимизировать время обработки запросов. Вместо того, чтобы делать кучу джойнов с группировками и вычисляемыми полями, можно завести представление (вью), которая будет содержать все нужные данные, хотя она не будет соблюдать 3 нормальных формы
💩Репликация — копирование одних и тех же данных между разными серверами. При использовании такого метода выделяют два типа серверов: master и slave. Мастер используется для записи или изменения информации, слейвы — для копирования информации с мастера и её чтения. Эффект достигается за счёт повышения отзазоустойчивости и разделения операций чтения и записи
💩Партиционирование — разделение таблиц на несколько частей в рамках одного сервера. Позволяет увеличить производительность за счёт уменьшения объема данных, которые нужно обрабатывать при выполнении запросов. Подробнее в этом посте
💩Шардирование — техника масштабирования БД, когда данные разносятся по нескольким машинам. Разделение данных эффективно, когда для разных запросов требуются разные данные некогда единой таблицы. Подробнее в этом посте


3️⃣ Приложения

Проектирование архитектуры приложений
💩DDD (Domain-Driven Design) — подход к проектированию архитектуры, при котором приложение разделяется на функциональные домены на основе того, как работает реальный бизнес. DDD помогает создавать более устойчивые и масштабируемые системы. Подробнее в этом посте
💩CQRS (Command Query Responsibility Segregation) — подход, при котором система разделяется на две части: одна отвечает за обработку команд (изменения состояния), а другая — за запросы (чтение данных). Команды и запросы могут быть масштабированы независимо, что позволяет системе более эффективно обрабатывать большое количество RPC. Подробнее в этом посте
💩CDC (Change Data Capture) — техника, используемая для определения и отслеживания изменений в данных. Очень полезно, когда нужно в режиме реального времени реагировать на изменения в базе-источнике. Подробнее

Интеграции
💩Брокеры сообщений — помогают обрабатывать тысячи запросов с гарантией доставки сообщений. Подробнее тут.
💩Использование gRPC — более производительный стиль интеграции, который под капотом использует HTTP/2 для транспорта и Protocol Buffers для сериализации данных. В этом посте подробнее.
💩Веб-сокеты — вместо множества запросов для обновления данных, веб-сокеты позволяют поддерживать постоянное соединение, через которое данные могут передаваться в обе стороны в реальном времени. Подробнее здесь.

Оптимизация кода
💩Распараллеливание запросов
💩Минимизация сериализации данных
💩Оптимизация запросов к БД
💩Управление HTTP-сессиями и использование возможностей TCP

⭐️ Подборка материалов доступна в базе знаний по системному анализу

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

Масштабирование БД. Партиционирование, шардирование и репликация

⚡️Максимально кратко
💩Партиционирование — разделение БД на части в рамках одного сервера. Может быть вертикальным (по столбцам) и горизонтальным (по строкам)
💩Шардирование — разделение БД на части по разным серверам. Может быть только горизонтальным (по строкам)
💩Репликация — копирование одних и тех же данных между разными серверами


💩Партиционирование

Партиционирование — разделение большой таблицы на несколько частей. Все части хранятся на одном сервере. Бывает горизонтальным и вертикальным.

1⃣ Горизонтальное партиционирование: данные разбиваются на несколько отдельных таблиц по строкам. Каждая такая таблица содержит содержит одинаковые столбцы, но разные строки данных.
Преимущества:
➕уменьшение объема данных, которые нужно обрабатывать при выполнении запросов
➕ускорение выполнения запросов, которые затрагивают только определенный диапазон строк
➕возможность распараллеливания запросов между подтаблицами
Пример: разделение таблицы заказов по дате заказа, так что каждая подтаблица содержит заказы за определенный месяц или год.

2⃣ Вертикальное партиционирование: данные разбиваются на несколько отдельных таблиц по столбцам. Каждая такая таблица содержит часть столбцов и все связанные с ними строки данных.
Преимущества:
➕уменьшение объема данных, которые нужно загружать в память при выполнении запросов
➕ускорение выполнения запросов, которые затрагивают только определенный набор столбцов
➕возможность оптимизации хранения данных в зависимости от типа и частоты использования столбцов.
Пример: разделение таблицы пользователей на две подтаблицы, одна из которых содержит основную информацию о пользователях, а другая — доп. информацию


💩Шардирование — техника масштабирования БД, когда данные разносятся по нескольким машинам. Бывает только горизонтальным (по строкам). Шардирование позволяет распределить нагрузку на запись и чтение данных между различными серверами, за каждый из которых отвечает отдельная машина

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

Методы шардирования

1. Хешированное — данные разбиваются на шарды на основе хеш-функции, которая принимает входные данные и возвращает хеш-значение. Это значение определяет, в какой шард будет помещена каждая запись данных. Метод позволяет достичь высокой производительности и отсутствия единой точки отказа, однако усложняет поиск данных

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

3. Круговое — шарды упорядочиваются в виде кольца и каждый из них ответственен за определенный диапазон значений. Запросы на данные маршрутизируются в соответствии с позицией шарда в кольце. Запросы распределяются равномерно, но при добавлении и удалении шардов требуется перераспределение данных

4. Динамическое — позволяет автоматически масштабировать хранилище в зависимости от текущей производительности и объема данных. Нужна система мониторинга и балансировки нагрузки


💩Репликация
Репликация — копирование данных между несколькими серверами. При использовании такого метода выделяют два типа серверов: master и slave. Мастер используется для записи или изменения информации, слейвы — для копирования информации с мастера и её чтения. Чаще используется один мастер и несколько слейвов, т. к. обычно запросов на чтение больше, чем запросов на изменение
Преимущество: большое количество копий данных. Если мастер выходит из строя, любой другой сервер сможет его заменить
Недостатки: рассинхронизация и задержки при передаче данных. Репликация используется как средство обеспечения отказоустойчивости вместе с другими методами

⭐️ Подборка материалов доступна в базе знаний по системному анализу

#бд

Подборка публичных собеседований системных аналитиков

1. Техническое собеседование для System Analyst

2. Техническое собеседование системного аналитика. В роли кандидата Булат Якубов, системный аналитик в Samokat Tech. В роли интервьюера Алексей Лобзов, руководитель направления в Альфа-Банке.

3. Публичное собеседование системного аналитика с компанией Usetech

4. Собеседование системного аналитика. Райффайзен банк

5. Публичное собеседование системного аналитика. Lamoda

6. Собеседование бизнес-системного аналитика. В роли интервьюера Сергей Нужненко — руководитель экспертной группы обновления профстандарта "Системный аналитик" редакции 2022 года, преподаватель, со-основатель Школы Cистемного Анализа. В роли кандидата — Ольга Шимкив, системный аналитик в финтехе.

7. Собеседование лида аналитиков. Интервьювер: Анна Серетенская, тимлид и системный аналитик в продуктовой разработке. Кандидат: Екатерина Зиновьева - главный системный аналитик в системном интеграторе

8. Моковое собеседование на системного аналитика. Интервьювер — Маргарита Нижельская, ex Head of SA в Мегафоне

9. Моковое собеседование на позицию Junior Системного аналитика


Бонусом — подборка интервью по System Design

1. Интервью по System Design. Александр Поломодов (Тинькофф)

2. Публичное интервью по System Design. Александр Поломодов (тех. дир. Тинькофф).

3. Публичное собеседование по System design. В роли собеседующего - Владимир Иванов (Bolt). На позиции собеседуемого - Виталий Лихачев (Авито)

4. Публичное собеседование по System Design. Интервьювер — Владимир Иванов (Bolt), собеседуемый — Денис Костоусов (Тинькофф)

5. Публичное собеседование по System Design. Проводить собеседование будет Игорь Антонов, TeamLead из Тинькофф

⏯ Все видео собрали в плейлисты на Ютубе:
1. Публичные собеседования системных аналитиков
2. System Design Interview

#подборка

Event Driven Architecture: краткий обзор

Event-Driven Architecture (EDA) — архитектурный подход, при котором система строится вокруг событий.

В таком подходе сервисы взаимодействуют друг с другом через генерацию событий, вместо того, чтобы вызывать друг друга напрямую через HTTP-запросы. Сервис, который породил событие, ничего не знает о сервисах, которые будут это событие обрабатывать (обратное тоже верно). Подход EDA широко применяется в архитектуре микросервисов.


Компоненты EDA
💩 Событие – любое изменение состояния некой сущности или возникновение новой.
💩Производитель события – сервис, который создаёт событие.
💩Обработчик события – сервис, который получает событие и обрабатывает его, после чего порождается новое событие – результат обработки события.
💩Маршрутизатор события – промежуточный слой, который обеспечивает. доставку события от производителя до обработчика. Обычно это брокер сообщений.

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


Модели доставки событий в EDA

1⃣Pub/Sub
1. Производители генерируют события и отправляют брокеру.
2. Брокер направляет события потребителям, которые на них подписались.
3. После отправки события удаляются.
Пример – RabbitMQ.

2⃣Потоковая передача
1. Производители генерируют события и отправляют брокеру.
2. Брокер сохраняет события у себя в журнале.
3. Потребители считывают события из любой части журнала в любой момент времени. События не удаляются брокером.
Пример – Kafka.


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

✅ Преимущества EDA

➕Слабая связность и гибкость: можно масштабировать, обновлять и развертывать сервисы независимо друг от друга.

➕Скорость: в EDA каждое событие может быть обработано независимо, что позволяет системе использовать параллельную обработку. А ещё можно эффективнее распределять нагрузку между обработчиками событий с учётом текущей загруженности узлов.

➕Отказоустойчивость и высокая доступность: даже если один сервис выйдет из строя, система в целом сохранит доступность. А ещё сервисы можно реплицировать и резервировать – когда один экземпляр сервиса падает, можно задействовать резервную реплику сервиса и быстрее восстановить работу.


⛔️ Недостатки EDA

💩Сложность разработки и тестирования вследствие распределённой архитектуры и асинхронного взаимодействия.

💩Отсутствие транзакционности. Поскольку компоненты обработчика событий сильно разобщены и распределены, очень трудно поддерживать транзакции между ними. Если нужно разделить один шаг процесса работы между обработчиками событий, то есть вы используете отдельные обработчики событий для чего-то, что должно быть неделимой транзакцией — вероятно, EDA тут не подходит.

💩Единая точка отказа – брокер сообщений, который является связующим звеном между всеми сервисами. Если он выйдет из строя, то вся система в целом перестанет работать.

💩Дополнительные затраты на инфраструктуру. Реализация EDA требует больше производительности вычислительных ресурсов, нужно больше хранилищ данных, растут расходы на поддержку и управление инфраструктурой.


⭐️ Подборка материалов доступна в базе знаний по системному анализу

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

Git. Обзор и подборка материалов

В связи всё более широким распространением подхода Docs as Code самое время изучить Git.

Git — это система контроля версий, которая помогает отслеживать изменения в проекте. Этот инструмент можно использовать как для индивидуальной, так и для командной работы.

Git позволяет:
💩Хранить историю изменений проекта. Git может определить, кто и в какой момент внёс изменения.
💩Параллельно работать над файлами. Все изменения затем сливаются воедино.
💩Откатиться к предыдущим версиям проекта, если что-то пойдёт не так.

Принцип работы Git

1️⃣Разработчик создаёт свою ветку от главного проекта, куда вносит свои изменения
2️⃣В своей ветке разработчик делает необходимые изменения в коде или документации, которые затем фиксируются в истории изменений.
3️⃣После того как работа в ветке завершена, разработчик сохраняет изменения, создавая коммиты. Коммиты отражают историю изменений и могут быть просмотрены в любой момент.
4️⃣Слияние изменений. Когда изменения готовы, создаётся Merge Request, чтобы влить изменения в мастер-ветку. До этого момента все изменения всё ещё находятся в отдельной ветке проекта. После слияния с мастер-веткой изменения вступают в силу для всего проекта.
5️⃣Контроль версий Git позволяет отслеживать все изменения, предоставляя возможность возвращения к любому предыдущему состоянию проекта, если это необходимо.


Курсы (бесплатные)

1. «Основы работы с Git» от Яндекс.Практикума. 16 часов обучения, свободный график, теория и тесты для самопроверки, поддержка специалистов, электронное свидетельство о прохождении курса, доступ после авторизации через Яндекс ID
2. Git для начинающих от Слёрм. Доступ придет на указанную почту после регистрации, закрытый Telegram-чат, теория и практические задания, без сертификата
3. Введение в Git от Хекслет. Видеоуроки, лекции, тренажеры с практикой, бессрочный доступ к теории, асинхронный формат обучения, без сертификата, доступ после регистрации
4. Основы Git из Степика. Много практики
5. Git. Базовый курс от GeekBrains. 13 видеоуроков, без сертификата, доступ после записи

⏯ Видосы с Ютуба
1. GIT - Полный Курс Git и GitHub Для Начинающих — одно видео на 4 часа полного погружения
2. Что такое Git для Начинающих — GitHub за 30 минут
3. Уроки по Git и GitHub от ITDoctor
4. Базовый курс по Git от Devcolibri

🕹 Интерактивные гайды на русском
1. Git How To — это интерактивный тур, который познакомит с основами Git
2. LearnGitBranching — веб-приложение по интерактивному погружению в Git

📄 Полезные статьи
1. Что такое GitHub и как он работает
2. Как начать работать с GitHub: быстрый старт
3. Про стратегии ветвления в Гите
4. 19 советов по повседневной работе с Git
5. Как настроить работу с Git в Intellij IDEA

✍️ Шпаргалка по командам Git

📖 Книга
Pro Git — основное чтиво по гиту от Скотта Чакона и Бена Штрауба


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

➿➿➿➿➿➿➿➿➿➿

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

▶ Способы асинхронного взаимодействия в API

Обзор посвящён асинхрону в API. Асинхрон в брокерах сообщений смотрите в этом посте. А здесь можно найти вводный пост по асинхронным интеграциям.

Асинхрон в API позволяет клиентским приложениям отправлять запросы на сервер и продолжать работу без ожидания ответа.

Зачем это нужно
👩‍🏫Клиент не блокируется в ожидании ответа. Важно для операций, требующих значительного времени на обработку
🧑‍🏫Сервер может обрабатывать больше запросов за счет асинхронной обработки
👨‍🏫Уменьшается количество необходимых запросов для получения обновленных данных, снижая нагрузку на сервер


Способы асинхронного взаимодействия в API

1⃣ Webhooks
1. Клиент отправляет запрос серверу, указывая сallback URL
2. Сервер принимает запрос и отвечает клиенту, что запрос принят в обработку (например, 202 Accepted)
3. Сервер обрабатывает запрос и отправляет клиенту запрос с результатами на сallback URL
➡ Пример: GitHub Webhooks отправляют автоматические уведомления о событиях в репозитории (например, push или pull request) на конфигурированный внешний сервис

2⃣ Polling
Клиент отправляет запрос на сервер, а затем раз в Т миллисекунд отправляет запросы к серверу, чтобы проверить статус операции
➡  Пример:
1. Пользователь заполняет анкету и загружает скан паспорта
2. Фронт отправляет файл на сервер, получает 202 Accepted и позволяет пользователю заполнять анкету дальше
3. Сервер начинает процесс распознавания паспортных данных, который в среднем занимает 5-7 секунд.
4. Приложение запускает фоновый процесс поллинга: раз в 1 секунду отправляет запрос для получения статуса обработки запроса

3⃣ Long Polling
Сервер получает запрос, но держит его открытым до момента появления новых данных. Это уменьшает количество запросов по сравнению с обычным поллингом. Работает на протоколе HTTP. После получения данных от сервера соединение закрывается.
➡  Пример: чат-приложения, где сервер держит соединение открытым до появления новых сообщений, и только после этого отправляет ответ

4⃣ Server-Sent Events (SSE)
Однонаправленный канал связи от сервера к клиенту, позволяющий серверу посылать события клиенту через открытое соединение. В отличие от Long Polling клиент может получать несколько событий и данных от сервера без необходимости устанавливать соединение заново.
➡ Торговые платформы в реальном времени, где клиенты получают обновления цен акций без необходимости постоянного запроса к серверу

5⃣ WebSocket API
Протокол, обеспечивающий двустороннее постоянное соединение между клиентом и сервером, позволяя обмениваться данными в реальном времени. Это именно отдельный протокол (не НTTP), клиент и сервер могут без задержек обмениваться данными в обе стороны, без необходимости устанавливать и закрывать соединения по несколько раз.
➡ Онлайн-игры, интерактивные приложения, где требуется немедленная реакция сервера на действия пользователя и наоборот


⭐️ Подборка материалов доступна в базе знаний по системному анализу

#интеграции #async

🪧Методы трассировки требований

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

Трассировка требований позволяет:
1️⃣ Обеспечить соответствие функциональности системы исходным бизнес-требованиям
2️⃣ Отслеживать изменения требований на протяжении всего жизненного цикла разработки
3️⃣ Управлять изменениями: позволяет оценить влияние изменений требований на другие артефакты и всю систему в целом
4️⃣ Упрощает тестирование: позволяет покрыть бизнес-требования тест-кейсами и не упустить важное

Для обеспечения прослеживаемости каждое требование должно уникальным образом идентифицироваться, например, иметь ID.
Каждая версия требования должна быть прослеживаема, т.к изменение неизбежны и нужно ими управлять.

Помимо ID, требования могут иметь следующие атрибуты:
💩статус
💩дата создания
💩версия
💩автор
💩владелец
💩приоритет
💩источник
💩обоснование
💩релиз
💩контактное лицо или ответственный за принятие решений по внесению изменений в требование
💩критерии приёмки

Виды трассировки

↕️Вертикальная—связи между высокоуровневыми элементами проекта ( бизнес-требованиями) и низкоуровневыми (техническими требованиями или кодом)
↔️Горизонтальная—связи между элементами одного уровня. Например, трассировка между функциональными требованиями или между разными компонентами архитектуры системы.

✏️ Методы трассировки требований

💫 Матрица трассировки (Requirements Traceability Matrix)

Это таблица для документирования связей между  требованиями и другими элементами системы: тест-кейсами, функциями, документацией, исходный код и т. д. Также может трассироваться история изменений требований.

Примеры возможных связей
—Один к одному: один элемент дизайна реализуется в одном модуле кода;
—Один ко многим: одно функциональное требование (ФТ) проверяется множеством тест-кейсов;
—Многие ко многим:  общие или повторяющиеся элементы дизайна могут удовлетворять нескольким ФТ. На практике данным видом трассировки сложно и трудно управлять

Эффективна
💩в проектах с большим количеством требований и сложной структурой
💩в проектах, где нужно установить связи между различными типами требований и элементами проекта
💩 для анализа и оценки влияния изменений в требованиях на проект

💫 Дерево требований

Структурированное дерево, показывающее иерархию требований от общих к более детальным.

Пример
Техническое требование
—> Архитектурное требование
——>Требование к БД
——>Требование к интерфейсу

Эффективно
💩в проектах, где требования имеют иерархическую структуру или зависимости друг от друга
💩для визуализации и управления связями между различными уровнями требований (бизнес-требования, функциональные требования и требования к интерфейсу)


Плюсы и минусы трассировки

➕Четкое представление о требованиях к системе и их взаимосвязях
➕Отслеживание изменений требований

➖Ресурсо-затратно: некоторые методы требуют времени на подготовку, ведение требований и обновление
➖Есть риск недооценки сложных взаимосвязей между требованиями и элементами проекта.

#требования

🧪 Требования ACID: Краткий обзор

ACID (Atomicity, Consistency, Isolation, Durability) — набор характеристик, обеспечивающих надежность транзакций в базах данных.

Транзакция в БД — логическая операция, состоящая из одного/нескольких запросов, которые выполняются как единое целое.

💩Атомарность: Транзакция рассматривается как "неделимая" единица работы. Транзакция либо полностью выполняется, либо вообще не выполняется. Нет промежуточных состояний.

💩Согласованность: Транзакция должна переводить базу данных из одного согласованного состояния в другое (например, в каждом столбце значения имеют нужный тип данных, сохранена ссылочная целостность, операции выполнены по порядку). Если БД была в согласованном состоянии до транзакции, она должна остаться такой и после.

💩Изолированность: Другие транзакции не должны видеть промежуточных результатов текущей транзакции. Каждая транзакция должна быть изолирована от других: ее выполнение не должно влиять на другие транзакции.

💩Долговечность (надёжность): После успешного завершения транзакции изменения в БД должны сохраняться даже в случае сбоев системы. Данные, внесенные в БД, должны быть долговечными.

Когда применяется ACID:
✅ В финансовых, банковских, бухгалтерских приложениях, где точность данных является критически важной
✅ В системах управления заказами и инвентарем, управления ресурсами (таких как авиабилеты, номера номеров и т.д.)

ACID не актуальны, когда:
➖ производительность имеет большее значение, чем полная гарантия целостности данных
➖ часто выполняются параллельные операции и где допустимы некоторые компромиссы в обмен на повышенную производительность
➖ данные имеют низкую ценность или могут быть легко восстановлены
➖ данные имеют высокую степень избыточности или дублирования.

ACID в реляционных/нереляционных СУБД

🔹Большинство традиционных реляционных БД поддерживают требования ACID

🔸В распределенных БД связанные данные находятся на нескольких узлах. Транзакции в NoSQL затруднены и в большинстве СУБД требования ACID не удовлетворяются. Но некоторые NoSQL СУБД (например, графовая Neo4j и документоориентированная MarkLogic) могут обеспечивать свойства ACID.

Пример

Пусть есть БД с информацией о банковских счетах Алисы и Боба. Рассмотрим две транзакции:
➕Перевод денег: Боб переводит Алисе 100$ со своего счета.
🔻Покупка печенек: Алиса покупает на 50$ со своей банковской карты.
У Алисы изначально 0 на счету. У Боба 110$

Применение ACID гарантирует:
💩А: Покупка печенек завершится ошибкой т.к баланс 0$, деньги не будут списаны. Отмена всей транзакции.
💩С: После обеих транзакций у Алисы должно остаться 50$ (0 + 100 - 50), а у Боба 10$. Операции выполнены в правильном порядке. Данные по клиентам корректно отражены
💩I: Если покупка происходит в то время, когда перевод еще не завершился, в БД не появится несогласованных данных. Блокировки и версионирование в БД изолируют транзакции во избежание путаницы в значениях.
💩D: Если обе транзакции завершились успешно, изменения (перевод и покупка) будут сохранены в базе данных даже в случае сбоев системы.

Как связаны ACID и CAP-теорема

Это две разные концепции, касающиеся транзакций в распределенных системах. Они не противоречат друг другу.
💩Цель ACID — обеспечить надежность в транзакционных БД , где данные обрабатываются в рамках централизованной системы.
💩CAP-теорема рассматривается там, где система распределена между несколькими узлами, что создает потенциальные проблемы согласованности и доступности.

🔹 Подробнее про CAP-теорему в нашем посте

⭐️ Подборки материалов по этой и другим темам доступны в базе знаний по системному анализу

#бд

✔️ Критерии приемки (Acceptance Criteria): краткий обзор

Критерии приемки (Acceptance Criteria, AC) — это набор условий, которым должна удовлетворять пользовательская история (User Story), чтобы её считали выполненной.

Критерии приёмки уникальны для каждой User Story (US) и являются основой для тестирования.

❓Для чего нужны

💩позволяют понять, выполнена ли US и работает ли, как ожидалось
💩определяют негативные сценарии и объясняют, как система должна реагировать на них
💩создают у клиента и команды разработки единое видение как должна быть реализована функциональность
💩помогают выявить проблемы на ранних этапах разработки

Критерии приемки должны:

➖быть определены до того, как начнется разработка US
➖иметь четкие формулировки для проверки их выполнения: «принято» или «не принято». AC должны описывать конкретное поведение или результат, который ожидается от функции
➖иметь четкие формулировки для проверки их выполнения.
➖соответствовать ценности и цели пользователя и продукта

✔️ Подходы к составлению критериев приемки

1. Сценарно-ориентированный подход (Scenario-based acceptance criteria)
2. Свод правил или чек-лист (Rule-based acceptance criteria)

1️⃣ Сценарно-ориентированный подход

Соответствует формату Дано/Когда/Тогда (Given/When/Then):

💩Given (Дано): чёткое описание контекста, состояние системы в начальный момент времени 
💩When (Когда): действие, которое выполняет пользователь или система
💩Then (Тогда): ожидаемый результат

Также можно дополнительно использовать:
💩Сценарий — название поведения, которое будет описано 
💩И / ИЛИ —  для продолжения любого из трех предыдущих утверждений

Пример US: Как пользователь, я хочу иметь возможность восстановить пароль от своей учетной записи, чтобы если я забыл пароль, мог получить доступ к своей учетной записи.
💩Сценарий: Забыт пароль
💩Дано: пользователь переходит на страницу входа 
💩Когда: пользователь выбирает опцию <забыл пароль> 
💩И: вводит действительный адрес эл. почты для получения ссылки на восстановление пароля 
💩Тогда: Система отправляет ссылку на указанный адрес электронной почты 

2️⃣ Свод правил (чек-листы)

Это простой список правил о том, как всё должно работать после реализации требования.

Например:
1. Все кнопки должны иметь скругленные углы радиуса 10
2. Пользователь может выбирать способ авторизации с паролем или через получение OTP
3. В случае неправильного ввода пароля два раза подряд система отображает пользователю капчу

AC 🆚 DoR 🆚 DoD

💩DoR (Definition of Ready) — это набор условий, которые должны быть выполнены, прежде чем командой может взять US в работу. Например, задача описана и декомпозирована, подготовлены CJ, HLD, прикреплены макеты дизайна, прописаны AC и т.д.

💩DoD (Definition of Done) — набор условий, которые должны быть выполнены, чтобы пользовательская история считалась завершенной.
Например, реализация соответствует ТЗ, выполнены AC, пройдены все тест-кейсы, составлена документация, одобрения получены и т.д

Главная разница
💩DoD & DoR одинаковые для всех US
💩AC уникальны для каждой US


⚒️ Использование Gherkin

Gherkin — сценарно-ориентированный язык, который легко читается бизнесом и используется для описания функциональности программного обеспечения. Пример (картинка)

Применяется для:

➖ Документирования пользовательских сценариев
➖ Написания автоматизированных тестов


⭐️ Подборки материалов по этой и другим темам доступны в базе знаний по системному анализу

#требования

🔵 5 книг по изучению SQL

💾 Сохраняйте к себе и делитесь с коллегами

1. Изучаем SQL. — А. Болье
2. SQL для чайников — Аллен Тейлор
3. SQL. Сборник рецептов — М. Энтони, де Грааф Роберт
4. SQL для анализа данных — К. Танимура
5. PostgreSQL. Основы языка SQL — Е.П. Моргунов


✔️ А ещё делимся ссылками на подборки материалов по БД:
1. Большая подборка полезных материалов по основам баз данных
2. Памятка по SQL
3. Список бесплатных онлайн-курсов по базам данных и SQL
4. Основные понятия баз данных. Главное
5. Типы связей в БД. Нормализация
6. SQL vs NoSQL: отличие реляционных и нереляционных БД
7. Виды нереляционных БД. Какие бывают NoSQL базы данных
8. Шпаргалка по выбору правильной СУБД


#бд #sql

✍️ Постановка задачи на разработку: этапы, отличие от ТЗ

Понятия постановки задачи на разработку и техническое задание часто путают меду собой, но это разные вещи.

🔸Техническое задание — это документ, который определяет, что должно быть реализовано и как это должно работать (функциональные требования) и насколько это должно быть быстро/безопасно/отказоустойчиво/дружелюбно/отслеживаемо (нефункциональные требования). ТЗ возникает как результат обработки бизнес-требований, и их перевода на системный уровень.

🔹Постановка задачи на разработку — описание конкретных задач, которые должны быть выполнены разработчиками для реализации ТЗ.

Когда постановка задачи должна быть представлена как отдельный артефакт

Постановка задачи на разработку нужна всегда, но не всегда должна быть оформлена как отдельный артефакт. Иногда достаточно ТЗ, если оно содержит нужные детали для разработки.

Случаи, когда необходимо описать постановку задачи отдельно:

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

Постановка задачи на разработку может содержать следующие пункты:

💩Введение, цель: Необходимо описать бизнес-контекст, почему задача возникла. Например, компания столкнулась с проблемой неэффективного учета заказов и хочет улучшить этот процесс.
💩Описание решения: способ и границы реализации (ТЗ, Use Case, статусные модели, макеты UX/UI, описание интеграций)
💩Ключевые источники информации: спецификации API, HLD, глоссарий, стандарты и т.д.
💩Диаграммы: например, UML sequence, activity, бизнес-процесс в BPMN, схемы данных
💩Заинтересованные стороны: перечень людей, влияющие на принятие решений
💩 Критерии приемки: критерии, по которым будет оцениваться успешное завершение проекта.
💩НФТ и ограничения решения: производительность, масштабируемость, доступность и т.д.


🆚 Отличие постановки задачи на разработку (ПЗ) от ТЗ

💩(утрируя) ТЗ — это текст в Confluence, ПЗ — описание в Jira
💩ТЗ описывает требования к функциональности в целом, а постановка направлена на реализацию функционала в рамках конкретных задач
💩Одно ТЗ может быть декомпозировано на несколько задач, при этом каждая может иметь свою постановку на разработку
💩Иногда в ТЗ уже содержится и постановка задачи, но лучше понятия не смешивать и всё равно прописывать постановку задачи отдельно


⭐️ Подборки материалов по этой и другим темам доступны в базе знаний по системному анализу


#требования

💚 Инфраструктура открытых ключей (PKI) : краткий обзор

Инфраструктура открытых ключей (Public Key Infrastructure, PKI) — набор правил, который использует цифровые сертификаты и ключи для обеспечения безопасности в сети, включая аутентификацию, шифрование и цифровые подписи

🔴 Сферы применения

🔷PKI используется везде, где требуется работа с чувствительными данными (e-commerce, банках, гос. системах и т.д), например:
-- Цифровые подписи в ПО
-- Ограниченный доступ к корпоративным интранетам и VPN
-- Бесплатный доступ к Wi-Fi без пароля в зависимости от владельца устройства
-- Шифрование эл. почты и данных

🔷PKI в HTTPS

В HTTPS PKI используется для обеспечения безопасности соединения между клиентом и сервером. Достигается с помощью SSL/TLS протоколов, использующие сертификаты для аутентификации сервера и шифрования данных.

♥️ Принцип работы PKI

В основе PKI лежит асимметричная криптография, использующая пары ключей: открытый и закрытый (приватный).
— Открытый используется для шифрования и проверки подписи
— Закрытый для дешифрования и создания подписи
Ключи связаны математически так, что сообщение, зашифрованное с помощью открытого ключа, может быть расшифровано только с помощью соответствующего закрытого ключа.

Подпись — цифровая подпись, созданная с использованием закрытого ключа. Привязывается к определенным данным или сообщению и служит для подтверждения подлинности и целостности этих данных. Может быть проверена с помощью открытого ключа.

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


👌 Основные компоненты PKI

🟢Центр сертификации (Certificate Authority, CA): выдает цифровые сертификаты, подтверждающие аутентичность открытых ключей пользователей. Отзывает сертификаты в случае утраты или компрометации
🟢Регистрационный центр (Registration Authority, RA): занимается проверкой личности пользователей и выдачей запросов на сертификаты CA
🟢Серверы доверия (Trust Stores): содержит списки доверенных корневых сертификатов, используемых для проверки цепочек сертификации
🟢Клиентские приложения: ПО, которое использует сертификаты для проверки подлинности удаленных сущностей и шифрования данных
🟢Инструменты управления ключами: для генерации, хранения и управления ключами и сертификатами, включая их резервное копирование и восстановление
🟢Протоколы и стандарты: PKI использует различные протоколы и стандарты, такие как:
— X.509 для формата сертификатов
— SSL/TLS для безопасного обмена информацией, наиболее распространенная реализация PKI
—протоколы OCSP и CRL для проверки отзыва сертификатов

✏️ Пример работы PKI

1️⃣Генерация ключей: Пользователь / устройство генерирует пару ключей.

2️⃣Сертификация ключей: Владелец открытого ключа обращается к доверенному CA с запросом на выдачу сертификата. CA проверяет подлинность запроса и подтверждает ассоциацию "открытый ключ" <-> "сущность" ( пользователем, устройством или веб-сайтом), создавая цифровую подпись для сертификата.

3️⃣Распространение сертификатов: Сертификат, содержащий открытый ключ и цифровую подпись CA, распространяется в сети (публикациЯ на веб-сайте, отправка через эл. почту или др)

4️⃣Проверка подлинности: Пользователь проверяет полученный сертификат, используя публичный ключ CA. Если сертификат и подпись верны, то всё ок

5️⃣Шифрование и подпись: Пользователь использует открытый ключ другой стороны для шифрования данных или проверки подписи. Для шифрования используется открытый ключ получателя, а для проверки подпись отправителя

6️⃣Отзыв сертификатов: Если ключ скомпрометирован, владелец ключа должен отозвать сертификат через CA. Это делается через список отзыва сертификатов (CRL) или протокол проверки статуса сертификата (OCSP)


⭐️ Подборки материалов по этой и другим темам доступны в базе знаний по системному анализу

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

Основы ООП

Объектно-ориентированное программирование (ООП) — методология или стиль программирования, при котором код организуется в логически связанные объекты с четкими интерфейсами и поведением. Это помогает создавать программы, которые легко понять, изменять и масштабировать

⚪️ Когда эффективно?

Когда система содержит схожие объекты, имеет сложную структуру данных и требует модульности и расширяемости. ООП подходит для проектов, где важно переиспользование кода и управление сложностью системы.

За счет чего эффективно?
— облегчения понимания и обслуживания кода благодаря модульной структуре
— улучшения переиспользование кода и уменьшения дублирования
— увеличения гибкости системы и возможности расширения функциональности без изменения существующего кода


▫️Основные принципы ООП

😈Инкапсуляция: скрытие реализации внутри класса.
Позволяет скрыть детали реализации и предоставить интерфейс для взаимодействия с объектом ➡️ обеспечивает безопасность и упрощает использование объекта другими частями программы
⚪️ Класс Animal содержит
— приватную переменную weight
— публичный метод feed()
Переменная weight скрыта от прямого доступа извне класса ➡️ предотвращает непреднамеренное изменение их значений.
Вместо этого доступ к ним осуществляется через методы класса ➡️ есть контроль доступа к данным.

😈Наследование: создание новых классов на основе существующих.
Подклассы наследуют свойства и методы родительского класса ➡️ можно повторно использовать код и упростить разработку.
Подклассы могут расширять функциональность родительского класса, добавляя новые методы или изменяя существующие.
⚪️ Рассмотрим классы Animal и Mammal
Класс Mammal -- подкласс Animal. Т.е. можно наследовать от него его свойства и методы, такие как move() или eat().
Класс Mammal может добавлять собственные методы, например, milkfeeding(), расширяя функциональность базового класса Animal.

😈Полиморфизм: способность объектов разных типов использовать общий интерфейс для выполнения различных действий.
Проявляется в том, что разные объекты могут реагировать на одну и ту же команду по-разному в зависимости от их типа
⚪️ У нас есть классы Dog и Cat, оба имеют метод makesound()
Когда вызывается метод makesound() для объекта класса Dog, он издаёт лай, а для объекта класса Cat - мяукание

😈Абстракция: позволяет отделить концепцию от её реализации.
Уровень абстракции скрывает сложные детали реализации и предоставляет простой интерфейс для использования объекта ➡️ помогает сосредоточиться на важных аспектах объекта, игнорируя незначительные детали.
⚪️ Класс 4legs абстрактный и имеет метод без реализации walk(). Класс является абстракцией (робот или насекомое тоже может иметь 4 ноги). Объект такого класса невозможно создать.
Но можно наследовать потомков.
Dog наследует класс 4legs и реализует метод walk()


💡 Зачем ООП аналитику?

Поможет структурировать требования в соответствии с требованиями бизнеса:
— выделить объекты
— определить их атрибуты
— методы и взаимосвязи между ними

⚪️Нужно описать систему управления библиотекой.
Можно представить систему как совокупность объектов, таких как "книга", "автор" и "читатель", каждый из которых имеет свои атрибуты и методы.

*️⃣Также понимание ООП поможет:
— спроектировать архитектуру приложения: используя принципы наследования, инкапсуляции и полиморфизма разделить функционал на компоненты
— в определении общих интерфейсов и абстракций, которые позволят разным частям системы взаимодействовать между собой

*️⃣Существуют объектно-ориентированные методы системного анализа (ООМСА).
Это подход к анализу, проектированию и моделированию систем, основанный на принципах ООП
Основные методы:
— моделирования объектов и классов
— анализа взаимодействия объектов
— проектирования классов и иерархий
— анализа наследования и агрегации


⭐️ Подборки материалов по этой и другим темам доступны в базе знаний по системному анализу

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