Бизнес-процесстерді қадағалау: қарапайым метрикалар мен алерттер

Неліктен серверлерді ғана емес, процесті де қадағалау маңызды

Сервер мониторингі жүйенің «тірі» екенін көрсетеді. Бірақ бизнестің көбіне басқа сұрағы бар: «Жұмыс уақытында әрі артық айналымсыз орындалып жатыр ма?» Серверлердің көрсеткіштері жасыл болуы мүмкін, ал өтінімдер апталар бойы кезекте тұруы мүмкін: ешкім оларды өңдемейді немесе үнемі доработкаға жіберіледі.

Тек инфрақұрылымды қарап отырсаңыз, симптомдарды көресіз (CPU жүктемесі, 500 қатесі, диск орны), бірақ нақты нәтижені көрмейсіз. Процесс адамдардан, ережелерден, кезектерден, қолмен тексерулер мен келісулерден тұрады. Көбінесе дәл сол жерлерде кідірістер мен сапаның төмендеуі пайда болады, ал бұл сервер метрикасында көрінбейді.

Темір мен сервистер деңгейінде «көрінбейтін» типтік проблемалар:

• этаптар арасындағы кезектер: құжат дайын, бірақ апта бойы қол қоюды күтіп жатады;
• қолмен істелетін қадамдар: біреу хаттағы мәліметті жүйеге көшіреді, ол ағынды баяулатады;
• қайтарымдар: өтінім бірнеше рет «доработкаға» қайтарылады да мерзім ұзартылады;
• жауапкершіліктің анық болмауы: қазір тапсырма қай кезеңде және кімде екені түсініксіз;
• айналып өтетін ерекшеліктер: бөлім ішіндегі чатта бір бөлігі шешіледі, сол бойынша тарих жоқ.

Бизнес-процестерді мониторингі «барлығы жұмыс істейді» деп айтудан «осы кезеңнен қанша өтінім өткізілді, олардың уақыты мен сапасы қандай» деген сұраққа көшуді қамтамасыз етеді. Тығыз орындарды жылдам табуға болады: қай қадамда артық артқы қатар жиналып жатқанын, қай жерде қайтарымдар жиі болатынын және регламент өзгергеннен кейін жағдай қалай өзгеретінін көруге болады.

Мұнда табыс қарапайым нәрселермен өлшенеді: кідірістер аз, қайтарымдар аз, өту уақыты болжамды және әр кезеңге жауапкершілік анық. Мысалы, сатып алуды келісу үнемі заңгерлік тексерісте «тұрып қалса», бұл дәл сол қадамдағы күту уақыттарының өсуінен көрінеді, жүйенің қатесі жоқ болса да. Мұндай кезде серверден мәселе іздеу емес, ережені, тапсырмаларды бөлу немесе құжат шаблондарын өзгертуге талдау жасау қисынды.

Қайдан бастау: процесті және өлшеу шегін таңдау

Ондаған диаграммалардан емес, нақты қаржылық не сенімге зиян келтіретін бір процеске барыңыз. Көп жағдайда бұл өтінімдерді келісу (сатып алу, командировка, құқықтар), қолдау қызметінің сұраныстарын өңдеу немесе шоттарды шығару болады. Барлығын бірден қамтуға тырыссаңыз, уақыт кетті, пайдалы сигналдар шықпайды.

Мониторинг жұмыс істеуі үшін процестің басталатын және аяқталатын жерлері анық болуы керек. Одан тыс «келісу уақыты» әркімге әртүрлі шығуы мүмкін, және даулар пайдалы эффектіні жояды.

Бір–екі процесс таңдап алу жолы

Кандидаттарды мына қарапайым белгілер бойынша бағалаңыз. Бастауға жарайтын процесс:

