Архитектура высоконагруженных систем

ДЗ 5. Скилл выявления НФТ и журналы Boardy, закрывающие НФТ

Срок: 11.11.2026, 14:00 (Екатеринбург) · Сдача: Pull request lab5 → main, в описании Closes #<номер задачи>

Цель

Две части:

1. Скилл. Превратить методику лекции 5 в скилл для нейросети, прогнать его по ТЗ Boardy и получить итоговый перечень НФТ с проверками.
2. Практика 5. Довести до работы у себя шесть шагов практики 5: журналы Boardy закрывают НФТ, и каждое требование закрыто, когда его проверка прошла.

Перед началом

• git checkout main && git pull → git checkout -b lab5.
• Методичка «Выявление НФТ» — в lab/lab5/.
• ДЗ 4 должно работать: журналы всех сервисов пишутся в ./logs/<сервис>.

Часть 1. Скилл

1. Скилл. Опишите процедуру методички как скилл для любой нейросети на ваш выбор: один файл или несколько .md — шаги, справочники, формулы, формат вывода. Если работали в браузере, файлы скилла всё равно положите в репозиторий. Проверка: файлы в lab/lab5/skill/.
2. Прогон по Boardy. На вход — ТЗ Boardy, на выходе — НФТ ко всей системе и к функциям, по формуле требования, с нумерацией по ТЗ и проверкой у каждого. Проверка: lab/lab5/nft.md.
3. Доработка. Сверьте результат с методичкой: что скилл пропустил, что придумал лишнего. Исправьте скилл и прогоните ещё раз. Проверка: каждая доработка — отдельный коммит с описанием «что было не так → что поправил».

Часть 2. Практика 5: журналы закрывают НФТ Boardy

Если Loki или Grafana (шаги 2 и 6) с первого раза не завелись — опишите в отчёте, на чём остановились. Разберём на следующей паре.

Отчёт lab/lab5/report.md — таблица «пункт ТЗ → шаг → проверка → замер (что получилось на самом деле) → закрыто / нет».

Что сдать

Критерии приёмки

Не принимается: скилл без прогона или прогон без скилла; журналы в репозитории (logs/ не в .gitignore); пароли или токены в журналах; система не поднимается с чистого клона.

Как сдать

1. git add . && git commit -m "…" → git push -u origin lab5
2. На GitHub: Pull request lab5 → main, в описании Closes #<номер задачи>.
3. Сдано в срок, если запрос открыт до срока — время фиксирует GitHub.

Срок: 04.11.2026, 14:00 (Екатеринбург) · Сдача: Pull request lab4 → main, в описании Closes #<номер задачи>

Цель

Довести до конца решение с практики 21.10: каждый сервис Boardy сам пишет свои журналы в папку проекта ./logs/<сервис>, у каждой папки правильный владелец. Это закрывает строку чек-листа НФТ «журнал есть у каждого сервиса и известно, где он» (сопровождаемость · анализируемость).

Перед началом

• Boardy поднимается: docker compose up -d → http://localhost:8080.
• git checkout main && git pull → git checkout -b lab4. Если на практике вы уже начали в другой ветке — продолжайте в ней и назовите PR lab4.
• Пошаговые фрагменты конфигов — в методичке lab/lab4/guide.md.

Как выполнять

1. Карта «было». Для каждого сервиса — nginx, php-fpm, Laravel, FastAPI (uvicorn), MySQL, Redis — запишите, какие журналы он пишет и куда. Проверка: таблица в lab/lab4/report.md.
2. Папки и права. Создайте ./logs/<сервис> для всех шести сервисов и отдайте каждую тому пользователю, под которым сервис пишет журнал. Проверка: после docker compose up -d с чистой папки logs/ все сервисы пишут журналы без ошибок прав; logs/ в .gitignore.
3. nginx, Laravel, uvicorn — то, что начали на практике, доведите до рабочего состояния у себя. Проверка: после открытия ленты и запроса к API строки появились в logs/nginx/access.log, logs/laravel/…, logs/api/….
4. php-fpm. Журнал ошибок и журнал доступа — в logs/php-fpm/. Проверка: php-fpm -tt показывает ваши пути; после открытия ленты в logs/php-fpm/ есть журналы.
5. MySQL. Журнал ошибок — в logs/mysql/. Проверка: после перезапуска MySQL в журнале строки запуска.
6. Redis. Журнал — в logs/redis/. Проверка: после перезапуска Redis в журнале строки запуска.
7. Карта «стало». Проверка: в отчёте таблица «сервис → журнал → путь в контейнере → файл на хосте → владелец».

