Opsgenie End of Life: отключение в 2027 году и альтернативы

Содержание

• Сроки прекращения поддержки Opsgenie
• Что перестанет работать после 5 апреля 2027 года?
• Официальная замена: Jira Service Management
• Когда лёгкая альтернатива Opsgenie имеет смысл
• Как обкатать Echobell до отключения Opsgenie
• 1. Выберите один критический источник оповещений
• 2. Создайте канал в Echobell
• 3. Добавьте второе назначение для вебхука
• 4. Осознанно распределите уровни срочности
• 5. Проведите оба пути через реальное дежурство
• 6. Зафиксируйте, что Echobell не заменяет
• Чек-лист миграции с Opsgenie
• Часто задаваемые вопросы
• Opsgenie действительно закрывают?
• Что приходит на смену Opsgenie?
• Может ли Echobell полностью заменить Opsgenie?
• Можно ли использовать Echobell во время миграции с Opsgenie?
• Когда начинать миграцию?
• Выберите минимальную замену, которая закрывает реальную задачу

Opsgenie отключат 5 апреля 2027 года. После этой даты продукт станет недоступен, его интеграции и REST API перестанут работать, а не перенесённые данные клиентов будут удалены.

Для большинства команд официальный путь Atlassian — переход на Jira Service Management — остаётся самой безопасной полноценной заменой. Но если вы используете Opsgenie в основном для того, чтобы превращать события мониторинга в срочные мобильные оповещения, это удобный момент решить, нужна ли вам целая платформа управления инцидентами или достаточно небольшого слоя уведомлений.

В этом руководстве разобраны сроки, предстоящие изменения и то, как выбрать путь миграции, не оставив пробела в покрытии дежурств.

Сроки прекращения поддержки Opsgenie

Действующие клиенты могут пользоваться Opsgenie до даты отключения, но откладывать переход до последних недель — это лишний риск. Atlassian рекомендует завершить переход до 5 апреля 2027 года. Актуальные сроки смотрите на официальной странице миграции Opsgenie и в FAQ по лицензированию Opsgenie.

Что перестанет работать после 5 апреля 2027 года?

После отключения Opsgenie команды теряют доступ к продукту и ко всем процессам, которые всё ещё на нём завязаны. В том числе:

• Оповещения Opsgenie и процессы дежурств
• Мобильное приложение Opsgenie
• Оставшиеся интеграции Opsgenie
• Эндпоинты REST API Opsgenie
• Данные и конфигурации, которые не были перенесены

Отключение затрагивает не только веб-панель. Система мониторинга может и дальше фиксировать сбой, а старая интеграция с Opsgenie при этом молча превратится в тупик. В руководстве Atlassian о том, что произойдёт после отключения Opsgenie, рекомендуется в первую очередь переносить все процессы оповещений и дежурств.

Официальная замена: Jira Service Management

Jira Service Management — выбор по умолчанию, когда нужно сохранить всю операционную модель Opsgenie: оповещения, графики дежурств, политики эскалации, процессы работы с инцидентами и историю.

Владельцы Opsgenie могут открыть Settings → Plan your move, чтобы увидеть рекомендованный тариф Jira Service Management и запланировать миграцию. По словам Atlassian, после выбора и подтверждения целевого тарифа большую часть данных и конфигураций Opsgenie можно синхронизировать автоматически.

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

Одно важное ограничение: встроенный инструмент миграции поддерживает цели в Atlassian Cloud, но не Jira Service Management Data Center. Командам, которые остаются на Data Center, нужно искать другой путь, а не рассчитывать на прямую миграцию. Atlassian описывает это ограничение в руководстве по планированию миграции.

Когда лёгкая альтернатива Opsgenie имеет смысл

Не в каждом аккаунте Opsgenie используются ротации, деревья эскалаций, таймлайны инцидентов и аналитика. Некоторые небольшие команды решают с его помощью более узкую задачу:

1. Система мониторинга фиксирует критическое событие.
2. Интеграция передаёт это событие дальше.
3. Телефон шумит достаточно, чтобы кто-то отреагировал.

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

Echobell — не полноценная замена Opsgenie один в один. Он не заменяет продвинутое планирование дежурств, политики эскалации, управление ходом инцидента и отчётность по его итогам. Для этих процессов используйте Jira Service Management или другую полноценную платформу управления инцидентами.

Echobell подойдёт, если:

• Источник мониторинга уже сам решает, какие события критические.
• Дежурство делит небольшая и стабильная группа людей.
• Вам нужна прямая доставка с вебхука на телефон без перестройки мониторинга.
• Для критических, предупреждающих и информационных событий нужны разные уровни срочности.
• Вы хотите обкатать доставку оповещений отдельно, до изменения остального стека.

