Стань системным аналитиком c EdMe: практический курс с оплатой обучения после трудоустройства и доходом от 140 000 рублей

Курс «Системный аналитик» от EdMe – не просто обучение. Это ваш первый шаг в новую профессию, где вы будете востребованы и станете экспертом в анализе и улучшении информационных систем. Вы научитесь определять бизнес-требования, проектировать эффективные решения, будете играть ключевую роль во взаимодействии между бизнес-пользователями и IT-специалистами.

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

☑️ Что особенного в программе:

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

• Jira и Confluence для проектного управления
• MySQL и DBeaver для работы с базами данных
• Postman и Swagger для API
• PlantUML и Draw. io для документации

🔵Фокус на реальных задачах.
Вы не просто изучаете теорию, а работаете над настоящим проектом, создаете техническую документацию, разрабатываете модели и диаграммы (UML, BPMN), осваиваете SQL и принципы работы с базами данных, изучаете Agile и Scrum, а также учитесь эффективно взаимодействовать с командой и пользователями. Это именно то, что ждет вас в реальной работе.

🔵Менторская поддержка.
Ментор группы – действующий системный аналитик, который поможет не только с обучением, но и с подготовкой к собеседованиям.

☑️ Что еще важно:
🔵Курс обеспечивает полноценную подготовку к началу карьеры и гарантирует трудоустройство с доходом от 140 000 рублей.
🔵Оплата за обучение начинается после вашего выхода на работу – 18% от зарплаты в течение 18 месяцев.

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

Узнать подробности и записаться EdMe.pro

Отбор включает тестовое задание, которое под силу выполнить человеку без опыта, и собеседование.

Реклама. ООО "БАКСЭТ", ИНН 4345115602. Erid 2VtzqwTN3DT

🔅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
6. Введение в Service Mesh: основные функции и преимущества
7. Большой обзор Service Mesh: часть первая | часть вторая


⏯⏯ Видео
1. Service mesh. Знакомство с Istio и Envoy // курс «Инфраструктурная платформа на основе Kubernetes»
2. Istio Service Mesh в федеративных топологиях Kubernetes / Максим Чудновский (Сбертех)

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

📎📎 Материалы по 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)

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

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

Роль 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 инструкция на русском
6. Упрощаем работу в Camunda Modeler с помощью плагинов
7. Стильная, модная, молодежная разработка BPM на Camunda
8. Использование Camunda для удобной оркестровки на основе REST и Workflow Engine (без Java)
9. Моделирование бизнес-процессов: практика использования Camunda BPM в Java разработке
10. Мониторинг бизнес-процессов в Camunda 8
11. Camunda 8 глазами аналитика
12. Визуальный конструктор бизнес-логики на основе Camunda BPM
13. Моделирование решений: краткий ликбез по нотации DMN
14. Что такое модель управления делами и нотация (CMMN)
15. DMN Документация

⏯ Видео
1. Camunda: как перестать писать код и начать его рисовать, Тинькофф
2. Цикл видео: Camunda BPM
3. Camunda BPM: разбор примера бизнес-процесса "Заявка на страховку"
4. Camunda, Kotlin, Spring Boot, Posgresql: делаем пустой шаблон приложения
5. Camunda BPM. Нон-фикшен
6. Сага на Camunda Platform 8: что это и для чего
7. Camunda BPM для начинающих. 1. Развертывание системы | 2. Сборка Process Application
8. Обучение работе в Camunda, часть 1 | часть 2
9. Тестирование бизнес-логики на примере Camunda BPM
10. Первый проект на Camunda: Создание и запуск бизнес-процесса
11. BPMN за 9 минут: все квадратики на примерах

🎓 Конференции
HighLoad++ Camunda на микросервисах, Промсвязьбанк)
Analyst Days: Расширение нотации BPMN: использование совместно с DMN(управл.решения) и CMMN(кейс-менеджмент)

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

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

Camunda

Camunda — платформа для моделирования и автоматизации бизнес-процессов.
Основана на открытых стандартах, предоставляет инструменты для создания, исполнения, мониторинга бизнес-процессов

Для чего нужна

🤤 для моделирования и автоматизации бизнес-процессов. Сначала создаются модели процессов в  BPMN 2.0, а затем Camunda исполняет эти модели, управляет порядком выполнения задач и взаимодействует с другими системами
🤤для поддержки гибких процессов, которые изменяются в зависимости от ситуации, с помощью CMMN
🤤для создания и выполнения моделей принятия решений с использованием DMN
🤤для отслеживания процессов в реальном времени, анализа производительности

*DMN (Decision Model and Notation): используется для описания бизнес-правил и логики принятия решений.
*CMMN (Case Management Model and Notation): для моделирования и управления неструктурированными, гибкими процессами, которые зависят от событий и контекста.


Компоненты