• жиі қайталанады (тәулігіне немесе апта сайын);
• айқын кідірістер немесе кезектер бар;
• бірнеше командаларды қамтиды, сондықтан «стыктар» жоғалып кетеді;
• бұған қатысты шағымдар немесе қолмен айналып өту жолдары бар.

Мысалы, ұйымда жабдық сатып алу өтінімін келіседі. Сервер мен пошта «жасыл» болса да, қызметкерлер апталар бойы күтеді, сосын өтінім формадағы бір қате үшін қайта жіберіледі. Мұнда инфрақұрылым жүктемесін емес, процестің тығыз жерлерін көру маңызды.

Өлшеу шегін қарапайым ережелермен бекітіңіз

«Старт = ...» және «Финиш = ...» деген екі сөйлем жазыңыз. Старт — өтінім «Жіберілді» статусын алған сәт болуы мүмкін (а сыны «Жасалған» емес, егер черновиктер ұзақ тұратын болса). Финиш — «Төленді» немесе «Аяқталды», сіз не бақылағыңыз келетініне байланысты.

Содан соң ролдерді бекітіңіз. Процестің иесі болуы керек (шешім қабылдап, ережелерді өзгерте алатын) және деректерге жауапты адам (статустар дұрыс толсын, оқиғалар бірдей түрде тіркелсін).

Және метрикалармен не істейтініңізге алдын ала келісіңіз. Жай ережелер мысалы:

• егер өтінімдердің 10% бір қадамда 48 сағаттан артық «тұрып қалса», сол қадамның жетекшісі күнделікті кезекті талдайды;
• қайтарымдар көбейсе, форма мен чек-лист жаңартылады.

Деректер мен оқиғалар: метрикалар үшін фактілер қайдан

Процесс метрикалары қарапайым фактілерге негізделеді: өтінім қашан пайда болды, оның статусы қалай өзгерді, кім қатысқан, қайтарым болды ма және неге. Жақсы жаңалық: бұл деректер көбіне бар, тек әртүрлі жерлерде жинақталған.

Көп жағдайда «процесс ізі» адамдар күнделікті жұмыс істейтін жерлерде табылады: сервис-деск (инциденттер және сұраныстар), CRM (сделкалар мен келісімдер), корпоративті пошта (хаттар мен жауаптар), кестелер (өтінім реестрі) және ішкі порталдар (формалар мен маршруттар). Тіпті жүйе біреу ғана болса да, қорытынды статусқа ғана емес, өзгерістер тарихы мен комментарийлерге қарау пайдалы. Комментарийлер қайтарым себептерін немесе блоктауға әкелген нақты түсініктемені жиі береді.

Бастапқыда бәрін жинауға тырыспаңыз. «Сұрастыру уақытын», «қайтарымдар үлесін» және «тұрып қалған өтінімдер» дау тудырмай есептеу үшін минималды өрістер жеткілікті:

• өтінім идентификаторы (нөмір);
• не сұралып жатқандығы (тип/тақырып);
• инициатор және келісуші кім;
• құру датасы мен уақыты;
• ағымдағы статус және соңғы өзгеріс уақыты.

Қайтарымдар болса, тағы бір өріс қосыңыз: қайтарым себебі (еркін мәтін емес, алдын ала берілген нұсқалар тізімі). Сол кезде қайтарым үлесі бөлімдер бойынша нақты салыстырылатын болады.

Басты тұзақ — адамдарды артық қолмен толтыруға мәжбүрлеу. Деректерді автоматты түрде алу жақсы: статус өзгерісін оқиға ретінде тіркеу, авторды және уақытты жүйеден алу, ал қайтарым себептерін қысқа тізімнен таңдату.

Мысал ретінде, жұмыс станцияларын немесе серверлерді сатып алуды келісу кезінде қайтарымдар көбіне ТЗ толық емес немесе бюджет қате көрсетілгендіктен болады. Бір ғана батырмамен белгіленсе, метрика сенімді болады, ал «тұрып қалған өтінімдер» туралы хабарламалар шудан тазаланады.

