Как работают логирование и мониторинг (стек ELK, Prometheus, Grafana)
(описание в следующем посте)

### Логирование и мониторинг (стек ELK, Prometheus, Grafana)
(продолжение предыдущего поста)

Что такое логирование и мониторинг?

* Логирование фиксирует, что происходило в вашей системе (ошибки, запросы, события).
* Мониторинг отслеживает состояние системы в режиме реального времени (CPU, память, трафик, время безотказной работы).
* Вместе они помогают выявлять проблемы, улучшать производительность и обеспечивать надёжность.

### стек ELK (Elasticsearch, Logstash, Kibana)

* Elasticsearch — эффективное хранение и поиск логов.
* Logstash — сбор, обработка и отправка логов.
* Kibana — визуализация логов на информационных панелях и графиках.
* Пример использования — централизованное управление логами и устранение неполадок.

### Prometheus (Сбор метрик)

* Собирает системные метрики и метрики приложений (использование CPU, память, задержка запросов).
* Хранит данные временных рядов для анализа.
* Отправляет оповещения, когда метрики превышают заданные пороги.

### Grafana (Визуализация и информационные панели)

* Взаимодействует с Prometheus и другими источниками данных.
* Создаёт интерактивные информационные панели для отслеживания производительности системы и тенденций.
* Помогает командам отслеживать время безотказной работы, сбои и использование ресурсов.

### Push- и Pull-мониторинг

Push-мониторинг

* Системы отправляют (push) свои метрики на сервер мониторинга.
* Хорошо подходит для динамичных сред (например, IoT-устройства, мобильные приложения).
* Риск: сервер мониторинга может быть перегружен входящими данными.

Pull-мониторинг

* Сервер мониторинга запрашивает (pull) метрики у систем через определённые интервалы.
* Prometheus следует этой модели — извлекает метрики из конечных точек.
* Преимущества: более простой контроль, предотвращение перегрузки, обеспечение согласованности.
* Ограничение: не идеален для систем, которые не всегда доступны.

### Аналогия

* Логирование — камеры видеонаблюдения, записывающие события в здании.
* Мониторинг — охранники, наблюдающие за экранами в режиме реального времени.
* Push-подход — охранники получают телефонные звонки из каждой комнаты о происходящем.
* Pull-подход — охранники сами обходят каждую комнату для проверки.

Фрилансеры и даже целые компании начали зарабатывать на исправлении ошибок в программном обеспечении, созданном вайб-кодерами. Так, в 404Media обратили внимание на то, что в LinkedIn появились профили «специалистов по очистке вайб-кода».

«Я предлагаю услуги по исправлению вайб-кода уже около двух лет, начиная с конца 2023 года. Сейчас я регулярно работаю примерно с 15-20 клиентами, а также выполняю разовые проекты в течение года», — написал один из таких разработчиков по имени Хамид Сиддики. По его словам, «всё больше разработчиков и небольших команд испытывают трудности с улучшением кода, сгенерированного ИИ, который был функциональным, но не обладал необходимой “отшлифованностью” или “атмосферой”, чтобы соответствовать их видению».
Он рассказал, что распространённые проблемы, которые он исправляет в проектах, включают несогласованный UI/UX-дизайн в интерфейсах, сгенерированных ИИ, плохо оптимизированный код, влияющий на производительность, неровно расположенные элементы брендинга и функции, которые работают, но кажутся неуклюжими или неинтуитивными. Он также поделился, что часто дорабатывает цветовые схемы, анимацию и макеты.

Кроме того, компании по разработке программного обеспечения, например, Ulam Labs. Как говорится на сайте этой компании:
«Создали что-то быстро? Теперь пора сделать это надёжным. Мы знаем, как это бывает. Нужно было действовать быстро, выпустить MVP [минимально жизнеспособный продукт] и проверить идею. Но теперь технический долг сдерживает: отсутствие тестов, шаткая архитектура, CI/CD [непрерывная интеграция и непрерывная поставка/развёртывание] — это просто мечта, а каждое изменение ощущается как обезвреживание бомбы. Вот тут-то и появляемся мы»

