🌎 Синхронизация времени по NTP

NTP (Network Time Protocol) — протокол для синхронизации времени между компьютерами в сети.
Позволяет устанавливать точное время на устройствах, синхронизируя их часы с часами специальных серверов времени (NTP-серверами)

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

1⃣Запрос времени: клиент отправляет запрос на сервер NTP с собственной меткой времени
отправления (T1)
2⃣ Ответ от сервера: сервер NTP записывает время получения запроса (T2), отправляет ответ с
временем отправления (T3) и временем получения (T2)
3⃣ Получение ответа: клиент сохраняет время получения ответа (T4) и рассчитывает сетевую
задержку и смещение во времени своих часов для их корректировки.


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

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

Обеспечение безопасности
➡ для своевременного мониторинга и реагирования, для проверки подлинности транзакций или предотвращения повторных атак

Координация действий между системами
➡помогает координировать действия между серверами и другими устройствами.

Работа распределённых БД
➡для правильного применения изменений и согласования данных между различными узлами.

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


За счет чего достигается высокая точность

😀 Высокоточные источники времени: использует атомные часы и GPS-синхронизированные серверы времени UTC.
UTC (всемирное координированное время) обеспечивает единый стандарт времени для всего мира.
Время с атомных часов и серверов UTC распространяется через сеть
😀 Алгоритмы коррекции задержек: используются ы для оценки и коррекции задержек в сети между клиентами и серверами времени. Это позволяет компенсировать задержки и улучшать точность синхронизации


Где применяется

😀Сетевые инфраструктуры: для согласования времени на маршрутизаторах и серверах
😀Финансовые системы: для точной фиксации времени транзакций
😀Системы безопасности: для точного ведения логов событий
😀Облачные сервисы и дата-центры: для координации операций между серверами


Кейсы использования

У пользователя украли данные карты и хотят снять деньги
💠Пользователь в ту же секунду блокирует карту
💠Банковская система отсортирует по времени входящие сообщения о снятии денег и о блокировке карты
💠Если часы пользователя, отстают, мошеннику удастся снять деньги
✅ Если обмен сообщениями проходит с использованием NTP, клиент успеет спасти деньги

Компилятор при пересборке проверяет время изменения файла
🟡Если исходный файл имеет большее время, чем его объектный файл, значит, исходный файл был изменен, и его нужно перекомпилировать
🟡При отставании часов распределённой системы даже на миллисекунду результат компиляции будет состоять из старых и новых файлов. Это делает отладку невозможной
✅ Если исходные файлы из разных частей системы передаются через NTP, то с отладкой кода проблем нет


Классы точности NTP-серверов

Цифра - уровень по отношению к UTC
🟡 Stratum 0 — референсные часы (атомные, GPS), обеспечивают наиболее точное время.
Это устройства не подключены напрямую к сети, служат основным источником
времени для серверов Stratum 1
🟡 Stratum 1 — серверы, напрямую подключенны к Stratum 0.
Самые точные серверы, могут учитывать время с точностью в одну триллионную долю секунды.
Они используют сложное и дорогое оборудование и обычно
не отвечают на запросы конечных пользователей, обслуживают только серверы более
низкого уровня.
🟡 Stratum 2 и выше — получают данные от Stratum 1 и работают с погрешностью примерно 0,001 секунды.
🟡Stratum 3 — получают данные от stratum 2, с точностью до 0,05 секунды. Дальше идут уровни 4, 5 и т.д.


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

🔵 Уровни изоляции транзакций в базах данных

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

Изоляция является одним из ключевых компонентов ACID

Напомним, транзакция в БД — последовательность операций, выполняемых как единое целое.
Должны быть либо полностью выполнены, либо полностью отменены.
Это обеспечивает целостность данных.

Где применяются уровни изоляции

💙в реляционных базах данных (MySQL, PostgreSQL, Oracle и SQL Server)
💙в системах с высоким количеством параллельных транзакций (финансовые, интернет-магазины, системы бронирования)


Основные механизмы

В основном реализуется через механизмы СУБД:
➖Блокировки: предотвращают одновременное чтение и запись одних и тех же данных
➖MVCC: версионирование данных для каждой транзакции

Иные:
➖Паттерны проектирования: например, очереди задач
➖Транзакционные менеджеры: внешние компоненты в распределенных системах


Аномалии при параллельной обработке транзакций