Что сдать

Критерии приёмки

Не принимается: журналы в репозитории (папка logs/ не в .gitignore); chmod 777 на папки журналов; система не поднимается с чистого клона; работа сделана нейросетью.

Как сдать

1. git add . && git commit -m "…" → git push -u origin lab4
2. На GitHub: Pull request lab4 → main, в описании Closes #<номер задачи>.
3. Сдано в срок, если запрос открыт до срока — время фиксирует GitHub.

Срок: 04.11.2026, 14:00 (Екатеринбург) · Сдача: Pull request lab3 → main, в описании Closes #<номер задачи>

Цель

Довести до рабочего состояния две функции из ТЗ Boardy, которые сейчас не работают: вход через GitHub и уведомления о новых объявлениях в реальном времени. Результат — обе функции работают с чистого клона, и это показано.

Перед началом

• ДЗ 2 слито в main.
• git checkout main && git pull → git checkout -b lab3

Как выполнять

1. Вход через GitHub. Заведите своё OAuth-приложение на GitHub и подключите его к Boardy. Ключи — только в .env, в репозиторий не коммитить; в .env.example — пустые строки с пояснением. Проверка: кнопка «Войти через GitHub» → GitHub → вы вошли в Boardy под своим аккаунтом.
2. Уведомления в реальном времени. Сценарий: в одном браузере открыта лента, во втором другой пользователь подаёт объявление. В первом браузере без перезагрузки страницы появляется уведомление о новом объявлении — не позже чем через 5 секунд. Проверка: сценарий воспроизводится, видео или два скрина приложены.
3. Найдите, почему не работало. Пройдите путь события от подачи объявления до экрана получателя и запишите каждое место, где оно терялось, и причину. Проверка: в отчёте список «где терялось → почему».
4. Чините по одному. Одна причина — один коммит, в сообщении — что было не так. Проверка: после каждой правки система поднимается, остальные функции работают как раньше.
5. Не перегибайте. Делаем минимально необходимое: брокеры сообщений (RabbitMQ, Kafka), новые сервисы и переписывание существующих в этой работе не нужны. Проверка: для каждой правки вы можете сказать, без чего сценарий не работал.
6. Проверьте с чистого клона: git clone в новую папку → .env с ключами → docker compose up -d → оба сценария. Проверка: оба работают.

Что сдать

Критерии приёмки

Не принимается: ключи GitHub в репозитории; уведомление только после перезагрузки страницы; все правки одним коммитом; работа сделана нейросетью.

Как сдать

1. git add . && git commit -m "…" по каждой правке → git push -u origin lab3
2. На GitHub: Pull request lab3 → main, в описании Closes #<номер задачи>.
3. Сдано в срок, если запрос открыт до срока — время фиксирует GitHub.

Срок: 21.10.2026, 14:00 (Екатеринбург) · Сдача: Pull request lab2 → main, в описании Closes #<номер задачи>

Цель

Поправить реализацию Boardy по базовым принципам — эвристикам (DRY, KISS, YAGNI, SoC, закон Деметры, POLA) и SOLID, — чтобы следующие темы курса строились на ровной основе. Устройство кода меняем, поведение системы — нет.

Перед началом

• Список нарушений: ваши находки из общего документа «Анализ архитектуры системы» с практики 07.10 и презентация с разбором практики 2, которую выдал преподаватель.
• Система поднимается: docker compose up -d → http://localhost:8080.
• git checkout main && git pull → git checkout -b lab2

Как выполнять

