Куча людей перешли на искусственный интеллект, так и не освоив собственный.
Мне нравится, даже при наличии ЛЛМ, думать самостоятельно.
Не из принципа "ебаать, я не такой, как все", а потому что это чуть ли не единственный тренажёр для мозга, оставшийся при нынешней пониженной нагрузке на инженера.
И у этого тренажёра есть техника: не искать готовый ответ, а раскладывать вопрос на слои, пока каждый слой не станет проверяемым.
Вот как это у меня выглядит на практике.
Пример.
Есть AD-сервис, допустим MS Entra. Есть AWS и сервисы внутри него. У какого-то сервиса - пусть OpenSearch, не важно, хоть Redis - по дефолту ебанутое имя типа:
- dkjfh-hui-izda-dgigkhurda-aws.account.region.amazonaws.com
Через Entra-приложение настроили SSO.
Всё работает: люди ходят на некрасивый урл, логинятся через проклятый майкрософтовский аккаунт, все счастливы.
Усложняем.
Разработчики захотели красивые адреса - для UI и CLI-агентов.
Задача: добавить в Route53 (или другой DNS сервис)
- logs-prod.domain.com
- redis-stage.domain.com
Почему - да без разницы, просто захотели.
И вот тут вместо того, чтобы спросить ЛЛМ "как правильно", я по очереди раскладываю задачу на слои - каждый следующий вопрос вытекает из ответа на предыдущий, а не из общей интуиции "SSO - это сложно".
- DNS. Просто добавить запись - заработает? По идее нет: нового адреса нет в списке разрешённых redirect URI в Entra, он отвалится с ошибкой мисматча. И это не хардкод где-то в коде, а обычный allowlist.
- Коллбек vs UI. Это одно и то же? Нет, вроде разные слои. UI-адрес - то, что видит браузер. Коллбек - то, куда Entra шлёт ответ после логина. Можно спокойно жить на новом UI-адресе, а коллбек временно оставить на старом.
- Что я поломаю нахуй самим добавлением. Само добавление DNS-записи - ничего. Ломает либо снос старой записи/старого redirect URI сразу, либо TLS: у AWS managed сервиса сертификат зашит под их дефолтный домен, левый CNAME туда просто не пройдёт проверку сертификата без прокладки сверху (ALB, CloudFront - что угодно со своим сертификатом на новый домен).
- Алиасы в Entra. Redirect URIs / Reply URLs - это список, в него добавляют, а не заменяют существующее. А если это SAML, появляется третий слой - Audience/Entity ID, и с ним уже не всегда так просто: не каждый SP умеет несколько audience одновременно. Умеет ли ентра?
- А может, сразу дропнуть старое и переехать целиком? Ну уж нет. Это же чисто flag day cutover на SSO - способ уронить логин всем разом, если хоть один слой не совпал.
- Где реально терминируется сертификат. Что если вместо Route53 - Cloudflare: как быть с прокси и эджем, что если это Cloudflare ACM. Здесь я сознательно не даю себе ответа - это уже вопрос конкретной архитектуры, а не общей логики разбора.
- А может у AWS есть custom URL фича для этого сервиса и ничего выдумывать не надо?
Обычно у меня нет прямого ответа на вопрос, как и задачи такой, ведь всё это лишь размышления.
Зато есть метод, который я в процессе применяю: не спрашивать "заработает или нет", а спрашивать самого себя "какие независимые системы должны согласиться друг с другом, чтобы это заработало" - и проверять их по одной. DNS, TLS, redirect URI, SAML audience и порядок отключения старого - это разные системы, которые нужно свести по отдельности, а не одна абстрактная "настройка SSO".
Вот это разложение на слои и есть то, что деградирует, когда думать за тебя начинает модель.
Факты модель знает лучше меня. Определённо.
А привычку резать проблему на проверяемые куски - тренирует только ручная работа.