Auteur Sujet: Incident 8 septembre  (Lu 12247 fois)

0 Membres et 1 Invité sur ce sujet

Nico

  • Modérateur
  • *
  • Messages: 44 445
  • FTTH 1000/500 sur Paris 15ème (75)
    • @_GaLaK_
Incident 8 septembre
« Réponse #24 le: 14 septembre 2014 à 08:11:47 »
Ici, on parle de l'incident TATA. Or, Bouygues est un gros client de TATA, en direct, sans aucun intermédiaire.
J'ai généralisé ma réponse, pour le cas de ce sujet voir la suite de ma réponse.
 
Citer
Là, je n'ai pas compris.
Ce que je dis justement c'est que si le NOC a bien sur accès à ces informations, ce n'est pas forcement partagé avec toutes les personnes qui sont susceptibles de voir un incident dans le cadre de leur boulot !
Je ne sais pas ce que fait précisèment Boris, mais ce n'est pas évident qu'il ait accès à tous les tickets ouverts par le NOC.

Boris de Bouygues Telecom

  • AS5410 Expert Bouygues Telecom
  • Abonné Bbox fibre
  • *
  • Messages: 2 763
  • Technopôle de Bouygues Telecom sur Meudon (92)
Incident 8 septembre
« Réponse #25 le: 14 septembre 2014 à 09:04:04 »
Le NOC gère les coupures et des dégradations forte sur notre réseau.

En cas de coupure, il s ont des règles à suivre pour déclencher le niveau 2 qui va ouvrir un ticket, escalader l'incident si nécessaire, voir même rappeler le fournisseur tous les 1/4 d'heure pour avoir l'avancement en cas de problème vraiment critique.

Là, aucune coupure, donc le NOC n'a pas d'alarme. De mon coté, difficile de voir que ce type de problème est lié à Tata vu que Cogent était fortement impacté par l'Incident.

A noter que j'ai ouvert un incident pour voir si il y a un problème sur notre réseau qui explique que le problème de Tata ait eu des répercussion sur Limelight. Plusieurs personnes se sont penché sur le sujet et le trafic dans les deux sens passe bien intégralement sur le PNI et donc le problème est visiblement coté Limelight, qui doit utiliser Tata pour alimenter ses caches.

Synack

  • AS16080 Rentabiliweb Telecom
  • Expert
  • *
  • Messages: 689
Incident 8 septembre
« Réponse #26 le: 14 septembre 2014 à 12:35:42 »
1) Pour le "qu'est-ce qu'il se passe ?" :

Bah comme dit au dessus, on est tous capables de voir les problèmes et d'identifier depuis quel fournisseur ça se produit, reste que tu peux plus difficilement identifier si c'est général à tous ou plutôt isolé, tu ne sais pas toujours bien la cause exacte non plus du comportement et les mailings permettent d'avoir parfois des infos plus précises et intéressantes sur les choses.

Tout monitorer en détail c'est bien, il faut même, mais ça demande du boulot et surtout ça génère facilement des faux positifs. En particulier parce qu'une IP que tu monitores peut ne plus exister chez l'opérateur en face, qu'un looking glass peut être en maintenance, etc.

2) Le côté pro-actif :

Oui tu es dans le monde des bisounours, Level 3 le fait (bien), mais beaucoup d'autres ne communiquent pas leurs propblèmes, parce que tout a un prix et qu'avoir un service de qualité se paye. A l'heure où tout le monde tire le prix vers le bas, c'est un effet de bord, la partie communication lors d'un incident n'est pas gérée correctement.

Le meilleur exemple de ça c'est Completel. Ca coûte bien moins cher pour avoir des liens P2P que tout autre fournisseur, mais le service est absolument indigne de ce que tu attends d'un opérateur et d'un pro.

Tu sais ce que tu payes...

Et là on parlait de ralentissements, mais pas de coupure, le service Tata fonctionnait au final.

Leon

  • Client SFR sur réseau Numericable
  • Modérateur
  • *
  • Messages: 5 971
