Jira и Confluence отключили: что поднять у себя за выходные

MAATRIX

Пятница, вечер, и выясняется, что доступ к Jira и Confluence пропал — аккаунт заблокирован, оплата не проходит, или сервис просто перестал открываться из России. Задачи, спринты, вся база знаний команды заперты внутри чужого облака, а в понедельник людям всё равно нужно понимать, что делать и где смотреть документацию. Паниковать не о чем: за выходные вполне реально поднять рабочую замену на своём сервере — не идеальную копию Atlassian, но достаточную, чтобы команда не встала. Ниже — как выбрать инструмент под дедлайн, что реально получится перенести и пошаговый план на два дня.

Что делать в первые часы, до выбора инструмента

Прежде чем ставить что угодно, потратьте 30–40 минут на трезвую оценку ситуации — это сэкономит весь остальной день.

Проверьте, что у вас реально есть:

• Экспорт данных. Если кто-то заранее сделал экспорт проектов из Jira (XML/CSV по каждому проекту) и экспорт пространств из Confluence (HTML/XML-архив) — это меняет всё: вы переносите историю, а не начинаете с нуля. Проверьте общие папки, диски админов, почту — экспорт мог остаться у кого-то локально.
• Доступ хоть к какому-то read-режиму. Иногда аккаунт заблокирован для новых действий, но старые вкладки в браузерах ещё показывают данные, или жив API-токен. Если так — соберите скриншоты активных досок и текстовые копии ключевых страниц wiki, пока доступ не пропал совсем. Это не замена нормальному экспорту, но лучше, чем ничего.
• Список того, что критично именно в понедельник. Не пытайтесь восстановить всю историю тикетов за три года. Выпишите: активные задачи текущего спринта, runbook'и из wiki, без которых встанет продакшн, процессы, которые люди держат в голове только потому, что «это же написано в Confluence».

Если экспорта и доступа нет — не тратьте выходные на попытки вернуть их в обход официальной поддержки. Параллельно с восстановлением доступа поднимайте систему с чистого листа: активные задачи восстановите по памяти команды на короткой встрече в понедельник, а вот сидеть без трекера и wiki неделями — куда дороже. Заодно стоит честно прикинуть, во что обходилась подписка и во что обойдётся своё решение на дистанции — об этом отдельный разбор: своя Jira или облачная подписка, где ломается экономика.

Трекер задач вместо Jira: что реально поднять за выходные

Экосистема open source трекеров задач выросла настолько, что для большинства команд среднего размера подобрать замену — вопрос дня, а не месяца. Разница между вариантами не в «умеет/не умеет», а в том, сколько времени уйдёт на разворачивание и насколько интерфейс похож на привычный.

Практический вывод: если команда пришла именно из Jira и важно видеть похожий интерфейс с эпиками, спринтами и статусами — берите OpenProject или Taiga, у обоих есть хоть какой-то путь импорта. Если критична скорость разворачивания, а перенос данных вы готовы делать вручную — быстрее всего поднимается Vikunja. Пошаговая установка на Ubuntu 24.04 разобрана отдельно, конфиг проверен: OpenProject на Ubuntu 24.04.

Ни один из этих инструментов не станет Jira один в один: кастомные поля, специфичные workflow, интеграции с плагинами Atlassian Marketplace придётся либо урезать, либо настраивать заново руками. За выходные вы поднимаете рабочий минимум, и это нормально — цель на понедельник не «идентично Jira», а «команда может ставить и закрывать задачи».

Wiki вместо Confluence: аналогичный выбор

С базой знаний логика похожая, но цена потери выше: в Confluence обычно лежат runbook'и, схемы архитектуры, онбординг новых сотрудников, а иногда и доступы к инфраструктуре (в идеале — в отдельном менеджере паролей, но по факту нередко и там). Потеря этого болезненнее потери спринт-борда — люди физически не вспомнят треть содержимого по памяти.

Если данных для переноса почти нет, а нужен минимальный работающий wiki уже сегодня вечером — DokuWiki выигрывает по скорости именно потому, что не требует базы данных: распаковали архив, настроили веб-сервер, страницы создаются через браузер сразу. Если на руках HTML-экспорт Confluence и есть пара часов на чистку разметки — Wiki.js или Outline дадут более удобный долгосрочный результат. Подробный разбор установки: Outline Wiki на Ubuntu 24.04.

Критерии быстрого выбора под срочную ситуацию

Когда решение нужно принять за час, а не после недели пилотов, помогает не сравнение фич по табличке маркетинга, а три вопроса по порядку.

