Список документов

# 2025-07-11 Лекция №4 CEP(ETL) Обычная встреча #### Супер краткое содержание: * Рассмотрены два подхода к хранению данных: база данных (SQL) и очередь сообщений (Kafka), с их преимуществами и недостатками. * Обсуждены механизмы уведомлений и синхронизации изменений в базе данных через Notify и таблицу Outbox, а также альтернатива Debezium. * Подробно описана архитектура Kafka: топики, партиции, продюсеры, потребители и группы потребителей, включая особенности перебалансировки. * Рассмотрены проблемы изменения количества партиций и влияния на распределение сообщений и потребителей. * Описаны сценарии восстановления данных из событий с использованием материализации и нумерации запросов для упорядочивания. * Представлены практические задания по реализации request-response через очереди, мультиплексированию и работе с Kafka и Redis через Docker. * Даны рекомендации по использованию TaskCompletionSource для асинхронного ожидания обработки запросов. * Обсуждены планы на дальнейшие задания с использованием технологий 11Labs, OpenAI и FFmpeg для медийной обработки. * Подчеркнута важность понимания архитектуры событийных систем и управления состоянием для разработки надежных реактивных систем. #### Саммари по темам: ## Обсуждение подходов к хранению и обработке данных в системах с использованием баз данных и очередей сообщений. * Определение первоисточника данных: база данных (SQL) или очередь (Kafka). * Преимущества базы данных: транзакции, поддержка целостности, возможность сложных запросов. * Недостатки базы данных: высокая задержка реакции, сложность обмена событиями. * Преимущества очередей: высокая скорость записи, поддержка нескольких потребителей, низкая задержка реакции. * Недостатки очередей: отсутствие реляционной модели, сложности с миграцией и отсутствием целостного состояния. ## Механизмы синхронизации и уведомлений при использовании базы данных как первоисточника. * Использование механизма Notify в PostgreSQL для уведомлений, но он ненадежен и может терять сообщения. * Внедрение таблицы Outbox (ChangeLog) для фиксации изменений и последующего опроса Notification Center. * Проблемы с ростом и очисткой Outbox, необходимость поддержки и миграции. * Альтернатива — использование Debezium для захвата изменений и отправки их в Kafka, но чувствителен к миграциям. ## Особенности работы с Kafka как системой очередей и массового обслуживания. * Kafka организует данные в топики, содержащие партиции (очереди). * Продюсер добавляет сообщения в партиции, выбор партиции зависит от ключа и хэш-функции. * Потребители (consumers) объединены в группы, каждая партиция обрабатывается одним потребителем в группе. * Перебалансировка групп потребителей при изменении числа участников вызывает задержки (\~10 секунд). * Kafka поддерживает режимы динамического и надежного закрепления партиций за потребителями. * Kafka использует long polling для передачи данных и поддерживает пакетную передачу сообщений. ## Проблемы и решения при изменении количества партиций и обработке ключей в Kafka. * Изменение количества партиций может привести к изменению назначения ключей и перераспределению сообщений. * Перебалансировка групп потребителей перераспределяет партиции между участниками, что требует контроля. * Решения включают создание нового топика с нужным количеством партиций и плавный переход. * Необходимо учитывать задержки и возможные проблемы при перебалансировке. ## Сценарии восстановления данных и материализация состояния из событий. * При падении базы данных возможен полный перезапуск и восстановление состояния из журнала событий (materialization). * События неизменны и хранятся постоянно, что позволяет восстановить состояние за время от нескольких минут до часа. * Пессимистичный сценарий: восстановление с нарушением порядка событий, что требует нумерации запросов для упорядочивания. * Использование Redis для нумерации запросов и последовательной обработки при восстановлении. * Возможность асинхронной обработки запросов с получением номера заявки и последующим опросом статуса. ## Практические задания и рекомендации по работе с Kafka и Redis. * Реализация сценария request-response через очереди с использованием ASP.NET сервера. * Использование TaskCompletionSource для ожидания обработки запросов без блокировки процессора. * Реализация мультиплексирования потоков с объединением результатов из нескольких обработчиков. * Поднятие Kafka и Redis через Docker Compose, создание топиков и тестирование сообщений. * Подготовка к следующему заданию с использованием 11Labs, OpenAI и FFmpeg для медийной обработки. #### Выделенные задачи: * Реализовать разделение событий на зоны для синхронизации и обработки * Настроить механизм Outbox в базе данных для захвата изменений и организации уведомлений * Организовать опрос таблицы Outbox и интеграцию с Notification Center для отправки SMS и email уведомлений * Разработать логику очистки и обслуживания таблицы Outbox для предотвращения роста и проблем с миграцией * Исследовать и внедрить использование Debezium для захвата изменений из базы данных и отправки их в Kafka с учетом миграций * Настроить обработку запросов создания и остановки голосований через очередь Kafka с двумя обработчиками (Redis и PostgreSQL) * Обеспечить корректное распределение партиций и управление курсорами в группах потребителей Kafka для гарантированного порядка обработки данных * Разработать и внедрить механизм контроля и фиксации ключей сообщений для обеспечения стабильного маршрута сообщений в партициях Kafka * Организовать процесс контролируемого увеличения количества партиций и перехода на новые топики с минимальными потерями данных и простоем * Реализовать очередь уведомлений (notifications) для подтверждения выполнения REST-запросов и синхронизации операций записи голосов * Обеспечить механизм нумерации запросов для отслеживания статуса выполнения и поддержки асинхронной обработки операций через REST API * Провести анализ и настройку параметров Kafka и групп консюмеров для минимизации перебалансировок и обеспечения гарантированной обработки сообщений одним потребителем * Реализовать сценарий request-response через очереди с очередью входящих запросов, обработчиками и очередью ответов, включая обработку отказов и использование TaskCompletionSource для неблокирующего ожидания * Поднять ASP.NET сервер и самостоятельно реализовать схему request-response через очереди с выделением участков обработки и имитацией отказов * Смоделировать мультиплексирование (mux) обработки запросов с разделением работы на несколько очередей и объединением результатов с учетом рандомизированного времени выполнения и сохранением состояния для правильного порядка выдачи ответа * Научиться поднимать Kafka и Redis через Docker, создавать топики Kafka из консоли и работать с ними * Подготовить и выдать два ключа к заданию для работы с 11Labs и OpenAI Изучить возможности озвучки текста с использованием OpenAI и обсудить интеграцию с базой данных * Изучить базовые команды FFmpeg для работы с консолью и подготовиться к созданию медийной системы с событийной трансформацией данных * Подготовиться к обсуждению Kafka метаданных и более сложного задания по работе с событиями и CQRS * Решить задачи по реализации request-response и secure-rest блоков, а также подготовить ожидающие таблицы для заданий