1. Зафиксируйте поведение «до». Пройдите по всем функциям системы (лента, объявление, комментарии, вход и регистрация, подача объявления, API) и сохраните результат: скрипт с запросами и их ответами или тесты. Проверка: результат «до» сохранён в lab/lab2/report.md или лежит в репозитории.
2. Составьте план правок. Из списка нарушений выберите, что исправляете, и у каждого пункта укажите принцип. Проверка: в отчёте таблица «нарушение → принцип → что сделаю».
3. Исправляйте по одному. Одна правка — один коммит, в сообщении — что было не так и какой принцип нарушен. Проверка: после каждой правки система поднимается, функции работают как раньше.
4. Не перегибайте. Делаем необходимое: DDD, фабрики «на будущее», новые слои и новая инфраструктура (логирование, метрики, очереди) в этой работе не нужны — сервис маленький. Проверка: для каждой новой абстракции вы можете назвать, какую правку она удешевляет.
5. Проверьте поведение «после». Повторите прогон из шага 1. Проверка: результат совпадает с «до».
6. Запишите итог. Проверка: в отчёте — что исправлено (ссылки на коммиты), что сознательно не стали делать и почему.

Что сдать

Критерии приёмки

Не принимается: система не поднимается; все правки одним коммитом; поведение системы изменилось; работа сделана нейросетью.

Как сдать

1. git add . && git commit -m "…" по каждой правке → git push -u origin lab2
2. На GitHub: Pull request lab2 → main, в описании Closes #<номер задачи>.
3. Сдано в срок, если запрос открыт до срока — время фиксирует GitHub.

Срок: 21.10.2026, 14:00 (Екатеринбург) · Сдача: Pull request lab1 → main, в описании Closes #<номер задачи>

Цель

Привести систему в рабочее состояние: исправить косяки, которые вы нашли и которые ещё не нашли, и довести функциональные требования.

Перед началом

• ДЗ 0 сдано (запрос на слияние lab0 принят или открыт).
• git checkout main && git pull → git checkout -b lab1

Как выполнять

1. Составьте список исправлений по общему документу с пары 30.09. Допишите косяки, которые найдёте по ходу.
2. Исправляйте по одному: одно исправление — один коммит, в сообщении — что было не так и чем грозило. Проверка: после каждого исправления docker compose up -d поднимается, функции работают.
3. Обязательно — технические дефекты, которые влияют на работу всей системы. Логирование, алерты и метрики на этом этапе не требуются.
4. Доведите функциональные требования из ДЗ 0, если не успели.
5. Запишите итог в отчёт: что исправлено (со ссылками на коммиты), что осталось и почему.

Что сдать

Критерии приёмки

Не принимается: система не поднимается; все правки одним коммитом; работа сделана нейросетью.

Как сдать

1. git push -u origin lab1
2. На GitHub: Pull request lab1 → main, в описании Closes #<номер задачи>.
3. Сдано в срок, если запрос открыт до срока — время фиксирует GitHub.

Срок: 21.10.2026, 14:00 (Екатеринбург) · Сдача: Pull request lab0 → main, в описании Closes #<номер задачи>

Цель

Восстановить техническое задание на доставшуюся систему: что она делает и что должна делать. Это первая часть ТЗ — функциональные требования. Нефункциональные пока не пишем.

Перед началом

• Получите репозиторий: https://ai-info.ru/?c=wa2 → войдите через GitHub → выберите себя → примите приглашение.
• Установлены Git и Docker.
• git clone <ваш репозиторий> → git checkout -b lab0

Как выполнять

1. Запустите проект: docker compose up -d. Проверка: http://localhost:8080 открывает ленту, http://localhost:8080/api/docs — документацию API. Если что-то мешает запуску — исправьте только это.
2. Пройдите систему руками и составьте список функций: лента, объявление, комментарии, регистрация, вход, подача объявления, пользователи, API. Проверка: каждую функцию вы сами выполнили.
3. Опишите назначение системы: что она делает, для кого, какие роли пользователей.
4. Напишите ТЗ — функциональные требования: пользовательские истории («Как роль, я хочу действие, чтобы цель») и к каждой пронумерованные ФТ (ФТ-1.1, ФТ-1.2…). У каждого ФТ — вход, что делает система, результат, реакция на ошибку. Проверка: каждая функция из шага 2 покрыта хотя бы одним ФТ.

Что сдать

Критерии приёмки

Не принимается: нет lab/lab0/report.md; работа сделана нейросетью.

Как сдать

1. git add lab/lab0/report.md && git commit -m "ДЗ 0: ТЗ" → git push -u origin lab0
2. На GitHub: Pull request lab0 → main, в описании Closes #<номер задачи>.
3. Сдано в срок, если запрос открыт до срока — время фиксирует GitHub.