Постановка итогового проекта: требования и правила игры

Хронометраж: занятие 60 минут — теория 30 минут, практика 30 минут. Домашняя работа: итоговый проект, 15–30 часов.

Кратко о чём урок: Описание сервиса (приложение + БД + кэш + фоновые задачи), обязательные требования ко всем вариантам, этапы и сроки, что считается выполненным, как оформляется репозиторий и документация.

---

1. Что изучаем

• понимать, что итоговый проект — это production-grade инфраструктура, а не «развернул и работает»;
• выбирать один из трёх вариантов стенда (VPS, Yandex Cloud, локальный) по своим целям;
• читать критерии приёмки капстоуна и понимать, откуда каждый взялся в курсе;
• проверять готовность проекта инструментом, а не на глаз;
• отличать обязательное (без чего не принимается) от желательного (что делает проект сильным).

2. Зачем это нужно и где применяется

Восемнадцать блоков курса дали инструменты по отдельности: контейнеры, оркестрацию, конвейеры, инфраструктуру как код, наблюдаемость, надёжность, безопасность. Итоговый проект — это место, где всё это собирается в одно: вы берёте настоящий сервис и доводите его до состояния, в котором его не стыдно отдать в эксплуатацию. Не «запустил приложение», а «развернул сервис так, что за него можно отвечать».

У капстоуна две цели, и обе практические. Первая — проверить себя: пока навыки лежат по блокам, кажется, что всё понятно; когда их надо связать в работающую систему, обнаруживаются дыры, и это лучшее место их найти — на учебном проекте, а не на первой работе. Вторая — портфолио: готовый проект с инфраструктурой как кодом, конвейером и документацией — это то, что показывают на собеседовании вместо слов «я умею Kubernetes». Урок 22.06 про это отдельно.

Этот урок не пишет за вас проект — он задаёт правила игры: что делаем, из чего выбираем и по каким критериям принимаем. Следующие три урока (22.02–22.04) показывают, как собрать проект на каждом из трёх стендов, урок 22.05 углубляет сквозные требования (наблюдаемость, безопасность, документация), а 22.06–22.07 — про выход на работу.

3. Теория (30 минут)

Что за проект

Проект один: взять веб-сервис и развернуть его как production-grade инфраструктуру. Сервис может быть учебным приложением курса (course-k8s-app / course-obs-app — они уже умеют пробы, метрики, логи, управляемое поведение) или вашим собственным — это не важно. Важно не приложение, а то, что вокруг него: как оно собирается, выкатывается, наблюдается, защищается и восстанавливается.

Минимальный сервис для капстоуна — это приложение плюс хотя бы одна зависимость с состоянием (база данных или кэш), потому что именно состояние поднимает большинство настоящих вопросов: миграции (07.07), резервные копии (07.10, 14.12), тома и права (08.06, 13.11), пул соединений (07.06). Сервис без состояния разворачивается слишком легко и половину курса не задействует.

Требование, отличающее капстоун от лабораторной: всё должно быть воспроизводимо из кода. Человек, которому вы отдадите репозиторий, должен поднять весь стенд по README одной-двумя командами, без вашего участия и без «а ещё надо вручную вот это». Это ровно то, что проверяет работодатель, и ровно то, чему учил весь курс — инфраструктура как код (блоки 10, 11), а не набор команд в чьей-то голове (20.06).

Три варианта стенда

Проект один, но собрать его можно на трёх разных стендах. Выбор — за вами, по целям и ресурсам; каждый вариант закрывает разные строки резюме.

Вариант A — VPS / bare-metal (урок 22.02). Одна-две обычные машины, docker compose или Ansible, nginx как вход, резервные копии скриптом по расписанию. Самый близкий к тому, как работает малый и средний бизнес, и самый дешёвый. Показывает, что вы умеете не только «нажать кнопку в облаке», а собрать сервис на голой машине — навык, который ценится и который многие обходят.

Вариант B — Yandex Cloud (урок 22.03). Terraform, Managed Kubernetes, GitOps, облачный балансировщик и хранилище. Самый близкий к тому, как работают крупные компании, и самый весомый в резюме. Дороже (реальные деньги за облако) и требует дисциплины уборки — но именно это стек большинства вакансий DevOps.

Вариант C — локальный стенд (урок 22.04). kind, Helm или Kustomize, конвейер на GitHub Actions. Бесплатный, целиком на своей машине, и при этом показывает почти весь стек Kubernetes. Лучший выбор, если облако недоступно по деньгам: на kind проверяется всё, кроме облачных интеграций (LoadBalancer с реальным адресом, облачный CSI), а про них честно пишется «на kind не воспроизводится» — это тоже навык, показанный в курсе многократно.

