Dit artikel is het eerste in een reeks artikelen 'Hoe u de controle over uw netwerkinfrastructuur overneemt'. De inhoud van alle artikelen in de serie en links zijn te vinden .
Ik geef volledig toe dat er voldoende bedrijven zijn waar een netwerkuitval van een uur of zelfs een dag niet kritisch is. Helaas of gelukkig heb ik niet de kans gehad om op zulke plaatsen te werken. Maar natuurlijk zijn de netwerken anders, de vereisten zijn anders, de benaderingen zijn verschillend, en toch zal de onderstaande lijst in een of andere vorm in veel gevallen feitelijk een “must-do” zijn.
De beginvoorwaarden dus.
U heeft een nieuwe baan, u heeft een promotie gekregen of u heeft besloten uw verantwoordelijkheden met een frisse blik te bekijken. Het bedrijfsnetwerk is jouw verantwoordelijkheidsgebied. Voor jou is dit in veel opzichten een uitdaging en nieuw, wat de mentortoon van dit artikel enigszins rechtvaardigt :). Maar ik hoop dat het artikel ook nuttig kan zijn voor elke netwerkingenieur.
Je eerste strategische doel is om te leren weerstand te bieden aan entropie en het geboden serviceniveau op peil te houden.
Veel van de hieronder beschreven problemen kunnen op verschillende manieren worden opgelost. Ik breng het onderwerp technische implementatie bewust niet ter sprake, omdat... in principe is het vaak niet zo belangrijk hoe je dit of dat probleem hebt opgelost, maar wat belangrijk is, is hoe je het gebruikt en of je het überhaupt gebruikt. Je professioneel gebouwde monitoringsysteem heeft bijvoorbeeld weinig nut als je er niet naar kijkt en niet reageert op waarschuwingen.
Uitrusting
Eerst moet u begrijpen waar de grootste risico's liggen.
Nogmaals, het kan anders zijn. Ik geef toe dat dit ergens bijvoorbeeld veiligheidsproblemen zullen zijn, en ergens kwesties die verband houden met de continuïteit van de dienst, en ergens misschien iets anders. Waarom niet?
Laten we voor alle duidelijkheid aannemen dat dit nog steeds de continuïteit van de dienstverlening betreft (dit was het geval in alle bedrijven waar ik werkte).
Dan moet je beginnen met de apparatuur. Hier is een lijst met onderwerpen waar u op moet letten:
- classificatie van apparatuur op basis van de mate van kriticiteit
- back-up van kritieke apparatuur
- ondersteuning, licenties
U moet mogelijke faalscenario's doordenken, vooral met apparatuur die bovenaan uw kriticiteitsclassificatie staat. Meestal wordt de mogelijkheid van dubbele problemen verwaarloosd, anders kunnen uw oplossing en ondersteuning onredelijk duur worden, maar in het geval van echt kritieke netwerkelementen, waarvan het falen aanzienlijke gevolgen voor het bedrijf zou kunnen hebben, moet u erover nadenken.
Voorbeeld
Laten we zeggen dat we het hebben over een root-switch in een datacenter.
Omdat we het erover eens zijn dat servicecontinuïteit het belangrijkste criterium is, is het redelijk om een “hot” back-up (redundantie) van deze apparatuur te bieden. Maar dat is niet alles. U moet ook beslissen hoe lang het acceptabel is om met slechts één resterende schakelaar te leven als de eerste schakelaar kapot gaat, omdat het risico bestaat dat deze ook kapot gaat.
Belangrijk! U hoeft dit probleem niet zelf te beslissen. U moet de risico's, mogelijke oplossingen en kosten voor het management of de bedrijfsleiding beschrijven. Zij moeten beslissingen nemen.
Dus als wordt besloten dat, gezien de kleine kans op een dubbele storing, 4 uur werken op één wissel in principe acceptabel is, dan kun je eenvoudigweg de juiste ondersteuning nemen (waarbij de apparatuur binnen 4 uur wordt vervangen). uur).
Maar het risico bestaat dat ze niet leveren. Helaas hebben wij ons ooit in een dergelijke situatie bevonden. In plaats van vier uur reisde de apparatuur een week lang!!!
Daarom moet dit risico ook worden besproken en misschien is het voor u juister om nog een schakelaar (derde) te kopen en deze in een pakket met reserveonderdelen te bewaren (“koude” back-up) of deze voor laboratoriumdoeleinden te gebruiken.
Belangrijk! Maak een spreadsheet van alle ondersteuning die u heeft, met vervaldata, en voeg deze toe aan uw agenda, zodat u minimaal een maand van tevoren een e-mail ontvangt dat u zich zorgen moet gaan maken over het verlengen van uw ondersteuning.
Het zal u niet worden vergeven als u vergeet uw ondersteuning te verlengen en de dag nadat deze is beëindigd, uw hardware kapot gaat.
Noodwerk
Wat er ook op uw netwerk gebeurt, idealiter moet u de toegang tot uw netwerkapparatuur behouden.
Belangrijk! U moet consoletoegang hebben tot alle apparatuur en deze toegang mag niet afhankelijk zijn van de gezondheid van het gebruikersdatanetwerk.
Ook moet u vooraf mogelijke negatieve scenario's voorzien en de noodzakelijke acties documenteren. De beschikbaarheid van dit document is ook van cruciaal belang, dus het moet niet alleen op een gedeelde bron voor de afdeling worden geplaatst, maar ook lokaal op de computers van de technici worden opgeslagen.
Er moet zijn
- informatie die nodig is om een ticket te openen met ondersteuning van een leverancier of integrator
- informatie over hoe u bij de apparatuur kunt komen (console, beheer)
Uiteraard kan het ook andere nuttige informatie bevatten, bijvoorbeeld een beschrijving van de upgradeprocedure voor verschillende apparatuur en nuttige diagnostische commando's.
partners
Nu moet u de risico's van partners beoordelen. Meestal dit
- Internetproviders en verkeersuitwisselingspunten (IX)
- aanbieders van communicatiekanalen
Welke vragen moet je jezelf stellen? Net als bij apparatuur moeten verschillende noodscenario's in aanmerking worden genomen. Voor internetproviders kan dit bijvoorbeeld zoiets zijn als:
- wat gebeurt er als internetprovider X om welke reden dan ook stopt met het verlenen van service?
- Hebben andere providers voldoende bandbreedte voor u?
- Hoe goed blijft de connectiviteit?
- Hoe onafhankelijk zijn uw internetproviders en zal een ernstige storing van één van hen problemen veroorzaken bij de anderen?
- hoeveel optische ingangen in uw datacenter?
- wat zal er gebeuren als een van de inputs volledig wordt vernietigd?
Wat de input betreft: in mijn praktijk in twee verschillende bedrijven, in twee verschillende datacenters, vernietigde een graafmachine putten en als bij wonder werd onze optiek niet beïnvloed. Dit is niet zo'n zeldzaam geval.
En u hoeft deze vragen natuurlijk niet alleen te stellen, maar ook, nogmaals, met de steun van het management, om in elke situatie een aanvaardbare oplossing te bieden.
Back-up
De volgende prioriteit kan een back-up van apparatuurconfiguraties zijn. Dit is in ieder geval een heel belangrijk punt. Ik zal de gevallen waarin u de configuratie kunt verliezen niet opsommen; het is beter om regelmatig back-ups te maken en er niet over na te denken. Bovendien kunnen regelmatige back-ups zeer nuttig zijn bij het monitoren van wijzigingen.
Belangrijk! Maak dagelijks back-ups. Het is niet zo'n grote hoeveelheid gegevens om hierop te besparen. In de ochtend ontvangt de dienstdoende monteur (of u) een rapport van het systeem, waarin duidelijk wordt aangegeven of de back-up is gelukt of niet, en als de back-up niet is gelukt, moet het probleem worden opgelost of moet er een ticket worden aangemaakt ( zie netwerkafdelingprocessen).
Softwareversies
De vraag of het de moeite waard is om de software van de apparatuur te upgraden is niet zo duidelijk. Aan de ene kant zijn oude versies bekende bugs en kwetsbaarheden, maar aan de andere kant is nieuwe software ten eerste niet altijd een pijnloze upgradeprocedure, en ten tweede nieuwe bugs en kwetsbaarheden.
Hier moet je de beste optie vinden. Een paar voor de hand liggende aanbevelingen
- installeer alleen stabiele versies
- Toch moet je niet leven met heel oude softwareversies
- maak een bord met informatie over waar bepaalde software zich bevindt
- lees regelmatig rapporten over kwetsbaarheden en bugs in softwareversies, en in geval van kritieke problemen moet u nadenken over upgraden
In dit stadium bent u, met consoletoegang tot de apparatuur, informatie over ondersteuning en een beschrijving van de upgradeprocedure, in principe klaar voor deze stap. De ideale optie is als u over laboratoriumapparatuur beschikt waarmee u de hele procedure kunt controleren, maar helaas gebeurt dit niet vaak.
In het geval van kritieke apparatuur kunt u contact opnemen met de ondersteuning van de leverancier met het verzoek om u te helpen bij de upgrade.
Ticketsysteem
Nu kun je rondkijken. Je moet processen opzetten voor interactie met andere afdelingen en binnen de afdeling.
Dit is misschien niet nodig (bijvoorbeeld als je bedrijf klein is), maar ik zou het ten zeerste aanbevelen om het werk zo te organiseren dat alle externe en interne taken via het ticketsysteem lopen.
Het ticketsysteem is in wezen uw interface voor interne en externe communicatie, en u moet deze interface voldoende gedetailleerd beschrijven.
Laten we een voorbeeld nemen van een belangrijke en veel voorkomende taak: het openen van toegang. Ik zal een algoritme beschrijven dat perfect werkte in een van de bedrijven.
Voorbeeld
Laten we beginnen met het feit dat klanten met toegang vaak hun wensen formuleren in een taal die onbegrijpelijk is voor een netwerkingenieur, namelijk in de taal van de applicatie, bijvoorbeeld: "geef mij toegang tot 1C."
Daarom hebben we nooit rechtstreeks verzoeken van dergelijke gebruikers geaccepteerd.
En dat was de eerste vereiste
- verzoeken om toegang moeten afkomstig zijn van technische afdelingen (in ons geval waren dit unix, windows, helpdesk engineers)
De tweede vereiste is dat
- deze toegang moet worden gelogd (door de technische dienst waarvan wij dit verzoek hebben ontvangen) en als verzoek ontvangen wij een link naar deze ingelogde toegang
De vorm van dit verzoek moet voor ons begrijpelijk zijn, d.w.z.
- het verzoek moet informatie bevatten over welk subnet en tot welk subnet toegang open moet zijn, evenals het protocol en (in het geval van tcp/udp) poorten
Het moet daar ook vermeld worden
- beschrijving van waarom deze toegang wordt geopend
- tijdelijk of permanent (indien tijdelijk, tot welke datum)
En een heel belangrijk punt zijn goedkeuringen
- van het hoofd van de afdeling die de toegang heeft geïnitieerd (bijvoorbeeld boekhouding)
- van het hoofd van de technische afdeling, vanwaar dit verzoek kwam naar de netwerkafdeling (bijvoorbeeld helpdesk)
In dit geval wordt de “eigenaar” van deze toegang beschouwd als het hoofd van de afdeling die de toegang heeft geïnitieerd (boekhouding in ons voorbeeld), en hij is er verantwoordelijk voor dat de pagina met ingelogde toegang voor deze afdeling up-to-date blijft .
Loggen
Dit is iets waar je in kunt verdrinken. Maar als je een proactieve aanpak wilt implementeren, moet je leren omgaan met deze datavloed.
Hier zijn enkele praktische aanbevelingen:
- u moet de logboeken dagelijks bekijken
- in het geval van een geplande beoordeling (en niet van een noodsituatie) kunt u zich beperken tot de ernstniveaus 0, 1, 2 en geselecteerde patronen uit andere niveaus toevoegen als u dat nodig acht
- schrijf een script dat logbestanden parseert en de logbestanden negeert waarvan u de patronen aan de negeerlijst hebt toegevoegd
Met deze aanpak kunt u na verloop van tijd een negeerlijst maken van logboeken die niet interessant voor u zijn, en alleen de logboeken achterlaten die u echt belangrijk vindt.
Het werkte prima voor ons.
controle
Het is niet ongebruikelijk dat een bedrijf geen monitoringsysteem heeft. U kunt bijvoorbeeld vertrouwen op logboeken, maar de apparatuur kan eenvoudigweg "uitvallen" zonder tijd te hebben om iets te "zeggen", of het udp-syslog-protocolpakket kan verloren gaan en niet aankomen. In het algemeen is actieve monitoring natuurlijk belangrijk en noodzakelijk.
De twee populairste voorbeelden in mijn praktijk:
- monitoring van de belasting van communicatiekanalen, kritische links (bijvoorbeeld verbinding maken met providers). Ze stellen u in staat proactief het potentiële probleem van serviceverslechtering als gevolg van verkeersverlies te onderkennen en dit dienovereenkomstig te vermijden.
- grafieken gebaseerd op NetFlow. Ze maken het gemakkelijk om afwijkingen in het verkeer te vinden en zijn zeer nuttig voor het detecteren van enkele eenvoudige maar belangrijke soorten hackeraanvallen.
Belangrijk! Stel sms-meldingen in voor de meest kritieke gebeurtenissen. Dit geldt zowel voor monitoring als voor logging. Heeft u geen dienst, dan moet de sms ook buiten werktijd binnenkomen.
Denk goed na over het proces, zodat niet alle ingenieurs wakker worden gemaakt. Hiervoor hadden we een monteur van dienst.
Verander controle
Naar mijn mening is het niet nodig om alle veranderingen te beheersen. Maar in ieder geval zou je, indien nodig, eenvoudig moeten kunnen achterhalen wie bepaalde wijzigingen op het netwerk heeft aangebracht en waarom.
Een paar tips:
- gebruik een ticketsysteem om gedetailleerd te beschrijven wat er op dat ticket is gedaan, bijvoorbeeld door de toegepaste configuratie naar het ticket te kopiëren
- gebruik commentaarmogelijkheden op netwerkapparatuur (commiteer bijvoorbeeld commentaar op Juniper). U kunt het ticketnummer noteren
- gebruik diff van uw configuratieback-ups
U kunt dit als een proces implementeren, waarbij u alle tickets dagelijks controleert op wijzigingen.
processen
Je moet de processen in je team formaliseren en beschrijven. Als je dit punt hebt bereikt, zou je team minimaal de volgende processen moeten hebben draaien:
Dagelijkse processen:
- werken met kaartjes
- werken met logboeken
- verander controle
- dagelijks controleblad
Jaarlijkse processen:
- verlenging van garanties, licenties
Asynchrone processen:
- reactie op diverse noodsituaties
Conclusie van het eerste deel
Is het je opgevallen dat dit allemaal nog niet over netwerkconfiguratie gaat, niet over ontwerp, niet over netwerkprotocollen, niet over routering, niet over beveiliging... Het is iets wat er omheen draait. Maar deze, hoewel misschien saai, zijn uiteraard zeer belangrijke elementen van het werk van een netwerkafdeling.
Tot nu toe heb je, zoals je kunt zien, niets verbeterd in je netwerk. Als er beveiligingsproblemen waren, dan bleven die; als er sprake was van een slecht ontwerp, dan bleef dat zo. Totdat u uw vaardigheden en kennis als netwerkingenieur heeft toegepast, waaraan u waarschijnlijk veel tijd, moeite en soms geld heeft besteed. Maar eerst moet je de basis leggen (of versterken) en dan beginnen met bouwen.
In de volgende onderdelen leest u hoe u fouten kunt opsporen en elimineren, en hoe u vervolgens uw infrastructuur kunt verbeteren.
Natuurlijk hoef je niet alles opeenvolgend te doen. Tijd kan van cruciaal belang zijn. Doe het parallel als de middelen dit toelaten.
En een belangrijke toevoeging. Communiceer, vraag, overleg met uw team. Uiteindelijk zijn zij degenen die dit allemaal ondersteunen en doen.
Bron: www.habr.com