**Супер краткое содержание**: - Представлены три подхода к обработке данных: ETL, ELT и Complex Event Processing, с акцентом на преимущества последних для сохранения данных и низкой задержки. - Описаны свойства событий как неизменяемых и строго упорядоченных по времени единиц информации, влияющих на состояние системы. - Рассмотрены операции над потоками событий: задержка, фильтрация, объединение, позволяющие создавать сложные и быстрые системы обработки. - Модель событийных систем применена для балансировки распределения работы между двумя рабочими с использованием очередей и операции ZIP. - Подчеркнута модульность и простота программирования таких систем на разных языках с применением TDD. - Предложено домашнее задание по реализации и тестированию системы балансировки с использованием описанных принципов. - Обсуждены компромиссы между скоростью обработки и консистентностью данных в современных системах. - Показано, как события формируют состояние баз данных и позволяют моделировать сложные бизнес-процессы. - Отмечена возможность масштабирования и расширения систем за счет композиции простых блоков и потоков событий. **Саммари по темам**: ## Обзор систем обработки данных ETL и ELT, их отличия и эволюция к системам сложной обработки событий (Complex Event Processing). - ETL (Extract, Transform, Load) — устаревший подход, где данные сразу преобразуются после извлечения и загружаются в базу. - ELT (Extract, Load, Transform) — современный подход, где сырые данные сначала загружаются в базу, а преобразование происходит внутри базы, что сохраняет исходные данные для будущего анализа и машинного обучения. - Переход к ELT обусловлен необходимостью сохранять полные данные для извлечения закономерностей и использования ML-моделей. - Появление озер данных (data lakes) для хранения больших объемов сырых данных. - Важность низкой задержки (low latency) в системах обработки данных и отказ от строгой консистентности в пользу временной согласованности (Time Consistency). ## Концепция событий (Event) и их свойства в системах обработки событий. - Событие — неизменяемая порция информации, произошедшая в конкретный момент времени. - События строго упорядочены по времени, что позволяет моделировать изменения состояния системы. - Изменение состояния системы происходит через последовательную обработку событий. - Пример с подсчетом лайков и дизлайков как изменение состояния системы. - Таблицы в базах данных формируются через последовательные события добавления, удаления и изменения записей. ## Операции и обработка потоков событий в Complex Event Processing. - Потоки событий могут подвергаться различным операциям: задержка (delay), фильтрация (filter/select), объединение (combine/zip). - Обработка потоков событий позволяет создавать сложные схемы и быстро отдавать данные пользователям. - Пример объединения потоков счетов и платежей с обеспечением временной согласованности. - Потоковые системы жертвуют консистентностью ради скорости и масштабируемости. ## Модель событийных систем и их применение для балансировки распределения работы. - Использование очередей событий (event queues) для фиксации и упорядочивания событий. - Модель с двумя рабочими и потоком работы, где рабочие сообщают о своей готовности, а система распределяет задачи через операцию ZIP. - ZIP объединяет события о готовности рабочих и заданиях, формируя пары для выполнения работы. - Фильтрация и распределение работы по очередям для каждого рабочего. - Балансировка гарантирует, что рабочие не перегружены, а система контролирует поток данных. ## Практическая реализация и программирование событийных систем. - Системы строятся из простых блоков (ZIP, фильтр, рабочие), каждый из которых имеет входящие (upstream) и исходящие (downstream) потоки. - Реализация возможна на любых языках программирования, включая C# и frontend-технологии. - Рекомендуется использовать TDD (Test-Driven Development) для разработки и тестирования каждого блока. - Интерфейсы блоков описывают входные и выходные очереди, а тесты покрывают ключевые сценарии. - Композиция блоков позволяет собирать сложные системы из простых компонентов. - Пример домашнего задания — реализовать систему балансировки с использованием очередей и операций ZIP и фильтрации. **Задачи:** - Смоделировать систему балансировки работы с использованием очередей событий и операции zip на любом удобном языке программирования - Реализовать систему с пятью очередями: исходных заявок, заявок 'я свободен', назначенных рабочих на задачи, работы к выполнению для первого и второго рабочих, а также очереди работы и результатов для каждого рабочего - Создать обработчик zip, который читает данные из очередей заявок и работы, объединяет их и помещает в очередь назначенных рабочих - Разработать фильтр, который распределяет назначенную работу между двумя рабочими, помещая данные в соответствующие очереди работы - Организовать обработчики для каждого рабочего, которые читают работу из очереди, выполняют её (например, имитируя работу с задержкой), и после выполнения помещают событие 'я свободен' обратно в очередь - Сгенерировать описание интерфейсов для потоковой системы с четырьмя участками (zip, фильтр, рабочие), включая описание входящих и исходящих очередей - Реализовать каждый из участков системы (zip, фильтр, рабочие) на основе описанных интерфейсов - Подготовить тесты для каждого участка системы с использованием tdd, покрывающие ключевые и граничные случаи (10-20 тестов) с использованием xunit или jest - Собрать и скомпоновать все четыре реализации участков в одну большую потоковую систему, проверить работоспособность и время выполнения

