Технические практики Agile
🔨 Agile включает практики, которые помогают быстрее реагировать на изменения:
• Continuous Integration (CI): код собирается и тестируется автоматически.
• Code Review: регулярный контроль кода помогает улучшать качество.
• Refactoring: поддержка кода в чистом и понятном состоянии.

💡 В Agile это позволяет:
• Сокращать время исправления ошибок.
• Повышать производительность.

🔗 #SYSTEMDESIGN

🔧 Основы протокола SOAP, структура сообщений и WSDL

SOAP (Simple Object Access Protocol) — это протокол обмена сообщениями, используемый для взаимодействия между приложениями через сеть. Основное преимущество SOAP — его независимость от языка программирования и платформы.

📜 Структура SOAP-сообщения (XML-файла):
SOAP-сообщения формируются в формате XML и состоят из 4 основных частей:
1️⃣ Envelope — обёртка, которая определяет границы сообщения.
2️⃣ Header (необязательный) — метаинформация, например, данные аутентификации.
3️⃣ Body — основное содержимое сообщения (данные запроса или ответа).
4️⃣ Fault (необязательный) — информация об ошибках, если произошёл сбой.

🔗 Пример SOAP-сообщения:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    <auth:Authentication xmlns:auth="http://example.com/auth">
      <auth:Username>user</auth:Username>
      <auth:Password>pass</auth:Password>
    </auth:Authentication>
  </soap:Header>
  <soap:Body>
    <example:Request xmlns:example="http://example.com/data">
      <example:Parameter>Value</example:Parameter>
    </example:Request>
  </soap:Body>
</soap:Envelope>

🛠 WSDL (Web Services Description Language):
WSDL — это XML-документ, который описывает веб-сервис. Он включает:
• Типы данных: форматы данных, которые используются в сообщениях.
• Операции: методы, которые поддерживает веб-сервис.
• Порт: адрес веб-сервиса.
• Протокол: описание, как взаимодействовать с сервисом (например, SOAP).

🔗 #INTEGRATION

📄 Что такое XSD-схема (XML Schema)?

XSD (XML Schema Definition) — это стандарт, который используется для описания структуры, содержимого и ограничений XML-документа. Она помогает проверить XML-документ на соответствие определённым правилам и гарантировать его корректность.

🔍 Основные возможности XSD:
1️⃣ Определение структуры документа: Указывает, какие элементы и атрибуты допустимы.
2️⃣ Типизация данных: Позволяет задать типы данных, такие как строки, числа, даты и др.
3️⃣ Ограничения и правила: Можно задать минимальные и максимальные значения, обязательные элементы, регулярные выражения для валидации и др.
4️⃣ Иерархия и вложенность: Описывает отношения между элементами (родитель-ребёнок).

✏️ Пример XSD-схемы:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="Person">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="FirstName" type="xs:string"/>
        <xs:element name="LastName" type="xs:string"/>
        <xs:element name="Age" type="xs:integer" minOccurs="1" maxOccurs="1"/>
      </xs:sequence>
      <xs:attribute name="id" type="xs:string" use="required"/>
    </xs:complexType>
  </xs:element>
</xs:schema>

🔧 Объяснение:
• Элемент Person содержит три вложенных элемента: FirstName, LastName, Age.
• Поле id задаётся как атрибут с обязательным использованием.


🔗 #INTEGRATION

Новый вопрос – новый чат 👍😊

Разница между RabbitMQ и Kafka. Когда что выбрать?

🔧 RabbitMQ и Kafka — два популярных брокера сообщений, но их цели и сценарии использования различаются.

💡 RabbitMQ
RabbitMQ — это традиционный брокер сообщений, ориентированный на управление очередями и маршрутизацию.

Особенности:
✅ Асинхронное общение между сервисами.
✅ Сложные схемы маршрутизации (Direct, Fanout, Topic).
✅ Поддержка множества протоколов (AMQP, MQTT, STOMP).

Когда использовать?
🔹 Для систем с небольшим или средним объёмом сообщений.
🔹 Там, где требуется сложная маршрутизация.
🔹 В системах, где время доставки сообщений критично.

💡 Kafka
Kafka — это платформа потоковой обработки, разработанная для обработки огромного объёма данных.

Особенности:
✅ Высокая пропускная способность.
✅ Подходит для хранения истории сообщений.
✅ Поддерживает обработку потоков данных в реальном времени.

Когда использовать?
🔹 Для систем с большим объёмом данных (Big Data).
🔹 Для потоковой аналитики.
🔹 Для обработки данных в реальном времени.

Сравнение:
• RabbitMQ: Лучший выбор для очередей и управления задачами.
• Kafka: Идеален для обработки больших данных и событийного взаимодействия.

🔗 #INTEGRATION

Как брокеры сообщений гарантируют доставку?

