Что такое 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 сохраняет данные в течение заданного времени, позволяя потребителям возвращаться к старым сообщениям.

Что произойдет, если перезапустить consumer во время обработки сообщения? 🤔

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

1️⃣ Сообщение будет считаться необработанным
В Kafka consumer сам отслеживает, какие сообщения он обработал, с помощью _offset_. Если consumer перезапускается, но не успел подтвердить (_commit_) обработку сообщения, брокер считает, что это сообщение не обработано. После перезапуска это сообщение будет снова отправлено потребителю.

2️⃣ Идемпотентность – ключ к правильной обработке
Если обработка сообщения не является идемпотентной (например, при внесении изменений в базу данных), то повторная обработка одного и того же сообщения может привести к дублированию действий. Поэтому важно проектировать обработку так, чтобы повторный запуск не создавал проблем. Например, использовать уникальные идентификаторы транзакций.

3️⃣ Автоматическая передача другому consumer'у
Если вы используете consumer group, то после перезапуска брокер может переназначить партиции другому consumer'у из той же группы. В этом случае сообщение начнет обрабатываться другим consumer'ом.

4️⃣ Настройка автокоммита
Если у вас включен автоматический коммит (_auto-commit_), есть вероятность, что _offset_ уже был зафиксирован, даже если сообщение фактически не обработано. Это может привести к пропуску сообщения. Чтобы этого избежать, лучше использовать ручной коммит после успешной обработки.

🔗 #SYSTEMDESIGN

Задача: Гарантированная доставка заказов в нестабильный брокер

Есть две системы: система А, в которой создаются заказы, и система Б, внешняя по отношению к системе А. Для интеграции требуется настроить процесс передачи заказов из системы А в брокер на стороне системы Б. Однако брокер системы Б работает нестабильно, что может приводить к сбоям при приёме сообщений. На стороне системы А также имеется собственный брокер сообщений, что добавляет возможности для реализации надёжной доставки. В системе А формируется до 2000 заказов в час. Как можно реализовать процесс таким образом, чтобы гарантировать доставку заказов в брокер системы Б, даже при его нестабильной работе? Какие доработки потребуются на стороне системы А, чтобы минимизировать риски потери данных и обеспечить устойчивую интеграцию?

Ответ:
Для гарантированной доставки заказов в брокер системы Б нужно настроить локальный брокер сообщений в системе А. При создании заказа сообщение о нём отправляется в локальный брокер. Локальный брокер отвечает за попытки доставки в брокер системы Б. В случае недоступности брокера системы Б сообщения остаются в локальном брокере и отправляются повторно до успешной доставки. Для недоставленных сообщений использовать dead-letter queue. Такой подход гарантирует надёжную и масштабируемую интеграцию, минимизируя риски потерь данных.

🛠 Контрольная сумма: зачем она нужна и как работает

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

📌 Простейшие методы
Бит четности – базовый способ, проверяющий четность/нечетность единичных битов. Прост, но пропускает двойные ошибки.
8-битная сумма – складывает значения всех байтов данных. Уязвим, если изменения в байтах компенсируются.

📌 Продвинутые подходы
Для улучшения используют побитовое смешивание или умножение на «магические» числа. Например, алгоритмы CRC (Cyclic Redundancy Check) повышают надежность благодаря равномерному распределению изменений данных.

🔗 #SECURITY

🖥 Stateful vs Stateless: что выбрать?

В программной архитектуре stateful и stateless относятся к способу управления состоянием системы. Разберем их основные различия, преимущества и недостатки.

📌 Stateful (с сохранением состояния)
Системы сохраняют информацию о сеансах и запросах, что удобно для сложных приложений с длительными взаимодействиями.
Плюсы:
• Сохранение состояния между запросами.
• Упрощенная логика работы.
• Более простое восстановление после сбоев.
Минусы:
• Высокая нагрузка на сервер из-за хранения состояния.
• Сложность изменения состояния.
• Ограниченная отказоустойчивость.

📌 Stateless (без сохранения состояния)
Каждый запрос независим и не зависит от предыдущих. Типичный пример — RESTful веб-сервисы.
Плюсы:
• Отличная масштабируемость.
• Упрощенная разработка и тестирование.
• Высокая отказоустойчивость.
Минусы:
• Сложность работы с сеансами или сложными сценариями.
• Увеличение нагрузки из-за передачи полной информации в каждом запросе.

📌 Что выбрать?
Если вы планируете распределенное и отказоустойчивое приложение - смотрите в сторону stateless-архитектуры. Если же вы создаете MVP, ваше приложение не является критичным с точки зрения простоя, и горизонтальное масштабирование не предполагается - выбирайте stateful-архитектуру. Что касается меня, то мой выбор - stateless по-умолчанию. И только в случае обоснованной необходимости, принимая все потенциальные риски, я выбираю stateful.

🔗 #SYSTEMDESIGN

Добрый день👨‍💻

🌐 Curl: универсальный инструмент для работы с HTTP-запросами

Что такое Curl?
Curl (Client URL) — это мощная утилита командной строки для работы с HTTP-запросами и передачи данных по множеству протоколов. С её помощью вы можете выполнять GET и POST-запросы, загружать файлы, тестировать API и отлаживать веб-приложения.

🛠 Основные возможности Curl

📥 Скачивание файлов
Сохраните JSON-ответ в файл:

curl -o post.json https://jsonplaceholder.typicode.com/posts/1

📋 Получение заголовков HTTP
Проверьте информацию о типе контента и статусе ответа:

curl -I https://jsonplaceholder.typicode.com/posts/1

🔑 Аутентификация
Работа с защищёнными ресурсами:

curl -u username:password https://jsonplaceholder.typicode.com/posts

