Denne artikel er den første i en serie af artikler "Hvordan man får netværksinfrastrukturen under kontrol". Indholdet af alle artikler i serien og links kan findes .
Jeg antager, at der findes tilstrækkeligt mange virksomheder, hvor en simpel netværksnedetid på en time eller endda en dag ikke er kritisk. Desværre eller heldigvis har jeg ikke haft fornøjelsen af at arbejde i sådanne steder. Men selvfølgelig er der forskellige netværk, forskellige krav, forskellige tilgange, og trods alt vil den liste, der præsenteres nedenfor, i mange tilfælde være ''must-do'' i en eller anden form.
Så, udgangsbetingelserne.
Du er på en ny arbejdsplads, eller du har fået forfremmelse, eller du har besluttet at se på dine opgaver på en ny måde. Virksomhedens netværk er dit ansvar. For dig er det i høj grad en udfordring og noget nyt, der delvist retfærdiggør den vejledende tone i denne artikel :). Men jeg håber, at artiklen også kan være nyttig for enhver netværkstekniker.
Dit første strategiske mål er at lære at modstå entropi og opretholde det ønskede serviceniveau.
Mange af de opgaver, der er beskrevet nedenfor, kan løses med forskellige midler. Jeg bringer bevidst ikke emnet teknisk implementering op, da det ofte ikke er så vigtigt, hvordan du løser en bestemt opgave, men hvordan du bruger løsningen, og om du overhovedet bruger den. Der er ikke meget gavn af for eksempel dit professionelt opbyggede overvågningssystem, hvis du ikke kigger på det og ikke reagerer på alarmerne.
Udstyr
Først skal du forstå, hvor de største risici ligger.
Igen kan det variere. Jeg antager, at et sted for eksempel vil det være sikkerhedsspørgsmål, et andet sted spørgsmål relateret til tjenestens kontinuitet, og et andet sted måske noget helt andet. Hvorfor ikke?
Lad os antage for klarhedens skyld, at det trods alt er tjenestens kontinuitet (sådan har det været i alle de virksomheder, jeg har arbejdet for).
Så skal vi begynde med udstyret. Her er en liste over emner, som du skal være opmærksom på:
- klassificering af udstyr efter kritikalitet
- reserveudstyr til kritisk udstyr
- support, licenser
Du skal overveje mulige fejlmuligheder, især med det udstyr, der befinder sig øverst i din kritikalitetsklassifikation. Man overser ofte sandsynligheden for dobbelte problemer, ellers kan dine løsninger og support blive urimeligt dyre. Men i tilfælde af virkelig kritiske netværkskomponenter, hvis nedbrud kan have en væsentlig indflydelse på forretningen, bør du også overveje dette.
Eksempel
Lad os antage, at vi taler om rodkontrolleren i datacenteret.
Da vi er blevet enige om, at kontinuitet i servicen er det vigtigste kriterium, er det fornuftigt at sikre „hot“ redundans af dette udstyr. Men det er ikke alt. Du skal også bestemme, hvor meget tid, det er acceptabelt for dig, at leve med kun én fungerende switch i tilfælde af nedbrud af den første switch, for der er en risiko for, at også den går i stykker.
Vigtigt! Du må ikke tage denne beslutning alene. Du skal beskrive risiciene, mulige løsninger og omkostningerne for din ledelse eller virksomhedsledelse. Det er dem, der skal træffe beslutningerne.
Så hvis det er blevet besluttet, at under betingelsen med en lille sandsynlighed for dobbelt nedbrud, at det at arbejde i fire timer på en switch i princippet er acceptabelt, kan du bare tage den relevante support (hvor udstyret vil blive erstattet inden for fire timer).
Men der er jo en risiko for, at de ikke leverer. Desværre har vi en gang været i en sådan situation. I stedet for fire timer tog det ugen!!!
Derfor skal denne risiko også diskuteres, og måske er det bedre for dig at købe endnu en switch (den tredje) og holde den som en reserve („cold“ redundancy) eller bruge den til laboratorieformål.
Vigtigt! Lav en liste over al den support, du har, med udløbsdatoer, og tilføj dem til din kalender, så du mindst en måned før får en påmindelse 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 udløber, går dit udstyr ned.
Nødarbejde
Uanset hvad der sker i dit netværk, bør du i ideelle tilfælde bevare adgangen til dit netværksudstyr.
Vigtigt! Du skal have konsoladgang til alt udstyr, og denne adgang må ikke afhænge af netværksforbindelsens funktionalitet.
Du skal også på forhånd overveje mulige negative scenarier og dokumentere de nødvendige handlinger. Tilgængeligheden af dette dokument er ligeledes kritisk, så det skal ikke kun være tilgængeligt på en fælles afdelingressource, men også gemmes lokalt på ingeniørernes computere.
Det skal der være
- information, der er nødvendig for at åbne en supportanmodning hos leverandøren eller integratoren
- information om, hvordan man får adgang til enhver udstyr (konsol, management)
Der kan selvfølgelig også være andre nyttige oplysninger, såsom en beskrivelse af opgraderingsprocedurer for forskelligt udstyr og nyttige diagnosekommandoer.
Partnere
Nu skal du vurdere risiciene forbundet med partnere. Dette omfatter typisk
- internetudbydere og trafik exchange punkter (IX)
- kommunikationskanaludbydere
Hvilke spørgsmål skal du stille dig selv? Som med udstyret skal du overveje forskellige nødscenarier. For eksempel, for internetudbydere, kan det være noget som:
- hvad sker der, hvis internetudbyder X af en eller anden grund stopper med at levere service til dig?
- har du tilstrækkelig båndbredde fra de øvrige udbydere?
- hvordan forbliver forbindelsen i orden?
- hvor uafhængige er dine internetudbydere, og vil en alvorlig hændelse hos én føre til problemer hos de andre?
- hvor mange optiske indgange har dit datacenter?
- hvad sker der, hvis en af indgangene bliver totalt ødelagt?
Om indgange, i min erfaring i to forskellige virksomheder, i to forskellige datacentre graverne har ødelagt brøndene, og kun af ren held er vores fiber ikke blevet ramt. Det er ikke en så sjælden hændelse.
Og naturligvis er det ikke nok bare at stille disse spørgsmål; igen, med ledelsens støtte skal du sikre en acceptabel løsning i enhver situation.
Backup
Næste prioritet kan være backup af konfigurationer for udstyret. Under alle omstændigheder er det et meget vigtigt punkt. Jeg vil ikke nævne de tilfælde, hvor du kan miste konfigurationen; det er bedre at lave backup regelmæssigt og ikke tænke over det. Desuden kan regelmæssig backup være meget nyttig til at kontrollere ændringer.
Vigtigt! Sørg for at tage backup dagligt. Det er ikke så stort et datavolumen, at man skal spare på det. Om morgenen skal den ansvarlige ingeniør (eller du) modtage en rapport fra systemet, der klart angiver, om backuppen var vellykket eller ikke, og i tilfælde af en mislykket backup skal problemet løses, eller der skal oprettes en billet (se netværksafdelingens processer).
Versioner af software
Spørgsmålet om, hvorvidt det er nødvendigt at opgradere hardwarens software, er ikke så entydigt. På den ene side er gamle versioner præget af kendte fejl og sårbarheder, men på den anden side er ny software ikke altid en smertefri opgraderingsprocedure, og der kan komme nye fejl og sårbarheder.
Her skal man finde den optimale løsning. Her er nogle åbenlyse anbefalinger:
- installer kun stabile versioner
- man bør ikke leve på helt gamle softwareversioner
- lav et skema med information om, hvilken software der er installeret hvor
- læs periodisk rapporter om sårbarheder og fejl i softwareversioner, og hvis der er kritiske problemer, bør man overveje at opgradere
På dette stadie, med konsoladgang til udstyret, information om support og en beskrivelse af opgraderingsproceduren, er du i princippet klar til dette skridt. Den ideelle situation er, når du har laboratorieudstyr, hvor du kan teste hele proceduren, men desværre sker det ikke ofte.
I tilfælde af kritisk udstyr kan du henvende dig til leverandørens support med anmodning om hjælp til at gennemføre opgraderingen.
Billetsystem
Nu kan du se dig omkring. Du skal etablere processer for interaktion med andre afdelinger og inden for afdelingen.
Måske er det ikke obligatorisk (f.eks. hvis dit firma er lille), men jeg vil stærkt anbefale at organisere arbejdet, så alle eksterne og interne opgaver går gennem ticketsystemet.
Ticketsystemet er i det væsentlige dit interface for interne og eksterne kommunikationer, og du skal beskrive dette interface med tilstrækkelig detaljer.
Lad os tage et vigtigt og ofte forekommende eksempel på en opgave om at åbne adgang. Jeg vil beskrive den algoritme, der fungerede fremragende i et af virksomhederne.
Eksempel
Lad os starte med, at bestillere af adgang ofte formulerer deres ønsker på en sprog, der er uklart for netværksingeniøren, nemlig på applikationssproget, for eksempel, “åbn 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 det Unix, Windows, helpdesk-ingeniører).
Det andet krav er, at
- denne adgang skal være protokolleret (af den tekniske afdeling, som vi modtog denne anmodning fra), og som anmodning modtager vi et link til denne protokolleret adgang.
Formen for denne anmodning skal være forståelig for os, det vil sige,
- anmodningen skal indeholde oplysninger om, fra hvilken og til hvilken subnet adgang skal åbnes, samt om protokollen og (i tilfælde af tcp/udp) portene.
Der skal også angives
- en beskrivelse af, hvorfor denne adgang åbnes.
- midlertidig eller permanent (hvis midlertidig, så indtil hvilken dato).
Og et meget vigtigt punkt er godkendelser.
- fra lederen af afdelingen, der har initieret adgangen (for eksempel regnskabsafdelingen).
- fra lederen af den tekniske afdeling, hvorfra denne anmodning kom til netværksafdelingen (for eksempel helpdesk).
Her betragtes lederen af afdelingen, der har initieret adgangen (regnskabsafdelingen i vores eksempel) som “ejeren” af denne adgang, og han er ansvarlig for, at siden med de protokollerede adgange for denne afdeling forbliver aktuel.
Logføring
Dette er noget, man kan drukne i. Men hvis du ønsker at implementere en proaktiv tilgang, skal du lære at håndtere denne datastrøm.
Her er nogle praktiske anbefalinger:
- logs skal gennemgås dagligt.
- Ved planlagt gennemgang (og ikke i en nødsituation) kan man begrænse sig til kritikalitetsniveauer (severity) 0, 1, 2 og tilføje udvalgte mønstre fra andre niveauer, hvis det anses for nødvendigt.
- Skriv et script, der parser logs og ignorerer de logs, hvis mønstre du har tilføjet til en ignorerliste.
Denne tilgang vil over tid gøre det muligt at sammensætte en ignorerliste over logs, der ikke interesserer dig, og kun tilbageholde dem, som du virkelig anser for vigtige.
Det fungerede glimrende 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 blot "døde", før det når at "sige" noget, eller en UDP-pakke fra syslog-protokollen kan gå tabt. Generelt er aktiv overvågning selvfølgelig vigtig og nødvendig.
To af de mest efterspurgte eksempler i min praksis:
- overvågning af belastningen på kommunikationskanaler, kritiske forbindelser (for eksempel forbindelser til udbydere). Dette gør det muligt at se potentielle problemer med serviceforringelse på grund af tab af trafik og derved undgå det.
- grafer baseret på NetFlow. De gør det let at finde anomalier i trafikken og er meget nyttige til at opdage nogle simple, men væsentlige former for hackerangreb.
Vigtigt! Indstil sms-notifikationer for de mest kritiske hændelser. Dette gælder både for overvågning og logfiler. Hvis du ikke har en vagt, skal sms'er også sendes uden for arbejdstid.
Planlæg processen således, at du ikke vækker alle ingeniørerne. Vi havde en vagtingeniør til dette.
Ændringskontrol
Efter min mening er det ikke nødvendigt at kontrollere alle ændringer. Men under alle omstændigheder skal du have mulighed for nemt at finde ud af, hvem der har foretaget hvilke ændringer i netværket, hvis det er nødvendigt.
Nogle tips:
- brug et ticketsystem til detaljeret beskrivelse af, hvad der er gjort i forbindelse med dette ticket, for eksempel ved at kopiere den anvendte konfiguration til ticketen.
- brug kommentarfunktionerne på netværksudstyr (for eksempel commit comment på Juniper). Du kan notere ticketnummeret.
- brug diffusoren af dine konfigurationsbackups.
Du kan indføre dette som en proces ved dagligt at gennemgå alle tickets for ændringer.
Processer
Du skal formalisere og beskrive processerne i dit team. Hvis du er nået til dette punkt, skal der i dit team allerede være følgende processer:
Daglige processer:
- arbejde med tickets
- arbejde med logfiler
- ændringskontrol
- daglig tjekliste
Årlige processer:
- fornyelse af garantier, licenser
Asynkrone processer:
- reagering på forskellige nødsituationer
Konklusion på første del
Har du bemærket, at alt dette ikke handler om netværkskonfiguration, design, netværksprotokoller, routing eller sikkerhed... Det er noget omkring det. Men selvom det måske virker kedeligt, er det selvfølgelig meget vigtige elementer i netværksafdelingens arbejde.
Som du kan se, har du indtil videre ikke forbedret dit netværk. Hvis der har været sikkerhedssårbarheder, så er de stadig der, hvis designet var dårligt, så er det stadig dårligt. Du har ikke brugt dine færdigheder og viden som netværksingeniør, som sandsynligvis har krævet en stor mængde tid, kræfter og nogle gange penge. Men først skal du skabe (eller styrke) fundamentet, og derefter kan du begynde at bygge.
Om hvordan man finder og afhjælper fejl, og dernæst forbedrer din infrastruktur – dette vil være emnet for de næste dele.
Selvfølgelig er det ikke nødvendigt 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ådspørg dit team. I sidste ende er det dem, der skal vedligeholde og udføre alt dette.
Kilde: habr.com
