Система оценивания

О чём этот файл

Описание того, как курс проверяет знания: какие инструменты используются, что каждый из них измеряет, как считаются баллы и какой результат считается проходным. Сами материалы проверки лежат в assessments/.

Принципы

Система построена на четырёх правилах.

1. Проверяется понимание, а не запоминание. Вопрос «какой флаг публикует порт» бесполезен — его отвечает docker run --help. Вопрос «почему приложение недоступно, хотя порт опубликован» проверяет то, что действительно нужно.

2. Каждая проверка имеет объективный критерий. «Хороший Dockerfile» — не критерий. «Образ меньше 350 MB по docker images (это DISK USAGE, а не вчетверо меньший CONTENT SIZE из docker image inspect), процесс запущен от UID ≠ 0, изменение кода не пересобирает dependencies, SIGTERM завершает приложение за 3 секунды» — критерий.

3. Диагностика проверяется отдельно. Умение собрать работающую конфигурацию и умение починить сломанную — разные навыки. Второй важнее в реальной работе и проверяется debugging challenges.

4. Самопроверка выполнима. Курс рассчитан на самостоятельное прохождение: каждое задание содержит команды проверки и ожидаемый вывод. Никакой инструмент не требует внешнего проверяющего.

Уровни проверки

  Уровень                Частота          Формат                Время
  ─────────────────────────────────────────────────────────────────────
  1. Встроенное      после каждого     задание с подсказками    15–30 мин
     задание урока   урока             и решением

  2. Exercises       после каждого     3–6 лабораторных задач   1–4 ч
                     раздела           с проверкой результата

  3. Quiz            после каждого     10 вопросов              10–15 мин
                     раздела

  4. Checkpoint      после группы      практическая задача      2–3 ч
                     разделов          с критериями приёмки

  5. Проект          4 раза за курс    полноценное приложение   4–12 ч

  6. Debugging       после раздела 13  20 сломанных             30 мин
     challenge                         конфигураций            каждая

  7. Итоговый        в конце           теория + практика        8 ч
     экзамен

1. Встроенное задание урока

Каждый полноценный учебный файл содержит блок:

## Практическое задание
## Подсказки
## Решение

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

Что измеряет: способность применить материал урока сразу, пока контекст свежий.

Самопроверка: каждое задание заканчивается разделом «Проверка результата» с командой и ожидаемым выводом.

2. Exercises раздела

Файл exercises.md в каждом разделе. Структура:

Каждое задание содержит: постановку, ожидаемый результат, команды проверки и — под спойлером — разбор.

Что измеряет: практическую применимость материала раздела.

3. Quiz раздела

Десять вопросов на раздел в assessments/module-quizzes.md. Состав фиксирован:

Оценка: правильных ответов из 10.

Quiz не влияет на итоговый балл курса. Это инструмент самодиагностики.

4. Checkpoints

Четыре контрольные точки после логических блоков курса. Материалы — assessments/checkpoints.md.

Каждый checkpoint содержит:

• диагностическую задачу — сломанная конфигурация, симптом и требование найти root cause;
• самостоятельное задание — небольшая, но законченная работа;
• критерии приёмки — проверяемый список из 5–8 пунктов.

Правило: checkpoint не пройден, пока не выполнены все критерии приёмки. Частичное выполнение не засчитывается — в эксплуатации частично работающий сервис равен неработающему.

5. Проекты

Четыре проекта нарастающей сложности. Каждый содержит TASK.md (техническое задание), SOLUTION.md (эталонная реализация) и CHECKLIST.md (критерии сдачи).

Порядок работы:

1. Прочитать TASK.md целиком, включая раздел «Критерии завершения».
2. Реализовать самостоятельно.
3. Пройти CHECKLIST.md — по каждому пункту выполнить указанную проверку.
4. Только после этого открыть SOLUTION.md и сравнить решения.
5. Разобрать расхождения: где решение курса лучше и почему, где ваше решение обоснованнее.

Пункт 5 важнее пунктов 1–4. Эталонное решение — не единственно верное. Умение объяснить, почему вы выбрали иначе, — признак уровня L4 в карте компетенций.

Дополнительные задания повышенной сложности в конце каждого TASK.md не входят в критерии сдачи, но существенно углубляют понимание.

6. Debugging challenges

Двадцать сломанных конфигураций в assessments/debugging-challenges.md. Каждая описывает симптом; конфигурация приложена; задача — найти root cause и починить.

Покрываемые сценарии:

Формат каждого challenge:

• симптом — то, что видит пользователь;
• сломанная конфигурация — рабочие файлы, воспроизводящие проблему;
• методика расследования — какие вопросы задавать и в каком порядке;
• команды диагностики;
• правильное исправление;
• объяснение root cause.

Правило: сначала решите самостоятельно, затем сверьтесь с разбором. Раздел «методика расследования» открывайте, если застряли более чем на 20 минут — он даёт направление, а не ответ.

Целевой результат: не менее 15 из 20 решено самостоятельно.

7. Итоговый экзамен

Теоретический тест

assessments/final-theory-exam.md — 40 вопросов, охватывающих все разделы. Проверяет понимание механизмов: namespaces, layers, NAT, сигналы, build cache, модель безопасности.

Проходной результат — 30 из 40.

Практический экзамен

assessments/final-practical-exam.md — контейнеризация незнакомого Python-приложения с нуля за 6 часов. Даны: исходный код, требования к развёртыванию, ограничения по ресурсам. Требуется: Dockerfile, compose.yaml, документация, tests и обоснование решений.

Оценивается по rubric.

Rubric — шкала 0–100

Полная версия с детализацией по каждому критерию: assessments/grading-rubric.md.

Пороговые значения

Обязательные требования (blocking)

Независимо от суммы баллов работа не принимается, если выполнено хотя бы одно:

1. Secrets (пароли, токены, ключи) присутствуют в layers образа — проверяется docker history --no-trunc.
2. Приложение запускается от root без явного письменного обоснования.
3. Конфигурация не воспроизводится с чистой машины по приложенной инструкции.
4. Используется development server (flask run, uvicorn --reload) в production-конфигурации.
5. Container не завершается по docker stop в пределах grace period.

Эти пункты не «снимают баллы» — они блокируют приём. Каждый из них в реальной эксплуатации приводит к инциденту.

Итоговый расчёт

Quizzes и checkpoints в итоговый балл не входят — они служат самодиагностикой. Но пройденный checkpoint является допуском к следующему блоку разделов.

Что делать с результатом

Навигация

← Предыдущий материал
Вернуться к главному оглавлению
Перейти к разделу 01. Подготовка среды →