Самое тревожное в GitLab на своём сервере — не сами обновления, а то, что лежит внутри: вся кодовая база компании, все клиентские проекты, вся история. Обновлять страшно, поэтому инстансы годами стоят на старых версиях и копят уязвимости. У студии GitLab застрял на 15.4: к лету 2024 это было уже две мажорные версии назад. Мы провели его через цепочку обязательных промежуточных релизов и две миграции PostgreSQL за 5 часов, а потом два года держали на свежих патчах: критические — в день выхода. За это время случился один ночной отказ. О нём ниже, без купюр.
Сводка
| Отрасль конечного клиента | digital-агентство, разработка сайтов |
| Конечный клиент | «Медиастудия» (код-имя), Россия |
| Формат сотрудничества | абонентская DevOps-поддержка парка из ~14 серверов |
| Тип проекта | сопровождение GitLab на своём сервере: большая миграция + регулярные и срочные обновления |
| Объём работ | цепочка 15.4.2 → 17.2.1 с PostgreSQL 12 → 14; далее 9+ обновлений, из них 3 критических security-патча |
| Дата проекта | 10 июн 2024 – 29 мая 2026 (718 дней) |
| Трудозатраты | ~10 ч за два года (большая миграция — 5 ч) |
| Команда | 3 специалиста (инженер · инженер-сисадмин · руководитель проекта) |
| Технологический стек | GitLab EE · PostgreSQL · CentOS 7 · AlmaLinux · Ubuntu 24 · Zabbix |
| Сдано | GitLab 18.11.4, PostgreSQL 14.11, ноль потерянных репозиториев за весь период |
Постановка задачи
Студия ведёт десятки клиентских проектов, и весь код живёт в собственном GitLab на отдельном VDS. К моменту нашего захода на поддержку инстанс стоял на версии 15.4.2. Формулировка клиента в трекере: «установлен gitlab, который давно уже не обновлялся. Необходимо обновить его до последней версии, чтобы уменьшить риски взлома».
Запрос простой на словах и неудобный на деле: обновить до последней версии, не останавливая работу. Разработчики пушат каждый день, поэтому любые окна — только после 18:00 по Москве или в выходные, с предупреждением команды.
Что здесь на кону, любой техдиректор понимает без перевода: GitLab — это не сервис, который «полежит и поднимется». Это кодовая база агентства целиком. Прыгать с 15.4 сразу на актуальную версию GitLab не умеет: нужно пройти цепочку обязательных промежуточных релизов. По пути дважды мигрирует PostgreSQL: 12 → 13 → 14. Каждый шаг — это перезапуски, миграции схемы БД и шанс получить инстанс, который больше не стартует. Тестовой копии нет: репетировать негде, ошибаться нельзя.
Как мы это сделали
1. Маршрут вместо прыжка. Сначала разведка: gitlab-rake gitlab:check, сверка с официальным upgrade path, вопросы клиенту про раннеры и интеграции (своих CI-раннеров проект не держал — минус один риск). План зафиксирован в трекере до начала работ: промежуточные точки 15.4.6 → 15.11.13 → 16.x → 17.2.1, миграции PostgreSQL на заранее известных шагах. Клиент подтвердил объём письменно: «обновляемся до последней доступной версии, включая postgres».
2. Две страховки, не одна. Перед стартом — бэкап встроенным инструментарием GitLab: 12 ГБ, плюс снапшот виртуалки у хостера. Вылезла деталь: в панели хостера нашлась галочка снапшота, но не нашлась кнопка отката. Выяснили это «на берегу», а не в момент аварии. Первый, самый рискованный переход сознательно перенесли на окно побольше: «перестрахуюсь. А то вдруг не апнется». Заодно настроили зеркало пакетов, чтобы обновления ставились без сюрпризов от недоступных репозиториев.
3. Проверка данных глазами клиента на каждом шаге. После каждой ступени мы просили команду проверить то, что важно ей: вход, создание проекта, git pull и push. Инженер честно предупредил, что тоньше всего будет на переходе с 15-й ветки на 16-ю. Ответ клиента после первых ступеней: «жалоб по работе с гитлабом пока ни от кого не было». Простои на перезапусках укладывались в 1–3 минуты, мониторинг фиксировал каждый.
4. Security-патчи — в день выхода, по нашей инициативе. Дальше пошла рутина, и в ней главное — скорость. 17.3.3: задачу завели и закрыли в один день, 0.5 ч. 17.4.2: «критическое. там прям сообщение в гите лезет что срочно обновитесь». Согласовали окно после 18:00, вечером готово, 0.25 ч. 17.7.7: «ибо уязвимости», 0.5 ч. Все три раза клиент не просил: бюро само мониторит анонсы и приходит с готовым предложением. Плановые версии (17.5.1, 17.6.1, 17.7.6) ехали в составе ежемесячных циклов обновления парка.
5. Потолок — письменно, заранее, с вариантами. В марте 2025 инженер зафиксировал прямо в задаче: «ни 17.8 ни 17.9 под 7 центос — нет. когда 17.7.x кончатся — надо будет смотреть в сторону конвертации в 8-9 AlmaLinux или новый сервер подымать». Никакого нагнетания, просто факт с развилкой и временем подумать. В ноябре добавили референс из практики: у другого клиента бюро та же конфигурация, конвертация в Alma с обновлением GitLab заняла 4 часа через 4 обязательные промежуточные точки.
Ночь, когда сервер не вернулся из ребута
Ещё в июле 2024, договариваясь о регламенте обновлений, инженер написал клиенту: «при обновлении всегда есть шанс, что сервер не вернётся из ребута». Поэтому на каждое окно нужен дежурный с доступом к консоли. Полтора года спустя фраза сработала буквально.
Ночь на 29 января 2026, плановое окно ежемесячного обновления. Инженер решает заодно закрыть долг по GitLab: конвертация CentOS 7 → AlmaLinux 8, поверх неё — обновление до актуальной версии. Хронология по чату (время московское):
- 03:29. Мониторинг: главная GitLab не отвечает, «No route to host».
- 03:50. Инженер в чате: «сервер из перезагрузки не вернулся… требуется доступ к консоли или хотя бы скрин». И сразу следом: «дёргать ребуты/ресеты не надо».
- 03:55. Руководитель направления (клиент) уже у консоли: диск заполнен под завязку. Инженер: «я ж смотрел — 20 гиг свободных было», и df из истории команд это подтверждает. Место съела сама конвертация.
- 03:57. Решение: Ctrl-Alt-Del через консоль, без жёсткого ресета.
- 03:58. Сервер поднялся, GitLab отвечает. От первого алерта до восстановления — 29 минут.
Данные целы, конвертация не прошла, GitLab остался на прежней версии. Ежемесячное обновление остальных серверов инженер доделал той же ночью, к 04:22.
А дальше — разбор, и он важнее самой аварии. Клиент резонно спросил: «мы ж не договаривались ещё на конвертацию». Выяснилось, что согласование развалилось на цитировании в чате: инженер спрашивал про обновление GitLab, клиент отвечал «принято, спасибо» на реплику, которую читал как напоминание о ежемесячном цикле. Никто не соврал: стороны прочли один диалог по-разному. Инженер закрыл тему без оправданий: «понял, буду выражаться яснее». Клиент — зеркально: «лучше явно писать, о чём речь». Стоимость урока: 29 минут ночного простоя и 1.5 ч работ. С тех пор рискованные работы называются в чате своими именами, а не угадываются из контекста.
Финал: переезд — силами клиента, сопровождение — наше
Конвертацию на месте после той ночи больше не пробовали: победил вариант с новым сервером. В апреле 2026 команда клиента сама перенесла GitLab на свежий сервер с Ubuntu 24 и обновила его. Это их работа, и мы её себе не приписываем. Показательно другое: за два года совместной эксплуатации клиентская команда насмотрелась на процесс настолько, что провела переезд без нас. Мы продолжили сопровождение уже на новой площадке и в мае 2026 обновили GitLab до 18.11.4 за 0.75 ч, в общем цикле с остальным парком.
Результаты
| Метрика | Значение |
|---|---|
| Версия GitLab | 15.4.2-ee → 18.11.4 |
| PostgreSQL | 12.10 → 14.11 (две миграции по пути) |
| Большая миграция 15.4 → 17.2 | 5 ч работ, плановые окна по 1–3 мин |
| Критические security-патчи | 3 за период, каждый в день выхода, 0.25–0.5 ч |
| Инцидент за два года | 1 (конвертация ОС), восстановление за 29 мин, данные целы |
| Потери репозиториев / данных | 0 — жалоб от разработчиков не зафиксировано ни на одном шаге |
| Трудозатраты на GitLab за весь период | ~10 ч |
Если коротко: система, на которую два года боялись смотреть, прошла через две мажорные версии, две миграции БД, три срочных патча и один честно разобранный отказ — и каждый рабочий день разработчики студии пушили код как обычно.
Процесс
| Фаза | Период | Результат |
|---|---|---|
| Разведка и план миграции | июнь 2024 | upgrade path зафиксирован в трекере, объём согласован письменно |
| Большая миграция 15.4.2 → 17.2.1 | июль 2024 | пройдена ступенями за 5 ч, PostgreSQL 12 → 14, проверки клиентом на каждом шаге |
| Регулярные + срочные обновления | сентябрь 2024 – декабрь 2025 | 17.3.3 → 17.7.7; критические патчи в день выхода; потолок CentOS 7 зафиксирован письменно |
| Инцидент конвертации ОС | январь 2026 | восстановление за 29 мин, разбор коммуникации, отказ от конвертации на месте |
| Переезд на Ubuntu 24 | апрель 2026 | выполнен силами клиента; бюро — сопровождение на новой площадке |
| Текущее состояние | май 2026 | GitLab 18.11.4, в общем цикле ежемесячных обновлений |
Фазы перекрываются с остальной абонентской поддержкой: GitLab — одно из направлений внутри общей абонентки, а не отдельный контракт.
Команда
- Инженер (бюро): большая миграция 15.4 → 17.2, миграции PostgreSQL
- Инженер-сисадмин (бюро): регулярные и срочные обновления, инцидент и восстановление
- Антон Херсун, Xaver Pro — руководитель проекта
Если ваш self-hosted GitLab тоже застрял на версии, которую страшно трогать, — напишите, какая стоит сейчас и на какой ОС. Мы сверим upgrade path, найдём узкие места вроде миграций PostgreSQL и потолка дистрибутива, вернёмся с фиксированной оценкой в часах. Разбор плана обновления бесплатный.