Подробное сравнение по возможностям — в материале Echobell и Opsgenie.

Как обкатать Echobell до отключения Opsgenie

Самая безопасная миграция — параллельный тест, а не разовое переключение в день дедлайна.

1. Выберите один критический источник оповещений

Начните с продакшн-сервиса, у которого есть явный ответственный и предсказуемый объём оповещений. Не переносите все интеграции разом.

2. Создайте канал в Echobell

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

3. Добавьте второе назначение для вебхука

Оставьте существующий путь через Opsgenie активным и добавьте в источнике мониторинга вебхук канала Echobell. Простой тестовый payload выглядит так:

curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Production API is down",
    "body": "Health check failed in us-east-1",
    "severity": "critical",
    "externalLink": "https://status.example.com/incidents/123"
  }'

В скриптах и менеджерах секретов используйте плейсхолдер вместо токена и не коммитьте реальный webhook-URL канала в систему контроля версий. Документация по вебхукам описывает переменные payload и шаблоны.

Если источник умеет отправлять email, но не поддерживает вебхуки, используйте триггер по email.

4. Осознанно распределите уровни срочности

Оставьте звонковые оповещения для событий, которые требуют немедленной реакции. Срочные оповещения используйте для важных предупреждений, а обычные уведомления — для информационных событий. Так срочный канал сохраняет доверие, а не воспроизводит усталость от оповещений в новом приложении.

5. Проведите оба пути через реальное дежурство

Сравните время доставки, понятность сообщений, ложные срабатывания и поведение дежурных. Проверьте и уведомления о восстановлении, а не только о сбоях.

6. Зафиксируйте, что Echobell не заменяет

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

Чек-лист миграции с Opsgenie

Пройдите этот чек-лист до отключения 5 апреля 2027 года:

• Составьте перечень всех входящих интеграций, heartbeat-проверок, API-клиентов и email-интеграций.
• Экспортируйте или перенесите исторические данные, которые команда обязана сохранить.
• Зафиксируйте графики дежурств, политики эскалации, правила уведомлений и зоны ответственности.
• Определите снятые с поддержки функции и интеграции, которые придётся заменять вручную.
• Обновите скрипты, обращающиеся к эндпоинтам opsgenie.com или opsgenie.net.
• Протестируйте оповещения, восстановления, подтверждения и доставку в нерабочее время.
• Держите старый и новый пути параллельно хотя бы один показательный цикл дежурства.
• Убирайте старый путь только после того, как дежурные подтвердят, что замена работает.

Часто задаваемые вопросы

Opsgenie действительно закрывают?

Да. Продажи прекратились 4 июня 2025 года, а 5 апреля 2027 года заканчивается поддержка Opsgenie. По заявлению Atlassian, после этого продукт отключат и он станет недоступен.

Что приходит на смену Opsgenie?

Официальный путь замены от Atlassian — Jira Service Management: именно туда переносят возможности Opsgenie по оповещениям и дежурствам. Какая альтернатива подойдёт вам, зависит от того, нужно ли команде полноценное управление инцидентами или только надёжная доставка оповещений.

Может ли Echobell полностью заменить Opsgenie?

Нет. Echobell заменяет слой срочных мобильных уведомлений в подходящих для этого процессах. Он не воспроизводит графики дежурств, деревья эскалаций, процессы управления инцидентами и отчётность Opsgenie.

Можно ли использовать Echobell во время миграции с Opsgenie?

Да. Направьте один источник оповещений сразу в оба назначения, проверьте доставку на реальном цикле дежурства и не отключайте Opsgenie, пока новый путь не докажет свою работоспособность.

Когда начинать миграцию?

Инвентаризацию и пилот стоит начать уже сейчас. Итоговая дата миграции зависит от количества интеграций, требований комплаенса и от того, переходите ли вы на Jira Service Management или перестраиваете стек оповещений.

Выберите минимальную замену, которая закрывает реальную задачу

Отключение Opsgenie задаёт жёсткий срок, но это не значит, что всем командам нужна одна и та же замена.

Выбирайте Jira Service Management, если Opsgenie у вас — полноценная система дежурств и управления инцидентами. Присмотритесь к специализированному слою доставки, если логика маршрутизации уже заложена в мониторинге, а основная задача — быстро довести критическое событие до нужных телефонов.

Скачайте Echobell для iPhone или загрузите из Google Play, а затем протестируйте одно продакшн-оповещение, пока текущий маршрут через Opsgenie ещё активен.