🔒 RabbitMQ и Kafka используют разные подходы для обеспечения доставки сообщений, делая их надёжными.

💡 RabbitMQ
RabbitMQ гарантирует доставку с помощью:
1️⃣ Подтверждения сообщений (ACK): Сообщение удаляется из очереди только после подтверждения обработчиком.
2️⃣ Хранение сообщений (Durable): Сообщения сохраняются на диск, чтобы избежать потерь при сбоях.
3️⃣ Механизма Dead Letter Queue (DLQ): Неполученные или отклонённые сообщения отправляются в отдельную очередь.

Гарантии RabbitMQ:
✅ Доставка каждого сообщения один раз.
✅ Перемещение сообщений при сбоях.

💡 Kafka
Kafka реализует гарантии с помощью:
1️⃣ Репликации: Данные копируются между несколькими брокерами для отказоустойчивости.
2️⃣ Подтверждения записи (ACKs): Производитель может настраивать уровень подтверждений (либо от одного брокера, либо от всех).
3️⃣ Retention Policy: Сообщения хранятся в топиках в течение заданного времени или до достижения объёма.

Гарантии Kafka:
✅ Доставка «как минимум один раз» или «точно один раз» при правильной настройке.
✅ Высокая устойчивость к сбоям.

Ключевая разница:
• RabbitMQ: Фокус на гарантии доставки через очереди и подтверждения.
• Kafka: Высокая пропускная способность, репликация и хранение истории данных.

🔗 #INTEGRATION

База в IT?

🧘 Философия Python: 19 принципов для красивого кода

1. Красота лучше, чем уродство.
2. Лучше, чтобы всё было понятно, чем скрыто.
3. Простота всегда лучше сложности.
4. Но сложность всё же лучше, чем хаос.
5. Лучше, чтобы всё было на одном уровне, чем вложено друг в друга.
6. Меньше и лаконичнее — лучше, чем перегруженно.
7. Код должен быть легко читаемым.
8. Особые случаи не стоят того, чтобы нарушать правила.
9. Практичность важнее абсолютной чистоты.
10. Ошибки не должны проходить незамеченными.
11. Разве что вы явно указали, что их можно игнорировать.
12. Если что-то неясно, не пытайтесь угадать решение.
13. Должен быть один — и, по возможности, только один — очевидный способ сделать это.
14. Хотя этот способ может быть неочевидным, если вы не голландец.
15. Лучше сделать что-то сейчас, чем откладывать навсегда.
16. Хотя в некоторых случаях лучше подождать, чем делать сразу.
17. Если идею трудно объяснить, она, скорее всего, плохая.
18. Если идею легко объяснить, она, возможно, хорошая.
19. Пространства имён — это круто! Давайте использовать их чаще.

Оригинал:

1. Beautiful is better than ugly;
2. Explicit is better than implicit;
3. Simple is better than complex;
4. Complex is better than complicated;
5. Flat is better than nested;
6. Sparse is better than dense;
7. Readability counts;
8. Special cases aren't special enough to break the rules;
9. Although practicality beats purity;
10. Errors should never pass silently;
11. Unless explicitly silenced;
12. In the face of ambiguity, refuse the temptation to guess;
13. There should be one — and preferably only one — obvious way to do it;
14. Although that way may not be obvious at first unless you're Dutch;
15. Now is better than never;
16. Although never is often better than right now;
17. If the implementation is hard to explain, it's a bad idea;
18. If the implementation is easy to explain, it may be a good idea;
19. Namespaces are one honking great idea — let's do more of those!

Артефакты Scrum: от идей до результата
В Scrum используются артефакты, которые помогают организовать работу и обеспечить прозрачность.

📂 Основные артефакты:
1️⃣ Product Backlog
Список всех задач и идей для продукта. Приоритеты определяет Product Owner.

2️⃣ Sprint Backlog
Подмножество задач из Product Backlog, которые команда планирует выполнить в текущем спринте.

3️⃣ Increment
Готовая часть продукта, которую можно продемонстрировать или даже использовать.

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

🔗 #SYSTEMDESIGN

Закон дырявых абстракций в действии:
🕳 Абстракции, такие как модели OSI или TCP/IP, упрощают сетевое взаимодействие, скрывая от пользователя сложные детали. Однако эти абстракции неидеальны, и их "дыры" становятся проблемой при реальной интеграции:

• TCP: Предполагается, что пакеты передаются гарантированно, но в реальности потеря пакетов, задержки и перегрузки сети всё равно требуют учёта и дополнительной логики.
• WebSocket: Работает как "прозрачный" двусторонний канал, но часто требует настройки таймаутов, реконнектов и обработки ошибок из-за разрывов соединений.
• FTP: Предполагает простую передачу файлов, но не учитывает сложные сценарии восстановления передачи при сетевых сбоях.

