Denne artikel er den første i en serie af artikler "Sådan tager du kontrol over din netværksinfrastruktur." Indholdet af alle artikler i serien og links kan findes .
Jeg indrømmer fuldt ud, at der er et tilstrækkeligt antal virksomheder, hvor en netværksnedetid på en time eller endda en dag ikke er kritisk. Desværre eller heldigvis havde jeg ikke mulighed for at arbejde sådanne steder. Men selvfølgelig er netværkene forskellige, kravene er forskellige, tilgangene er forskellige, og alligevel, i en eller anden form, vil nedenstående liste i mange tilfælde faktisk være et "must-do".
Altså de indledende betingelser.
Du er i et nyt job, du har fået en forfremmelse, eller du har besluttet dig for at tage et nyt blik på dit ansvar. Virksomhedsnetværket er dit ansvarsområde. For dig er dette på mange måder en udfordring og nyt, hvilket i nogen grad retfærdiggør mentortonen i denne artikel :). Men jeg håber, at artiklen også kan være nyttig for enhver netværksingeniør.
Dit første strategiske mål er at lære at modstå entropi og opretholde serviceniveauet.
Mange af de problemer, der er beskrevet nedenfor, kan løses på forskellige måder. Jeg rejser bevidst ikke emnet teknisk implementering, fordi... i princippet er det ofte ikke så vigtigt, hvordan du har løst dette eller hint problem, men det vigtige er, hvordan du bruger det, og om du overhovedet bruger det. For eksempel er dit professionelt byggede overvågningssystem til ringe nytte, hvis du ikke ser på det og ikke reagerer på advarsler.
Оборудование
Først skal du forstå, hvor de største risici er.
Igen kan det være anderledes. Jeg indrømmer, at et eller andet sted, for eksempel, vil disse være sikkerhedsproblemer, og et eller andet sted, spørgsmål relateret til kontinuiteten af tjenesten, og et eller andet sted, måske, noget andet. Hvorfor ikke?
Lad os antage, for at være tydelige, at dette stadig er kontinuitet i tjenesten (dette var tilfældet i alle de virksomheder, hvor jeg arbejdede).
Så skal du i gang med udstyret. Her er en liste over emner, du skal være opmærksom på:
- klassificering af udstyr efter grad af kritikalitet
- backup af kritisk udstyr
- support, licenser
Du skal gennemtænke mulige fejlscenarier, især med udstyr øverst i din kritikalitetsklassificering. Normalt negligeres muligheden for dobbelte problemer, ellers kan din løsning og support blive urimeligt dyr, men i tilfælde af virkelig kritiske netværkselementer, hvis svigt kan påvirke virksomheden betydeligt, bør du tænke dig om.
Eksempel
Lad os sige, at vi taler om en rodswitch i et datacenter.
Da vi var enige om, at servicekontinuitet er det vigtigste kriterium, er det rimeligt at levere "hot" backup (redundans) af dette udstyr. Men det er ikke alt. Du skal også tage stilling til, hvor længe, hvis det første skifte går i stykker, er det acceptabelt for dig at leve med kun én tilbageværende kontakt, fordi der er risiko for, at den også går i stykker.
Vigtig! Du behøver ikke selv at afgøre dette spørgsmål. Du skal beskrive risici, mulige løsninger og omkostninger for ledelsen eller virksomhedsledelsen. De skal træffe beslutninger.
Så hvis det blev besluttet, at i betragtning af den lille sandsynlighed for en dobbeltfejl, at arbejde i 4 timer på en kontakt i princippet er acceptabelt, kan du blot tage den passende støtte (i henhold til hvilken udstyret vil blive udskiftet inden for 4 timer).
Men der er en risiko for, at de ikke leverer. Desværre stod vi engang i sådan en situation. I stedet for fire timer rejste udstyret i en uge!!!
Derfor skal denne risiko også diskuteres, og måske vil det være mere korrekt for dig at købe en anden switch (tredje) og opbevare den i en reservedelspakke (“kold” backup) eller bruge den til laboratorieformål.
Vigtig! Lav et regneark med al den support du har med udløbsdatoer og tilføj det til din kalender, så du får en mail mindst en måned i forvejen om, at du skal begynde at bekymre dig om at forny din support.
Du vil ikke blive tilgivet, hvis du glemmer at forny din support, og dagen efter den slutter går din hardware i stykker.
Akut arbejde
Uanset hvad der sker på dit netværk, bør du ideelt set bevare adgangen til dit netværksudstyr.
Vigtig! Du skal have konsoladgang til alt udstyr, og denne adgang bør ikke afhænge af brugerdatanetværkets tilstand.
Du bør også forudse mulige negative scenarier på forhånd og dokumentere de nødvendige handlinger. Tilgængeligheden af dette dokument er også kritisk, så det bør ikke kun lægges op på en delt ressource for afdelingen, men også gemmes lokalt på ingeniørernes computere.
Der må være
- oplysninger, der kræves for at åbne en billet med leverandør- eller integratorsupport
- oplysninger om, hvordan du kommer til udstyr (konsol, ledelse)
Det kan selvfølgelig også indeholde enhver anden nyttig information, for eksempel en beskrivelse af opgraderingsproceduren for forskelligt udstyr og nyttige diagnostiske kommandoer.
Affiliates
Nu skal du vurdere de risici, der er forbundet med partnere. Normalt dette
- Internetudbydere og trafikudvekslingspunkter (IX)
- udbydere af kommunikationskanaler
Hvilke spørgsmål skal du stille dig selv? Som med udstyr skal forskellige nødscenarier tages i betragtning. For internetudbydere kan det for eksempel være noget som:
- hvad sker der, hvis internetudbyder X af en eller anden grund holder op med at give dig service?
- Vil andre udbydere have nok båndbredde til dig?
- Hvor god vil forbindelsen forblive?
- Hvor uafhængige er dine internetudbydere, og vil et alvorligt afbrydelse af en af dem give problemer med de andre?
- hvor mange optiske input til dit datacenter?
- hvad vil der ske, hvis en af inputs er fuldstændig ødelagt?
Angående input, i min praksis i to forskellige virksomheder, i to forskellige datacentre Gravemaskinen ødelagde brøndene, og det var kun ved et mirakel, at vores optik ikke blev beskadiget. Det er ikke en så sjælden begivenhed.
Og selvfølgelig skal du ikke kun stille disse spørgsmål, men igen, med støtte fra ledelsen, at levere en acceptabel løsning i enhver situation.
Backup
Den næste prioritet kan være en backup af udstyrskonfigurationer. Under alle omstændigheder er dette en meget vigtig pointe. Jeg vil ikke liste de tilfælde, hvor du kan miste konfigurationen, det er bedre at lave regelmæssige sikkerhedskopier og ikke tænke på det. Derudover kan regelmæssige sikkerhedskopier være meget nyttige til overvågning af ændringer.
Vigtig! Lav sikkerhedskopier dagligt. Det er ikke så stor en mængde data at spare på dette. Om morgenen skulle den vagthavende ingeniør (eller du) modtage en rapport fra systemet, som tydeligt angiver, om sikkerhedskopieringen var vellykket eller ej, og hvis sikkerhedskopieringen var mislykket, skulle problemet løses, eller der skulle oprettes en billet ( se netværksafdelingens processer).
Software versioner
Spørgsmålet om, hvorvidt det er værd at opgradere udstyrets software, er ikke så entydigt. På den ene side er gamle versioner kendte fejl og sårbarheder, men på den anden side er ny software for det første ikke altid en smertefri opgraderingsprocedure, og for det andet nye fejl og sårbarheder.
Her skal du finde den bedste mulighed. Et par oplagte anbefalinger
- installer kun stabile versioner
- Alligevel bør du ikke leve af meget gamle versioner af software
- lave et skilt med information om, hvor noget software er placeret
- læs med jævne mellemrum rapporter om sårbarheder og fejl i softwareversioner, og i tilfælde af kritiske problemer bør du overveje at opgradere
På dette stadium, med konsoladgang til udstyret, information om support og en beskrivelse af opgraderingsproceduren, er du i princippet klar til dette trin. Den ideelle mulighed er, når du har laboratorieudstyr, hvor du kan kontrollere hele proceduren, men det sker desværre ikke ofte.
I tilfælde af kritisk udstyr kan du kontakte leverandørens support med en anmodning om at hjælpe dig med opgraderingen.
Billetsystem
Nu kan du se dig omkring. Du skal etablere processer for interaktion med andre afdelinger og inden for afdelingen.
Det er måske ikke nødvendigt (f.eks. hvis din virksomhed er lille), men jeg vil varmt anbefale at tilrettelægge arbejdet på en sådan måde, at alle eksterne og interne opgaver går gennem billetsystemet.
Billetsystemet er i bund og grund din grænseflade til intern og ekstern kommunikation, og du bør beskrive denne grænseflade tilstrækkeligt detaljeret.
Lad os tage et eksempel på en vigtig og fælles opgave med at åbne adgang. Jeg vil beskrive en algoritme, der fungerede perfekt i en af virksomhederne.
Eksempel
Lad os starte med det faktum, at adgangskunder ofte formulerer deres ønsker på et sprog, der er uforståeligt for en netværksingeniør, nemlig på applikationens sprog, for eksempel "giv mig adgang til 1C."
Derfor har vi aldrig accepteret anmodninger direkte fra sådanne brugere.
Og det var det første krav
- anmodninger om adgang skal komme fra tekniske afdelinger (i vores tilfælde var disse unix, windows, helpdesk-ingeniører)
Det andet krav er det
- denne adgang skal logges (af den tekniske afdeling, som vi modtog denne anmodning fra) og som en anmodning modtager vi et link til denne loggede adgang
Formen for denne anmodning skal være forståelig for os, dvs.
- anmodningen skal indeholde information om hvilket undernet og til hvilket undernetadgang der skal være åben, samt protokollen og (ved tcp/udp) porte
Det skal også angives der
- beskrivelse af, hvorfor denne adgang åbnes
- midlertidig eller permanent (hvis midlertidig, indtil hvilken dato)
Og et meget vigtigt punkt er godkendelser
- fra lederen af den afdeling, der påbegyndte adgangen (f.eks. regnskab)
- fra lederen af den tekniske afdeling, hvorfra denne anmodning kom til netværksafdelingen (f.eks. helpdesk)
I dette tilfælde anses "ejeren" af denne adgang for at være lederen af den afdeling, der påbegyndte adgangen (regnskab i vores eksempel), og han er ansvarlig for at sikre, at siden med logget adgang for denne afdeling forbliver opdateret .
Logning
Det er noget, du kan drukne i. Men hvis du vil implementere en proaktiv tilgang, så skal du lære, hvordan du håndterer denne dataflod.
Her er nogle praktiske anbefalinger:
- du skal gennemgå loggene dagligt
- i tilfælde af en planlagt gennemgang (og ikke en nødsituation), kan du begrænse dig til sværhedsgrad 0, 1, 2 og tilføje udvalgte mønstre fra andre niveauer, hvis du finder det nødvendigt
- skriv et script, der analyserer logfiler og ignorerer de logfiler, hvis mønstre du har tilføjet til ignoreringslisten
Denne tilgang vil give dig mulighed for over tid at oprette en ignoreringsliste over logfiler, der ikke er interessante for dig, og kun efterlade dem, som du virkelig anser for vigtige.
Det fungerede fantastisk for os.
overvågning
Det er ikke ualmindeligt, at en virksomhed mangler et overvågningssystem. Du kan for eksempel stole på logfiler, men udstyret kan simpelthen "dø" uden at have tid til at "sige" noget, eller udp syslog-protokolpakken kan gå tabt og ikke ankomme. Generelt er aktiv overvågning naturligvis vigtig og nødvendig.
De to mest populære eksempler i min praksis:
- overvågning af belastningen af kommunikationskanaler, kritiske links (for eksempel forbindelse til udbydere). De giver dig mulighed for proaktivt at se det potentielle problem med serviceforringelse på grund af tab af trafik og dermed undgå det.
- grafer baseret på NetFlow. De gør det nemt at finde uregelmæssigheder i trafikken og er meget nyttige til at opdage nogle simple, men væsentlige typer hackerangreb.
Vigtig! Konfigurer SMS-beskeder for de mest kritiske hændelser. Det gælder både overvågning og logning. Har du ikke vagthold, så skal sms også komme udenfor arbejdstiden.
Tænk processen igennem på en sådan måde, at du ikke vækker alle ingeniørerne. Vi havde en ingeniør på vagt til dette.
Skift kontrol
Efter min mening er det ikke nødvendigt at kontrollere alle ændringer. Men under alle omstændigheder bør du om nødvendigt nemt kunne finde ud af, hvem der har foretaget visse ændringer på netværket og hvorfor.
Et par tips:
- bruge et billetsystem til at detaljere, hvad der blev gjort på den billet, for eksempel ved at kopiere den anvendte konfiguration ind i billetten
- bruge kommentarfunktioner på netværksudstyr (for eksempel commit comment på Juniper). Du kan skrive billetnummeret ned
- brug diff af dine konfigurations backups
Du kan implementere dette som en proces, og gennemgå alle billetter dagligt for ændringer.
processer
Du skal formalisere og beskrive processerne i dit team. Hvis du har nået dette punkt, bør dit team allerede have mindst følgende processer kørende:
Daglige processer:
- arbejder med billetter
- arbejder med logs
- ændre kontrol
- dagligt kontrolark
Årlige processer:
- forlængelse af garantier, licenser
Asynkrone processer:
- reaktion på forskellige nødsituationer
Konklusion på første del
Har du lagt mærke til, at alt dette endnu ikke handler om netværkskonfiguration, ikke om design, ikke om netværksprotokoller, ikke om routing, ikke om sikkerhed... Det er noget rundt. Men disse, selvom de måske er kedelige, er naturligvis meget vigtige elementer i arbejdet i en netværksafdeling.
Indtil videre, som du kan se, har du ikke forbedret noget i dit netværk. Hvis der var sikkerhedssårbarheder, så forblev de, hvis der var dårligt design, så forblev det. Indtil du har brugt dine færdigheder og viden som netværksingeniør, som du højst sandsynligt har brugt en stor mængde tid, kræfter og nogle gange penge på. Men først skal du skabe (eller styrke) fundamentet og derefter begynde at bygge.
De følgende dele fortæller dig, hvordan du finder og fjerner fejl og derefter forbedrer din infrastruktur.
Du behøver selvfølgelig ikke at gøre alt sekventielt. Tid kan være kritisk. Gør det parallelt, hvis ressourcerne tillader det.
Og en vigtig tilføjelse. Kommuniker, spørg, rådfør dig med dit team. I sidste ende er det dem, der støtter og gør alt dette.
Kilde: www.habr.com
