SAP Solution Manager мониторингі: сценарийлер және аздан бастау

Неліктен эксплуатацияға SAP экожүйесін мониторингтеу қажет

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

SAP Solution Manager-дегі мониторинг инцидентпен ғана емес, оның алдындағы белгілермен де көруге көмектеседі. Сол кезде реакция жоспарлы болады: мәселенің себебін бизнес-процеске тигізер алдында жоясыз.

Көбінесе алдын ала байқалатын симптомдар: жауап беру уақыты өседі (алдымен бір модульде немесе бір пайдаланушылар тобында), интерфейстерде қателер мен қайталанатын әрекеттер пайда болады (IDoc/RFC/PI/PO), фондық тапсырмалар «құйрық» боп жиналады және блокировкалар пайда болады, файл жүйелері мен журналдар толып қалады, ал жаңартулардан кейін жаңа дамптар мен қателердің толқыны орын алады.

Бастауға әдетте үш кедергі кедергі жасайды.

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

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

Үшіншісі — базалық сызық жоқ: тарих болмаса қалыпты мен деградацияны ажырату қиын.

"Аздан бастап" дегеніміз үлкен жоба жасау емес, шектеулі сигналдарды таңдап, оларды әрекетке дейін жеткізу. Мысалы: бір продуктивтік жүйе, 5–10 көрсеткіш, түсінікті шектер және реакция ережесі (кім қарайды, қаншалықты жиі, не істейді).

Практикалық мысал: құжаттарды баяу өңдеу бойынша бірнеше инциденттен кейін команда бірнеше негізгі симптомдарды бекітіп (жауап беру уақыты, жаңарту кезегі, интерфейс қателері), апта бойы тарих жинап, қарапайым оповещениелер орнатады. Бір айдан кейін тыныш ритм қалыптасады: проблемалар тренд бойынша табылады, ал өзгерістер нақты жүктемені ескере отырып жоспарланады, «көзбен бағалау» емес.

SAP Solution Manager мониторингі неге қамтиды

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

Әдетте бақылауға үш топ объект кіреді: SAP жүйелері өздері (ABAP, Java, HANA, дерекқорлар), фондық тапсырмалар мен кезектер және интерфейстер мен интеграциялар (IDoc, RFC, PI/PO, веб‑қызметтер). Бұл әкімшілік құралдарды алмастырмайды, бірақ оқиғалар ортақ ережелер мен шектерге келтірілетін біртұтас бақылау нүктесі болады.

Бақылау мен басқаруды алдын ала бөліп қою пайдалы.

Бақылау — деректерді, статустарды және трендтерді жинау.

Басқару — реакция: хабарлау, инцидент ашу, процедура іске қосу, өзгерісті келісу, себепті тіркеу.

Тек жинауды орнатсаңыз, команда «қызыл шамдарды» көреді, бірақ кейін не істеу керектігін білмейді.

Алысаспау үшін үш бақылау деңгейін есте сақтаңыз:

• Техникалық: қолжетімділік, жүктеме, инфрақұрылым қателері, журналдардың өсуі, HANA және хосттың жағдайы.
• Қолданбалы: бизнес‑кезектер, IDoc қателері, фондық тапсырмалардың сәтсіздігі, өңдеулердегі кідірістер.
• Процессілік: реакция жылдамдығы, инциденттерді жабудың сапасы, себептердің қайталануы, техникалық терезелерге сәйкестік.

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

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

Егер сізде SolMan бойынша бөлек команда болмаса, ролдерді және маршруттарды келісіп алу пайдалы: кім алертті растайды, кім жояды, эскалация туралы кім шешім қабылдайды.

Қолайлы бақылау сценарийлері: ең тез әсер ететіндері

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

1) Негізгі компоненттердің қолжетімділігі мен «тіршілік қабілеттігі"

Қарапайымнан бастаңыз: жүйе қолжетімді ме және жауап бере ме? ABAP, SAP HANA дерекқоры, SAP Gateway және Web Dispatcher сияқты кіру нүктелерін бөлек тексеріңіз. Тек «up/down» емес, деградация белгілері де пайдалы: қосылу қателерінің өсуі, жиі қайта жүктелулер, ілініп қалған процестер.

2) Пайдаланушылар сезетін өнімділік

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

Бастапқыда бірнеше қарапайым сценарий жеткілікті: диалог қадамдарының кідірісі және транзакциялар бойынша жауап беру уақыттарының өсуі, кірістегі қателер (Gateway, Web Dispatcher), негізгі кезектердің толуы және ілініп қалған тапсырмалар санының өсуі, CPU мен жадының ұзақ мерзімді өсуі, диск бос көлемі мен журналдар/таблицалық кеңістіктердің өсуі.

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

