Cet article est le premier d'une série d'articles « Comment prendre le contrôle de votre infrastructure réseau ». Le contenu de tous les articles de la série et les liens peuvent être trouvés .
J'admets pleinement qu'il existe un nombre suffisant d'entreprises où une indisponibilité du réseau d'une heure voire d'une journée n'est pas critique. Malheureusement ou heureusement, je n'ai pas eu l'occasion de travailler dans de tels endroits. Mais, bien sûr, les réseaux sont différents, les exigences sont différentes, les approches sont différentes, et pourtant, sous une forme ou une autre, la liste ci-dessous sera dans de nombreux cas en réalité un « incontournable ».
Donc les conditions initiales.
Vous occupez un nouvel emploi, vous avez reçu une promotion ou vous avez décidé de porter un nouveau regard sur vos responsabilités. Le réseau d'entreprise est votre domaine de responsabilité. Pour vous, il s'agit à bien des égards d'un défi et d'une nouveauté, ce qui justifie quelque peu le ton mentoral de cet article :). Mais j'espère que l'article pourra également être utile à tout ingénieur réseau.
Votre premier objectif stratégique est d'apprendre à résister à l'entropie et à maintenir le niveau de service fourni.
La plupart des problèmes décrits ci-dessous peuvent être résolus par divers moyens. Je n'aborde délibérément pas le sujet de la mise en œuvre technique, car... en principe, la manière dont vous avez résolu tel ou tel problème n'est souvent pas si importante, mais ce qui est important, c'est comment vous l'utilisez et si vous l'utilisez du tout. Par exemple, votre système de surveillance conçu par des professionnels est de peu d’utilité si vous ne le regardez pas et ne répondez pas aux alertes.
équipement
Vous devez d’abord comprendre où se situent les plus grands risques.
Encore une fois, cela peut être différent. J'avoue que quelque part, par exemple, ce seront des questions de sécurité, et quelque part, des questions liées à la continuité du service, et quelque part, peut-être, autre chose. Pourquoi pas?
Supposons, pour être clair, qu’il s’agisse toujours d’une continuité de service (c’était le cas dans toutes les entreprises où j’ai travaillé).
Ensuite, vous devez commencer par l’équipement. Voici une liste de sujets auxquels il faut prêter attention :
- classification des équipements par degré de criticité
- sauvegarde des équipements critiques
- assistance, licences
Vous devez réfléchir aux scénarios de défaillance possibles, en particulier avec des équipements en tête de votre classification de criticité. Habituellement, la possibilité de doubles problèmes est négligée, sinon votre solution et votre support pourraient devenir excessivement coûteux, mais dans le cas d'éléments de réseau véritablement critiques, dont la défaillance pourrait affecter considérablement l'entreprise, vous devriez y penser.
Exemple
Disons que nous parlons d'un commutateur racine dans un centre de données.
Puisque nous avons convenu que la continuité du service est le critère le plus important, il est raisonnable de prévoir une sauvegarde « à chaud » (redondance) de cet équipement. Mais ce n'est pas tout. Vous devez également décider combien de temps, si le premier interrupteur tombe en panne, est-il acceptable que vous viviez avec un seul interrupteur restant, car il existe un risque qu'il se brise également.
Important! Vous n'êtes pas obligé de résoudre ce problème vous-même. Vous devez décrire les risques, les solutions possibles et les coûts à la direction ou à la direction de l'entreprise. Ils doivent prendre des décisions.
Ainsi, s'il a été décidé que, compte tenu de la faible probabilité d'une double panne, travailler pendant 4 heures sur un interrupteur est en principe acceptable, alors vous pouvez simplement prendre le support approprié (selon lequel l'équipement sera remplacé dans les 4 heures). heures).
Mais il y a un risque qu’ils ne tiennent pas leurs promesses. Malheureusement, nous nous sommes retrouvés une fois dans une telle situation. Au lieu de quatre heures, le matériel a voyagé pendant une semaine !!!
Par conséquent, ce risque doit également être discuté et, peut-être, il serait plus correct pour vous d'acheter un autre interrupteur (un troisième) et de le conserver dans un emballage de pièces de rechange (sauvegarde « à froid ») ou de l'utiliser à des fins de laboratoire.
Important! Créez une feuille de calcul de tout le support dont vous disposez avec les dates d'expiration et ajoutez-la à votre calendrier afin de recevoir un e-mail au moins un mois à l'avance vous informant que vous devriez commencer à vous soucier du renouvellement de votre support.
Vous ne serez pas pardonné si vous oubliez de renouveler votre support et que le lendemain de la fin de celui-ci, votre matériel tombe en panne.
Travaux d'urgence
Quoi qu’il arrive sur votre réseau, vous devriez idéalement conserver l’accès à votre équipement réseau.
Important! Vous devez disposer d'un accès console à tous les équipements et cet accès ne doit pas dépendre de la santé du réseau de données utilisateur.
Vous devez également prévoir à l’avance d’éventuels scénarios négatifs et documenter les actions nécessaires. La disponibilité de ce document est également essentielle, il doit donc non seulement être publié sur une ressource partagée pour le département, mais également sauvegardé localement sur les ordinateurs des ingénieurs.
Il doit y avoir
- informations requises pour ouvrir un ticket avec le support du fournisseur ou de l'intégrateur
- informations sur l'accès à n'importe quel équipement (console, gestion)
Bien entendu, il peut également contenir toute autre information utile, par exemple une description de la procédure de mise à niveau de divers équipements et des commandes de diagnostic utiles.
partenaires
Vous devez maintenant évaluer les risques associés aux partenaires. Habituellement ceci
- Fournisseurs Internet et points d'échange de trafic (IX)
- fournisseurs de canaux de communication
Quelles questions devriez-vous vous poser ? Comme pour les équipements, différents scénarios d’urgence doivent être envisagés. Par exemple, pour les fournisseurs d’accès Internet, cela pourrait ressembler à :
- que se passe-t-il si le fournisseur Internet X cesse de vous fournir le service pour une raison quelconque ?
- Les autres fournisseurs auront-ils suffisamment de bande passante pour vous ?
- Quelle sera la qualité de la connectivité ?
- Dans quelle mesure vos fournisseurs d'accès Internet sont-ils indépendants et une panne grave de l'un d'entre eux entraînera-t-elle des problèmes avec les autres ?
- combien d'entrées optiques dans votre centre de données ?
- que se passera-t-il si l’une des entrées est complètement détruite ?
Concernant les intrants, dans mon cabinet dans deux entreprises différentes, dans deux centres de données différents, une excavatrice a détruit des puits et par miracle nos optiques n'ont pas été affectées. Ce n'est pas un cas si rare.
Et, bien sûr, vous devez non seulement poser ces questions, mais, encore une fois, avec le soutien de la direction, apporter une solution acceptable dans n'importe quelle situation.
Sauvegarde
La prochaine priorité pourrait être une sauvegarde des configurations des équipements. En tout cas, c'est un point très important. Je ne listerai pas les cas où l'on peut perdre la configuration, il vaut mieux faire des sauvegardes régulières et ne pas y penser. De plus, des sauvegardes régulières peuvent être très utiles pour suivre les modifications.
Important! Faites des sauvegardes quotidiennement. Ce n’est pas une grande quantité de données à économiser à ce sujet. Dans la matinée, l'ingénieur de service (ou vous) devriez recevoir un rapport du système, qui indique clairement si la sauvegarde a réussi ou non, et si la sauvegarde a échoué, le problème doit être résolu ou un ticket doit être créé ( voir processus du service réseau).
Versions du logiciel
La question de savoir s’il vaut la peine de mettre à niveau le logiciel de l’équipement n’est pas aussi claire. D'une part, les anciennes versions sont des bugs et des vulnérabilités connus, mais d'autre part, les nouveaux logiciels ne sont pas toujours une procédure de mise à niveau indolore et, d'autre part, de nouveaux bugs et vulnérabilités.
Ici, vous devez trouver la meilleure option. Quelques recommandations évidentes
- installer uniquement les versions stables
- Pourtant, vous ne devriez pas vivre avec de très anciennes versions de logiciels
- faire un panneau avec des informations sur l'emplacement de certains logiciels
- lisez périodiquement les rapports sur les vulnérabilités et les bugs dans les versions du logiciel, et en cas de problèmes critiques, vous devriez penser à une mise à niveau
A ce stade, disposant d'un accès console au matériel, d'informations sur le support et d'une description de la procédure de mise à niveau, vous êtes, en principe, prêt pour cette étape. L'option idéale est lorsque vous disposez d'un équipement de laboratoire où vous pouvez vérifier l'ensemble de la procédure, mais malheureusement, cela n'arrive pas souvent.
Dans le cas d’un équipement critique, vous pouvez contacter le support du fournisseur avec une demande d’aide pour la mise à niveau.
Système de tickets
Maintenant, vous pouvez regarder autour de vous. Vous devez établir des processus d'interaction avec d'autres départements et au sein du département.
Cela n'est peut-être pas nécessaire (par exemple, si votre entreprise est petite), mais je vous recommande fortement d'organiser le travail de manière à ce que toutes les tâches externes et internes passent par le système de tickets.
Le système de tickets est essentiellement votre interface pour les communications internes et externes, et vous devez décrire cette interface de manière suffisamment détaillée.
Prenons un exemple d'une tâche importante et courante d'ouverture de l'accès. Je vais décrire un algorithme qui a parfaitement fonctionné dans l'une des entreprises.
Exemple
Commençons par le fait que souvent les clients d'accès formulent leurs désirs dans un langage incompréhensible pour un ingénieur réseau, à savoir dans le langage de l'application, par exemple « donnez-moi accès à 1C ».
Par conséquent, nous n’avons jamais accepté les demandes directement de ces utilisateurs.
Et c'était la première exigence
- les demandes d'accès doivent provenir des services techniques (dans notre cas, il s'agissait d'ingénieurs Unix, Windows, Helpdesk)
La deuxième exigence est que
- cet accès doit être enregistré (par le service technique dont nous avons reçu cette demande) et en guise de demande nous recevons un lien vers cet accès enregistré
La forme de cette demande doit nous être compréhensible, c'est-à-dire
- la demande doit contenir des informations sur le sous-réseau et sur quel sous-réseau l'accès doit être ouvert, ainsi que le protocole et (dans le cas de TCP/UDP) les ports
Il convient également d'y indiquer
- description de la raison pour laquelle cet accès est ouvert
- temporaire ou permanent (si temporaire, jusqu'à quelle date)
Et un point très important concerne les approbations
- du chef du service qui a initié l'accès (par exemple, comptabilité)
- du chef du service technique, d'où cette demande est venue au service réseau (par exemple, helpdesk)
Dans ce cas, le « propriétaire » de cet accès est considéré comme le chef du service qui a initié l'accès (comptabilité dans notre exemple), et il lui incombe de veiller à ce que la page avec les accès journalisés pour ce service reste à jour. .
Enregistrement
C'est quelque chose dans lequel vous pouvez vous noyer. Mais si vous souhaitez mettre en œuvre une approche proactive, vous devez alors apprendre à gérer ce déluge de données.
Voici quelques recommandations pratiques :
- vous devez consulter les journaux quotidiennement
- dans le cas d'un examen planifié (et non d'une situation d'urgence), vous pouvez vous limiter aux niveaux de gravité 0, 1, 2 et ajouter des modèles sélectionnés à partir d'autres niveaux si vous le jugez nécessaire
- écrivez un script qui analyse les journaux et ignore les journaux dont vous avez ajouté les modèles à la liste des ignorés
Cette approche vous permettra, au fil du temps, de créer une liste ignorée des logs qui ne vous intéressent pas et de ne laisser que ceux que vous considérez vraiment comme importants.
Cela a très bien fonctionné pour nous.
Surveillance
Il n’est pas rare qu’une entreprise ne dispose pas d’un système de surveillance. Vous pouvez, par exemple, vous fier aux journaux, mais l'équipement peut simplement « mourir » sans avoir le temps de « dire » quoi que ce soit, ou le paquet du protocole udp syslog peut être perdu et ne pas arriver. En général, bien entendu, une surveillance active est importante et nécessaire.
Les deux exemples les plus populaires dans ma pratique :
- surveiller la charge des canaux de communication, les liens critiques (par exemple, la connexion aux fournisseurs). Ils vous permettent de voir de manière proactive le problème potentiel de dégradation du service dû à la perte de trafic et, par conséquent, de l'éviter.
- graphiques basés sur NetFlow. Ils facilitent la recherche d'anomalies dans le trafic et sont très utiles pour détecter certains types d'attaques de pirates simples mais significatives.
Important! Configurez des notifications SMS pour les événements les plus critiques. Cela s’applique à la fois à la surveillance et à la journalisation. Si vous n'avez pas de service, les SMS doivent également arriver en dehors des heures de travail.
Réfléchissez au processus de manière à ne pas réveiller tous les ingénieurs. Nous avions un ingénieur de service pour cela.
Le contrôle des changements
À mon avis, il n’est pas nécessaire de contrôler tous les changements. Mais, dans tous les cas, vous devriez pouvoir, si nécessaire, retrouver facilement qui a effectué certaines modifications sur le réseau et pourquoi.
Quelques conseils:
- utiliser un système de ticket pour détailler ce qui a été fait sur ce ticket, par exemple en copiant la configuration appliquée dans le ticket
- utiliser les fonctionnalités de commentaires sur les équipements réseau (par exemple, valider un commentaire sur Juniper). Vous pouvez noter le numéro du billet
- utilisez le diff de vos sauvegardes de configuration
Vous pouvez mettre en œuvre cela sous forme de processus, en examinant quotidiennement tous les tickets pour détecter les modifications.
Processus
Vous devez formaliser et décrire les processus dans votre équipe. Si vous avez atteint ce point, votre équipe devrait déjà avoir au moins les processus suivants en cours d'exécution :
Processus quotidiens :
- travailler avec des billets
- travailler avec des journaux
- le contrôle des changements
- feuille de contrôle quotidienne
Processus annuels :
- extension de garanties, licences
Processus asynchrones :
- réponse à diverses situations d'urgence
Conclusion de la première partie
Avez-vous remarqué que tout cela n'est pas encore une question de configuration réseau, ni de conception, ni de protocoles réseau, ni de routage, ni de sécurité... C'est quelque chose autour. Mais ces éléments, même s'ils sont peut-être ennuyeux, constituent évidemment des éléments très importants du travail d'une division de réseau.
Jusqu’à présent, comme vous pouvez le constater, vous n’avez rien amélioré dans votre réseau. S’il y avait des failles de sécurité, elles persistaient ; si la conception était mauvaise, elles persistaient. Jusqu'à ce que vous ayez appliqué vos compétences et vos connaissances en tant qu'ingénieur réseau, auxquelles vous avez probablement consacré beaucoup de temps, d'efforts et parfois d'argent. Mais vous devez d’abord créer (ou renforcer) les fondations, puis commencer la construction.
Les parties suivantes vous expliqueront comment rechercher et éliminer les erreurs, puis améliorer votre infrastructure.
Bien entendu, vous n’êtes pas obligé de tout faire dans l’ordre. Le temps peut être critique. Faites-le en parallèle si les ressources le permettent.
Et un ajout important. Communiquez, demandez, consultez votre équipe. En fin de compte, ce sont eux qui soutiennent et font tout cela.
Source: habr.com