🔘Потерянное обновление: две транзакции одновременно изменяют одни и те же данные, и одно из изменений теряется

0️⃣«Грязное» чтение: транзакция читает данные, которые были изменены другой транзакцией, но еще не зафиксированы

0️⃣Неповторяемое чтение: транзакция повторно читает данные и видит разные значения из-за изменений, внесенных другой транзакцией

0️⃣Фантомная запись: транзакция повторно выполняет запрос и видит новые строки, добавленные другой транзакцией


Уровни изоляции


💙 Read Uncommitted (Чтение неподтвержденных данных)

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

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

➖Возможны все проблемы: "грязное" чтение, повторное обновление, неповторяемое чтение, фантомные записи


💙 Read Committed (Чтение подтвержденных данных)

Транзакции могут читать только те изменения, которые были зафиксированы
Механизм: блокировка строк на запись до завершения транзакции

💙Когда важна балансировка между целостностью данных и производительностью
💙 Система интернет-магазина: заказы читаются только после их подтверждения
💙 Большинство OLTP систем

➕избегается "грязное" чтение и повторное обновление
➖неповторяемое чтение и фантомные записи


💙 Repeatable Read (Повторяемое чтение)

Транзакция A читает данные, они блокируются для изменения другими транзакциями.
Транзакция B не может изменять эти данные, пока транзакция A не завершится, но может добавлять новые строки.
Транзакция A повторно читает те же данные, но не видит новых строк.
Механизм: блокировка всех прочитанных строк до завершения транзакции

💙Когда критично избегать несогласованность данных
💙 Финансовая система: состояние счета должно быть неизменным на протяжении всей транзакции

➕избегаются "грязное" чтение, неповторяемое чтение, повторное обновление
➖фантомные записи


💙 Serializable (Сериализуемость)

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

💙Когда есть высокие требованиями к целостности данных, а параллельные транзакции могут привести к конфликтам
💙 Банковская система: одновременные транзакции по переводу средств должны быть строго упорядочены

➕ Избегаются все аномалии


Как выбрать уровень изоляции

➖Требования: какие аномалии допустимы
➖Регулирование: законодательные и отраслевые стандарты
➖Тестирование: для оценки консистентности данных и нагрузки на систему

Чем выше уровень изоляции, тем:
💙больше шансов блокировки транзакций
💙выше целостность данных

💙меньше ошибок из-за параллельных транзакций
💙меньше производительность системы

#бд

Apache Kafka

Apache Kafka – распределённая система для обработки данных в режиме реального времени.
Работает как почта — одни сервисы передают туда сообщения, а другие — получают.
Называют брокером сообщений, так как выступает в качестве посредника


Компоненты

🟣Продюсеры — приложения, которые публикуют данные
🟣Консьюмеры — приложения, которые читают

⚪️Топики – каналы, куда продюсеры публикуют сообщения. Могут иметь множество подписчиков (консьюмеров)
⚪️Партиции – части топиков для параллельной обработки данных.
Сообщения в партиции хранятся в строгом порядке

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

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

*️⃣Публикация: продюсер отправляет данные в топик, выбирает партицию для записи (с помощью ключа сообщения, по алгоритму round-robin)

*️⃣Хранение: сообщение записывается в выбранную партицию на одном из брокеров.
Происходит репликация (об этом далее)

*️⃣Чтение: консьюмер запрашивает данные из топика, Kafka направляет консьюмера к соответствующей партиции.
Читает, начиная с последнего прочитанного сообщения (офсета).

*️⃣Обновление офсетов: консьюмер периодически обновляет свой текущий офсет (в Zookeeper / в самом Kafka, зависит от настройки)
Это позволяет возобновить чтение с правильного места в случае сбоя.


Репликация данных

✨Реплика в Kafka – копия партиции топика, хранится на другом брокере для обеспечения надежности и отказоустойчивости.

✨Лидер — основная копия партиции, которая обрабатывает все операции записи и чтения.
Фолловеры — дополнительные копии, которые синхронизируются с лидером.

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

➖Сообщения записываются в лидера и затем копируются на фолловеров
➖Фолловеры следят за лидером и обновляются в реальном времени
➖Если лидер выходит из строя, один из фолловеров становится новым лидером для непрерывности работы

✨Replication factor — количество реплик для каждой партиции. Например, фактор репликации 3 означает 1 основную копию и 2 резервные.