Интеграцияларды өткізіп алмаңыз: RFC қателері, IDoc, ілініп қалған кезектер, қайталанатын хабарламалар. Сондай‑ақ негізгі қауіпсіздік бақылауын сақтаңыз: сәтсіз кірулердің толқыны, шоттардың массалық бітелуі, рөлдердегі критикалық өзгерістер. Бұл көбінесе сервистік десктен бұрын мәселені көрсетеді.

Бастау үшін 5–10 сигналды қалай таңдау керек

Мониторинг жүздеген метрикалардан басталмауы тиіс. Алғашқы 2–4 аптада 5–10 сигнал таңдап, олар негізгі процестердің қолжетімділігін көрсетіп, түсінікті әрекеттерге әкелуі маңызды: не істеу керек, кім және қанша уақыт ішінде.

Бастапқыда критикалық сервистердің қысқа тізімін жасаңыз. Бұл әрқашан «жасыл» болуы тиіс жүйелер мен интеграциялар: продуктивті ERP (PRD), орталық дерекқор, SAP Gateway/ICM, негізгі интеграциялар (мысалы, банкпен немесе EDI‑мен алмасу), басып шығару, аутентификация (SSO, LDAP, AD). Егер сервис тоқтаса және жұмыс тоқтап қалса — ол тізімге кіреді.

Басымдық матрицасы: 24/7 немесе күн сайын тексеру

Оқиғаларда батып кетпеу үшін сигналдарды екі режимге бөліңіз.

24/7 режиміне әдетте кіреді: логин/негізгі компоненттердің қолжетімділігі, критикалық файл жүйелеріндегі бос орын, RFC/IDoc қателері, фондық тапсырмалардағы маңызды сәтсіздіктер және кезектер/интеграциялар бойынша кешігулер.

Күнделікті шолу үшін жиі жарайды: көлем мен сыйымдылықтың өсуі, баяу диалогтар/SQL бойынша трендтер, бэкаптардың аяқталуы, жаңартулар мен патчтердің статусы, жалпы жады мен диск бойынша болжау.

Одан кейін «пайдаланушы көзінше өлшеу нүктелерін» қосыңыз. Инфрақұрылым қалыпты көрінсе де, пайдаланушылар зардап шегуі мүмкін. 1–2 қарапайым сценарий таңдаңыз: жүйеге кіру және негізгі транзакцияны іске қосу (мысалы, құжаттар тізімін ашу). SolMan‑да бұл тұрақты тексерістер ретінде жазып қоюға ыңғайлы: «кіру 20 секундтан ұзақ» немесе «транзакция 60 секундта ашылмады» сияқты шектермен.

Әр сигналдың иесі болуы керек. Әйтпесе алерт «ешкімнің емес» болады. Әдетте жауапкершілік былай бөлінеді: Basis — SAP инстанстары мен фондық тапсырмаларға, дерекқор админдері — бэкаптар мен дерекқор өнімділігіне, қолданбалы команда — критикалық джобтар мен қолданбалы қателерге, интеграция командасы — RFC/IDoc/кезектерге.

Соңғы қадам — реакция уақыты мен эскалацияны келісу. 24/7 үшін нақты ережелер жеткілікті: бірінші алертті кім қабылдайды, келесі деңгей қанша минуттан кейін қосылады және статус қай жерде тіркеледі (жалпы чат немесе сервис‑деск). Бұл метрикаларды басқарылатын қолдауға айналдырады, тек шу емес.

Тұрақтылық пен жоспарлау үшін қандай деректер жинау керек

Мониторинг эксплуатацияға шынымен көмектесуі үшін деректер екі сұраққа жауап беруі керек: «жүйе тірі ме?» және «проблемадан бұрын не өзгерді?». Аз ғана сигналды таңдап, оларды тұрақты және бірдей түрде (DEV, QAS, PRD) жинау маңызды.

Тұрақтылық үшін минималды жинақ

Ең тез алынатын, тоқтауды және «жұмсақ» проблемалардың жиналуын көрсететін нәрседен бастаңыз:

