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

▶️ ER-диаграмма (Entity-Relationship Diagram)

ER-диаграмма (Entity-Relationship Diagram, ERD) — диаграмма "сущность-связь",  которая применяется для:
🔘проектирования БД, описания процессов и бизнес-логики
🔘моделирования структуры данных и их связей в системах или приложениях
🔘документирования требований

Состоит из элементов

⏩Сущности — объекты (например, пользователь, заказ)
⏩Атрибуты — характеристики сущностей (имя, дата заказа)
⏩Связи — отображают, как сущности связаны друг с другом ( пользователь делает заказ)


Типы связей между сущностями

🟡Один-к-одному (1:1): каждая запись в одной сущности соответствует одной записи в другой
🟡Один-ко-многим (1:M): одна запись в сущности соответствует нескольким записям в другой
🟡Многие-ко-многим (M:M): каждая запись в одной сущности связана с несколькими записями в другой, и наоборот


Пример ERD для интернет-магазина

*️⃣Сущности: пользователь, заказ, товар

*️⃣Атрибуты:
— пользователь: ID, имя, email
— заказ: ID заказа, дата, сумма
— товар: ID товара, название, цена

*️⃣Связи:
— пользователь делает заказ (один пользователь может сделать много заказов — связь "один ко многим")
— заказ содержит товары (один заказ может включать много товаров — связь "многие ко многим")


Уровни ER-диаграмм

ER-диаграммы делятся на 3 уровня в зависимости от уровня детализации

🟡Концептуальный: описывает общую структуру данных без технических деталей.
Показывает, какие сущности и связи существуют
➡ применяется на стадии сбора требований и анализа для обсуждения с бизнесом и заказчиками.

🟡Логический: уточняет атрибуты сущностей и типы связей.
Детализирует модель, но не привязан к конкретной СУБД
➡ используется на этапе уточнения требований и согласования структуры данных

🟡Физический: описывает, как данные будут реализованы в БД, с учётом таблиц, индексов, первичных и внешних ключей.
➡ используется на этапе реализации и разработки БД


Нотации ERD

ER-диаграмма —  визуальная модель или схема,
а нотации — методы, с помощью которых она строится

🟡Нотация IDEF1X: фундаментальная, используется для физического уровня, ориентирована на стандарты реляционных БД. Редко используется на практике
⏩сущности: прямоугольники с именем сущности
⏩связи: линии с символами "лапками" для связи один-ко-многим, "палка" для связи один-к-одному
⏩атрибуты: внутри прямоугольников сущностей

🟡Нотация Чена: классическая нотация, часто используют для концептуальных моделей
⏩сущности: прямоугольники
⏩связи: ромбы, соединены линиями с сущностями
⏩атрибуты: овалы, соединены линиями с сущностями

🟡Нотация Мартина («воронья лапка»): компактнее нотации Чена, используют для логического уровня, когда нужно описать все атрибуты сущностей

⏩сущности: прямоугольники с атрибутами внутри
⏩связи: линии с "лапками вороны" для связи один-ко-многим и палочкой для связи один-к-одному
⏩атрибуты: внутри сущностей, первичные ключи выделены отдельной строкой


Отличия от других инструментов

🔵UML-диаграммы классов

Нужны для моделирования объектов и их поведения в объектно-ориентированном программировании, а не для реляционных БД
⏩UML отражают методы (функции) классов
⏪ERD показывают только структуру данных и их взаимосвязи

🔵BPMN

Моделируют бизнес-процессы и последовательность действий, а не данные
⏩BPMN отображает шаги процесса и участников
⏪ERD — только структуру данных и их отношения внутри системы


📎 Материалы

1. Сущности и связи: как и для чего системные аналитики создают ER‑диаграммы
2. Что такое ER-диаграмма и как ее создать?
3. Проектирование ER-диаграммы
4. Что выбрать для проектирования БД: сравнение UML-диаграммы классов и ER-диаграммы
5. Модель диаграммы Entity Relations (ER) с примером СУБД

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

➿➿➿➿➿➿➿➿➿➿

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

🔵 Интеграция через общую базу данных

Рассмотрим еще один способ интеграции, менее популярый: интеграция через общую БД
Этот подход имеет свои преимущества, но не всегда является лучшим выбором из-за сложностей с согласованностью данных и производительностью

При интеграции через общую БД несколько систем используют одну и ту же БД для обмена данными

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

🤤 все подключено к одной БД, ее используют для обмена информацией
🤤 системы читают и пишут данные напрямую через SQL-запросы или с помощью API, коннекторов

Особенности

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


Способы интеграции

😮‍💨 Коннекторы (Database Connectivity, DBC)

Например, ODBC/JDBC-драйверы.
🟧JDBC — интерфейс для подключения Java-приложений к БД, позволяет выполнять SQL-запросы
🟧ODBC — универсальный интерфейс для подключения приложений на разных языках к БД, также использует SQL-запросы

Работают как посредники между приложением и БД.
Принимают запросы от приложения, преобразуют их в SQL-команды для БД, выполняют запросы и возвращают результат

😮‍💨 API

Приложения взаимодействуют с БД через REST или SOAP API
Отправляют HTTP-запросы, которые преобразуются в SQL-запросы внутри базы

😮‍💨 Прямое подключение

🤤 через SQL-запросы
Прямое подключение через SQL-запросы: приложение отправляет SQL-команды напрямую в базу данных по сети (например, через TCP/IP), без использования посредников.

🤤 через сетевые драйверы
Используются драйверы для установления связи с БД по сети (например, TCP/IP), затем приложение отправляет SQL-запросы напрямую

В обоих случаях идет работа с БД напрямую.
Но сетевые драйверы (например, для PostgreSQL или MySQL) обеспечивают управление сетевым соединением

🤤 через представления

Создаются виртуальные таблицы (представления), которые объединяют данные из нескольких таблиц.
🟧приложения не изменяют основные таблицы
🟧они выполняют SQL-запросы к представлениям, как к обычным таблицам
🟧выдаются права на чтение нужных представлений


Когда использовать общую БД

💙интеграция внутренних систем (например, системы из одной корпоративной платформы: ERP, CRM и т.д.)
💙для объединения данных из разных источников
💙надо сразу видеть изменения в системе
💙для минимизации повторного хранения данных
💙для интеграции Legacy-систем или самописных систем


Пример работы

В компании несколько систем: интернет-магазин, система управления складом и бухгалтерия

⏩ интернет-магазин: клиенты оформляют заказы, данные сразу записываются в общую Д
⏩ система управления складом: получает информацию о заказах из той же БД и обновляет количество товара на складе
⏩ бухгалтерия: автоматически подтягивает данные о продажах из общей БД для учёта финансов

Все системы работают с одной БД, не нужно синхронизировать данных между ними, данные актуальны во всех системах


Недостатки

❌ проблемы с согласованностью, если несколько систем одновременно изменяют данные.
❌ увеличение нагрузки -> снижается производительность
❌ изменения в структуре данных требуют координации между всеми системами
❌ уязвимость к атакам
❌ сложнее поддерживать и обновлять систему из-за её зависимостей


📎 Материалы

1. Основы интеграции информационных систем
2. Архитектура приложений и интеграций: гайд по основным понятиям простыми словами
3. Современные стандарты информационного взаимодействия систем
4. Простой пример JDBC для начинающих
5. Две альтернативы JDBC
6. PostgreSQL и JDBC выжимаем все соки
7. Доктор, у меня легаси: лечим устаревшие ИТ-системы
8. Legacy-системы
9. Общая информация о ODBC и Connector/ODBC
10. Почему интеграционная бд это отстой