**Супер краткое содержание**: - Реализована event-driven система обработки задач с использованием ограниченных очередей и асинхронных каналов в C#. - Введены интерфейсы и опции для гибкой композиции и тестирования компонентов системы. - Обсуждены механизмы работы с очередями: синхронное и асинхронное чтение/запись, ожидание освобождения места и появления данных. - Представлена модель приоритетных очередей с учетом времени обработки и дедлайна для оптимизации качества обслуживания. - Рассмотрены сценарии ограничения количества одновременно обрабатываемых задач для предотвращения перегрузок. - Выделены типы отказов и предложены fallback стратегии для обеспечения устойчивости системы. - Добавлено логирование с форматированным выводом для мониторинга процессов. - Созданы абстрактные xUnit тесты для проверки интерфейсов и реализации компонентов. - Планируется дальнейшее развитие системы с акцентом на обработку отказов и оптимизацию потоков. **Саммари по темам**: ## Обзор и реализация системы обработки задач с использованием очередей и каналов в C# - Создана система с потоками заявок, каналами обслуживания и блоком распределения работы, где работа назначается первому освободившемуся исполнителю. - Реализованы интерфейсы JobChannel, JobPlant, JobProcessor с использованием async/await и передачей зависимостей через options. - Исполнители уведомляют о своей готовности через очередь, работа маршрутизируется на конкретного исполнителя. - Введена концепция контролируемого вайб-кодинга для безопасной работы с кодом и модификации по частям. - Реализованы ограниченные очереди с capacity 100 и 3 исполнителями, запущены асинхронные задачи для чтения и записи данных. - Добавлено логирование через Vector с использованием MarkupLine для форматированного вывода. - Созданы абстрактные xUnit тесты для интерфейсов с возможностью подмены реализации для тестирования. - Введена стратегия делегирования чтения через options для улучшения тестируемости и гибкости. - Обсуждена композиция и запуск основных блоков системы: supply area, planning area, production area, delivery area. ## Механизмы работы с очередями и приоритетами задач - Очереди реализованы по принципу FIFO с поддержкой синхронного и асинхронного чтения и записи. - Описаны операции read-sync, read-async, write-sync, write-async с ожиданием освобождения места или появления данных. - Рассмотрены wait-to-read и wait-to-write операции для управления ожиданием в очередях. - Объяснены модели "толкай" (push) и "выталкивай" (pop) для взаимодействия с очередями. - Введена концепция упорядоченных и приоритетных очередей с буферизацией и сортировкой задач по сложности и дедлайну. - Приведен пример влияния порядка обработки задач на время ожидания и качество обслуживания (QoS). - Обсуждены индексы приоритета, учитывающие время обработки и дедлайн, с возможностью комбинирования для оптимизации очереди. - Рассмотрены сценарии с ограничением количества одновременно обрабатываемых задач (пул) для предотвращения перегрузки системы. ## Обработка отказов и fallback механизмы в системах с очередями - Выделены типы отказов: отказ очереди (нельзя поставить задачу в очередь) и отказ обслуживания (ошибка при выполнении задачи). - Обсуждены действия при отказах: перекладывание задач в очередь на разбор, хранение в базе данных или утилизация. - Приведен пример с невозможностью удаления файла из-за удержания системой, с предложением отложенной очистки при следующем запуске. - Отмечена важность учета отказов для устойчивости системы и предотвращения потерь данных. - Планируется дальнейшее обсуждение обработки отказов, мультиплексирования и демультиплексирования потоков на следующем занятии. **Задачи:** - Разработать систему обработки очереди заявок с блоками распределения, назначения, маршрутизации, выполнения и выпуска работы с учетом фиксированного количества исполняемых блоков и возможности отмены участков - Придумать план реализации и показать интерфейсы одним кодовым сегментом с учетом требований: зеркалирование строки, upper case, задержка выполнения от 1 до 5 секунд - Реализовать остальные части системы и сделать композицию для main - Переписать логику назначения работы на исполнителей, чтобы у каждого была своя очередь и назначалась только его работа через job assignment - Добавить логирование через vector с использованием markupline и escape - Создать новый проект с юнит-тестами на xunit и реализовать абстрактный тест интерфейса с покрытием edge cases, используя фабричный метод - Переписать тест интерфейса, убрать дисплейные элементы и реализовать стратегию чтения через прокидывание в options - Сделать xunit тест интерфейса supply area по аналогии с фабричным методом - Реализовать делегат для асинхронного чтения (readline async delegate) в supply area options и протестировать его - Смоделировать систему с приоритетом задач с двойным индексом: оценка времени обработки и дедлайн, реализовать сортировку и приоритизацию задач в очереди (**deadline:** Через 2 дня) - Реализовать потоковую систему с приоритетом, учитывающую время постановки в очередь, время обработки и время вывода, построить гистограммы распределения времени в excel (**deadline:** Через 2 дня) - Разработать механизм обработки отказов очереди и отказов обслуживания с логикой переноса задач в очередь на разбор или утилизацию - Реализовать систему ограничения количества одновременно обрабатываемых заявок (пул) с контролем возврата заявок в пул

