Как Databricks съкращава времето за разследване на инциденти с ИИ

Публикувано от Svetni.me Editorial на 24 август 2026 г.

Как Databricks използва ИИ за разследване на инциденти
Изображение: Svetni.me / ИИ генерирано изображение

В официално споделен технически анализ [1] екипът на Databricks разкрива как използва изкуствен интелект (ИИ), за да ускори процесите по разследване на инциденти и да поддържа стотици микроуслуги, разположени в над 1500 Kubernetes клъстера. Управлението на толкова мащабна инфраструктура, обхващаща повече от 70 региона и три различни облачни платформи, поставя сериозни изпитания пред инженерите по надеждност на сайтовете. Когато възникне критичен срив в ранните часове на денонощието, дежурният инженер трябва светкавично да отговори на един основен въпрос: „Какво се промени?“ [1].

За да реши този проблем, компанията разработва AI SRE – интелигентен агент за отстраняване на грешки, който започва разследване в момента, в който се задейства дадена аларма. Той автоматично съпоставя сигнали от различни нива на софтуерния стек и навигира инженерите по надеждност към установяване на първопричината за проблема.

Архитектура на AI SRE за автоматизиран анализ на инциденти
Изображение: Svetni.me / ИИ генерана инфографика

Анатомията на нощния инцидент

В традиционния работен процес при възникване на инцидент (например скок в латентността на клиентско API), дежурният SRE (Site Reliability Engineering) специалист обикновено преминава през дълга поредица от ръчни действия. Това включва проверка на логовете на услугите, търсене на скорошни внедрявания (deployments) на код, преглед на конфигурационни промени и съпоставяне на метрики от различни системи. Въпреки че отделните инструменти за наблюдение функционират добре сами по себе си, връзката между техните сигнали се изгражда изцяло в съзнанието на инженера [1].

Опитните специалисти, които познават архитектурата в детайли, често се справят бързо, но по-новите членове на екипа губят часове или са принудени да ескалират инцидента. Наблюденията на Databricks показват, че основните пречки пред бързото решаване на проблеми са три:

  1. Времето, изгубено в превключване между контексти и събиране на данни от различни инструменти.
  2. Повтарящото се изпълнение на едни и същи диагностични процедури (runbooks), които често са остарели или зле документирани.
  3. Липсата на автоматизирано съпоставяне на инфраструктурните аномалии с кода на приложенията.

Проучването на тези модели показва, че макар разследването да е поредица от повтарящи се стъпки, крайната оценка изисква експертна преценка. Следователно решението не е пълно автоматизиране на отстраняването на инциденти, а създаването на платформа с изкуствен интелект, която да предоставя по-бърза и структурирана диагностика на екипите [1].

Тристранната стратегия за автоматична триаж

AI SRE предоставя две взаимно допълващи се преживявания: автоматичен триаж (проверка) веднага след възникване на инцидент и интерактивно разследване, при което инженерите могат да задават въпроси. Автоматичният триаж стартира незабавно в три паралелни направления:

  • Проверки на системната среда: Анализира се състоянието на клъстерите и облачните региони, в които работи засегнатата услуга. Това позволява на инженерите незабавно да изключат общи инфраструктурни сривове (например прекъсвания при доставчика на облачни услуги) и да се фокусират върху софтуерния код на самото приложение.
  • Анализ на ниво услуга: Извличат се логове, метрики и трасировки за съответната микроуслуга и нейните преки зависимости. Системата сканира за неотдавнашни промени в кода или конфигурациите и идентифицира аномалии спрямо базовото поведение на услугата (например открива, че натоварването на процесора е скочило трикратно точно по време на внедряване на нова версия, променяща размера на партидите данни).
  • Изпълнение на специфични runbooks: AI SRE приема ролята на експерт в конкретния домейн. Екипите могат да превърнат своите статични ръководства в динамични ИИ умения (skills), които черпят информация от кодовата база, хронологията на инцидентите и наблюдаваните метрики. Тези стъпки се изпълняват за секунди, вместо за десетки минути.

Когато натовареният дежурен инженер отвори лаптопа си, той вече разполага с цялостна диагностична справка: какво е счупено, какво се е променило и какво препоръчва съответният runbook [1].

Архитектурните слоеве на системата

За да постигне надеждност в критични среди, Databricks проектира AI SRE като модулна платформа с четири ясно дефинирани архитектурни слоя:

  1. Примитиви (Primitives): Това са суровите операционни данни – метрики, аларми, логове, информация за версиите и кодовата база. Този слой не заменя съществуващите observability инструменти, а ги признава за единствен източник на истина.
  2. API слой (API Layer): Предоставя контролиран и унифициран достъп до примитивите. Тук са разположени специализираните API за наблюдение, внедряване и аларми. Този слой се грижи за автентификацията, ограниченията на трафика (rate limiting) и нормализирането на данните. Това гарантира, че ако основна система бъде сменена, инструментите над нея няма да се счупят.
  3. Основен двигател (Core Engine): Сърцето на интелигентността, което съдържа бот рамка за изграждане на сценарии и управлява паралелното изпълнение на задачите, корелацията на резултатите и синтеза чрез големи езикови модели (LLM).
  4. Слой на приложенията (Application Layer): Мястото, където се изпълняват триаж ботовете, специфичните за различните екипи ИИ runbooks и евентуални външни инструменти за сигурност и анализ [1].

Инженерни принципи за доверие

Изграждането на ИИ система за работа при инциденти, където доверието е най-ценният ресурс, налага спазването на строги инженерни правила:

  • Структурирани проверки преди разсъждения с LLM: AI SRE винаги изпълнява първо детерминистичните системни тестове и runbooks. Езиковият модел се използва само за синтезиране и обяснение на резултатите, а не за самостоятелно вземане на решения относно събирането на данни.
  • Прозрачност пред сляпо доверие: Всяко заключение на агента е придружено с хиперлинк към съответното доказателство – конкретен лог, метрика или промяна в кода. Инженерите никога не биха действали по препоръка, която не могат да подложат на одит.
  • Плавно влошаване на качеството на услугата (Graceful Degradation): Ако AI SRE не успее да идентифицира първопричината с висока степен на увереност, той изрично признава това и представя събраните доказателства, сортирани по значимост. Частичното и честно разследване е много по-полезно от халюцинирана диагноза [1].

Резултати и практически поуки

Към момента AI SRE поддържа над 150 екипа в рамките на Databricks. Системата се радва на повече от 250 активни потребители седмично, които извършват над 2000 разследвания всеки ден, спестявайки значително време на дежурните специалисти.

Опитът на компанията показва четири критични извода за софтуерната индустрия. Първо, екипите трябва да притежават и поддържат собствените си runbooks като съставими ИИ компоненти, вместо да се разчита на един голям и остаряващ централизиран агент. Второ, изграждането на стабилен контекстен слой с унифициран достъп до данни е по-важно от оптимизирането на самите подсказки (prompts) към езиковите модели. Трето, ИИ агентите изискват много по-сериозни защитни стени и ограничения на трафика (API guardrails) от хората, тъй като те изпращат паралелни вълни от заявки към вътрешната инфраструктура и могат лесно да я претоварят в критичен момент [1].

В бъдеще Databricks планира да разшири възможностите на AI SRE от разследване на инциденти към навигирано отстраняване на проблемите, помагайки на инженерите да вземат безопасни коригиращи мерки в реално време.

Източници:

[1]: How Databricks Uses AI to Accelerate Incident Investigation - Databricks Blog