#интеграции

➿➿➿➿➿➿➿➿➿➿

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

🔵 Нормальные формы баз данных

Напомним, нормализация — организация данных в таблицах БД так, чтобы:
🟠устранить избыточность данных (уменьшаеся объем хранения, ниже риск рассинхронизации и проще управление)
🟠улучшить целостность данных (поддерживается правильные связи, меньше ошибок)
🟠уменьшить их дублирование (оптимизация структуры, лучше производительность)


Процесс нормализации

Таблицы делятся на мелкие, связанные по смыслу, а между ними создаются связи.
Происходит шаг за шагом. В результате БД приводится к нормальным формам (NF)


Нормальные формы (NF) – требование к структуре таблиц реляционных БД
🟣чем выше NF, тем меньше лишних и зависимых данных -> БД работает быстрее и точнее , но усложняется её структура
🟣БД считается нормализованной после достижения третьей нормальной формы.
NF выше третьей нужны для устранения более сложных зависимостей
🟣чтобы таблица была в нужной NF, она сначала должна соответствовать всем предыдущим формам.


😈Первая нормальная форма (1NF)
Требования:
➖каждое поле должно содержать атомарные значения (неделимые на части).
➖отсутствие повторяющихся групп данных

Пример:
➡️ до: таблица с полем "телефоны", где у одного человека несколько телефонов в одной ячейке.
⬅️ после: каждый телефон записан в отдельной строке

😈нормальная форма (2NF)
частичные зависимости разделяются на новые таблицы.
➖все столбцы должны зависеть полностью от первичного ключа, а не только от его части (если первичный ключ состоит из нескольких полей)

➡️ до: в таблице заказов хранятся поля "имя клиента", "адрес клиента" и "ID заказа". Эти данные повторяются для каждого заказа клиента, что приводит к избыточности.
⬅️ после: эти данные выносятся в отдельную таблицу "клиенты", чтобы убрать дублирование в каждом заказе одного клиента

😈нормальная форма (3NF)
➖все столбцы зависят только от первичного ключа
(т.е. устранение транзитивных зависимостей: когда второй атрибут зависит от первого, а третий - от второго)

➡️ до: в таблице товаров есть поле "город" и "почтовый индекс".
"почтовый индекс" зависит от "города", а не от товара.
⬅️ после: данные разделяются: "город" и "почтовый индекс" в отдельную таблицу адресов, а "товар" — в другую

🔣Нормальная форма Бойса-Кода (BCNF) — более строгая версия 3NF, решает некоторые её недостатки
➖каждый атрибут, от которого зависят другие поля в таблице, однозначно идентифицировал запись (был кандидатным ключом)

😈нормальная форма (4NF)
➖удаляются многозначные зависимости (несколько значений зависят от одного атрибута)

➡️ до: в таблице "студенты" есть поля "курсы" и "хобби". Один студент может учиться на нескольких курсах и иметь несколько хобби, что приведёт к дублированию данных.
⬅️ после: зависимости разделяют на отдельные таблицы: одна для курсов, другая для хобби, чтобы избежать повторений

😈нормальная форма (5NF)
➖удаляются JOIN- зависимости, данные не могут быть разделены на более мелкие части без потери информации.
Предотвращает аномалии при соединении данных из множества таблиц.

➡️ в системе договоров один договор может включать несколько услуг от разных компаний.

😈нормальная форма (6NF)
редко используется, дальнейший шаг нормализации для поддержки временных данных и их зависимостей

➡️ когда данные меняются во времени (например, истории изменений зарплат), чтобы каждая запись была уникальной и не дублировалась


📎 Материалы
1. Нормализация отношений. Шесть нормальных форм
2. Как привести данные в форму: что такое нормализация и зачем она нужна
3. Нормализация и нормальные формы (описание 1-6 NF)
4. Нормализация СУБД: пример базы данных 1NF, 2NF, 3NF
5. Первая НФ (1NF) базы данных
6. Вторая НФ (2NF) базы данных
7. Нормальные формы: третья и Бойса-Кодда
8. Четвертая НФ (4NF) базы данных
9. Пятая НФ (5NF)
10. Шестая НФ (6NF) базы данных

📚Книги
1. Технологии проектирования баз данных -- Дмитрий Осипов (Глава 6-7)
2. Основы технологий баз данных — Новиков Б. А. / Б. А. Новиков, Е. А. Горшкова, Н. Г. Графеева; под ред. Е. В. Рогова
3. Основы баз данных — Кузнецов (Лекции 7-9)

#бд

➿➿➿➿➿➿➿➿➿➿

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

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

✍️ Распределенные системы: архитектурные паттерны и стили

В распределённой системем различные компоненты работают вместе, при этом физически разнесены

Характеристики

💙нет центрального управляющего узла
💙узлы взаимодействуют через сеть
💙параллельное выполнение задач на разных узлах
💙отказоустойчивость: работа при отказах отдельных узлов
💙масштабирование: доабвление узлов для увеличения мощности
💙автоматическое перераспределение ресурсов в зависимости от нагрузки
💙адаптация к разным архитектурам / технологиям

Виды

⚪️Вычислительные: распределённые ресурсы для вычислительных задач (пример: кластеры для обработки больших данных)
⚪️Хранилища данных: распределяют данные между несколькими узлами (Cassandra, Яндекс.Cloud)
⚪️Файловые системы: доступ к файлам через распределённую сеть (Virtuozzo Storage, HDFS)
⚪️БД: на нескольких узлах для согласованности и доступности данных (Tarantool, CockroachDB)
⚪️Очереди сообщений (Kafka, RabbitMQ)
⚪️Системы управления (Kubernetes)


Примеры архитектурных стилей распределённых систем

Напомним, архитектурный стиль — общий принцип, а паттерн — конкретная реализация этого принципа

✨Клиент-сервер: центральный сервер обслуживает запросы клиентов
➡ Пример: веб-приложения, где браузер взаимодействует с веб-сервером

✨Микросервисы: система делится на независимые сервисы. Взаимодействуют через API и могут разрабатываться, развёртываться и масштабироваться независимо
➡ платформа для доставки еды, где микросервисы управляют заказами, платежами и клиентским профилем отдельно

✨Одноранговая (P2P): все узлы равноправны, каждый может быть как клиентом, так и сервером
➡ торрент-сети (файлы передаются без центрального сервера)

✨Многоуровневая: система разделена на слои (представление, логика, данные), каждый выполняет свою функцию
➡ веб-приложения с фронтендом, бекендом и БД на разных серверах

✨Событийно-ориентированная архитектура (EDA): система реагирует на события, что позволяет асинхронное взаимодействие
➡ онлайн-магазин: событие "новый заказ" отправляется в очередь. Службы (склад, оповещения) реагируют на события и выполняют действия (упаковка товара, отправка уведомлений)

✨Сервис-ориентированная архитектура (SOA): взаимодействие между различными сервисами, которые выполняют отдельные бизнес-функции
➡ корпоративные системы, где отдельные сервисы отвечают за учет, CRM, логистику и др.


Примеры архитектурных паттернов