**Супер краткое содержание**: - Реализована и протестирована система очередей с приоритетами, буфером и двумя типами задач с разной длительностью обработки. - Введена архитектура с тремя очередями и двумя параллельными каналами обслуживания, обеспечивающая эффективное распределение задач. - Разработана модель синхронизации данных между фронтендом и бэкендом через событийный ChangeLog и систему снимков для согласования состояний. - Обеспечена возможность масштабирования и замены графических движков без изменения логики обработки. - Проведен анализ производительности системы с учётом лагов, долгов и SLA, реализована система клапанов для управления нагрузкой. - Рассмотрены методы прогнозирования нагрузки и динамического масштабирования ресурсов с использованием Kubernetes. - Задано домашнее задание по реализации событийной системы изменений с синхронизацией структуры папок. - Подчеркнута важность точного логирования, уникального именования и мониторинга для отладки и контроля работы системы. - Обсуждены практические аспекты работы с потоками данных, очередями и системами синхронизации в распределённых приложениях. **Саммари по темам**: ## Разработка и тестирование системы очередей с приоритетами и буфером - Успешно реализована очередь с приоритетами, тестирование продолжается. - Используется модель с двумя типами задач: быстрые (синие, 1 секунда) и медленные (красные, 10 секунд). - Введён буфер ограниченного размера (например, 100 элементов) между входящей очередью и обработчиками. - Задачи ранжируются по приоритету с учётом времени пребывания в буфере (максимум 5 секунд) и типа задачи. - Реализованы три очереди: входящая (Qin), очередь задач к выполнению (Qtudu) и очередь результатов (Qres). - Два канала обслуживания обрабатывают задачи параллельно, имитируя задержки в зависимости от типа задачи. - Вся система построена на каналах с интерфейсами ChannelReader и ChannelWriter для синхронной и асинхронной работы. - Введена система логирования и уникального именования участков и каналов для удобства отладки и мониторинга. - Реализован расчёт рейтинга задач через отдельную функцию, учитывающую время ожидания и тип задачи. - Введён сбор статистики по времени обработки заявок, включая 90-й перцентиль и среднее время. - Поток заявок моделируется с вероятностью 10% красных и 90% синих, с возможностью изменения параметров нагрузки. ## Синхронизация и взаимодействие систем через событийные очереди и ChangeLog - Рассмотрена модель синхронизации данных между фронтендом и бэкендом через очередь событий. - Данные предметной области представлены в виде таблиц узлов (Nodes) и связей (Edges) с операциями добавления, удаления и обновления. - Изменения в таблицах транслируются в виде событий с типом и параметрами, формируя ChangeLog. - Обработчики событий создают и обновляют визуальные элементы в графическом движке PixiJS, обеспечивая согласованное отображение. - Поддерживается возможность замены движка (например, на 3GS) без изменения логики обработки событий. - Реализована система согласования состояний между клиентом и сервером с учётом конфликтных изменений и версионности событий. - Введена система снимков (Snapshot) для ускорения синхронизации новых клиентов и восстановления после рассинхронизации. - ChangeLog обеспечивает непрерывность и упорядоченность событий, предотвращая пропуски и рассинхронизацию. - Обсуждена архитектура с несколькими обработчиками событий, работающими параллельно и независимо. ## Анализ производительности и управление нагрузкой в системе очередей - Обсуждены характеристики входящего потока заявок, включая интенсивность и распределение времени между заявками. - Рассмотрена модель каналов обслуживания с разной скоростью обработки задач и случайным распределением времени обработки. - Выявлен эффект пробок и гусениц, когда задачи накапливаются и обрабатываются с задержками. - Введены метрики лагов (latency) и долгов (backlog) для оценки текущего состояния системы. - Рассчитаны показатели SLA (соглашение об уровне обслуживания) с порогами отказа при превышении задержек (например, 30 секунд). - Реализована система клапанов (valves) для управления приёмом заявок при перегрузках с разными порогами включения и отключения (например, включение при снижении задержки до 15 секунд). - Обсуждены методы прогнозирования нагрузки с использованием статистики, регрессий и нейронных сетей. - Рассмотрены подходы к масштабированию каналов обслуживания с помощью Kubernetes и динамического распределения ресурсов. - Подчёркнута важность информирования пользователей о перегрузках и отказах в обслуживании. ## Домашнее задание по реализации системы событийных изменений и синхронизации - Задана задача реализации системы с одной таблицей, содержащей записи с булевым флагом и строкой. - Изменения (добавление, удаление, изменение) должны транслироваться через ChangeLog в очередь. - Обработчик должен создавать папки и файлы в зависимости от состояния булевого флага (true – подпапка с readme.txt, false – файл readme в корне). - Система должна обеспечивать событийную синхронизацию структуры папок с изменениями в таблице. - Ожидается демонстрация работы консольного приложения с реализованной логикой. - Задача направлена на закрепление принципов работы с очередями, ChangeLog и синхронизацией данных. **Задачи:** - Реализовать систему очередей с приоритетами, включая три очереди (входящих заявок, работы к выполнению, результатов) и два канала обслуживания с имитацией времени обработки (красные задачи 10 сек, синие 1 сек), с ограничением буфера до 100 элементов и временем максимального пребывания заявки в буфере 5 секунд - Сделать маркировку каждой заявки временем постановки в очередь с использованием stopwatch или timestamp, обеспечить неизменяемость параметров заявок (immutable), реализовать уникальное именование url для участков очередей и каналов обслуживания - Реализовать интерфейсы для всех каналов обработки с использованием runasync для передачи зависимостей и параметров, обеспечить вывод логов с информацией о начале, процессе и завершении обработки заявок - Переписать логику обработки очереди с вытягивания на логику с выталкиванием: сначала проверять возможность выталкивания заявки в буфер, затем подкачивать буфер и ранжировать заявки, вынести расчет индекса рейтинга в отдельную функцию - Добавить в dto jobtodo поля origin и временные метки попадания и выхода из буфера, объединить весь код в один файл для удобства проверки и отладки - Создать генератор работы с фиксированной интенсивностью (например, 100 заявок в минуту) с вероятностью 10% красных и 90% синих задач, реализовать запись в output с логированием действий - Обеспечить вывод в консоль информации о прохождении работы через участки с использованием библиотеки pector (консольное приложение) и цветового оформления (spectrum), контролировать размер кода (не превышать 400 строк) - Вынести расчет best index в отдельную функцию с детальными комментариями для удобства валидации - Переделать участок кода с readall на использование readasync для оптимизации чтения - Реализовать буфер накопления до 10к заявок для расчета статистики и перцентилей времени обработки - Переписать подсчет total lag, сделать явное хранение массива и расчет статистики из него - Добавить вывод статистики sla: среднее время обработки, 90% перцентиль, количество обработанных заявок с цветовой маркировкой (cyan вместо grey) - Настроить параметры нагрузки: уменьшить поток до 30 работ в минуту с вероятностью красных 10%, затем увеличить до 240 запросов в секунду с вероятностью красных 2-8% - Изменить время обработки синей работы с 1 секунды на 5 миллисекунд для проведения чистого исследования нагрузки - Проанализировать влияние красных заявок на блокировку каналов и время ожидания, визуализировать состояние обработки заявок по цветам - Реализовать систему с таблицами узлов и ребер с операциями добавления, удаления и обновления (позиция, payload) - Создать процессор событий для последовательной обработки изменений и синхронизации визуального редактора с данными - Обеспечить сохранение всех событий без пропусков в change log и реализовать механизм восстановления при рассинхронизации (desync) - Разработать механизм создания и обновления снимков (snapshots) состояния системы для синхронизации новых клиентов и восстановления после потери связи - Организовать очередь изменений от нескольких пользователей с упорядочиванием и обработкой на сервере, включая трансляцию изменений клиентам - Обеспечить согласование серверного состояния с локальным состоянием клиента, включая обработку конфликтных изменений и маркировку версий - Подготовить домашнее задание по использованию 3d-движков и интеграции с системой изменений - Реализовать систему внесения изменений (add, remove, change) в словарь через api с записью в changelog и синхронизацией структуры папок согласно состоянию булевых флагов - Подготовить и показать консольное приложение, демонстрирующее работу реализованной системы изменений и синхронизации - Проанализировать и визуализировать статистику работы очередей и каналов обслуживания: построить гистограммы, графики lag, latency, количества элементов в очереди, используя выгрузку данных в excel - Разработать и внедрить систему контроля sla с порогами отказа в приеме заявок при превышении задержки обработки (30 секунд) и повторного включения при снижении задержки до 15 секунд (клапан-валв система) - Обеспечить информирование внешних пользователей о перегрузке системы и отказе в обслуживании с рекомендацией повторить попытку позже - Исследовать и применить методы прогнозирования нагрузки и задержек (линейная и нелинейная регрессия, авторегрессионные модели, нейронные сети) для управления клапанами и масштабированием системы - Настроить автоматическое масштабирование сервисов и каналов обслуживания на серверном уровне (например, kubernetes) с учетом метрик нагрузки и сигналов для увеличения или уменьшения ресурсов - Подготовить систему к маршрутизации трафика и аренде вычислительных мощностей для защиты и устойчивости при dos-атаках и пиковых нагрузках - Изучить принципы работы с kafka и научиться рисовать соответствующие схемы - Спроектировать системы с состояниями, таблицами, очередями и каналами обслуживания, а также подготовить статистику по четырём показателям (расхождение между номерами, объемом работ, задержка, время поступления заявок) - Передать разработанные схемы олегу паснову для моделирования в labview и получения рекомендаций по индексам без программирования

