Задание 1. Составьте карту pipeline
- Укажите этапы от pull request до production в корректном порядке.
- Для каждого назовите хотя бы одно доказательство прохождения.
- Определите, какой этап обязан остановить текущий релиз, и объясните почему.
Обеспечение качества функционирования компьютерных систем · работа 5/5
Контроль качества релизов и CI/CD
Критерии допуска, воспроизводимость сборок, canary и rollback. Сначала изучите теорию и интерактивные модели, затем выполните три практических задания и тест внизу страницы. Всё сохраняется в этом браузере автоматически.
01
Качество не заканчивается на запуске тестов
Команда «Кампуса» готовит версию 1.5.0: теперь преподаватель может массово загрузить оценки. Модульные тесты проходят, но в staging сборка падает на больших CSV-файлах. Если нажать «Опубликовать» без анализа, дефект получат все пользователи. Поэтому для выпуска требуется решение о готовности релиза, основанное на свидетельствах.
CI — частая интеграция изменений с автоматическими проверками. CD в зависимости от практики означает автоматизированную доставку к развёртыванию (continuous delivery) или автоматическое развёртывание (continuous deployment). Сами термины не делают pipeline безопасным: важно содержание проверок и разрешения на production.
Изменение кодаPull request
→ПроверкиСборка и тесты
→StagingСреда, близкая к рабочей
→РешениеКритерии и одобрение
→ProductionРазвёртывание и мониторинг
Принцип shift left помогает обнаруживать дефекты раньше. Наблюдение после выпуска («shift right») проверяет реальные риски эксплуатации. Подходы дополняют друг друга.
02
Quality gates: какие проверки должны блокировать релиз
Quality gate — правило допуска к следующему этапу. Оно работает только при конкретном условии, известном источнике доказательства и понятном владельце решения. Например, «все обязательные интеграционные тесты прошли» — проверяемый gate; «мы надеемся, что всё хорошо» — нет.
| Контроль | Что доказываем | Когда блокировать |
|---|---|---|
| Unit-тесты | Локальные контракты функций | Есть падения обязательных тестов |
| Интеграционные | API согласованно работает с БД | Есть падения критичных сценариев |
| Проверки безопасности | Нет известных неприемлемых рисков по согласованной политике | Обнаружен блокирующий риск |
| Проверка staging | Новый артефакт ведёт себя как ожидается | Критичный сценарий не работает |
| Одобрение | Ответственный рассмотрел доказательства | Одобрение обязательно, но не получено |
| План rollback | Есть проверенный вариант восстановления версии | Нечем безопасно откатиться |
В реальном GitHub Actions защищённые environments могут использовать согласование и ограничения веток. Доступность отдельных правил зависит от конфигурации и условий репозитория. Учебный симулятор ниже воспроизводит логику допуска, но не выполняет реальные deployment-действия.
03
Сборка, версии, артефакты и воспроизводимость
Версия вроде 1.5.0 помогает человеку понять выпуск; commit SHA определяет состояние исходного кода; digest контейнерного образа фиксирует точное содержимое образа. Docker-тег app:1.5.0 сам по себе технически может быть переназначен. Надёжный pipeline связывает тестировавшийся артефакт с тем, что развёрнуто.
CommitИсходники
→BuildОдин артефакт
→TestПроверяем его
→PromoteТот же digest
→DeployУправляемое развёртывание
Типовые этапы: статические проверки → unit → integration → сборка контейнера → проверка и публикация артефакта → staging → ручной/политический допуск → production → наблюдение. Точное расположение проверок зависит от инфраструктуры; существенна прослеживаемость и запрет на обход обязательных этапов.
Версия: v1.5.0
Commit: 2e8a… (пример короткого идентификатора)
Artifact: app@sha256:… (пример неизменяемой адресации)
Отчёт: tests=PASS; staging=PASS; approval=YES
При rollback возвращают известную исправную сборку. Однако изменения схемы БД могут оказаться несовместимыми со старой версией приложения — план отката должен учитывать миграции и данные.
04
Канареечные релизы, наблюдение и остановка
Массовое развёртывание повышает радиус воздействия ошибки. Canary deployment сначала направляет небольшую часть трафика на новую версию; blue-green использует две среды с переключением трафика. Ни одна стратегия не отменяет мониторинг и план обратного переключения.
| Стратегия | Идея | Риск, который нужно контролировать |
|---|---|---|
| Rolling | Постепенная замена экземпляров | Сосуществование разных версий |
| Canary | Проверка новой версии на части трафика | Корректность метрик на малой выборке |
| Blue-green | Подготовить новую среду и переключить | Данные и совместимость схемы |
Учебный сценарий после запуска
В течение 10 минут после выхода версии p95 сохранения оценок вырос с 240 до 1700 мс, а доля ошибок — с 0,2% до 6%. При заранее установленном пороге автоматического rollback команда должна остановить расширение canary, проверить подтверждённые метрики и безопасно вернуть предыдущую версию.
После исправления проводят post-incident review: что стало причиной, почему защита не сработала раньше и какое изменение процесса предотвратит повторение. Цель — улучшение системы, а не назначение виновного.
05
Интерактив: решение «выпускать или нет»
🧪 Release gate — тренажёр допуска
Отметьте только подтверждённые проверки для версии 1.5.0. Выпуск будет разрешён исключительно при выполнении всех обязательных условий. Это учебное правило команды, а не универсальный стандарт.
Кнопка «Отметить все проверки» не выполняет реальные тесты. В настоящем процессе статус должен приходить из достоверных источников, быть привязан к конкретному артефакту и защищён от произвольного изменения.
06
Прослеживаемость релиза: протокол доказательств
Когда сборка прошла 300 тестов, нужно знать, какая именно сборка прошла проверку и какой набор тестов запускался. Если после тестов пересобрать контейнер с другими зависимостями, прослеживаемость будет нарушена. Поэтому записывают commit, версию, digest и результаты обязательных этапов.
| Поле протокола | Пример значения | Зачем нужно |
|---|---|---|
| Commit | 2e8a… | Исходники, по которым собран продукт |
| Версия | v1.5.0 | Читаемая метка выпуска |
| Digest | sha256:… | Точное содержимое артефакта |
| Тестовый отчёт | run-502: PASS | Доказательство проверок |
| Staging / approval | PASS / approved | Допуск к следующей среде |
Сравнивайте не просто название версии, а идентичность артефакта. Особенно это важно для rollback: команда должна знать, что возвращает именно проверенный выпуск, а не произвольное содержимое под похожим тегом.
07
Схема базы данных и безопасные изменения
Новая функция массовой загрузки оценок требует добавить поле import_batch_id. Если новая версия приложения сразу начнёт читать это поле, а миграция в БД не применена, запросы могут падать. Если после миграции старая версия больше не работает, rollback тоже окажется затруднительным.
Паттерн expand–migrate–contract уменьшает риск: сначала в схему добавляют обратно совместимое поле, затем переводят приложение и данные на новую структуру, а удаление старого выполняют отдельным поздним изменением после проверки. Не каждую миграцию можно безопасно откатить одной обратной командой.
ExpandДобавить совместимую структуру
→MigrateПеренести данные и трафик
→VerifyУбедиться в совместимости
→ContractУбрать старую структуру позже
Миграции необходимо проверять на копии реалистичной схемы и объёма данных, учитывать блокировки таблиц, сроки выполнения и доступность старых клиентов. Вопрос «как вернуться назад?» решают до запуска изменения, а не после аварии.
08
Оценка риска изменений и финальный чек-лист
Одинаково строгие процедуры могут быть избыточны для исправления опечатки и недостаточны для изменения модели доступа к оценкам. При выборе объёма испытаний учитывают масштаб изменений, критичность данных, сложность rollback, охват пользователей и предыдущие инциденты. Обязательные требования безопасности остаются обязательными даже для «маленького» патча.
| Изменение | Основной риск | Нужный акцент в проверках |
|---|---|---|
| Текст подсказки | Непонятное описание для пользователя | UI и доступность интерфейса |
| Массовая загрузка CSV | Потеря или повреждение оценок | Интеграция, границы, нагрузка, откат |
| Новый механизм авторизации | Чужие полномочия и отказ доступа | Негативные тесты безопасности |
| Миграция БД | Долгая блокировка или несовместимость | Тест данных и план восстановления |
Перед итоговым GO соберите паспорт релиза: цель изменения, затронутые операции, неизменяемый артефакт, результаты тестов, замечания, ответственные, ограничения, план rollout, критерии остановки и rollback. В этом и состоит связка обеспечения качества с эксплуатацией компьютерной системы.
09
Практика: протокол решения о релизе
Вы — инженер контроля качества версии «Кампус 1.5.0». Перед вами вводные: unit-тесты прошли, интеграционный тест массовой загрузки падает, staging ещё не проверен, план rollback есть, руководитель выпуска требует «скорее в production». По согласованной политике все семь условий симулятора обязательны.
Задание 2. Примите решение по выпуску
- Для заданного сценария запишите GO или NO-GO и обоснуйте решение тремя фактами.
- Составьте короткое сообщение команде с указанием блокирующего теста и следующего действия.
- Объясните, почему давление сроков не должно отменять обязательные проверки.
Задание 3. Подготовьте контроль после развёртывания
- Предложите две метрики качества новой функции и пороги с интервалом наблюдения.
- Опишите, когда останавливать canary и выполнять rollback.
- Назовите возможный риск отката при изменении схемы базы данных.
Часть II · проверка знаний
Тест по изученному материалу
Выберите один ответ в каждом вопросе и нажмите «Проверить тест». После проверки появятся разборы. Практические задания и развёрнутые вопросы проверяет преподаватель — в процентах они не учитываются.
Часть A. Выберите правильный ответ
Часть Б. Объясните своими словами
Эти вопросы оценивает преподаватель. Не копируйте определения: приведите собственный аргумент и, где необходимо, расчёт или пример.
Источники для дополнительного изучения
Теоретические сведения адаптированы для обучения. Интерактивные расчёты и сценарии — учебные модели, не измерения работающей инфраструктуры. Внешние ссылки нужны только для дополнительного чтения: сама работа открывается без интернета.
Перед сдачей
✓ Заполнены ФИО, группа и дата.
✓ Выполнены три практических задания.
✓ Выбраны и проверены ответы на 15 тестовых вопросов.
✓ Записаны три развёрнутых ответа.
Нажмите «Отправить работу — сохранить PDF» и в диалоге печати выберите «Сохранить как PDF». В PDF попадут ФИО, ответы, результат тестирования и задания. Никакие данные не отправляются на сервер.
Открылось окно печати — выберите «Сохранить как PDF».