Деактивация организации на SaaS-платформе не должна сводиться к изменению поля вроде active = false. Такое изменение может скрыть учетную запись в интерфейсе, но при этом пользователи сохранят действующие сеансы, интеграция продолжит отправлять данные, а задача в очереди — изменять ресурсы. Чтобы надежно деактивировать учетную запись организации в SaaS-приложении на PHP, нужно определить значение каждого статуса и скоординировать действия с идентификацией, процессами и данными.
Цель — получить результат операции, который можно проверить, и обеспечить возможность продолжить ее после сбоя на полпути, не дублируя эффекты и не оставляя несогласованных разрешений. Для этого нужно продумать как жизненный цикл, так и процедуры выполнения и восстановления.
Разделите приостановку, закрытие и удаление
Эти термины обозначают разные решения. Приостановка обычно носит временный характер: она блокирует определенные операции, сохраняя организацию для возможной повторной активации. Закрытие означает прекращение операционных отношений и может включать отзыв доступов и отмену задач. Удаление затрагивает данные и должно соответствовать правилам хранения, юридическим обязательствам и политикам продукта.
Не следует использовать один индикатор для обозначения всех трех ситуаций. Явная модель может включать такие статусы, как active, suspending, suspended, closing, closed и deletion_pending. Конкретные названия зависят от продукта; важно, чтобы у каждого статуса были определенное значение, условия перехода в него и разрешенные операции.
- Приостановка: запретить новые бизнес-операции, сохранив данные и возможность выполнять необходимые административные действия.
- Закрытие: остановить обычную деятельность, аннулировать доступы и завершить задачи по закрытию.
- Удаление: удалить или анонимизировать данные в соответствии с заданной политикой, а не как неявное следствие приостановки.
Смоделируйте переходы и разрешения
Определите конечный автомат или эквивалентные правила переходов. Например, активная организация может перейти в состояние приостановки; запрос на закрытие может инициировать состояние closing; и только после необходимых проверок организация переходит в состояние closed. Если переход запрещен, приложение должно отклонить его, указав понятную причину, которую можно зарегистрировать.
При проверке авторизации на сервере нужно учитывать статус организации наряду с ролями пользователя. Скрытие кнопок в интерфейсе не отзывает разрешения. В PHP-приложении централизуйте эту логику в доменных сервисах, middleware или повторно используемых политиках, а не полагайтесь на разрозненные проверки в контроллерах.
Уточните, какие действия разрешены на каждом этапе. Например, во время closing можно разрешить экспорт данных и просмотр счетов, но запретить создание пользователей, запуск бизнес-процессов и изменение интеграций. Такое соглашение не позволит разным компонентам по-разному трактовать понятие «деактивирована».
Отзовите доступы, сеансы и учетные данные
Закрытие должно охватывать все связанные с организацией способы доступа: веб-сеансы, API-токены, сервисные ключи, ожидающие приглашения, учетные данные OAuth и делегированные доступы. Определите, где они выдаются и как их аннулировать. Даже не принятое приглашение может предоставить доступ в будущем, поэтому его нужно отменить или сделать недействительным.
Способ отзыва сеанса зависит от механизма управления им. Если система хранит сеансы на сервере, их можно аннулировать напрямую; если используются самодостаточные токены, может потребоваться проверять статус организации при каждом запросе, использовать список отзыва или установить короткий срок действия токенов. Подходящий вариант зависит от уровня риска и требований к производительности, однако статус закрытия должен иметь приоритет над еще не истекшим токеном.
Учитывайте также пользователей, состоящих в нескольких организациях. Деактивация компании не должна автоматически блокировать их личную учетную запись или законный доступ к другим клиентам. Контроль следует применять в контексте организации и с учетом фактических разрешений для каждого запроса.
Остановите очереди, вебхуки и интеграции
Изменение статуса в базе данных само по себе не отменяет уже поставленные в очередь задачи. Проверьте обработчики очередей, запланированные задачи, процессы импорта и экспорта, синхронизации и уведомления. Перед выполнением действия каждый обработчик должен проверять, разрешена ли организации соответствующая операция. Если нужно, отбросьте или отмените ожидающие задачи и зарегистрируйте те, которые остановить не удалось.
Для исходящих вебхуков определите, нужно ли доставлять, отменять или сохранять для аудита уже созданные события. Для входящих интеграций отключите учетные данные и отклоняйте новые запросы, даже если внешний провайдер еще не получил уведомление о закрытии. Не полагайтесь на то, что третья сторона вовремя завершит отключение.
В распределенных системах не следует считать эти действия и обновление базы данных одной атомарной транзакцией. Используйте контролируемую последовательность и, если это уместно, транзакционный паттерн outbox для публикации событий изменения статуса. Обеспечьте, чтобы обработчики выдерживали повторную доставку сообщений благодаря идемпотентным операциям.
Сделайте процесс отключения возобновляемым и поддающимся аудиту
Представьте отключение как операцию с идентификатором, датой начала, инициатором, при необходимости причиной, версией процесса и результатами каждого этапа. Возможные этапы: блокировка операций, отзыв учетных данных, отмена задач, уведомление интеграций и выполнение проверок. Регистрируйте статусы — ожидает выполнения, завершено или завершилось ошибкой — вместе с данными, полезными для диагностики, не сохраняя секреты и ненужные персональные данные.
Если этап завершился ошибкой, система должна позволять повторить его без вредных побочных эффектов. Например, повторный отзыв уже отозванных учетных данных должен быть безопасной операцией. Различайте временные ошибки, после которых можно повторить попытку, и ошибки, требующие вмешательства. Не отмечайте закрытие как завершенное только потому, что асинхронная задача была запущена.
Кроме того, определите, что означает повторная активация. Приостановку можно отменить, восстановив разрешенные операции, но повторная активация закрытой организации не должна автоматически создавать заново удаленные учетные данные или восстанавливать отмененные задачи. Политика должна указывать, что восстанавливается, для чего требуется действие администратора и что уже нельзя отменить.
Определите судьбу данных
Перед удалением данных определите, какие записи зависят только от организации, какие нужно сохранить по операционным или юридическим причинам и какие относятся к общей информации. Уточните порядок обработки документов, журналов аудита, счетов, резервных копий и данных, хранящихся у внешних провайдеров. Удаление учетной записи не обязательно означает, что все копии исчезнут немедленно; разъясните применимые правила и не обещайте сроки, которые система не может гарантировать.
Если удаление выполняется асинхронно, используйте явные статусы, например deletion_pending и deleted, и регистрируйте результат для каждой категории данных. При анонимизации убедитесь, что процедура исключает разумную возможность повторной идентификации и не нарушает ссылки, которые необходимо сохранить. Решение должно соответствовать обязательствам и политикам, применимым к продукту.
Проверьте и протестируйте всю операцию
Завершение отключения должно подтверждаться проверками, а не только сообщением об успехе. Убедитесь, что для организации недоступны заблокированные операции, предусмотренные учетные данные больше не работают, приглашения аннулированы и несовместимые задачи не продолжают выполняться. Также проверьте состояние интеграций и исключения, требующие дальнейшего контроля.
Добавьте автоматизированные и операционные тесты для характерных ситуаций:
- Повторные запросы на приостановку или закрытие, которые не должны приводить к дублированию эффектов.
- Сбой после отзыва доступов, но до остановки интеграции.
- Повторная попытка после сетевой ошибки или неудачного ответа провайдера.
- Повторная активация приостановленной организации и ограничения для закрытой учетной записи.
- Пользователи, активные в нескольких организациях, и задачи в очереди, запущенные до изменения статуса.
Наблюдаемый контрольный список вместе с метриками ожидающих и завершившихся ошибкой операций помогает обнаруживать зависшие процессы закрытия. Главное — рассматривать отключение как бизнес-процесс с определенными статусами, разрешениями и последствиями. Тогда деактивация учетной записи организации в SaaS-приложении на PHP перестанет быть изолированным изменением и станет контролируемым, восстанавливаемым и согласованным переходом для всех компонентов.