# **🚩 Шаблон сценария выступления на МегаДемо** ### 🎯 Цель выступления: Представить ключевые результаты работы команды за прошедший период, подчеркнуть бизнес-ценность и значимость проделанной работы, продемонстрировать продукт. **Продолжительность:** максимум 15 минут **Участники:** Определяются командой самостоятельно. --- ## **⏱ Структура выступления (тайминг):** ### 1️⃣ Введение (1 минута) * Короткое представление команды и проекта. * Четкое описание основной бизнес-ценности продукта. «Здравствуйте\! Мы команда \[название\]. Представляем вам \[название проекта\], который помогает/предназначен \[основная бизнес-ценность продукта\].» --- ### 2️⃣ Ключевые достижения за квартал (2 минуты) * Перечислите 3–5 важнейших задач или целей, достигнутых командой. **Краткие и убедительные формулировки:** * Используют конкретные цифры и измеримые результаты. * Показывают разницу "до → после". * Отражают явную пользу для бизнеса или пользователей. Пример: «Разработали функционал, отмодерировали ХХ колво поставленных кадров, выявили ХХ кол-во дефектов, улучшили показатели метрик системы на ХХ%, обучили ХХ колво сотрудников и тд». --- ### 3️⃣ Демонстрация продукта (8–10 минут) **Чёткий сценарий включает следующие шаги:** * Вступление: кратко обозначить, что сейчас будет показано. * Демонстрация реализованного функционала, с уклоном на новые функции. * Подчеркнуть, как это решает конкретные задачи пользователей. * Продемонстрировать достигнутые улучшения с визуализацией (при необходимости). --- ### 4️⃣ Краткий взгляд в будущее (1 минута) * Обозначение основных задач на следующий этап разработки. Пример: «Следующие шаги/этапы – интеграция новых сервисов и дальнейшее повышение производительности системы». --- ### 🏁 Заключение (30 секунд) * Поблагодарите за внимание. --- ## **🎙 Рекомендации по подготовке и выступлению:** * Выберите пару успешных тест-кейсов, отрепетируйте заранее всей командой. * Не обновляйте релиз продукта за час до демо, лучше делать это накануне презентации. * Не перегружайте вашу речь техническими деталями, концентрируйтесь на бизнес-ценности. * В презентации используйте минималистичные и ясные слайды 5-6 шт, с минимальным набором текста, изображений текст добавьте в описание к слайду и зачитывайте оттуда. [Гайд](https://presium.pro/blog/30-rules-and-secrets-of-a-successful-presentation?ysclid=mcyxr5vvr4408129976) по подгтовке презентаций