🔎 Elasticsearch: краткое описание и подборка материалов

Elasticsearch (ES) — это распределенный поисковой и аналитический движок, построенный на основе Apache Lucene. Предоставляет открытый и гибкий интерфейс для хранения, поиска и анализа данных в реальном времени. Условно говоря, ES — это документоориентированная NoSQL БД и гугл одновременно.

Elasticsearch является частью стека ELK (Elasticsearch, Logstash и Kibana).

💩Logstash собирает, обрабатывает и передает данные из различных источников в хранилище, такое как ES. Поддерживает различные источники данных и форматы логов.
💩Elasticsearch индексирует и анализирует собранные данные и производит поиск в них.
💩Kibana предназначена для работы с логами, поддерживает гибкий и сложный поиск по логам. Так же в Kibana можно строить дашборды, отчёты и визуализировать данные.
💩Также есть Beats — легковесные агенты для отправки логов в ES. Они более примитивны, чем Logstash, т.к. только собирают и отправляют данные, без преобразований

Архитектура Elasticsearch распределенная:

1. Данные хранятся в виде JSON-документов
2. Эти документы индексируются для быстрого поиска
3. Каждый индекс разбивается на шарды для распределения их по узлам кластера, что позволяет балансировать нагрузку.
Кластер состоит из одного или нескольких узлов, объединенных в единое целое для совместной работы.

Как работает ES?

1. Данные отправляются в ES в виде документов JSON с помощью API или инструментов приема, например, Logstash.
2. ES автоматически сохраняет исходный документ и добавляет ссылку на него в индекс кластера, включая возможность поиска.
3. Следом можно найти и извлечь документ, используя API Elasticsearch.
4. Также для визуализации данных и создания интерактивных панелей управления можно задействовать Kibana.

🔨Применение ES

— Мониторинг и логирование. Хранение, поиск и анализ логов для отслеживания работы приложений, системы, серверов .

— Аналитика и BI. Поиск, фильтрация, агрегация, анализ больших объемов данных в реальном времени для выявления паттернов, создания отчетов. Например, компании в финансовой сфере используют ES для анализа данных о транзакциях, инвестициях и рынке

— Поисковые системы. Используется для быстрого и точного поиска. Например, платформы соцсетей используют ES для быстрого поиска, фильтрации и сортировки контента. Или интернет-магазины для поиска товаров. Также у ES есть возможность поиска и анализа данных на основе геолокации.

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

💩Быстрый поиск и агрегация данных. Обеспечивает мгновенный доступ к данным и эффективный поиск за счет распределенной архитектуры, индексации и возможности добавлять новые узлы в кластер
💩Отказоустойчивость. Достигается благодаря распределению данных и запросов между различными узлами кластера и шардами. В случае проблем ES автоматически восстанавливает реплики и данные.
💩Масштабируемость и гибкость. ES можно масштабировать горизонтально без потери производительности. Кластеры ES могут расширяться и сжиматься в зависимости от потребностей с помощью добавления новых узлов.
💩Экосистема ELK: входит в стек ELK, предоставляя комплексное решение для обработки, хранения и визуализации данных.

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

💩Сложность конфигурации. Настройка и управление ES может быть сложным для новичков, т.к. содержит множество параметров и настроек.
💩Управление ресурсами. Управление памятью, диском и другими ресурсами может быть сложным из-за использования обратных индексов Неоптимальная конфигурация может привести к недостаточной производительности.

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

#инструменты

Обзор популярных нотаций моделирования

Владение нотациями крайне важно для системного аналитика. Это must have, который встречается практически в любой вакансии

Нотация — это система условных обозначений и правил для представления систем, процессов, участников и взаимосвязей в понятной графической форме.

Зачем нужны нотации

1️⃣ Визуализация сложного в картинках

2️⃣ Моделирование — позволяют создавать описание структуры данных для анализа системных процессов (например, для фиксации требований)

3️⃣ Стандартизация — единый язык для коммуникации между разными специалистами (например, бизнеса, разработки)

Виды нотаций

💩 Структурные нотации: отображают состав объекта и взаимодействие между его частями. Примеры: UML-диаграммы классов, компонентов, кооперации, композитной структуры, развертывания, пакетов, объектов и профилей. К таким нотациям относятся IDEF0, IDEF1x, IDEF4, IDEF5 и IDEF6 из стандарта IDEF.

💩 Динамические нотации: показывают потоки данных или логику выполнения процессов. Примеры: DFD, EPC, BPMN, а также UML-диаграммы деятельности, состояний, вариантов использования и последовательностей.

Примеры распространённых нотаций