Үш негізгі метрика: анықтамалары дауыспен болмайтындай

Бизнес-процестер мониторингі пайдалы болу үшін метрикалар екі түрлі адам есептесе де бірдей шығатындай анықталуы керек. Төменде алғашқы аптада тығыз жерлерді көрсете алатын үш негізгі метрика берілген.

1) Сұрастыру уақыты

Бұл — өтінімнің анықталған старттан анықталған финишіге дейінгі уақыты. Қате — жүйедегі «қалай шықты» деп есептеу, ережелерге келіспей.

Старт әдетте өтінім «келісуге дайын» болған сәтте тіркеледі: жұмысқа жіберілді, міндетті өрістер толтырылды, құжаттар қосылды. Аяқталу — соңғы шешім қабылданды (бекітілді немесе қабылданбады), біреу қарағаны жеткізбейді.

Пауза қалай есептелетінін бөлек шешіңіз. Екі ыңғайлы нұсқа бар:

• күнтізбелік уақыт (бизнес сезініп жатқандай);
• белсенді уақыт (команда қалай жұмыс істейді).

Мысалы, өтінім инициатордан дерек күтумен 2 күн тұрса, бұл жалпы уақытқа қосылуы да мүмкін (қызмет көрсетуді бағалау үшін) немесе қосылмауы да мүмкін (келісушілердің жылдамдығын бағалау үшін). Екі санды сақтау жақсы, бірақ оларды бір графикте араластыруға болмайды.

2) Қайтарымдардың үлесі

Қайтарым — кез келген түсініктеме емес. Бұл инициатордан түзету талап етілетін статус өзгерісі: «на доработку», «толтыруға қайтарылды», «құжаттар жарамсыз» сияқты. Қайтарым үлесі қарапайым есептеледі: қайтарымдар / сол кезеңдегі барлық өтінімдер.

Метрика басқарылатын болсын десеңіз, қайтарым себептерін жіктеу қажет. 30 категория қажет емес. 4–5 нақты категория жеткілікті. Мысалы: «деректер толық емес», «сома/номенклатура қатесі», «қате маршрут», «құжат жоқ/негіз жоқ», «басқа».

Егер қайтарымдардың 60% — «деректер толық емес» болса, форма мен толтыруға көмек енгізу керек, ал келісушілерге қысым көрсету емес.

3) Тұрып қалған өтінімдер

«Тұрып қалған» — бір қадамда белгіленген шектен ұзақ уақыт өзгеріссіз тұрған өтінім. Маңыздысы — бұл қозғалыс болмауы, жалпы циклдің ұзақтығы емес. Өтінім ұзақ болуы мүмкін, бірақ әр күні әрекеттер жүріп жатса ол «тұрып қалған» есептелмейді.

Екі параметрді анықтаңыз: қандай статустар «әрекет күтуде» деп саналады және қанша сағат/күннен кейін бұл проблемаға айналады. Мысалы: «Жетекшінің келісуінде» 48 сағаттан артық өзгеріссіз — тұрып қалу. Осылайша тар нүктелерді дәл ұстайсыз, ал бүкіл процесті айыптамайсыз.

Нормалар мен шектер: жұмысқа жарамды мақсат қою

Процесс үшін нормалар әдемі сандар үшін емес, әдеттегі тербелістер мен нақты мәселені ажырату үшін қажет. Егер шектер тым қатал болса, хабарламалар үнемі қосылып, оларды оқымай қалады. Егер тым жеңіл болса, ақауды клиенттің шағымымен ғана білесіз.

«Сұрастыру уақыты» үшін орташа мәннен емес, перцентильдерден бастау ыңғайлы. P50 (медиана) типтік уақытты көрсетеді, ал P90 «құйрықтағы» жағдайды көрсетеді, дәл сол жерде кідірістер жасырынған. Практикада P90 жиі ауыр мәселені көрсетеді: сирек, бірақ қатты жағдайлар.