Incident 8 septembre
« Réponse #27 le: 14 septembre 2014 à 13:13:17 »
Là, aucune coupure, donc le NOC n'a pas d'alarme. De mon coté, difficile de voir que ce type de problème est lié à Tata vu que Cogent était fortement impacté par l'Incident.
Tu veux dire qu'un packet loss important sur certaines destinations ne génère pas d'alarme? De même une chute anormal du trafic (au global ou sur certains liens) ne génère pas d'alarme?
Encore une fois, je suis très surpris! Par exemple, Online dit avoir très rapidement coupé la session BGP avec TATA pour re-router le trafic ailleurs. C'est bien qu'ils ont eu une alarme, qu'ils ont repéré le problème, et qu'ils ont géré manuellement les choses. Tu veux dire que Bouygtel (avec pourtant un réseau beaucoup plus gros) n'a appliqué aucune mesure pendant l'incident? Pourtant, TATA communiquait visiblement pendant l'incident. Online aurait-il une équipe réseau (de 2 ou 3 personnes seulement) plus performante que Bouygtel?

Oui tu es dans le monde des bisounours, Level 3 le fait (bien), mais beaucoup d'autres ne communiquent pas leurs propblèmes, parce que tout a un prix et qu'avoir un service de qualité se paye. A l'heure où tout le monde tire le prix vers le bas, c'est un effet de bord, la partie communication lors d'un incident n'est pas gérée correctement.
Mais là on parle d'un client (Bouygtel) qui verse des centaines de milliers d'euro par an à chacun de ses fournisseur de transit! Comment imaginer une seule seconde qu'il n'y ait pas un support de haute qualité pour un tel client? Encore une fois, TATA a communiqué avec Online.

Et là on parlait de ralentissements, mais pas de coupure, le service Tata fonctionnait au final.
Fonctionnait... avec un packet loss important, donc ne fonctionnait pas de manière acceptable. Les gros opérateurs garantissent un ping et un packet loss au moins sur leur réseau. Donc la prestation n'était pas assurée.

Ce que je dis justement c'est que si le NOC a bien sur accès à ces informations, ce n'est pas forcement partagé avec toutes les personnes qui sont susceptibles de voir un incident dans le cadre de leur boulot !
Je ne sais pas ce que fait précisèment Boris, mais ce n'est pas évident qu'il ait accès à tous les tickets ouverts par le NOC.
Je connais un peu le système de gestion d'incidents d'un gros réseau, pour y avoir eu accès (lecture seule, vue N2). Et tous ces cas sont gérés : une liste d'incidents gérés en transversal et susceptibles d'impacter beaucoup de gens, avec des niveaux de priorité (par degré d'impact). Tous les supports N1/N2/N3 y ont accès, avec des vues différentes. Ces incidents transversaux sont gérés entre intervenants N2/N3, et une partie "communicable au client" (interne ou externe) est éditée en temps réel (=ne pas tout dire). Et un incident client peut être rattaché instantanèment à l'incident transversal, pour hériter de la mise à jour du statut, ce qui permet d'informer de très nombreux clients (internes ou externes) en temps réel. Bref, tous ces cas sont gérables, même en cas de très gros réseau.

Leon.

Synack

  • AS16080 Rentabiliweb Telecom
  • Expert
  • *
  • Messages: 689
Incident 8 septembre
« Réponse #28 le: 14 septembre 2014 à 13:38:57 »
Pour Online, je pense que ce sont eux qui ont contacté Tata et pas l'inverse. Je ne pense pas que Tata ait été pro-actif avec Online. Faudra poser la question à Arnaud ou Mickaël.

Faut voir que Tata est un truc énorme, que Bouygues Telecom est un très gros client français pour nous mais une goutte d'eau dans l'univers Tata. Comme on peut constater que beaucoup d'opérateurs US s'occupent moins bien de clients européens qu'américains parfois (NOC non européen qui ne voit pas la même criticité de sa lorgnette)

Après c'est en premier lieu une question de transparence et d'outils. La transparence c'est prendre le risque de montrer à tous ces clients qu'on a un problème et générer beaucoup de travail de communication avec beaucoup de clients alors qu'une majorité ne remarquera pas ce qui se passe et ne remontera aucun incident. Les outils, c'est avoir un moyen simple et efficace de communiquer avec l'ensemble de ses clients sans passer du temps là dessus au lieu d'en passer sur le problème. Pour un gros acteur, normalement ce ne sont cependant pas les mêmes personnes, mais pour un tier-2, ça arrive et dans tous les cas il y a toujours ce sujet de celui qui gère le problème qui doit prendre du temps pour communiquer la situation à quelqu'un régulièrement.

Pour le coup beaucoup d'opérateurs sont mal équipés pour ça, c'est aussi là où des hosteurs me semblent en avance (OVH, Online) car ils ont l'habitude de la communication de masse et ont plus de vraies équipes de dev proches de leur métier.

La communication chez les opérateurs ça a très souvent été un problème de mon expérience, c'est vrai que ça ne fait pas très sérieux mais bon il faut aussi relativiser, on a tous de la redondance entre plusieurs fournisseurs et si ça coupe, c'est pas comme si on coupait l'électricité dans un hôpital, faut relativiser.

mikmak

  • AS12876 Expert Scaleway
  • Expert
  • *
  • Messages: 177
    • @mmarcha
Incident 8 septembre
« Réponse #29 le: 14 septembre 2014 à 13:45:18 »
oui c'est notre équipe qui a un ouvert un incident chez eux (on le fait quasiment systèmatiquement pour un incident important, surtout là on avait tout coupé, il nous fallait une confirmation de leur part que c'était bien "maitrisé" avant de re-up)