🔹 BPMN (Business Process Model and Notation) — используется для моделирования бизнес-процессов. Представляет собой набор графических элементов, которые отображают задачи, события, шлюзы, потоки, пулы, дорожки и т.д. BPMN позволяет наглядно и однозначно описать логику, последовательность, роли и правила выполнения бизнес-процессов.

🔸 eEPC (extended Event-driven Process Chain) — нотация моделирования бизнес-процессов с фокусом на события и их результаты. eEPC показывает, какие события инициируют, контролируют и завершают функции, а также какие ресурсы и данные участвуют в процессах.

🔹 IDEF (Integrated DEFinition) — семейство нотаций (IDEF0, IDEF1, IDEF2 и т. д.) для описания разных видов моделирования, например, функционального, данных, логики и т.д. Одна из старейших нотаций.

🔸 UML (Unified Modeling Language) — это система обозначений, которую можно применять для объектно-ориентированного анализа и проектирования. UML имеет 12 диаграмм, которые показывают структуру и поведение системы на разных уровнях.

🔹 DFD (Data Flow Diagram): для визуализации и анализа потоков данных в информационной системе. Помогает выявить входы, выходы и обработку данных в различных процессах.

🔸 ERD (Entity-Relationship Diagram) — нотация для моделирования сущностей и их отношений в базах данных. ERD показывает, какие сущности существуют в базе данных, какие атрибуты их описывают, какие связи между ними устанавливаются и какие ключи обеспечивают их идентификацию и целостность.

🔹 С4 (Context, Containers, Components, Code) – простая нотация для описания архитектуры. Модель объединяет 4 иерархических уровня: контекст, контейнеры, компоненты и классы.

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

📎 Ссылки
1. Один пример и три нотации: сравниваем BPMN, EPC и DMN
2. Ликбез по BPMN, EPC и UML activity с примерами для начинающих аналитиков
3. Основные нотации моделирования бизнес процессов и их применение
4. Плюсы и минусы IDEF, eEPC, BPMN
5. ТОП-5 нотаций моделирования архитектуры

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

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

User Story vs Job Story

📄User Story – это краткое описание функции с точки зрения пользователя и наименьшая единица работы в Agile. В среднем, команда может выполнить 2-3 user story за двухнедельный спринт

Цель: декомпозировать требования на понятные и выполнимые элементы
Формула: Я, как [тип пользователя], хочу [желание], чтобы [ценность или результат]
Пример: Я, как пользователь сайта, хочу получить трек-номер, чтобы следить за посылкой. Я, как пользователь, могу запросить напоминание пароля, чтобы восстановить пароль

Как составить user story:
➖Определите пользователя, для которого создается функция
➖Сформулируйте результат, который получит пользователь после использования функции
➖Опишите ситуацию, в которой пользователь может использовать функцию
➖Укажите ограничения или условия, при которых функция должна работать

Способ проверки “INVEST”:
➖«I» Independent — независима от других историй
➖«N» Negotiable — обсуждаема, по ней можно спланировать дальнейшие действия
➖«V» Valuable — ценная, отвечает на вопрос «зачем»
➖«E» Estimable — оцениваемая, можно установить критерии успеха
➖«S» Small — маленькая или короткая, описывает одну задачу
➖«Т» Testable — тестируемая - можно получить обратную связь от пользователей и сделать выводы


🎯Job Story (инструмент из концепции Jobs To Be Done (JBTD)) - это описание возможных ситуаций, при которых пользователь хочет воспользоваться нашим продуктом

Цель: определить ситуации, в которых у пользователя возникает потребность в продукте
Формула: Когда [ситуация], я хочу [мотивация], чтобы [ожидаемый результат]
Пример: когда пользователь оплатил заказ на сайте, он беспокоится, доставят ли ему товар и хочет получить трек-номер, чтобы следить за посылкой

Способ проверки:
➖Описывает результат, который получит пользователь
➖Не содержит готовое решение
➖Описывает контекст, в котором человек находится при возникновении проблемы, а не саму проблему
➖Отвечает на вопрос «Почему/для чего?» мы должны это сделать

Отличия:
💩User Story описывает конкретный сценарий с точки зрения пользователя, Job Story - общую задачу, которую он выполняет в системе
💩User Story фокусируется на описании одной задачи, Job Story может включать в себя несколько User Story
💩User Story помогать лучше узнать пользователей, Job Story отвечают на вопрос почему они продолжают пользоваться продуктом и почему приходят новые


Совмещение инструментов:
1. Изучить потребности пользователей
2. Описать потребности по шаблону Job Story, это позволит видеть картину пользователя целиком: его чувства, эмоции, привычные реакции
3. Придумать как удовлетворить потребности, описанные в Job Story
4. Выбрать решение и описать его по шаблону User Story
5. Передать User Story в разработку

