Īpaša servera iestatīšanas ceļvedis pirmajai dienai
Publicēts 2026. gada 16. oktobrī
Jauns īpašs serveris vēl nav gatavs darbam produkcijas vidē tikai tāpēc, ka operētājsistēma ir palaista. Šis īpaša servera iestatīšanas ceļvedis sākas ar pasākumiem, kas neļauj nelielai konfigurācijas kļūdai pārvērsties garā naktī: aizsargāta piekļuve, aktuāla programmatūra, pārbaudītas dublējumkopijas un iespēja redzēt, ko serveris dara.
Īpašs serveris sniedz pilnīgu kontroli pār fizisko aparatūru un tās resursiem. Tas arī uzliek pilnu atbildību par lēmumiem, kas pārsniedz aparatūras slāni. Tas ir noderīgi noslogotiem veikaliem, aģentūru darba slodzēm, datubāzēm, spēļu serveriem, SaaS lietojumprogrammām un ikvienam pakalpojumam, kas izaudzis no koplietojamas infrastruktūras. Pirmās dienas mērķis nav pielāgot ikvienu iestatījumu. Mērķis ir izveidot drošu pamatu un pēc tam izvietot sistēmu ar pārliecību.
Īpaša servera iestatīšanas ceļvedis: sāciet ar piekļuves kontroli
Pirms lietojumprogrammas instalēšanas noskaidrojiet, kam un kā ir pieejams serveris. Sākotnējos pakalpojumu sniedzēja piekļuves datus paturiet tikai tik ilgi, cik nepieciešams, lai izveidotu nosauktus administratoru kontus un drošas alternatīvas. Koplietojamas root paroles ir grūti pārbaudīt un vēl grūtāk deaktivizēt, kad aiziet darbuzņēmējs vai darbinieks.
Linux serveros administratīvajai piekļuvei izmantojiet SSH atslēgu autentifikāciju. Ģenerējiet atslēgas uzticamā darbstacijā, pievienojiet publisko atslēgu attiecīgajam kontam un atsevišķā terminālī pārbaudiet jaunu pieteikšanos, pirms maināt paroli vai kādu SSH iestatījumu. Neaizveriet aktīvo sesiju, kamēr nav pierādīts, ka jaunais piekļuves ceļš darbojas. Šis vienkāršais ieradums pasargā no klasiskās situācijas, kad serveris ir drošs pret visiem, ieskaitot tā īpašnieku.
Ja darba slodze to pieļauj, atspējojiet tiešu root pieteikšanos, apstiprinātai administrēšanai izmantojiet sudo un pēc piekļuves ar atslēgu pārbaudes atspējojiet autentifikāciju ar paroli. Windows Server vidē izveidojiet atsevišķu administratora lietotāju, ierobežojiet piekļuvi, izmantojot Remote Desktop, pieprasiet spēcīgus un unikālus piekļuves datus un izmantojiet tīkla līmeņa autentifikāciju. Abos gadījumos, kad vien tas ir praktiski iespējams, ierobežojiet ienākošos pārvaldības savienojumus, atļaujot tikai zināmas biroja, VPN vai bastiona resursdatora IP adreses.
Ugunsmūrim pēc noklusējuma jāliedz savienojumi. Atveriet tikai tos portus, kas nepieciešami jūsu pakalpojumam. Tipiskam tīmekļa serverim var būt nepieciešami 80. un 443. ports, savukārt piekļuve SSH vai RDP jāierobežo, atļaujot tikai uzticamas avota adreses. Datubāzu portiem parasti jāpaliek privātiem, un tiem jābūt pieejamiem tikai lietojumprogrammu serveriem vai privātajam tīklam. Publiski pieejams datubāzes ports nav nekāda priekšrocība. Parasti tas ir aicinājums uz nepatikšanām.
Atjauniniet operētājsistēmu, pirms tiek izvietota darba slodze
Vispirms instalējiet jaunākos operētājsistēmas atjauninājumus, tostarp drošības ielāpus, pakotņu atjauninājumus un serverim paredzētos aparātprogrammatūras vai platformas paziņojumus. Iekšējā dokumentācijā pierakstiet operētājsistēmas versiju, kodola versiju, resursdatora nosaukumu, publisko IP adresi, privātās IP adreses informāciju, ja tāda tiek izmantota, un servera nolūku. Nākotnē jūs par to būsiet pateicīgāks, nekā pašlaik domājat.
Neinstalējiet atjauninājumus produkcijas vidē bez apdomas, ja tā ir svarīga jau esoša sistēma. Tomēr jaunai izvietošanai parasti labāk sākt ar pilnībā atjauninātu pamatsistēmu. Plānojiet automātiskos drošības atjauninājumus, tikai vispirms izvērtējot, kā lietojumprogramma uzvedas pēc pārstartēšanas. Nelielas riska pakāpes satura vietne var vieglāk pieņemt plānotu apkopes pārstartēšanu nekā darījumu platforma ar stingrām pieejamības prasībām.
Noņemiet nevajadzīgās pakotnes un pakalpojumus. Noklusējuma attēlos var būt iekļauti rīki, kurus nekad neizmantosiet, un katrs pakalpojums, kas gaida savienojumus, rada papildu uzturēšanas pienākumus. Ar operētājsistēmas rīkiem pārbaudiet aktīvos pakalpojumus, pēc tam apturiet un atspējojiet nevajadzīgos. Uzturiet serveri pietiekami vienkāršu, lai arī stresa apstākļos tā darbība būtu saprotama.
Veidojiet lietojumprogrammu kopu, domājot par komponentu nošķiršanu
Instalējiet darba slodzei nepieciešamo tīmekļa serveri, izpildvidi, datubāzes klientu, rindas apstrādes procesu, konteineru dzinēju vai vadības paneli. Nenovietojiet visas biznesa funkcijas vienā datorā tikai tāpēc, ka pirmajā serverī ir brīva jauda. Viens īpašs serveris var būt piemērots sākumpunkts, taču komponentu nošķiršana kļūst vērtīga, kad datubāzes veiktspēja, drošības robežas vai izvietošanas biežums sāk konfliktēt.
Piemēram, e-komercijas vietne sākumā var labi darboties, tīmekļa lietojumprogrammai un kešošanas slānim atrodoties vienā īpašā serverī. Pieaugot pasūtījumu skaitam, datubāzes pārvietošana uz atsevišķu privātu resursu var mazināt resursu konkurenci un padarīt uzturēšanu drošāku. Savukārt izstrādes aģentūra var dot priekšroku izolētām klientu vidēm, atsevišķiem dublējumkopiju glabāšanas termiņiem un pārvaldības piekļuvei ar savu zīmolu.
Izmantojiet pakalpojumu kontus, piešķirot katram komponentam tikai nepieciešamās atļaujas. Glabājiet slepenos datus ārpus lietojumprogrammas repozitorija, mainiet tos, kad mainās darbinieku piekļuve, un nošķiriet produkcijas vides vērtības no testēšanas un izstrādes vides vērtībām. Ja plānā ir iekļauti konteineri, pirms izvietošanas nosakiet resursu ierobežojumus un pastāvīgās krātuves noteikumus. Konteineri atvieglo programmatūras pakotņu izveidi; tie neliek diskā aizņemtajai vietai pieklājīga lūguma dēļ pazust.
Pārdomāti konfigurējiet DNS, TLS un e-pastu
Iestatiet DNS ierakstus tikai tad, kad mērķa pakalpojums ir gatavs apstrādāt pieprasījumus. Pirms plānotas migrācijas samazinot DNS ieraksta TTL, var saīsināt gaidīšanas laiku, līdz izmaiņas stājas spēkā, taču tas neliek visiem DNS atrisinātājiem tās uzreiz aizmirst. Uzturiet veco un jauno vidi vienlaikus pietiekami ilgi, lai pārbaudītu datplūsmu, žurnālus un fona uzdevumus.
Instalējiet derīgu TLS sertifikātu, attiecīgā gadījumā novirziet HTTP datplūsmu uz HTTPS un pārbaudiet sertifikātu ķēdi no ārpus servera. Konfigurējiet automātisku atjaunošanu un brīdinājumus, pirms pirmā sertifikāta derīguma termiņa beigas kļūst par ārkārtas situāciju. Lietojumprogrammām, kas apstrādā klientu datus, uzmanīgi pievienojiet drošības galvenes un pārbaudiet to darbību īstās pārlūkprogrammās, nevis akli pārņemiet stingru politiku no nejauša konfigurācijas piemēra.
Ja serveris sūta e-pastu, pareizi konfigurējiet sūtītāja identitāti un sekojiet līdzi piegādes rezultātiem. Darījumu ziņojumi, paroļu atiestatīšanas e-pasti un pasūtījumu apstiprinājumi nedrīkst būt atkarīgi no pasta konfigurācijas, kas pārbaudīta tikai ar lokālu komandrindas komandu.
Dublējumkopijas ir jāpārbauda, veicot atjaunošanu
Dublējumkopija ir noderīga tikai tad, ja to var atjaunot laikā, ko jūsu uzņēmums spēj pieļaut. Nosakiet, kas jāaizsargā: lietojumprogrammas faili, datubāzes, augšupielādētais klientu saturs, konfigurācijas faili un šifrēšanas atslēgas vai atkopšanas materiāli. Ar datubāzes izdrukām vien var nepietikt, lai iekļautu augšupielādētos failus; savukārt ar pilna diska momentuzņēmumiem vien var nepietikt, lai sasniegtu vajadzīgo atkopšanas punktu. Lielākajai daļai produkcijas sistēmu ir vajadzīga iepriekš plānota kombinācija.
Glabājiet dublējumkopijas atsevišķi no primārā servera. Ja serveris tiek dzēsts, kompromitēts vai tiek bojāta tā failu sistēma, dublējumkopijas, kas glabājas tikai šajā serverī, atrodas tajā pašā glābšanas laivā. Nosakiet glabāšanas termiņus atbilstoši reālajām uzņēmējdarbības vajadzībām, pēc tam aizsargājiet piekļuvi dublējumkopijām ar atsevišķiem piekļuves datiem un, ja iespējams, nemaināmu vai versētu krātuvi.
Pirms iestatīšanas pabeigšanas pārbaudiet atjaunošanu. Atjaunojiet datubāzi vidē, kas nav produkcijas vide, atjaunojiet reprezentatīvu failu kopu un pārliecinieties, ka lietojumprogramma startē ar atjaunotajiem datiem. Izmēriet, cik ilgs laiks tam nepieciešams. Žurnāli tagad vēsta to pašu: veiksmīgi pabeigts dublēšanas uzdevums vēl nepierāda, ka datus var atjaunot.
Pārraugiet serveri, pirms lietotāji pamana problēmu
Pārraudzībai jāaptver pieejamība, resursu jauda un lietojumprogrammas darbība. Vismaz pārraugiet CPU noslodzi, atmiņas noslodzi, diska vietas izmantojumu, diska ievadi un izvadi, tīkla caurlaidspēju, procesu darbspēju, SSL sertifikāta derīguma termiņu, dublēšanas pabeigšanu un ārējo pakalpojumu sasniedzamību. Lietojumprogrammai, kas izmanto datubāzi, pievienojiet savienojumu skaitu, lēnos vaicājumus, replikācijas statusu, ja tas ir aktuāli, un krātuves pieaugumu.
Iestatiet brīdinājumu sliekšņus, kas komandai dod laiku rīkoties. Brīdinājums par disku, kas aizpildīts par 95 %, var būt tehniski precīzs, bet darbības ziņā novēlots, īpaši tad, ja žurnāli vai datubāzes faili strauji pieaug. Izmantojiet brīdinājuma un kritisko notikumu līmeņus, nosūtiet brīdinājumus cilvēkiem, kuri var reaģēt, un nesūtiet katru sīku notikumu uz vienu un to pašu kanālu. Brīdinājumu nogurums pārvērš noderīgu pārraudzību dekoratīvā troksnī.
Vietnē kodu.cloud pārvaldīts operacionālais atbalsts un FASTCARE pārraudzība var samazināt jūsu komandas ikdienā veicamās infrastruktūras uzraudzības apjomu. Arī tad, ja saņemat pārvaldītu atbalstu, saglabājiet atbildību par pakalpojumu karti, eskalācijas kontaktpersonām un atkopšanas prioritātēm. Atbalsta dienests var reaģēt ātrāk, ja paredzamā darbība ir dokumentēta.
Noslēgumā veiciet pirmās dienas pārbaudi
Pirms pakalpojuma nodošanas lietotājiem pārbaudiet to tā, kā to darītu lietotājs. Atveriet lietojumprogrammu, izmantojot HTTPS, iesniedziet īstu veidlapu vai testa pasūtījumu, pārliecinieties, ka ieplānotie uzdevumi darbojas, pārbaudiet izejošo e-pastu un pārskatiet lietojumprogrammas un sistēmas žurnālus, lai atrastu atkārtotas kļūdas. Pārbaudiet, vai ārēji ir redzami tikai paredzētie porti un vai pārraudzības brīdinājumi tiek piegādāti vajadzīgajā vietā.
Īsā nodošanas piezīmē dokumentējiet rezultātus: servera nolūku, piekļuves pārvaldītājus, ugunsmūra noteikumus, izvietotos pakalpojumus, dublējumkopiju atrašanās vietu un atjaunošanas procedūru, pārraudzības brīdinājumus un nākamo apkopes datumu. Tā nav birokrātija tikai birokrātijas pēc. Tā ir karte, kas jūsu komandai būs vajadzīga, kad pienāks atjauninājums, radīsies incidents vai vēlu vakarā būs jāatbild uz jautājumu.
Stabils īpašs serveris nav tāds, kas nekad nemainās. Tas ir serveris, kurā piekļuve tiek kontrolēta, atkopšanas iespējas ir pārbaudītas un kāds var pietiekami savlaicīgi pamanīt problēmas, lai tās pienācīgi novērstu.
Andres Saar, klientu atbalsta inženieris