🔹CQRS: разделение операций чтения и записи для повышения производительности и масштабируемости
💙 интернет-магази: обработка заказов и поиск товаров работают независимо

🔹Service Mesh: управление сетевыми взаимодействиями микросервисов для маршрутизации, мониторинга и безопасности
💙 Istio, Linkerd: управление трафиком между микросервисами

🔹Сага: уразделяет транзакции на последовательность шагов, каждый включает компенсационные действия в случае сбоя
💙 бронирование путешествия: бронь билетов, отеля и аренды автомобиля. Тут каждый шаг может быть отменён

🔹Двухфазная фиксация (2PC): протокол для атомарности транзакций. Состоит из двух фаз — подготовка и фиксация, что гарантирует согласованность данных.
💙 банковская система: перевод средств между счетами требует согласования изменений в нескольких БД


Недостатки распределенных систем

➖сложное управление и мониторинг
➖сетевые задержки влияют на производительность
➖проблемы с согласованностью данных при частых изменениях и высоких нагрузках
➖риски из-за множества точек доступа


Связь с CAP-теоремой

CAP-теорема относится только к распределённым системам.
Утверждает, что система может одновременно гарантировать только две из трёх характеристик:
💙консистентность
💙доступность
💙устойчивость к разделению


📎 Материалы
1. Лекция 1: Введение в распределенные системы
2. Централизованные vs децентрализованные vs распределенные системы
3. Основы Распределенных Систем
4. Консистентность и ACID-гарантии в распределенных системах хранения данных
5. Топ-5 архитектурных паттернов для распределённых систем

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

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

БАЗА ЗНАНИЙ по системному анализу 🧠

Все посты из канала за всё время разложены по полочкам в едином месте — базе знаний 🤓

Наша цель — сделать кладезь знаний системного аналитика 🧠

Какие плюшки вас ждут:

🗂 Все знания в едином месте: кратко, ёмко, без воды и с подборками полезных материалов 🔥

🔎 Удобный поиск и навигация: все наши конспекты структурированы по группам навыков СА и есть поиск по тексту — вы не утоните в тоннах воды и часах гуглинга

🆕 Всегда актуально: мы регулярно добавляем новые материалы и улучшаем базу, при этом стараемся обновлять уже опубликованный контент

📝 Контент на заказ бесплатно: хотите материал на конкретную тему? Любой покупатель может оставить запрос, и мы сделаем обзор с исчерпывающей подборкой материалов абсолютно бесплатно!


➡️ Приобрести вечный доступ к постоянно обновляемой Базе знаний по цене айтишниой книги можно тут: analitik.me — всего 4900 ₽

❗️После успешной оплаты нажмите кнопку Вернуться в магазин, чтобы получить ссылку на закрытый канал (он нужен для авторизации). Если случайно закрыли, ссылка придёт вам на почту.

Если нет карты РФ и по любым другим вопросам можно писать сюда: @radale

P.S. каналы @sys_sa и @lib_analyst продолжают работу в прежнем формате

🌲Подборка наших постов за💚💚💚💚

Управление требованиями
🔘Методы трассировки требований
🔘Критерии приемки (Acceptance Criteria): краткий обзор
🔘Постановка задачи на разработку: этапы, отличие от ТЗ
🔘Customer Journey Map (CJM)
🔘User Story vs Job Story

Работа с API
🔵Версионирование REST API
🔵Обеспечение идемпотентности API
🔵Способы асинхронного взаимодействия в API
🔵Работа со списками данных в REST API: сортировка, фильтрация, пагинация
🔵Знакомство со Swagger
🔵Производительность API: краткий обзор способов

Архитектура и проектирование
💩Обзор популярных нотаций моделирования
💩Способы обеспечения работы высоконагруженных систем
💩Паттерны проектирования и архитектурные паттерны
💩Event Driven Architecture: краткий обзор
💩Service Mesh
💩TOGAF. Краткий обзор
💩Паттерны асинхрона: Request-Reply, Publish-Subscribe, Point-to-Point
💩Антипаттерны проектирования ПО
💩Интеграция через файловый обмен

Базы данных и хранилища
💩Масштабирование БД. Партиционирование, шардирование и репликация
💩Шпаргалка по SQL
💩Требования ACID: Краткий обзор
💩Уровни изоляции транзакций в базах данных
💩Изолированность транзакций в БД: MVCC, блокировки
💩Хранимые процедуры и пользовательские функции в БД
💩Денормализация в БД и не только
💩Оконные функции
💩Колоночные БД, Cassandra vs PostreSQL
💩Data Warehouse (DWH)
💩OLTP и OLAP
💩ETL и ELT

Авторизация и безопасность
💩OAuth 2.0 и OpenID Connect
💩Инфраструктура открытых ключей (PKI) : краткий обзор
💩Хэширование и Шифрование
💩Кибератаки и их виды

Инструменты
🔵Camunda
🔵Grafana: Обзор и возможности
🔵Apache Kafka

Расширение IT-кругозора
◾️Как работает интернет
◾️Kanban vs Scrum: сравнение методологий
◾️Модель TCP/IP: Краткий обзор и сравнение с OSI
◾️Git. Обзор и подборка материалов
◾️Основы ООП
◾️CI/CD
◾️UX/UI
◾️SRE (Site Reliability Engineering)
◾️Веб-приложения: SPA , MPA, PWA
◾️Паттерны GRASP
◾️Синхронизация времени по NTP
◾️Тест-кейсы: как и зачем писать
◾️SQA: обеспечение качества ПО
◾️Методы оценки трудоёмкости проектов и задач

Полезные подборки
🔹Подборка публичных собеседований системных аналитиков
🔹Матрица компетенций системного аналитика
🔹Бесплатные выпуски подкаста «Аналитики у микрофона» для и про аналитиков

В ближайшие дни откроем продажи к базе знаний — веб-порталу, где будут собраны все наши посты в едином месте, с удобной навигацией и поиском. Следите за новостями.

Всех с Наступающим 🎉

#подборка

📖 Подборка книг, опубликованных в 2️⃣0️⃣2️⃣4️⃣

Системный анализ и управление требованиями
🔘Жемчужины разработки. Чему мы научились за 50 лет создания ПО от Карла Вигерса
🔘Формализация требований на практике

Архитектура и проектирование ПО
🔵Предметно-ориентированное проектирование. Самое основное от Вона Вернона
🔵Фундаментальный подход к программной архитектуре: паттерны, свойства, проверенные методы от Марка Ричардса и Нила Форда
🔵Распределенные системы. Паттерны проектирования от Брендана Бернса
🔵Объектно-ориентированное мышление от Мэтта Вайсфельда
🔵Приемы объектно-ориентированного проектирования. Паттерны проектирования от Э. Гаммы, Р. Хелма, Р. Джонсона, Дж. Влиссидеса
🔵Объектно-ориентированный анализ и проектирование с примерами приложений
🔵Предметно-ориентированное проектирование: паттерны, принципы и методы от Скотта Миллетта и Ника Тьюна
🔵Архитектура программного обеспечения на практике от Л. Басса, П. Клементса и Р. Кацмана
🔵Идеальная архитектура. Ведущие специалисты о красоте программных архитектур от Диомидиса Спинеллиса и Георгиоса Гусиоса

Разработка высоконагруженных систем
🔵Высоконагруженные приложения. Программирование, масштабирование, 🔵поддержка от Мартина Клеппмана
🔵Разработка высоконагруженных систем — брошюра по материалам конференции HighLoad++

