Comment nous changeons le routage sans demander la permission.
Quand la plupart des hébergeurs ont besoin d'un changement de routage, ils ouvrent un ticket chez leur upstream et attendent. Quand nous en avons besoin, nous le faisons. Voici la discipline qui le rend sûr.
Dans cet article 4 sections
- Un hébergeur qui loue son réseau demande des changements de routage. Un hébergeur qui le possède les fait.
- La vitesse sans discipline est un risque. Chaque changement sur de l'équipement de production suit le même runbook écrit, décrit ci-dessous.
- Un petit ensemble standardisé de plateformes, une seule grammaire d'exploitation : les ingénieurs au support sont ceux qui définissent la politique de routage.
Il y a un moment, dans chaque incident sérieux, où quelqu'un dit que le routage doit changer. Ce qui se passe ensuite dépend entièrement de qui possède le réseau. Un hébergeur installé sur une dorsale louée ouvre un ticket chez son upstream et attend dans la file de quelqu'un d'autre. Nous, nous nous connectons à notre propre bordure et nous faisons le changement. Avec soin, selon des règles que nous allons vous montrer, mais nous le faisons. Personne en amont n'a à l'approuver, à le planifier, ni à se faire rappeler qui nous sommes.
Le changement nous appartient
Le mot pour cela n'est pas vitesse, c'est autonomie. Parce que le réseau s'annonce comme notre propre AS, la politique de routage est à nous de la définir : comment le trafic entre, quel opérateur il préfère, ce qui est déplacé quand un chemin se dégrade. La nôtre est le même groupe d'ingénieurs qui répond à la ligne de support, et le routeur est à nous.
La vitesse n'est rien sans la sûreté
Pouvoir changer n'importe quoi en quelques minutes n'est sûr qu'avec de la discipline, et la nôtre est écrite. Voici les règles permanentes pour toucher à de l'équipement réseau de production, citées du vrai runbook, écrit à partir de l'exploitation réelle, pas d'un exercice au tableau :
Chaque changement sur de l'équipement de production suit un runbook écrit : hostname vérifié, running config sauvegardée, une commande à la fois, rien n'est sauvegardé dans la startup avant vérification, et un second ingénieur voit le plan d'abord.
Aucune de ces règles n'est exotique. Ce qui compte, c'est qu'elles sont appliquées sur de l'équipement qui nous appartient, par des gens à deux bureaux l'un de l'autre, au lieu d'être décrites dans le document de gestion des changements d'un tiers.
Pourquoi nous pouvons opérer aussi profond
La réponse sans éclat est la standardisation. La bordure, c'est du Cisco ASR 9000 à Athènes et du Juniper MX204 à Amsterdam, alimentant un fabric EVPN/VXLAN Cisco Nexus 9000 : un petit ensemble standardisé de plateformes que nos ingénieurs connaissent de bout en bout, une seule grammaire d'exploitation du haut en bas. C'est le jumeau réseau de la doctrine 3PAR : quand chaque machine parle un seul dialecte, l'ingénieur au téléphone à 3 h du matin peut aussi raisonner sur le routage, parce que c'est la même personne et le même système connu. Il n'y a pas d'escalade vers un propriétaire de dorsale qui n'a jamais entendu parler de vous, parce qu'il n'y a pas de propriétaire de dorsale au-dessus de nous vers qui escalader.
La leçon pour vous
À 3 h du matin, la question n'est pas de savoir si votre hébergeur est aimable. C'est de savoir si la personne qui décroche peut changer le réseau, ou si elle attend quelqu'un en amont avec une file, un comité de changement, et aucune idée de qui vous êtes. Cette seule capacité, détenue ou non, fait l'essentiel de la différence entre un incident qui dure des minutes et un incident qui dure une nuit.
Réponses directes
Vous n'avez vraiment besoin de la permission de personne ?+
Pour notre propre politique de routage, non. Nous annonçons nos propres routes depuis notre propre AS. Nos upstreams les transportent. La discipline interne est la structure d'autorisation : le plan est relu avant l'exécution, selon le runbook ci-dessus. Ce dont nous n'avons pas besoin, c'est d'un ticket chez un tiers pour changer la façon dont notre propre réseau se comporte.
Serais-je informé des changements qui me concernent ?+
Les changements à impact visible pour le client ont une fenêtre de maintenance et un préavis. La plupart des changements n'en ont aucun, ce qui est tout l'intérêt de la discipline.
Comment savoir si mon hébergeur possède son propre réseau ?+
C'est une information publique. Cherchez qui annonce la plage IP dans laquelle se trouve votre serveur : si l'AS appartient à une autre entreprise que celle qui vous facture, votre hébergeur revend le réseau de quelqu'un d'autre. La liste complète des cinq questions, outils de recherche compris, se trouve dans Vous ne possédez pas votre réseau. C'est ça, votre vrai lock-in.
Demandez à votre hébergeur à quelle vitesse il peut rerouter votre trafic. Puis demandez-nous.
Les gens qui exploitent l'AS200477 sont ceux qui décrochent le téléphone.
Ouvrir le Sizing DeskVous êtes arrivé à la fin.
Mettez la lecture en pratique
Que faites-vous tourner ?
Parlez-nous de la charge de travail, du trafic et des exigences de reprise. Commencez par le configurateur de serveur, ou passez en revue les détails avec un ingénieur.
Écrit par les ingénieurs qui construisent et exploitent l'infrastructure qu'il décrit.Parler à un ingénieur