n'importe quel client d'un fournisseur est en droit d'exiger un rapport d'incident, il suffit de leur demander hein ;)

Mik

Synack

  • AS16080 Rentabiliweb Telecom
  • Expert
  • *
  • Messages: 689
Incident 8 septembre
« Réponse #30 le: 14 septembre 2014 à 15:09:15 »
oui c'est notre équipe qui a un ouvert un incident chez eux (on le fait quasiment systèmatiquement pour un incident important, surtout là on avait tout coupé, il nous fallait une confirmation de leur part que c'était bien "maitrisé" avant de re-up)

n'importe quel client d'un fournisseur est en droit d'exiger un rapport d'incident, il suffit de leur demander hein ;)

Mik

Yep, le rapport d'incident heureusement, la question se pose surtout sur la pro-activité et la communication pendant l'incident.

Ceci dit pour Completel même les rapports d'incident post événement sont très difficiles à avoir... (sic)

mikmak

  • AS12876 Expert Scaleway
  • Expert
  • *
  • Messages: 177
    • @mmarcha
Incident 8 septembre
« Réponse #31 le: 14 septembre 2014 à 15:20:38 »
faut pas rever, aucun fournisseur de transit ne communique quand ca va mal,
on est jamais venu me dire "hey, ca deconne vers telle destination on est en train de regarder"

ca serait un peu comme venir te voir le chéquier à la main pour les SLAs ;)

Mik

Synack

  • AS16080 Rentabiliweb Telecom
  • Expert
  • *
  • Messages: 689
Incident 8 septembre
« Réponse #32 le: 14 septembre 2014 à 15:49:40 »
faut pas rever, aucun fournisseur de transit ne communique quand ca va mal,
on est jamais venu me dire "hey, ca deconne vers telle destination on est en train de regarder"

ca serait un peu comme venir te voir le chéquier à la main pour les SLAs ;)

Mik

Exactement :D

Level 3 a tendance à mieux communiquer ceci dit que les autres dans ces cas là, mais c'est plutôt une exception effectivement.

Leon

  • Client SFR sur réseau Numericable
  • Modérateur
  • *
  • Messages: 5 971