Базы данных и хранилища
💩5 книг по изучению SQL
💩Распределенные данные. Алгоритмы работы современных систем хранения информации от Алекса Петрова
💩Проектирование и реализация систем управления базами данных от Эдварда Сьоре
💩Основы технологий баз данных: учебное пособие
💩Технологии проектирования баз данных от Дмитрия Осипова
💩PostgreSQL 15 изнутри от Егора Рогова

Проектирование API
💩Designing APIs with Swagger and OpenAPI

Моделирование и бизнес-процессы
💩Моделирование бизнес-процессов в нотации BPMN 2.0
💩The C4 Model for Visualising Software Architecture от Саймона Брауна
💩Свод знаний по управлению бизнес-процессами BPM CBOK 4.0
💩Построение бизнес-моделей от Александра Остервальдера

DevOps и SRE
⚫️Книги по DevOps от Джена Кима
⚫️Site Reliability Engineering. Надежность и безотказность как в Google

Agile и управление проектами
💩Подборка книг по Agile
💩Подборка книг по Scrum
💩Подборка книг по Kanban
💩Экстремальное программирование. Разработка через тестирование от Кента Бека
💩Управление проектным бизнесом от Алексея Васильева

QA
◾️Тестирование веб-API от Марка Винтерингема
◾️Agile-тестирование. Обучающий курс для всей команды от Джанеты Грегори и Лайзы Криспин

Информационная безопасность
🔘Безопасность веб-приложений от Хоффмана Эндрю
🔘Искусство быть невидимым. Как сохранить приватность в эпоху Big Data от Кевина Митник и Уильяма Л. Саймона

Пользовательский опыт и интерфейсы
🔸Не заставляйте меня думать от Стива Круга
🔸Хороший интерфейс — невидимый интерфейс от Голдена Кришны

Инструменты
💩Apache Kafka. Потоковая обработка и анализ данных
💩Pro Git от Скотта Чакона и Бена Штрауба

Личное развитие и soft skills
🔘Принцип пирамиды Минто. Золотые правила мышления, делового письма и устных выступлений от Барбары Минто
🔘Думай медленно... решай быстро от Даниэля Канемана
🔘Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию от Уильяма Детмера
🔘Искусство системного мышления от Джозефа О'Коннора и Иана Макдермотта


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

#подборка

Жемчужины разработки. Чему мы научились за 50 лет создания ПО

✍️ Автор: Карл Вигерс
🗓 Год издания: 2024
🔤 Язык: русский
📚 Объём: 368 стр.

Книга «Жемчужины разработки» от классика Карла Вигерса — это очень полезная для системных аналитиков, стремящихся улучшить свои навыки и избежать распространенных ошибок. Вигерс собрал 60 практических уроков, которые помогут научиться на чужом опыте и не наступать на грабли лишний раз.

Ключевые темы книги охватывают шесть основных аспектов успешной разработки:

1. Требования
2. Дизайн
3. Управление проектами
4. Культура и командная работа
5. Качество
6. Улучшение процессов

Для каждого из этих направлений автор предлагает:

🔘«Первые шаги», которые помогут вам проанализировать свой опыт
🔘Конкретные идеи и примеры, которые можно сразу же применить на практике

Кроме того, Вигерс предлагает «следующие шаги» для внедрения полученных знаний в ваши проекты и команды. Эти уроки основаны на реальном опыте и не могут быть получены в учебных заведениях, что делает их особенно ценными.

Если вы хотите развиваться и повышать эффективность своей работы, эта книга станет отличным помощником.

Обзор книги на Хабре

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

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

❌ Антипаттерны проектирования ПО (часть 2)

Лавина изменений (Lava Flow)

Неиспользуемый или мертвый код остается в проекте
❔ боязнь сломать существующую систему, отсутствие документации
➡ код, написанный в начале проекта, но не удаленный после изменения требований


Незакрытые соединения (Resource Leak)

Системные ресурсы (например, память или соединения) не освобождаются после использования
❔ошибки в управлении ресурсами, отсутствие тестирования
➡ открытые файловые сетевые соединения, которые не закрываются после завершения работы


Избыточная абстракция (Abstract Obsession)

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


Форма, нарушающая контракт (Leaky Abstraction)

Абстракция, которая не скрывает детали реализации, нарушая инкапсуляцию
❔ недостаточно продуманная архитектура, слишком низкий уровень абстракции
➡ библиотека, которая требует от пользователя знания о её внутренней структуре


Необоснованные зависимости (Unnecessary Dependencies)

Модули зависят друг от друга без веской причины
❔плохое планирование, отсутствие модульности
➡ логика бизнес-слоя зависит от UI-компонентов, что затрудняет изменение интерфейса


Перекрестные зависимости (Cyclic Dependencies)

Модули зависят друг от друга, создавая циклические зависимости
❔ недостаточное планирование, отсутствие четкой архитектуры
➡ модуль А зависит от модуля B, который в свою очередь зависит от модуля A


Копипаст (Copy-and-Paste Programming)

Код копируется и вставляется в разных местах без модификации или рефакторинга
❔ спешка, отсутствие времени на рефакторинг
➡ фрагмент кода для обработки ошибок, дублированный в нескольких методах


Неразрешимая взаимозависимость (Circular Dependency)

Два или более модуля зависят друг от друга напрямую или косвенно
❔ непродуманное разделение обязанностей, спешка при разработке
➡ модуль управления пользователями зависит от модуля управления ролями, и наоборот


Черный ящик (Magic Numbers)

Использование в коде числовых значений без пояснения их смысла
❔ недостаток времени на документирование, слабое проектирование
➡ число "7", использованное для обозначения количества попыток, без объяснения причины выбора


Часть 1 👆

📎 Материалы
1. Магическое число (Magic Number)
2. Большой комок грязи
3. Антипаттерн — Золотой молоток (Golden Hammer)
4. Золотой молоток
5. Спагетти-статья о спагетти-коде
6. Автоматы против спагетти-кода
7. God object. Анализ сложных проектов
8. Антипаттерн — Божественный объект (God Object)
9. Антипаттерн — Метод копипаста (Copy and paste programming)
10. Антипаттерны проектирования: Dead End
11. Антипаттерны построения микросервисных приложений в высоконагруженных проектах
12. Что такое антипаттерны? Разбираем примеры
13. Топ-10 антипаттернов при использовании микросервисов
14. 9 анти-паттернов, о которых должен знать каждый программист


⏯ Видео
1. Худшие практики разработки и архитектуры за 12 минут
2. Антипаттерны
3. Антипаттерны (обзор нескольких)


📚 Книги
Типичные ошибки проектирования -- Эрик Аллен

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

<BIG пост перед новогодними праздниками>

❌ Антипаттерны проектирования ПО (часть 1)

Архитектурные антипаттерны — распространенные ошибки в проектировании систем, которые приводят к проблемам в производительности, поддержке и масштабируемости.
Возникают из-за неправильного понимания требований, недостатка опыта или давления сроков.

Существуют ~ 20-30 известных антипаттернов, рассмотрим некоторые.

Большой комок грязи (Big Ball of Mud)

Неорганизованная, беспорядочная архитектура без четкой структуры
❔ Причины: отсутствие долгосрочного планирования, постепенного роста системы без рефакторинга и учета архитектурных принципов
➡ Пример: проект, где новые функции добавляются без четкого разделения компонентов, рефакторинга, создается хаос и трудности в поддержке