Итог:
💩Job Story подходит, если нужны идеи для доработки текущего продукта или создания нового
💩User Story подходит, если нужно декомпозировать и описать уже выбранное решение

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

#требоваия

Тест-кейсы: как и зачем писать📝

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

Виды тест-кейсов:

✅ Позитивные (положительные). Проверяют, что система правильно реагирует на корректные данные
Пример: пользователь существует в системе и он может пройти авторизацию

❌ Негативные (отрицательные). Показывают, что система умеет работать с некорректными данными
Пример: пользователь при регистрации ввёл простой пароль 12345, а кнопка “Установить пароль” активной не стала, т.к ждёт более сложный

🚫 Деструктивные. Служат для проверки прочности системы
Пример: метод для получения заказов пользователя нельзя выполнить без авторизации


Особенности:
💩Идеально подходят для описания сложных проверок в системе и регрессионного тестирования
💩Помогают автоматизировать ручные проверки, если тестирование занимает много времени
💩Используются для проверки системы не тестировщиками, для онбординга новых людей на проект
💩Помогают определить необходимое время на тестирование
💩Избыточны для небольших задач
💩Требуют много времени на написание и актуализацию
💩Может возникнуть "Эффект пестицида" — когда из-за постоянного повторения одинаковых шагов не получается найти ошибки


Содержание тест-кейса

💫Уникальный номер. Позволит ссылаться на тесты по номеру
💫Заголовок. Отражает цель - что именно нужно проверить
💫Предусловия. Что нужно сделать перед началом тест-кейса
💫Постусловия (редко). Что нужно сделать после проведения проверки. Например, удалить изменения из базы данных
💫Шаги. Что нужно сделать для проверки
💩Не описывать шаги слишком подробно. Например, следует писать «Введите email» вместо «Введите email, нажимая клавиши на клавиатуре».
💩Шаги должны быть конкретными. Написать: “Нажмите на иконку пользователя → Личный кабинет” вместо “Зайдите в личный кабинет”
💩Скриншоты можно использовать только как дополнение к текстовому описанию
💫Ожидаемый результат. Что должно получиться после или во время прохождения шагов
💫Статус. Passed/Failed, то есть Успех/Провал или другой. Отмечается при прохождении кейса тестировщиком


Use Case 🆚 Test Case

🔹 Use Case — детальное описание того, как пользователь взаимодействует с системой, включая различные сценарии, условия и результаты. Используют для описания функциональных требований к системе

🔸 Test Case — детальное описание того, как должно проходить тестирование конкретной функции в системе. Основываются на юскейсах и используются для проверки соответствия реализации требованиям.


👨‍💻 Аналитик и тест-кейсы
➖На старте проекта кейсы может написать и согласовать аналитик - именно он лучше всех знает требования к системе. Это упростит сдачу проекта в будущем
➖Аналитик подсвечивает тестировщику какую часть функционала нужно оформить в виде кейсов для регрессионного тестирования - что было самым важным в релизе
➖Ревью тест-кейсов — аналитик проверяет, что тестировщик правильно понял задачу и ожидаемый результат соответствует требованиям


Инструменты ведения для тест-кейсов:
➖Zephyr for Jira
➖TestRail
➖Qase
➖Test IT


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

#тестирование

Kanban vs Scrum: сравнение методологий

Kanban и Scrum — методологии гибкого управления проектами, используемые для реализации принципов Agile и DevOps при разработке.

Kanban — подход к управлению процессом разработки, который включает следующие практики:

💩Визуализация задач и прогресса с помощью канбан-доски, установление приоритетов задачам
💩Ограничение количества задач со статусом "В работе", или WIP (work in progress). Если лимит превышен, то команда не может взять новую задачу в работу, пока не будет завершена одна из текущих
💩Управление потоком: отслеживание метрик, таких как скорость движения задач между статусами, для устранения «бутылочных горлышек», где процесс замедляется
💩Проведение каденций — встреч членов команды по процессу разработки. Всего выделяют 7 видов встреч. Главная цель — объяснение правил для всех участников команды и сбор обратной связи
💩Непрерывное улучшение процесса на основе обратной связи и анализа метрик

Что общего между Kanban и Scrum

➖Обе методологии относятся к Agile
➖Важна визуализация работы для прозрачности и оценки текущего состояния задач.
➖Имеют итерационный подход к работе, даже если длительность итераций различается.
➖Имеют механизмы для определения и управления приоритетами задач.
➖Акцентируют внимание на командной работе и взаимодействии между участниками


✅ Когда лучше применять

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

Scrum:
💩 важен строгий контроль сроков и структура
💩 требуется четкое определение целей и результатов
💩 команда является кросс-функциональной
Пример: Разработка новой версии продукта с фиксированным релизным циклом, например, каждые 3 месяца.