Типы доставки сообщений

🟠At most once: сообщение может быть доставлено максимум один раз, возможны потери
🟠At least once — как минимум один раз, возможны дублирования
🟠Exactly once — ровно один раз, без потерь и дублирования

Надежность доставки

Продюсеры могут настроить количество подтверждений (acks) от брокеров
😀acks=0: Без подтверждений, низкая надежность.
😀acks=1: Подтверждение от лидера, средняя надежность.
😀acks=all: Подтверждение от всех реплик, высокая надежность.


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

*️⃣Прямое подключение: через стандартные клиенты (Java, Python, Go и др.)
*️⃣Коннекторы Kafka Connect: для интеграции с БД, хранилищами и др.
*️⃣Потоковые платформы: Apache Flink, Apache Spark и др


Примеры

Синхронная работа

⏺Синхронная передача: приложения отправляют данные и ожидают подтверждения от Kafka
☺️ параметр acks=all у продюсера, чтобы дождаться подтверждения от всех реплик перед продолжением

⏺Запрос-ответ: консьюмер отправляет запрос и ожидает ответа в другом топике.
☺️ уникальные ключи для корреляции запросов и ответов

Асинхронная

⏺Логирование и мониторинг: отправка логов без ожидания подтверждения
☺️ параметр acks=1 или acks=0 для продюсеров, чтобы минимизировать задержку

⏺Обработка событий
☺️ группа консьюмеров параллельно обрабатывает события

⏺ETL-процессы: загрузка в хранилища через Kafka
☺️ Kafka Connect для интеграции с источниками и приемниками


Kafka как хранилище данных

😀Можно настраивать время хранения сообщений от минут до нескольких лет
😀Сообщения хранятся в сегментах и индексируются ✨ эффективное управление большими объемами данных
😀Высокая скорость записи и чтения данных

Ограничения
😀Нет сложных запросов и транзакционной поддержки
😀Старые данные автоматически удаляются по истечению срока
😀Иногда нужна интеграция с др системами (HDFS, S3, реляционные БД)


📎 Подборка материалов в этом посте

#интеграции

✉️ Интеграция через файловый обмен

Интеграция через файловый обмен — один из 4-х главных методов интеграции систем. Системы обмениваются между собой обычными файликами в стандартных форматах, например, CSV, XML или JSON.

Особенности

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

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

🟧между корпоративными системами: для передачи отчетов, данных о продажах, бухгалтерской информации и тд
➡ для автоматизации и упрощения обмена данными
🟧B2B-интеграции: например, для обмена данными между партнерами и поставщиками
➡ для надежного и безопасного обмена
🟧передача старых данных на серверы или облачные хранилища для долгосрочного хранения
🟧регулярное копирование данных на удаленные серверы

Способы

1⃣ Протоколы

🟡FTP (File Transfer Protocol) — простой протокол для передачи файлов, но без встроенной защиты
🟡FTPS (FTP Secure) -- расширение FTP с использованием SSL/TLS для шифрования
🟡SFTP (SSH File Transfer Protocol) — расширение FTP, обеспечивает защищенную передачу данных с использованием SSH (Secure Shell).

✨SSH — сетевой протокол прикладного уровня для защищенного соединения между клиентом и сервером

2⃣ Общие сетевые диски: общие папки на локальных серверах, доступные через внутреннюю сеть для совместного доступа и редактирования файлов внутри организации.

3⃣ Облачные сервисы: удаленные серверы для хранения файлов с доступом через интернет (например, AWS S3, Google Drive)

4⃣ Отправка файлов как вложения по электронной почте
🧑‍🏫есть ограничения на размер файлов и проблемы с безопасностью и конфиденциальностью данных
🧑‍🏫актуально для небольших файлов и нечастых обменов


Принцип работы FTP, FTPS, SFTP

FTP
➡️клиент подключается к серверу
➡️вводит логин, пароль
➡️файлы передаются в нешифрованном виде через отдельный порт
➡️отключение клиента от сервера

FTPS
➡️подключается с использованием SSL/TLS для шифрования
➡️вводит логин, пароль. Передаются по защищенному каналу
➡️файлы передаются в зашифрованном виде через защищенный канал
➡️отключение

SFTP
➡️подключается с соединением через SSH
➡️вводит логин, пароль / использует SSH-ключи
➡️файлы передаются в зашифрованном виде через SSH-соединение
➡️отключение