Сватантра Сохни, создатель сайта для авторов проектов вайб-кодинга, которым нужна помощь опытных разработчиков, говорит, что почти 300 профессионалов уже разместили свои профили на площадке.
По его мнению, большинство этих вайб-кодеров — либо менеджеры по продукту, либо продавцы, либо владельцы малого бизнеса, и они думают, что могут что-то создать. Однако они могут создать лишь прототипы, а для доведения до ума нужны опытные разработчики
Ещё одна серьёзная проблема, которую обозначил разработчик — это «прожигание кредитов», то есть деньги, которые вайб-кодеры тратят на оплату использования ИИ при добавлении новых функций, нарушающих работу существующих.

https://www.404media.co/the-software-engineers-paid-to-fix-vibe-coded-messes/

Различные архитектурные паттерны:
(описание к предыдущему посту)

1. Client-Server Architecture (Клиент-серверная архитектура)
Эта архитектура основана на взаимодействии между клиентом и сервером. Клиент отправляет запросы, а сервер обрабатывает их и возвращает результаты. Включает компоненты, такие как балансировщик нагрузки, CDN и серверы.

2. Layered Architecture (Многоуровневая архитектура)
Система разделена на уровни:
- Presentation Layer (Уровень представления) — отвечает за взаимодействие с пользователем.
- Business Logic Layer (Уровень бизнес-логики) — обрабатывает логику приложения.
- Data Access Layer (Уровень доступа к данным) — взаимодействует с базами данных.

3. Pipes and Filter (Трубы и фильтры)
Данные проходят через серию фильтров, каждый из которых выполняет определенную операцию. Это позволяет обрабатывать данные поэтапно.

4. Domain Driven Design (Проектирование, управляемое доменом)
Подход, при котором архитектура строится вокруг бизнес-домена. Включает контексты, такие как Catalog Context, Order Context, Fulfillment Context и Billing Context.

5. Monolithic Architecture (Монолитная архитектура)
Все компоненты приложения объединены в единое целое. Это упрощает разработку, но усложняет масштабирование.

6. Microservices Architecture (Микросервисная архитектура)
Приложение разбивается на независимые сервисы, которые взаимодействуют друг с другом. Это повышает гибкость и масштабируемость.

7. Event-Driven Architecture (Архитектура, управляемая событиями)
Компоненты взаимодействуют через события. Производитель создает события, а потребители реагируют на них.

8. Serverless Architecture (Бессерверная архитектура)
Приложения работают на серверах, предоставляемых облачными провайдерами. Разработчики не управляют инфраструктурой.

9. Stream Processing (Обработка потоков)
Потоки данных обрабатываются в реальном времени с использованием таких инструментов, как Lambda и Stream Processing Engine.

Шпаргалка по использованию очередей
(продолжение в следующем посте)

Шпаргалка по использованию очередей
(описание к предыдущему посту)

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

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

Основные определения:
1. Очередь — структура данных или система для хранения задач/сообщений в порядке FIFO (First-In-First-Out — «первым пришёл — первым ушёл»).
2. Производитель — компонент, отправляющий сообщения в очередь.
3. Потребитель — компонент, считывающий и обрабатывающий сообщения из очереди.
4. Брокер — промежуточное ПО, управляющее очередями (например, RabbitMQ, Kafka, SQS).
5. Подтверждение (ACK) — сигнал об успешной обработке сообщения.
6. Очередь недоставленных сообщений (Dead Letter Queue / DLQ) — очередь для неудачных/необрабатываемых сообщений.
7. Идемпотентность — гарантия того, что повторная обработка сообщения не создаст дублирующихся побочных эффектов.
8. Тайм-аут видимости — время, в течение которого сообщение невидимо для других во время обработки.

Лучшие практики и подводные камни:

* Используйте идемпотентных потребителей → предотвращает двойную обработку.
* Определите политики повторных попыток (экспоненциальное отступление, максимальное количество попыток).
* Отслеживайте длину очереди и отставание в обработке как индикаторы работоспособности.
* Используйте очереди недоставленных сообщений для неудачных сообщений.
* Обеспечьте упорядоченность сообщений только в случае бизнес-критичности (упорядочивание увеличивает затраты/сложность).
* Делайте сообщения небольшими и самодостаточными.
* Всегда включайте идентификаторы корреляции для отслеживания.

Рекомендации по производительности:

* Для пропускной способности → параллельные потребители или разделы
* Для надёжности → сохраняйте, если критично (компромисс: скорость)
* Для масштабируемости → автоматическое масштабирование потребителей

Паттерны:

* Рабочая очередь (Work Queue) → распределение задач между работниками
* Pub/Sub → трансляция для множества подписчиков
* Отложенная очередь (Delayed Queue) → повторная попытка позже или планирование задач
* Очередь приоритетов (Priority Queue) → обработка срочных задач в первую очередь

Карта памяти программы в Windows #windows

Развертывание (Docker, Kubernetes, CI/CD)
(продолжение в следующем посте)

Развертывание (Docker, Kubernetes, CI/CD)
(продолжение предыдущего поста)

Что такое развертывание?

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

### Docker (Контейнеризация)

→ Представьте Docker как транспортный контейнер для программного обеспечения.
→ Он упаковывает код, библиотеки и зависимости вместе, чтобы приложение работало одинаково в любой среде.
→ Преимущества: переносимость, изоляция и согласованность между средами (разработка, тестирование, продакшен).

### Kubernetes (Оркестрация)

→ Когда у вас появляется много контейнеров, вам нужен менеджер.
→ Kubernetes — это как портовая администрация, которая направляет, масштабирует и перезапускает контейнеры.
→ Управляет балансировкой нагрузки, масштабированием, поэтапными обновлениями и самовосстановлением контейнеризированных приложений.

### CI/CD (Непрерывная интеграция и непрерывное развертывание)

→ CI — это как проверка каждого продукта перед отправкой с завода: тесты запускаются автоматически при каждом внесении изменений разработчиками.
→ CD — это система доставки: одобренные изменения автоматически отправляются в продакшен.
→ Преимущества: более быстрые релизы, меньше ошибок, более слаженная командная работа.

### Аналогия

→ Docker → Герметичный ящик, содержащий ваши товары.
→ Kubernetes → Логистическая компания, организующая и маршрутизирующая все ящики.
→ CI/CD → Конвейер, который непрерывно отправляет ящики без задержек.

Фактически смерть еще одного отечественного проекта

Юрлицо российского игрового движка Nau Engine, в который VK планировал инвестировать 1 млрд руб., находится в стадии ликвидации. Участники рынка называют шаг логичным, команда проекта уже перешла в контур университета ИТМО, а ответственная за разработку ассоциация говорит, что технология будет развиваться силами профильного сообщества. Но пока движок не нашел его поддержки, говорят разработчики, и рынок использует зарубежные решения Unity и Unreal Engine.

Как заявляется, развитие движка продолжится сообществом при поддержке АПРИОРИ и техническом сопровождении ИТМО.

Финансирование проекта, согласно плану, должно было происходить за счет продаж лицензий на его коммерческую версию, в том числе по подписке. Официально VK сообщил о начале работы над игровым движком только в 2023 году, в его разработку планировалось вложить1 млрд руб. и сформировать профильную команду.

https://www.kommersant.ru/doc/8039708

API Rate Limiting & Throttling (Ограничение и регулирование частоты запросов API)
(продолжение в следующем посте)

API Rate Limiting & Throttling (Ограничение и регулирование частоты запросов API)
(продолжение предыдущего поста)

### Что такое API Rate Limiting?

API Rate Limiting — это процесс контроля количества запросов, которые клиент может отправить к API в течение определённого промежутка времени. Это помогает защитить API от злоупотреблений, обеспечивает справедливое использование и предотвращает перегрузку сервера.

→ Пример: разрешение только 100 запросов на пользователя в минуту.

### Почему важно ограничение частоты запросов

