Применимость: Cloud. Названия пунктов и доступность функций зависят от версии, плана и типа проекта. Проверяйте изменения на тестовом окружении. Описанные рабочие процедуры — предлагаемый подход, а не гарантии поставщика.
Сначала разберитесь с организацией
Компания хочет централизованно управлять Atlassian-аккаунтами с корпоративной почтой. До изменения DNS определите нужную организацию Atlassian, её администраторов и владельца домена. У одного бизнеса могут быть несколько организаций после приобретений или отдельных пилотов. Ошибка выбора затронет не только текущий проект Jira. Получите согласование на управление аккаунтами и составьте список ответственных за инфраструктуру, идентификацию и поддержку. Подтверждение домена и назначение доступа к конкретному приложению решают разные задачи. Не обещайте сотрудникам, что одна DNS-запись автоматически настроит все роли, синхронизацию и вход во всех системах.
Проведите инвентаризацию до claim
Официальная процедура Atlassian различает подтверждение владения доменом и последующее принятие аккаунтов под управление организации. До принятия изучите доступный экспорт учётных записей: могут обнаружиться аккаунты, созданные сотрудниками для других рабочих задач. Сопоставьте адреса с действующим кадровым справочником и ответственными за интеграции. Не деактивируйте неизвестные записи автоматически. Среди них могут быть владельцы важных ресурсов или используемые технические идентичности. Согласуйте порядок разбора совпадений и уведомление пользователей. Экспорт содержит персональные сведения, поэтому храните его в ограниченном месте, удаляя рабочие копии по принятому регламенту.
Выберите поддерживаемый способ проверки
Atlassian описывает подтверждение через DNS TXT и HTTPS-файл, а также варианты с подключёнными провайдерами идентификации. Для DNS запросите точное значение из панели организации и передайте его владельцу зоны. Не заменяйте существующие TXT-записи вслепую: в той же зоне могут находиться другие проверки и почтовые политики. Для HTTPS нужен корректный сертификат и размещение файла по требуемому адресу. Выберите метод, который инфраструктурная команда сможет поддерживать после завершения проекта. В рабочей инструкции сохраните назначение записи или файла, организацию и владельца, чтобы очередная очистка сайта не удалила проверку как ненужный артефакт.
Проверьте инфраструктуру и выполните подтверждение
Для DNS сначала убедитесь, что значение опубликовано на авторитетных серверах и доступно снаружи. Учитывайте время распространения изменений и не добавляйте несколько разных значений в попытке ускорить результат. В панели Atlassian выполните проверку домена и прочитайте фактический статус. Для HTTPS проверьте внешний URL, сертификат и содержимое файла без корпоративной авторизации. Ошибки перенаправления диагностируйте по правилам официальной процедуры. Сохраните время и результат проверки в заявке на изменение. После подтверждения не удаляйте технический признак: Atlassian периодически проверяет сохранение владения, и его потеря может повлиять на управление аккаунтами.
Проводите изменения политики отдельно
После инвентаризации выполните согласованное принятие аккаунтов и проверьте небольшой набор пользователей из разных команд. Если дальше планируется изменение аутентификации, оформите его отдельным этапом с пилотом, поддержкой и аварийным доступом. Не включайте одновременно новую политику входа, синхронизацию групп и массовую смену доступа к приложениям. Такое объединение осложняет поиск причины отказов. Доступность конкретных механизмов зависит от конфигурации организации; проверьте её перед обещанием функциональности. Подготовьте коммуникацию: что меняется для сотрудника, когда это произойдёт и как обратиться за помощью, если вход перестал работать.
Определите безопасную остановку
Если обнаружена неверная организация или неожиданный набор аккаунтов, остановитесь до массового принятия и подключите владельцев управления идентификацией. Не используйте удаление DNS-проверки как универсальную кнопку отката. Последствия такого действия отличаются от отмены выдачи доступа и могут затронуть политики. Для возврата применяйте подтверждённый сценарий вашей организации и при необходимости обращайтесь в поддержку Atlassian. После внедрения настройте контроль сохранения проверки домена и резервного административного доступа. Перед передачей проекта убедитесь, что эксплуатация знает назначение TXT-записи или HTTPS-файла и порядок действий при изменении домена либо хостинга.
Контрольная карта передачи эксплуатации
Перед завершением проекта подготовьте карточку домена: организация, администраторы, метод проверки, владелец DNS или сайта и место хранения заявки. Сам проверочный признак храните согласно внутренней политике, не рассылая его по случайным каналам. Попросите эксплуатацию объяснить, что произойдёт при переносе зоны или обновлении веб-сервера. Если команда считает файл временным, документация передачи ещё недостаточна. Включите проверку сохранения признака владения в план инфраструктурных изменений, которые затрагивают домен. Отдельно согласуйте действия при увольнении администратора организации и способ восстановления ответственного контакта. Проведите настольное упражнение: после переноса сайта статус домена изменился, кто замечает проблему и кому передаёт заявку. Результатом должны быть понятные роли и последовательность диагностики. Не проверяйте аварийный сценарий удалением действующей записи на производственном домене без отдельного согласованного плана.
Официальная документация
Применить это к вашей системе
Обсудим контекст, ограничения и безопасный порядок изменений.
Обсудить задачу