Cet article est le premier d'une série d'articles intitulée « Comment prendre le contrôle de l'infrastructure réseau ». Le contenu de tous les articles de la série et les liens peuvent être trouvés .
Je suis tout à fait conscient qu'il existe un nombre suffisant d'entreprises où un simple réseau en une heure, voire une journée, n'est pas critique. Malheureusement ou heureusement, je n'ai pas eu l'occasion de travailler dans de tels endroits. Cependant, il est certain que les réseaux sont variés, les exigences différentes, et les approches également divergentes, et cependant, d'une manière ou d'une autre, la liste ci-dessous sera dans de nombreux cas un « must-do ».
Alors, les conditions initiales.
Vous êtes à un nouveau poste ou vous avez été promu, ou vous avez décidé de revoir vos responsabilités. Le réseau de l'entreprise est de votre responsabilité. Pour vous, c'est en grande partie un challenge et quelque chose de nouveau, ce qui justifie en partie le ton mentor de cet article :). Mais, j'espère que l'article peut également être utile à tout ingénieur réseau.
Votre premier objectif stratégique est d'apprendre à lutter contre l'entropie et à maintenir le niveau de service fourni.
De nombreuses tâches décrites ci-dessous peuvent être résolues par divers moyens. Je ne soulève intentionnellement pas le sujet de la mise en œuvre technique, car souvent il n'est pas si important comment vous avez résolu telle ou telle tâche, mais plutôt comment vous en faites usage et si vous l'utilisez du tout. Il y a peu d'intérêt, par exemple, à votre système de surveillance professionnellement élaboré si vous ne le consultez pas et ne réagissez pas aux alertes.
Matériel
La première chose à faire est de comprendre où se situent les plus grands risques.
Encore une fois, cela peut varier. Je suppose qu'à certains endroits, cela sera des questions de sécurité, ailleurs des questions liées à la continuité du service, ou peut-être autre chose. Pourquoi pas ?
Supposons pour des raisons de clarté qu'il s'agit tout de même de la continuité du service (c'était le cas dans toutes les entreprises où j'ai travaillé).
Alors, il faut commencer par le matériel. Voici une liste de thèmes sur lesquels porter votre attention :
- classification du matériel par degré de criticité
- redondance du matériel critique
- support, licences
Vous devez réfléchir aux éventuelles pannes, en particulier pour l'équipement se trouvant au sommet de votre classification de criticité. Il est courant de négliger la probabilité de pannes doubles, sinon votre solution et votre support peuvent devenir injustement coûteux. Mais dans le cas des éléments critiques du réseau, dont la défaillance peut avoir un impact significatif sur l'entreprise, vous devez aussi y réfléchir.
Exemple
Supposons que nous parlons du commutateur principal dans un data center.
Puisque nous avons convenu que la continuité de service est le critère le plus important, il est judicieux de prévoir une redondance pour cet équipement. Mais ce n'est pas tout. Vous devez également déterminer combien de temps, en cas de panne du premier commutateur, vous êtes prêt à fonctionner avec un seul commutateur restant, car il y a un risque qu'il tombe également en panne.
Important ! Vous ne devez pas décider de cette question seul. Vous devez décrire les risques, les solutions possibles et les coûts à votre direction ou à la direction de l'entreprise. Ce sont eux qui doivent prendre les décisions.
Ainsi, si il a été décidé qu'avec une petite probabilité de panne double, fonctionner pendant 4 heures sur un seul commutateur est en principe acceptable, alors vous pouvez simplement choisir le support approprié (où l'équipement sera remplacé en 4 heures).
Mais il y a un risque qu'il ne soit pas livré. Malheureusement, nous avons déjà été dans une telle situation. Au lieu de quatre heures, l'équipement a mis une semaine !!!
Par conséquent, ce risque doit également être discuté et, peut-être, il serait plus sage pour vous d'acheter un troisième commutateur et de le garder en réserve (redondance froide) ou de l'utiliser à des fins expérimentales.
Important ! Établissez un tableau de tous les supports que vous avez, avec les dates d'expiration, et ajoutez-les à votre calendrier, afin que vous receviez au moins un mois avant un email vous indiquant que vous devez commencer à vous inquiéter de prolonger le support.
On ne vous pardonnera pas si vous oubliez de prolonger le support et le lendemain de son expiration, votre équipement tombe en panne.
Travaux d'urgence
Quoi qu'il arrive dans votre réseau, idéalement, vous devez conserver l'accès à votre matériel réseau.
Il est important ! Vous devez avoir un accès console à tout l'équipement et cet accès ne doit pas dépendre du bon fonctionnement du réseau de transmission des données utilisateur.
Vous devez également anticiper les scénarios négatifs potentiels et documenter les actions nécessaires. L'accessibilité de ce document est tout aussi critique, il doit donc être non seulement mis à disposition sur une ressource partagée du service, mais également sauvegardé localement sur les ordinateurs des ingénieurs.
Cela doit obligatoirement inclure
- les informations nécessaires pour ouvrir un ticket de support auprès du fournisseur ou de l'intégrateur
- les informations sur la façon d'accéder à n'importe quel équipement (console, management)
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. En général, cela inclut
- les fournisseurs d'accès Internet et les points d'échange de trafic (IX)
- les fournisseurs de canaux de communication
Quelles questions devez-vous vous poser ? Comme dans le cas de l'équipement, il faut envisager différents scénarios d'urgence. Par exemple, pour les fournisseurs d'accès Internet, cela pourrait être quelque chose comme :
- que se passera-t-il si le fournisseur d'accès Internet X cesse pour une raison quelconque de vous fournir un service ?
- avez-vous suffisamment de bande passante avec les autres fournisseurs ?
- quelle sera la qualité de la connectivité ?
- quelle est l'indépendance de vos fournisseurs d'accès Internet et une grave défaillance de l'un d'eux ne causera-t-elle pas de problèmes aux autres ?
- combien d'entrées optiques y a-t-il dans votre centre de données ?
- que se passera-t-il si l'une des entrées est complètement détruite ?
En ce qui concerne les entrées, dans ma pratique dans deux entreprises différentes, deux fois centres de données fiables une excavatrice a détruit des puits et, par miracle, notre fibre optique n'était pas affectée. Ce n'est pas si rare.
Eh bien, bien sûr, vous devez non seulement poser ces questions, mais, encore une fois, avec le soutien de la direction, garantir une solution acceptable dans toutes les situations.
Sauvegarde
Le suivant par ordre de priorité pourrait être la sauvegarde des configurations de l'équipement. Dans tous les cas, c'est un point très important. Je ne vais pas énumérer les cas où vous pouvez perdre une configuration, il vaut mieux faire régulièrement des sauvegardes et ne pas y penser. De plus, des sauvegardes régulières peuvent être très utiles pour le contrôle des changements.
Important ! Effectuer une sauvegarde quotidienne. Ce n'est pas un volume de données si important pour économiser là-dessus. Le matin, l'ingénieur de garde (ou vous) doit recevoir un rapport du système indiquant clairement si la sauvegarde a été réussie ou non, et en cas d'échec, le problème doit être résolu ou un ticket doit être créé (voir les processus du service réseau).
Versions des logiciels
La question de savoir s'il faut ou non procéder à la mise à niveau des logiciels n'est pas si simple. D'une part, les anciennes versions présentent des bugs et des vulnérabilités connus, mais d'autre part, un nouveau logiciel n'est pas toujours une procédure d'upgrade indolore, et de nouvelles vulnérabilités et bugs peuvent également apparaître.
Il faut trouver l'option optimale. Voici quelques recommandations évidentes
- installer uniquement des versions stables
- il est tout de même préférable de ne pas rester sur des versions de logiciels très anciennes
- dressez un tableau avec les informations sur les logiciels utilisés
- lisez régulièrement les rapports sur les vulnérabilités et les bugs des versions des logiciels, et en cas de problèmes critiques, envisagez de procéder à une mise à niveau
À ce stade, avec l'accès console au matériel, les informations sur le support et la description de la procédure de mise à niveau, vous êtes en principe prêt pour cette étape. L'idéal serait d'avoir un matériel de laboratoire où vous pouvez tester toute la procédure, mais malheureusement, cela arrive rarement.
En cas de matériel critique, vous pouvez contacter le support du fournisseur en demandant de l'aide pour effectuer la mise à niveau.
Système de tickets
Vous pouvez maintenant regarder autour de vous. Vous devez établir des processus d'interaction avec d'autres départements et au sein du service.
Cela peut ne pas être obligatoire (par exemple, si votre entreprise est petite), mais je recommanderais 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 en essence votre interface pour les communications internes et externes, et vous devez décrire cette interface avec un degré de détail suffisant.
Prenons pour exemple une tâche importante et courante d'ouverture d'accès. Je vais décrire un algorithme qui a bien fonctionné dans l'une des entreprises.
Exemple
Commençons par le fait que les clients formulent souvent leur demande d'accès dans un langage incompréhensible pour un ingénieur réseau, à savoir, dans le langage de l'application, par exemple, "ouvrez-moi l'accès à 1C".
C'est pourquoi nous n'avons jamais accepté de demandes directement de ces utilisateurs.
Et c'était la première exigence.
- Les demandes d'accès doivent provenir des départements techniques (dans notre cas, il s'agissait des ingénieurs unix, windows, helpdesk).
La seconde exigence est que.
- cet accès doit être protocolé (par le département technique d'où nous avons reçu cette demande) et en tant que demande, nous obtenons un lien vers cet accès protocolé.
La forme de cette demande doit être claire pour nous, c'est-à-dire.
- la demande doit contenir des informations sur le réseau source et le réseau cible où l'accès doit être ouvert, ainsi que sur le protocole et (dans le cas de tcp/udp) les ports.
Il doit également être indiqué.
- une description du motif de cet accès.
- temporaire ou permanent (si temporaire, jusqu'à quelle date).
Et un point très important est les approbations.
- du responsable du département ayant initié l'accès (par exemple, la comptabilité).
- du responsable du département technique d'où cette demande est venue au département réseau (par exemple, helpdesk).
Dans ce contexte, le "propriétaire" de cet accès est considéré comme le responsable du département ayant initié l'accès (la comptabilité dans notre exemple), et il est responsable de veiller à ce que la page contenant les accès protocolés pour ce département reste à jour.
Journalisation
C'est là où l'on peut se noyer. Mais si vous voulez adopter une approche proactive, vous devez apprendre à gérer ce flux de données.
Voici quelques recommandations pratiques :
- les journaux doivent être consultés quotidiennement.
- En cas de consultation planifiée (et non en situation d'urgence), vous pouvez vous limiter aux niveaux de criticité (severity) 0, 1, 2 et ajouter des modèles sélectionnés d'autres niveaux si vous le jugez nécessaire.
- écrivez un script pour analyser les journaux et ignorer les logs dont les modèles ont été ajoutés à la liste d'ignorance.
Cette approche permettra, au fil du temps, de constituer une liste d'ignorance des journaux qui ne vous intéressent pas et de ne conserver que ceux que vous considérez vraiment comme importants.
Cela a très bien fonctionné chez nous.
Surveillance
Il n'est pas rare qu'une entreprise n'ait pas de système de surveillance. Par exemple, vous pouvez compter sur les journaux, mais l'équipement peut tout simplement « mourir » sans rien « dire », ou un paquet UDP du protocole syslog peut se perdre et ne pas parvenir. En général, bien sûr, une surveillance active est importante et nécessaire.
Deux exemples les plus courants dans ma pratique :
- la surveillance de la charge des canaux de communication et des liens critiques (par exemple, la connexion aux fournisseurs). Ils permettent de voir de manière proactive un problème potentiel de dégradation de service dû à la perte de trafic et donc de l'éviter.
- des graphiques basés sur NetFlow. Ils permettent de détecter facilement des anomalies dans le trafic et sont très utiles pour détecter certains types simples mais significatifs d'attaques informatiques.
Important ! Configurez les alertes SMS pour les événements les plus critiques. Cela s'applique à la fois à la surveillance et à la journalisation. Si vous n'avez pas d'équipe de garde, alors les SMS doivent également être envoyés en dehors des heures de travail.
Pensez au processus de manière à ne pas réveiller tous les ingénieurs. Nous avions un ingénieur de garde pour cela.
Contrôle des changements
À mon avis, il n'est pas nécessaire de contrôler tous les changements. Mais dans tous les cas, vous devez avoir la possibilité de retrouver facilement qui a fait quels changements dans le réseau, et pourquoi, si nécessaire.
Quelques conseils :
- utilisez un système de tickets pour décrire en détail ce qui a été fait dans le cadre de ce ticket, par exemple en copiant la configuration appliquée dans le ticket.
- utilisez les fonctionnalités de commentaire sur le matériel réseau (par exemple, commit comment sur Juniper). Vous pouvez enregistrer le numéro du ticket.
- utilisez diff de vos sauvegardes de configuration.
Vous pouvez intégrer cela comme processus, en examinant quotidiennement tous les tickets pour des changements.
Processus
Vous devez formaliser et décrire les processus dans votre équipe. Si vous en êtes arrivé à ce point, alors au moins les processus suivants devraient déjà être en place dans votre équipe :
Processus quotidiens :
- gestion des tickets
- gestion des journaux
- contrôle des changements
- liste de contrôle quotidienne
Processus annuels :
- renouvellement des garanties, des licences
Processus asynchrones :
- réaction à diverses situations d'urgence
Conclusion de la première partie
Vous avez remarqué que tout cela ne concerne pas encore la configuration du réseau, le design, les protocoles réseau, le routage ou la sécurité… C'est quelque chose d'aux alentours. Mais ce sont, bien que peut-être ennuyeux, des éléments très importants du fonctionnement du département réseau.
Pour l'instant, comme vous pouvez le voir, vous n'avez rien amélioré dans votre réseau. S'il y avait des vulnérabilités en matière de sécurité, elles sont toujours présentes ; si le design était mauvais, il l'est toujours. Tant que vous n'avez pas appliqué vos compétences et vos connaissances en ingénierie réseau, ce sur quoi vous avez probablement passé beaucoup de temps, d'efforts, et parfois d'argent. Mais d'abord, il faut établir (ou renforcer) une base, puis s'occuper de la construction.
Sur la façon de rechercher et de résoudre des erreurs, et ensuite d'améliorer votre infrastructure – c'est le sujet des prochaines parties.
Bien sûr, il n'est pas nécessaire de tout faire de manière séquentielle. Le temps peut être critique. Faites-le en parallèle, si les ressources le permettent.
Et un ajout important. Communiquez, demandez, consultez votre équipe. Après tout, c'est elle qui va maintenir et réaliser tout cela.
Source : habr.com