• Негізгі компоненттердің қолжетімділігі мен жағдайы (қолданба, дерекқор, жүйелер арасындағы байланыс).
• Фондық тапсырмалар мен тізбектер бойынша сигналдар: не басталмады, не іліп қалды, не әдеттен едәуір ұзақ жұмыс істеді.
• Кезектер мен жиналулар (интеграциялықты қоса): көлемнің өсуі және қайталанатын қателер.
• Дерекқор мен сақтау көлемінің өсуі: жалпы көлем, өсу қарқыны, бірден төбеге жетпеу үшін толып қалу.
• Пайдаланушы симптомдары: кіру сәтсіздігінің толқыны, RFC/интеграция қателерінің өсуі, диалогтардың күтпеген түрде тоқтатылуы.

Бұл көп „өртенген“ жағдайларды ұстап қалуға және ерте мәселелерді көруге жеткілікті.

Тексерулер үшін журналдар, қателер және өндірістік көрсеткіштер

Тек алерттер жеткіліксіз. Себебін түсіндіретін іздер қажет: қысқа дамптар, жүйелік қолданба журналдары, жаңарту қателері және интерфейстердегі қайталанатын хабарлар.

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

Өзгерістер мен жүктеме күнтізбесі туралы деректер

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

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

Сақтау ережесі

Сақтау мерзімін алдын ала келісіңіз: егжей‑тегжейлі деректер қысқа уақытқа сақталсын (мысалы, 7–14 күн, жаңа инциденттерді талдау үшін), ал агрегаттар мен трендтер ұзағырақ сақталсын (мысалы, 3–6 ай) — емкосты жоспарлау және «нашарлап жатыр ма?» сұрағына жауап беру үшін.

Аздан бастау: 2–4 аптаға арналған қадамдық жоспар

SAP Solution Manager‑да мониторинг бастауын пилот ретінде жүргізу жақсы, үлкен жоба емес. Алғашқы 2–4 аптадағы мақсат қарапайым: негізгі жүйелерді қосып, 5–10 түсінікті сигналды ұстап, оларға кім және қалай жауап беретіні туралы келісу.

Апталық жұмыс жоспары

Алдымен қысқа инвентаризация жасаңыз: ортаға қандай жүйелер кіреді (PRD/QAS/DEV, PI/PO, BW, HANA), қандай критикалық интерфейстер мен бизнес‑процестер бар және әр аймақтың иесі кім (Basis, ABAP, интеграциялар, желі, дерекқор). Бұл бірден «алерт бар, жауап беретін жоқ» деген классикалық мәселені шешеді.

Сосын мынадай қадамдармен жүріңіз:

• Апта 1: жүйелерді SolMan‑ға қосып, базалық қолжетімділік пен өнімділік алерттерін қосыңыз (шектерді күрделендірмей).
• Апта 1–2: фондық тапсырмалар мен кезектерді бақылауды қосыңыз, сондай‑ақ интерфейстер мониторингін (IDoc/qRFC/tRFC/HTTP) орнатыңыз.
• Апта 2: алғашқы шектерді анықтап, шолулар кестесін келісіңіз: күнделікті қысқа шолу, апталық сводка, айлық тренд.
• Апта 2–4: пилотты жүргізіп, шу тудыратын алерттерді белгілеп, шектер мен ерекшеліктерді түзетіңіз.
• Пилот соңында: реакция регламенін және дежурлыға қысқа нұсқаулықты бекітіңіз.

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

Дежурлыға мини‑нұсқаулық

Оны бір бетке сыйдырыңыз: қай 5–10 сигналды критикалық деп санау, жалған срабатыванняны қалай тексеру, иесіне қашан эскалация жасау және шешім тарихы қайда сақталатыны. Практикада бұл реакция уақытын идеалды шектер орнатудан әлдеқайда тез қысқартады.

Өзгерістер үшін мониторинг: релиздер, транспорты және қызмет көрсету терезелері

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

Өзгеріс терезесі басталғанда ағымдағы күйдің қысқа срезін жасаңыз. «Жасыл шамдар» ғана емес, шегіне жақын нәрселер де көрінуі тиіс: ағымдағы жүктеме (диалогтар, RFC, фон), кезектер мен кешігу (job/backlog/spool, интеграциялық кезектер), бос ресурстар (CPU/жады/диск, әсіресе /usr/sap және лог файлдар), критикалық сервис атауларының қолжетімділігі (ICM/HTTP(S), SAP Gateway, RFC destinations) және жүйелік гигиена (системалық журнал, дамптар және соңғы өзгерістерден кейінгі динамика).

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

Релизден кейін пайдаланушылардан бұрын проблемаларды ұстау үшін 3–5 маячок жеткілікті: 1–2 негізгі транзакция, бір типтік интеграция және бірнеше фондық тізбек (мысалы, түнгі есептеулер). Қателер болса, «алдымен және кейін» салыстыру маңызды.