🍃Camunda BPM Engine: ядро платформы, исполняет процессы, смоделированные в BPMN, CMMN, и DMN
🍃🍃Camunda Modeler: десктопное приложение для создания / редактирования моделей
🍃🍃Tasklist: веб-интерфейс для управления и выполнения пользовательских задач, назначенных в рамках процесса
🍃🍃Cockpit: веб-интерфейс для мониторинга и управления запущенными процессами, анализа их выполнения, и устранения проблем
🍃🍃Admin: веб-интерфейс для администрирования платформы, управления пользователями, авторизациями и развертыванием процессов


Примеры применения

Сценарий: Оркестрация процесса обработки заказа
🍃клиент отправляет заказ через веб-приложение.
он поступает в Camunda, которая запускает процесс обработки.
🍃Camunda вызывает микросервис для валидации данных заказа  (например, проверка наличия товаров на складе)
🍃расчет стоимости: Camunda вызывает другой микросервис для расчета итоговой стоимости
🍃платеж и подтверждение: Camunda направляет запрос на внешний платежный сервис для списания средств.
🍃оповещение склада: Camunda отправляет уведомление на склад для сборки заказа.
🍃Camunda отправляет уведомление клиенту о статусе заказа


Способы интеграции с платформой

😮‍💨 REST API: передача данные о клиентах из CRM-системы в процесс Camunda для авоматического выполнения задач
😮‍💨 Java API: интеграция Camunda в Java-приложение для управления внутренними процессами компании
😮‍💨 Message Queues: обработка событий онлайн и передача их в процессы Camunda
😮‍💨 Connector Framework: для быстрой интеграции с облачными сервисами


Скрипты в Camunda

Используются для задач внутри бизнес-процессов, для реализации логики без написания полного Java-класса или запуска отдельного сервиса.
Могут быть написаны на JavaScript, Groovy или Python


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

♥️порог входа: требуются знания BPMN, DMN,CMMN для освоения платформы
♥️сложно моделировать процессы, которые не вписываются в стандартные нотации
♥️в корпоративной среде требует значительного времени на настройку и интеграцию.
♥️при больших нагрузках могут быть проблемы с производительностью


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

Паттерны асинхрона: Request-Reply, Publish-Subscribe, Point-to-Point

Архитектурные паттерны Request-Reply, Publish-Subscribe, Point-to-Point используются для взаимодействия между компонентами системы.
Например, в распределенных системах и микросервисных архитектурах

🔘🔘 Request-Reply

Request-Reply — паттерн, в котором клиент отправляет запрос и получает ответ от сервера через очереди сообщений.

Как работает

🔘клиент отправляет запрос в очередь сообщений
🔘сервер извлекает запрос из очереди и обрабатывает его
🔘cервер отправляет промежуточный ответ клиенту (опционально)
🔘сервер помещает ответ в очередь ответов
🔘клиент извлекает ответ

Зачем нужно

Для реализации асинхронного взаимодействия, когда требуется ответ на запрос.
➖подходит для микросервисов и систем, где требуется подтверждение выполнения задач
➖архитектурно можно реализовать через REST API

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

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

♥️задержка при больших объемах данных
♥️сложность реализации для управления состоянием запросов и ответов

👍 Пример: асинхронные веб-сервисы, обработка задач в распределенных системах., запросы к БД


💙Publish-Subscribe

Publish-Subscribe -- паттерн, в котором публикатор отправляет сообщения множеству подписчиков через брокера сообщений (например, Kafka, RabbitMQ)

Как работает

💙публикатор отправляет сообщение в канал (топик)
💙подписчики этого канала получают сообщение

Зачем нужно

Для рассылки сообщений множеству получателей одновременно.
К примеру, уведомлений или обновлений
API паттерны: подписка на события через WebSockets или другие механизмы push-уведомлений

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

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

♥️нужно управлять подписками и качеством обслуживания
♥️непредсказуемая задержка доставки из-за обработки сообщений подписчиками

💙 Примеры: системы уведомлений, новостные рассылки, обновления в реальном времени, интернет вещей (IoT)


🟣🟣Point-to-Point

Point-to-Point -- паттерн, в котором один отправитель передает сообщение одному получателю через очередь сообщений.

Работает также как Publish-Subscribe, только тут 1 получатель

Зачем нужно

Для гарантированной доставки сообщений одному получателю. Обеспечивает строгую очередность и порядок обработки.
⏩ может быть реализовано с помощью систем управления очередями (например, JMS, RabbitMQ)
⏩API паттерны: с помощью REST API, работающих с брокерами сообщений

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

➕гарантированная доставка сообщений (надежное хранение сообщений в очереди)
➕последовательный порядок обработки сообщений в очереди
➕независимая работа отправителя и получателя

♥️ограничение на одного получателя
♥️потенциальная задержка из-за обработки очереди

➡️ Пример: очереди задач, системы обработки заказов, логирование, финансовые транзакции


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

Репост: