Mirëmbajtja e serverëve: plan operimi për përditësime, kopje rezervë dhe rikthim real

Çdo detyrë ka nevojë për një rol përgjegjës

Një server mund të monitorohet teknikisht dhe megjithatë të mbetet jashtë pune për orë nëse askush nuk reagon ndaj alarmit. Prandaj plani i operimit fillon me aplikacionet, kontaktet dhe oraret e biznesit. Regjistroni kush e trajton teknikisht incidentin, kush vendos përparësinë dhe kush miraton nga ana e biznesit shërbimin e rikthyer. Zëvendësuesit duhet të kenë akses në të njëjtin informacion të nevojshëm.

Shembull i matricës së përgjegjësive
Detyra	Pala përgjegjëse	Rezultati
Pajisjet dhe platforma	IT-ja e brendshme ose operatori i kontraktuar	Platformë e monitoruar dhe zëvendësim i organizuar
Sistemi operativ dhe baza e të dhënave	Mbështetje teknike e emërtuar	Përditësime të kontrolluara dhe konfigurim i dokumentuar
Kopja rezervë dhe rikthimi	Përgjegjës i emërtuar për kopjet rezervë me një zëvendësues	Kopje rezervë e përdorshme dhe rikuperim i regjistruar
Pranimi nga biznesi	Personi përgjegjës për aplikacionin	Proceset kryesore dhe gjendja e të dhënave të konfirmuara

Një person mund të mbajë disa role. Rëndësi ka që asnjë rol të mos mbetet pa përgjegjës. Me një ofrues shërbimesh, dakordësoni me shkrim përgjegjësitë dhe disponueshmërinë. Një kohë e premtuar reagimi fillimisht do të thotë se puna nis; nuk garanton automatikisht një aplikacion të rikthyer plotësisht brenda së njëjtës periudhë. Ndajini këta objektiva në specifikimin e shërbimit.

Një ritëm mirëmbajtjeje me qëllim të arsyetuar

Plani i mëposhtëm është modeli ynë fillestar për një mjedis të vogël. Nuk është standard universal. Shpeshtësia dhe urgjenca varen nga biznesi, ekspozimi i sistemit, njoftimet e prodhuesit dhe objektivat e dakordësuara të rikuperimit. Informacioni i ri kritik trajtohet jashtë intervaleve rutinë kur është e nevojshme.

Shembull plani të mirëmbajtjes së vazhdueshme
Shpeshtësia	Detyra	Prova
Vazhdimisht, me shqyrtim në ditët e punës	Monitoroni arritshmërinë, sinjalet e aplikacionit dhe gabimet e kopjeve rezervë	Alarm i caktuar një përgjegjësi ose gjendje ditore e konfirmuar
Çdo javë	Shqyrtoni kapacitetin, proceset e dështuara dhe ndryshimet e hapura	Listë e shkurtër veprimesh me përgjegjës
Gjatë intervalit të planifikuar të përditësimit	Instaloni dhe kontrolloni përditësimet e miratuara	Versionet, kontrollet funksionale dhe çdo devijim
Çdo tremujor si pikënisje	Rikuperim përfaqësues dhe shqyrtim i aksesit	Kohëzgjatje e matur, gjendje e të dhënave dhe pranim nga biznesi
Çdo vit dhe pas ndryshimeve të mëdha	Shqyrtoni mbështetjen, arkitekturën, kontratat dhe planin e emergjencës	Vendim i përditësuar për operimin

Për një aplikacion me objektiv shumë të ngushtë rikuperimi, testimi tremujor mund të jetë tepër i rrallë. Anasjelltas, jo çdo aplikacion i vogël mbështetës i pandryshuar kërkon rindërtim të plotë mujor. Zgjidhni përmbajtjen sipas rrezikut dhe ndryshojeni pas dështimeve, përditësimeve të mëdha ose një ndryshimi të kopjeve rezervë. Një kalendar i ngurtë nuk zëvendëson vlerësimin e informuar.

Përditësimet përfundojnë me një kontroll funksional

NIST e përshkruan menaxhimin e arnimeve si identifikim, caktim përparësie, sigurim, instalim dhe verifikim të përditësimeve. Udhëzuesi e klasifikon atë si mirëmbajtje parandaluese. Në praktikë, një përditësim përfundon vetëm kur janë kontrolluar instalimi dhe shërbimi i nevojshëm. NIST SP 800-40 Rev. 4: Planifikimi i menaxhimit të arnimeve ↗

Përpara intervalit, sqaroni varësitë, njoftimet e prodhuesit, kopjet rezervë të disponueshme dhe rrugën e kthimit pas. Për aplikacionet e rëndësishme, provojeni ndryshimin fillimisht në një mjedis të përshtatshëm testimi. Ekipi përcakton sa gjatë të presë për një përditësim të suksesshëm dhe kur të kalojë te kthimi pas i përgatitur. Një skemë baze të dhënash mund të mos jetë e kthyeshme thjesht duke rikthyer një skedar programi.

Përpara: dokumentoni shërbimet e prekura, miratimin, gjendjen e kopjes rezervë dhe ndërprerjen e pritshme.
Gjatë: regjistroni ndryshimet dhe devijimet pa hapur njëkohësisht disa drejtime pune të paplanifikuara.
Pas: kontrolloni hyrjen, funksionin kryesor të biznesit, proceset në sfond, lidhjen me bazën e të dhënave dhe monitorimin.
Përfundimi: regjistroni versionet e reja, konfirmoni rinisjet e nevojshme dhe caktoni përgjegjës për defektet e pazgjidhura.

Planifikoni kopjet rezervë duke nisur mbrapsht nga objektivi i rikuperimit

RPO është objektivi i humbjes së tolerueshme të të dhënave, i shprehur si interval kohor. RTO është objektivi i kohëzgjatjes së rikuperimit. Nëse nuk mund të humben më shumë se 30 minuta porosi, vetëm një kopje rezervë ditore nuk mund ta përmbushë këtë objektiv. Nëse përshtaten kopje më të shpeshta, kopjimi i regjistrit të transaksioneve ose një metodë tjetër varet nga aplikacioni dhe ruajtja e të dhënave.

Në modulin e konceptit të kopjeve rezervë, BSI thekson ndër të tjera rikuperimin e dokumentuar. Udhëzimet që mungojnë ose informacioni i padisponueshëm mund ta vonojnë ose pengojnë rikuperimin. Prandaj dokumentacioni duhet të mbetet i arritshëm edhe nëse serveri i prekur dhe rrugët e tij normale të aksesit dështojnë. BSI: CON.3 Koncepti i kopjeve rezervë, botimi 2022 ↗

Kontrolloni kopjet e veçanta, afatin e përshtatshëm të ruajtjes dhe ndarjen e aksesit nga mjedisi i prodhimit. Për kopjet rezervë të enkriptuara, çelësat dhe lejet e nevojshme janë pjesë e planit të rikuperimit. Ato duhet të mbeten të disponueshme në mënyrë të sigurt pa u ekspozuar në dokumentacionin e përgjithshëm. Një kopje rezervë baze të dhënash duhet të sigurojë gjithashtu një gjendje konsistente; kopjimi arbitrar i skedarëve aktualisht të hapur nuk është supozim i besueshëm për këtë.

Shembull: pse nuk arrihet objektivi i rikthimit brenda dy orësh

Një shërbim hipotetik duhet të jetë përsëri i përdorshëm brenda dy orësh nga ndërprerja. Kopja rezervë përmban 200 GB në njësi dhjetore. Për testin, supozojmë një shpejtësi efektive transferimi prej 400 Mbit/s. Prandaj vetëm transferimi i të dhënave kërkon 200 × 8,000 / 400 = 4,000 sekonda, ose rreth 67 minuta. Të gjitha kohëzgjatjet e mëposhtme janë supozime të modelit tonë.

Zinxhiri i rikuperimit në skenarin model
Hapi	Kohëzgjatja	Koha nga ndërprerja
Zbulimi dhe marrja e përgjegjësisë për incidentin	15 minuta	15 minuta
Përgatitja e sistemit të synuar dhe aksesit të nevojshëm	20 minuta	35 minuta
Transferimi i 200 GB të dhënave	Rreth 67 minuta	Rreth 102 minuta
Rikthimi i bazës së të dhënave dhe aplikacionit	30 minuta	Rreth 132 minuta
Kontrolli i funksionit të biznesit dhe gjendjes së të dhënave	25 minuta	Rreth 157 minuta

Rezultati është afërsisht dy orë e 37 minuta, duke mos arritur objektivin. Vetëm një lidhje më e shpejtë nuk do ta zgjidhë domosdoshmërisht çdo problem. Masat e mundshme përfshijnë një sistem të synuar të përgatitur, një kopje rezervë më lehtësisht të disponueshme, më pak varësi manuale ose një metodë rikuperimi teknikisht të ndryshme. Matni përsëri më pas. Një vlerë optimiste në një fletëllogaritëse nuk llogaritet si objektiv i arritur.

Lidhni alarmet me një veprim

Një kontroll i thjeshtë ping raporton se një kompjuter përgjigjet. Ai nuk tregon nëse klienti mund të hyjë ose të ruajë një porosi. Kombinoni sinjalet teknike me një kontroll me ndikim të ulët të funksionit të nevojshëm. Një alarm duhet të identifikojë aplikacionin e prekur, urgjencën, kush reagon dhe ku ndodhen udhëzimet përkatëse.

Vëzhgoni prirjet krahas gabimeve: kapacitetin rezervë, moshën e kopjes së fundit të suksesshme rezervë, rritjen e kohëve të përgjigjes dhe certifikatat që skadojnë. Për hapësirën e ruajtjes ka rëndësi ndryshimi. Llogaritja jonë me 500 GB të lira dhe rritje prej 20 GB në ditë jep teorikisht 25 ditë deri në mbushje; rezervat për mirëmbajtje dhe kulmet e shkurtojnë periudhën e përdorshme. Kjo lejon planifikimin e zgjerimit përpara se një aplikacion të refuzojë shkrimet.

Hiqni ose ndryshoni alarmet që vazhdojnë të jenë pa kuptim. Një kuti hyrëse plot me mesazhe identike e vështirëson njohjen e ndërprerjeve reale. Gabimet e përsëritura kërkojnë një veprim për shkakun rrënjësor me një afat. Alarmet e heshtura kanë nevojë për një datë përfundimi ose një arsye të dokumentuar që të mos harrohen pas mirëmbajtjes.

Mirëmbani edhe afatet e mbështetjes dhe informacionin e dorëzimit

Mbani një kalendar të ciklit jetësor për sistemin operativ, bazën e të dhënave, aplikacionin dhe pajisjet. Përmbajtja e mbështetjes varet nga produkti, versioni dhe çdo kontratë e blerë. Canonical, për shembull, dallon mbulime të ndryshme mirëmbajtjeje dhe mbështetjeje në ciklin jetësor të Ubuntu. Kontrolloni mbulimin real të instalimit tuaj, jo vetëm moshën e numrit të versionit. Canonical: Cikli i publikimeve të Ubuntu dhe mbulimi i mbështetjes ↗

Fillojeni një përmirësim versioni mjaftueshëm herët për të testuar përputhshmërinë dhe kthimin pas. Mbajeni edhe inventarin të përditësuar: cilit aplikacion i duhet cila bazë të dhënash, ndërfaqe dhe person përgjegjës? Kur ia dorëzoni një ofruesi të ri shërbimi, informacioni dhe aksesi i nevojshëm duhet të mund të transferohen në mënyrë të rregullt. Dokumentacioni është pjesë e sistemit që operohet.

Një raport mujor që çon te vendimet

Një raport i dobishëm operimi nuk ka nevojë për njëzet grafikë. Ai emërton ndërprerjet përkatëse, ndryshimet e përfunduara, provat më të fundit të rikthimit dhe kufijtë e ardhshëm të kapacitetit ose mbështetjes. Çështjet e hapura kanë një përgjegjës dhe një datë. Pronarët e biznesit mund të shohin kështu cili kufizim mbetet dhe cili vendim nevojitet.

Kopjet rezervë të dështuara ose një objektiv rikuperimi i paarritur duhet të jenë të dukshme në këtë raport. Vetëm një shkak i korrigjuar dhe një test i suksesshëm e mbyllin çështjen. Mirëmbajtja kështu shndërrohet nga një tarifë mujore e paqartë në një shërbim të verifikueshëm, kontributi i të cilit në aftësinë e kompanisë për të punuar mbetet i kuptueshëm.