Код-спагетти (Spaghetti Code)

Код с многочисленными запутанными зависимостями, который сложно поддерживать и тестировать
❔ плохая структурированность, спешка в разработке, отсутствие документации
➡ старый проект, в котором нет модульности, а изменения в одном месте приводят к сбоям в других частях
➡ Spaghetti Code относится к проблемам в коде на уровне отдельных компонентов / модулей, а Big Ball of Mud описывает хаос в общей архитектуре системы


Золотой молоток (Golden Hammer)

Использование одного инструмента или технологии для решения всех задач
❔ограниченное знание технологий, привычка к одному инструменту
➡применение SQL для всех видов хранения данных, даже когда NoSQL подходит лучше


Изобретение велосипеда (Reinventing the Wheel)

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


Дымоход (Stovepipe System)

Набор изолированных систем, которые плохо взаимодействуют друг с другом
❔ отсутствие координации между командами, историческое "наследие"
➡ когда каждый отдел разрабатывает свои собственные ИТ-системы без учета интеграции с другими


Божественный объект (God Object)

Один объект, который знает слишком много или делает слишком много
❔ недостаточное разделение ответственности, централизованное управление
➡ класс в ООП, который содержит логику для всего приложения и отвечает за все задачи


Продолжение примеров ниже👇

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

📂 Методы оценки трудоёмкости проектов и задач

⏩ Покер планирования (Planning Poker)

Оценка задач с использованием карточек с числовыми значениями (например, 1, 2, 3, 5, 8 по Фибоначчи).

Алгоритм
🟡участники получают карты с числами (например, 1, 3, 5, 8)
🟡оценивают одновременно, не показывая карты
🟡если оценки разные, обсуждают и переоценивают

✅ учитывает мнения всей команды, стимулирует обсуждения и достижения консенсуса
✖ требует времени на обсуждения, сложно организовать в больших командах


⏩ Система корзин (Bucket System)

Задачи группируются в "ведра" по сложности, затем внутри групп задач идет их сортировка
Для оценки большого числа задач, когда точность важна, но при этом нужно сохранить эффективность.

Алгоритм
🟡разделить задачи на ведра (например, "легкие", "средние", "сложные")
🟡разместить задачи в ведра на основе их сложности
🟡уточнить оценки внутри ведра

✅ быстро оценивает множество задач, эффективен для команд с разными уровнями опыта
✖ может быть менее точным для малых задач


⏩ Оценка по размерам футболок (T-Shirt Sizes)

Оценка по аналогии с размерами одежды (XS, S, M, L, XL), где каждый размер — относительная сложность задачи.
Быстрая и простая оценка для грубого прогнозирования.

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


⏩ Трехточечная оценка (Three-Point Estimation)

Оценка на основе трёх значений: оптимистичного, пессимистичного и наиболее вероятного.

Алгоритм
🟡определить оптимистичную, пессимистичная и наиболее вероятную оценки
🟡рассчитать среднюю: (Оптимистичная + 4*Наиболее вероятная + Пессимистичная) / 6. Итого 6 голосов.
➡  5ч - оптимистичная,  7ч - наиболее вероятная, и 9 - пессимистичная. Средняя оценка = (5 + 4*7 + 9)/6 = 7 часов

✅ оценка учитывает риски и неопределенность, полезна для сложных проектов
✖ требует больше времени и усилий для создания оценок


⏩ Снизу вверх (Bottom-up)

Задача сначала оценивается целиком, а затем делится на более мелкие компоненты

Алгоритм
🟡разбить задачу на подзадачи
🟡оценить каждую подзадачу
🟡суммировать оценки для полной задачи\

✅ быстрый способ для общей оценки крупных проектов; удобен на ранних этапах планирования
✖ возникновение неточностей из-за отсутствия детализации на уровне подзадач


⏩ Диаграмма сходства (Affinity Mapping)

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

Алгоритм
🟡записать задачи на карточках
🟡группировать похожие задачи 
🟡оценить группы задач

✅ помогает увидеть скрытые взаимосвязи между задачами
✖ может запутать, если задачи плохо структурирована


⭕ Выбор метода

➡ Покер планирования: для команд, где важно коллективное мнение
➡ Система корзин: для быстрого распределения большого количества задач
➡ Оценка по размерам футболок: для грубой оценки на ранних этапах
➡ Трехточечная оценка: когда нужна более детализированная оценка с учетом рисков
➡ Снизу вверх: для детальной оценки крупных проектов
➡ Диаграмма сходства: для группировки и оценки взаимосвязанных задач


📎 Материалы
1. Как оценивать проектные задачи, чтобы не слить бюджет и не убить команду: советы QA-лида
2. Agile in IT: 7 техник оценки задач
3. Гибкие методологии и 10 лучших техник оценки трудоемкости
4. Путеводитель по оценкам задач и котики

5. Planning Poker: как сделать процесс постановки задач максимально прозрачным и четким
6. Стратегия Bottom-up: как не упустить прорывные идеи и стать гибкой командой
7. T-Shirt Sizing - Agile Estimation Guide
8. Методы оценки - три точки
9. 5 шагов к созданию диаграммы близости


🌐 Инструменты
1. PlanningPoker (eng)
2. PlanningPoker (ru)
3. PlanningPoker (ru)
4. Шаблон диаграммы сходства


⏯ Видео
1. Planning Poker: командная игра для принятия решений и брейнштормов
2. Покер планирования: что это и как его проводить?
3. Трехточечная оценка проекта. Как мы оцениваем задачи

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

🔅Service Mesh

Service Mesh — архитектурный слой. Управляет сетевым взаимодействием между сервисами в распределённых системах.
Каждый сервис взаимодействует с другими через прокси (sidecar), который управляет всем трафиком между сервисами

☑️ Часто Service Mesh используют в облачных инфраструктурах - в контейнерах и Kubernetes

Основные задачи

🔵Шифрование трафика между сервисами и управление доступом на уровне соединений
🔵Сбор метрик, логов и трассировок для мониторинга взаимодействий между сервисами
🔵Балансировка нагрузки, маршрутизация запросов и отказоустойчивость на уровне сетевых вызовов
🔵Автоматическое переключение при сбоях и лимитирование запросов

Примеры решений для Service Mesh: Istio, Envoy Proxy, Linkerd2, Conduit, Consul Connect


Компоненты Service Mesh

⚙️ Data Plane

💩набор прокси-серверов (например, Envoy), которые развертываются рядом с каждым сервисом (sidecar pattern)
💩отвечает за обработку сетевого трафика между сервисами
💩прокси выполняют функции маршрутизации, шифрования, балансировки нагрузки и сбора метрик

🛡 Control Plane

💩управляет настройками Data Plane, определяет правила маршрутизации, политику безопасности и другие конфигурации
💩централизованно контролирует и управляет прокси в Data Plane
Примеры: Istio, Consul Connect


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

✈️ Централизованное управление политиками безопасности (аутентификация, авторизация, шифрование трафика)

Пример: Istio для настройки политики безопасности для взаимодействия микросервисов. Использует мутаторы и проверки на уровне прокси

✈️ Инструменты для мониторинга, сбора метрик и трассировки запросов

Пример: в Linkerd2 есть инструменты (Linkerd Dashboard) для отслеживания состояния микросервисов и анализа метрик производительности в реальном времени

