Үзіліссіз жұмыс үшін сервер профилактикасы: тексерістер жоспары

Үзіліссіз профилактика деген не және неге қажет

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

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

Осы тәсіл әдетте байқалмай жиналатын қауіптерді жауып қояды: шаңнан немесе тозған вентиляторлардан болатын қызу, дискілердің деградациясы және RAID қателері, қуатпен (БП, ИБП, батареялар) байланысты проблемалар, сондай-ақ ескірген прошивкалардан туындайтын багтар мен үйлесімсіздіктер. Алғашында бұл сирек тұрып қалулар немесе таңқаларлық ескерту хабарлары ретінде көрінуі мүмкін, кейіннен — тоқтап қалуға әкеледі.

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

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

Тіпті сапалы жабдықта жүйенің денсаулығы тек тексерістердің жүйелілігіне және нәтижелерді қалай тіркейтініне байланысты. Бұл GSE.kz деңгейіндегі интеграторлар салатын инфрақұрылымға да қатысты.

Қалай ұйымдастыру керек: рөлдер, жауапкершілік, күнтізбе

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

Практикада жауапкершілікті мынадай бөлу ыңғайлы:

• Инфрақұрылым иесі (IT) — күнтізбені жүргізеді, жұмыстарды жоспарлайды және қорытындыларды жинайды.
• Сервер әкімшісі — тексерістерді орындайды (RAID, прошивкалар, вентиляторлар) және ұсыныстар береді.
• Қолданба әкімшісі — өзгерістер сервистерге қауіпсіз екенін растайды.
• Ақпараттық қауіпсіздік — патчтар, журналдар және қолжетімділік талаптарын анықтайды.
• Қолдау жеткізушісі — диагностикалау және жаңартуларға көмектеседі (егер сыртқы қолдау болса).

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

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

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

Алдын ала не дайындау керек: есеп, тәуелділіктер және негізгі құжаттама

Бастапқыда тексерістерден емес, есептен бастау керек. Әйтпесе әр жолы не бар екенін қайта-қайта анықтаумен уақыт жоғалтасыз.

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

Қызметтердің тәуелділік картасын жасаңыз: қай сервистер қай жерде орналасқан, не ненің жұмысын талап етеді (мысалы, дерекқор, домен, файл ресурстары, мониторинг) және әр сервиске кімнің бизнес иесі екені. Бұл келісімді тездетеді.

«Ағымдағы күй паспортын» жасаңыз: BIOS/BMC/RAID нұсқалары, RAID параметрлері, желі баптаулары (VLAN, агрегация, мекенжайлар), резервтеу схемасы. Жаңартулар жоспарланбаса да, бұл база диагностика жылдамдығын арттырады.

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

Осы блоктар дайын болса, айлық және тоқсандық тексерістер әдетке айналып, тексеріс емес, шынайы қызметке айналады.

Ай сайынғы тексерістер: сервисті тоқтатпайтын қысқа жиынтық

Ай сайынғы профилактика әдетте бір серверде 20–40 минутты алады және қайта жүктеулерді талап етпейді. Мақсат — проблемалардың алғашқы белгілерін тауып, деректер қорғанышы жұмыс істейтінін растау.

Бастапқы тексеріс мониторингтен басталады: CPU мен дискілердің температурасы, қуат блоктарының жағдайы (екі енгізу бар ма), жады қателері (ECC), аппараттық ескертпелер. Маңыздысы — тек ағымдағы мәнді емес, соңғы 7–30 күндегі күрт өзгерістерді қарау.

Содан кейін журналдарды тексеріңіз. Аппараттық және сақтау жүйесі бойынша қайталанатын оқиғаларды іздеңіз: I/O қателері, таймауттар, қызу, массивтің деградациясы, тұрақсыз желі. Шуға батқанға жол бермеу үшін белгілі «күтілетін» хабарларды белгілеп, қайталану жиілігін тіркеңіз.

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

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

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

Тоқсандық тексерістер: тереңірек бақылау және жақсарту жоспары

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

Прошивкалар мен жаңартулар: күйге қарап жоспар құрамыз, «күйзеліспен» емес

Айына бір рет емес, тоқсан сайын нұсқалар мен тәуекелдер матрицасын жинаңыз: BIOS/UEFI, BMC, RAID/HBA және желі адаптерлері прошивкалары. Алдымен релиз ноттарын қараңыз — қауіпсіздік, тұрақтылық, үйлесім мәселелері. Содан кейін жаңартулар тәртібін және оралу жоспарын анықтаңыз. Бір кластер түйінін бір-бірден жаңарту және жүктемені ауыстыру қауіпсіз; бәрін бірден жаңарту қауіпті болуы мүмкін.