Инциденттерді талдау үшін срезтар тарихын сақтаңыз: релиз алдындағы 30–60 минут, импорт уақытында және одан кейін 1–2 сағат. Порогтық метрикалар, қателер мен дамптар саны, ауыр сұраулардың топ‑тізімі және кезектердің жағдайы сияқты деректер қажет.

Ерте ескерту жүйелерін, мысалы EWA (EarlyWatch Alert) пайдаланыңыз — олар трендтер мен «жұмсақ» тәуекелдерді көрсетіп, келесі релизге дейін проблемаларды хабарлайды.

Орнатудағы типтік қателіктер мен тұзақтар

Бірінші тұзақ — «бәрін бірден» жасау. SolMan‑ға ондаған метрикалар қосылып, күнделікті жүздеген алерт келіп, команда жауап беруді тоқтатады. Ережесі қарапайым: 10 нақты сигналға жауап беруге жақсырақ, 200 «әдемі» сигналдан гөрі.

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

Екінші қателік — метриканың иесі жоқ. Сигнал бар, шешім жоқ: Basis «әзірлеуге» жібереді, әзірлеу «интеграторларға» жібереді, бизнес «ИТ шешеді» деп ойлайды. Әр метрикада иесі және эскалация маршруты болуы керек. Жақсы тексеру: егер шек қызыл 30 минут тұрса, кім инцидентті жабады?

Үшінші тұзақ — шектер «аспаннан алынған». Базалық сызық болмаса, немесе жалған ескертулер көп, немесе деградация байқалмайды. Алғашында 1–2 апта жинақталған бақылауды алып, шыңдарды (айдың жабылуы, түнгі жүктемелер, пакет жұмыстар) белгілеңіз де, содан кейін шектер орнатыңыз. Көбіне трендтер шектерден де пайдалы: «апта бойы өсіп келеді».

Төртінші қателік — тек серверлерді ғана бақылау. SAP‑та көптеген ақаулар CPU‑дан емес, кезектерден, фондық тапсырмалардан, RFC, IDoc, интерфейс қателерінен, басып шығару ілінісі мен журнал кестелерінің толуынан басталады. Міне, солар пайдаланушыларға бірінші соққы береді.

Бесінші тұзақ — инциденттермен байланыстың жоқтығы. Деректер жиналады, бірақ таланбайды. Әр P1/P2 үшін минимумы: инцидентке дейін қандай метрикалар қызыл болғаны, кейін қандай метрикалар қызарғаны және қай сигнал алдын‑ала ескерткен болар еді — осындай жазбалар мониторингті жай панельден тұрақтылық құралына айналдырады.

Қысқа чек‑лист — эксплуатацияда не тексеру керек және қаншалықты жиі

Чек‑лист күнделікті нақты тәуекелдерді ұстап тұру үшін қажет. Қысқа тексеріс жинағын жасап, команда оны кесте бойынша орындап, ауытқуларды тіркеуі керек.

Күнделікті (10–20 минут)

Таңертең пайдаланушылар үшін маңызды нәрселерді тексеріңіз: жүйе тірі ме, критикалық қызыл алерттер бар ма және фондық процестер «бәрі тәртіпте ме».

• Негізгі жүйелер мен сервистердің қолжетімділігі (қолданба, дерекқор, RFC/IDoc кезектері, шлюз).
• Technical Monitoring SolMan‑дағы қызыл алерттер және олардың динамикасы (жаңа немесе қайталанатын).
• Сәтсіз аяқталған тапсырмалар: бэкаптар, мерзімді есептер, жүктеулер, BW/PI/PO тізбектері (бар болса).
• Кезектер мен ілініп қалулар: SMQ1/SMQ2, IDoc backlog, фондық жұмыстардың орындалу уақыттарының өсуі.

Аптасында бір рет (30–60 минут)

Апта сайын жинақтық тенденцияға көз жүгіртіңіз: қайда қарыз жиналып жатыр және не жарылуға әзір.

• Интеграциялар бойынша топ‑қателер (IDoc/RFC/HTTP), қайталанатындары және себептері.
• Дерекқордың өсуі: жалпы көлем, өсу қарқыны, үлкен кестелер, файл жүйелерінің толуы.
• Жауаптылықтың тұрақтылығы: диалог уақыттарының өсуі, шоқты уақыттар, жиі таймауттар.
• Фондық өңдеудің сапасы: маңызды джобтардың орташа орындалу уақыты, кезектер, блокировкалар.