Пример использования

В ETL процессе:
➡ извлечение: использование SFTP для загрузки CSV файлов с данными
➡ преобразование: чтение файлов с данными, удаление дубликатов, приведение дат к единому формату, агрегация данных.
➡ загрузка: передача обработанных данных через FTPS на сервер БД для дальнейшего анализа

Обмен данными между отделом логистики и складом
➡ отдел логистики создает файлы с информацией о грузах в формате XML
➡ логистика загружает файлы на защищенный SFTP-сервер
➡ склад скриптом скачивает их и импортирует


Как обеспечить безопасность

🟧 SFTP: использование SSH для шифрования данных и аутентификации пользователей обеспечивает безопасную передачу данных.
🟧 Шифрование данных: При использовании облачных хранилищ или общих сетевых дисков рекомендуется шифровать файлы перед передачей.
🟧 Контроль доступа: Настройка прав доступа и использования аутентификации для ограничения доступа к файлам.
🟧 Антивирусная защита: Проверка файлов на вирусы и вредоносные программы перед и после передачи.
🟧 Логирование и мониторинг: Ведение журналов передачи файлов и мониторинг активности для обнаружения и предотвращения несанкционированного доступа.


Сервисы и приложения

➡️ FTP-клиенты: FileZilla, Cyberduck, CuteFTP
➡️ Интеграционные платформы: Mulesoft, Boomi, Talend для автоматизации обмена файлами
➡️ Сетевые файлообменники: NAS (Network Attached Storage), SAN (Storage Area Network)


#интеграции

✍️ Кибератаки и их виды

Виды 

✖️  Межсайтовый скриптинг (XSS , Cross-Site Scripting)

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

Атака через ввод данных в формы на сайте или URL-адреса.
Скрипт выполняется в контексте сайта.
Может красть данные, перенаправлять пользователя или выполнять другие вредоносные действия

✅ меры: валидация и экранирование вводимых данных, использование Content Security Policy (CSP)

💙CSP — заголовок HTTP. Ограничивает источники из которых браузер может загружать ресурсы (скрипты, стили, изображения и т.д.).


✖️  Кликджекинг (Clickjacking)

Обман пользователя, чтобы он кликнул на что-то отличное от того, что он видит

Веб-страница размещает невидимый фрейм над кнопками или ссылками, чтобы пользователи выполняли нежелательные действия

✅  меры: использование  X-Frame-Options, CSP, фильтров спама,

💙X-Frame-Options — заголовок HTTP. Предотвращает загрузку веб-сайтов в iframe (HTML-элемент для встраивания одной веб-страницы в другую)


✖️  SQL-инъекции

Внедрение вредоносного SQL-кода в запросы к БД

Атака через формы ввода данных, URL-адреса или параметры HTTP-запросов.
Вредоносный SQL-код может извлекать, изменять или удалять данные в БД

✅  меры: использование подготовленных выражений (prepared statements), валидация и экранирование входных данных


✖️ Фишинг (Phishing)

Для получения конфиденциальной информации

Атака через поддельные веб-сайты, электронные письма или сообщения

✅  меры: обучение пользователей, фильтры электронной почты, двухфакторная аутентификация (2FA)


✖️ DDoS атаки (Distributed Denial of Service)

Перегрузка серверов, сайтов или сетей с целью сделать их недоступными.

Атака происходит через множество скоординированных запросов с различных устройств, часто зараженных вредоносным ПО.

✅  меры: сетевые фильтры, распределенные сетей доставки контента (CDN), системы предотвращения DDoS-атак (Cloudflare, Akamai Kona Site Defender, Imperva Incapsula)


✖️ Атака посредника (MitM, Man-in-the-Middle)

Перехват коммуникаций между двумя сторонами с целью кражи или изменения данных.

✅ меры: использование HTTPS, VPN, шифрование


✖️ Атака «грубой силой» (Brute Force Attack)

Подбор паролей методом перебора возможных комбинаций

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


Способы защиты от кибератак

⏩ Обучение о методах кибератак
⏩ Регулярное обновление антивирусов
⏩ Брандмауэры и IDS/IPS:
  🟡брандмауэры (межсетевые экраны) фильтруют трафик
  🟡IDS (Intrusion Detection System) анализирует сетевой трафик и уведомляет о возможных угрозах
  🟡IPS (Intrusion Prevention System) обнаруживает угрозы и автоматически принимает меры для их предотвращения (например, блокируя подозрительный трафик)