🔗 #SYSTEMDESIGN

У всех же так?

Базовые операции SQL

💾 SQL — это ключевой инструмент для работы с базами данных. Одни из самых важных операций известны как CRUD:

1️⃣ Создание записи (Create):
Добавляем новую запись с помощью команды INSERT.

INSERT INTO employees (name, age, department)  
VALUES ('Анна', 30, 'Маркетинг');

👉 Этот запрос добавляет сотрудника "Анна" в отдел "Маркетинг".


2️⃣ Чтение данных (Read):
Используем SELECT, чтобы извлечь данные.

SELECT name, department  
FROM employees  
WHERE age > 25;

👉 Этот запрос возвращает имена и отделы всех сотрудников старше 25 лет.


3️⃣ Обновление данных (Update):
Изменяем существующие записи с помощью UPDATE.

UPDATE employees  
SET department = 'Продажи'  
WHERE name = 'Анна';

👉 Теперь "Анна" работает в отделе "Продажи".


4️⃣ Удаление записи (Delete):
Удаляем ненужные данные с помощью DELETE.

DELETE FROM employees  
WHERE name = 'Анна';

👉 Этот запрос удаляет запись о сотруднике "Анна".

💡 Советы для работы с CRUD:
• Используйте WHERE, чтобы применять изменения только к нужным строкам.
• Будьте осторожны с UPDATE и DELETE: без условий они затронут всю таблицу.

🔗 #DBMS

Архитектура хранилищ данных: традиционная vs облачная

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


Почему облачные хранилища данных?
1️⃣ Экономия ресурсов: Нет необходимости покупать и поддерживать физическое оборудование.
2️⃣ Гибкость: Быстрая настройка и масштабирование под текущие потребности бизнеса.
3️⃣ Производительность: Массовая параллельная обработка ускоряет выполнение аналитических запросов.


Традиционная архитектура: подходы
🔹 Трёхуровневая структура:
• Нижний уровень: Извлечение данных из источников.
• Средний уровень: Преобразование данных для анализа с помощью OLAP.
• Верхний уровень: Клиентский интерфейс для визуализации и анализа.

🔹 Подходы к проектированию:
• Ральф Кимбалл: Децентрализованное хранилище через витрины данных (подход «снизу вверх»).
• Билл Инмон: Централизованное корпоративное хранилище с нормализованной моделью (подход «сверху вниз»).


Новые облачные архитектуры
☁️ Amazon Redshift:
• Использует колоночное хранение и массовую параллельную обработку.
• Поддерживает структурированные данные и интеграцию с AWS-сервисами.

☁️ Google BigQuery:
• Облачная архитектура без серверов с автоматическим управлением ресурсами.
• Позволяет загружать данные в реальном времени.

☁️ Panoply:
• Самооптимизирующаяся система на основе машинного обучения.
• Ускоряет обработку данных от источника до анализа.


Сложности при работе с облачными хранилищами
1️⃣ Настройка ETL/ELT-процессов для загрузки данных.
2️⃣ Работа с полуструктурированными данными.
3️⃣ Оптимизация кластеров и запросов для высокой производительности.
4️⃣ Резервное копирование и восстановление данных требуют тщательной настройки.

🔗 #DBMS

Когда тебя всё-таки взяли с липовым резюме🧑‍💻

Пирожки с картошкой или с капустой?

Секреты оптимальной работы с базами данных

Индексы в базах данных: зачем и как их использовать?
Индексы применяются для ускорения выполнения запросов с фильтрацией (WHERE), сортировкой (ORDER BY), группировкой (GROUP BY), агрегацией (SUM, COUNT) и объединением таблиц (JOIN). Они позволяют сократить время выборки данных за счёт создания структуры, облегчающей доступ к строкам таблицы. Составные индексы оптимизируют запросы по нескольким столбцам, а уникальные индексы предотвращают дублирование данных. Однако индексы увеличивают нагрузку на операции INSERT, UPDATE и DELETE, требуя регулярного обновления. Их использование эффективно для часто запрашиваемых данных, но может быть избыточным для редко используемых столбцов.

Типы индексов в реляционных БД:
1️⃣ B-Tree: Универсальный тип, эффективен для диапазонных запросов.
2️⃣ Hash: Быстрее всего на точных совпадениях, но не подходит для диапазонов.
3️⃣ Bitmap: Идеален для столбцов с небольшим числом уникальных значений.

Нужно ли индексировать внешние ключи (FK)?
✅ Да! Это ускоряет выполнение запросов с JOIN и предотвращает замедления при проверке связей между таблицами. Без индекса FK проверка ограничений может стать узким местом.

Индексация для агрегации: избыточность или польза?
Если атрибут используется только для агрегации (SUM, COUNT, AVG), индекс может быть полезен при частом выполнении таких запросов. Однако, если данные обновляются часто, индекс может замедлять систему. Оцените частоту операций перед индексацией.