❌ Когда не подойдет

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

Scrum
💩 продукт нужен целиком, итерации невозможны
💩 когда нет сплочённой, самоорганизованной и кросс-функциональной команды
💩 для слишком маленьких групп из 1–2 человек, или, наоборот, больших лучше заменить другими методами — SAFe, LeSS.


☯️ Гибрид ScrumBan

Используется в средах, где необходимо управление проектом в условиях неопределенности и частых изменений. ScrumBan легче внедрить, чем Scrum
💩от Scrum: сохраняет ключевые элементы Scrum: спринты, роли (Product Owner, Scrum Master, и команда разработки) и основные события (планирование, ревью, ретроспектива).
💩от Kanban: заимствует концепцию визуализации процесса на доске, ограничения рабочего объема, адаптацию к изменениям в реальном времени и фокус на поток задач.

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

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

Больше подборок в закрытом канале

Ещё больше полезных материалов по системному анализу можно получать в закрытом канале, который доступен по подписке.

Что входит в подписку:
➖2-3 подборки материалов каждую неделю в закрытом канале
➖навигация по всем материалам
➖коммьюнити подписчиков — обмен опытом и общение
➖доступ к каналу с тестовыми заданиями из собеседований
➖тесты для самопроверки
➖(скоро) обновляемая база знаний по ключевым темам системного анализа
➖(скоро) исчерпывающая интерактивная карта навыков системного аналитика со ссылками на материалы из базы знаний

Тарифы:
💩350 ₽ — месяц
💩3400 ₽ — год (283 р/мес, экономия 20%)

Оформить подписку можно через кнопки ниже.

OAuth 2.0 и OpenID Connect

🔐 OAuth 2.0 — протокол авторизации, который позволяет приложениям получать доступ к ресурсам от имени пользователей, без необходимости передавать логин и пароль. Вместо этого используются токены доступа.

👤 OpenID Connect — протокол аутентификации, который позволяет безопасно узнать сведения о пользователе, от имени которого совершается вход. OpenID Connect позволяет реализовывать сценарии, когда единственный логин можно использовать во множестве приложений, — этот подход также известен как single sign-on (SSO).

В чём отличие между OAuth 2.0 и OpenID Connect

Вся разница сводится к различию процессов аутентификации и авторизации.

Простыми словами:

💩Аутентификация — это когда мы проверяем, кто именно запрашивает доступ и является ли он тем, кем он себя представляет.

💩Авторизация — это когда мы проверяем, имеет ли конкретный клиент доступ к запрашиваемой информации.

OAuth 2.0 используется для авторизации, а OpenID Connect для аутентификации. А ещё OpenID Connect делает возможным использование SSO.

Токены

Оба протокола используют токены. Токен — это строка, которая содержит зашифрованную или подписанную информацию.

💩id_token — содержит информацию о клиенте, он выдается провайдером идентификации (IdP) в ответ на успешную аутентификацию пользователя. Может содержать, например, id пользователя, фамилию, имя, телефон и т.д.
💩access_token — это токен доступа, который используется для совершения действий от имени пользователя. Может быть ограничен скоупом — перечислением прав, которые может делать приложение с этим токеном от имени клиента. access_token имеет короткий срок жизни в целях безопасности.
💩refresh_token — это токен, который используется для получения нового access_token, когда старый истекает или отзывается. Имеет более длительный срок.

Все эти токены можно генерировать по-разному, но самый популярный формат — это JSON Web Token (JWT).

Структура JWT
💫Заголовок (header) — состоит из типа токена и алгоритма хэширования подписи
💫Полезная нагрузка (payload) — любые данные, которые вы хотите передать в токене. Payload не шифруется при использовании токена, поэтому не стоит передавать в нем чувствительные данные. Например, паспортные данные.
💫Подпись (signature) — заголовок и нагрузка формируются отдельно в формате JSON, кодируются в base64, а затем на их основе вычисляется подпись, которая также становится частью токена.

🔀 Процесс на примере использования VK API

1. Приложение генерирует параметры запроса и отправляет пользователя на сервер авторизации oauth.vk.com, добавив к ссылке параметры, включая запрашиваемый scope, например, friends
2. Пользователю открывается окно, где он проходит аутентификацию — вводит логин и пароль
3. После входа открывается окно с запросом прав доступа. Пользователь нажимает на кнопку "Разрешить". Тем самым он авторизует приложение на выполнение действий от его имени с запрашиваемым scope.
4. Сервер авторизации генерирует access_token и refresh_token и возвращает их приложению
5. Теперь приложение может управлять списком друзей пользователя

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

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