Жабдық, сенімділік және сыйымдылық: динамиканы бақылау

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

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

Сыйымдылықты қадағалаңыз: бос орын, журналдардың өсуі, CPU/RAM/IO трендтері. Көбінесе байқалмай өсіп жатқан журналдар 2–3 айда резервті толтырып, жазуды тоқтатуға әкеледі.

Тоқсандық тексеріс үшін қысқа бағдар: прошивка нұсқаларын салыстырып, жаңарту жоспарын құрыңыз; диск деградациясын және вентилятор динамикасын қараңыз; кластерлер мен репликацияны тексеріңіз; 3–6 айға сыйымдылықты бағалаңыз; «физиканы» (кабельдер, ұстағыштар, сүзгілердің тазалығы және ауа қабылдау) қараңыз.

Журналдар мен оқиғалар: не маңызды, не алшақты өткізуге болады

Профилактика барлығы оқуды қалдырғандай болмауы үшін тізбекті сақтаңыз: BMC/IPMI (аппарат) -> ОС журналдары -> RAID/сақтау подсистемасы -> гипервизор -> қолданба журналдары. Осылай бастапқы себепті табу оңай.

Реакция әдетте бір кодпен қайталанатын қателіктерді, күтпеген reset/reboot немесе watchdog, таймауттар мен I/O қателерін, RAID деградация туралы оқиғаларды, cache/battery қатысты ескертпелерді және температура мен вентиляторлар бойынша шектен шығуларды талап етеді.

Табылғандарды осылай тіркеу пайдалы: бір аптадан кейін не болғанын түсіну үшін нақты уақыт, қайнар көз (BMC/ОС/RAID/гипервизор/қолданба), жиілігі және пайдаланушыларға әсері.

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

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

Дискілер мен RAID: істен бұрын деградацияны қалай байқау керек

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

SMART және контроллер хабарламалары: қандай белгілер қауіпті

SMART-та жалпы статус емес, нақты көрсеткіштер мен олардың өсуі маңызды. SSD үшін тозу дәрежесі мен жазу қателері де қаралады.

Ең жиі қауіпті белгілер: Reallocated Sectors, Pending Sectors немесе Uncorrectable Errors көрсеткіштерінің өсуі, бір дискіде қайталанатын I/O қателері, контроллердегі media error немесе predictive failure туралы хабарлар, дискінің «шықып қайта қосылуы» (flapping) және SSD-дегі денсаулық көрсеткішінің едәуір төмендеуі.

Көрсеткіштер айдан-айға өсіп бара жатса, массив әлі «жасыл» болып тұрса да ауыстыруды жоспарлау себебі бар.

Қашан алдын ала ауыстыру керек және оны қалай рәсімдеу

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

Егер hot spare қолдансаңыз, резервтің контроллер тарапынан көрініп, сыйымдылығы мен жылдамдығы жарамды екеніне алдын ала көз жеткізіңіз. RAID5/6 үшін ребилд үстіндегі жүктемені ескеріп, ребилдті аяқтауға және тексеруге уақытты жұмыс терезесіне енгізіңіз.

Вентиляторлар мен салқындату: апаттан сақтайтын қарапайым тексерістер

Салқындату мәселелері әдетте біртіндеп басталып, кенеттен апатқа алып келеді: сервер жиілікті төмендетіп, қайта жүктеледі немесе дискілер тез арада деградацияланады.

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

Сенсор көрсеткіштері мен ескерту шектерін тексеріңіз. Біртекті серверлерде шектер бірдей бапталуы керек, әйтпесе бір жерде қызу көрініп, басқа жерде байқалмай қалады.

Тоқтамай істеп болатын базалық әрекеттер: температура мен RPM-ды «дені сау» базаға салыстыру, стойканы көзбен тексеру (кабельдер, заглушкалар, арақашықтық, ыстық ауа ұясын жоқ па), вентиляторлардың RPM бойынша үнемі секіруі бар-жоғын анықтау және сүзгілерді белгіленген кесте бойынша тазалау. Егер вентилятор деградация жасаса, оны SLA бойынша «ыстық ауыстыру» арқылы ауыстырған дұрыс, істен шығуын күту қажет емес.

Тоқтаусыз жұмыс үшін жұмыс терезелері: қалай рәсімдеу және келісу

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

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

