Den här artikeln är den första i en serie artiklar "Hur du tar kontroll över din nätverksinfrastruktur." Innehållet i alla artiklar i serien och länkar finns .
Jag erkänner fullt ut att det finns tillräckligt många företag där en nätavbrottstid på en timme eller till och med en dag inte är kritisk. Tyvärr eller lyckligtvis hade jag inte möjlighet att arbeta på sådana platser. Men, naturligtvis, nätverken är olika, kraven är olika, tillvägagångssätten är olika, och ändå, i en eller annan form, kommer listan nedan i många fall faktiskt att vara ett "måste".
Så, de ursprungliga förutsättningarna.
Du har ett nytt jobb, du har fått befordran eller så har du bestämt dig för att ta en ny titt på ditt ansvar. Företagsnätverket är ditt ansvarsområde. För dig är detta på många sätt en utmaning och nytt, vilket till viss del motiverar mentorstonen i denna artikel :). Men jag hoppas att artikeln också kan vara användbar för alla nätverksingenjörer.
Ditt första strategiska mål är att lära dig att motstå entropi och bibehålla den servicenivå som tillhandahålls.
Många av problemen som beskrivs nedan kan lösas på olika sätt. Jag tar medvetet inte upp ämnet teknisk implementering, eftersom... i princip är det ofta inte så viktigt hur du löste det eller det problemet, utan det som är viktigt är hur du använder det och om du använder det överhuvudtaget. Till exempel är ditt professionellt byggda övervakningssystem till liten nytta om du inte tittar på det och inte svarar på varningar.
Оборудование
Först måste du förstå var de största riskerna finns.
Återigen, det kan vara annorlunda. Jag erkänner att någonstans, till exempel, kommer dessa att vara säkerhetsfrågor, och någonstans, frågor relaterade till kontinuiteten i tjänsten, och någonstans, kanske, något annat. Varför inte?
Låt oss anta, för att vara tydliga, att detta fortfarande är kontinuitet i tjänsten (detta var fallet i alla företag där jag arbetade).
Sedan måste du börja med utrustningen. Här är en lista över ämnen att uppmärksamma:
- klassificering av utrustning efter grad av kritikalitet
- backup av kritisk utrustning
- support, licenser
Du måste tänka igenom möjliga felscenarier, särskilt med utrustning överst i din klassificering av kritik. Vanligtvis försummas möjligheten till dubbla problem, annars kan din lösning och support bli orimligt dyra, men i fallet med verkligt kritiska nätverkselement, vars misslyckande kan påverka verksamheten avsevärt, bör du tänka på det.
Exempel
Låt oss säga att vi pratar om en rotswitch i ett datacenter.
Eftersom vi var överens om att tjänstens kontinuitet är det viktigaste kriteriet, är det rimligt att tillhandahålla "het" backup (redundans) av denna utrustning. Men det är inte allt. Du måste också bestämma dig för hur länge, om den första växeln går sönder, är det acceptabelt för dig att leva med endast en kvarvarande växel, eftersom det finns en risk att den också går sönder.
Viktig! Du behöver inte bestämma denna fråga själv. Du ska beskriva risker, möjliga lösningar och kostnader för ledningen eller företagsledningen. De måste fatta beslut.
Så om det beslutades att, med tanke på den lilla sannolikheten för ett dubbelfel, att arbeta i 4 timmar på en strömbrytare i princip är acceptabelt, kan du helt enkelt ta lämpligt stöd (enligt vilket utrustningen kommer att ersättas inom 4 timmar).
Men det finns en risk att de inte levererar. Tyvärr hamnade vi en gång i en sådan situation. Istället för fyra timmar reste utrustningen i en vecka!!!
Därför måste denna risk också diskuteras och kanske är det mer korrekt för dig att köpa en annan switch (tredje) och förvara den i ett reservdelspaket (”kall” backup) eller använda den för laboratorieändamål.
Viktig! Gör ett kalkylblad över all support du har med utgångsdatum och lägg till den i din kalender så att du får ett mail minst en månad i förväg om att du ska börja oroa dig för att förnya din support.
Du kommer inte att bli förlåten om du glömmer att förnya din support och dagen efter det upphör din hårdvara går sönder.
Nödarbete
Vad som än händer på ditt nätverk bör du helst ha tillgång till din nätverksutrustning.
Viktig! Du måste ha konsolåtkomst till all utrustning och denna åtkomst bör inte bero på tillståndet hos användardatanätverket.
Du bör också förutse möjliga negativa scenarier i förväg och dokumentera nödvändiga åtgärder. Tillgängligheten av detta dokument är också avgörande, så det bör inte bara läggas upp på en delad resurs för avdelningen, utan också sparas lokalt på ingenjörernas datorer.
Det måste finnas
- information som krävs för att öppna en biljett med leverantörs- eller integratörssupport
- information om hur man kommer till valfri utrustning (konsol, hantering)
Naturligtvis kan den också innehålla annan användbar information, till exempel en beskrivning av uppgraderingsproceduren för olika utrustningar och användbara diagnostiska kommandon.
partner
Nu måste du bedöma riskerna med partners. Vanligtvis detta
- Internetleverantörer och trafikutbytespunkter (IX)
- leverantörer av kommunikationskanaler
Vilka frågor bör du ställa dig själv? Liksom med utrustning måste olika nödsituationer beaktas. För internetleverantörer kan det till exempel vara något som:
- vad händer om internetleverantören X slutar tillhandahålla tjänster till dig av någon anledning?
- Kommer andra leverantörer att ha tillräckligt med bandbredd för dig?
- Hur bra kommer anslutningen att förbli?
- Hur oberoende är dina internetleverantörer och kommer ett allvarligt avbrott hos en av dem att orsaka problem med de andra?
- hur många optiska ingångar till ditt datacenter?
- vad händer om en av ingångarna förstörs helt?
När det gäller input, i min praktik i två olika företag, i två olika datacenter, förstörde en grävmaskin brunnar och bara genom mirakel påverkades inte vår optik. Detta är inte ett så ovanligt fall.
Och, naturligtvis, behöver du inte bara ställa dessa frågor, utan, återigen, med stöd från ledningen, för att tillhandahålla en acceptabel lösning i alla situationer.
Säkerhetskopiering
Nästa prioritet kan vara en säkerhetskopia av utrustningskonfigurationer. Detta är i alla fall en mycket viktig punkt. Jag kommer inte att lista de fall då du kan förlora konfigurationen; det är bättre att göra regelbundna säkerhetskopior och inte tänka på det. Dessutom kan regelbundna säkerhetskopior vara mycket användbara för att övervaka förändringar.
Viktig! Gör säkerhetskopior dagligen. Det här är inte så stor mängd data att spara på detta. På morgonen bör vakthavande ingenjör (eller du) få en rapport från systemet, som tydligt indikerar om säkerhetskopieringen lyckades eller inte, och om säkerhetskopieringen misslyckades bör problemet lösas eller en biljett skapas ( se nätverksavdelningens processer).
Programvaruversioner
Frågan om det är värt att uppgradera utrustningens programvara är inte så tydlig. Å ena sidan är gamla versioner kända buggar och sårbarheter, men å andra sidan är ny programvara för det första inte alltid en smärtfri uppgraderingsprocedur, och för det andra nya buggar och sårbarheter.
Här måste du hitta det bästa alternativet. Några uppenbara rekommendationer
- installera endast stabila versioner
- Ändå bör du inte leva på mycket gamla versioner av programvara
- göra en skylt med information om var viss programvara finns
- läs regelbundet rapporter om sårbarheter och buggar i mjukvaruversioner, och vid kritiska problem bör du tänka på att uppgradera
I detta skede, med konsolåtkomst till utrustningen, information om support och en beskrivning av uppgraderingsproceduren, är du i princip redo för detta steg. Det idealiska alternativet är när du har laboratorieutrustning där du kan kontrollera hela proceduren, men det händer tyvärr inte ofta.
I fallet med kritisk utrustning kan du kontakta leverantörens support med en begäran om att hjälpa dig med uppgraderingen.
Biljettsystem
Nu kan du se dig omkring. Du behöver etablera processer för interaktion med andra avdelningar och inom avdelningen.
Detta kanske inte är nödvändigt (till exempel om ditt företag är litet), men jag rekommenderar starkt att organisera arbetet på ett sådant sätt att alla externa och interna uppgifter går genom biljettsystemet.
Biljettsystemet är i huvudsak ditt gränssnitt för intern och extern kommunikation, och du bör beskriva detta gränssnitt tillräckligt detaljerat.
Låt oss ta ett exempel på en viktig och vanlig uppgift att öppna åtkomst. Jag kommer att beskriva en algoritm som fungerade perfekt i ett av företagen.
Exempel
Låt oss börja med det faktum att åtkomstkunder ofta formulerar sina önskemål på ett språk som är obegripligt för en nätverksingenjör, nämligen på applikationens språk, till exempel "ge mig tillgång till 1C."
Därför har vi aldrig accepterat förfrågningar direkt från sådana användare.
Och det var det första kravet
- förfrågningar om åtkomst bör komma från tekniska avdelningar (i vårt fall var dessa unix, windows, helpdesk-ingenjörer)
Det andra kravet är det
- denna åtkomst måste loggas (av den tekniska avdelning som vi fick denna begäran från) och som en begäran får vi en länk till denna loggade åtkomst
Formen på denna begäran måste vara förståelig för oss, d.v.s.
- begäran måste innehålla information om vilket subnät och vilket subnätaccess som ska vara öppen, samt protokoll och (vid tcp/udp) portar
Det bör också anges där
- beskrivning av varför denna åtkomst öppnas
- tillfälligt eller permanent (om det är tillfälligt, till vilket datum)
Och en mycket viktig punkt är godkännanden
- från avdelningschefen som initierade åtkomst (till exempel redovisning)
- från chefen för den tekniska avdelningen, varifrån denna förfrågan kom till nätverksavdelningen (till exempel helpdesk)
I det här fallet anses "ägaren" av denna åtkomst vara chefen för den avdelning som initierade åtkomsten (redovisning i vårt exempel), och han ansvarar för att sidan med loggad åtkomst för denna avdelning förblir uppdaterad .
Skogsavverkning
Det här är något man kan drunkna i. Men om du vill implementera ett proaktivt tillvägagångssätt måste du lära dig hur du hanterar denna dataflod.
Här är några praktiska rekommendationer:
- du måste granska loggarna dagligen
- vid en planerad granskning (och inte en nödsituation) kan du begränsa dig till svårighetsgrad 0, 1, 2 och lägga till valda mönster från andra nivåer om du anser det nödvändigt
- skriv ett skript som analyserar loggar och ignorerar de loggar vars mönster du lagt till i ignoreringslistan
Det här tillvägagångssättet gör att du med tiden kan skapa en ignoreringslista över loggar som inte är intressanta för dig och bara lämna de som du verkligen anser vara viktiga.
Det fungerade jättebra för oss.
övervakning
Det är inte ovanligt att ett företag saknar ett övervakningssystem. Du kan till exempel lita på loggar, men utrustningen kan helt enkelt "dö" utan att hinna "säga" något, eller så kan udp syslog-protokollpaketet gå förlorat och inte komma fram. Generellt sett är naturligtvis aktiv övervakning viktig och nödvändig.
De två mest populära exemplen i min praktik:
- övervakning av belastningen av kommunikationskanaler, kritiska länkar (till exempel anslutning till leverantörer). De låter dig proaktivt se det potentiella problemet med tjänsteförsämring på grund av förlust av trafik och följaktligen undvika det.
- grafer baserade på NetFlow. De gör det enkelt att hitta anomalier i trafiken och är mycket användbara för att upptäcka några enkla men betydande typer av hackerattacker.
Viktig! Ställ in SMS-aviseringar för de mest kritiska händelserna. Det gäller både övervakning och loggning. Om du inte har ett jourpass bör sms också komma utanför arbetstid.
Tänk igenom processen på ett sådant sätt att inte väcka alla ingenjörer. Vi hade en ingenjör i tjänst för detta.
Förändring kontroll
Enligt min mening är det inte nödvändigt att kontrollera alla förändringar. Men i alla fall bör du vid behov enkelt kunna hitta vem som gjort vissa ändringar i nätverket och varför.
Några tips:
- använd ett biljettsystem för att detaljera vad som gjordes på den biljetten, till exempel genom att kopiera den tillämpade konfigurationen till biljetten
- använd kommentarsfunktioner på nätverksutrustning (till exempel kommentera Juniper). Du kan skriva ner biljettnumret
- använd diff av dina konfigurationsbackuper
Du kan implementera detta som en process och granska alla biljetter dagligen för ändringar.
Processerna
Du ska formalisera och beskriva processerna i ditt team. Om du har nått denna punkt bör ditt team redan ha åtminstone följande processer igång:
Dagliga processer:
- arbetar med biljetter
- arbetar med stockar
- förändring kontroll
- dagligt kontrollblad
Årliga processer:
- förlängning av garantier, licenser
Asynkrona processer:
- reaktion på olika nödsituationer
Avslutning på första delen
Har du märkt att allt detta ännu inte handlar om nätverkskonfiguration, inte om design, inte om nätverksprotokoll, inte om routing, inte om säkerhet... Det är något runt. Men dessa, även om de kanske är tråkiga, är naturligtvis mycket viktiga delar av arbetet med en nätverksavdelning.
Så långt, som du kan se, har du inte förbättrat något i ditt nätverk. Om det fanns säkerhetsbrister så fanns de kvar, om det fanns dålig design så fanns det kvar. Tills du har tillämpat dina färdigheter och kunskaper som nätverksingenjör, som du med största sannolikhet har spenderat mycket tid, ansträngning och ibland pengar på. Men först måste du skapa (eller stärka) grunden och sedan börja bygga.
Följande delar berättar hur du hittar och eliminerar fel och sedan förbättrar din infrastruktur.
Naturligtvis behöver du inte göra allt sekventiellt. Tid kan vara kritisk. Gör det parallellt om resurserna tillåter.
Och ett viktigt tillägg. Kommunicera, fråga, rådgör med ditt team. I slutändan är det de som stöttar och gör allt detta.
Källa: will.com