Шпаргалка по LVM (Logical Volume Manager)
(продолжение предыдущего поста)

LVM (Logical Volume Manager) в Linux позволяет гибко управлять дисковым пространством, добавлять или удалять диски, изменять размеры томов и обеспечивать резервное копирование данных. Ее основные элементы:

- **Файловая система: Это верхний уровень структуры, где размещаются данные. Примеры файловых систем включают /home, / и /mnt/backups. Эти файловые системы форматируются в определённый тип (например, ext4, xfs) и монтируются в соответствующих точках.

- Логические тома: Это абстрактные блоки хранения, которые создаются внутри групп томов. Примеры логических томов включают lv_home, lv_root и lv_backups. Они могут быть увеличены или уменьшены в размере без остановки системы.

- Группы томов: Объединяют физические тома в единое пространство хранения. Примеры групп томов: vg_system и vg_others. Группа томов позволяет гибко управлять дисковым пространством.

- Физические тома: Это разделы или целые диски, которые используются для создания логических томов. Примеры физических томов: /dev/vda1, /dev/vda2, /dev/vda3, /dev/vda4 и /dev/vda5. Они могут быть объединены в группы томов для создания единого пространства хранения.

- Разделы: Это физические разделы на дисках, которые используются для создания физических томов. Примеры разделов: /dev/vda1 и /dev/vda2.

- Диски: Это физические устройства хранения данных, такие как жёсткие диски или SSD. На изображении показаны четыре диска, которые могут быть использованы для создания физических томов.
#linux

Python vs Java. Запуск и выполнение программы

Как работают логирование и мониторинг (стек 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 (Балансировка нагрузки и обратный прокси-сервер)
(продолжение в следующем посте)