Сильный ход — собрать проект на одном стенде, а в README описать, что изменится при переносе на другой: это демонстрирует понимание переносимости (карта эквивалентов из 11.10) и стоит больше, чем три недоделанных варианта.

Критерии приёмки: обязательное и желательное

Проект принимается не «на глаз», а по критериям, и они разделены на два уровня. Обязательные — без них проект не засчитывается вовсе: развёрнутое приложение, инфраструктура кодом, конвейер сборки и проверок (CI), автоматизированный выкат (CD), пробы готовности и живости, секреты не в открытом виде, README «как поднять и как проверить». Это тот минимум, ниже которого инфраструктуру нельзя назвать инженерной.

Желательные поднимают проект с «зачёт» до «сильный»: метрики и логи (наблюдаемость), заявленный SLO и бюджет ошибок, алерты на симптомы, сканирование образа и зависимостей, опробованный (а не только описанный) откат, проверенные резервные копии, runbook на типовые аварии, хотя бы одно записанное архитектурное решение (ADR). Ни один из них не «для галочки» — каждый закрывает реальный риск, и каждый разбирался в курсе.

Ключевая мысль: каждый критерий имеет адрес в курсе. Пробы — 07.05 и 13.10, секреты — 07.03 и 18.03, SLO — 16.10 и 20.04, откат — 13.05 и 20.03, резервные копии — 07.10 и 14.12, runbook — 17.06 и 20.06. Капстоун не требует ничего, чего вы не проходили; он требует связать пройденное. В практике этого урока проверятель capstone-check.py печатает по каждому критерию урок, откуда он взялся, — заодно это карта для повторения.

Правила игры

Три правила, которые делают капстоун капстоуном, а не демонстрацией.

Проверяемость запуском. Каждое заявленное свойство должно подтверждаться командой, файлом или ссылкой, а не словами. «Есть мониторинг» — это запрос в Prometheus, дающий число; «есть откат» — это проведённый откат, а не строчка в README. Это дисциплина всего курса (проверка фактов): непроверенное не считается сделанным.

Документированность. README объясняет, как поднять стенд и как убедиться, что он работает; runbook — что делать при типовых авариях; ADR — почему приняты ключевые решения. Проект, который понимает только автор, в эксплуатации бесполезен (20.06): знание должно жить в артефактах, а не в голове.

Защитимость. Вы должны уметь объяснить каждое решение: почему этот стенд, почему такой SLO, почему секреты так, а не иначе. Собеседование по проекту (22.07) — это разговор о принятых решениях, и защитить чужой скопированный проект нельзя. Отсюда требование ADR: записанное решение с обоснованием — это и документация, и подготовка к защите.

Как довести проект до конца

Капстоун проваливают не потому, что не хватает навыков, а потому, что берутся за всё сразу и вязнут. Проект надо вести так же, как любой инфраструктурный проект из 20.07: декомпозировать, оценить, делать по этапам, а не одним рывком.

Разумная последовательность — сначала минимальный сквозной путь, потом наращивание. Первый этап: приложение с зависимостью развёрнуто из кода и отвечает — пусть без наблюдаемости и без CI, но целиком из репозитория. Это костяк, на который потом навешивается остальное, и он сразу проверяет главное (воспроизводимость). Второй этап: конвейер сборки и выката. Третий: сквозные требования — наблюдаемость, безопасность, документация (урок 22.05). Такой порядок даёт работающий проект на каждом шаге, а не гору незаконченных кусков; если время кончится, у вас всё равно есть цельный, пусть меньший, результат.

Оценивать время стоит по трёхточечной методике из 20.07: у инфраструктурных задач длинный хвост («поднять кластер» может занять и час, и день из-за мелочи), и капстоун — не исключение. Заложите запас, ведите проект этапами с проверяемым результатом каждого, и не беритесь за три варианта стенда сразу: один доведённый до конца проект сильнее трёх начатых. Проверятель capstone-check.py здесь работает как дорожная карта — прогоняйте его по ходу, и он показывает, что уже закрыто и что осталось.

Что каждый критерий говорит работодателю

Критерии приёмки — это не школьные требования, а сигналы, которые читает работодатель, и полезно понимать, что именно каждый из них сообщает о вас (подробно про это — урок 22.06).

