# У подтверждения для каждого использования есть точка безубыточности Подтверждение для каждого использования оправдано лишь до тех пор, пока оно перехватывает достаточно необычные вызовы, требующие нового решения человека. Когда обычная работа в production создаёт непрерывный поток запросов, этот контроль заставляет команду снова и снова платить за одно и то же решение. Точка безубыточности обычно ниже, чем ожидают: сам клик почти ничего не стоит. Основную цену составляют ожидание, чтение контекста для уверенности в запросе и восстановление после прерванной мысли. Для полезного сравнения нужны две отдельные книги учёта. В одной учитывается время оператора. В другой - последствия для безопасности от более широкого окна разрешений. Если смешать их, получаются плохие выводы вроде `двенадцать запросов раздражают` или `в production всегда нужен клик`. Ни один из них не показывает, меняет ли запрос решение. Модель ниже назначает цену прерыванию, не притворяясь, что разрушительная команда к базе данных несёт тот же риск, что и вызов статуса только для чтения. ## Рассчитайте полную стоимость одного подтверждения Полная стоимость одного подтверждения складывается из времени ответа и той доли восстановления после прерывания, которую действительно вызвал запрос. Используйте секунды, а не расплывчатые оценки вроде «низкое трение». Определим значения: - `p`: подтверждений в день - `t`: медианное число секунд от появления запроса до завершённого решения - `r`: медианное число секунд, нужное для возвращения к прерванной задаче - `q`: доля запросов, пришедших во время сосредоточенной работы - `d`: разработчики, чьи индивидуальные количества запросов представлены в `p` Если `p` задано на одного разработчика, дневные затраты команды будут такими: ```text per_use_seconds = p * d * (t + q * r) ``` Если `p` уже включает все подтверждения команды, уберите `d`: ```text per_use_seconds = p * (t + q * r) ``` Это различие предотвращает самую частую ошибку в таблицах: взять общее число запросов команды и ещё раз умножить его на размер команды. Подписывайте единицу рядом с каждым входным значением. `8 prompts/person/day` и `48 prompts/team/day` могут описывать одну и ту же команду из шести человек. Для `t` берите медиану, потому что несколько брошенных запросов могут исказить среднее. Но не скрывайте такие запросы: учитывайте их число отдельно как незавершённую работу. Для восстановления измеряйте время до того момента, когда разработчик вернулся к предыдущему осмысленному действию, а не до закрытия окна подтверждения. Разработчик, который одобрил запрос за девять секунд, а затем две минуты восстанавливал запрос, потратил 129 секунд, а не девять. Член `q` не даёт модели приписывать восстановление запросам, обработанным между задачами. Если пока не можете его измерить, рассчитайте диапазон при `q = 0.5` и `q = 1`. Такой диапазон честнее точного числа, построенного на догадке. ## Считайте запросы на границе, которую ощущает человек Считайте каждое решение, которое должен принять человек, а не каждый API-запрос и не каждое уведомление, отправленное системой. Одна карточка одобрения, покрывающая пять повторных попыток, - одно подтверждение. Пять карточек, созданных циклом автоматических повторов, - пять подтверждений, даже если логически операция одна. Модель оценивает человеческую работу, поэтому её единица должна совпадать с человеческой границей. Начинайте отсчёт, когда запрос становится доступен для действия. Карточка, которая появилась, но непонятна без открытия терминала, уже забрала время ответа. Включайте отказы, просроченные запросы и дубликаты, потому что они занимают внимание. Автоматические вызовы, которые никогда не спрашивают человека, записывайте отдельно: они важны для риска и пропускной способности, но не имеют прямой стоимости подтверждения. Форма всплесков важна, даже если дневное число остаётся тем же. Двадцать запросов, распределённых на десять часов, могут быть терпимыми. Те же двадцать во время релиза способны остановить единственных людей, которые умеют диагностировать релиз. Ведите простой максимум подтверждений в любом 15-минутном окне. Дневное уравнение оценивает трудозатраты, а показатель всплеска показывает операционную задержку. Не считайте оповещения, отправленные нескольким людям, несколькими подтверждениями, если их не проверяют несколько человек. Если производственный запрос уходит четырём разработчикам и двое обычно открывают его до того, как один одобрит, запишите два человеческих ответа. Граница затрат - не доставка уведомления, а внимание. Для надёжной записи события достаточно нескольких полей: ```text ts, request_id, responder, decision, shown_at, decided_at, prior_task_resumed_at, key_class 2026-07-21T14:03:10Z, r-1842, dev-3, allow, 14:03:10, 14:03:22, 14:05:01, deploy-read ``` В этой строке `t` равно 12 секундам, а наблюдаемое восстановление - 99 секундам. Запись также помогает найти повторные запросы для одной операции, неравномерную нагрузку между отвечающими и дорогие классы ключей, не собирая секрет или полезную нагрузку запроса. ## Сессионная авторизация меняет смысл одобрения Сессионная авторизация не убирает подтверждение. Она переносит решение с каждого использования на начало ограниченного запуска агента. Поэтому единица сравнения меняется с вызовов на сессии. Подтверждение сессии должно идентифицировать процесс и завершаться при его выходе. Одобрение, привязанное лишь к понятному имени или открытому временному окну, - другой и более слабый контроль. Пусть `s` - число новых сессий агента на одного разработчика в день, а `a` - медианное число секунд на проверку и одобрение сессии. Дневные затраты времени оператора: ```text session_seconds = d * s * a ``` Арифметика быстро склоняется в пользу сессий, потому что одно решение может покрыть много вызовов. Цена для безопасности - более широкие полномочия внутри одобренного запуска. Скомпрометированный или ошибочно направленный процесс может сделать другой разрешённый вызов без нового запроса. Поэтому одно сравнение времени не может назвать универсального победителя. У сессии должен быть однозначный конец. Выход процесса легко анализировать: разрешение исчезает вместе с процессом, который его получил. Фиксированное восьмичасовое окно может пережить задачу, передачу смены и покрыть более позднее действие, о котором никто не думал во время одобрения. Если система авторизации не умеет отозвать активную сессию или показать, какой процесс ею владеет, учитывайте это как дефект контроля, а не как бесплатную возможность. Запрос на сессию также должен дать отвечающему достаточно данных об идентичности для решения. Имена путей и метки агентов можно скопировать. Центр сертификации подписи кода, идентичность исполняемого файла и контекст запуска дают более сильные доказательства того, что именно стартовало. Человек одобряет субъект на определённый период, а не благословляет фразу о том, что агент хочет доступ. ## Уравнение безубыточности показывает настоящий порог Подтверждение для каждого использования требует больше времени оператора, когда его дневные полные секунды превышают стоимость одобрений сессий. Для числа запросов на одного разработчика приравняем уравнения: ```text p * d * (t + q * r) = d * s * a p_break_even = (s * a) / (t + q * r) ``` Размер команды сокращается, когда у всех разработчиков одинаковые частоты запросов и сессий. Это не делает `d` неважным. Порог на человека не меняется с ростом команды, а общая стоимость растёт с обеих сторон. Размер команды снова важен при неравномерной работе, когда один запрос проверяют несколько отвечающих или сессии агентов запускает лишь часть команды. Рассмотрим шесть разработчиков. Каждый запускает два производственных запуска агента в день, а решение по сессии занимает 15 секунд. Медианное время решений для каждого использования - 12 секунд. Семьдесят процентов запросов приходят во время сосредоточенной работы, а медианное восстановление занимает 90 секунд. ```text p_break_even = (2 * 15) / (12 + 0.70 * 90) p_break_even = 30 / 75 p_break_even = 0.4 confirmations per developer per day ``` При восьми запросах на разработчика в день команда обработает 48 запросов. Их полная стоимость: ```text 48 * (12 + 0.70 * 90) = 3,600 seconds = 60 minutes/day ``` 12 одобрений сессий стоят `6 * 2 * 15 = 180 seconds`, то есть три минуты. Разрыв составляет 57 минут в каждый производственный день. Если учитывать только клики, для подтверждения каждого использования получится 9,6 минуты и большая часть стоимости останется незамеченной. Порог 0,4 не означает, что каждой сессии надо давать широкий доступ. Он говорит, что повторяющиеся запросы уже стали более дорогим способом одобрять сопоставимые обычные вызовы. Оставляйте решения для каждого использования для вызовов, последствия которых могут меняться от запуска к запуску. Переносите предсказуемую ограниченную работу в рамки сессии, только когда идентичность сессии, её срок, разрешённый канал и отзыв делают такую область приемлемой. Перед действием проверьте чувствительность. При тех же данных, но нулевой стоимости восстановления, порог станет `30 / 12 = 2.5` запроса на разработчика в день. При трёх минутах восстановления он упадёт ниже 0,22. Если рекомендация меняется только при неправдоподобной оценке восстановления, решение устойчиво. Если она меняется во всём вашем правдоподобном диапазоне, измерьте восстановление вместо споров о нём. ## Дешёвый запрос всё равно может задержать всю операцию Затраты труда и прошедшая задержка отвечают на разные вопросы. Уравнение выше суммирует человеческое время, но агент тоже ждёт, пока никто не может действовать. Решение за 15 секунд может занять только 15 секунд труда и всё же добавить четыре минуты к развёртыванию, если карточку не замечают 225 секунд. Отслеживайте оба значения. Первое показывает, во что контроль обходится команде, второе - во что он обходится производственному процессу. Представьте агента, который делает проверку релиза из пяти вызовов: читает состояние развёртывания, получает последние ошибки, проверяет активную ревизию, запускает команду состояния через SSH и записывает результат. Каждый вызов использует ключ, настроенный на подтверждение для каждого использования. Первая карточка приходит дежурному разработчику во время проверки кода. Разработчик проверяет её и возвращается к diff. Следующий вызов приходит через 40 секунд, после того как агент обработал первый ответ. Это повторяется до конца процесса. Пять кликов могут занять всего минуту. Это не одно прерывание: промежутки позволяют разработчику снова войти в проверку и снова отвлекают его. Если каждое прерывание требует 75 секунд на восстановление, полная человеческая стоимость достигает 435 секунд: `5 * (12 + 75)`. Прошедшая задержка агента может быть выше, потому что его работа последовательно ждёт каждого одобрения. Ни одно число не появится, если панель показывает только задержку клика. Теперь предположим, что четвёртый вызов просит выполнить команду состояния на неожиданном хосте. Разработчик отказывает. Этот отказ доказывает, что один запрос содержал полезную информацию, специфичную для вызова. Он не доказывает, что остальные четыре обычных чтения требовали отдельных решений. Более удачный дизайн может авторизовать идентифицированный процесс агента для трёх известных вызовов чтения, сохранить подтверждение для каждого использования для SSH и отклонять хосты вне намеченной области. Модель поддерживает такое разделение, потому что группирует затраты и отказы по классу ключа, а не усредняет весь процесс. Этот сбой также показывает стоимость последовательных подтверждений. Когда вызовы зависят от предыдущих результатов, задержка одобрения оказывается на критическом пути. Для независимых вызовов агент может отправить несколько запросов сразу, создавая всплеск, который должен проверить отвечающий. Дневное уравнение полной стоимости одинаково рассматривает одинаковое число человеческих решений, но операционная форма различается. Когда важны скорость релиза и реакция на инциденты, записывайте прошедшее время процесса или время ожидания агента. Не переводите время ожидания агента напрямую в стоимость труда разработчика. Ожидающий процесс - не работающий человек. Показывайте его как прошедшую задержку, а затем решайте, чему она вредит: длительности развёртывания, диагностике инцидента, автоматическому дедлайну или ничему существенному. Раздельный учёт не даёт получить впечатляющую, но ложную сумму. Та же дисциплина относится к отклонённым вызовам. Отказ предотвращает последствия нежелательного действия, которые могут многократно превысить стоимость прерывания, но без доказательств нельзя назначить им правдоподобную денежную цену. Сообщайте конкретно, что перехватил барьер. `Denied SSH to an unrecognized host` - это доказательство решения. `Approval prevented a major incident` - спекуляция, если расследование не установило такой исход. Используйте разбор сбоя как проверку дизайна. Если удаление четырёх запросов одновременно удалит контекст, нужный для перехвата пятого, предложенная область сессии слишком широка. Если каждый вызов использует отдельный класс ключа, а чувствительный вызов сохраняет свой барьер, обычные запросы добавляют стоимость, не помогая этому решению. Уравнение безубыточности показывает, когда проверить дизайн, а последовательность вызовов - где его разделить. ## Медианное время ответа не показывает очереди и брошенную работу Медианное время ответа описывает типичный обработанный запрос, но производственная работа часто проваливается в хвосте распределения. Запрос, ожидающий единственного авторизованного разработчика, может блокировать агента, развёртывание или проверку инцидента намного дольше медианы. Наряду со значением в уравнении трудозатрат записывайте 90-й перцентиль времени ответа, просроченные запросы и время до первого подходящего отвечающего. Не подставляйте 90-й перцентиль во все расчёты стоимости. Тогда каждый запрос считался бы медленным. Используйте медиану для оценки обычного труда, а хвост показывайте как операционное ограничение. Например: `42 loaded minutes/day; median decision 11s; p90 decision 96s; 3 expirations/week`. Эта короткая строка честнее одного смешанного показателя. У восстановления после прерывания тоже есть хвост. Запрос, пришедший, когда человек читает логи, может стоить полминуты. Запрос, пришедший, когда тот же человек держит в памяти ещё не выполненное исправление базы данных, может потребовать полной перепроверки. Разделите предыдущие задачи на две или три категории: обычная, сосредоточенная и инцидент. Вам нужна граница политики, а не статья о нейронауке. Брошенную работу нужно включать в книгу затрат. Если агент истекает по времени в ожидании, повторяет попытку и показывает другую карточку, первый запрос не стоил ноль только потому, что его никто не одобрил. Считайте полученное им внимание, задержку агента и дубликат, если его потом тоже проверяет человек. Усталость от подтверждений не доказывается только большим числом запросов. Ищите повторные одобрения одного класса ключей, сокращение времени проверки, дубликаты и почти нулевую долю отказов для обычных операций. Эти сигналы говорят, что интерфейс просит людей повторно подтвердить уже принятое решение. Высокая доля отказов означает, что запросы всё ещё отделяют приемлемые вызовы от неприемлемых, даже если они дороги. ## Больше разработчиков меняют координацию, а не множитель Число производственных отвечающих важно, потому что запросы редко распределяются равномерно. Умножение общего числа запросов команды на численность завышает стоимость, а усреднение по всем может скрыть, что почти все прерывания получают два человека. Сначала рассчитайте полные минуты на каждого, затем сложите их. Показывайте медиану, самого загруженного отвечающего и итог команды. Предположим, в производственную группу из десяти человек поступает 60 запросов, но маршрутизация отправляет 45 основной паре. Среднее по команде, шесть запросов на человека, не описывает ничей день. Основным отвечающим может понадобиться сессионная авторизация для обычных вызовов, даже если остальные почти не испытывают неудобств. Ротация основной роли может распределить неудобства, но не уменьшит общую стоимость и может добавить работу по передаче смены. Рассылка нескольким людям создаёт ещё одну стоимость. Когда запрос уходит нескольким людям, одно одобрение завершает ожидание, но другие разработчики уже могли его прочитать. Добавьте `w`, среднее число людей, проверяющих каждый запрос. Тогда форма для общего числа команды будет такой: ```text per_use_seconds = p * w * (t + q * r) ``` Используйте эту форму, только если каждая проверка стоит примерно одинаково. Если победивший отвечающий тратит 20 секунд, а остальные лишь смотрят две секунды, рассчитывайте эти группы отдельно. Модель должна становиться чуть подробнее, когда этого требует рабочий процесс, а не потому, что в таблице есть место для новых ячеек. Стоимость сессий тоже может сосредоточиться. Если производственные запуски начинают только два назначенных оператора, используйте два на стороне сессий, а не десять человек, которые могут получить запрос для каждого использования. Указывайте группу рядом с каждым членом. Численность сама по себе не умножает риск: это делают распределение полномочий и реальное внимание. Здесь также важно владение очередью. Общая очередь одобрений с понятным дежурным отвечающим уменьшает дублирующую проверку. Рассылка каждого запроса всей команде может повысить шанс быстрого клика, незаметно съедая больше общего внимания. Быстрое одобрение и дешёвое одобрение - разные показатели. ## Риск определяет, для каких вызовов сохранить барьеры на каждый раз Объём может показать, что контроль дорог, но последствия определяют, стоит ли продолжать платить. Разделяйте ключи или классы действий по тому, что другой вызов сможет сделать в той же сессии. Инвентаризация только для чтения, запуск развёртывания, изменение production и администрирование учётных данных не должны наследовать одну настройку лишь потому, что их вызывает один агент. В этой области часто смешивают аутентификацию, авторизацию и подтверждение. Аутентификация определяет процесс или человека. Авторизация выдаёт область доступа. Подтверждение просит человека заново оценить одно предложенное использование. Повторное подтверждение не исправляет слабую идентичность процесса, а сильная идентичность не делает широкий доступ безопасным. Если путать эти три вещи, придётся кликать на каждом вызове, одновременно давая разрешение не тому процессу. Сохраняйте подтверждение для каждого использования, когда запрос содержит факты, существенно меняющие решение: целевой хост, класс операции, среду или затрагиваемый ресурс. Разрушительная команда в production может заслуживать новой проверки даже при большом объёме. Если отвечающие одобряют её не читая, потому что она появляется пятьдесят раз в день, дизайн уже провалился. Сократите исходный объём или сузьте разрешённое действие, вместо того чтобы считать быстрые клики контролем. Сессионная авторизация подходит для повторяющихся вызовов, когда человек может один раз принять осмысленное решение о процессе и области. У хороших кандидатов есть ограниченный срок, предсказуемый канал, видимая идентичность, немедленный отзыв и запись аудита, достаточно подробная для восстановления отдельных вызовов. Сессия не должна превратиться во вседневное bearer-разрешение, передаваемое между несвязанными процессами. Часто верным будет гибридное решение. Поместите обычные чтения API и известные проверки развёртывания в сессию, привязанную к процессу. Оставьте подтверждение для каждого использования на небольшом наборе ключей, которые могут менять production или администрировать учётные данные. Так число прерываний уменьшится, а осознанная остановка останется там, где одно действие меняет риск. Не оправдывайте подтверждение для каждого использования тем, что больше запросов всегда означает больше безопасности. Контроль, который одобряют рефлекторно, создаёт много церемоний и плохо различает ситуации. Полезный вопрос в том, достаточно ли часто запрос приводит к другому решению, чтобы оправдать его полную стоимость. ## Измеряйте одну производственную неделю до смены области Одной недели выборки обычно достаточно, чтобы заменить догадки правдоподобным диапазоном, если в ней есть обычная производственная работа и хотя бы один загруженный период. Не создавайте инцидент ради измерения. Экспортируйте события запросов, попросите отвечающих записывать восстановление для небольшой выборки и сделайте таблицу достаточно простой, чтобы её заполнили. Используйте одну строку на каждого отвечающего в день: ```text date | responder | prompts_seen | prompts_allowed | prompts_denied | median_response_s | focus_share | median_recovery_s | sessions_started | median_session_approval_s 2026-07-21 | dev-3 | 11 | 10 | 1 | 12 | 0.70 | 90 | 2 | 15 ``` Рассчитайте эти ячейки: ```text loaded_per_use_min = prompts_seen * (median_response_s + focus_share * median_recovery_s) / 60 session_min = sessions_started * median_session_approval_s / 60 break_even_prompts = sessions_started * median_session_approval_s / (median_response_s + focus_share * median_recovery_s) ``` Затем изучите запросы по классам ключей. Итог по команде может показать, что изменения нужны, но разбивка по классам скажет, что именно менять. Если 80 процентов запросов приходят от проверок статуса только для чтения, а немногочисленные отказы касаются изменения production, перевод всех ключей в один режим уничтожит самую полезную часть доказательств. Записывайте одну причину каждого отказа простыми категориями: неверная цель, неожиданная операция, дубликат или недостаточный контекст. Свободные описания инцидентов трудно агрегировать. Распределение причин показывает, перехватывает ли барьер опасные запросы или компенсирует непонятные карточки. Выборка восстановления не требует слежки. Попросите каждого отвечающего для части запросов отметить `0`, `30`, `90` или `180+` секунд либо выводите возвращение к работе из локальной рабочей трассы, которой он сам управляет. Опубликуйте метод вместе с результатом. Грубое наблюдаемое распределение лучше выдуманной константы с двумя знаками после запятой. До изменения авторизации запишите прогноз: какие классы запросов исчезнут, сколько одобрений сессий их заменит и какие барьеры для каждого использования останутся. На следующей неделе измерьте те же поля. Если число вызовов растёт, потому что агенты могут продолжать без ожидания, сравнивайте человеческие решения, а не необработанное число API-запросов. ## Тратьте подтверждения там, где они могут изменить решение Модель должна давать решение о маршрутизации, а не один глобальный порог. Для каждого класса ключей сравнивайте полные минуты на подтверждения для каждого использования с минутами на одобрения сессий, затем опишите последствия одного дополнительного вызова во время одобренной сессии. Обычные классы с большим разрывом в цене и приемлемыми последствиями сессии можно перенести. Классы с высоким воздействием остаются с подтверждением для каждого использования, даже если их временная стоимость очевидна. Задайте триггер пересмотра по наблюдаемому поведению. Пересчитывайте при удвоении объёма запросов, смене группы отвечающих, изменении длины сессии или сдвиге причин отказов. Порог, скопированный у другой команды, почти бесполезен, потому что время восстановления и рассылка нескольким людям различаются сильнее, чем время клика. Система контроля должна сохранять доказательства после изменения области. Записывайте начало сессии, одобренную идентичность, отзыв и каждый отдельный вызов. Иначе сессионная авторизация выигрывает время, убирая именно тот след, который нужен для расследования действий агента. Убедитесь, что история аудита позволяет обнаружить удаление или изменение записей, не полагаясь на агента, который совершал действия. Sallyport реализует это разделение как фиксированную лестницу: заблокированное хранилище запрещает все действия, новый процесс агента по умолчанию получает одно решение на сессию, а выбранные ключи всё ещё могут требовать одобрения при каждом использовании. Его журналы Sessions и Activity хранят записи уровня запуска и уровня вызова, поэтому изменение области подтверждений не стирает отдельные действия. Не устанавливайте порог на встрече, спрашивая, что кажется раздражающим. Подставьте семь дней запросов в уравнение, держите единицы на виду и отделяйте обычные вызовы от вызовов, чьи факты меняют решение. Сохраните исходную таблицу вместе с решением, чтобы команда могла позже оспорить допущения. Когда человек десятки раз одобрил одни и те же ограниченные полномочия без единого отказа, ещё одна идентичная карточка не сохраняет суждение. Она его расходует.