Нормаларды өтінім типтері бойынша бөлеңіз. Шұғыл өтінімдердің маршруты мен күтуі әртүрлі болады. Егер шұғыл және кәдімгі өтінімдерді бір шектеуге араластырсаңыз, жалған дабылдар пайда болады немесе деградация байқалмай қала береді.

Тағы бір дау тудыратын нәрсе — күнтізбе: «24 сағат» және «24 жұмыс сағат» — екі бөлек нәрсе. Келісулер үшін жұмыс уақытын есептеу әдетте әділ болады (мысалы, 09:00–18:00 жұмыс күндері). Солайша жұма кеште жасалған өтінім дүйсенбі таңғысына дейін апатты көрінбейді.

Бірінші мақсатты қою үшін соңғы 2–4 апта дерегінен бастап, шекті қазіргі жағдайдан сәл жақсы деңгейге қойыңыз:

• базаны шығарыңыз: қазіргі P50 және P90 бойынша;
• 2–3 категорияға бөліңіз (мысалы, шұғыл және кәдімгі, немесе бөлімдер бойынша);
• жұмыс уақытын есепке алу керектігін шешіңіз;
• алдыға бір қадам мақсат қойыңыз (мысалы, P90-ды 10–20% жақсарту);
• бұзушылықты қалай анықтайтыныңызды белгілеңіз: «күн бойынша P90 шектен жоғары» немесе «шектен үлкен N өтінім».

Мысал: кәдімгі өтінімдер үшін қазіргі P50 — 6 жұмыс сағат, P90 — 2 жұмыс күні болса, алғашқы мақсат ретінде P50 — 5 сағатқа және P90 — 1,5 күнге дейін түсіру орынды болуы мүмкін. Шұғылдар үшін бөлек: P50 — 1 сағатқа, P90 — 4 сағатқа. Мұндай тәсіл нақты күтулер береді және артық шу шығармайтын қарапайым хабарламаларға негіз болады.

Қарапайым алерттерді баптау: қадамдық схема

Алерт — мессенджер көрінісі үшін емес, адам уақытында араласып, клиент зардап шекпей тұрып әрекет етуі үшін керек. Бизнес-процесс мониторингінде 2–3 түсінікті сигналдан бастап, оны әдетке енгізген жөн, ондаған ережені бірден жасамаңыз.

Бес қадамдық схема

1. Қандай сигнал пайдалы және кімге екенін анықтаңыз. Топ жетекшісіне қозғалыссыз өтінімдер маңызды, орындаушыға жақындап қалған мерзім туралы ескерту пайдалы, ал процес иесіне — қайтарымдардың күрт өсуі.

2. Оператор шартты анықтаңыз. Бір өлшемнен бастаңыз: статустық уақыт («Келісуде» 48 сағаттан артық), оқиғаның қайталануы («қайтарым» 2 реттен көп) немесе кезектің шоғырлануы («тағайындауды күтетіндер» 20 өтінімнен артық). Күрделі формулалар көбіне дау тудырады.

3. Контекст қосыңыз, сол арқылы алерт нақты әрекетпен жабылады, жазысумен емес. Міндетті минимум: өтінім нөмірі, ағымдағы статус, кім жауапты, қанша уақыт өткен және келесі нақты қадам не болуы керек (мысалы, «орындаушы тағайындау керек» немесе «жетекшінің қол қоюы күтілуде»).

4. Каналды және «тыныштық» ережесін анықтаңыз. Кей хабарламалар поштамен жеткізілсін, басқалары — жұмыс чатында, тағы бірі — тек күнделікті шолуда. Хабарламалар келмеу уақыты мен жиілігін шектеңіз: мысалы, бір өтінім бойынша 4 сағаттан артық емес бір хабарлама.