Инфраструктура кодом говорит: «я не настраиваю сервер руками, за мной можно повторить». Конвейер (CI/CD) говорит: «у меня изменения едут в прод через проверки, а не через ssh и надежду». Пробы, SLO и алерты говорят: «я думаю про эксплуатацию, а не только про запуск» — это отличает инженера от того, кто один раз развернул по инструкции. Управление секретами и сканирование говорят: «я не оставлю пароль в git и уязвимость в образе». README, runbook и ADR говорят: «мой проект переживёт меня» — а это то, чего работодатель боится больше всего (незаменимый человек с знанием в голове, 20.06).

Отсюда практический вывод для приоритетов: если времени в обрез, сначала закрывайте то, что даёт самый сильный сигнал за наименьшую цену. Инфраструктура кодом и CI/CD — обязательны и весомы. Наблюдаемость и SLO — дорого по времени, но именно они отличают сильный проект от среднего. Один настоящий SLO с бюджетом ошибок и парой алертов на симптомы (16.10, 17.02) на собеседовании стоит больше, чем десять дашбордов без цели.

3.1. Примеры и варианты реализации

Одна задача — три среды. Это и есть три варианта капстоуна; здесь кратко, подробно — в 22.02–22.04.

Среда	Стек капстоуна	Что показывает в резюме
Локальный стенд (kind)	kind, Helm/Kustomize, Actions	почти весь k8s-стек, бесплатно (22.04)
VPS / bare-metal	Compose/Ansible, nginx, бэкапы	сервис на голой машине, дёшево (22.02)
Yandex Cloud	Terraform, Managed K8s, GitOps	облачный стек вакансий (22.03)

Что выбрать. Нет облачного бюджета — вариант C (локальный), он закрывает большую часть навыков бесплатно. Есть цель в облачную вакансию и небольшой бюджет — вариант B, но с жёсткой дисциплиной уборки (F30). Хочется показать «умею без облака» — вариант A. Критерии приёмки одинаковы для всех трёх; различается только стек, которым они закрываются.

4. Практика на занятии (30 минут)

Что делаем. Знакомимся с критериями приёмки и прогоняем проверятель на образце проекта.

Курс проходят самостоятельно, поэтому каждый шаг говорит, что сделать (или что ввести), зачем, что должно получиться и что делать при неудаче.

Файлы для работы: blocks/22-capstone-and-career/examples/22.01-capstone-statement/ — манифест проекта project.yaml и проверятель capstone-check.py.

Шаг 1 (5 минут). Посмотрите манифест проекта.

• Что ввести:

  cat project.yaml
  

• Зачем: манифест — это честный список того, что в проекте реально сделано, и именно на нём дальше работает проверятель.
• Ожидаемый результат: пятнадцать полей вида да/нет (variant, app_deployed, iac, ci_pipeline, healthchecks, observability, secrets_managed, readme и так далее) — каждое должно подтверждаться файлом или командой, а не словами.
• Если не так: файла нет или он пуст — проверьте, что вы находитесь в каталоге examples/22.01-capstone-statement/, а не в корне блока.

Шаг 2 (10 минут). Прогоните проверятель на образце.

• Что ввести:

  python3 capstone-check.py project.yaml; echo "код=$?"
  

• Зачем: проверятель сверяет манифест с критериями приёмки и печатает по каждому пункту, закрыт он или нет, и урок курса, откуда критерий взялся — так же будет работать проверка вашего капстоуна.
• Ожидаемый результат: «Обязательных закрыто: 7 из 7», «Желательных закрыто: 4 из 8», вердикт «ПРОЕКТ ПРИНЯТ: зачёт (обязательное закрыто, желательное стоит добрать).», код=0.
• Если не так: числа отличаются от указанных — образец project.yaml кто-то поправил; сверьте его построчно с версией из репозитория, а не гадайте по выводу.

Шаг 3 (10 минут). Смоделируйте недоделку.

• Что ввести:

  sed 's/^readme: yes/readme: no/' project.yaml > /tmp/p.yaml
  python3 capstone-check.py /tmp/p.yaml; echo "код=$?"
  

• Зачем: показать на практике, что обязательный критерий нельзя компенсировать желательными — без README проект не принимается вовсе, сколько бы наблюдаемости и SLO ни было сверху.
• Ожидаемый результат: строка «[НЕТ] README: как поднять и как проверить», «Обязательных закрыто: 6 из 7», вердикт «ПРОЕКТ НЕ ПРИНЯТ: не закрыты обязательные критерии — README: как поднять и как проверить.», код=1. Именно эта проверка (ненулевой код при недоборе обязательного) и ставится в CI капстоуна.
• Если не так: код всё равно 0 — проверьте cat /tmp/p.yaml | grep readme: возможно, sed не нашёл строку readme: yes (лишний пробел, другой регистр) и файл не изменился.