⏩ Шифрование данных
⏩ Многофакторная аутентификация
⏩ Регулярное обновление ПО
⏩ Разделение сети на сегменты для ограничения распространения атак.
⏩ VPN: безопасный удаленный доступ


Для чего знать аналитику?

◾️чтобы идентифицировать и минимизировать риски
◾️включать меры безопасности в архитектуру систем
◾️анализировать инциденты
◾️внедрять защитные механизмы


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

🌎 Веб-приложения: SPA , MPA, PWA

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

SPA (Single Page Application)

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

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

🔵Из чего состоит
💙клиентская часть (HTML, CSS, JavaScript)
💙фреймворки и библиотеки (React, Angular, Vue.js)
💙API для взаимодействия с сервером

🔖Как работает
1. загрузка начальной HTML-страницы
2. загрузка CSS и JavaScript файлов
3. инициализация фреймворка/библиотеки
4. запросы к API для получения данных
5. динамическое обновление DOM с использованием данных из API
6. обновление URL и состояния приложения без перезагрузки страницы
🔵Плюсы и минусы
💛 быстрая загрузка после первого запроса  (кэширование ресурсов и данных на клиенте)
💛 плавные и мгновенные переходы между разделами (виртуальный DOM и клиентская маршрутизации)
💛 меньше нагрузка на сервер (меньше количество запросов к серверу)

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

➡️ Примеры: Яндекс.Почта, ВКонтакте

✳️ Интеграция
⭕REST API, GraphQL для взаимодействия с сервером
⭕Веб-сокеты для реального времени


MPA (Multi Page Application)

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

🟢Применение: сайты с большим количеством контента, новостные сайты, интернет-магазины

🟢Зачем нужно: легче интегрировать SEO (оптимизацию сайтов для поисковых систем), т.к. у каждой страницы свой уникальный URL

🟢Из чего состоит
🟢серверная часть (бэкэнд: на PHP, Python, Java и тд)
🟢клиентская часть (HTML, CSS, JavaScript)
🟢система маршрутизации

🔖Как работает
1. пользователь переходит по URL
2. сервер обрабатывает запрос и возвращает HTML-страницу
3. браузер загружает ее отображает
4. при переходе на другую страницу процесс повторяется
5. доп. данные могут загружаться через AJAX-запросы

🟢Плюсы и минусы
➕простота SEO-оптимизации (каждая страница имеет свой статический контент)
➕четкая структура и маршрутизация (страницы обрабатываются отдельно)
➕простая архитектура

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

➡️ Примеры: Озон, сайт РБК

✳️ Интеграция
🟢REST API для взаимодействия с сервером
🟢встраивание iframe для отдельных модулей


PWA (Progressive Web Application)

PWA — сочетает возможности веб-приложений и нативных мобильных приложений.
Работает офлайн, отправляет push-уведомления и может устанавливаться на устройствах.

⚪Применение: веб-приложения, требующие офлайн-доступа и уведомлений, мобильные версии веб-сайтов

⚪Зачем нужно: обеспечивает нативный пользовательский опыт в веб-приложении, увеличивает вовлеченность пользователей

⚪Из чего состоит
⭕ клиентская часть (HTML, CSS, JavaScript)
⭕ Service Workers для работы офлайн
⭕ Web App Manifest для установки на устройства

🔖Как работает
1. пользователь открывает PWA в браузере
2. устанавливаются Service Workers
3. контент кэшируется для офлайн-доступа
4. пользователь может установить PWA на устройство

⚪Плюсы и минусы
➕офлайн-доступ и кэширование
➕push-уведомления
➕можно установить на устройства

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

➡️ Примеры: Лента.ру, КиноПоиск

✳️ Интеграция
🟡Service Workers для кэширования и работы офлайн
🟡Push API для уведомлений
🟡Web App Manifest для
установки на устройства


#развитие #веб