→ Предотвращает атаки типа «отказ в обслуживании» (DoS-атаки).
→ Защищает ресурсы сервера.
→ Обеспечивает справедливый доступ для всех пользователей.
→ Улучшает стабильность и производительность API.

### Что такое API Throttling?

API Throttling (Регулирование частоты) — это процесс контроля потока запросов путём их замедления или постановки в очередь, когда частота превышает допустимый предел. В отличие от строгого ограничения частоты, регулирование допускает дополнительные запросы, но обрабатывает их более плавно.

→ Пример: после достижения 100 запросов в минуту дополнительные запросы задерживаются, а не блокируются полностью.

### Почему важно регулирование частоты

→ Предотвращает резкие скачки трафика.
→ Обеспечивает стабильную работу системы.
→ Помогает сбалансировать нагрузку между серверами.

### Rate Limiting vs Throttling

→ Rate Limiting: устанавливает максимальное количество запросов; запросы сверх лимита отклоняются.
→ Throttling: контролирует скорость запросов; избыточные запросы могут быть задержаны или поставлены в очередь.

### Распространённые методы

→ Token Bucket: запросы разрешаются, если доступны токены; токены восполняются с течением времени.
→ Leaky Bucket: запросы обрабатываются с фиксированной скоростью, избыточные запросы отбрасываются или ставятся в очередь.
→ Fixed Window (Фиксированное окно): ограничивает запросы в фиксированный промежуток времени (например, 1 минута).
→ Sliding Window (Скользящее окно): ограничивает запросы в подвижном временном интервале для более плавного контроля.

Load Balancing и Reverse Proxy (Балансировка нагрузки и обратный прокси-сервер)
(продолжение в следующем посте)

Load Balancing и Reverse Proxy (Балансировка нагрузки и обратный прокси-сервер)
(продолжение предыдущего поста)

→ Что такое Load Balancing (балансировка нагрузки)?
Представьте загруженный ресторан с несколькими поварами на кухне. Вместо того чтобы перегружать одного повара всеми заказами, менеджер ресторана (балансировщик нагрузки) равномерно распределяет заказы между всеми поварами. Это гарантирует, что ни один повар не будет перегружен, а клиенты получат свои блюда быстрее.

→ Зачем нужна балансировка нагрузки?

✓ Предотвращает перегрузку любого отдельного сервера
✓ Улучшает производительность приложений
✓ Повышает надёжность и время бесперебойной работы
✓ Обеспечивает масштабируемость при росте трафика

→ Типы балансировки нагрузки

✓ Круговая система (Round Robin) → Каждый сервер получает запросы по очереди, как при раздаче карт за покерным столом.

✓ Наименьшее количество соединений (Least Connections) → Новые запросы направляются на сервер с наименьшим количеством активных запросов, подобно выбору самой короткой очереди в супермаркете.

✓ IP-хеш (IP Hash) → IP-адрес клиента определяет, к какому серверу он подключается, как если бы клиентов распределяли по постоянным столикам.

Что такое обратный прокси-сервер?

→ Обратный прокси-сервер располагается перед серверами и направляет клиентские запросы к ним. Представьте администратора в офисе, который направляет посетителей к нужному сотруднику, не позволяя им свободно перемещаться.

→ Преимущества обратного прокси-сервера

* Безопасность → Скрывает внутренние серверы от прямого доступа
* Терминация SSL → Обрабатывает шифрование и дешифрование, освобождая серверы от этой задачи
* Кэширование → Сохраняет часто запрашиваемые ответы для более быстрой доставки
* Централизованная аутентификация → Управляет контролем доступа до того, как запросы попадут на серверы

Балансировка нагрузки против обратного прокси-сервера

→ Балансировщик нагрузки → Сосредоточен на равномерном распределении запросов между серверами (справедливое распределение).

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

Современные инструменты (такие как Nginx, HAProxy, AWS ELB) часто объединяют обе функции.

Как центральный процессор отрисовывает каждый пиксель (на примере визуального симулятора RISC-V), когда мы записываем в буфер кадра один пиксель

Согласованность «читай-то-что-записал» (read-your-writes)
(продолжение в следующем посте)