Шаг 4 (5 минут). Пройдите по столбцу уроков.

• Что сделать: для каждого критерия из вывода шага 2 найдите урок курса рядом с ним и честно отметьте для себя — «умею закрыть прямо сейчас» или «нужно повторить».
• Зачем: это ваша карта повторения — список того, что предстоит связать в проекте, а не список тем для изучения с нуля.
• Ожидаемый результат: по каждому из пятнадцати критериев (семь обязательных, восемь желательных) у вас есть пометка «умею» или «повторить» и номер урока рядом с ней.
• Если не так: по нескольким критериям ответ «не помню, что это» — вернитесь к указанному уроку до начала работы над капстоуном, а не посреди него, когда это дороже.

Проверка результата. Вы понимаете, из чего состоит приёмка, и видите разницу между «обязательное не закрыто» (не принят) и «желательное стоит добрать» (принят, но можно сильнее). Проверятель — не формальность, а чек-лист, по которому вы будете вести свой проект.

5. Домашняя работа (итоговый проект, 15–30 часов на весь блок)

Задание (этап 1 из нескольких — постановка). Выберите вариант стенда и сервис. Составьте свой project.yaml в состоянии «план»: отметьте, что уже умеете и что предстоит сделать. Напишите короткий устав проекта в карточке capstone-charter.md: какой сервис, какой стенд и почему, какие обязательные и желательные критерии берёте, где какой критерий будете закрывать (каким инструментом из курса). Это план капстоуна; выполнение — в уроках 22.02–22.05.

Критерии приёмки этапа.

• выбран вариант стенда и сервис с состоянием (БД/кэш), выбор обоснован;
• project.yaml заполнен как план (что есть / что предстоит);
• python3 capstone-check.py запускается на вашем манифесте и печатает список;
• в уставе для каждого обязательного критерия назван инструмент курса, которым закроете;
• названы 3–4 желательных критерия, которые берёте сверх минимума, с обоснованием.

6. Частые ошибки и подводные камни

• «Развернул — значит готово». Симптом: приложение отвечает, но нет ни CI, ни проб, ни README. Причина: спутали запуск и production-готовность. Что делать: вести проект по критериям приёмки с самого начала.
• Три варианта разом, все недоделанные. Симптом: начаты VPS, облако и kind, ни один не закончен. Причина: переоценка времени (20.07). Что делать: один вариант до конца, перенос описать в README.
• Сервис без состояния. Симптом: проект разворачивается за пять минут и не задействует половину курса. Причина: выбрали слишком простое приложение. Что делать: добавить БД или кэш — появятся миграции, бэкапы, тома.
• README «для себя». Симптом: поднять стенд может только автор. Причина: документация писалась после и наспех. Что делать: README проверяется тем, что по нему поднимает другой человек (или вы на чистой машине).
• Скопированный проект. Симптом: на защите нечего сказать про решения. Причина: взяли чужое. Что делать: капстоун защищается разговором о решениях (22.07) — делайте своё и записывайте ADR.

7. Проверка усвоения

1. Чем итоговый проект отличается от «развернул приложение, оно работает»?
2. Почему в капстоун-сервис обязательно берут зависимость с состоянием?
3. Что значит «воспроизводимо из кода» и как это проверяется?
4. Чем обязательные критерии отличаются от желательных и почему разделение именно такое?
5. Почему у каждого критерия приёмки есть адрес в курсе?
6. Какой вариант стенда выбрать без облачного бюджета и что при этом нельзя показать?
7. Что такое «защитимость» проекта и как к ней готовит ADR?

8. Материалы

Минимум два варианта на выбор: официальная документация плюс книга/статья/видео.

• DORA, Capabilities (dora.dev/capabilities/) — список практик, которые исследование связывает с производительностью доставки: по сути, чек-лист зрелой инфраструктуры, к которой ведёт капстоун.
• Google SRE Book, Production Readiness Review (sre.google/sre-book/) — как крупная эксплуатация проверяет готовность сервиса; основа для критериев приёмки этого урока.
• Оглавление курса (README.md) — карта, по которой собран проверятель: каждый критерий отсылает к блоку, где он разбирался. Лучший источник для повторения перед капстоуном.

---

← Предыдущий: 21.11. Эксплуатация обвязки: разрешения, субагенты, стоимость, наблюдаемость · Блок 22 · Следующий: 22.02. Вариант A: VPS / bare-metal — Compose, Ansible, nginx, бэкапы →