Denne artikkelen er den første i en serie artikler "Hvordan ta kontroll over nettverksinfrastrukturen din." Innholdet i alle artiklene i serien og lenker finner du .
Jeg innrømmer fullt ut at det er et tilstrekkelig antall selskaper der en nedetid på nettverket på én time eller til og med én dag ikke er kritisk. Dessverre eller heldigvis hadde jeg ikke mulighet til å jobbe på slike steder. Men, selvfølgelig, nettverkene er forskjellige, kravene er forskjellige, tilnærmingene er forskjellige, og likevel, i en eller annen form, vil listen nedenfor i mange tilfeller faktisk være et "må-gjøre".
Så de første betingelsene.
Du er i en ny jobb, du har fått opprykk, eller du har bestemt deg for å ta en ny titt på dine ansvarsområder. Bedriftsnettverket er ditt ansvarsområde. For deg er dette på mange måter en utfordring og nytt, noe som rettferdiggjør veiledningstonen i denne artikkelen :). Men jeg håper at artikkelen også kan være nyttig for enhver nettverksingeniør.
Ditt første strategiske mål er å lære å motstå entropi og opprettholde servicenivået som tilbys.
Mange av problemene beskrevet nedenfor kan løses på forskjellige måter. Jeg tar bevisst ikke opp temaet teknisk implementering, fordi... i prinsippet er det ofte ikke så viktig hvordan du løste det eller det problemet, men det som er viktig er hvordan du bruker det og om du i det hele tatt bruker det. For eksempel er ditt profesjonelt bygde overvåkingssystem til liten nytte hvis du ikke ser på det og ikke reagerer på varsler.
Оборудование
Først må du forstå hvor de største risikoene er.
Igjen, det kan være annerledes. Jeg innrømmer at et sted, for eksempel, vil dette være sikkerhetsspørsmål, og et sted, problemer knyttet til kontinuiteten i tjenesten, og et eller annet sted, kanskje, noe annet. Hvorfor ikke?
La oss anta, for å være tydelig, at dette fortsatt er kontinuitet i tjenesten (dette var tilfellet i alle selskapene der jeg jobbet).
Da må du begynne med utstyret. Her er en liste over emner du bør være oppmerksom på:
- klassifisering av utstyr etter grad av kritikalitet
- backup av kritisk utstyr
- støtte, lisenser
Du må tenke gjennom mulige feilscenarier, spesielt med utstyr på toppen av kritikalitetsklassifiseringen. Vanligvis blir muligheten for doble problemer neglisjert, ellers kan løsningen og støtten din bli urimelig dyr, men i tilfelle av virkelig kritiske nettverkselementer, hvis feil kan påvirke virksomheten betydelig, bør du tenke på det.
Eksempel
La oss si at vi snakker om en rotsvitsj i et datasenter.
Siden vi var enige om at tjenestekontinuitet er det viktigste kriteriet, er det rimelig å gi "hot" backup (redundans) av dette utstyret. Men det er ikke alt. Du må også bestemme hvor lenge, hvis den første bryteren bryter, er det akseptabelt for deg å leve med bare én gjenværende bryter, fordi det er en risiko for at den også går i stykker.
Viktig! Du trenger ikke bestemme dette problemet selv. Du må beskrive risiko, mulige løsninger og kostnader til ledelsen eller selskapsledelsen. De må ta avgjørelser.
Så hvis det ble bestemt at, gitt den lille sannsynligheten for en dobbel feil, er det i prinsippet akseptabelt å jobbe i 4 timer på en bryter, så kan du ganske enkelt ta riktig støtte (i henhold til hvilken utstyret vil bli erstattet innen 4 timer).
Men det er en risiko for at de ikke leverer. Dessverre befant vi oss en gang i en slik situasjon. I stedet for fire timer reiste utstyret i en uke!!!
Derfor må denne risikoen også diskuteres, og kanskje vil det være mer riktig for deg å kjøpe en annen bryter (tredje) og ha den i en reservedelspakke («kald» backup) eller bruke den til laboratorieformål.
Viktig! Lag et regneark over all støtten du har med utløpsdatoer og legg den til i kalenderen din slik at du får en e-post minst en måned i forveien om at du bør begynne å bekymre deg for å fornye støtten.
Du vil ikke bli tilgitt hvis du glemmer å fornye støtten og dagen etter at den avsluttes, går maskinvaren i stykker.
Nødarbeid
Uansett hva som skjer på nettverket ditt, bør du ideelt sett ha tilgang til nettverksutstyret ditt.
Viktig! Du må ha konsolltilgang til alt utstyr og denne tilgangen skal ikke avhenge av helsen til brukerdatanettverket.
Du bør også forutse mulige negative scenarier på forhånd og dokumentere nødvendige handlinger. Tilgjengeligheten av dette dokumentet er også kritisk, så det bør ikke bare legges ut på en delt ressurs for avdelingen, men også lagres lokalt på ingeniørenes datamaskiner.
Det må være
- informasjon som kreves for å åpne en billett med leverandør- eller integratorstøtte
- informasjon om hvordan du kommer til utstyr (konsoll, ledelse)
Selvfølgelig kan den også inneholde annen nyttig informasjon, for eksempel en beskrivelse av oppgraderingsprosedyren for diverse utstyr og nyttige diagnosekommandoer.
partnere
Nå må du vurdere risikoen knyttet til partnere. Vanligvis dette
- Internett-leverandører og trafikkutvekslingspunkter (IX)
- leverandører av kommunikasjonskanaler
Hvilke spørsmål bør du stille deg selv? Som med utstyr må ulike nødscenarier vurderes. For Internett-leverandører kan det for eksempel være noe sånt som:
- hva skjer hvis Internett-leverandøren X slutter å gi deg tjenester av en eller annen grunn?
- Vil andre leverandører ha nok båndbredde til deg?
- Hvor god vil tilkoblingen forbli?
- Hvor uavhengige er Internett-leverandørene dine, og vil et alvorlig avbrudd hos en av dem skape problemer med de andre?
- hvor mange optiske innganger til datasenteret ditt?
- hva vil skje hvis en av inngangene blir fullstendig ødelagt?
Når det gjelder input, i min praksis i to forskjellige selskaper, i to forskjellige datasentre, ødela en gravemaskin brønner og bare ved et mirakel ble ikke optikken vår påvirket. Dette er ikke et så sjeldent tilfelle.
Og, selvfølgelig, trenger du ikke bare å stille disse spørsmålene, men igjen, med støtte fra ledelsen, for å gi en akseptabel løsning i enhver situasjon.
backup
Neste prioritet kan være en sikkerhetskopi av utstyrskonfigurasjoner. Uansett er dette et veldig viktig poeng. Jeg vil ikke liste opp de tilfellene når du kan miste konfigurasjonen; det er bedre å ta regelmessige sikkerhetskopier og ikke tenke på det. I tillegg kan regelmessige sikkerhetskopier være svært nyttige for å overvåke endringer.
Viktig! Lag sikkerhetskopier daglig. Dette er ikke så store datamengder å spare på dette. Om morgenen bør vakthavende ingeniør (eller du) motta en rapport fra systemet, som tydelig indikerer om sikkerhetskopieringen var vellykket eller ikke, og hvis sikkerhetskopieringen var mislykket, bør problemet løses eller en billett opprettes ( se prosesser for nettverksavdelingen).
Programvareversjoner
Spørsmålet om det er verdt å oppgradere programvaren til utstyret er ikke så entydig. På den ene siden er gamle versjoner kjente bugs og sårbarheter, men på den andre siden er ny programvare for det første ikke alltid en smertefri oppgraderingsprosedyre, og for det andre nye bugs og sårbarheter.
Her må du finne det beste alternativet. Noen få åpenbare anbefalinger
- installer kun stabile versjoner
- Likevel bør du ikke leve på veldig gamle versjoner av programvare
- lage et skilt med informasjon om hvor noe programvare befinner seg
- les periodisk rapporter om sårbarheter og feil i programvareversjoner, og ved kritiske problemer bør du tenke på å oppgradere
På dette stadiet, med konsolltilgang til utstyret, informasjon om støtte og en beskrivelse av oppgraderingsprosedyren, er du i prinsippet klar for dette trinnet. Det ideelle alternativet er når du har laboratorieutstyr hvor du kan sjekke hele prosedyren, men dessverre skjer dette ikke ofte.
Ved kritisk utstyr kan du kontakte leverandørens support med en forespørsel om å hjelpe deg med oppgraderingen.
Billettsystem
Nå kan du se deg rundt. Du må etablere prosesser for samhandling med andre avdelinger og innad i avdelingen.
Dette er kanskje ikke nødvendig (for eksempel hvis din bedrift er liten), men jeg vil sterkt anbefale å organisere arbeidet på en slik måte at alle eksterne og interne oppgaver går gjennom billettsystemet.
Billettsystemet er i hovedsak ditt grensesnitt for intern og ekstern kommunikasjon, og du bør beskrive dette grensesnittet i tilstrekkelig detalj.
La oss ta et eksempel på en viktig og vanlig oppgave med å åpne tilgang. Jeg vil beskrive en algoritme som fungerte perfekt i et av selskapene.
Eksempel
La oss starte med det faktum at tilgangskunder ofte formulerer sine ønsker på et språk som er uforståelig for en nettverksingeniør, nemlig på applikasjonsspråket, for eksempel "gi meg tilgang til 1C."
Derfor har vi aldri akseptert forespørsler direkte fra slike brukere.
Og det var det første kravet
- forespørsler om tilgang bør komme fra tekniske avdelinger (i vårt tilfelle var disse unix, windows, helpdesk-ingeniører)
Det andre kravet er det
- denne tilgangen må logges (av den tekniske avdelingen som vi mottok denne forespørselen fra) og som en forespørsel mottar vi en lenke til denne loggede tilgangen
Formen på denne forespørselen må være forståelig for oss, dvs.
- Forespørselen må inneholde informasjon om hvilket subnett og hvilket subnetttilgang som skal være åpen, samt protokoll og (ved tcp/udp) porter
Det skal også angis der
- beskrivelse av hvorfor denne tilgangen åpnes
- midlertidig eller permanent (hvis midlertidig, til hvilken dato)
Og et veldig viktig poeng er godkjenninger
- fra avdelingslederen som initierte tilgang (for eksempel regnskap)
- fra sjefen for teknisk avdeling, hvorfra denne forespørselen kom til nettverksavdelingen (for eksempel helpdesk)
I dette tilfellet anses "eieren" av denne tilgangen å være lederen av avdelingen som initierte tilgangen (regnskap i vårt eksempel), og han er ansvarlig for å sørge for at siden med logget tilgang for denne avdelingen forblir oppdatert .
Hogst
Dette er noe du kan drukne i. Men hvis du vil implementere en proaktiv tilnærming, må du lære deg hvordan du håndterer denne datafloden.
Her er noen praktiske anbefalinger:
- du må gå gjennom loggene daglig
- i tilfelle av en planlagt gjennomgang (og ikke en nødsituasjon), kan du begrense deg til alvorlighetsgradene 0, 1, 2 og legge til utvalgte mønstre fra andre nivåer hvis du anser det nødvendig
- skriv et skript som analyserer logger og ignorerer de loggene hvis mønstre du la til i ignoreringslisten
Denne tilnærmingen vil tillate deg, over tid, å lage en ignoreringsliste over logger som ikke er interessante for deg og bare la de du virkelig anser som viktige.
Det fungerte utmerket for oss.
overvåking
Det er ikke uvanlig at en bedrift mangler et overvåkingssystem. Du kan for eksempel stole på logger, men utstyret kan ganske enkelt "dø" uten å ha tid til å "si" noe, eller udp syslog-protokollpakken kan gå tapt og ikke ankomme. Generelt er selvsagt aktiv overvåking viktig og nødvendig.
De to mest populære eksemplene i min praksis:
- overvåking av belastningen på kommunikasjonskanaler, kritiske lenker (for eksempel tilkobling til leverandører). De lar deg proaktivt se det potensielle problemet med tjenesteforringelse på grunn av tap av trafikk og følgelig unngå det.
- grafer basert på NetFlow. De gjør det enkelt å finne uregelmessigheter i trafikken og er svært nyttige for å oppdage noen enkle, men betydelige typer hackerangrep.
Viktig! Sett opp SMS-varsler for de mest kritiske hendelsene. Dette gjelder både overvåking og logging. Har du ikke vakthold, så bør sms også komme utenom arbeidstid.
Tenk gjennom prosessen på en slik måte at du ikke vekker alle ingeniørene. Vi hadde en ingeniør på vakt for dette.
Endre kontroll
Etter min mening er det ikke nødvendig å kontrollere alle endringer. Men i alle fall bør du om nødvendig enkelt kunne finne hvem som har gjort visse endringer på nettverket og hvorfor.
Noen tips:
- bruk et billettsystem for å detaljere hva som ble gjort på den billetten, for eksempel ved å kopiere den brukte konfigurasjonen inn i billetten
- bruk kommentarfunksjoner på nettverksutstyr (for eksempel commit comment på Juniper). Du kan skrive ned billettnummeret
- bruk diff av konfigurasjonssikkerhetskopiene
Du kan implementere dette som en prosess, og gjennomgå alle billetter daglig for endringer.
prosesser
Du må formalisere og beskrive prosessene i teamet ditt. Hvis du har nådd dette punktet, bør teamet ditt allerede ha minst følgende prosesser i gang:
Daglige prosesser:
- jobber med billetter
- arbeider med logger
- endre kontroll
- daglig sjekkark
Årlige prosesser:
- utvidelse av garantier, lisenser
Asynkrone prosesser:
- respons på ulike nødsituasjoner
Konklusjon av første del
Har du lagt merke til at alt dette ennå ikke handler om nettverkskonfigurasjon, ikke om design, ikke om nettverksprotokoller, ikke om ruting, ikke om sikkerhet... Det er noe rundt. Men disse, selv om de kanskje er kjedelige, er selvfølgelig svært viktige elementer i arbeidet til en nettverksavdeling.
Så langt, som du kan se, har du ikke forbedret noe i nettverket ditt. Hvis det var sikkerhetssårbarheter, så ble de værende; hvis det var dårlig design, så forble det. Inntil du har brukt dine ferdigheter og kunnskaper som nettverksingeniør, som du mest sannsynlig har brukt mye tid, krefter og noen ganger penger på. Men først må du lage (eller styrke) grunnlaget, og deretter begynne å bygge.
De følgende delene vil fortelle deg hvordan du finner og eliminerer feil, og deretter forbedrer infrastrukturen.
Du trenger selvfølgelig ikke gjøre alt sekvensielt. Tid kan være kritisk. Gjør det parallelt hvis ressursene tillater det.
Og et viktig tillegg. Kommuniser, spør, rådfør deg med teamet ditt. Til syvende og sist er det de som støtter og gjør alt dette.
Kilde: www.habr.com