Перед началом
- изменение описано и имеет owner;
- известен affected service и его зависимости;
- сделан подходящий backup;
- подготовлен rollback artifact/config;
- maintenance window согласовано для критичного изменения;
- monitoring не удалён, а переведён в maintenance при необходимости.
Systemd service
1
Проверьте unit и environment
Используйте
systemd-analyze verify, не выводите secret values.2
Установите новый binary
Сохраняйте предыдущую версию для rollback.
3
Перезапустите один service
Не делайте reboot VM без необходимости.
4
Проверьте состояние
systemctl status, локальный health и journal.5
Проверьте edge
Внешний DNS/TLS/API контракт должен отвечать.
Docker Compose / Portainer
1
Зафиксируйте image digests
Не используйте плавающий
latest для критичных сервисов.2
Проверьте Compose config
Volumes, networks, healthchecks и secrets.
3
Получите новые images
Старые images оставьте на rollback window.
4
Обновите stack
Следите за health, restart count и миграциями.
5
Проверьте данные
Открытие UI недостаточно для stateful приложения.
Обновление Proxmox guest
- Проверьте backup и свободное место ZFS.
- Убедитесь, что QEMU Guest Agent отвечает.
- Обновите приложение внутри guest по его runbook.
- Перезагружайте guest только если этого требует kernel/runtime.
- Reboot PVE node планируется отдельно и учитывает VM autostart.
102–104 не имеют onboot: 1. Перед плановым reboot xinboshin
нужно либо включить согласованную startup policy, либо подготовить ручной
порядок запуска GitLab, Runner и launcher-server.
Rollback
- Binary: вернуть предыдущий файл и перезапустить service.
- Container: вернуть прежний image digest и выполнить
compose up -d. - Database: не откатывать schema копированием старого приложения без проверки backward compatibility; используйте migration rollback/restore plan.
- Proxy: вернуть старый upstream.
- VM: restore выполняется в новый VMID, если inplace restore создаёт лишний риск.