Уақытты ИТ жайлы ыңғайдан емес, жүктеме бойынша таңдаңыз: мониторингтен шың уақыттарды қарап, ресурстардың артығы бар кезді белгілеңіз. Егер операция 10 минут алса, алдын-ала және кейінгі тексерулер мен қауіпсіз оралуға 30–40 минут қарастырыңыз.

Хабарламаларды келесідей ережелермен бекітіңіз: 3–5 күн бұрын бизнес иелері мен қолдауды ескертіңіз, 24 сағат бұрын нақты уақыт пен контактілерді жіберіңіз, 15 минут бұрын басталатынын еске салыңыз, аяқталғанда статус пен нәтижелерді жіберіңіз.

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

Нәтижелерді қалай тіркеу және профилактика журналын жүргізу

Егер тексерістер жүргізілсе, бірақ тіркелмесе, бір айдан кейін қайтадан сол бір нәрсені талқылайсыз. Журнал тек бюрократия үшін емес, не өзгергенін, қай жерде ауытқу шыққанын және оның неге әкелетінін жылдам түсіну үшін қажет.

Минимум артефактілерді бірден жинаңыз: прошивкалар мен драйверлер нұсқалары (жаңартулар болса — бұрынғы және кейінгі), кезең бойынша журналдардан негізгі ескертпелер, RAID/дискілер/температуралардың статусы, мониторингтің жұмыстан бұрын және кейінгі белсенді ескертпелері, қуат пен вентиляторлар бойынша жазбалар.

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

Ауытқуларды дәл факт ретінде тіркеу керек, пікірлер мен ұғымдарсыз: «Диск 3 — SMART ескерту, 10 күнге дейін ауыстыру жоспары». Осылай аудит үшін (мәселен, ISO талаптары бойынша) тарих пайда болады және бюджетке негіздеме оңай болады.

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

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

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

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

Қысқа чек-листтер: тез тексеретін нәрселер және тәртібі

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

Ай сайын (серверге 15–30 минут)

Аппараттық ескертпелерді жылдам шолу (қуат, температура, вентиляторлар, RAID), диск пен массивті тексеру, кезең бойынша журналдардың қайталанатын қателерін қарау, бос орын және негізгі CPU/RAM метрикаларын бақылау. Маңыздысы — тексерулерді сол серверге тән қалыпты мәндермен салыстыру.

Тоқсан сайын (тереңдетілген + приоритеттер)

Прошивкалар мен драйверлерді мақсатты нұсқалармен салыстыру, жабдықтың тәуекелін бағалау (тозу, қателер тарихы, температура, қуат), төзімділіктің дайын екенін тексеру (диск/БП/вентилятор/порт істен шықса не болады және кім жауап береді), сыйымдылық пен жүктеме прогнозы, содан кейін тоқсанға арналған 3–5 тапсырықтан тұратын жоспар және жауапты.

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

Уақыт аз болса, маңыздылық бойынша жүріңіз: RAID пен дискілер, қуат пен температуралар, критикалық журналдар, бос орын. Қалғанын тіркеп, келесі жақын терезеге қалдырыңыз.

Мысал сценарий: кішігірім серверлік үшін тоқтаусыз регламент

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

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

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

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

Келесі қадамдар: регламентті енгізіп, қолдауды бөлу

Регламент қағазда қалып қоймас үшін, бірінші кезеңге минималды нұсқасын енгізіп, команда ырғаққа үйренген сайын кеңейтіңіз.

Келесі 2–4 аптаға жеткілікті қарапайым жоспар: алдымен инвентаризация және жауапты контактілер, содан кейін айлық тексерістер және пробалық жұмыс терезесі шаблонымен бір серверде тәжірбие жасау; одан кейін тоқсандық тексерістер мен тәуекел критерийлері (қашан оралу керек және қашан эскалациялау), және соңында чек-листтерді түзету және журнал иесін анықтау.

Жауапкершілік шекараларын бірден келісіңіз: кім журналдарды қарайды, кім прошивкалар мен драйверлерге жауапты, кім диск немесе вентилятор ауыстыру туралы шешім қабылдайды.

Интегратор мен өндірушінің қолдауын тартқан жөн, егер кластер болса, критикалық дерекқорлар бар болса, сервер модельдері әртүрлі болса немесе микробағдарламаларды топтап жаңарту жоспарланып жатса. Егер инфрақұрылым GSE серверлеріне негізделген болса (мысалы S200 Series), профилактиканы алдын ала келісілген кестеге және GSE.kz арқылы 24/7 техникалық қолдауға байлау ыңғайлы — осылайша тексерістер, ауыстырулар және жаңартулар бір түсінікті процесс арқылы өтеді.