Нормализация: какую НФ (нормальную форму) выбрать?
Чтобы понять, до какой нормальной формы (НФ) нормализовать данные:
1️⃣ 1НФ: Минимум требований: атомарные значения в ячейках.
2️⃣ 2НФ: Если есть составные ключи, избегайте частичных зависимостей.
3️⃣ 3НФ: Избегайте транзитивных зависимостей (значения зависят друг от друга через третью колонку).

🔗 #DBMS

Что такое Service Level Agreement (SLA)?

💼 SLA (Service Level Agreement) — это соглашение об уровне предоставляемого сервиса между поставщиком услуги и клиентом. Оно описывает ключевые параметры и характеристики, которые определяют качество и доступность услуг.

Что включает SLA?
1️⃣ Доступность — процент времени, в течение которого услуга доступна (например, 99,9% времени).
2️⃣ Время реакции — скорость, с которой поставщик начнёт реагировать на инциденты или запросы.
3️⃣ Обязательства — чёткие гарантии качества предоставляемого сервиса.

Почему это важно?
SLA позволяет:
• Установить ожидания между клиентом и поставщиком.
• Минимизировать риски, связанные с нарушениями сервиса.
• Упростить управление и мониторинг предоставляемых услуг.

Пример: Для облачного сервиса может быть указано, что его доступность составляет 99,95%, а время реакции на критические инциденты — не более 1 часа.

🔗 #SYSTEMDESIGN

2 типа увольнения😂

SLO и SLI: как улучшить пользовательский опыт и контролировать качество сервиса

Когда речь заходит о качественном предоставлении ИТ-услуг, важно понимать, что ключевые параметры SLI (Service Level Indicator) и SLO (Service Level Objective) играют огромную роль в оценке и улучшении пользовательского опыта.

👉 Что такое SLI?
SLI — это измеримый индикатор качества работы сервиса. Это может быть время отклика, процент ошибок или доступность. Например, если доступность сервиса составляет 99,95%, это значит, что он доступен практически всегда.

👉 Что такое SLO?
SLO — это целевое значение для SLI. Если доступность сервиса измеряется через SLI, то SLO может быть определено как 99,95% в месяц. Это цель, которой стремится достичь команда, обеспечивая стабильную работу системы.

🛠 Практическое внедрение
1. Определите критичные пути пользователя. Начните с выявления транзакций или сервисов, которые напрямую влияют на пользовательский опыт, например, добавление товара в корзину или оплата.
2. Выберите метрики для SLI. Это могут быть время выполнения операций, процент ошибок или производительность.
3. Установите SLO и Error Budget. Error Budget определяет допустимое время простоя. Например, если SLO равен 99,95% доступности, Error Budget может составить 21 минуту в месяц.
4. Настройте визуализацию. Используйте инструменты мониторинга, такие как Instana, для отслеживания метрик и визуализации статуса SLO.

🚨 Error Budget: право на ошибку
Этот показатель помогает командам контролировать допустимый уровень недоступности сервиса. Например, если сервис выходит за рамки Error Budget, приоритетными задачами становятся устранение проблем и работа над стабильностью, а не внедрение новых фич.

📊 Инструменты для контроля
В инструментах вроде Instana вы можете создать SLI, определить метрики и установить виджеты для мониторинга SLO. Это позволяет оперативно отслеживать статус сервиса и предпринимать меры в случае нарушений.

🔗 #SYSTEMDESIGN

Умный брокер или глупый consumer?

В мире брокеров сообщений часто обсуждают концепцию "умный брокер, глупый consumer" и наоборот. Эта характеристика описывает архитектуру распределения задач между брокером сообщений и потребителями. Давайте разберемся, где в этом спектре находится Kafka.

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

📌 Глупый брокер, умный consumer
Теперь давайте разберем противоположную концепцию. Kafka ближе к этой модели. Брокер в Kafka работает как высокопроизводительное хранилище, которое просто сохраняет и отдает сообщения. Все сложные задачи — например, управление смещениями (*offsets*), распределение нагрузки и повторная обработка сообщений — возлагаются на потребителей.

🎯 Почему Kafka выбирает "глупый брокер"?
• Производительность. Упрощенный брокер может работать с огромными объемами данных, минимально вмешиваясь в обработку. Kafka поддерживает миллионы сообщений в секунду.
• Гибкость. Потребители полностью контролируют логику обработки: какой *offset* читать, как обрабатывать ошибки и в каком темпе работать. *(Offset — это позиция, с которой потребитель начинает читать сообщения в топике.)*
• Долговременное хранение. Kafka сохраняет данные в течение заданного времени, позволяя потребителям возвращаться к старым сообщениям.