Contrairement à ce qu'affirme Octave, ce n'est pas une erreur humaine (qui n'est pas toujours évitable) mais une erreur de process (qui eux servent à mitiger les erreurs humaines).
Il y aurait du avoir une vérification en amont avant la mise en production et très probablement que le saut de ligne foireux aurait été détecté à ce moment.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
Suivre des processus établis, ça réduit les chances d'erreur, mais c'est comme les feuilles administrative, il manque souvent la case correspondant au cas que l'on rencontre. Heureusement, les humains sont là pour mitiger les erreurs des processus.
Les processus permettent d'éviter des oublis des humains
Les humains permettent d'éviter des oublis et cas non prévus dans les processus et d'améliorer les processus.
C'est comme les checklist dans les procédure de vol, et le pilotage automatique (avion ou voiture), c'est toujours mieux quand l'humain peut couper les automatismes quand ils se mettent à buguer avec des problèmes liés à des cas jamais rencontrés.
Comparer le coût de 4 yeux à la place de 2 dans les moments critique face au coût de l'impact de son manque. Le problème est que ce n'est pas facile de calculer le second car c'est de l'image, du long terme… Mais ça a un coût non négligeable. Surtout en période de mise en bourse (le prix de vente est au bas de la fourchette, est-ce dû ou pas à cet incident? Difficile à dire).
Les « erreurs humaines », ça n’existe pas, il n’y a jamais qu’une seule cause à un incident et ce genre de problèmes sont généralement « systémiques » (je conseille fortement le livre The Field Guide to Understanding 'Human Error' à ce sujet).
À l’époque quand tu rentrais chez OVH, on te faisait un topo sur la règle des Cinq pourquoi, on dirait qu’ils se sont arrêté au premier :
On a eu une panne. Pourquoi ?
Parce que quelqu’un a appliqué une mauvaise configuration en prod.
Posté par YBoy360 (site web personnel) .
Évalué à -3.
Dernière modification le 13 octobre 2021 à 21:36.
Voilà l'intérêt d'avoir des lignes de code courtes, c'est qu'en cas de copier/coller, on évite les sauts de ligne (puisque l'on peut rendre la fenêtre de l'éditeur étroite sans avoir de retour à la ligne automatique)…
Posté par Big Pete .
Évalué à 10.
Dernière modification le 13 octobre 2021 à 22:38.
En fait, d’après le tweet supprimé d'octave, il s'agirait d'une commande de type
> route-map NAME
Ou NAME est juste une string, en l’occurrence ipv4.
Ce type de route-map est l'équivalent d'une politique (policy) pour les protocoles de routages, en gros, une liste d'entrées qui définissent ce que l'on accepte ou pas, des règles de filtrage en gros.
C'est généralement utilisé en complément des protocoles de routage comme BGP (encore lui !) pour l'ingénierie de trafic, (en gros déterminer par ou doit transiter tel ou tel trafic, en fonction des préfixes etc …)
Bref, le truc important, c'est que c'est surement du cisco. (même si on a pas grand chose dans le tweet, ça suffit pour deviner surtout que c'est de notoriété qu'ils utilisent Cisco chez OVH (enfin, il me semble en tout cas).
Et sur cisco, ce que tu tape est pris en compte directement. Si jamais tu loupe la ligne
> route-map ipv
> 4
en fait, ta route-map va s'appeller ipv au lieu d'ipv4 et suivant comment elle est implémentée, par exemple, disons que c'est la liste de tout les réseaux que l'on accepte de redistribuer à ses voisins, ben du coup, on n'envoit plus de route, puisque on va référencer ailleurs généralement dans la partie de la configuration qui traite du raccordement aux autres routeurs une route-map ipv4 qui n'existe pas.
Cisco, c'est assez merdique pour ça. surtout si on s’amuse a copier/collé dans la console. Sur Junos par exemple (ceux d'en face : Juniper), on écrit d'abord sa conf, puis on peux la relire et visualiser le patch avec la conf courante, et faire ensuite un commit. on peux même faire un double commit confirmé et/ou un commit simulé, c'est a dire, un premier commit avec un rollback automatique au bout de quelque minutes si tu ne le confirme pas par un second. ça permet de retrouver la main sur un routeur dont on se serait bêtement coupé l’accès.
Junos a la réputation d'être beaucoup moins casse gueule a configurer que cisco et participe de la zenitude de l'admin réseau du fait de sa ligne de commande plus conviviale.
Je crois que le pire que j'ai vu sur cisco c'est la commande :
switchport trunk allowed vlan add 42
Cette commande permet d'ajouter un numéro de réseau virtuel a une interface contenant de multiples réseaux virtuels. Admettons que cette interface contiens la liste de tout les vlan de ton réseau ben si tu oublie le add, il comprend qu'il n'y a plus que le 42 et vire tout le reste, et ça instantanément.
Tout les mecs qui ont touché un jour du Cisco, ça leur a pété au nez cette connerie, et même des bons, surtout les bons d'ailleurs, car souvent ils souffrent d'un excès de confiance, et c'est ça c'est très dangereux ….
(note, je dis cisco, mais Quagga sous linux, fait pareil ….)
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
Tu expliques très bien pourquoi je n'aime pas trop cisco : une vraie plaie… (mais pour me consoler je me suis toujours dit que c'est parce-que je ne suis pas un vrai admin réseau)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Troisième point, les solutions. Les yakafokons ne proposent en général pas de solutions concrètes, ils se contentent la plupart du temps de proposer des process (règles bureaucratiques à suivre aveuglément, dans l'espoir d'éliminer l'humain et donc les erreurs humaines). Du genre « aucun changement dans la configuration des routeurs sans la signature de N managers ». Dans la réalité, ce sont souvent au contraire ces règles qui créent les problèmes, par leur rigidité. Il faut se rappeler que le changement de configuration chez OVH qui a créé le problème était en réponse à un accroissement des attaques par déni de service. Faut-il patienter alors que les attaques sont en cours, au nom du process ?
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
Tu aurais pu citer le début du paragraphe juste en dessous :
Deuxième chose, le coût. J'utilise OVH, comme beaucoup, parce que ce n'est pas cher. Exiger une fiabilité de centrale nucléaire est irréaliste pour ce prix. S'assurer qu'un réseau fonctionne pendant 99,999 % du temps n'est pas un peu plus cher que de s'assurer qu'il fonctionne pendant 99,99 % du temps, c'est beaucoup plus cher.
C’est justement ça le problème d’OVH, c’est qu’ils prétendent être des concurrents aux grands noms du cloud, ils prétendent être les sauveurs du cloud européen, mais en réalité, ils font du low cost, à l’arrache, et continuent de configurer des routeurs Cisco à la main.
# Ce n'est pas une erreur humaine mais une erreur de process
Posté par Nibel . Évalué à 3.
Contrairement à ce qu'affirme Octave, ce n'est pas une erreur humaine (qui n'est pas toujours évitable) mais une erreur de process (qui eux servent à mitiger les erreurs humaines).
Il y aurait du avoir une vérification en amont avant la mise en production et très probablement que le saut de ligne foireux aurait été détecté à ce moment.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Ce n'est pas une erreur humaine mais une erreur de process
Posté par tao popus . Évalué à 4.
Suivre des processus établis, ça réduit les chances d'erreur, mais c'est comme les feuilles administrative, il manque souvent la case correspondant au cas que l'on rencontre. Heureusement, les humains sont là pour mitiger les erreurs des processus.
C'est comme les checklist dans les procédure de vol, et le pilotage automatique (avion ou voiture), c'est toujours mieux quand l'humain peut couper les automatismes quand ils se mettent à buguer avec des problèmes liés à des cas jamais rencontrés.
[^] # Re: Ce n'est pas une erreur humaine mais une erreur de process
Posté par Psychofox (Mastodon) . Évalué à 4.
la politique des 4 yeux marche souvent bien mais difficile de payer le double d'ingés.
[^] # Re: Ce n'est pas une erreur humaine mais une erreur de process
Posté par Zenitram (site web personnel) . Évalué à 1.
Comparer le coût de 4 yeux à la place de 2 dans les moments critique face au coût de l'impact de son manque. Le problème est que ce n'est pas facile de calculer le second car c'est de l'image, du long terme… Mais ça a un coût non négligeable. Surtout en période de mise en bourse (le prix de vente est au bas de la fourchette, est-ce dû ou pas à cet incident? Difficile à dire).
# « Erreur humaine »
Posté par Anonyme . Évalué à 6.
Les « erreurs humaines », ça n’existe pas, il n’y a jamais qu’une seule cause à un incident et ce genre de problèmes sont généralement « systémiques » (je conseille fortement le livre The Field Guide to Understanding 'Human Error' à ce sujet).
À l’époque quand tu rentrais chez OVH, on te faisait un topo sur la règle des Cinq pourquoi, on dirait qu’ils se sont arrêté au premier :
# 77 colonnes
Posté par YBoy360 (site web personnel) . Évalué à -3. Dernière modification le 13 octobre 2021 à 21:36.
Voilà l'intérêt d'avoir des lignes de code courtes, c'est qu'en cas de copier/coller, on évite les sauts de ligne (puisque l'on peut rendre la fenêtre de l'éditeur étroite sans avoir de retour à la ligne automatique)…
[^] # Re: 77 colonnes
Posté par Big Pete . Évalué à 10. Dernière modification le 13 octobre 2021 à 22:38.
En fait, d’après le tweet supprimé d'octave, il s'agirait d'une commande de type
Ou NAME est juste une string, en l’occurrence ipv4.
Ce type de route-map est l'équivalent d'une politique (policy) pour les protocoles de routages, en gros, une liste d'entrées qui définissent ce que l'on accepte ou pas, des règles de filtrage en gros.
C'est généralement utilisé en complément des protocoles de routage comme BGP (encore lui !) pour l'ingénierie de trafic, (en gros déterminer par ou doit transiter tel ou tel trafic, en fonction des préfixes etc …)
Bref, le truc important, c'est que c'est surement du cisco. (même si on a pas grand chose dans le tweet, ça suffit pour deviner surtout que c'est de notoriété qu'ils utilisent Cisco chez OVH (enfin, il me semble en tout cas).
https://www.cisco.com/c/fr_ca/support/docs/ip/ip-routed-protocols/47900-cat3550pbr.html
Et sur cisco, ce que tu tape est pris en compte directement. Si jamais tu loupe la ligne
en fait, ta route-map va s'appeller ipv au lieu d'ipv4 et suivant comment elle est implémentée, par exemple, disons que c'est la liste de tout les réseaux que l'on accepte de redistribuer à ses voisins, ben du coup, on n'envoit plus de route, puisque on va référencer ailleurs généralement dans la partie de la configuration qui traite du raccordement aux autres routeurs une route-map ipv4 qui n'existe pas.
Cisco, c'est assez merdique pour ça. surtout si on s’amuse a copier/collé dans la console. Sur Junos par exemple (ceux d'en face : Juniper), on écrit d'abord sa conf, puis on peux la relire et visualiser le patch avec la conf courante, et faire ensuite un commit. on peux même faire un double commit confirmé et/ou un commit simulé, c'est a dire, un premier commit avec un rollback automatique au bout de quelque minutes si tu ne le confirme pas par un second. ça permet de retrouver la main sur un routeur dont on se serait bêtement coupé l’accès.
Junos a la réputation d'être beaucoup moins casse gueule a configurer que cisco et participe de la zenitude de l'admin réseau du fait de sa ligne de commande plus conviviale.
Je crois que le pire que j'ai vu sur cisco c'est la commande :
Cette commande permet d'ajouter un numéro de réseau virtuel a une interface contenant de multiples réseaux virtuels. Admettons que cette interface contiens la liste de tout les vlan de ton réseau ben si tu oublie le add, il comprend qu'il n'y a plus que le 42 et vire tout le reste, et ça instantanément.
Tout les mecs qui ont touché un jour du Cisco, ça leur a pété au nez cette connerie, et même des bons, surtout les bons d'ailleurs, car souvent ils souffrent d'un excès de confiance, et c'est ça c'est très dangereux ….
(note, je dis cisco, mais Quagga sous linux, fait pareil ….)
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: 77 colonnes
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Tu expliques très bien pourquoi je n'aime pas trop cisco : une vraie plaie… (mais pour me consoler je me suis toujours dit que c'est parce-que je ne suis pas un vrai admin réseau)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: 77 colonnes
Posté par ChocolatineFlying . Évalué à 1.
c'est ca, le copier coller qui foire une fois sur 2 sur des CISCO 850, bon il restait le choix de charger le fichier de conf proprement.
# À l'attention de ceux qui savent tout mieux que les autres
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 10.
Stéphane Bortzmeyer explique en détails la panne d'OVH.
Je vous cite le dernier paragraphe :
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: À l'attention de ceux qui savent tout mieux que les autres
Posté par Anonyme . Évalué à 1.
Tu aurais pu citer le début du paragraphe juste en dessous :
C’est justement ça le problème d’OVH, c’est qu’ils prétendent être des concurrents aux grands noms du cloud, ils prétendent être les sauveurs du cloud européen, mais en réalité, ils font du low cost, à l’arrache, et continuent de configurer des routeurs Cisco à la main.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.