Ez a cikk az első a „Hogyan veheti át az irányítást a hálózati infrastruktúrája felett” című cikksorozatban. A sorozat összes cikkének tartalma és linkjei megtalálhatók .
Teljes mértékben elismerem, hogy elég sok olyan cég van, ahol az egyórás vagy akár egynapos hálózati leállás nem kritikus. Sajnos vagy szerencsére nem volt lehetőségem ilyen helyeken dolgozni. De természetesen mások a hálózatok, mások a követelmények, mások a megközelítések, és mégis, az alábbi lista ilyen vagy olyan formában sok esetben valóban „kötelező”.
Tehát a kezdeti feltételek.
Új munkahelyen dolgozik, előléptetést kapott, vagy úgy döntött, hogy új pillantást vet a feladataira. A vállalati hálózat az Ön felelősségi köre. Számodra ez sok szempontból kihívás és újdonság, ami némileg indokolja a cikk mentori hangját :). De remélem, hogy a cikk hasznos lehet bármely hálózati mérnök számára.
Az első stratégiai célod az, hogy megtanulj ellenállni az entrópiának és fenntartani a nyújtott szolgáltatás szintjét.
Az alábbiakban leírt problémák közül sok különböző módon megoldható. Szándékosan nem vetem fel a műszaki megvalósítás témáját, mert... elvileg sokszor nem az a fontos, hogy ezt vagy azt a problémát hogyan oldottad meg, hanem az a fontos, hogy hogyan használod és használod-e egyáltalán. Például a professzionálisan felépített felügyeleti rendszerének nem sok haszna van, ha nem nézi meg, és nem reagál a riasztásokra.
Оборудование
Először is meg kell értened, hol vannak a legnagyobb kockázatok.
Megint más lehet. Elismerem, hogy valahol ezek például biztonsági problémák lesznek, valahol a szolgáltatás folytonosságával kapcsolatos problémák, valahol pedig esetleg valami más. Miért ne?
Tegyük fel, hogy egyértelmű legyen, hogy ez továbbra is a szolgáltatás folytonossága (minden cégnél így volt, ahol dolgoztam).
Ezután a felszereléssel kell kezdeni. Íme egy lista azokról a témákról, amelyekre érdemes odafigyelni:
- berendezések besorolása kritikussági fok szerint
- a kritikus berendezések biztonsági mentése
- támogatás, licencek
Át kell gondolnia a lehetséges meghibásodási forgatókönyveket, különösen a kritikussági besorolása tetején lévő berendezések esetében. Általában figyelmen kívül hagyják a kettős problémák lehetőségét, ellenkező esetben indokolatlanul megdrágulhat a megoldása, támogatása, de az igazán kritikus hálózati elemek esetében, amelyek meghibásodása jelentősen érintheti az üzletet, érdemes elgondolkodni ezen.
Példa
Tegyük fel, hogy egy adatközpont gyökérkapcsolójáról beszélünk.
Mivel egyetértettünk abban, hogy a szolgáltatás folytonossága a legfontosabb kritérium, indokolt ezen berendezés „forró” biztonsági mentése (redundancia) biztosítása. De ez még nem minden. Azt is el kell döntenie, hogy ha az első kapcsoló tönkremegy, mennyi ideig elfogadható-e, hogy csak egy kapcsolóval éljen, mert fennáll annak a veszélye, hogy az is elromlik.
Fontos! Ezt a kérdést nem neked kell eldöntened. Le kell írnia a kockázatokat, a lehetséges megoldásokat és a költségeket a menedzsment vagy a vállalatvezetés számára. Döntéseket kell hozniuk.
Tehát, ha úgy döntöttek, hogy a kettős meghibásodás csekély valószínűsége miatt elvileg elfogadható 4 órás munkavégzés egy kapcsolón, akkor egyszerűen felveheti a megfelelő támogatást (mely szerint a berendezést 4 órán belül kicserélik). órák).
De fennáll annak a veszélye, hogy nem teljesítenek. Sajnos egyszer mi is ilyen helyzetbe kerültünk. Négy óra helyett egy hétig utazott a felszerelés!!!
Ezért ezt a kockázatot is meg kell beszélni, és talán helyesebb lesz, ha vesz egy másik kapcsolót (harmadik), és azt alkatrészcsomagban tárolja ("hideg" tartalék), vagy laboratóriumi célokra használja.
Fontos! Készítsen egy táblázatot az összes támogatásáról a lejárati dátumokkal, és adja hozzá azokat a naptárához, hogy legalább egy hónappal korábban kapjon egy e-mailt arról, hogy aggódnia kell a támogatás megújítása miatt.
Nem bocsátják meg Önnek, ha elfelejti megújítani a támogatást, és a hardver meghibásodását követő napon.
Sürgősségi munka
Bármi is történik a hálózaton, ideális esetben fenn kell tartania a hozzáférést a hálózati berendezéshez.
Fontos! Konzol hozzáféréssel kell rendelkeznie az összes berendezéshez, és ez a hozzáférés nem függhet a felhasználói adathálózat állapotától.
Előre kell látnia a lehetséges negatív forgatókönyveket is, és dokumentálnia kell a szükséges intézkedéseket. Ennek a dokumentumnak az elérhetősége is kritikus, ezért nem csak a részleg megosztott erőforrásán kell közzétenni, hanem helyileg is menteni kell a mérnökök számítógépére.
Ott kell lennie
- a jegyek szállítói vagy integrátori támogatással történő megnyitásához szükséges információk
- információ arról, hogyan lehet eljutni bármely berendezéshez (konzol, menedzsment)
Természetesen bármilyen más hasznos információt is tartalmazhat, például a különféle berendezések frissítési eljárásának leírását és hasznos diagnosztikai parancsokat.
Partnerek
Most fel kell mérnie a partnerekkel kapcsolatos kockázatokat. Általában ezt
- Internetszolgáltatók és forgalmi cserepontok (IX)
- kommunikációs csatorna szolgáltatók
Milyen kérdéseket kell feltenned magadnak? A berendezésekhez hasonlóan különböző vészhelyzeti forgatókönyveket kell figyelembe venni. Például az internetszolgáltatók számára ez valami ilyesmi lehet:
- mi történik, ha az X internetszolgáltató valamilyen okból leállítja a szolgáltatás nyújtását?
- Más szolgáltatóknál lesz elegendő sávszélesség az Ön számára?
- Mennyire lesz jó a kapcsolat?
- Mennyire függetlenek az Ön internetszolgáltatói, és az egyik komoly leállása okozhat-e problémát a többinél?
- hány optikai bemenet van az adatközpontban?
- mi történik, ha az egyik bemenet teljesen megsemmisül?
Ami a bemeneteket illeti, a praxisomban két különböző cégnél, két különböző adatközpontban egy kotró kutat tönkretett, és csak a csoda folytán az optikánkat nem érintette. Ez nem olyan ritka eset.
És természetesen nemcsak fel kell tennie ezeket a kérdéseket, hanem ismét a vezetőség támogatásával, minden helyzetben elfogadható megoldást kell adnia.
biztonsági mentés
A következő prioritás a berendezés konfigurációinak biztonsági mentése lehet. Mindenesetre ez egy nagyon fontos szempont. Nem sorolom fel azokat az eseteket, amikor elveszítheti a konfigurációt, jobb, ha rendszeresen készít biztonsági másolatot, és nem gondol rá. Ezenkívül a rendszeres biztonsági mentések nagyon hasznosak lehetnek a változások nyomon követésében.
Fontos! Naponta készítsen biztonsági másolatot. Ez nem olyan nagy mennyiségű adat, hogy megspóroljuk ezt. Reggel az ügyeletes mérnök (vagy Ön) kapjon egy jelentést a rendszertől, amely egyértelműen jelzi, hogy a mentés sikeres volt-e vagy sem, és ha a mentés nem sikerült, akkor a problémát meg kell oldani, vagy jegyet kell készíteni ( lásd a hálózati részleg folyamatait).
Szoftververziók
Az a kérdés, hogy érdemes-e frissíteni a berendezés szoftverét, nem ennyire egyértelmű. Egyrészt a régi verziók ismert hibák és sebezhetőségek, másrészt az új szoftverek egyrészt nem mindig fájdalommentes frissítési eljárást jelentenek, másrészt új hibákat és sebezhetőségeket jelentenek.
Itt kell megtalálnia a legjobb lehetőséget. Néhány nyilvánvaló ajánlás
- csak a stabil verziókat telepítse
- Ennek ellenére nem szabad túl régi szoftververziókkal élnie
- készítsen egy táblát bizonyos szoftverek elhelyezkedésének információival
- rendszeresen olvassa el a jelentéseket a szoftververziók sebezhetőségeiről és hibáiról, és kritikus problémák esetén gondoljon a frissítésre
Ebben a szakaszban, ha konzolon hozzáfér a berendezéshez, rendelkezik a támogatással kapcsolatos információkkal és a frissítési eljárás leírásával, elvileg készen áll erre a lépésre. Az ideális megoldás az, ha rendelkezik olyan laboratóriumi berendezéssel, ahol ellenőrizheti a teljes eljárást, de sajnos ez nem gyakran fordul elő.
Kritikus berendezés esetén felveheti a kapcsolatot a szállító ügyfélszolgálatával, hogy segítsen a frissítésben.
Jegyrendszer
Most már körülnézhet. Ki kell alakítania a más részlegekkel és az osztályon belüli interakció folyamatait.
Lehet, hogy erre nincs is szükség (például ha kicsi a céged), de nagyon javaslom, hogy úgy szervezd a munkavégzést, hogy minden külső és belső feladat a jegyrendszeren keresztül menjen át.
A jegyrendszer alapvetően az Ön belső és külső kommunikációs felülete, és ezt az interfészt kellően részletesen le kell írnia.
Vegyünk egy példát a hozzáférés megnyitásának fontos és gyakori feladatára. Leírok egy algoritmust, ami az egyik cégnél tökéletesen működött.
Példa
Kezdjük azzal a ténnyel, hogy a hozzáférést biztosító ügyfelek gyakran egy hálózati mérnök számára érthetetlen nyelven fogalmazzák meg vágyaikat, mégpedig az alkalmazás nyelvén, például „adj hozzáférést az 1C-hez”.
Ezért soha nem fogadtunk el közvetlenül ilyen felhasználóktól érkező kéréseket.
És ez volt az első követelmény
- a hozzáférési kérelmek műszaki osztályoktól érkezzenek (esetünkben ezek voltak a unix, a windows, a helpdesk mérnökei)
A második követelmény az
- ezt a hozzáférést naplózni kell (a műszaki osztálynak, ahonnan ezt a kérést kaptuk), és kérésként kapunk egy linket erre a naplózott hozzáférésre
Ennek a kérésnek a formájának számunkra érthetőnek kell lennie, pl.
- a kérésnek tartalmaznia kell információt arról, hogy melyik alhálózathoz és melyik alhálózathoz legyen nyitva, valamint a protokollt és (tcp/udp esetén) portokat
Ott is fel kell tüntetni
- annak leírása, hogy miért van megnyitva ez a hozzáférés
- ideiglenes vagy állandó (ha ideiglenes, milyen időpontig)
És egy nagyon fontos pont a jóváhagyások
- a hozzáférést kezdeményező osztály vezetőjétől (például könyvelés)
- a műszaki osztály vezetőjétől, ahonnan ez a kérés a hálózati osztályhoz érkezett (például helpdesk)
Ebben az esetben a hozzáférés „tulajdonosa” a hozzáférést kezdeményező osztály vezetője (a példánkban a könyvelés), és ő felelős azért, hogy az adott részleg naplózott hozzáférésű oldala naprakész legyen. .
Fakitermelés
Ez az, amibe bele lehet fulladni. Ha azonban proaktív megközelítést szeretne alkalmazni, akkor meg kell tanulnia, hogyan kezelje ezt az adatözönt.
Íme néhány gyakorlati javaslat:
- naponta át kell néznie a naplókat
- tervezett felülvizsgálat (és nem vészhelyzet) esetén korlátozhatja magát a 0, 1, 2 súlyossági szintre, és ha szükségesnek tartja, más szintekből is hozzáadhat kiválasztott mintákat
- írjon egy szkriptet, amely elemzi a naplókat, és figyelmen kívül hagyja azokat a naplókat, amelyek mintáit hozzáadta a mellőzési listához
Ez a megközelítés lehetővé teszi, hogy idővel figyelmen kívül hagyó listát hozzon létre azokról a naplókról, amelyek nem érdekesek az Ön számára, és csak azokat hagyja meg, amelyeket valóban fontosnak tart.
Nekünk remekül bevált.
megfigyelés
Nem ritka, hogy egy cégnél hiányzik a monitoring rendszer. Bízhat például a naplókban, de előfordulhat, hogy a berendezés egyszerűen „meghal” anélkül, hogy lenne ideje „mondani” valamit, vagy az udp syslog protokoll csomagja elveszhet, és nem érkezik meg. Általában természetesen az aktív megfigyelés fontos és szükséges.
A két legnépszerűbb példa a gyakorlatomban:
- kommunikációs csatornák, kritikus linkek terhelésének figyelése (például szolgáltatókhoz való csatlakozás). Lehetővé teszik, hogy proaktívan láthassa a forgalom elvesztése miatti szolgáltatásromlás lehetséges problémáját, és ennek megfelelően elkerülje azt.
- grafikonok a NetFlow alapján. Könnyűvé teszik a forgalom anomáliáinak megtalálását, és nagyon hasznosak néhány egyszerű, de jelentős típusú hackertámadás észlelésében.
Fontos! SMS-értesítések beállítása a legkritikusabb eseményekről. Ez vonatkozik a megfigyelésre és a naplózásra is. Ha nincs ügyeleti műszak, akkor munkaidőn kívül is érkezzen sms.
Gondolja végig a folyamatot úgy, hogy ne ébressze fel az összes mérnököt. Erre egy mérnökünk volt szolgálatban.
Válts irányítást
Véleményem szerint nem szükséges minden változást ellenőrizni. De mindenesetre szükség esetén könnyen meg kell találnia, hogy ki és miért végzett bizonyos változtatásokat a hálózaton.
Néhány tipp:
- jegyrendszerrel részletezheti, hogy mi történt az adott jeggyel, például az alkalmazott konfiguráció bemásolásával a jegybe
- kommentelési lehetőségeket használjon a hálózati eszközökön (például a Juniperen írjon megjegyzést). Leírhatod a jegy számát
- használja a konfigurációs biztonsági másolatok diff-jét
Ezt egy folyamatként is végrehajthatja, naponta felülvizsgálva az összes jegyet a változások miatt.
A folyamatok
Formalizálnia és le kell írnia a folyamatokat a csapatában. Ha elérte ezt a pontot, akkor csapatában már futnia kell legalább a következő folyamatoknak:
Napi folyamatok:
- jegyekkel dolgozik
- rönkökkel dolgozik
- Válts irányítást
- napi csekklap
Éves folyamatok:
- garanciák, engedélyek kiterjesztése
Aszinkron folyamatok:
- reagálni a különböző vészhelyzetekre
Az első rész lezárása
Észrevetted, hogy mindez még nem a hálózati konfigurációról szól, nem a tervezésről, nem a hálózati protokollokról, nem az útválasztásról, nem a biztonságról... Ez valami körülötte van. De ezek, bár talán unalmasak, természetesen nagyon fontos elemei egy hálózati részleg munkájának.
Eddig, amint látja, semmit sem javított a hálózatán. Ha voltak biztonsági rések, akkor azok megmaradtak, ha rossz volt a tervezés, akkor megmaradt. Amíg nem alkalmazta készségeit és tudását hálózati mérnökként, amelyre nagy valószínűséggel sok időt, erőfeszítést és néha pénzt költött. De először létre kell hoznia (vagy meg kell erősítenie) az alapot, majd el kell kezdenie az építkezést.
A következő részekből megtudhatja, hogyan találhatja meg és háríthatja el a hibákat, majd javíthatja infrastruktúráját.
Természetesen nem kell mindent egymás után csinálni. Az idő kritikus lehet. Végezze el párhuzamosan, ha az erőforrások engedik.
És egy fontos kiegészítés. Kommunikálj, kérdezz, konzultálj csapatoddal. Végül ők azok, akik támogatják és megteszik mindezt.
Forrás: will.com