5. Аптасына бір рет қысқа шулы талдау жасаңыз. Қай алерттер жиі қосылатындығын және олардың қалай аяқталғанын қараңыз. Егер сигнал үнемі еленбесе, ережені жеңілдету немесе ауыстыру қажет.

«Шуды» тез азайту жолы

Алерт тек нақты әрекет иесі болған жерге ғана қалсын. Егер жауапты адам жоқ болса, алдымен өтінім маршруттарын түзетіңіз. Порогтарды реалистік ұстаңыз: әр кішкентай кідіріс үшін хабарландырулар функционалдық құндылығын тез жоғалтады.

Дашбордтар мен есептер: кімге қандай сандар көрсету керек

Жақсы мониторинг көбіне деректерде емес, олардың көрсетілуінде «ұшып кетеді». Сол бір метрикалар әртүрлі рөлдер үшін әртүрлі көмектеседі. Сондықтан бірден бөлген дұрыс: шешім қабылдайтын кім, кезекті кім басқарады және жұмысты кім орындайды.

Басшыға: процестің денсаулығын көрсететін 3–5 түсінікті көрсеткіш

Басшыға өтінімдер тізімі керек емес. Оған процес қай жерде уақыт пен сапа жоғатып жатқанын түсіну маңызды. Бір экранда әдетте 3–5 көрсеткіш жеткілікті: уақыт тренді (апталар бойынша), қайтарымдар үлесі, мерзімі өткендердің үлесі және келіп түскен ағын көлемі. Топ-3 қайтарым себебін көрсету пайдалы, сонда әңгіме тез іс-қимылға өтеді.

Орташа уақыттан гөрі медиана немесе 75-перцентиль көрсетіңіз. Орташа сирек жағдайлармен оңай бұзылады, ал перцентиль көпшіліктің жағдайын адал көрсетеді.

Орындаушыларға: не тұрып қалды және қазір не істеу керек

Орындаушыларға арналған дашборд жұмыс үстелі тәрізді болуы керек: графиктер аз, нақты міндеттер көп. Орталықта — тұрып қалған өтінімдердің тізімі және оларға приоритет беру. Приоритетті екі белгіге қарай оңай есептеуге болады: өтінім қаншалықты мерзімі өткен және оның қаншалықты маңыздылығы (тип, клиент, бөлім).

Жұмыс істеу үшін әр өтінімге қысқа нұсқаулық қосыңыз: қай қадамда тұрып қалды, статустың қанша сағат бойы өзгермегені, қозғалту үшін не қажет (комментарий, құжат, келісім).

Күнделікті қысқа есеп: тек шешімді талап ететін нәрселер

Күнделікті есеп — таңертеңгі «пульс» ретінде пайдалы. Ол үш сұраққа жауап беруі керек: қазір не өткен мерзімде тұр, не шектеліп қалған және қай жерде жетекші көмегін керек етеді. Әдетте үш блок жеткілікті:

• мерзімі өткендер: саны және ең көне 5 жағдай;
• шектеуде: бүгін шектен асып кететіндер (этаптар бойынша);
• шешім талап ететіндер: жауапсыз, иесі жоқ немесе қайтарып алынған өтінімдер.

Метрикалар түсінікті болуы үшін бірегей атаулар мен өлшем бірліктерін бекітіңіз. Мысалы: «Сұрастыру уақыты, сағатпен» — бұл жіберуден бастап финалдық шешімге дейінгі уақыт. Жанында бір өтінім бойынша қысқа есептеу мысалын берсеңіз дау азаяды.

Инфрақұрылым, келісімдер және ИТ өзгерістері параллель жүретін ұйымдарда (мысалы, инфрақұрылымды енгізу және 24/7 қолдау кезінде) рөлге сай мәлімет көрсету сандарды жұмыс құралына тез айналдырады.

Практикалық мысал: ұйымдағы келісім өтінімдері