✈️ Упрощает сложные сценарии маршрутизации трафика и балансировки нагрузки между сервисами

Пример: Istio для создания сложных правил маршрутизации (канареечные релизы или A/B тестирование), которые применяются к версиям сервисов без изменения их кода

✈️ Легко управлять версиями сервисов и конфигурациями -> лучше управление релизами и тестированием

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


Минусы

🧮 Для внедрения нужна сложная настройка и управление доп компонентами -> усложняет инфраструктуру

🧮 Введение прокси-сервисов в Data Plane может добавить расходы на обработку сетевого трафика -> влияет на производительность

Пример: Envoy Proxy, используемый в качестве прокси во многих Service Mesh решений, может добавить дополнительные задержки в обработку запросов

🧮 Может потребовать дополнительных вычислительных ресурсов для работы прокси и Control Plane -> увеличение стоимость эксплуатации

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

🧮 Усложняется интеграция с существующими системами и приложениями. Особенно если сервисы не были изначально спроектированы с учётом использования Service Mesh


📎 Материалы
1. Что такое service mesh простыми словами
2. Service Mesh: что нужно знать каждому Software Engineer о самой хайповой технологии
3. 5 самых популярных вопросов при внедрении service mesh в корпорации на примере Istio
4. Istio Service Mesh: как упростить управление микросервисами
5. Что такое service mesh, когда внедрять, альтернативы Istio и другие ответы экспертов с АМА-сессии Слёрм по service mesh


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

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

📎 Материалы по SRE
1. Цель SRE — надёжная система». Обзор основных метрик SRE
2. Как внедрить Site Reliability Engineering (SRE) в компании
3. Что такое Site Reliability Engineering и зачем он нужен компаниям?
4. Простыми словами о базовых принципах SRE
5. Основные принципы SRE
6. Принципы SRE: 7 основных правил
7. Принципы SRE компании Google при проектировании программного обеспечения
8. Почему SRE приносит пользу командам и клиентам
9. Принципы Xаос-Инженерии

10. Кто такой SRE-инженер
11. Как Лёха стал инженером по SRE: выдуманная история про невыдуманные проблемы
12. SRE-инженер: автоматизируй всё!
13. Чем занимаются SRE и DevOps‑инженеры в Yandex Cloud
14. Вся правда об SRE-инженерах: чем занимается, чем отличаются от DevOps, на каком стеке работают

15. Любите DevOps? Вы еще не знаете об SRE!
16. DevOps и SRE: отличия и сферы применения
17. DevOps & SRE — основное различие
18. Чем отличаются SRE и DevOps
19. SRE или DevOps — чувствуем разницу

20. SLO и SLI на практике — что это такое, как внедрить и как контролировать на примере инструмента Instana
21. Пошаговое руководство по расчету SLA, SLI и SLO для ваших IT-услуг
22. ⁠⁠SLA, SLO и SLI: в чем разница?
23. Как определить и протестировать SLO
24. Как внедрить SLO в продукт и получить от этого пользу
25. MTBF, MTTR, MTTA и MTTF
26. MTBF, MTTF и MTTR

27. Ansible для начинающих
28. Terraform: новый подход к Infrastructure as code
29. Пять инструментов Site Reliability Engineering
30. Проверяем реалистичность SLO и анализируем риски, как настоящие SRE-инженеры
31. Как мониторить золотые сигналы SRE
32. А ваша организация задумывается о надежности? Уроки Google SRE

33. Курс по SRE от Google (можно смотреть бесплатно если выбрать кнопку "Audit" при старте курса)


⏯ Видео
1. Т-Образование: Лекторий по SRE
2. Mobile SRE: кто и зачем? — Александр Агейченко, Тинькофф
3. DevOрs VS SRE методология. Чем занимается DevOps-инженер и SRE
4. DevOps vs SRE. В чем отличие?
5. Лекция: Введение. Как ломаются большие системы. Разбор статистики поломок сервисов I SRE Week I ШАД
6. Как из инженера службы поддержки стать SRE?
7. Google: SLIs, SLOs, SLAs, oh my! (class SRE implements DevOps)
8. Kubernetes probes: учимся отслеживать состояние сервисов в кластере // «SRE практики и инструменты»
9.  Путь в SRE, вебинар курса «SRE: внедряем DevOps от Google»

🎓 Конференции
1. DevOpsConf: : SRE в большой компании — сложно ли? / Иван Ишмаметьев (Тинькофф)
2. DevOpsConf: SRE — человек-оркестр или просто опять переименовали админов? / Михаил Жучков (Neuron Digital)
3. DevOpsConf: Проверка навыков SRE: собеседования по system design и troubleshooting / Ал-др Поломодов (Тинькофф)
4. HighLoad++: Как SRE следит за стабильностью и скоростью HeadHunter / Антон Иванов (HeadHunter)
5. HighLoad++: Внедрение SRE. Итоги 5 лет опыта / Павел Притчин


📚 Книги
1. Site Reliability Engineering. Надежность и безотказность как в Google —  Бейер Бетси, Джоунс Крис
2. ​​The Site Reliability Workbook. Practical Ways to Implement SRE (2018) — Betsy Beyer, Niall Richard Murphy (англ)


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

SRE (Site Reliability Engineering)

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

Цель: баланс между внедрением новых функций и поддержанием стабильности

Роль SRE: следить за тем, чтобы платформа или сервис были доступны клиентам в любой момент и в любых обстоятельствах.

Задачи

🤎поддержание стабильности сложных систем
🤎устранение рутинных задач
🤎управление рисками сбоев при внедрении новых функций

Где используется

💚крупные технологические компании
💚облачные провайдеры
💚организации с критической инфраструктурой
💚высокоавтоматизированные среды с быстрыми циклами разработки


Принципы SRE

✔ Бюджет ошибок: количество простоев или ошибок, которые может иметь сервис без нарушения SLO
🤎 если SLO доступности — 99.9%, то 0.1% времени простоя может быть использовано для тестирования новых фич

✔ Автоматизация: использовать инструменты для управления и эксплуатации сложных систем, сокращения количества ручных действий (Terraform, Ansible, Grafana и т.д)
🤎 автоматизация для уменьшения времени реакции на инцидент

✔ Мониторинг и оповещение: постоянный мониторинг систем и настройка оповещений только по важным метрикам, чтобы не перегружать команды.
🤎 настройка алертов на время отклика сервиса или процент отказов.

✔ Реагирование на инциденты и постмортемы: следование четко установленным процедурам управления инцидентами.
Подготовка постмортемов— специальных документов с анализом первопричины проблемы и планом дальнейших действий по предотвращению.
🤎 после сбоя в работе сервиса команда проводит постмортем для выявления системных ошибок.


MTTR , MTBF, MTTR

Это характеристики отказоустойчивости систем

✨MTBF (Mean Time Between Failures) -- среднее время между исправляемыми сбоями.
✨MTTR (Mean Time to Repair) -- среднее время восстановления после сбоя
✨MTTA (Mean Time to Acknowledge) -- среднее время с момента отправки оповещения до начала работы над исправлением


SLO, SLI, SLA

Показатели управления уровнем обслуживания

✨SLI (Service Level Indicator) — метрика, измеряющая параметры работы системы.
🤎 пример: время отклика (95% запросов должны обрабатываться менее чем за 200 мс), доступность (99.9% времени сервис должен быть доступен), процент успешных транзакций.

