• # Ce n'est pas une erreur humaine mais une erreur de process

    Posté par  . Évalué à 3 (+2/-1).

    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  . Évalué à 4 (+3/-0).

      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.

  • # « Erreur humaine »

    Posté par  (site Web personnel) . Évalué à 6 (+4/-0).

    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.
  • # 77 colonnes

    Posté par  (site Web personnel) . Évalué à -3 (+0/-4). Dernière modification le 13/10/21 à 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  . Évalué à 10 (+10/-0). Dernière modification le 13/10/21 à 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).

      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

         > 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.

      • [^] # Re: 77 colonnes

        Posté par  . Évalué à 4 (+2/-0).

        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)

        • [^] # Re: 77 colonnes

          Posté par  . Évalué à 1 (+1/-0).

          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  (site Web personnel) . Évalué à 10 (+12/-0).

    Stéphane Bortzmeyer explique en détails la panne d'OVH.

    Je vous cite le dernier paragraphe :

    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é.

    • [^] # Re: À l'attention de ceux qui savent tout mieux que les autres

      Posté par  (site Web personnel) . Évalué à 0 (+0/-2).

      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.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.