Келісім процесін елестетіңіз: инициатор өтінімді жасайды, одан әрі ол қаржылық тексеруден, заңгерлік келісуден, ИТ қауіпсіздік тексерісінен өтеді және басшының бекітуін алады. Серверлер мінсіз жұмыс істей алады, бірақ бір келісушінің үстінде апталап өтінім жатса бизнес тоқтап қалуы мүмкін.

Мониторингтің түсінікті сигнал беруі үшін сіз дәл тіркейтін оқиғалар туралы келісіңіз: «өтінім жасалды», «қадамға тапсырылды», «бекітілді», «доработкаға қайтарылды», «жабылды». Содан кейін метрикалар ашық есептеледі.

Пайдалы минимум:

• әр қадамға шыққан уақыт (қанша сағат немесе күн өтінім қаржыда, заңгерде, ИТБ-де өткізді) — бұл «орталықша» көрсеткіштен гөрі тар нүктені көрсетеді;
• қайтарымдар: кемінде бір рет доработкаға қайтарылған өтінімдердің үлесі және бөлек қайта қайтарылғандардың үлесі;
• жалпы цикл: құрудан жабылуға дейін.

Алерттер қысқа және бірмәнді болуы керек:

• «Өтінім тұрып қалды»: нақты қадамда X сағаттан артық статус өзгермеді;
• «Қайта қайтару»: өтінім тізбектеліп екінші рет доработкаға қайтарылды;
• «Цикл шегі»: жалпы келісу уақыты Y күннен асты, тіпті әр қадам шамамен қалыпты болғанда да.

Содан соң ең маңыздысы — әрекеттерге келісу. Егер қайтарымдар заңгер қадамына жиі келсе, мәселе адамдарда емес, критерийлерде: келісім шаблоны жоқ, міндетті өрістер жеткіліксіз, инициатор дұрыс құжаттарды қоспайды. Егер бір келісушінің үстінде тұрақты тұрып қалулар болса, бұл жүктеменің артықтығы немесе жаз мезгіліне байланысты алмастыру ережесі жоқ деген сияқты — өтінімдерді қайта бөлу және ауыстыру ережелері көмектеседі.

Іске асыру және қолдау жобаларында (мысалы, GSE.kz сияқты жүйелік интеграторлар атқаратын) бастапқыда тек дашборд емес, «реакция регламентін» де бекіткен жөн: хабарлама кімге, қашан жіберіледі, эскалация қашан іске қосылады және шешім не деп есептеледі.

Мониторингте жиі кездесетін қателіктер мен тұзақтар

Көбінесе мониторингті барлығын бірден бақылап қаламын деп бастаса, бәрі бұзылады. Ондайда ондаған график пайда болады, әрқайсысы «маңызды» деп аталады, бірақ ешкім цифрлармен не істеу керектігін түсінбейді. Көп кешікпей есептер қажетсіз боп қалады, себебі олар шешім қабылдауға көмектеспейді.

Көбіне кездесетін тұзақтар:

• көрсеткіштердің көптігіне жүгіну: метрикалар көп болса, адамдар әдемірек көрінетіндерін таңдайды және қалғандарға сенімін жоғалтады;
• есептеу ережелерінің анық еместігі: біреу сұрастыру уақытын құрудан бастап есептейді, басқа біреу бірінші қараудан бастап, үшіншісі демалыстарды шығарып тастайды;
• «ешқайда апармайтын» алерт: хабарламалар бәріне немесе ешкімге келеді, жауапты жоқ, реакция жоқ;
• деректер сапасының нашарлығы: бос статустар, артқа жазылған түзетулер, қайтарым себептерінің түрліше жазылуы;
• метрикаларды жазау құралы ретінде пайдалану: адамдар есепті айналып өту үшін статустарды формальді түрде жабады, өтінімдерді бөлек бөліп жібереді.