✨Service Level Objectives (SLOs) -- целевое значение для SLI.
SLI определяет фактическое состояние, SLO - устанавливает желаемый уровень этого состояния.
🤎 пример: 95% запросов должны обрабатываться менее чем за 200 мс

✨SLA (Service Level Agreement) — договор между провайдером и клиентом о минимальном уровне обслуживания.
🤎 пример: обещание, что проблему с продуктом X в течение 24 часов.: обещание, что проблему с продуктом X в течение 24 часов.

✅SLIs могут включать метрики, связанные с MTBF и MTTR.
Например, процент времени безотказной работы. SLA может требовать определенный MTBF
✅SLA может содержать обещания по времени восстановления (MTTR), чтобы обеспечить выполнение обязательств перед клиентом


Отличие SRE от DevOps

Имеют общие принципы, но отличаются по основным целям и задачам
➡️ DevOps стремится сократить время между разработкой и развёртыванием через автоматизацию и совместную работу
⬅️ SRE акцентирует внимание на поддержании стабильности и надежности в продакшене, используя инженерные подходы к операционным задачам

➡️ DevOps отвечает за инфраструктуру и автоматизацию
⬅️SRE отвечает за отказоустойчивость "собственного" приложения, разработка ПО


Подборка материалов в следующем посте👇

#развитие #devops

📎 Материалы по теме DWH
1. Что такое Data Warehouse
2. Архитектура хранилищ данных: традиционная и облачная
3. Хранители данных: как устроена работа с DWH в Lamoda
4. Единое хранилище данных и плюсы, которые оно несёт. Опыт НМГ
5. Хранилища данных. Обзор технологий и подходов к проектированию
6. Enterprise Data Warehouse: компоненты, основные концепции и типы архитектур EDW
7. Обзор технологий хранения больших данных. Плюсы, минусы, кому что подойдет
8. Хранилища данных.Обзор технологий и подходов к проектированию
9. Как быстро развернуть хранилище и аналитику данных для бизнеса
10. Создание хранилища данных: пошаговое руководство
11. 7 шагов успешного создания хранилища данных(DWH)
12. Создаем аналитическое хранилище данных командой из 2-3 спецов

13. DWH по Кимбаллу и Data Mesh
14. Статьи Ральфа Кимбалла
15. Взгляд Ральфа Кимбалла на хранилища данных
16. Концепции хранилищ данных: подход Кимбалла против Инмона
17. Основные подходы к архитектуре Хранилищ данных
18. Сходство и различия двух подходов к архитектуре Хранилищ данных

19. Снежинка, Data Vault, Anchor Modeling. Какая методология проектирования DWH подойдет для вашего бизнеса?
20. Схема снежинки
21. Схема «снежинка» в модели хранилища данных
22. Схема Снежинка (Snowflake scheme)
23. Схема Звезда (Star scheme)
24. «Звезда» — оптимальная структура данных при переходе на российский BI
25. Что такое звездная схема? Преимущества и недостатки
26. 5 шагов проектирования DWH с подходом Data Vault: практический пример
27. Data Vault
28. Введение в Data Vault
29. Anchor Modeling и GP: как мечты разбиваются о реальность (презентация)

30. Хранилище данных и база данных: понимание различий
31. 8 лучших инструментов для хранилищ данных
32. 13 инструментов для хранилищ данных с открытым исходным кодом (2024 г.)

⏯ Видео
1. Методология моделирования данных для хранилища Data Vault
2. Курс "Создание хранилища данных"
3. Евгений Ермаков: Есть 2 стула - Data Vault и Anchor Modeling, на какой сядешь, на какой DWH посадишь
4. DataVault / Anchor Modeling / Николай Голов
5. Все о корпоративных хранилищах данных (КХД, Data Warehouse, DWH)
6. Архитектура хранилища данных и создание ETL потоков
7. Как построить хранилище данных, так чтобы оно работало. Архитектурные подходы и современные тренды
8. Что такое data warehouse со стороны аналитика?
9. Роль Аналитик DWH: задачи и инструменты // Демо-занятие курса «Data Warehouse Analyst»

🔵 Data Warehouse (DWH)

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

Архитектура ХД

⚪️Нижний уровень — БД. Объединяют данные из источников информации (например, из транзакционных СУБД или SaaS-сервисов)
⚪️Средний — сервисы и приложения. Преобразуют данные в структуру для анализа и сложных запросов. Например, сервер OLAP
⚪️Верхний — инструменты для создания отчетов, визуализации и анализа. Также называют уровнем клиента

Модели ХД

⏺Виртуальное ХД — отдельные БД, которые можно использовать совместно, чтобы получать доступ ко всем данным (как при хранении в одном ХД)
⏺Модель витрины данных — для отчетности и анализа конкретных бизнес-линий.
Хранилища – агрегированные данные из исходных систем, по одной бизнес-сфере
⏺Модель корпоративного ХД — хранение агрегированных данных со всей организации


Схемы ХД

✨Звезда: в центре ХД таблица фактов, которая хранит основные метрики.
Вокруг расположены таблицы измерений с атрибутами.
Простая и быстрая для чтения схема, оптимизирована для производительности запросов
⏩ Пример: в центре — таблица фактов с информацией о продажах (сумма, количество).
Вокруг — таблицы измерений: товары, клиенты, дата, магазины

✨Снежинка: нормализованная версия "Звезды", где таблицы измерений делятся на подтаблицы Экономит место, но усложняет запросы.
⏩Таблица "клиенты" делится на персональные данные, контакты, адреса

✨Anchor Modeling: полная нормализация данных.
В центре — якоря (таблицы с сущностями)
К ним присоединяются атрибуты и связи. Хранятся в отдельных таблицах.
Легко добавлять данные и расширять структуру без изменений существующих таблиц.
Но требует более сложных запросов и тщательного планирования.
⏩В центре — якоря (клиенты и товары)
Атрибуты для якоря "клиенты": имя, дата рождения.
Связи между якорями "клиенты" и "товары": связь покупок
Изменения (обновления адреса клиента), добавляются как новые строки, сохраняя историю изменений

✨Data Vault: гибридный подход, объединивший плюсы схемы «звезды» и 3-ей нормальной формы.
Состоит из:
➖Хаб — таблица с основными данными по бизнес-сфере
➖Ссылка — таблица, которая соединяет и масштабирует систему
➖Спутник — таблица с описанием ключа хаба
⏩ Отдельные хабы для "Клиентов" и "Продуктов".
Ссылки связывают хабы с транзакциями.
Сателлиты хранят изменяющиеся атрибуты (текущий адрес, обновлённые данные о продукте)


Методологии проектирования

📌 Инмон: нисходящий подход.
После процесса ETL создается нормализованная модель ХД. Из нее создаются витрины размерных данных

😉 Представим хранилище в виде библиотечного шкафа с карточками, в котором хранятся данные.

Сначала берутся 10 карточек, выписывается из них важное на листочек и кладется в шкаф.

➡️ например, в страховании сначала формируется общая картинка о застрахованных (доход, возраст, хронические болезни, авариях на дорогах и пр.)
После фильтруются и ложатся в основу модели

📌 Кимбалла: восходящий подход.
Данные после процесса ETL поступают в ХД.
Строится несколько независимых хранилищ для конкретных бизнес-направлений. Затем они объединяются в единое DWH

