Як NTT DATA скоротила аналіз інциденту з Codex до 30 хвилин

OpenAI повідомляє, що NTT DATA Group розгорнула Codex приблизно для 9 000 працівників, а один ранній workflow виконав складний аналіз інциденту за 30 хвилин — роботу, яка раніше займала три дні у п’яти досвідчених інженерів. Це сильний сигнал про можливість стискати investigation loop, але customer story не розкриває клас інциденту, обсяг журналів, критерій завершення, повторюваність результату чи незалежний аудит.

Тому сторінка не перетворює 30 хвилин на універсальний benchmark і не стверджує про 99,3% економії для іншої команди. Її окремий пошуковий намір — відтворювана організація Codex-assisted incident analysis. Загальний матеріал про autonomous coding agents пояснює sandbox і patch gates, а playbook incident response — containment та recovery; тут вони сходяться в одному evidence-first investigation workflow.

Incident commander спочатку створює task contract: incident ID, часовий інтервал, affected services, дозволені джерела, known facts, відкриті питання, критерій достатнього evidence і явні заборони. Codex може читати очищені logs, traces, deploy manifests, repository snapshots і runbooks; production console, live credentials, customer records та destructive commands не стають доступними лише тому, що агент здатний ними скористатися.

Automation Level A3 описує корисну межу: агент самостійно досліджує, запускає дозволені локальні команди, будує й відкидає гіпотези та готує висновок. Рішення про containment, rollback, повідомлення клієнтів або merge remediation належить людям і детермінованим change controls. Публічне джерело не доводить автономної production remediation, тому підвищувати кейс до A4 чи A5 було б безпідставно.

• Scope → конкретний incident, systems і time window;
• Evidence → незмінні snapshots із provenance та access policy;
• Actions → read-only queries і sandboxed reproduction;
• Output → hypotheses, citations, uncertainty та reproduction steps;
• Authority → жодного production commit без окремого human-owned workflow.

Корисний агент не просто стискає журнали в оповідь. Ingestion layer нормалізує timestamps і service identifiers, редагує secrets та PII, обчислює hashes і зберігає посилання на immutable originals. Timeline builder поєднує alert, deployment, configuration change, trace anomaly та operator action, але кожен зв’язок позначає як observed, inferred або unknown.

Далі hypothesis loop формулює причинне припущення, перелічує evidence за і проти, пропонує discriminating test і виконує його лише в дозволеному середовищі. Якщо даних бракує, правильний результат — запит конкретного артефакту або abstention, а не правдоподібна root cause. Фінальний bundle містить claim-to-evidence map, команди відтворення, невизначеність, альтернативні пояснення і список дій, які агент не виконував.

• collect → зафіксувати джерело, час, hash і policy class;
• normalize → узгодити часові зони, IDs та схеми;
• correlate → відділити спостереження від висновку;
• test → перевірити гіпотезу на snapshot або replay;
• report → дати reviewer відтворюваний evidence bundle.

NTT DATA, за описом OpenAI, формалізувала правила для допустимих даних, підключених систем, network traffic, sandbox mode, рівня автоматизації та human review. Це важливіше за загальне навчання prompt engineering: authority має бути закодована в середовищі виконання, а не залишена побажанням у текстовій інструкції.

Для incident workflow базовий профіль — read-only artifact store, ephemeral workspace, deny-by-default network, allowlist інструментів, redacted environment і повний command log. Тимчасовий доступ видають під incident ID та автоматично відкликають. Якщо reproduction потребує реального секрету або live write, агент готує план і зупиняється; уповноважений інженер вирішує, чи виконувати дію через наявний operational procedure.

Reviewer не повинен приймати гарно написаний postmortem за доказ. Перша перевірка — coverage: чи всі consequential claims посилаються на доступний артефакт. Друга — temporal consistency: причина мусить передувати наслідку. Третя — counterfactual test: чи зникає симптом на known-good configuration або відтворюється після повернення suspected change. Четверта — alternative hypotheses: чи пояснює інша подія ті самі сигнали краще.

Release gate для висновку може вимагати zero unsupported causal claims, resolvable evidence references, повторювані команди, явну uncertainty і sign-off service owner. Окремо перевіряють process safety: неекспоновані secrets, відсутність live side effects і повний audit trail. Agent judge корисний для структури звіту, але causal acceptance та operational action не делегують тій самій моделі, що створила гіпотезу.

OpenAI описує внутрішній Center of Excellence NTT DATA, який підтримує license distribution, technical validation, events, use-case development, usage monitoring, knowledge resources і системи для adoption. Для incident analysis CoE має перетворювати локальну перемогу не на універсальний prompt, а на versioned package: task template, data-classification rules, sandbox profile, eval cases, evidence schema, reviewer checklist і rollback procedure.

Пакет отримує owner і lifecycle: proposed, sandboxed, reviewed, approved, monitored, deprecated. Service teams зберігають ownership інцидентів, тоді як CoE курує reusable controls і порівнювану telemetry. Відкликання package version повинно зупинити нові runs без видалення старих evidence bundles. Так масштабування не розмиває відповідальність і не переносить один успішний кейс на несумісні системи.

Time-to-analysis вимірює швидкість підготовки reviewable bundle, а не автоматично mean time to recovery. Операційний scorecard також містить evidence coverage, hypothesis precision після human review, reproduction success, reviewer time, escalation rate, policy violations, secret exposure, cost per accepted investigation і частку звітів, що змінилися після delayed ground truth.

Reported 30 minutes варто зберігати як provider-attributed result одного описаного workflow. Для власного pilot команда фіксує baseline method, incident class, engineer-hours, input volume і definition of done. Порівняння чесне лише на схожих incidents; швидкий, але хибний causal report може подовжити containment і бути гіршим за повільний ручний аналіз.

Почніть із закритого інциденту, для якого є очищені logs, repository snapshot, deployment history, підтверджена root cause і postmortem. Приховайте фінальний висновок, дайте агенту bounded evidence package та виміряйте, чи побудував він правильну timeline, чи відкинув хибні гіпотези й чи створив відтворюваний report без недозволених дій.

Після кількох replay cases можна перейти до shadow mode на живих розслідуваннях: агент готує bundle паралельно, а команда не використовує його для containment. Canary починається з low-severity, reversible scenarios і обов’язкового reviewer. Rollback означає повернення до ручного runbook та відкликання agent package; зібрані traces залишаються для regression evaluation, але не змінюють indexing або production-launch gates сайту.