Экспресс-курс · No. 39
Приходишь в американскую компанию на несколько тысяч человек — и каждый день слышишь одни и те же имена: Azure, Entra, Okta, Snowflake, Databricks, Fabric. Звучит как шесть разных миров. На деле это три слоя: где работает код, кого пускают внутрь и где лежат данные компании. Курс простыми словами объясняет каждую систему, а потом показывает, как ИИ-агент подключается ко всем сразу — и не пугает команду безопасности.
42 понятия · схема у каждого · актуально на октябрь 2026 · шпаргалка в конце
Шесть названий продуктов, три работы. Прежде чем лезть в детали, пойми, к какому слою относится каждая система и где между ними сидит твой ИИ-проект.
Карта: 42 понятия в восьми главах
Карта метро: сначала видишь линии целиком, потом едешь по станциям.
Курс идёт по трём слоям. Сначала облако — Microsoft Azure, где работает твой код и модели компании. Потом идентичность — Microsoft Entra ID и Okta: они решают, кто может войти и что ему можно трогать. Потом данные — Snowflake, Databricks и Microsoft Fabric, где компания держит цифры продаж, финансов и CRM. Последняя глава собирает всё вместе: как ИИ-агенту получить минимально возможный доступ, пройти security review у клиента и не ждать роль три недели.
Как читать этот курс
Паспорт: у всех одни и те же поля, поэтому их легко сравнивать.
У каждого понятия есть английское название (это слово ты услышишь на созвонах и прочитаешь в документации), образ из жизни, схема и карточка: что это, пример, подвох и связи с другими понятиями. Если знаешь Google Cloud, ты будешь снова и снова узнавать знакомое: большинство корпоративных систем — привычные идеи под другими именами. Названия продуктов здесь меняются часто — Azure AD стал Entra ID, Azure AI Foundry стал Microsoft Foundry, Vector Search стал AI Search, — поэтому курс даёт и старое имя. У клиента ты услышишь оба.
Enterprise Stack — три слоя и проект посередине
Офисное здание: этажи принадлежат арендодателю (облако), охрана в лобби проверяет пропуска (идентичность), а архив в подвале хранит все записи (данные). Новому арендатору — ИИ-приложению — нужны все три.
В каждой большой компании одни и те же три слоя. Облако — где работает код; в компании, которая живёт на Microsoft, обычно это Azure. Идентичность — справочник людей компании и стойка, через которую они входят: Entra ID или Okta. Данные — где лежат записи компании: Snowflake, Databricks или Fabric, обычно что-то одно из трёх. Твоё ИИ-приложение сидит посередине: сотрудники входят через identity provider компании, приложение работает в облаке компании и читает данные с минимальными нужными правами. Коротко: облако — где работает код, идентичность — кого пускают, данные — что читают.
- Что это
Три слоя, которые есть в каждой большой компании: облако, identity provider и платформа данных.
- Пример
Логистическая фирма: Azure для кода, Entra ID для входа, Snowflake для данных о продажах — ИИ-агент касается всех трёх.
- Подвох
У каждого слоя свой админ, свои тикеты и свои правила безопасности. Доступы — обычно самая медленная часть проекта.
- Связи
Главы идут по слоям: Azure, Entra ID / Okta, Snowflake / Databricks / Fabric; всё сходится в Least Privilege.
Шесть названий продуктов — на самом деле три работы: облако запускает код, идентичность решает, кого пускать, а платформа данных хранит записи компании. Твой агент живёт между ними.
Azure — облако Microsoft. Если знаешь AWS или Google Cloud, идеи тебе уже знакомы. Меняются названия, строгая структура папок и то, насколько безопасность держится на identities, а не на ключах.
Microsoft Azure — облако, которое выбирают, «потому что у нас всё Microsoft»
Переезд в новый город, где магазины те же, но называются иначе: супермаркет, аптека и булочная на месте — нужна только новая карта.
Microsoft Azure — облако Microsoft, как AWS (Amazon) или Google Cloud: виртуальные серверы, контейнеры, базы данных, файловые хранилища, сети, очереди. Плюс доступ к моделям — OpenAI, Anthropic и другим — через Microsoft Foundry. Почему он везде в компаниях среднего размера? Они уже платят Microsoft за Office 365, Teams и Outlook, а сотрудники уже входят с рабочим аккаунтом Microsoft. Второе облако — это новый контракт, новая система входа, новые юристы и новый security review. А для ИИ есть причина важнее: многие компании не отправят данные в публичный api.openai.com, а модели в Azure работают внутри их облака, по их контракту и их правилам доступа.
- Что это
Публичное облако Microsoft: вычисления, хранилище, сети, базы данных и ИИ-модели.
- Пример
Компания на Office 365 запускает нового ИИ-ассистента в Azure — счёт идёт по тому же контракту с Microsoft, вход через те же рабочие аккаунты.
- Подвох
Два вида прав: Azure RBAC (на ресурсы) и роли Entra (на каталог) — разные вещи. Contributor на подписке не даёт права создать app registration.
- Связи
Устроен по Resource Hierarchy; вход — через Entra ID; модели — из Microsoft Foundry.
Resource Hierarchy — tenant → subscription → resource group
Матрёшка: компания держит папки контрактов, в каждом контракте — коробки проектов, в каждой коробке — сами вещи. Открой большую матрёшку — и всё внутри идёт вместе с ней.
Azure строг к структуре, и она нужна тебе с первого дня, потому что по ней идут и доступы, и счета. Tenant — вся компания в мире Microsoft: один каталог людей и приложений, живёт в Entra ID. Management group — папка подписок с общими правилами (Azure Policy, например «ресурсы только в East US»). Subscription — контракт + счёт + граница доступа; обычно отдельные для prod и dev. Resource group — папка для вещей, которые живут и умирают вместе: приложение, его база, его vault. Удалишь группу — уйдёт всё внутри. Главное правило: роль Azure RBAC (кто что может), выданная на верхнем уровне, действует на всё ниже. Поэтому проси роль на одну resource group, а не на подписку.
- Что это
Вложенные папки Azure: tenant → management group → subscription → resource group → resource.
- Пример
Твой доступ как подрядчика: гостевой аккаунт в их tenant и роль Contributor только на
rg-ai-agent-dev.- Подвох
Новая роль может начать работать только минут через 5 (иногда дольше). 403 сразу после выдачи — это нормально, подожди.
- Связи
Верхний уровень — tenant в Entra ID; роли выдают Managed Identity, человеку или группе.
Where Code Runs — App Service, Container Apps, AKS, Functions
Способы добраться до работы: автобус по расписанию (Functions), такси, которое просто вызываешь (App Service), каршеринг — сам за рулём, но никакого обслуживания (Container Apps), и своя машина со всем её ремонтом (AKS).
В Azure четыре обычных дома для твоего кода. App Service — «просто залей веб-приложение»; как Heroku, стиль постарше, запускает Python, Node, .NET или контейнер. Container Apps — контейнеры без мыслей о серверах, с автоскейлингом до нуля; ближе всего к Google Cloud Run и обычно лучший выбор для бэкенда агента. AKS (Azure Kubernetes Service) — полноценный Kubernetes, как GKE; бери, только если у клиента уже есть Kubernetes-платформа. Functions — код, который запускается по событию (HTTP, таймер, очередь); хорош для фоновых задач вроде «пришёл файл — обработай».
- Что это
- Serverless-контейнеры Azure — обычный дом для бэкенда ИИ-агента.
- Пример
API агента работает как Container App со своей managed identity и ночью сжимается до нуля.
- Подвох
Забытый кластер AKS или большая VM стоит сотни или тысячи долларов в месяц. Поставь бюджетные алерты на resource group и удаляй dev-ресурсы.
- Связи
Права получает через Managed Identity; до сервисов ходит через Private Endpoints.
Managed Identity — аккаунт для приложения совсем без пароля
Ключ-карта в отеле, которую ресепшен каждое утро программирует заново: мастер-ключа у тебя нет, карта открывает только твои комнаты и сама перестаёт работать.
Managed identity — аккаунт для твоего приложения, который Azure создаёт и обслуживает сам. Ни пароля, ни файла с ключом: код просто просит у Azure токен. На практике ты вызываешь DefaultAzureCredential() — на ноутбуке он берёт твой az login, а внутри Container App получает короткоживущий токен от Entra ID (живёт около часа) через локальный endpoint. Дальше ты даёшь этой identity ровно те роли, что нужны, например Cognitive Services OpenAI User на ресурс Foundry. Это версия service account из Google Cloud для Azure — только без JSON-ключей. Видов два: system-assigned живёт и умирает вместе с одним ресурсом; user-assigned — отдельный объект, который можно прицепить к нескольким ресурсам.
- Что это
Аккаунт для приложения, которым управляет Azure: получает токены от Entra ID, пароля не хранит никогда.
- Пример
Агент вызывает модель с токеном из
DefaultAzureCredential()— ни одного API-ключа ни в коде, ни в конфиге.- Подвох
С октября 2025 Microsoft вводит обязательный MFA для изменений через CLI, SDK и Terraform от имени пользователя. Автоматизируй через managed или workload identity, а не через личный аккаунт.
- Связи
Особый вид Service Principal; секреты читает из Key Vault; CI так же использует workload identity federation (OIDC).
Key Vault — сейф для секретов
Банковская ячейка: ценности не лежат в ящике стола в офисе, открыть ячейку могут только люди из списка — и каждый визит записывается.
Иногда секрет всё же нужен — скажем, API-ключ от CRM клиента или приватный ключ Snowflake. Key Vault — сейф Azure для секретов, ключей и сертификатов, как Secret Manager в Google Cloud. Приложение читает секрет своей managed identity, у которой есть роль Key Vault Secrets User на этот vault. Ничего не лежит в config.yaml или в .env в git. Именно этот ответ хочет услышать команда безопасности на вопрос «где ваши секреты?».
- Что это
- Управляемое хранилище Azure для секретов, ключей и сертификатов.
- Пример
При старте агент забирает из Key Vault ключ CRM и приватный ключ Snowflake.
- Подвох
Vault, закрытый private endpoint, недоступен с твоего ноутбука — заранее продумай путь для dev.
- Связи
Читается через Managed Identity; часто спрятан за Private Endpoint.
Private Endpoint — сервисы без двери в интернет
Офисное здание, где у архива вообще нет входа с улицы: попасть туда можно только по внутреннему коридору, после того как тебя пропустили в лобби.
VNet (Virtual Network) — частная сеть клиента в Azure, как VPC в Google Cloud. Private endpoint даёт сервису — Key Vault, Foundry, Postgres — частный IP-адрес внутри этой VNet. После этого сервис можно полностью закрыть от интернета (publicNetworkAccess: Disabled). Корпоративная безопасность это обожает, а в компаниях среднего размера это часто обязательно. Платишь за это ты: твой локальный код больше не достучится до закрытого сервиса. Понадобится VPN, jump box или dev-среда внутри VNet — и правильно настроенный private DNS, классический источник вопроса «почему это имя не резолвится?».
- Что это
Частный IP облачного сервиса внутри сети клиента, чтобы сервис можно было закрыть от интернета.
- Пример
Foundry, Key Vault и Postgres получают адреса вроде
10.0.1.4; публичный доступ выключен.- Подвох
Ломает доступ с ноутбука и требует private DNS. Продумай путь для dev до первого деплоя.
- Связи
Один из первых вопросов Security Review; родственник в Google Cloud — Private Service Connect.
Microsoft Foundry — модели внутри tenant клиента
Столовая в офисе, которую ведёт внешний кейтеринг: еда та же, что в их ресторане, но готовят её в твоём здании, по твоим правилам и по твоему контракту.
Microsoft Foundry — ИИ-платформа Azure. Имя менялось часто: Azure AI Studio (2023) → Azure AI Foundry (2024) → Microsoft Foundry (с конца 2025), а Azure OpenAI теперь часть «Foundry Models». В одном месте ты создаёшь model deployment — свою именованную копию модели (скажем, gpt-4o-contracts) со своей quota: TPM (токены в минуту) или PTU (ёмкость, купленная заранее). Агентов строишь в Foundry Agent Service с tools и MCP, плюс получаешь evaluations, content filters и трейсы. Старые endpoints и ключи Azure OpenAI в основном продолжают работать. Текущий scope токена — https://ai.azure.com/.default; в старых примерах — https://cognitiveservices.azure.com/.default.
- Что это
Платформа Azure для моделей (включая Azure OpenAI), агентов и evaluations.
- Пример
model="gpt-4o-contracts"— в этом поле имя deployment, а не имя модели.- Подвох
Нужной модели может не быть в регионе клиента, или её TPM-квота слишком мала. Проверь до старта, а не в день демо. 404 часто значит неправильное имя deployment.
- Связи
Вызывается с токеном Managed Identity через Private Endpoint; родственник в Google Cloud — Vertex AI, в AWS — Bedrock.
Azure — знакомое облако со строгими папками. Проси одну resource group, дай приложению managed identity вместо ключей, держи секреты в Key Vault и проверь квоту модели в первый же день.
Твоё приложение не должно проверять пароли. У компании уже есть стойка, которая знает каждого сотрудника. В этой главе — общие слова (IdP, SSO, OIDC), а потом стойка Microsoft, Entra ID, где живёт больше всего путаницы.
Identity Provider и SSO — одна стойка для всех приложений
Охрана в бизнес-центре: охранник знает всех по пропуску. Офисы наверху сами паспорта не проверяют — они доверяют пропуску из лобби.
Identity provider (IdP) — система, которая подтверждает: «это Анна, она из отдела продаж». Entra ID, Okta и Google — это IdP. SSO (Single Sign-On) — то, что чувствуют люди: входят один раз рабочим аккаунтом и дальше попадают во все приложения — Outlook, Salesforce, Jira, твоего агента — без новых паролей. До этого у каждого приложения был свой логин: пятнадцать паролей на человека, половина на стикерах, новички неделю ждут аккаунтов, а ушедшие ещё полгода открывают CRM. С IdP айтишники выключают один аккаунт — и доступ пропадает везде. И есть один журнал: кто куда входил.
- Что это
Сервис входа компании; с ним один рабочий аккаунт открывает все приложения (SSO).
- Пример
У внутреннего агента нет формы логина — «Войти» отправляет людей в Entra ID или Okta клиента.
- Подвох
Ты им не управляешь. Любое изменение того, как твоё приложение логинит людей, идёт через IT клиента.
- Связи
- Говорит на OIDC или SAML; два главных — Entra ID и Okta.
OIDC и SAML — как приложение спрашивает стойку
Два способа доказать, что ты гость: QR-код в телефоне, который дверь сканирует за секунду (OIDC), или бумажное письмо с печатью от хозяина, которое охранник читает строчку за строчкой (SAML).
Два стандарта позволяют приложению «спросить стойку». OAuth 2.0 — как получить access token, чтобы вызвать API. OIDC (OpenID Connect) стоит поверх OAuth и нужен для входа: он добавляет ID token — JWT, где сказано, кто этот человек. Для нового веб-приложения OIDC — выбор по умолчанию. SAML — более старый XML-стандарт, всё ещё частый в корпоративном SaaS; бери его, если клиент настаивает. Обычный поток OIDC — authorization code + PKCE: редирект на IdP, человек входит (с MFA), IdP возвращает одноразовый код, твой бэкенд меняет его на токены. Потом ты проверяешь ID token: подпись (ключи из JWKS), iss, aud, срок, nonce. Для фоновой работы без человека есть поток client credentials; когда твой API вызывает другой API от имени пользователя — on-behalf-of (OBO).
- Что это
Стандарты, через которые приложение логинит людей через IdP. OIDC — современный JSON/JWT; SAML — более старый XML.
- Пример
Тот же поток «код + PKCE», что ты знаешь по «Войти через Google», только направленный на
login.microsoftonline.com/<tenant-id>илиacme.okta.com.- Подвох
Никогда не используй email как ключ пользователя — он меняется. Бери стабильный ID:
oid+tidв Entra,subв Okta.- Связи
IdP за ним — Entra ID или Okta; приложение, с которым он говорит, — App Registration.
Microsoft Entra ID — справочник компании в облаке
Справочник сотрудников, скрещённый со шкафом ключей: в нём каждый человек и каждая группа, и он же выдаёт ключи.
Microsoft Entra ID — до 2023 года Azure AD — облачный каталог людей и приложений компании от Microsoft плюс её сервер входа. Tenant — каталог одной организации: у него есть ID (GUID) и домены вроде contoso.com. Внутри — users (сотрудники и guests: ты как подрядчик обычно заходишь B2B-гостем со своей почтой), groups (security groups для прав; группы бывают статические и динамические, например «все с department = Sales») и apps. Многие компании до сих пор держат старый локальный Active Directory и синхронизируют его в Entra через Entra Connect. Правило для твоего приложения: давай права группам, а не людям. IT добавляет человека в группу — он получает доступ, а ты не трогаешь код.
- Что это
Облачный каталог и identity provider Microsoft для сотрудников, групп и приложений.
- Пример
Агент по контрактам пускает только участников группы
AI-Agent-Usersв tenantcontoso.com.- Подвох
Для внутреннего приложения используй tenant ID клиента — не
/common, который пускает любую организацию и личные аккаунты, — и проверяйtidв токене.- Связи
Приложения живут здесь как App Registrations и Service Principals; доступ задают App Roles и Conditional Access.
App Registration vs Service Principal — паспорт и виза
Паспорт и виза: паспорт (registration) один раз говорит, кто ты. Визу (service principal) выдаёт каждая страна, куда ты въезжаешь, — и именно виза говорит, что тебе там можно.
Эту пару путают все. App registration — паспорт твоего приложения: его client ID (публичный, это не секрет), redirect URI (куда вернуть человека после входа — совпадать должен точь-в-точь), его credentials, права, которые оно просит, и роли, которые оно объявляет. Service principal — экземпляр приложения внутри конкретного tenant; в портале он называется Enterprise application. Права выдают service principal, людей назначают на него, и Conditional Access действует на него. У одной регистрации могут быть service principals во многих tenants — так работают SaaS-продукты. Managed identity — тоже service principal, просто без паспорта, которым тебе нужно управлять. Про credentials: client secret протухает (максимум два года, по политике часто 6–12 месяцев); сертификат лучше; federated credential лучше всего — протухать нечему.
- Что это
Registration = описание приложения (client ID, redirect URI, права, роли). Service principal = его копия в tenant, которая получает права.
- Пример
«Contract Assistant»: single-tenant регистрация, redirect URI
https://agent.contoso.com/auth/callback, federated credential вместо секрета.- Подвох
Скорее всего, ты не сможешь сам создать регистрацию или дать admin consent — это делает Application Administrator. Пришли точный список заранее — это экономит недели.
- Связи
Просит Delegated или Application Permissions; объявляет App Roles; Managed Identity — тоже service principal.
Delegated vs Application Permissions — от имени пользователя или от своего
Личный помощник с ключом от твоего кабинета открывает только твои двери. Ночной охранник с мастер-ключом открывает все двери в здании — удобно для обхода, опасно в чужих руках.
Есть два вида прав на вызов API Microsoft. Delegated permissions (scopes) — приложение действует от имени вошедшего пользователя и видит только то, что видит он: User.Read, Files.Read. В токене они лежат в claim scp. Application permissions — приложение действует само по себе, без пользователя, для фоновой работы: Sites.Read.All читает все сайты SharePoint. Это очень сильные права, и им всегда нужен admin consent. Consent — это согласие: «да, этому приложению можно читать мой профиль». Обычные права пользователь может одобрить сам, если компания разрешает; сильные — только админ. Многие компании вообще выключают согласие пользователей — отсюда самый частый экран при первом входе: «Need admin approval».
- Что это
Delegated = действовать как вошедший пользователь, в пределах его прав. Application = действовать как само приложение, на всём, что выдано.
- Пример
Агент «вопрос-ответ по SharePoint» использует delegated
Sites.Read.All, и SharePoint сам применяет права каждого пользователя.- Подвох
Application permissions обходят права людей. С application
Sites.Read.Allагент, который отвечает сотрудникам, легко покажет кому-то документ, который тому видеть нельзя.- Связи
- Сердце As the User vs As Itself; первый вопрос Security Review.
App Roles — твои роли, которые раздаёт их IT
Цветные браслеты на фестивале: организатор решает, что открывает синий браслет, касса раздаёт браслеты, а на входе смотрят только на цвет.
App roles — роли, которые ты объявляешь в своей app registration, скажем Agent.User и Agent.Admin. IT клиента назначает их группам. Когда человек входит, его роли приходят в claim roles токена, и твой бэкенд их проверяет: нет Agent.User → 403. Включи «Assignment required» — и неназначенные люди даже войти не смогут. Почему бы просто не читать группы из токена? Из-за groups overage: если пользователь состоит в слишком многих группах (больше 200 для JWT), группы вообще не приходят в токене — вместо них ссылка на Graph. App roles обходят эту проблему и оставляют контроль у клиента: IT двигает людей между группами, а ты не трогаешь код.
- Что это
Роли, объявленные твоим приложением, назначенные группам силами IT клиента и доставленные в токене.
- Пример
if "Agent.User" not in claims.get("roles", []): abort(403)— финансы получаютAgent.Adminчерез свою группу.- Подвох
Если вместо этого полагаться на groups claim, всё ломается для людей больше чем в 200 группах — групп просто нет в токене.
- Связи
Объявляются в App Registration; аналог в Okta — отфильтрованный groups claim.
Conditional Access — правила на входе
Вышибала в клубе со списком правил: члены клуба проходят, гости показывают документ, в кроссовках не пускают никого — и так на входе каждый раз.
Conditional Access — набор правил «если — то», которые Entra проверяет при каждом входе: если кто-то из группы Finance открывает приложение X с неуправляемого устройства, то требуй MFA — или блокируй. В условиях могут быть пользователь или группа, приложение, устройство, место и риск входа. MFA — второй фактор: пуш в Microsoft Authenticator, ключ FIDO2, passkey. Conditional Access требует лицензии Entra ID P1 или выше; у маленьких tenants без P1 могут быть только security defaults (MFA для всех). Доступ на основе риска и PIM требуют P2, а Conditional Access для service principals — отдельной лицензии Workload Identities. «У нас нет такой функции» часто значит «у нас нет такой лицензии».
- Что это
Правила входа в Entra ID: условия (кто, приложение, устройство, место, риск) → действие (пустить, MFA, заблокировать).
- Пример
Агент по контрактам автоматически попадает под политику компании «MFA плюс управляемое устройство».
- Подвох
«Только управляемые устройства» может заблокировать твои тесты, твой CI и твой собственный ноутбук. Договорись об исключениях заранее и проверь, что dev-среду не заперли.
- Связи
Действует на Service Principal; версия Okta — authentication policies.
Microsoft Graph — один API ко всему Microsoft 365
Центральный коммутатор здания: один номер соединяет с любым отделом — почтой, календарём, архивом файлов — вместо отдельной линии для каждого.
Microsoft Graph — один большой API ко всему в Microsoft 365: пользователи, группы, почта, календари, Teams, файлы в OneDrive и SharePoint. Адрес — https://graph.microsoft.com/v1.0/…. Для ИИ-агента это главная дверь к документам клиента: «найди контракт 42 в SharePoint», «назначь встречу». С delegated-токеном Graph возвращает только то, что видит вошедший пользователь, — так инструмент поиска агента бесплатно наследует права SharePoint. Старый Azure AD Graph API выключен; остался только Microsoft Graph. Официальная библиотека для входа и токенов — MSAL (Python, JS, .NET и другие).
- Что это
- Единый REST API к данным Microsoft 365.
- Пример
Инструмент поиска агента вызывает
POST /v1.0/search/queryс access token пользователя и получает только те документы, которые этот пользователь может открыть.- Подвох
Что вернёт Graph, ограничено scopes в токене. Попросишь мало — вызовы падают; попросишь много — security review встаёт.
- Связи
Вызывается с Delegated или Application Permissions; токен приходит из входа по OIDC.
Entra Agent ID — identity, сделанная для ИИ-агентов
Пропуск сотрудника для робота: своё фото, свой список доступов, он виден в журнале посетителей, и охрана может отключить его на стойке, как любой другой.
В 2026 году в Entra появился отдельный вид identity для ИИ-агентов: Agent ID (общедоступен с апреля 2026). Агент получает свою identity, созданную по шаблону — agent identity blueprint, — и IT управляет ей как сотрудником: права, Conditional Access, логи входов, отключение. Это ответ на вопрос, который команды безопасности теперь задают часто: «как нам знать, какие агенты существуют и что им можно?». Штука новая, так что стоит знать слово и спросить клиента, пользуются ли они ей.
- Что это
Полноценный тип identity в Entra для ИИ-агентов: создаётся по blueprint и управляется как пользователь.
- Пример
Агент по контрактам и агент продаж получают каждый свой Agent ID с отдельными правами и логами.
- Подвох
Новинка 2026 года — многие tenants в среднем бизнесе её ещё не внедрили. Спрашивай, а не предполагай.
- Связи
Аналог в Okta — Cross App Access с Agent SSO; оба служат Least Privilege.
Entra ID — справочник и стойка компании. Зарегистрируй приложение, дай IT назначать app roles группам, предпочитай delegated permissions и пришли IT один точный список — тогда admin consent будет быстрым.
Okta делает ту же работу, что Entra ID, но это независимая компания. Она выигрывает там, где у клиента смесь инструментов и Microsoft не в центре. Стандарты те же; отличаются слова и админка.
Okta Workforce Identity — нейтральная стойка
Стойка, которую держит независимая охранная фирма, а не арендодатель: она работает с каждым арендатором в здании, какой бы марки ни был замок в его офисе.
Okta Workforce Identity — продукт Okta для сотрудников: он знает каждого человека в компании и решает, кто куда может войти. Люди входят один раз и попадают в Slack, Salesforce, Jira, AWS и твоё приложение. Компании выбирают его, когда у них «зоопарк» — Google Workspace, AWS, Slack, Salesforce, маки — и Microsoft не главный вендор; в его каталоге, Okta Integration Network (OIN), больше 8 000 готовых интеграций. У каждой компании есть org с адресом вроде acme.okta.com — версия tenant в Okta. Обычно есть production org и preview org (на oktapreview.com): сначала проси доступ к preview. Universal Directory хранит людей (с полями вроде отдела и руководителя), группы, а теперь и ИИ-агентов; данные обычно приходят из HR-системы — «HR — источник правды». Не путай Okta с Auth0: компания та же, но Auth0 — для клиентов компании, которые входят в её продукт, а Okta Workforce — для сотрудников.
- Что это
Независимый облачный identity provider для сотрудников: каталог, SSO, MFA, provisioning.
- Пример
Агент — это OIDC app integration в
acme.okta.com, назначенная группеAI-Agent-Users.- Подвох
По умолчанию группы в токен не кладутся. Нужен groups claim с фильтром (скажем, «начинается с AI-Agent-») — «все группы» раздувают JWT и ломают заголовки и cookies.
- Связи
Те же стандарты, что у Entra ID (OIDC и SAML); provisioning через SCIM; токены от Authorization Servers.
SCIM — пришёл, перешёл, ушёл — автоматически
Когда имя новичка появляется в списке HR, в первый же день у него есть пропуск, стол и шкафчик; когда он уходит, пропуск перестаёт работать в тот же вечер — и никому не надо об этом помнить.
SCIM — стандартный REST API, чтобы создавать, обновлять и выключать пользователей в приложении. IdP — Okta или Entra — это SCIM-клиент; твоё приложение — SCIM-сервер с endpoints /Users и /Groups. Lifecycle management покрывает три момента: joiner (человеку назначили приложение → POST /scim/v2/Users), mover (он сменил команду → группы обновились), leaver (он ушёл → PATCH с active=false: аккаунт выключен, а не удалён). Без SCIM пользователи появляются в твоей базе только при первом входе (just-in-time), и ушедших никто не удаляет — «мёртвые души» с историей чатов и настройками.
- Что это
Стандартный API, через который IdP создаёт, обновляет и выключает пользователей в твоём приложении.
- Пример
Человек уходит в пятницу; Okta шлёт
PATCH active=false, и его аккаунт в агенте выключен в тот же день.- Подвох
Важно, только если приложение хранит свои записи о пользователях. Если хранит, а SCIM ты пропустил, — будут аккаунты, которые переживут своих владельцев.
- Связи
Работает от Okta или Entra ID; в паре с короткоживущими токенами даёт быстрый отзыв доступа.
Authorization Servers — org или custom
В здании есть один стандартный пропуск, который открывает главные двери, но лаборатория с особыми правилами печатает свои пропуска со своими печатями. Стандартный пропуск на двери лаборатории не сработает.
Часть Okta, которая выпускает токены, — authorization server, и их два вида. Org authorization server встроен, issuer — https://acme.okta.com; он годится для обычного входа и вызовов API самой Okta, но свои scopes туда не добавишь. Custom authorization server (issuer вроде https://acme.okta.com/oauth2/default) защищает твои API: твои scopes вроде agent.read и agent.tickets.write, твои claims, твои политики, machine-to-machine. Для него нужна платная подписка API Access Management — у клиента её может не быть. Классическая ошибка: проверять в своём API токен от org-сервера так, будто это твой access token. Если строишь API, нужен custom-сервер. Сначала выясни issuer.
- Что это
Эмитент токенов в Okta. Org = встроенный, для SSO; custom = твои scopes и claims, для твоих API.
- Пример
Бэкенд проверяет токены по issuer
…/oauth2/default, audienceapi://ai-agent, ключам из/v1/keys.- Подвох
Перепутаешь — и проверка
audпадает или scope не добавить. Для вызовов API Okta используй OAuth service app, а не статический SSWS-токен, который ломается, когда его админ уходит.- Связи
Выпускает токены для OIDC; агенты могут ходить в другие приложения через Cross App Access.
Cross App Access и Agent SSO — агенты, которые не копят токены
Вместо того чтобы каждый помощник носил связку скопированных ключей от всех офисов, стойка выдаёт короткий гостевой пропуск на каждый визит — и записывает каждый визит в журнал.
Новая проблема: агенту в приложении A нужны данные из приложения B от имени пользователя. По-старому каждый пользователь в каждом приложении жмёт «подключи свою Jira», а агент хранит эти токены — и IT не видит ни одной такой связи. Cross App Access (XAA) — открытый протокол на основе черновика IETF ID-JAG (Identity Assertion JWT Authorization Grant): агент просит Okta, Okta проверяет политику и выпускает короткий токен для приложения B, и Okta видит и логирует каждую такую связь. XAA принят как расширение Enterprise-Managed Authorization для MCP; среди партнёров — Slack, Atlassian, Zoom, Asana, Datadog, Cloudflare и Claude. Agent SSO (общедоступен с 24 августа 2026, входит в стандартный Okta SSO без доплаты) регистрирует агента с поддержкой XAA как отдельную identity в Universal Directory, рядом с людьми, с короткоживущими токенами вместо статических API-ключей. Сверх этого Okta for AI Agents — отдельная платная подписка для обнаружения агентов и управления ими. Для клиентской стороны Auth0 for AI Agents (GA с ноября 2025) даёт Token Vault, асинхронное одобрение человеком и тонкий доступ для RAG.
- Что это
Способ через Okta получить агенту в одном приложении короткий, залогированный токен для другого приложения — от имени пользователя.
- Пример
Агент продаж создаёт тикеты в Jira через XAA — хранить нечего, и IT видит эту связь в Okta.
- Подвох
Работает, только если и приложение агента, и целевое приложение это поддерживают. У многих клиентов среднего размера это не включено — держи план Б: обычный OAuth с минимальными scopes.
- Связи
Аналог у Microsoft — Entra Agent ID; это As the User, только централизованно.
Okta — нейтральная стойка: тот же OIDC, который ты уже знаешь, плюс SCIM для прихода и ухода людей, два вида серверов токенов, а теперь и Cross App Access, чтобы агенты перестали копить токены.
Где компания держит свои цифры? Сначала три формы хранения данных. Потом Snowflake — SQL-хранилище, где storage и compute разделены, а платишь посекундно.
Warehouse, Lake, Lakehouse — три способа хранить данные компании
Библиотека, гараж и современный архив. В библиотеке строгие полки и каталог, но принимают только готовые книги. Гараж берёт что угодно, но найти там что-то — кошмар. Архив хранит всё в дешёвых коробках — с каталогом сверху.
Data warehouse — база данных для анализа, а не для работы приложения: большие строгие таблицы и тяжёлые запросы вроде «продажи по регионам за три года», на SQL. Быстро и надёжно, но дороже, и внутрь попадает только чистая часть данных. Data lake — просто папки файлов в облачном хранилище — S3, ADLS, GCS: логи, выгрузки CRM, CSV, JSON, картинки. Дёшево и огромно, но без порядка: нет транзакций, файлы ломаются при одновременной записи, никто не знает, какая версия правильная. Годами компании держали и то и другое и копировали данные туда-сюда — две копии, два набора прав, отчёты, которые не сходятся с моделями. Lakehouse (lake + warehouse) хранит данные один раз в дешёвом хранилище, в табличном формате, который добавляет транзакции, схему и историю, — и SQL, Spark и ML работают с одними и теми же таблицами.
- Что это
Три формы хранения: строгие SQL-таблицы, сырые файлы любого вида или файлы с табличным форматом сверху.
- Пример
Финансовые отчёты живут в warehouse; логи приложения падают в lake; lakehouse обслуживает и то и другое из одной копии.
- Подвох
Сегодня Snowflake, Databricks и Fabric умеют почти всё и жёстко конкурируют — ярлыки говорят только о том, откуда каждый начинал.
- Связи
Snowflake (корни в warehouse), Databricks и Microsoft Fabric (lakehouse на Delta Lake).
Snowflake — хранилище в одном месте, вычисления по требованию
Огромный склад товаров и отдельные бригады грузчиков, которых нанимаешь поминутно. Нужно быстрее — зови бригаду побольше. Никто не работает — никому не платят.
Snowflake — облачная база данных для аналитики. Компания вливает туда свои данные — продажи, CRM, склад, финансы, — и каждый отдел спрашивает их обычным SQL. Серверы, диски, индексы, бэкапы — забота Snowflake. Главная идея: storage отделён от compute. Одна копия данных, а у каждой команды свой вычислительный кластер, который не тормозит остальных. Слоёв три: cloud services (мозг — вход и роли, метаданные, оптимизатор запросов, кэш результатов), compute (virtual warehouses, оплата в кредитах) и storage (колоночные данные в micro-partitions, оплата за TB в месяц). Snowflake работает поверх AWS, Azure или GCP — облако и регион выбирает клиент. У твоего account идентификатор вроде myorg-myaccount; веб-консоль — Snowsight. Бонусы: Time Travel читает таблицу «как она была вчера» (по умолчанию 1 день, до 90 на Enterprise), а zero-copy clone за секунды делает dev-базу из prod.
- Что это
SQL-платформа для аналитики, где storage и compute разделены, а за compute платишь по использованию.
- Пример
Запросы агента идут на его собственном маленьком кластере, поэтому дашборды BI-команды не тормозят.
- Подвох
Имена без кавычек становятся ЗАГЛАВНЫМИ:
"orders"в кавычках иorders— разные таблицы. И бери новый идентификаторorg-account, а не старый формат locator.- Связи
Compute — это Virtual Warehouse; доступ — Roles and RBAC; ИИ — Cortex.
Virtual Warehouse — вычислительный кластер, а не склад
Такси со счётчиком: приезжает по вызову, счётчик крутится, только пока едешь, и уезжает, когда ты вышел. Машина побольше стоит дороже за минуту.
Это слово путает всех: virtual warehouse ничего не хранит. Это вычислительный кластер, который выполняет твои запросы. У него есть размер — X-Small, Small, Medium, Large и так до 6X-Large, — и каждый шаг вверх даёт вдвое больше мощности за вдвое большую цену. Цена — в credits, внутренней валюте Snowflake: X-Small сжигает 1 кредит в час, Small — 2, Medium — 4, Large — 8, X-Large — 16 (Gen1). Цена кредита в долларах зависит от редакции, облака, региона и контракта — одной цифры нет. Оплата посекундная, с минимумом 60 секунд на каждый запуск. Auto-suspend усыпляет кластер в простое (ставь 60 секунд); auto-resume будит его на следующий запрос; multi-cluster (Enterprise) добавляет копии под нагрузкой. Resource monitor ограничивает кредиты: уведомить на 80%, остановить на 100%. Без активного warehouse SQL не запустится: «No active warehouse selected».
- Что это
Вычислительный кластер Snowflake с размером и посекундной ценой в кредитах; данных не хранит.
- Пример
AI_AGENT_WH: X-Small,AUTO_SUSPEND = 60, resource monitor на 50 кредитов иQUERY_TAG, чтобы видеть расходы агента.- Подвох
Нет auto-suspend или слишком большой размер = тысячи долларов в месяц. Агент, который шлёт 20 запросов на каждый вопрос, держит warehouse бодрствующим весь день.
- Связи
- Слой compute в Snowflake; используется через Role.
Roles and RBAC — права ролям, роли людям
Ключи на доске с крючками, подписанными по должности, а не по имени: «кассир», «ночной менеджер». Новичок получает крючок своей должности; россыпью ключи не раздают никому.
В Snowflake права никогда не дают пользователю напрямую: их дают ролям, а роли — пользователям. Это RBAC (role-based access control). Встроенные роли: ACCOUNTADMIN — бог аккаунта (тебе его никто не даст, и он тебе не нужен); SECURITYADMIN и USERADMIN управляют пользователями и правами; SYSADMIN создаёт базы и warehouses; PUBLIC есть у всех. Роли можно вкладывать друг в друга. Для агента ты создаёшь его собственную роль, скажем AI_AGENT_RO, с USAGE на его warehouse, базу и схему и SELECT на нужные views — плюс SNOWFLAKE.CORTEX_USER, если он вызывает Cortex. Сверху row access policies решают, какие строки кто видит, а masking policies прячут значения вроде email или SSN. Объекты называются DATABASE.SCHEMA.OBJECT, например SALES.MART.ORDERS_V.
- Что это
Модель доступа Snowflake: права выдают ролям, роли — пользователям и другим ролям.
- Пример
GRANT SELECT ON ALL VIEWS IN SCHEMA SALES.MART TO ROLE AI_AGENT_RO— только views, никогда не сырые таблицы с PII.- Подвох
«Object does not exist» или «no warehouse» — почти никогда не опечатка, а пропущенный
USAGE. Snowflake говорит «не существует», когда роль объект не видит.- Связи
- Выдаётся Service User; хрестоматийный пример Least Privilege.
Service User — аккаунт Snowflake для программы, пароли запрещены
Робот-курьер попадает в здание по запрограммированному чипу, а не набирая код на двери — и здание просто больше не пускает роботов по кодам.
Service user (TYPE = SERVICE) — пользователь Snowflake для программы, а не для человека. Пароли ему запрещены: он входит через key pair (JWT), OAuth, programmatic access token (PAT) или workload identity federation. И теперь это строго: с августа по октябрь 2026 Snowflake полностью заблокировал вход по паролю для service users, а пользователей LEGACY_SERVICE переводят в SERVICE. Так что старые примеры из интернета с password= не работают — не копируй их. С key-pair auth ты генерируешь пару ключей RSA, отдаёшь админу публичный ключ (RSA_PUBLIC_KEY), а приватный держишь в Key Vault или Secret Manager. Коннектор подписывает им JWT (authenticator="SNOWFLAKE_JWT"). Второй слот, RSA_PUBLIC_KEY_2, позволяет менять ключи без простоя; network policy ограничивает, с каких IP можно подключаться.
- Что это
Пользователь Snowflake для софта: входит только по ключу, OAuth, PAT или workload identity.
- Пример
SVC_AI_AGENTсDEFAULT_ROLE = AI_AGENT_RO,DEFAULT_WAREHOUSE = AI_AGENT_WHи только публичным RSA-ключом.- Подвох
Если все пользователи агента идут через один service user, все видят одни и те же данные. Реши заранее: row policies или вход от имени пользователя через OAuth из Okta или Entra.
- Связи
Держит Role; ключи живут в Key Vault; выбор дизайна — As the User vs As Itself.
Cortex — ИИ рядом с данными
Вместо того чтобы таскать коробки из архива к внешнему эксперту, ты зовёшь эксперта в архив — бумаги не покидают здание.
Cortex AI — ИИ-слой Snowflake: модели Anthropic, OpenAI, Meta, Mistral и других работают внутри периметра безопасности Snowflake. Cortex AI Functions (бывший «AISQL») встраивают LLM прямо в SQL: AI_COMPLETE, AI_CLASSIFY, AI_EXTRACT, AI_SENTIMENT — классифицируй 100 000 отзывов одним запросом. Cortex Analyst превращает вопрос на английском в SQL с помощью semantic view, где описаны бизнес-термины («revenue = SUM(amount) where status = 'paid'»). Cortex Search — готовый RAG-поиск по тексту: векторы + ключевые слова + reranking. Cortex Agents (GA с ноября 2025) планируют шаги и вызывают Analyst, Search, твои процедуры и MCP-коннекторы; 28 августа 2026 Snowflake рекомендовал перейти с отдельного Analyst API на Cortex Agents. Snowflake Intelligence — готовый чат-интерфейс сверху. Snowflake-managed MCP server (CREATE MCP SERVER, до 50 tools) открывает всё это внешним агентам вроде Claude или Cursor — со Snowflake OAuth или внешним OAuth из Okta или Entra.
- Что это
Встроенный ИИ Snowflake: LLM-функции в SQL, text-to-SQL, RAG-поиск и агенты — рядом с данными.
- Пример
Путь B для агента «почему упала маржа в Техасе?»: semantic view + Cortex Agent, который вызывается из твоего приложения, — данные не покидают Snowflake.
- Подвох
Вызовы Cortex стоят кредитов за токены — отдельная строка в счёте; попробуй на 1 000 строк, прежде чем на миллионе. Не каждая модель есть в каждом регионе. И text-to-SQL без семантического слоя врёт: никто не знает, что значит
AMT_NET_2.- Связи
Агенты достают его через MCP; родственник в Databricks — Agent Bricks, в Fabric — Data Agent.
Snowflake отделяет storage от compute и берёт за compute посекундно. Дай агенту свой service user с ключом, роль только на чтение, X-Small warehouse и лимит кредитов — и пришли админу готовый SQL-скрипт.
Databricks начинался с файлов и Spark, а не с SQL-таблиц. Это lakehouse: одна копия данных в собственном облачном хранилище клиента, один охранник на весь доступ и ИИ-платформа на тех же таблицах.
Databricks — склад, цех и лаборатория на одной площадке
Заводская площадка: дешёвый склад для сырья, цех, где его чистят и обрабатывают, витрина с готовой продукцией, лаборатория для экспериментов — и один охранник на воротах, который проверяет пропуск у каждого.
Databricks — платформа данных от создателей Apache Spark. Компания держит все данные в дешёвом облачном файловом хранилище, обрабатывает их в Spark (распределённый движок для данных, которые не влезают в одну машину), отвечает на вопросы на SQL и строит ML-модели и ИИ-агентов на тех же данных — всё под одной системой прав, Unity Catalog. Работает поверх облака клиента: AWS, Azure (как Azure Databricks) или GCP. Люди работают в notebooks (как Jupyter, в браузере, всегда подключены к compute) и jobs; аналитики — в SQL и Genie; ИИ-работа живёт в Agent Bricks. Compute — clusters для Spark, SQL warehouses для SQL, serverless — оплачивается в DBU (Databricks Units). Ещё есть Lakebase — управляемый Postgres для приложений, которым нужны быстрые чтения и записи.
- Что это
Lakehouse-платформа: файлы в облачном хранилище клиента, сверху Spark и SQL, ИИ на тех же таблицах.
- Пример
Дистрибьютор держит продажи, склад и CRM в gold-таблицах
main.sales_gold.*на Azure Databricks.- Подвох
Три облака — три немного разных продукта: на Azure identity идёт через Entra; доступность функций (Lakebase, serverless) зависит от облака и региона.
- Связи
Таблицы — Delta Lake; права — Unity Catalog; агент ходит в SQL Warehouse.
Delta Lake — папка файлов, которая ведёт себя как таблица
Журнал склада: коробки на полках — просто коробки, но журнал у двери говорит, какие из них составляют сегодняшний запас. Поменяй запись в журнале одним росчерком — и запас меняется целиком.
Delta Lake — открытый табличный формат. Внизу — обычные файлы Parquet (колоночный формат файлов) плюс папка _delta_log — журнал, где записано, какие файлы составляют таблицу прямо сейчас. Благодаря журналу простая папка файлов получает силы настоящей базы данных: ACID-транзакции (запись ложится целиком или никак; читатели не видят половину), схему (строку в числовую колонку не запишешь), time travel (прочитать таблицу «как она была вчера») и MERGE, UPDATE, DELETE. Если знаешь Postgres: это как WAL, только журнал лежит рядом с файлами в S3, а не внутри сервера базы. Fabric использует тот же формат.
- Что это
Открытый табличный формат: файлы Parquet плюс журнал
_delta_log, который добавляет транзакции и историю.- Пример
Ночной job делает MERGE новых заказов в
orders; аналитики никогда не видят недописанную таблицу.- Подвох
Это формат, а не сервер: чтобы его прочитать, всё равно нужен compute — и платишь ты именно за него (DBU).
- Связи
- Основа Lakehouse; общий для Databricks и Microsoft Fabric.
Unity Catalog — один охранник с одним журналом
Охранник на единственных воротах с журналом: неважно, пришёл ты пешком, приехал на машине или ты робот-доставщик, — он проверит пропуск и запишет, что ты взял.
Unity Catalog — единый слой прав и каталога для всех данных и ИИ в Databricks; он включён по умолчанию в каждом workspace, созданном после 8 ноября 2023. Имена трёхуровневые — catalog.schema.table, например main.sales_gold.orders, — и та же схема покрывает views, volumes (папки файлов вроде PDF), функции и модели. Права выдаются через GRANT людям, группам и service principals. Можно прятать строки (row filters) и колонки (column masks). Lineage рисует, откуда данные пришли и куда ушли, а каждое действие пишется в аудит в system tables. Откуда бы ни пришёл запрос — из notebook, SQL или от твоего агента, — он проходит одну и ту же проверку. Чтобы прочитать одну таблицу, principal нужны три права сразу: USE CATALOG + USE SCHEMA + SELECT.
- Что это
Центральные права, каталог, lineage и аудит Databricks для данных и ИИ-объектов.
- Пример
Service principal агента получает
SELECTна схемуmain.sales_goldиREAD VOLUMEнаmain.docs.contracts— и больше ничего.- Подвох
Если не хватает одного из трёх прав, это выглядит как «table not found». В старых workspaces таблицы могут ещё лежать в legacy
hive_metastoreсо старыми правилами — проверь, что мигрировали.- Связи
Охраняет таблицы Delta Lake; проверяет каждый запрос к SQL Warehouse.
Medallion — bronze, silver, gold
Руда из шахты, металл из печи, готовое кольцо на витрине. Ювелир продаёт только кольцо — но руду хранит на случай, если печь придётся запустить заново.
Medallion — не продукт, а общепринятый способ раскладывать данные по слоям качества. Bronze — сырые данные ровно в том виде, как пришли из источника: дубли, мусор, смешанные форматы. Их хранят, чтобы можно было всё пересобрать. Silver — очищенные: правильные типы, без дублей, таблицы связаны ключами. Gold — агрегаты и бизнес-таблицы: выручка по дням, активные клиенты. Отчёты и агенты читают gold. Пайплайны, которые двигают данные между слоями, — Lakeflow Jobs (бывшие Workflows) и Lakeflow Declarative Pipelines (бывшие Delta Live Tables, DLT). Правило для ИИ-проекта: агент читает gold, иногда silver и никогда bronze.
- Что это
Слои данных по качеству: сырые (bronze), очищенные (silver), готовые для бизнеса (gold).
- Пример
Агент читает
main.sales_gold.orders; сырые дампы CRM остаются в bronze, вне его досягаемости.- Подвох
Gold обновляется раз в ночь или раз в час. Агент должен говорить, на какую дату его цифры.
- Связи
Строится на Delta Lake; давай агенту только gold через Unity Catalog.
SQL Warehouse и OAuth M2M — как агент задаёт вопрос
Окошко самообслуживания с автоматом талонов: один раз показываешь документ, получаешь талон на час, и служащий сверяется со списком, прежде чем что-то выдать.
SQL warehouse — compute Databricks только для SQL; BI-инструменты и твоё приложение подключаются к нему по server hostname и HTTP path (оба есть в Connection details у warehouse). Типов три: serverless (рекомендуется, обычно стартует за 2–6 секунд), pro и classic (около 4 минут). Агент входит как service principal через OAuth M2M (machine-to-machine): меняет client_id и client_secret на короткоживущий токен и шлёт SQL. Unity Catalog проверяет права и фильтры; движок читает только нужные файлы и колонки; строки возвращаются; и каждый запрос попадает в таблицы аудита (system.access.audit). Передавай значения как параметры запроса (:since), а не склеивай строки — даже когда SQL пишет LLM, — и всегда добавляй LIMIT.
- Что это
Compute Databricks только для SQL; приложения и агент ходят в него с токеном service principal.
- Пример
Маленький serverless warehouse только для агента (право
CAN USE) — его расходы видны, и ему можно поставить свой лимит.- Подвох
Classic warehouse стартует ~4 минуты, и первый запрос агента падает по таймауту — а API по умолчанию создаёт именно classic. Personal access tokens (PAT) часто запрещены; используй OAuth M2M.
- Связи
Проверяется Unity Catalog; identity — Service Principal; выбор дизайна — As the User vs As Itself (U2M / on-behalf-of).
Agent Bricks — ИИ-зонтик Databricks
Торговый центр, где все ИИ-магазины переехали под одну крышу и одну вывеску: магазины те же, над входом новое имя.
Больше всего имена менялись именно в этом углу. Mosaic AI — старое имя зонтика (после того как Databricks купил MosaicML); с марта 2026 зонтик для всего ИИ — Agent Bricks, платформа, чтобы строить и запускать агентов. Она поддерживает frontier- и открытые модели (OpenAI, Anthropic, Gemini и другие), фреймворки вроде LangGraph, CrewAI и Claude Agent SDK, трейсинг через MLflow, управляемую память агентов (на Lakebase), песочницу для запуска кода и разбор документов (ai_parse_document, ai_extract, ai_classify). Вокруг: Model Serving (модель как REST endpoint, для LLM — совместимый с OpenAI), Unity AI Gateway (одни ворота для вызовов моделей и MCP: права, бюджеты, лимиты, защита PII, трейсинг), Databricks Apps (хостинг агента внутри Databricks), Genie (спрашивай данные на английском, есть Genie MCP server). Vector search 1 июня 2026 переименовали в AI Search, и теперь он добавляет full-text, гибридный поиск и reranking; индекс может держаться в синхроне с Delta-таблицей.
- Что это
Платформа Databricks, чтобы строить, запускать агентов и управлять ими рядом с данными.
- Пример
Контракты разобраны через
ai_parse_document→ таблица чанков → индекс AI Search, который держится с ней в синхроне; вызовы модели агента идут через Unity AI Gateway.- Подвох
Переименования повсюду: DLT → Declarative Pipelines, Workflows → Lakeflow Jobs, Vector Search → AI Search, Delta Sharing → OpenSharing (июнь 2026). В документах клиента старые имена — знай оба.
- Связи
Аналог в Snowflake — Cortex; в Fabric — Data Agent; в Azure — Microsoft Foundry.
Databricks — это lakehouse: Delta-файлы в хранилище клиента, Unity Catalog как единственный охранник, gold-таблицы для агента и маленький serverless warehouse с OAuth — а не личные токены.
Fabric — ответ Microsoft на Snowflake и Databricks: один продукт с хранилищем, загрузкой данных, обработкой, Power BI и ИИ. Его выбирают компании, которые уже живут в Microsoft. Новые идеи здесь — одно хранилище на всю компанию и одна общая capacity, которую тратят все.
Microsoft Fabric и OneLake — «Office для данных»
Пять кладовых в пяти зданиях, у каждой свой ключ, — а вместо них одно большое здание с одним пропуском и одним счётом за электричество.
Microsoft Fabric — SaaS-платформа данных «всё в одном»: одно общее хранилище (OneLake), загрузка данных (Data Factory), обработка (Spark, SQL), отчёты (Power BI) и ИИ (Copilot, data agents) — в одном портале в браузере, вход через Entra ID, оплата как одна capacity. До Fabric компания на Microsoft склеивала Azure Data Factory, ADLS, Azure Synapse и Power BI — у каждого свой счёт, свои права и своя сеть, а данные копировались по три-четыре раза. OneLake — одно логическое хранилище на весь tenant, создаётся автоматически; Microsoft называет его «OneDrive для данных». Внутри папки по workspace и item, таблицы в формате Delta (тот же открытый формат, что у Databricks); снаружи выглядит как ADLS Gen2. Роли в workspace — Admin, Member, Contributor, Viewer, — а ещё можно расшарить отдельный item. В Power BI semantic model (бывший «dataset») — бизнес-слой из таблиц, связей и мер DAX; часто именно там компания уже договорилась, что значит «выручка».
- Что это
Платформа данных Microsoft «всё в одном» с одним хранилищем (OneLake) и одним счётом (capacity).
- Пример
Сеть клиник зеркалит свою медкарту (EHR) и биллинг из Azure SQL в Fabric, отчёты — в Power BI на F64.
- Подвох
Проще, чем Databricks, но меньше контроля. И имена плывут: dataset → semantic model, «license mode» → «workspace type», P SKU → F SKU.
- Связи
Оплачивается через Capacity; читается через SQL Analytics Endpoint; наполняется через Shortcuts and Mirroring.
Capacity и F SKUs — один общий счёт за электричество
Договор на электричество для всего офиса: если твой новый обогреватель работает на полную, свет мигает и на этаже финдиректора.
Capacity — пул вычислений, который покупает компания. Каждый workspace привязан к одной capacity, и всё, что он делает, — SQL, Spark, обновления отчётов, Copilot — тратит её CU (capacity units). Размеры — F SKUs: F2, F4, F8 … F64 … F2048; число — это количество CU, а F64 соответствует старому Power BI Premium P1. Покупается в Azure, оплата посекундная (минимум минута) или резерв на год со скидкой; цены зависят от региона, так что смотри калькулятор Azure для региона клиента. Capacity можно поставить на паузу — тогда в ней ничего не работает. F64 — это порог: начиная с F64 люди с бесплатной лицензией могут смотреть отчёты Power BI; ниже каждому зрителю нужна Pro или PPU. Fabric разрешает тяжёлой задаче ненадолго взять больше купленного (bursting) и размазывает стоимость во времени (smoothing: интерактивную работу минимум на 5 минут, фоновую — на 24 часа). Переборщишь — начнётся throttling: после 10 минут «долга» интерактивные запросы ждут 20 секунд, после 60 минут их отклоняют, после 24 часов отклоняют всё.
- Что это
Общий, заранее купленный пул вычислений, который тратят все привязанные к нему workspaces Fabric.
- Пример
Одна F64 обслуживает всю компанию; запросы агента держат маленькими и следят за ними в приложении Capacity Metrics.
- Подвох
Throttling — это не «чуть медленнее», а ошибки
CapacityLimitExceededу всех. А если клиент ради экономии ставит capacity на паузу на ночь, твой агент ночью не работает.- Связи
Счёт Microsoft Fabric; поштучный Virtual Warehouse в Snowflake — противоположная модель.
SQL Analytics Endpoint — снаружи Fabric выглядит как SQL Server
Музейная витрина: можно сколько угодно разглядывать каждый предмет со всех сторон, но впереди стекло — ничего не сдвинешь и не добавишь.
В Fabric два дома для таблиц. Lakehouse — для дата-инженеров: Delta-таблицы (папка Tables) плюс любые файлы (папка Files), пишутся через Spark, notebooks и pipelines. Warehouse — для людей SQL: только таблицы, с полным T-SQL (диалект SQL от Microsoft) — INSERT, UPDATE, MERGE. Оба — Delta в OneLake, и их можно соединять в одном запросе. Каждый lakehouse (и mirrored database) автоматически получает SQL analytics endpoint: T-SQL только на чтение поверх его Delta-таблиц. Можно делать SELECT, создавать views и функции, настраивать row-level security — но не менять данные. Снаружи это выглядит как SQL Server: агент подключается через ODBC Driver 18 на порт 1433 (протокол TDS) к адресу вроде xxxx.datawarehouse.fabric.microsoft.com с токеном Entra для scope https://database.windows.net/.default. «Только чтение» — это хорошо для агента.
- Что это
Автоматический endpoint в стиле SQL Server, только на чтение, поверх lakehouse или mirrored database в Fabric.
- Пример
pyodbc+ токен Entra →SELECT TOP (100) clinic, COUNT(*) … FROM dbo.appointmentsс параметрами.- Подвох
Видны только таблицы в
/Tables, а новые — после синхронизации метаданных (иногда с задержкой). Логи агента или кэш туда не запишешь — бери warehouse, SQL database в Fabric или свою базу.- Связи
Тратит Capacity; для доступа Service Principal нужна роль в workspace или право на item.
Shortcuts и Mirroring — данные без своего ETL
Ярлык на рабочем столе открывает файл, который лежит где-то ещё. Mirroring — копия этого файла, которая сама обновляется каждый раз, когда меняется оригинал.
Способ Fabric обойтись без пайплайнов копирования. Shortcut — как symlink: папка в lakehouse, которая на самом деле указывает на S3, ADLS, Google Cloud Storage, Dataverse, SharePoint/OneDrive или другой item в OneLake. Данные не копируются; удалишь shortcut — источник не пострадает. Для внутренних shortcuts доступ проверяется по identity того, кто читает. Mirroring — непрерывная копия: Fabric реплицирует базу в OneLake как Delta, почти в реальном времени. Источники — Azure SQL, SQL Server, Azure Database for PostgreSQL, Cosmos DB, Snowflake, Google BigQuery, Oracle и SAP. Для Azure Databricks есть metadata mirroring: копируется только каталог, а данные читаются через shortcuts. Вычисления для репликации бесплатны, а хранение реплик бесплатно до 1 TB на каждую CU capacity.
- Что это
Два способа завести внешние данные в OneLake: указать на них (shortcut) или держать живую копию (mirroring).
- Пример
Таблицы биллинга из Azure SQL зеркалятся в Fabric; агент читает их через SQL endpoint mirrored database.
- Подвох
Capacity на паузе останавливает и mirroring. В именах shortcuts нельзя пробелы и нелатинские символы.
- Связи
Кладёт данные в OneLake Microsoft Fabric; mirrored databases получают SQL Analytics Endpoint.
Fabric Data Agent — готовый «чат с данными»
Библиотекарь-справочник, который знает каталог наизусть и сам приносит ответы, — но только с тех полок, которые открывает твой читательский билет, и никогда не даёт писать в книгах.
Fabric data agent — настраиваемый «чат с данными». Ты выбираешь до пяти источников — lakehouse, warehouse, semantic model, KQL database, mirrored database, ontology, — пишешь инструкции и примеры пар «вопрос → запрос», и агент превращает вопрос в SQL, DAX или KQL и выполняет его. Он общедоступен. Он работает только на чтение и от имени пользователя: видит только то, что можно этому человеку. Вызывать его можно из Microsoft 365 Copilot, Copilot Studio, Teams, Microsoft Foundry или как MCP-сервер. Fabric IQ — более новый слой «бизнес-смысла» (ontology, semantic models, data agents) для внешних агентов; в Foundry Agent Service старый инструмент «Fabric data agent» уберут 6 ноября 2026 в пользу Fabric IQ. Copilot in Fabric, встроенный помощник, теперь работает на любой платной capacity начиная с F2 (требование F64 отменили в апреле 2025), — но не на пробной.
- Что это
Встроенный в Fabric агент «вопрос → запрос» поверх выбранных источников, только на чтение и от имени пользователя.
- Пример
Путь A для агента «почему в Остине растут неявки?»: data agent поверх semantic model, опубликованный в Teams, — права пользователей применяются сами.
- Подвох
Только английский, LLM не выбрать, ответы ограничены 25 строками × 25 колонками, без PDF, а источник и агент должны быть в одном регионе capacity. Нужно больше контроля? Строй своего агента на SQL endpoint (путь B).
- Связи
Родственник Cortex и Agent Bricks в Fabric; путь B использует SQL Analytics Endpoint.
Fabric — платформа данных Microsoft в одной коробке: OneLake для хранения, одна общая capacity для вычислений, SQL endpoint только на чтение для твоего агента — и встроенный data agent, когда хватает простого пути.
Теперь настоящая работа: ИИ-агент внутри компании клиента. Каждая система выше задаёт одни и те же несколько вопросов: кто такой агент, что ему можно читать, от чьего имени он действует и подпишет ли это команда безопасности. Ответь рано — и проект движется; ответь поздно — и он ждёт.
Чертёж: один агент, три слоя
Въезд в офисное здание новым арендатором: пропуска от стойки, помещение от арендодателя и ключ только от своей полки в архиве — всё оформлено до того, как приехал грузовик с вещами.
Типичный проект простыми словами. Данные клиента живут в Snowflake (или в Databricks, или в Fabric). Сотрудники входят через Entra ID (или Okta). Приложение работает в облаке клиента — часто в Azure. Твой агент пускает только «своих» через их собственный вход, с app roles, которые их IT назначает группам. Он работает как Container App с managed identity, вызывает model deployment в Foundry, читает секреты из Key Vault и сидит за private endpoints, если безопасность просит. Данные читает с минимальными правами: service user в Snowflake с ключом и ролью только на чтение, service principal в Databricks с OAuth M2M и правами только на gold или service principal в Fabric с Viewer на одном item. Логи идут в Application Insights — без персональных данных в промптах. Деплой — из GitHub через OIDC, никаких секретов в репозитории.
Least Privilege — только то, что нужно для работы
Ключ-карта горничной в отеле открывает номера на её этаже во время её смены — не сейф, не кабинет управляющего, не другие этажи.
Least privilege — давать только минимум нужных прав, на самый узкий охват, по умолчанию только на чтение. У каждой системы своя версия: Contributor на одну resource group вместо всей подписки; роль вроде AI_AGENT_RO с SELECT на views вместо чего-то близкого к ACCOUNTADMIN; delegated Files.Read.All вместо application Sites.Read.All; Viewer на одном item в Fabric вместо Admin на workspace; только gold-схема в Unity Catalog. Для агентов это важно даже больше, чем для людей: LLM можно обмануть prompt injection, и тогда ущерб останавливается ровно там, где кончается то, что ему разрешено.
- Что это
Давать только те права, что нужны для работы, на самый узкий охват и на как можно меньший срок.
- Пример
Роль агента в Snowflake может читать три views в
SALES.MARTи больше ничего — даже сырые таблицы за ними.- Подвох
Слишком узко — и агент падает странно («table not found»). Начни с минимума, добавляй права по одному и записывай, зачем нужно каждое.
- Связи
Определяет роли в Resource Hierarchy, Roles and RBAC, права в Unity Catalog; первое, что проверяет Security Review.
As the User vs As Itself — чьими глазами смотрит агент
Отправить помощницу в архив с твоим читательским билетом или с мастер-картой здания. С твоим она принесёт только то, что мог бы взять ты. С мастер-картой принесёт что угодно — и тебе решать, что кому она покажет.
Это главный выбор дизайна, и о нём спрашивает каждый security review. As the user: агент обращается к источнику данных с identity вошедшего человека — delegated permissions в Entra, on-behalf-of, OAuth U2M в Databricks, вход через Okta или Entra в Snowflake, data agent в Fabric. Источник применяет права каждого человека сам, так что Анна видит Техас, а Бен — Огайо, бесплатно. As itself: агент использует один service account — service principal, managed identity, service user в Snowflake, «аккаунт для программы, а не для человека». Все, кто говорит с агентом, видят одни и те же данные, поэтому фильтровать должен ты: row access policies в Snowflake, row filters в Unity Catalog, RLS в Fabric или твой собственный код. Правило: отвечаешь людям → действуй от имени пользователя; фоновые задачи вроде ночной индексации → маленькая service identity.
- Что это
Выбор: агент действует с identity каждого пользователя или со своей собственной service identity.
- Пример
Ассистент по контрактам ищет в SharePoint от имени пользователя; отдельный фоновый индексатор работает как service identity с небольшим набором application permissions.
- Подвох
Для медицинских и других чувствительных данных это ключевой вопрос ревью. С одной общей identity будь готов точно показать, как фильтруются строки.
- Связи
Собирается из Delegated vs Application Permissions, Cross App Access, Service User; главный вопрос Security Review.
Security Review — экзамен перед запуском
Приёмка здания перед открытием: инспектор обходит его с чек-листом, и двери открываются только после последней галочки.
Security review — проверка твоего решения командой безопасности клиента перед запуском. Вопросы предсказуемы, так что готовь ответы заранее — лучше всего коротким документом со списком всех подключений. Куда уходят данные, в каком регионе работает модель, какая LLM и по какому контракту (data residency)? Есть ли API-ключи? Правильный ответ: «нет — managed identity, секреты в Key Vault». Закрыты ли сервисы от интернета? Минимальны ли роли? Агент действует от имени пользователя или от своего, и кто что видит? Что он может сделать сам — записать, удалить, отправить письмо, — и есть ли подтверждение человеком? Что попадает в логи, на какой срок и есть ли персональные данные в промптах? Как отозвать доступ — выключить пользователя, удалить enterprise app — и работает ли это сразу? Ещё всплывают защита от prompt injection и content filters.
- Что это
Проверка командой безопасности клиента потоков данных, identities, прав, логов и отзыва доступа перед запуском.
- Пример
Ты приносишь карту на одну страницу: каждое подключение, его identity, его роль и зачем оно нужно — плюс таблицы аудита, где виден каждый запрос.
- Подвох
Сильнее всего ревьюеров пугают права на чтение всего от имени приложения (
*.Read.All). Будь готов обосновать каждое или заменить его delegated-доступом.- Связи
Проверяет Least Privilege, As the User vs As Itself, Private Endpoint, Key Vault.
Day-One Access — начни с самого медленного
Заказать костюм на свадьбу у портного: примерки занимают недели, поэтому заказываешь в день, когда пришло приглашение, а не за неделю до свадьбы.
В компании среднего размера доступы — обычно самая медленная часть всего проекта. Гостевой аккаунт, роль на resource group, app registration с admin consent, service user в Snowflake, права в Unity Catalog, настройка tenant в Fabric «Service principals can call Fabric public APIs» — каждое из этого тикет к другому админу, и вместе это может занять от одной до трёх недель. Ты не админ и не станешь им. Поэтому в первый же день отправь одно сообщение со всем сразу: redirect URIs, scopes, app roles, группы, права — и зачем нужно каждое. Для Snowflake пришли готовый SQL-скрипт, который админ просто запустит. Сначала проси preview/тестовую среду. И проверь квоту модели в нужном регионе до того, как начнёшь строить, а не в день демо.
- Что это
Привычка запрашивать все аккаунты, роли и настройки в самом начале, одним точным списком.
- Пример
День 1: гость + Contributor на
rg-ai-agent-dev, детали app registration, скрипт дляSVC_AI_AGENT, контакт админа Fabric, проверка квоты.- Как избежать
Найди каждого админа заранее — админ Fabric часто не тот же человек, что админ Azure. Веди запросы как задачи, с ответственными и сроками.
- Связи
- Практическая сторона Least Privilege; питает Security Review.
Как всё связано
Пазл: отдельный кусочек мало что значит; вместе они складываются в картину.
Понятия этого курса — одна система. Ветка облака — resource hierarchy Azure, managed identity, Key Vault, private endpoints и Foundry — отвечает на вопрос, где работает агент и как он обходится без секретов. Ветка идентичности — IdP и SSO, OIDC, Entra ID с app registrations, permissions, app roles и Conditional Access, Okta со SCIM и Cross App Access, и Agent ID — отвечает на вопрос, кто такие агент и его пользователи. Ветка данных — от lake до lakehouse, Snowflake, Databricks, Fabric — отвечает на вопрос, что агенту можно читать. Все три сходятся в твоём агенте, а держат их вместе least privilege, выбор между действием от имени пользователя или от своего и security review.
- Кто админы — Azure, Entra или Okta, платформа данных, Fabric — и отправил ли я каждому точный список?
- Где работает агент — Container App с managed identity, роли на одну resource group?
- Как входят люди — OIDC через IdP клиента, app roles или отфильтрованные группы, стабильные ID пользователей?
- От имени пользователя или от своего — а если от своего, как фильтруются строки?
- Что он читает — только gold-таблицы или views, только на чтение, через маленький compute, который засыпает?
- О чём спросит безопасность — ключи, сеть, роли, логи, data residency, отзыв доступа — и записаны ли мои ответы?
- Tenant, subscription, resource group — и почему роль на одну RG лучше, чем на подписку.
- Managed identity, Key Vault, private endpoint — приложение без ключей и без публичной двери.
- IdP, SSO, OIDC, SAML — и почему пользователей ключуют по
oid+tidилиsub, а не по email. - App registration vs service principal, delegated vs application permissions, admin consent.
- App roles, Conditional Access, Microsoft Graph, Entra Agent ID.
- Okta org, Universal Directory, SCIM, org vs custom authorization server, Cross App Access.
- Data warehouse, data lake, lakehouse, Delta Lake, medallion.
- Virtual warehouse, credits, service user, Cortex; Unity Catalog, SQL warehouse, OAuth M2M, Agent Bricks.
- OneLake, capacity, F SKU, SQL analytics endpoint, shortcut, mirroring, data agent.
- Least privilege, service account, security review.
Шпаргалка: все 42 понятия
Карта
- Enterprise Stackоблако · идентичность · данные
Три слоя в каждой большой компании; твой агент сидит между ними.
Облако: Azure
- Microsoft Azureоблако Microsoft
Знакомые облачные идеи под другими именами; выбирают, потому что «всё Microsoft».
- Resource Hierarchytenant · subscription · RG
Вложенные папки; роль, выданная выше, действует на всё ниже.
- Container AppsApp Service · AKS · Functions
Serverless-контейнеры — обычный дом для бэкенда агента.
- Managed Identityбез пароля
Аккаунт приложения, который получает токены от Entra; утекать нечему.
- Key Vaultсейф для секретов
Где живут немногие настоящие секреты; читаются с узкой ролью.
- Private EndpointVNet
Частный IP для сервиса, чтобы закрыть его от интернета.
- Microsoft Foundryбывший Azure AI Foundry
Model deployments, агенты и evals внутри tenant клиента.
Идентичность: Entra ID
- Identity ProviderIdP · SSO
Стойка компании; один рабочий аккаунт открывает все приложения.
- OIDC and SAMLauth code + PKCE
Как приложения логинят людей через IdP; для нового кода — OIDC.
- Microsoft Entra IDбывший Azure AD
Облачный каталог людей, групп и приложений от Microsoft.
- App Registration vs Service PrincipalEnterprise app
Паспорт приложения и его копия в tenant, которая держит права.
- Delegated vs Application Permissionsconsent
Действовать как пользователь или как само приложение с admin consent.
- App Rolesroles claim
Твои роли, которые их IT назначает группам, а твой бэкенд проверяет.
- Conditional Accessправила MFA
Правила «если — то» при каждом входе; нужна Entra ID P1.
- Microsoft Graphgraph.microsoft.com
Один API к данным Microsoft 365, ограниченный scopes токена.
- Entra Agent IDagent blueprint
Тип identity для ИИ-агентов, которым управляют как сотрудником.
Идентичность: Okta
- OktaWorkforce Identity
Нейтральный IdP для компаний со смесью вендоров; по org на компанию.
- SCIMjoiner–mover–leaver
IdP сам создаёт и выключает пользователей в твоём приложении.
- Authorization Serverorg vs custom
Org — для входа; custom — для scopes твоего собственного API.
- Cross App AccessXAA · Agent SSO
Агенты получают через Okta короткие залогированные токены к другим приложениям.
Данные: Snowflake
- Warehouse · Lake · Lakehouseтри формы
Строгие таблицы, сырые файлы или файлы с правилами таблиц сверху.
- Snowflakeоблачное хранилище данных
SQL-аналитика с разделёнными storage и compute.
- Virtual Warehousecredits
Вычислительный кластер с посекундной оплатой; ставь auto-suspend на 60.
- Roles and RBACAI_AGENT_RO
Права — ролям, роли — пользователям; агенту только views.
- Service UserTYPE = SERVICE
Аккаунт программы; key pair или OAuth, пароли заблокированы.
- CortexИИ рядом с данными
LLM-функции, text-to-SQL, поиск и агенты внутри Snowflake.
Данные: Databricks
- Databrickslakehouse-платформа
Файлы в хранилище клиента; Spark, SQL и ИИ на тех же таблицах.
- Delta LakeParquet + журнал
Папка файлов, которая ведёт себя как транзакционная таблица.
- Unity Catalogодин охранник
Права, маски, lineage и аудит для любого пути внутрь.
- Medallionbronze · silver · gold
Слои качества; агент читает gold.
- SQL WarehouseOAuth M2M
Compute для SQL; serverless стартует за секунды, classic — за минуты.
- Agent Bricksбывший Mosaic AI
ИИ-зонтик Databricks: модели, serving, gateway, AI Search, Genie.
Данные: Fabric
- Microsoft FabricOneLake
Одно хранилище и один счёт для всех инструментов данных Microsoft.
- CapacityF SKU · CU
Общий пул вычислений; перерасход ведёт к throttling.
- SQL Analytics EndpointT-SQL только на чтение
Lakehouse, видимый как SQL Server; идеален для чтений агента.
- Shortcuts and Mirroringбез ETL
Указать на внешние данные или держать их живую копию в OneLake.
- Fabric Data AgentFabric IQ
Встроенный «чат с данными» только на чтение, от имени пользователя.
Собираем всё вместе
- Least Privilegeминимальные права
Только то, что нужно для работы, на самый узкий охват.
- As the User vs As ItselfOBO vs service account
Права каждого пользователя или одна identity, чей вывод фильтруешь ты.
- Security Reviewодобрение клиента
Предсказуемые вопросы; держи ответы записанными.
- Day-One Accessсписок доступов
Запроси всё в первый же день, одним точным сообщением.
ИИ-агент внутри компании — это прежде всего проект про доступы. Запускай его в их облаке без ключей, логинь людей через их IdP, читай самый маленький срез данных и проси всё в первый же день.