Biznesa serveru uzraudzības kontrolsaraksts: 12 pārbaudes
Publicēts 2026. gada 2. augustā
Serveris var atbildēt uz ping pieprasījumiem un vienlaikus būt tikai vienas restartēšanas attālumā no ļoti ilgas pēcpusdienas. Šis biznesa serveru uzraudzības kontrolsaraksts vispirms koncentrējas uz signāliem, kas ietekmē klientus, personālu un ieņēmumus: pieejamību, lietotņu darbību, jaudu, drošību un atjaunojamību. Mērķis nav sūtīt brīdinājumus par katru sīkāko izmaiņu. Mērķis ir laikus zināt, kad sāk veidoties reāla pakalpojuma problēma.
Sāciet ar to, ko bizness patieš ām izmanto
Uzraudzība ir noderīga tikai tad, ja tā seko klienta ceļojumam. CPU diagramma jums nepateiks, vai darbojas norēķināšanās process, vai klientu portāls sūta e-pastu vai vai API atgriež derīgas atbildes. Sāciet ar to pakalpojumu uzskaitīšanu, kuriem jāpaliek pieejamiem: tīmekļvietnes, datubāzes, pasta pakalpojumi, VPN, fona darbinieki, failu glabātuve, ieplānotie uzdevumi un trešo pušu integrācijas.
Katram pakalpojumam norādiet īpašnieku, definējiet pieņemamu atbildes laiku un izlemiet, kas tiek uzskatīts par dīkstāvi. Mārketinga vietne var pieļaut dažas papildu ielādes sekundes. Maksājumu galapunkts vai produkcijas API parasti to nevar. Tieši šeit mazākas komandas iegūst priekšrocību: saraksts var būt īss, skaidrs un saistīts ar reālu ietekmi uz biznesu.
Biznesa serveru uzraudzības kontrolsaraksts: 12 pamatpārbaudes
1. Ārējā darbspēja un atbildes laiks
Pārbaudiet savus svarīgākos publiskos URL un pakalpojumu portus no ārpuses servera. Iekšējā uzraudzība var rādīt, ka viss ir kārtībā, kamēr DNS problēma, ugunsmūra noteikums, sertifikāta derīguma termiņa beigas vai augšupējās maršrutēšanas kļūme bloķē reālos apmeklētājus.
Uzraugiet HTTP statusa kodus, lapas vai API atbildes laiku un, kur iespējams, jēgpilnu satura pārbaudi. Tiešsaistes veikalam ir lietderīgi pārliecināties, ka sākumlapa atgriež 200. Vēl labāk ir pārliecināties, ka darbojas preču meklēšana vai groza galapunkts.
2. CPU lietojums, load average un steal time
Ilgstoša CPU pārsātināšana palēnina datubāzes, tīmekļa darbiniekus, cron uzdevumus un attālināto administrēšanu. Sekojiet līdzi vidējam CPU noslogojumam, bet salīdziniet arī load average ar pieejamo CPU kodolu skaitu. Augsts load average var norādīt uz CPU pressure, procesiem, kas gaida diska I/O, vai bloķētiem uzdevumiem.
Virtuālajā privātajā serverī uzmanību ir pelnījis CPU steal time. Augsts steal time nozīmē, ka hipervizors pavada pārāk daudz laika, apkalpojot citas slodzes, pirms jūsu slodze tiek pie sava kārtas. Tā ne vienmēr ir lietotnes problēma, un PHP pielāgošana neizlabos trokšņaina kaimiņa situāciju.
3. Atmiņas pieejamība un swap aktivitāte
Zems brīvās atmiņas apjoms pats par sevi ne vienmēr ir slikti. Linux izmanto neizmantoto atmiņu kešatmiņai, un tā ir normāla darbība. Brīdinājuma pazīmes ir pieaugošs swap lietojums, biežas lapu kļūdas, out-of-memory notikumi vai process, ko kodols ir nogalinājis.
Sekojiet līdzi pieejamajai atmiņai, nevis tikai brīvajai atmiņai. Ja swap normālas datplūsmas laikā pastāvīgi pieaug, pirms nākamās datplūsmas virsotnes izpētiet lietotni, datubāzes buferus, darbinieku limitus vai servera izmēru.
4. Diska ietilpība, inode lietojums un pieauguma temps
Pilns disks var apturēt datubāzes, neļaut ierakstīt žurnālus, sabojāt dublējumkopijas un izraisīt citādi veselīgas tīmekļvietnes atteici pārsteidzošos veidos. Uzraugiet visus attiecīgos montēšanas punktus, ne tikai galveno failu sistēmu. Iekļaujiet lietotņu sējumus, datubāzu glabātuvi, dublējumkopiju sagatavošanas zonas un pagaidu direktorijas.
Uzraugiet arī inode patēriņu. Miljoniem mazu failu var izsmelt inode pat tad, ja diskā vēl ir daudz vietas. Sekojiet līdzi arī pieauguma tempam. Failu sistēma ar 70% noslogojumu var būt mierīga; tāda, kas aug par 10% dienā, sūta visai skaidru pastkarti no nepatikšanām.
5. Diska I/O latentums un failu sistēmas kļūdas
Diska lietojums ir ietilpība. Diska latentums ir veiktspēja. Liels lasīšanas vai rakstīšanas gaidīšanas laiks var likt serverim šķist sastingušam pat tad, ja CPU noslogojums ir zems. Pakalpojumi ar lielu datubāžu slodzi ir īpaši jutīgi pret lēnu glabātuvi.
Iestatiet brīdinājumus par neparastu I/O wait, ilgstošu diska latentumu, failu sistēmas kļūdām un atkārtotām montēšanas problēmām. Ja datubāzes vaicājums pēkšņi kļūst lēns visā sistēmā, pirms pieņemt, ka datubāzei vajag lielāku kešatmiņu, jāpārbauda glabātuves darbība.
6. Tīkla datplūsma, pakešu zudums un savienojumu kļūdas
Sekojiet līdzi ienākošajai un izejošajai caurlaidspējai attiecībā pret servera porta ietilpību, bet neapstājieties pie tā. Pakešu zudums, atkārtota pārraide, saskarnes kļūdas, nomestas paketes un negaidīti liels savienojumu skaits bieži izskaidro lēnu vai neuzticamu pakalpojumu.
Datplūsmas pieaugums var būt laba ziņa, piemēram, veiksmīga kampaņa. Vai arī tā var būt botu datplūsma, skrāpēšanas izpilde, nepareizā stundā ieplānota dublējuma pārsūtīšana vai uzbrukums. Uzraudzība sniedz jums pierādījumus, lai to novērtētu, nevis minētu pēc ļoti krāsaina grafika.
7. Tīmekļa servera un lietotnes stāvoklis
Jūsu tīmekļa serveri vajadzētu pārbaudīt vairāk nekā tikai pēc tā, vai process darbojas. Uzraugiet aktīvos savienojumus, pieprasījumu ātrumu, atbildes kodus, darbinieku pieejamību, rindas dziļumu un lietotnes kļūdu biežumu. Process var palikt dzīvs, kamēr katrs pieprasījums atgriež 500 kļūdu.
PHP, Node.js, Java, Python vai līdzīgiem lietotņu stekiem uzraugiet darbinieku restartēšanās, atmiņas pieaugumu, neapstrādātus izņēmumus un pieprasījumu latentumu pa galapunktiem. Labākais brīdinājums bieži vien nav “process apstājās”. Tas ir “norēķināšanās galapunkts ir piecas reizes lēnāks nekā parasti”.
8. Datubāzes veiktspēja un replikācijas statuss
Datubāzes ir pelnījušas savu uzraudzības plānu, jo tās atteicas citādi nekā tīmekļa serveri. Sekojiet līdzi savienojumu lietojumam, lēniem vaicājumiem, vaicājumu latentumam, bloķēm, bufera vai kešatmiņas efektivitātei, glabātuves pieaugumam un kļūdu žurnāliem.
Ja izmantojat replikāciju, uzraugiet replikācijas aizturi un replikas veselību. Replika, kas atpaliek par vairākām stundām, joprojām var parādīties kā tiešsaistē, taču tā nav gatava atbalstīt atskaites, pārslēgšanos kļūmes gadījumā vai atjaunošanu. Pārvaldītām datubāžu slodzēm izlemiet, kurš pārskata lēno vaicājumu modeļus un cik bieži. Atstāt to līdz brīdim, kad lietotne kļūst redzami lēna, ir dārgs laika izvēlējums.
9. Dublējumkopiju pabeigšana un gatavība atjaunošanai
Dublējumkopijas uzdevums, kas ir sācies, automātiski nav dublējumkopija, kas var jūs izglābt. Uzraugiet, vai uzdevumi tika pabeigti, cik ilgi tie darbojās, dublējumkopijas izmēru, mērķa glabātuves pieejamību, šifrēšanas statusu, kur tas tiek izmantots, un visus dublējumkopiju rīka brīdinājumus.
Vissvarīgākais ir ieplānot atjaunošanas testus. Pārbaudiet faila atjaunošanu, datubāzes atjaunošanu un, kur tas ir praktiski iespējams, pilnu pakalpojuma atjaunošanu atsevišķā vidē. Žurnāli stāsta to pašu stāstu tikai tad, ja atjaunošana ir pārbaudīta. Dublējumkopija bez pierādījuma par atjaunošanu joprojām ir tikai cerīgs risinājums.
10. Drošības notikumi un ielāpu statuss
Uzraugiet neveiksmīgu pieteikšanos modeļus, privilēģiju izmaiņas, jaunus lietotāju kontus, SSH piekļuvi, ugunsmūra bloķējumus, ļaunprogrammatūras brīdinājumus, sertifikātu derīguma termiņa beigas un neparastus izejošos savienojumus. Ne katra neveiksmīga pieteikšanās prasa zvanu pusnaktī, bet pēkšņs uzliesmojums pret administratīvo kontu ir pelnījis rūpīgāku pārbaudi.
Ielāpu uzraudzībai jāziņo gan par pieejamiem atjauninājumiem, gan par kavētiem kritiskiem labojumiem. Lietojiet atjauninājumus ar uzturēšanas plānu, kas atbilst pakalpojumam. izstrādes VPS var pieļaut ātru restartēšanu. Uz klientiem vērstam produkcijas serverim var būt nepieciešama testēšana, dublējumkopijas pārbaude un ieplānots izmaiņu logs.
11. SSL, DNS un domēna atkarības
Sertifikāta derīguma termiņa beigas var pārvērst strādājošu tīmekļvietni par tūlītēju uzticības problēmu. Iestatiet brīdinājumus labu laiku pirms sertifikātu termiņa beigām un uzraugiet automātiskās atjaunošanas rezultātus. Pārbaudiet, vai sertifikāts atbilst paredzētajam resursdatora nosaukumam un vai pilnā ķēde tiek pasniegta korekti.
DNS ir pelnījis līdzīgu rūpību. Uzraugiet svarīgākos DNS ierakstus, nosaukumserveru pieejamību un negaidītas ierakstu izmaiņas. DNS nav pati skaistākā situācija, kad tas noiet greizi, taču tas ir kontrolējams, ja jums ir zināms bāzes stāvoklis un brīdinājums pirms par to ziņo klienti.
12. Žurnāli, ieplānotie uzdevumi un brīdinājumu piegāde
Kur iespējams, centralizējiet noderīgos žurnālus un sekojiet līdzi atkārtotām kļūdām, autentifikācijas neveiksmēm, lietotnes izņēmumiem un pakalpojumu restartiem. Arī žurnālu apjoms ir signāls. Pēkšņi plūdi var aizpildīt glabātuvi; pēkšņs klusums var nozīmēt, ka žurnālu aģents ir atteicies.
Uzraugiet cron uzdevumus, rindas, ieplānotus importus, atskaišu ģenerēšanu un atjaunošanas uzdevumus. Šie uzdevumi bieži atteicas klusi, jo pati tīmekļvietne paliek tiešsaistē. Visbeidzot, pārbaudiet brīdinājumu piegādi. Brīdinājums, kas nonāk iesūtnē, kuru neviens nepārbauda plkst. 3.00. vairāk atgādina dienasgrāmatas ierakstu nekā operacionālu kontroli.
Iestatiet sliekšņus, kas rosina rīcību, nevis troksni
Izvairieties no universāliem sliekšņiem. 90% CPU brīdinājums var būt steidzams mazā VPS, kas parasti darbojas pie 15%, bet nekaitīgs pakešu apstrādes serverim, kas paredzēts darbam ar augstu slodzi stundu katru nakti. Nosakiet bāzes līmeni normālas datplūsmas laikā, pēc tam iestatiet brīdinājumus par ilgstošu novirzi un ietekmi uz biznesu.
Izmantojiet smaguma līmeņus ar skaidrām darbībām. Brīdinājums var lūgt dežurējošajai personai pārskatīt pieaugošu diska noslogojumu darba laikā. Kritiskam brīdinājumam vajadzētu nozīmēt, ka kādam jārīkojas tagad, jo uz klientiem vērsts pakalpojums nedarbojas, datu aizsardzība ir apdraudēta vai jauda drīz izsīks.
Katram svarīgam brīdinājumam jāatbild uz trim jautājumiem: kas atteicās, kas ir ietekmēts un kas jāpārbauda vispirms. Brīdinājuma ziņojumā iekļaujiet servera nosaukumu, pakalpojumu, laika zīmogu, attiecīgo rādītāju un īsu atsauci uz runbook. Persona, kas to saņem, var būt nogurusi, jauna šajā vidē vai arī abi. Dodiet viņiem godīgu sākumu.
Izveidojiet eskalācijas ceļu, pirms rodas spiediens
Uzraudzības steks neaizstāj operacionālo atbildību. Dokumentējiet, kurš saņem brīdinājumus, kurš var apstiprināt restartēšanu vai atgriešanu, kur akreditācijas dati tiek droši glabāti un kā klienti tiek informēti apstiprināta incidenta laikā. Aģentūrām tas ir īpaši vērtīgi, jo viens infrastruktūras notikums var vienlaikus ietekmēt vairākus klientu kontus.
Pārvaldīta uzraudzība šeit var mazināt slogu. Tādi pakalpojumi kā FASTCARE monitoring ir noderīgi, ja jūsu komandai ir vajadzīgas cilvēka acis uz servera signāliem, īpaši ārpus darba laika, taču jums joprojām vajadzētu vienoties par eskalācijas kontaktiem un atļautajām darbībām. Ātra reakcija darbojas vislabāk, kad nevienam nav jāmeklē tālruņa numurs, kamēr disks sasniedz 100%.
Pārskatiet kontrolsarakstu katru mēnesi un pēc katra incidenta. Noņemiet brīdinājumus, kas rada troksni, pievienojiet pārbaudes atteicēm, kas palika neatklātas, un atjauniniet sliekšņus, pieaugot slodzei. Mierīga infrastruktūra nav klusa infrastruktūra. Tā ir vide, kurā pareizie cilvēki saņem pareizo signālu pietiekami agri, lai atkal padarītu pakalpojumu mierīgu.
Andres Saar Klientu apkalpošanas inženieris