Incident 8 septembre
« Réponse #33 le: 14 septembre 2014 à 16:14:21 »
faut pas rever, aucun fournisseur de transit ne communique quand ca va mal,
on est jamais venu me dire "hey, ca deconne vers telle destination on est en train de regarder"
Je n'ai jamais dit que c'était au fournisseur de transit de communiquer. Ca peut marcher dans les 2 sens : si le fournisseur a envie de communiquer (en public ou en privé à l'ensemble de ses clients), il le fait; sinon, c'est au client d'ouvrir un incident.  Tant que les incidents sont bien traités , je n'ai pas de problème avec ce mode de fonctionnement.

Mais je ne comprends pas ici pourquoi Bouygtel n'a pas déclaré un incident auprès de TATA, ni pourquoi des clients de TATA (ou autre fournisseur de transit) posent demandent "qu'est-ce qu'il se passe" sur la liste FRNOG. Pour moi, ça n'a pas de sens! 
Pour Bouygtel, il se peut que l'incident ait été déclaré auprès de TATA, mais dans ce cas, c'est le suivi interne qui ne fonctionne pas.

Leon.

Synack

  • AS16080 Rentabiliweb Telecom
  • Expert
  • *
  • Messages: 689
Incident 8 septembre
« Réponse #34 le: 14 septembre 2014 à 16:41:12 »
Je n'ai jamais dit que c'était au fournisseur de transit de communiquer. Ca peut marcher dans les 2 sens : si le fournisseur a envie de communiquer (en public ou en privé à l'ensemble de ses clients), il le fait; sinon, c'est au client d'ouvrir un incident.  Tant que les incidents sont bien traités , je n'ai pas de problème avec ce mode de fonctionnement.

Mais je ne comprends pas ici pourquoi Bouygtel n'a pas déclaré un incident auprès de TATA, ni pourquoi des clients de TATA (ou autre fournisseur de transit) posent demandent "qu'est-ce qu'il se passe" sur la liste FRNOG. Pour moi, ça n'a pas de sens! 
Pour Bouygtel, il se peut que l'incident ait été déclaré auprès de TATA, mais dans ce cas, c'est le suivi interne qui ne fonctionne pas.

Leon.

Pour moi il y a plusieurs éléments :

- Boris n'a peut-être pas toutes les informations sur le traitement en cours de l'équipe backbone ou l'équipe backbone n'a pas encore l'information, donc par curiosité il multiplie les canaux de communication pour avoir l'information plus rapidement. C'est le cas aussi pour FRnOG, en général l'idée c'est de voir l'ampleur du problème et de checker qu'une personne mieux placée n'a pas l'information plus rapidement ou n'a pas plus de détails sur l'incident qu'un "on a un problème backbone" du fournisseur

- C'est facile après coup et en ayant le recul de se poser la question par rapport à Tata, mais au moment où Boris indique le problème, la cause a plusieurs conséquences et il n'est pas évident que Tata soit la cause du problème de ce qu'il voit. De mon côté j'ai checké différentes choses y compris au niveau routage pour vérifier la cause et c'était intéressant de discuter ici ou sur FRnOG pour avoir plusieurs angles de vue du problème afin de mieux le cerner. Notamment l'impact sur Limelight n'est pas trivial à comprendre comme ça.


C'est toujours intéressant d'échanger sur les forums ou mailing pour mieux comprendre l'environnement dans lequel on évolue, parce que personnellement j'aime pas me contenter de la communication de mon fournisseur quand je peux avoir plus de détails qui m'aideront à mieux gérer ma redondance à l'avenir.

C'est intéressant de comprendre les causes et les conséquences d'un événement pour mieux debuger les futures situations et mieux préparer ton infra pour ces situations.

Bref, partager des informations et avoir des points de vues divers c'est toujours intéressant, parfois bien plus que la communication de ton fournisseur qui est biaisée par le rapport client/fournisseur.

Pour finir, ça permet d'informer les gens qui n'avaient pas remarqué le problème, ça peut leur être utile.

ut0mt8

  • AS49477 e-TF1
  • Expert
  • *
  • Messages: 145
  • Boulognes(92)
    • (ex AS49477) Senior Engineering Manager
Incident 8 septembre
« Réponse #35 le: 08 octobre 2014 à 22:58:37 »
Avec un peu de retard sur ce thread.

Ayant été complétement impacté par le problème Tata je peux te dire comment ça a été géré par chez nous.
Notre astreinte nous appelle car dixit "c'est tout rouge, ça a l air réseau". En // je commence à recevoir des sms.

Je regarde vite fait le monitoring, le graphing, et je me connecte rapidement sur mes routers et je constate rapidement que :
1) les destinations US depuis mon réseau sont HS (normal elles étaient pref via Tata)
2) Tata est quasi HS en Europe

Actions : coupure Tata coté Paris, ouverture de ticket chez Tata, et go IRC pour voir ce que constate les autres.

Et oui parce que Tata ne répondait juste pas pendant l'incident, et donc je voulais savoir si le problème était seulement de mon coté ou pas.
Donc ça peut paraitre bizarre, mais oui le monitoring aide a voir ce qui ne va, mais ce qui aide à comprendre, c'est à la fois les sondes, les ingé qui bossent et la communauté.

PS : j'ai du bataillé pendant une semaine pour avoir un rapport d'incident, je suis un petit client, et même mon commercial Tata que j'aime bien avait pas beaucoup d'info le lendemain...

En revanche pour un gros tel bouygues, ca prouve juste que c'est jamais facile de former un NOC, d'avoir les bonnes procédures d'escalades, etc...

Et surtout tu ne peux pas compter sur le support des gros. Dans le meilleurs des cas ils confirment juste ce que tu as détecté 2h avant, dans le pire des cas ils te bullshitent complétement.