Наблюдението на системите за наличност и скорост, и сигнализирането на отклонения преди потребителите да усетят последствията, е задача, която до голяма степен може да бъде поета. Не защото AI изведнъж разбира от инфраструктура, а защото самата задача от години е изградена около метрики, прагове и повторяемост. Това е различно заключение спрямо задачи, при които преценката или преговарянето са същината.
Три оси са определящи тук: обем, структурираност и цена на грешката.
Обемът е висок. Мониторингът протича непрекъснато, денонощно, върху стотици или хиляди измервателни точки. Човек, който би го проследявал ръчно, поглежда таблата през интервали и пропуска какво се случва между тях. Система, която измерва всяка секунда и сравнява с прагова стойност, не пропуска това.
Структурираността е висока. Задачата се състои от: измерване, сравняване с норма, и при отклонение — подаване на сигнал. Това е фиксирана процедура, не отворен въпрос. Сравнете това с отговарянето на потребителски въпрос за софтуер, където въпросът всеки път е формулиран различно и се нуждае от контекст.
Цената на грешката е ниска до средна. Пропуснато или закъсняло известие е неприятно, но обикновено поправимо: системата изпраща ново предупреждение, щом отклонението продължава, а повечето прагови стойности са зададени с марж. Това е различно от задача, при която една пропусната стъпка веднага оставя потребител без работещо приложение, както при разрешаването на инцидент от първа линия в ИТ.
Две оси спъват картината: пространството за преценка и креативността са съответно на 2 и 1.
Сигнализирането на отклонение е нещо различно от разбирането какво означава то за организацията. Пик в използването на паметта може да е безобиден, или начало на проблем, който след два часа ще срине онлайн магазина. Определянето на това значение, и решението за ескалиране до инженер, който да се намеси, остава работа за хора. AI сигнализира отклонението; човек с познания за средата преценява каква е стойността му.
Точно затова тази задача не съществува изолирано. Сигналът, който инструментът за мониторинг подава, трябва да отиде някъде: като регистриран инцидент с правилната спешност. Как продължава оттам, е описано при регистриране и приоритизиране на ИТ инциденти, задача, която е малко по-малко строго дефинирана от самия мониторинг.
Оценката е: агент. Не отделен скрипт, който проверява една прагова стойност, а система, която непрекъснато измерва, комбинира множество сигнали и сама преценява дали даден модел заслужава известие, преди човек да го види. Това е крачка напред спрямо обикновеното сигнализиране, и крачка назад от пълната автономност: агентът сигнализира и категоризира, администратор решава какво се прави със сигнала.
Две гранични условия определят дали това работи. Трябва да има зададени прагови стойности, съобразени с това какво е нормално за конкретните системи: праг, който за едно приложение е достатъчно строг, за друго може постоянно да дава фалшива тревога. И трябва да има автоматизирано известяване, което действително доставя сигнала до някого. Без тези две неща няма какво да се поеме: няма норма, спрямо която да се сравнява, няма канал, през който да се предаде.
При компания с няколко сървъра и фиксирано работно време мониторингът често все още е въпрос на периодично поглеждане. Печалбата в обем от автоматизацията там е ограничена, просто защото обемът е нисък. При компания с много системи, клиенти, които очакват достъп по всяко време на денонощието, и история на инциденти, възникнали през нощта, картината е различна: там капацитетът в еквивалент на пълно работно време, който се освобождава чрез непрекъснато автоматизирано наблюдение, бързо нараства, защото алтернативата е човек, който трябва да е постоянно в готовност.
Оста за цена на грешката също се измества според компанията. При вътрешна тестова среда пропуснато известие е без последствия. При система, която пряко засяга платежен трафик или медицински данни, летвата за съответствие е по-висока, а това избутва оста за съответствие, която тук вече е на 4, още повече в посока задължително документиране и доказуема последваща реакция.
Това не е твърдение за персонала. Дали и как една организация ще използва по друг начин освободения капацитет на системен администратор е избор на работодателя, със собствени законови изисквания, доколкото това засяга решения за длъжности. Тази страница описва само работата, не хората, които я вършат сега.
Мониторингът рядко е изолирана задача. Той е свързан с извършване и проверка на резервни копия, с обработката на инциденти, и с планирането кой кога трябва да е на разположение за последваща реакция. Който иска по-широка представа какво AI може да поеме в ИТ функцията като цяло, може да намери отправна точка на страницата за работа и планиране.
Тази страница дава оценка въз основа на задачата в общ вид. Колко от това важи за конкретна компания зависи от броя на системите, зададените прагови стойности и последствията от пропуснато известие. Индикация за собствената ситуация може да се получи с безплатния бърз скенер: дванадесет въпроса, без акаунт, с индикация каква част от часовете в този профил могат да бъдат поети от AI днес. Пълният работен скенер, който разбива работата на цяла компания на задачи, все още е в процес на разработка.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.