Критичные ссылки не должны зависеть от одного внешнего домена

Симптом

Ссылки на ботов, каналы и пользователей через домен t.me перестали работать. Проблема затронула сразу все места, где этот домен был зашит в генерируемые ссылки.

Контекст

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

Корневая причина

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

Ошибочное предположение

Мы считали, что домен глобального сервиса достаточно надёжен и не исчезнет без предупреждения. На практике даже чужой инфраструктурный компонент, который кажется постоянным, может временно стать недоступным.

Обнаружение

Проблему обнаружили по неработающим ссылкам. Для более раннего обнаружения нужен периодический мониторинг нескольких критичных ботов, каналов и пользовательских ссылок с проверкой не только HTTP-ответа, но и ожидаемого redirect/target.

Исправление

Ссылки быстро переключили на доступный альтернативный домен Telegram. Это восстановило работоспособность без изменения самих Telegram-ресурсов.

Проверка

Регрессионная проверка должна:

• проверять, что генератор использует управляемый redirect URL, а не внешний домен напрямую;
• регулярно открывать несколько критичных ссылок;
• проверять, что при смене конечного домена старые ссылки продолжают вести к нужному ресурсу.

Общий вывод

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