📎 Материалы по SPA, MPA, PWA
1. Web-приложение: понятие, компоненты и принципы работы
2. Веб-программа: описание и особенности
3. Следующий этап развития Веба
4. Веб-приложение и веб-сайт: в чем разница?
5. Влияние service worker'ов на web-приложения
6. Архитектура веб приложения: компоненты, слои и типы
7. JAMstack — зачем, почему и за что
8. Flutter for Web: гайд для начинающих
9. Что нужно для создания веб-приложений
10. Сравнительный анализ сайта, веб-приложения, SPA и PWA
11. Мобильное приложение или веб?
12. Пишем правильный манифест для сайта
13. Как создать Web App Manifest PWA
14. Service Workers. Инструкция по применению

SPA и MPA
15. Single Page Application: как работает сайт-приложение
16. Что такое SPA, и нужно ли оно вашему проекту?
17. Single Page Application
18. Технология SPA: почему вместо обычных сайтов нужно делать веб-приложения
19. Одностраничные (spa) и многостраничные веб-приложения
20. SPA и (MPA): преимущества и недостатки
21. О SPA и MPA

PWA
22. PWA — это просто
23. Всё, что нужно знать о Progressive Web App (PWA)
24. Зачем нужны PWA-приложения: примеры успешного использования
25. PWA vs Native: чек-лист, который поможет выбрать
26. Как запустить мобильное приложение за две недели с помощью PWA
27. PWA: не Chrome'ом единым?
28. PWA не для всех
29. Как сделать Progressive Web Apps: руководство новичка
Секреты Progressive Web Apps: часть 1 | часть 2
30. Одно PWA, чтоб править всеми
31. Как тестировать PWA?
32. Когда проснулся и узнал, что существуют PWA


⏯ Видео
🎓 AnalystDays: Применение веб-аналитики для улучшения UX
🎓 Code Fest: PWA vs. нативные приложения: когда и как выбрать?
1. Как работает веб? MPA, SPA
2. Знакомство с MPA/SPA, SSR/CSR - отличия, недостатки, примеры реализации
3. Роутинг на React. SPA и MPA на примерах
4. Веб-приложение и веб-сайт: разница за 8 минут
5. Чем веб-приложения отличаются от веб-сайтов
6. Как работают SPA (Single Page Application) страницы сайтов в браузерах
7. Всё, что нужно знать о сайтах-одностраничниках (SPA)
8. Веб-приложение (PWA) I Достойная замена мобильному приложению
9. PWA: что такое прогрессивное веб-приложение?
10. PWA – технология будущего? Создание PWA проекта на практике
11. Как работают веб приложения. Что происходит, когда вы вводите адрес в браузере
12. Архитектура современных WEB приложений. Эволюция от А до Я

Архитектура программного обеспечения на практике

✍️ Авторы: Л. Басс, П. Клементс, Р. Кацман
🗓 Год издания: 2006 (2-е издание)
🔤 Язык: русский
📚 Объём: 575 стр.

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

Что внутри:
💩 Основы архитектуры ПО и ключевые атрибуты качества (готовность, производительность, модифицируемость).
💩 Безопасность: подходы к защите данных и инфраструктуры.
💩 Тестирование и расширяемость архитектурных решений.
💩 Приёмы документирования архитектуры, полезные всем участникам проекта.
💩 Методика ATAM (анализ компромиссных архитектурных решений) для выбора оптимальных решений.
💩 Реальные примеры успешных архитектур, включая организационные и технические аспекты.

Почему стоит читать системным аналитикам:
✔️ Помогает глубже понять архитектуру ПО и её влияние на бизнес-требования.
✔️ Даёт инструменты для оценки и документирования архитектурных решений, что делает работу с разработчиками эффективнее.
✔️ Учит учитывать не только технические, но и коммерческие аспекты проектирования систем.

Отзыв на книгу от системного аналитика

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

Паттерны асинхрона: 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, работающих с брокерами сообщений

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

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

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

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


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

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

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

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

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

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

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

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

🔵 Протоколы связи: Основной протокол интернета — это 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 отвечает, и браузер отображает страницу


#сети

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

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-е издание -- Таненбаум Эндрю, Фимстер Ник, Уэзеролл Дэвид

#сети

🔵 Data Warehouse (DWH)

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

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

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

Модели ХД

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


Схемы ХД

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

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

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

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


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

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

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

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

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

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

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

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


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

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


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

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

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

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

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


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

🔅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


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

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

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

⏩ Покер планирования (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. Трехточечная оценка проекта. Как мы оцениваем задачи

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

<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)

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


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

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

❌ Антипаттерны проектирования ПО (часть 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. Антипаттерны (обзор нескольких)


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

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