1. Сколько у вас реально есть на разворачивание? Если на весь проект — вечер пятницы и часть субботы, откажитесь от вариантов, требующих отдельного OAuth-провайдера, внешнего email-сервера для приглашений и тонкой настройки прав доступа. Простой Docker Compose с одной командой docker compose up -d — то, что реально запускается за 20–30 минут вместе с чтением документации.
2. Есть ли что импортировать? Если экспорт из Jira/Confluence на руках — выбирайте инструмент с хоть каким-то путём импорта (OpenProject/Taiga для трекера, Wiki.js/Outline для wiki), даже если это не «нажал одну кнопку», а получасовой скрипт-конвертер. Если экспорта нет вообще — приоритет смещается в сторону максимально быстрого старта (Vikunja, DokuWiki), потому что переносить всё равно нечего, значит, важнее скорость первого запуска, а не качество импортёра.
3. Что команда сможет освоить за выходные без обучения? Инструмент, максимально похожий по структуре на привычный (доски и спринты для трекера, дерево страниц для wiki), снижает сопротивление в понедельник утром. Экзотичный, пусть и более мощный, инструмент, где всем придётся учиться заново — плохой выбор именно в срочной ситуации, даже если в спокойной обстановке он был бы лучше.

Отдельно взвесьте ресурсы сервера, на котором будете поднимать оба сервиса. OpenProject и Taiga заметно тяжелее по потреблению памяти, чем Vikunja или DokuWiki, за счёт числа контейнеров (приложение, база данных, очередь задач, иногда Redis) — если сервер слабый, лёгкая связка Vikunja + DokuWiki на одной VPS отработает надёжнее, чем OpenProject + Outline, которым тесно на минимальной конфигурации.

Импорт данных: что перенесётся, а что придётся руками

Здесь стоит быть честным: даже при наличии официального экспорта из Jira и Confluence, полный автоматический перенос в open source аналог — редкость. Разумные ожидания такие:

Из Jira обычно переносится без проблем: список задач (заголовок, описание, статус на момент экспорта, автор), разбивка по проектам/эпикам — с ручной перепроверкой соответствия статусов, потому что workflow в новой системе почти наверняка отличается.

Из Jira обычно теряется или требует доработки: полная история переходов между статусами и комментариев с точными таймстампами; кастомные поля и связи между задачами (blocks/is blocked by) — часто восстанавливаются руками только для критичных задач; вложения — нередко переносятся отдельным архивом, который приходится прикреплять к задачам вручную.

Из Confluence переносится с ручной чисткой: текст страниц — при экспорте в HTML/XML разметка почти всегда «плывёт», макросы Confluence (панели, вставки Jira-фильтров) не имеют прямого аналога; иерархия страниц сохраняется, но порядок и вложенность стоит проверить глазами; картинки и файлы обычно экспортируются отдельно и требуют повторной загрузки.

Практический совет: не пытайтесь автоматизировать перенос на 100% в первый же день. Импортируйте то, что переносится программно, а критичные документы (runbook'и по инцидентам, актуальные архитектурные схемы) перепишите руками в первую очередь — их немного, а качество важнее скорости. Остальное донесёте постепенно в течение недели. Если регулярных экспортов и бэкапов данных из SaaS у вас не было в принципе — это тот урок, который стоит закрепить процессом на будущее, а не только разовым спасением.

План действий на выходные: от выбора инструмента до рабочего понедельника

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

Пятница вечер (1–2 часа):

• Соберите всё, что есть по экспорту данных и доступам (см. первый раздел).
• Определитесь с парой инструментов (трекер + wiki) по таблицам выше, исходя из наличия экспорта и мощности сервера.
• Закажите/подготовьте сервер, если его ещё нет: для связки трекер + wiki на команду до 30–40 человек обычно хватает машины среднего уровня с SSD, точный объём CPU/RAM зависит от выбранной пары инструментов.

Суббота утро (2–4 часа): поднимаем трекер

• Разворачиваете выбранный трекер через Docker Compose по готовому конфигу.
• Создаёте организацию, базовую структуру проектов под текущие активные задачи (не всю историю — только то, что нужно в понедельник).
• Заводите пользователей команды, проверяете вход и создание задачи у второго человека, не только у себя — это ловит проблемы с сетью и DNS раньше, чем в понедельник при живой нагрузке.

Суббота день (2–3 часа): импорт данных трекера

• Если есть экспорт из Jira — прогоняете через импортёр выбранной системы, начиная с одного тестового проекта.
• Проверяете результат вручную: статусы, исполнители, критичные связи между задачами.
• Вносите руками то, что важно, но не перенеслось: актуальные приоритеты, что в работе прямо сейчас.

Воскресенье утро (2–3 часа): поднимаем wiki

• Разворачиваете выбранную wiki-систему.
• Переносите не всё подряд, а короткий список критичного: runbook'и по инцидентам, доступы к инфраструктуре (если хранились там), инструкции по деплою, онбординг.
• Настраиваете права доступа хотя бы на базовом уровне (кто редактирует, кто только читает) — проще сделать сразу, чем чинить постфактум.

Воскресенье день (1–2 часа): проверка и коммуникация с командой

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

Если есть сервер под другие задачи со свободными ресурсами — можно временно подселить трекер и wiki туда, но для системы, которая проживёт дольше пары недель, лучше сразу выделить отдельный сервер: меньше риска, что чужая нагрузка положит и продакшн, и единственный источник знаний команды разом. Общий подход к планированию такого переезда описан в материале как составить план миграции на новый сервер — часть шагов оттуда применима и здесь, просто в сжатые сроки.

Частые вопросы