🔄 Следование редиректам
Позволяет автоматически перенаправлять запросы:

curl -L https://jsonplaceholder.typicode.com/posts/1

📤 Загрузка данных (POST-запрос)
Создайте JSON-файл и отправьте его на сервер:

echo {"title":"Test","body":"Example","userId":1} > newpost.json  
curl -X POST -H "Content-Type: application/json" -d @newpost.json https://jsonplaceholder.typicode.com/posts

🔍 Почему использовать Curl?
Curl выделяется своей универсальностью, поддержкой множества протоколов (HTTP, HTTPS, FTP и других) и простым синтаксисом.

📌 Поделитесь в комментариях, как вы используете Curl в своей работе!

🔗 #OTHER

📂 Системы контроля версий — это программные инструменты, которые позволяют фиксировать изменения в файлах, хранить историю этих изменений и управлять версиями данных. Они незаменимы в командной работе, где важно знать, кто и когда внес правки, возвращаться к нужной версии или откатывать изменения при необходимости.

📂 Основные виды систем контроля версий:
1️⃣ Copy-paste: Самый простой способ — вручную создавать копии файлов с разными названиями, например file_v1, file_v2. Но такой подход неудобен и приводит к ошибкам.
2️⃣ Локальные системы: Первые системы, как RCS, хранили изменения локально. Однако они не подходили для командной работы, так как все данные были на одном устройстве.
3️⃣ Централизованные системы: Например, Subversion (SVN). Все данные хранятся на одном сервере, и команды могут работать вместе. Но если сервер «падает», доступ к проекту теряется.
4️⃣ Распределенные системы: Такие, как Git. Здесь у каждого разработчика есть полная копия проекта. Это обеспечивает надежность — если один компьютер выходит из строя, данные остаются у других участников.

🖥 Почему Git стал лидером?
В 2005 году разработчики Linux создали Git как систему, которая объединяет скорость, децентрализацию и удобство. С тех пор он стал стандартом в IT и используется для работы над проектами любой сложности.

#SYSTEMDESIGN

Клиент всегда прав?

🔗 Что такое вебхук и зачем он нужен?

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

📌 Пример:
🛒 Клиент оформил заказ в интернет-магазине → 🖥 Система отправила вебхук → 📲 Владелец магазина получил уведомление в приложении.

🤔 В чем разница между вебхуком и API?
API: Клиент постоянно запрашивает сервер: «Есть новости?»
Вебхук: Сервер сам отправляет уведомление, когда появятся важные данные.

🛠 Где используются вебхуки?
• GitHub — для уведомлений о новых коммитах.
• CRM и интернет-магазины — для уведомлений о заказах.
• Коллтрекинг — для уведомлений о звонках и заявках.

🔒 Как сделать вебхуки безопасными?
• Использовать HTTPS для шифрования данных.
• Добавлять уникальные токены в URL вебхуков.
• Реализовать аутентификацию для подтверждения отправителя.

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

#INTEGRATION

📌 Нотация C4: как визуализировать архитектуру системы понятным языком

Когда речь заходит о проектировании архитектуры программного обеспечения, важно не только понимать систему, но и уметь наглядно передавать информацию другим. Один из самых удобных способов для этого — C4-нотация, разработанная Саймоном Брауном.

🔹 Что такое C4?
C4 помогает моделировать архитектуру ПО на 4 уровнях:
📌 Context — показывает систему в общем контексте (пользователи, внешние сервисы).
📌 Container — определяет основные компоненты (приложения, базы данных).
📌 Component — детализирует структуру внутри контейнеров.
📌 Code — описывает реализацию на уровне классов и модулей (используется редко).

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

🔹 Примеры использования
📌 На этапе проектирования: для утверждения архитектуры с командой.
📌 При разработке: чтобы упростить взаимодействие между командами.
📌 Во взаимодействии с заказчиком: помогает объяснить структуру проекта простыми схемами.
📌 В документации: делает систему прозрачной для новых сотрудников.

🔹 Как создавать диаграммы C4?
📌 Draw.io — удобный инструмент для графического создания диаграмм.
📌 Structurizr — генерация C4-схем через код, удобно для автоматизации.
📌 Miro, Lucidchart — подойдут для совместной работы с командой.

#ARCHITECTURE

🛠 Postman для тестировщиков: основы и автоматизация

Postman — это удобный инструмент для работы с API, который позволяет тестировщикам 📌 отправлять запросы, проверять ответы, автоматизировать тестирование и интегрировать проверки в CI/CD. Он поддерживает REST, SOAP, GraphQL, работает на всех ОС и позволяет легко управлять переменными и окружениями.

🔍 Основные возможности
✅ Отправка запросов и анализ ответов
✅ Использование коллекций и переменных
✅ Автоматизация тестирования с Collection Runner
✅ Запуск тестов по расписанию ⏳
✅ Интеграция с CI/CD через Newman

📜 Создание тестов
Вкладка Tests позволяет автоматически проверять ответы сервера. Например, проверка статуса ответа:

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

Или проверка содержимого ответа:

pm.test("Response contains campaign name", function () {
    pm.expect(pm.response.text()).to.include("Campaign TEST");
});

🔄 Использование переменных
Переменные помогают передавать данные между запросами 🔗. Например, сохранить auth-токен для последующего использования:

var jsonData = pm.response.json();
pm.environment.set("authToken", jsonData.token);

Также можно передавать ID созданного объекта:

pm.environment.set("campaignID", jsonData.id);

Переменные бывают глобальные, окружения, локальные и из файлов (CSV, JSON) 📂.

🚀 Автоматизация с Collection Runner
📌 Можно запускать коллекции запросов в нужном порядке, задавать количество итераций и запускать тесты по расписанию.