📑 По аналогии с библиотекой: начинается процесс с нескольких ящиков (витрин данных), а потом решается, что сложить в общий шкаф

➡️ например, для анализа рекламных кампаний нужны только выборочные метрики


Пример работы DWH по шагам

⏺Извлечение данных (ETL) о транзакциях, счетах и клиентах из системы транзакций, бухгалтерских базы или CRM
⏺Трансформация данных: удаление дублей, сопоставление клиентов с транзакциями, расчет суммарных значений (общие расходы или доходы)
⏺Загрузка по схеме "Звезда": загружается основная таблица фактов (транзакции) и связанные с ней таблицы измерений (клиенты, счета)
⏺Данные сохраняются в DWH и структурируются для доступа через OLAP-кубы или напрямую
⏺Бизнес-аналитики / системы BI используют интерфейсы отчетности для получения и анализа данных (отчеты по прибыли и убыткам, оценки рисков)


Подборка материалов в следующем посте👇

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

📎Материалы по теме Как работает интернет

1. Основы Интернета
2. Объясни мне: как устроен интернет
3. Что такое интернет и как он устроен
4. Что такое Интернет — простыми словами
5. Как устроена и организована глобальная сеть в РФ?
6. Протоколы передачи данных: их типы и особенности
7. Что такое протоколы передачи данных
8. Протокол - что это?
9. Сетевые протоколы: базовые понятия и описание самых востребованных правил
10. Какие бывают протоколы передачи данных?
11. Что такое DNS простыми словами
12. DNS: Введение в систему доменных имён
13. Как работает технология DNS
14. Domain Name System (DNS)
15. Основы DNS: понятие, иерархия, записи
16. Протоколы семейства TCP/IP. Теория и практика
17. Как устроен типичный ISP (Internet Service Provider)
18. Как зарегистрировать домен: выбор имени, DNS и TLD
19. «Отец интернета» Винт Серф объясняет, что такое ICANN и как работает Интернет
20. ICANN и управление интернетом: домены, IP-адреса, безопасность
21. Кто такая ICANN, чем она занимается и почему без неё «интернета не будет»?


🔹 Посты из нашего канала
1. Модель TCP/IP: Краткий обзор и сравнение с OSI
2. HTTP. Что нужно знать аналитику
3. Разбираемся с моделью OSI на пальцах


⏯ Видео
1. Как работает интернет? Что такое api
2. Чем занимается организация ICANN
3. Устройство интернета для новичков в IT. Как работает интернет
4. HTML с нуля: урок 1 - как работает Интернет и что такое сайт
5. Как работает интернет | TCP/IP, https, DNS
6. Как работает Интернет? Как интернет узнает тебя
7. DNS сервер - что это и как работает?
8. Что Такое DNS? Для Чего Нужен DNS Простыми Словами
9. Как работает интернет в космосе?
10. Как работает Интернет?


📚 Книги
1. Компьютерные сети. Нисходящий подход -- Куроуз Джеймс, Росс Кит
2. Компьютерные сети. 6-е издание -- Таненбаум Эндрю, Фимстер Ник, Уэзеролл Дэвид

#сети

🌎 Как работает интернет

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

Структура интернета

🔵 Протоколы связи: Основной протокол интернета — это TCP/IP (Transmission Control Protocol/Internet Protocol). TCP гарантирует целостность передачи, разбивая данные на пакеты и контролируя их доставку. IP отвечает за маршрутизацию пакетов от отправителя к получателю
🔵 Доменная система имен (DNS): Распределенная база данных, которая служит для хранения и преобразования доменных имен (например, google.com) в IP-адреса (172.217.18.0), которые используются для маршрутизации данных в интернете
🔵 Интернет-провайдеры (ISP): Компании, которые предоставляют доступ к интернету
🔵 Маршрутизаторы и коммутаторы: Устройства, которые направляют данные через сеть, по оптимальным маршрутам
🔵 Протоколы приложений: Протоколы, такие как HTTP/HTTPS, FTP, SMTP, POP3 и другие, обеспечивают работу интернет-сервисов и приложений (веб-сайты, электронная почта, файловый обмен и т.д.).

Интернет работает на базе набора протоколов TCP/IP, которые реализовывают 3, 4 и 7 уровни модели OSI:

🔵TCP (Transmission Control Protocol): Обеспечивает надежную передачу данных.
🔵IP (Internet Protocol): Определяет маршрутизацию пакетов.
🔵HTTP/HTTPS (HyperText Transfer Protocol): Протоколы передачи гипертекста, обеспечивающие взаимодействие между клиентом и сервером. HTTPS включает шифрование для безопасности.

Подробнее про OSI — в наших постах (ссылки в материалах)

Доменная система имен (DNS). Включает:

1⃣ Корневые серверы — вершина иерархии DNS. Их задача — направлять запросы к соответствующим серверам доменов верхнего уровня (TLD). В мире существует 13 наборов корневых серверов, обозначенных буквами от A до M, управляемых различными организациями.
Пример: Один из корневых серверов — A.ROOT-SERVERS.NET, управляемый организацией VeriSign.

2⃣ DNS-серверы доменов верхнего уровня (TLD DNS Servers — top-level domains) — управляют доменами верхнего уровня, такими как .com, .org, .net, .ru и т.д. Они получают запросы от корневых серверов и направляют их к авторитетным серверам для конкретных доменов второго уровня.
Пример: Для домена .com существует множество TLD серверов, например, a.gtld-servers.net.

3⃣ Авторитетные серверы содержат информацию о доменных именах и их IP-адресах. Возвращают окончательные ответы на DNS-запросы.
Пример: Если запрос касается домена example.com, авторитетный сервер для google.com может быть ns1.google.com.

Интернет централизован?

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

Однако существует координационный орган — ICANN (Internet Corporation for Assigned Names and Numbers). ICANN отвечает за распределение IP-адресов, управление доменными зонами и поддержание стабильности работы сети.

ICANN координирует распределение IP-адресов и доменных зон верхнего уровня (.com, .org и т.д.), т.е. обеспечивает работу корневых DNS-серверов. ICANN не управляет содержимым сайтов и интернет-провайдерами, а лишь поддерживает техническую инфраструктуру. Хотя ICANN не может физически отключить интернет в стране, но может прекратить обслуживание доменных зон.

Что происходит, когда мы вводим в браузере google.com?

1⃣ Браузер отправляет запрос на локальный DNS-сервер.
2⃣ Локальный DNS-сервер ищет IP-адрес. Если не находит, пересылает запрос на корневой сервер
3⃣ Корневой сервер направляет запрос на TLD-сервер (для .com)
5⃣ TLD-сервер направляет запрос на авторитетный DNS-сервер для google.com
5⃣ Авторитетный сервер возвращает IP-адрес
6⃣ Браузер отправляет HTTP/HTTPS-запрос на полученный IP-адрес
7⃣ Сервер Google отвечает, и браузер отображает страницу


#сети

📎 Материалы по теме Camunda
1. Camunda — что это такое?
2. Camunda: тестируем модели процессов
3. Пошаговая инструкция: делаем свой первый проект на Camunda и Kotlin
4. Автоматизируем бизнес-процессы с Camunda и Spring Boot: отказоустойчивая реализация BPM-схем
5. Camunda modeler инструкция на русском

📚 Книги
Моделирование бизнес-процессов в нотации BPMN 2.0 —  И.Г. Фёдоров

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

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