Релиз алдында және кейін

Релиз алдындағы мақсат — ресурстарда запас барын және откат жоспары барын тексеру. Релизден кейін мақсат — негізгі процестердің қалыпты жұмыс істеп жатқанын тез растау.

Релиз алдында бос ресурстарды (CPU/жад/диск), кезектер мен backlog‑ты, келісілген жұмыс терезесін және откат қадамдарының тәртібін тексеріңіз.

Релизден кейін негізгі транзакциялар, интеграциялар және фондық тізбектерді бақылап, жауапты базалық сызықпен салыстырыңыз.

Ай сайын (жоспарлау үшін)

Айлық шолу мониторингті емкость пен бюджет үшін дәлелге айналдырады: не өсіп жатыр, қашан қор таусылуы мүмкін және қандай өзгерістер қосымша қуат қажет етеді.

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

Мысал сценарий: команда үлкен жоба емес, бақылауды қалай іске қосты

Эксплуатация командасы ABAP‑тағы SAP ERP‑ге, SAP HANA дерекқорына, бірнеше сыртқы жүйемен интеграцияларға және түнгі пакет тапсырмаларға жауапты болды. Бұрын олар пайдаланушы шағымына қарай ғана әрекет ететін: дежурный SM37 пен кезектерді қолмен тексеріп, себебін кеш қайтар жүргенде іздейтін.

Олар аздан бастап мониторингті іске қосуға шешім қабылдады: SolMan‑да таңерленген, таңертең жиі жұмыс істемеуіне әкелетін нәрселерге ғана назар аударды. Бірінші спринтте бес сигнал таңдады, олар бизнесті түсіндіруге оңай және тез тексерілетін еді:

• Негізгі компоненттердің (ABAP, HANA) қолжетімділігі және жауап уақыты.
• IDoc кезегінің өсуі (жиналу және «іліну").
• Үш критикалық түнгі job: аяқталуы және ұзақтығы.
• Дисктердің толуы және HANA дерекқорының өсу жылдамдығы.
• Журналдардың өсуі мен кенеттен өсуі (application/system).

Аптадан кейін алғашқы табылғандар пайда болды. Бір рет IDoc кезегі серіктесте болған қателікке байланысты іліп қалды: деректер жіберілмей қалды, бірақ пайдаланушы таңертең ғана байқады. Сонымен қатар дерекқордың тұрақты өсімі анықталды: бүгін жеткілікті орын бар, бірақ бір айдан кейін жетпейді. Тағы бір түнгі job интеграция таймаутынан уақытылы құлағаны анықталды, SM37‑де ол бір реттік оқиға сияқты көрінген.

Одан әрі олар қамтуды кеңейтпей, реакцияны жетілдірді. IDoc кезегі үшін шекті «0» емес, динамика бойынша жасады: егер 15–20 минут бойы өсу сақталса — ескерту. Job үшін «ұзақтығы орташа мәннен +30%» және job белгіленген уақытта аяқталмаса бөлек хабарландыру ережесі қосылды. Хабарламаларды деңгейлерге бөлді: дежурныйға дереу, интеграция иесіне — тек қайталанғанда.

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

Келесі қадамдар: мониторингті қалай кеңейту және кім көмектесе алады

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

Бір‑екі бетті құжатта (1–2 парақ) бақылап жатқан жүйелер тізімін жинаңыз: PROD, QAS, DEV, SAP HANA, SAProuter, Solution Manager, интеграциялар және негізгі интерфейстер. Олардың қасында бастапқы сигналдар мен шектерді тіркеңіз. Бұл «біз бұл мониторингті жүргіземіз бе?» деген дауларды шеше алады және жаңадан келгендердің тезірек қосылуына көмектеседі.

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

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

3 айға арналған кеңейту жоспарын шағын қадамдармен жасаңыз: ай сайын 2–3 сценарий қосып, циклды толық жауып отырыңыз (шектер, жауаптылар, есеп, инцидент талдауы).

Көмек қажет болса, ол әдетте екі бағытта болады: әдістемелік (сценарий таңдау, шектер орнату, SLA келісу, алерттермен жұмыс бойынша оқыту) және инфрақұрылымдық (SolMan үшін ресурстарды бағалау, метрикалар сақтау орны мен база, 24/7 қолдауды ұйымдастыру). Қазақстанда инфрақұрылымдық бөлікті жүйелік интегратор мен жабдық өндіруші, мысалы GSE.kz жабуы мүмкін: серверлер мен СХД, сондай‑ақ тәулік бойы техникалық қолдау.