Қарапайым мысал: өтінім «Заңгерлер» қадамында 6 күн тұрып қалды. Алерт он адамға бірден келді. Ешкім жауапты сезінбеді, өйткені «бұл менің аймағым емес». Сонымен қатар карточкада «қайтарым себебі» міндетті өріс емес, және кейбір қайтарымдар «басқа» деп жазылады. Есепте кідірістер бар екені көрінеді, бірақ себептер анық емес, сондықтан түзетуге ештеңе жоқ.

Осындай тұзақтарға түспеу үшін бірнеше ереже:

• 1–2-ден артық емес, бір сөйлеммен түсіндірілетін және әрекетке байланған метрикалардан бастаңыз;
• анықтамаларды жазбаша бекітіңіз: қай оқиға мен қай оқиға арасында есептеледі, қандай статустар жарамды, қай нәрселер шығарылып тасталады;
• әр алерттің иесі және қарапайым әрекеті болсын: «тексеру», «эскалировать», «пікірмен қайтару»;
• деректер гигиенасы туралы келісіңіз: міндетті өрістер, қайтарым себептерінің тізімі, бос статустарға тыйым салу;
• метрикаларды кезеңді жақсарту үшін құрал ретінде көрсетіңіз, кінә іздеуге емес.

Осылайша сіз цифрларға сенімділікті тезірек орнатасыз және процесті басқаруды «кім дұрыс есептейді» туралы дау емес, нақты істерге айналдырасыз.

Қысқа чек-лист және келесі қадамдар

Бизнес-процестер мониторингі тек процесс иесі барда және сандар баршаға бірдей нәрсені білдіргенде ғана жұмыс істейді.

Іске қосар алдында жылдам чек-лист

• процесс иесі тағайындалған және метрикалар нәтижесіне шешім қабылдайтын адам бар;
• метрикалар анық әрі дау тудырмайды (қай оқиғадан қай оқиғаға дейін есептеледі, қандай статустар кіреді, не қайтарым болып саналады);
• шектер мен мақсаттар белгіленген (норма, ескерту, критикалық) және әр деңгейде не істелетіні анық;
• алерттер контексті қамтиды: өтінім нөмірі, қадам, қанша уақыт тұрып тұр, кім орындаушы, келесі қадам не болмақ;
• деректер сенімді: статустар толтырылады, қайтарым себептері «басқа» деп жиналмайды, алдын ала берілген тізім қолданылады.

Содан кейін алерттерді нақты тексеріңіз. Бір көзқарас хабарламаға «не болды, қайда, қаншалықты шұғыл, кім және не істеу керек» деген сұрақтарға жауап беруі тиіс. Егер алерттер шулы болса, оларды елемеуге ауысады. Егер олар үнсіз болса, мәселені бірінші клиенттен естисіз.

30 күндік жоспар, ілесіп қалмау үшін

Бір процеске пилот жасап, оны әдетке айналдырыңыз:

• 1–7 күндер: процессті таңдау, анықтамаларды бекіту, оқиғаларды жинауды қосу;
• 8–14 күндер: 2–3 метриканы және қарапайым шектерді баптау, тарихи деректер бойынша тексеру;
• 15–21 күндер: шектеулі топқа алерттерді қосу, шуды қысқарту, контекст қосу;
• 22–30 күндер: иені бекіту, күнделікті 10 минуттық тексеру ритуалын орнату, алғашқы 3–5 қайталанатын кідірістерді жою.

Одан кейін көршілес процестерге кеңейтіңіз, бірақ тек пайдалысы дәлелденгендерді көшіріңіз.

Егер ағымдағы жүйелермен интеграция, оқиғаларды жинауға инфрақұрылымды дайындау және 24/7 қолдау қажет болса, бұл мәселені GSE.kz (gse.kz) сияқты жүйелік интеграторлармен талқылауға болады — солар арқылы процестер мониторингі басқару құралына айналсын, тек «құжат үшін» есеп емес.