Retour d'expérience: panne du DC Level3
Bonjour, Je n'ai pas encore reçu de RFO sur cette panne électrique donc je ne donnerai pas de détails sur ce qui s'est passé. C'est la 2ème panne majeure sur ce DC en 14 mois: en octobre 2013 c'est la clim qui avait arrêtée de fonctionner... Petite récap des conséquences physiques : - 2 PDU APC ont cramé - l'ensemble de mes équipements a redémarré au moins une fois - une bonne dizaine de serveurs ont redémarrés électriquement et aucun d'entre eux n'a causé de problèmes - un voisin, je ne sais pas qui, a perdu 12 serveurs qui ne redémarreront jamais ... Au final, j'aurais perdu peu de matériel, et heureusement parce que je n'avais pas assez de spares. Ce n'est pas ma première panne datacenter, mais c'est aussi dans ce cas qu'on peut juger de la qualité des constructeurs : - Serveurs Dell, rien à dire à partir des R320. Les vieux 1950 et 2950 tiennent toujours la route comme au début. La gamme des R200 est insuffisante en terme de qualité physique. - Brocade : il faut du haut de gamme. Le milieu de gamme ne tient pas les montées de température. Par exemple, mes vieux FESX de 8 ans sont monté à 105° et fonctionnent toujours contrairement aux FCX de 3 ans qui ont tous arrêter de fonctionner. Mais un FESX coute le double d'un FCX ... - APC : c'est sensé être du haut de gamme et pourtant ... ils sont trop sensible à la température et arrêtent de fonctionner les un après les autres, à la moindre hausse de T° ... (Je n'ai que du switched) - KVM Dell (en réalité du Advocent) : RAS. Maintenant au niveau business : - on a perdu 3h d'activité, perte sèche de CA - l'activité est revenue complètement à la normale en ~8h Ce qui ramène aux conclusions stratégiques et managériales : - on est en plein dans le "nobody known what I do until I don't do it", du coup quand tout fonctionne l'équipe ops se retrouve à faire de plus en plus autre chose que son métier, comme du développement - les Ops sont tout de même responsables car ... c'est dans leur responsabilité - les économies faites sur le matériel coûtent finalement bien plus cher ... Tout ça ce sont des évidences auxquelles nous avons été et nous sommes confrontés régulièrement. Cette panne m'aura fait prendre quelques cheveux blancs supplémentaires, et m'aura donné l'occasion de croiser le regard déçu de mon patron ... mais aussi de redéfinir les priorités. Même quand tout fonctionne, les sysadmin doivent faire évoluer une archi, et pas que pour des raisons de sécu ou de perfs. Donc la question du trolldi est: est-ce qu'il est nécessaire d'avoir de temps en temps une grosse panne à gérer ? C'est paradoxale ... Greg
tu ne fais qu'aborder un truc commun en sécurité informatique, et quand je parle de sécurité informatique, je l'entend au niveau de la théorie de la sécurité. On se dit toujours que celà ne nous arriveras jamais => conclusion ça nous arrive et on est pas prêt. Si la disponibilité est très importante il faut investir en conséquence, il faut le faire comprendre aux décideur, et c'est là tout le soucis Cordialement Alexis Lameire Le 28 novembre 2014 10:10, Greg <greg-frsag@duchatelet.net> a écrit :
Bonjour,
Je n'ai pas encore reçu de RFO sur cette panne électrique donc je ne donnerai pas de détails sur ce qui s'est passé. C'est la 2ème panne majeure sur ce DC en 14 mois: en octobre 2013 c'est la clim qui avait arrêtée de fonctionner...
Petite récap des conséquences physiques : - 2 PDU APC ont cramé - l'ensemble de mes équipements a redémarré au moins une fois - une bonne dizaine de serveurs ont redémarrés électriquement et aucun d'entre eux n'a causé de problèmes - un voisin, je ne sais pas qui, a perdu 12 serveurs qui ne redémarreront jamais ...
Au final, j'aurais perdu peu de matériel, et heureusement parce que je n'avais pas assez de spares. Ce n'est pas ma première panne datacenter, mais c'est aussi dans ce cas qu'on peut juger de la qualité des constructeurs : - Serveurs Dell, rien à dire à partir des R320. Les vieux 1950 et 2950 tiennent toujours la route comme au début. La gamme des R200 est insuffisante en terme de qualité physique. - Brocade : il faut du haut de gamme. Le milieu de gamme ne tient pas les montées de température. Par exemple, mes vieux FESX de 8 ans sont monté à 105° et fonctionnent toujours contrairement aux FCX de 3 ans qui ont tous arrêter de fonctionner. Mais un FESX coute le double d'un FCX ... - APC : c'est sensé être du haut de gamme et pourtant ... ils sont trop sensible à la température et arrêtent de fonctionner les un après les autres, à la moindre hausse de T° ... (Je n'ai que du switched) - KVM Dell (en réalité du Advocent) : RAS.
Maintenant au niveau business : - on a perdu 3h d'activité, perte sèche de CA - l'activité est revenue complètement à la normale en ~8h
Ce qui ramène aux conclusions stratégiques et managériales : - on est en plein dans le "nobody known what I do until I don't do it", du coup quand tout fonctionne l'équipe ops se retrouve à faire de plus en plus autre chose que son métier, comme du développement - les Ops sont tout de même responsables car ... c'est dans leur responsabilité - les économies faites sur le matériel coûtent finalement bien plus cher ...
Tout ça ce sont des évidences auxquelles nous avons été et nous sommes confrontés régulièrement. Cette panne m'aura fait prendre quelques cheveux blancs supplémentaires, et m'aura donné l'occasion de croiser le regard déçu de mon patron ... mais aussi de redéfinir les priorités. Même quand tout fonctionne, les sysadmin doivent faire évoluer une archi, et pas que pour des raisons de sécu ou de perfs.
Donc la question du trolldi est: est-ce qu'il est nécessaire d'avoir de temps en temps une grosse panne à gérer ? C'est paradoxale ...
Greg
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Hello Greg,
Petite récap des conséquences physiques : - 2 PDU APC ont cramé - l'ensemble de mes équipements a redémarré au moins une fois - une bonne dizaine de serveurs ont redémarrés électriquement et aucun d'entre eux n'a causé de problèmes - un voisin, je ne sais pas qui, a perdu 12 serveurs qui ne redémarreront jamais ...
Sympa, tu as de la chance car ton voisin n'en as pas eu. Le fait que des APC ont cramé c'est soit qu'il y a eu un retour de courant important, soit qu'ils étaient trop vieux.
Au final, j'aurais perdu peu de matériel, et heureusement parce que je n'avais pas assez de spares. Ce n'est pas ma première panne datacenter, mais c'est aussi dans ce cas qu'on peut juger de la qualité des constructeurs : - Serveurs Dell, rien à dire à partir des R320. Les vieux 1950 et 2950 tiennent toujours la route comme au début. La gamme des R200 est insuffisante en terme de qualité physique. - Brocade : il faut du haut de gamme. Le milieu de gamme ne tient pas les montées de température. Par exemple, mes vieux FESX de 8 ans sont monté à 105° et fonctionnent toujours contrairement aux FCX de 3 ans qui ont tous arrêter de fonctionner. Mais un FESX coute le double d'un FCX ...
Ils ont fait des efforts, j'ai eu des ServerIron XL qui ont arrêté de fonctionner a 62°C (le switch fonctionnais "a peu près, mais le LB L7 -> mort). Ceci dit, si tu regardes les datasheets de Brocade ils sont clair au dessus de 55°C : c'est plus dans les specs, conclusion il faut des fois bien ranger ses baies.
- APC : c'est sensé être du haut de gamme et pourtant ... ils sont trop sensible à la température et arrêtent de fonctionner les un après les autres, à la moindre hausse de T° ... (Je n'ai que du switched)
Idem, > 55°C dans une baie, c'est que tu as un pb.
- KVM Dell (en réalité du Advocent) : RAS.
Maintenant au niveau business : - on a perdu 3h d'activité, perte sèche de CA - l'activité est revenue complètement à la normale en ~8h
Ce qui ramène aux conclusions stratégiques et managériales : - on est en plein dans le "nobody known what I do until I don't do it", du coup quand tout fonctionne l'équipe ops se retrouve à faire de plus en plus autre chose que son métier, comme du développement - les Ops sont tout de même responsables car ... c'est dans leur responsabilité - les économies faites sur le matériel coûtent finalement bien plus cher ...
Effectivement, et je dirais même plus : les économies faites quand on est dans un seul datacenter sont des fois, dans des cas où les clients sont sur l'internet, des fausses économies. Vaux mieux avoir un systèmes redondonant sur 2 DC quittes a avoir a tenir une charge moindre que faire de la perte de CA. D'ailleurs vu que tu as 3h de pertes sèche de CA, tu peux donc calculer combien d'argent a été perdue et donc calculer si avoir un second DC serait une bonne idée. A ajouter dans ce cas : être maitre de son routage. Ca aide beaucoup pour faire des choses fiables.
Donc la question du trolldi est: est-ce qu'il est nécessaire d'avoir de temps en temps une grosse panne à gérer ? C'est paradoxale ...
Mon expérience avec nos amis les DAF, il faut souvent qu'ils se trouvent au pied du mur pour qu'ils agissent, et en général n'écoutent jamais les responsables / sysadmin senior / guru qui leur disent : si on fait pas ça on vas se payer un mur. Dans la boite où je suis, à chaque fois qu'ils se payent un mur ils font ce que je leur avais dit plusieurs mois ou années avant, comme par ex : - changer / entretenir la clim du DC au bureau - bouger les serveurs sensible dans un vrai DC (avec onduleurs / groupe et double clim) - virer colt (désolé s'il y a des gens de colt içi) et prendre un opérateur qui facture pas 1K€ une connectivité a 10Mbps par mois - dégager les tunnel IPSEC + ADSL boxalacon et coller des SDSL - tuer les serveurs legacy asap (qui datent de 2003 et qui sont pas à jour) et migrer sur des solutions opensource/logicielles qui peuvent être maintenues - avoir du spare de switch... - le backup ... :) En deux ans, chaque point évoqués ont bougés quand ils se sont payés un mur, malgré les informations claires et précises du mur qui arrive "demain"... Je ne sais pas si c'est un standard des entreprises francaises, mais hélas c'est quelque chose que je vois (et pas que moi) de plus en plus souvent dans la gestion des risques informatiques. Souvent l'informatique est prise comme un outil et les DAF sont incapables de comprendre pourquoi on demande une enveloppe de 20K€ pour sécuriser un truc "qui marche déjà bien comme ça"... </trolldi> Xavier
Salut Xavier, Le 28 novembre 2014 10:58, Xavier Beaudouin <kiwi@oav.net> a écrit :
Sympa, tu as de la chance car ton voisin n'en as pas eu. Le fait que des APC ont cramé c'est soit qu'il y a eu un retour de courant important, soit qu'ils étaient trop vieux.
voir plus bas ;)
Idem, > 55°C dans une baie, c'est que tu as un pb.
c'est lors de la panne de clim d'octobre 2013 que la température a monté drastiquement. Suite à quoi j'ai perdu les FCX et PDU un par un sur 14 mois donc ...
Effectivement, et je dirais même plus : les économies faites quand on est dans un seul datacenter sont des fois, dans des cas où les clients sont sur l'internet, des fausses économies. Vaux mieux avoir un systèmes redondonant sur 2 DC quittes a avoir a tenir une charge moindre que faire de la perte de CA.
on est déjà sur 2 sites, mais on m'a coupé les vivres en route suite à un changement de DG, je n'ai donc pas pu finir le travail ...
D'ailleurs vu que tu as 3h de pertes sèche de CA, tu peux donc calculer combien d'argent a été perdue et donc calculer si avoir un second DC serait une bonne idée.
Clairement, 3H de perte sèche de CA ne représente pas ce que coûterait un 2eme DC (avec liens redondés etc) par contre si on ajoute les coûts des conséquences sur l'image, les partenaires etc ... ça n'a (presque) pas de prix !
A ajouter dans ce cas : être maitre de son routage. Ca aide beaucoup pour faire des choses fiables.
C'était prévu en 2014 puis abandonné pour les mêmes raisons. Mais c'est cool, je vais pouvoir relancer ce projet aussi :)
Mon expérience avec nos amis les DAF, il faut souvent qu'ils se trouvent au pied du mur pour qu'ils agissent, et en général n'écoutent jamais les responsables / sysadmin senior / guru qui leur disent : si on fait pas ça on vas se payer un mur.
Dans la boite où je suis, à chaque fois qu'ils se payent un mur ils font ce que je leur avais dit plusieurs mois ou années avant, comme par ex : - changer / entretenir la clim du DC au bureau - bouger les serveurs sensible dans un vrai DC (avec onduleurs / groupe et double clim) - virer colt (désolé s'il y a des gens de colt içi) et prendre un opérateur qui facture pas 1K€ une connectivité a 10Mbps par mois - dégager les tunnel IPSEC + ADSL boxalacon et coller des SDSL - tuer les serveurs legacy asap (qui datent de 2003 et qui sont pas à jour) et migrer sur des solutions opensource/logicielles qui peuvent être maintenues - avoir du spare de switch... - le backup ... :)
En deux ans, chaque point évoqués ont bougés quand ils se sont payés un mur, malgré les informations claires et précises du mur qui arrive "demain"...
Même expérience, à chaque fois qu'on s'est payé le mur les choses ont évoluées. Aujourd'hui mon patron est tellement sensibilisé aux backups que c'est quasiment la 1ère chose qu'il me demande en cas de nouveau projet, et qu'on a des backups sur 4 sites :) Suite à une panne de load-balancers sur des R200, j'ai pu m'équiper de ServerIron 4G (8x plus cher) qui encaisse toutes les pannes. Suite à une autre panne pour des filers sous-dimensionnés, j'ai pu m'équiper de SAN EqualLogic (6x plus cher). On n'a plus aucun problèmes et ce sont ces systèmes qui redeviennent UP les premiers, sans corruption de données, bref sans aucune intervention ... Parce que dans le cas de solutions, je n'ai plus le droit à l'erreur, je dois m'équiper de matériel de bien meilleure qualité que ce que j'avais préconisé avant la panne. Et donc plus couteux, là encore paradoxal ...
Je ne sais pas si c'est un standard des entreprises francaises, mais hélas c'est quelque chose que je vois (et pas que moi) de plus en plus souvent dans la gestion des risques informatiques. Souvent l'informatique est prise comme un outil et les DAF sont incapables de comprendre pourquoi on demande une enveloppe de 20K€ pour sécuriser un truc "qui marche déjà bien comme ça"...
Parce qu'on demande aux DAF de faire des économies et que c'est un moyen simple d'y parvenir à court terme :-( -- Greg
On 11/28/14 11:14, Greg wrote:
En deux ans, chaque point évoqués ont bougés quand ils se sont payés un mur, malgré les informations claires et précises du mur qui arrive "demain"...
Ce qui est navrant dans notre métier, c'est que tu dis toujours : "Je vous l'avais bien dit les gars" "Reprenez l'email du xxxxx ou je vous expose clairement qu'il faut deux DC et/ou gérer notre réseau" "Je vous ai fait toute l’étude financière de bout en bout (avec 3 scenarii) , vous avez prit la décision de ne pas donner suite" Mais quand arrive la panne, Et, le fait qu'il faut gérer les 3-8 au pied levés d'une heure a l'autre, parce que l’intégralité d'une production est HS, C'est quand même nous qui agissons. On a beau avoir prévenu du mur, deux, trois fois, il faut qu'on se le prenne pour que les DAF bougent. Moi je vous le dis, On ne fait pas un métier facile ;-)
Le 28/11/2014 11:22, Alexandre Legrix a écrit :
Ce qui est navrant dans notre métier, c'est que tu dis toujours :
"Je vous l'avais bien dit les gars" "Reprenez l'email du xxxxx ou je vous expose clairement qu'il faut deux DC et/ou gérer notre réseau" "Je vous ai fait toute l’étude financière de bout en bout (avec 3 scenarii) , vous avez prit la décision de ne pas donner suite"
Mais quand arrive la panne, Et, le fait qu'il faut gérer les 3-8 au pied levés d'une heure a l'autre, parce que l’intégralité d'une production est HS, C'est quand même nous qui agissons. On a beau avoir prévenu du mur, deux, trois fois, il faut qu'on se le prenne pour que les DAF bougent.
Moi je vous le dis, On ne fait pas un métier facile ;-)
Quand tu démontres que les économies d'un DAF font perdre plus de CA ou d'image de marque que l'économie réalisée ça fait aussi très mal pour eux, en tout cas quand je fais de l'audit / conseils je me gêne pas pour faire remarquer que les économies de pacotilles ont été et sont donc responsable ou vont être responsable d'une grosse perte. Déjà assisté à cela en réunion de présentation d'un audit, le DAF s'est fait retourné par la direction qui était heureusement technique et pas commerciale et le CTO s'est aussi fait réprimandé, on lui a reproché de pas s'être plus justifié sur ses besoins de budget et de ne pas avoir alerté la direction quand on le DAF lui a coupé les fonds. Mais malheureusement dans la trop grande majorité des entreprises la direction est commerciale donc le DAF a plein pouvoir pour faire des économies et quand ils sont dans le mur et que l'image en prend un coup ils transforment cela en plan d'attaque de modernisation, donc grosse comm auprès des clients / partenaires et du coup ça rassure ... du coup le marketing a du taf et tout le monde est content. Limites certains ont le droit à des couvertures médias pour annoncer qu'ils ont redondés leurs infras, regardez c'est devenu critique on fait du coup ce qu'il y a de mieux ...
Moi je vous le dis, On ne fait pas un métier facile ;-)
Avec de l'expérience j'ai associé les métier opérationnels de l’informatique (système/réseaux/logiciels) à de la gestion de risques. En gros il faut se forcer à faire une étude de cout/impact en cas de fail sur l'architecture dont tu as la responsabilité. Après tu présentes cela à ta direction qui fait le choix. De ton point de vue tu as fait ton boulot, même si il y a évidement plein de trucs que tu peux faire pour 0 qui vont améliorer la résilience. Et on ne pourra rien te reprocher. Maintenant c'est assez pénible de se heurter à un mur humain, je confirme :) Cdt, -- Raphael Mazelier
Le 28 novembre 2014 11:34, Wallace <wallace@morkitu.org> a écrit :
Quand tu démontres que les économies d'un DAF font perdre plus de CA ou
Ah c'est une bonne idée ça, économiser un DAF ! Ca coute quoi un DAF ? Aller, environ 100k€ brut soit ~ 160k€, de quoi monter une belle infra redondée et il en resterait encore ! quoi on est trolldi, non ? :) -- Greg
Le 28 nov. 2014 à 11:22, Alexandre Legrix a écrit :
On 11/28/14 11:14, Greg wrote:
En deux ans, chaque point évoqués ont bougés quand ils se sont payés un mur, malgré les informations claires et précises du mur qui arrive "demain"...
Ce qui est navrant dans notre métier, c'est que tu dis toujours :
"Je vous l'avais bien dit les gars" "Reprenez l'email du xxxxx ou je vous expose clairement qu'il faut deux DC et/ou gérer notre réseau" "Je vous ai fait toute l’étude financière de bout en bout (avec 3 scenarii) , vous avez prit la décision de ne pas donner suite"
Mais quand arrive la panne, Et, le fait qu'il faut gérer les 3-8 au pied levés d'une heure a l'autre, parce que l’intégralité d'une production est HS, C'est quand même nous qui agissons. On a beau avoir prévenu du mur, deux, trois fois, il faut qu'on se le prenne pour que les DAF bougent.
Moi je vous le dis, On ne fait pas un métier facile ;-)
Oui, ceci dit si vous n'aviez pas prévenu avant la faute aurait été sur vous. Conclusion : prévoir la panne n'a pas pour but de l'anticiper ou de l'éviter mais d'être sûr de garder votre poste lorsqu'elle se produira ! ;) Cordialement Emmanuel Thierry
Salut Grégory, Les incidents en datacentre arrivent, j'aurais tendance à dire qu'ils arrivent à présent moins souvent avec les derniers modèles de design 2N voir plus mais comme ces datacentres sont tout neuf et qu'ils n'ont pas encore essuyé les plâtres il faudra attendre pour voir arriver les premiers problèmes. Concernant le matériel je te rejoins sans soucis, il y a presque 10 ans nous avons eu dans un datacentre privé une grosse panne de clim en plein été caniculaire. Nous avons eu beau mettre des blocs de clim mobiles louées, des ventilos de pompiers la chaleur était intenable humainement et pourtant lorsqu'on a craint un départ d'incendie tellement les serveurs et rack étaient brulant on nous a dit noway. Pourtant ce risque était sérieux mais ça a tenu, 10h sans clim et les serveurs qui étaient en vie à la fin c'était tous les IBM et HP UX attention je parle des monstres d'y il y a 10 ans donc 4U mini et donc pas mal de place à l'intérieur pour un gros dissipateur thermique. Ce qui n'avait pas résisté à l'époque c'était tous les serveurs entrée / moyen de gamme y compris chez les constructeurs sérieux. Mais bon passer 10h dans une pièce à 70° au niveau de l'air et sans doute dépasser la centaine en interne sur les cpu / disque ce n'est pas donné à tout matériel. Encore plus en arrière y a 14 ans pour un opérateur vert de l'époque, nous avions une salle à CBV Ldcom où nous avions demandé à avoir du 14° en température sortie de grille au sol pour qu'en haut des racks on ne dépasse pas les 19° à l'entrée des serveurs. Pourquoi? Parce que c'était que des serveurs low cost et si ils dépassaient les 25° en entrée des serveurs on perdait des composants aléatoirement. Mais par contre on avait pour 200 serveurs en pièce détachée l'équivalent d'une quinzaine. Quand on rackait on avait tellement froid qu'on allai se réchauffer derrière les serveurs Prost Grand Prix qui chauffaient fort, souvenirs :D Après pour parler revenues, si une activité ne peut supporter quelques heures de coupures c'est qu'il est temps en effet de rallonger le budget pour mettre une redondance en place sur 2 DC et faire le développement nécessaire pour que les applications suivent. Ou alors faire comme un client il y a 10 ans où Google était tombé en panne un dimanche après midi pendant 5h soit on accédait pas à leurs sites, soit les résultats renvoyés étaient loufoques. Le client dépendait tellement du référencement que plus de 90% de ses visites ont disparus pendant ce temps. Le manque a gagné en pub était autour de 25K€. Le lendemain ils s'assuraient en perte de CA ce qui leur a coûté 10% de leur CA annuel. Je sais pas si avec le recul et la chute des revenus publicitaires cela leur a servi à nouveau mais c'est aussi une solution pour lisser la perte sans trop sortir de moyens techniques. Et pour ta question, oui une architecture ça s'entretient, si tu passes sur autre chose en interne c'est que l'infra n'est pas critique ou alors qu'il est temps de sous traiter la gestion quotidienne en infogérance. ++
Le 28/11/2014 10:10, Greg a écrit :
Ce qui ramène aux conclusions stratégiques et managériales : - on est en plein dans le "nobody known what I do until I don't do it", du coup quand tout fonctionne l'équipe ops se retrouve à faire de plus en plus autre chose que son métier, comme du développement - les Ops sont tout de même responsables car ... c'est dans leur responsabilité - les économies faites sur le matériel coûtent finalement bien plus cher ...
Perso, je vois aussi que, avec ma petite salle climatisée qui doit ressembler à du bricolage par rapport à un datacenter "renommé", je ne fais pas moins bien :-) -- Manu Jacquet
On 11/28/14 12:43, Manu wrote:
Perso, je vois aussi que, avec ma petite salle climatisée qui doit ressembler à du bricolage par rapport à un datacenter "renommé", je ne fais pas moins bien
Jusqu'a la prochaine panne majeur d'EDF dans ta région avec aucune idée du quand ça va revenir ;-) Ou la prochaine canicule. On en reparle si tu le veux bien. Cdlt
Le 28/11/2014 13:38, Alexandre Legrix a écrit :
Jusqu'a la prochaine panne majeur d'EDF dans ta région avec aucune idée du quand ça va revenir;-) Ou la prochaine canicule. On en reparle si tu le veux bien.
Ah mais je parle du site en tant que tel :-) Je n'ai pas dis que je n'avais pas de serveurs AILLEURS. Ce qui d'ailleurs pour moi reste la seule et unique solution viable. Selon Frederic
Comparer une salle privée récente avec un DC de plusieurs centaines de baies âgé de 14 ans,
En l'occurence, la salle dont je m'occupe a plus de 15 ans, est très petite, mais s'est adapté au fil du temps avec les évolutions de besoins. Donc je suis d'accord avec ton analyse. Merci pour tes précisions ;) -- Manu Jacquet
Hello, Le 28/11/14 12:43, Manu a écrit :
Le 28/11/2014 10:10, Greg a écrit :
Ce qui ramène aux conclusions stratégiques et managériales : - on est en plein dans le "nobody known what I do until I don't do it", du coup quand tout fonctionne l'équipe ops se retrouve à faire de plus en plus autre chose que son métier, comme du développement - les Ops sont tout de même responsables car ... c'est dans leur responsabilité - les économies faites sur le matériel coûtent finalement bien plus cher ...
Perso, je vois aussi que, avec ma petite salle climatisée qui doit ressembler à du bricolage par rapport à un datacenter "renommé", je ne fais pas moins bien :-)
C'est toujours facile de prendre ce genre de raccourci. On est dans un métier où on fait de la gestion de risque, c'est tout le côté délicat, tant que ça fonctionne, ça parait être la bonne solution, jusqu'au jour où... Le site de Level 3 Gateway à Nanterre est un très beau site au départ, mais c'est un site historique opérateur qui accuse à la fois son âge et le fait de ne pas être un DC opéré par une société dont c'est le métier premier. Il date d'avant la crise de 2000, il a été prévu et provisionné pour complètement dès son ouverture (capa électrique, clims, salles, baies, même le câblage des baies en cuivre). Les problème qui en découlent : - Le site a 14 ans et n'a pas franchement connu beaucoup de rénovations techniques (à moins que dernièrement ça ait changé) - Le site est dans l'enceinte d'un building de bureaux dont Level 3 est locataire au RDC, ce qui entraine de contraintes - Je pense que le programme de maintenance et l'entretien sur le long terme n'est pas aussi soigné que pour d'autres DC dont c'est le métier premier - Pas de présence 24/24 de quelqu'un sur site (plus depuis qu'AOL n'est plus là) - Comme tout a été provisionné dès le lancement, l'ensemble du matériel est âgé Avec des conséquences qu'on a connu : - Rupture de canalisation des WC du 1er qui a innondé le DC il y a quelques années (problème qu'ils ont connu 2 fois à Londres également, pas de bol) - Rupture d'une canalisation de circuit d'eau froide de clim en faux plancher (rouillée) entrainant une panne générale de clim - Problème électrique dernièrement - Problème de points chauds, puisque le dégagement calorifique des baies est bien supérieur à ce qu'il était au début des années 2000 Comparer une salle privée récente avec un DC de plusieurs centaines de baies âgé de 14 ans, c'est comme dire qu'un jeune de 20 ans à l'hygiène de vie douteuse est en meilleure santé qu'un mec de 50 ans qui fait du sport et qui a eu un problème physique. Pour moi un DC demande plusieurs années de fonctionnement pour qu'on puisse tirer un bilan. On se souvient aussi que Redbus Courbevoie a été considéré comme un bon DC à pas cher pendant des années avant de connaître une très grosse panne électrique il y a 10 ans dont on parle encore de nos jours. Pourtant ils n'en ont pas eu avant et ils n'en ont pas eu après. Il faut bien garder en tête que Level 3 est un site opérateur à la base et qu'il est vieux et n'a pas la qualité d'un DC neutre dont c'est le métier premier, mais qu'une salle "maison" ne l'est pas plus, même si elle n'a pas (encore) connu de problème. Il faut quand même souligner que Level 3 (j'exclus Global Crossing là) n'a pas eu de problème réseau pendant ces incidents, alors que le coeur de leur réseau parisien se concentre sur ce site (sur le circuit 48V) Frédéric
Le 28-11-2014 14:14, Frederic Dhieux a écrit :
Il faut quand même souligner que Level 3 (j'exclus Global Crossing là) n'a pas eu de problème réseau pendant ces incidents, alors que le coeur de leur réseau parisien se concentre sur ce site (sur le circuit 48V)
Et pourtant... 2014-11-18 15:05:49 BgpPeer BGP Session Up: 213.242.X.Y (AS3356), time 4m 46s ago 2014-11-18 14:10:57 BgpPeer BGP Session Down: 213.242.X.Y (AS3356), time 2m 35s ago. Arnaud.
Hello, Sur place au Capitole ? Rien eu de mon côté. Frederic Le 03/12/14 09:47, Arnaud Launay a écrit :
Le 28-11-2014 14:14, Frederic Dhieux a écrit :
Il faut quand même souligner que Level 3 (j'exclus Global Crossing là) n'a pas eu de problème réseau pendant ces incidents, alors que le coeur de leur réseau parisien se concentre sur ce site (sur le circuit 48V)
Et pourtant...
2014-11-18 15:05:49 BgpPeer BGP Session Up: 213.242.X.Y (AS3356), time 4m 46s ago 2014-11-18 14:10:57 BgpPeer BGP Session Down: 213.242.X.Y (AS3356), time 2m 35s ago.
Arnaud. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 28 novembre 2014 10:10, Greg <greg-frsag@duchatelet.net> a écrit :
Ce qui ramène aux conclusions stratégiques et managériales : - on est en plein dans le "nobody known what I do until I don't do it", du coup quand tout fonctionne l'équipe ops se retrouve à faire de plus en plus autre chose que son métier, comme du développement - les Ops sont tout de même responsables car ... c'est dans leur responsabilité - les économies faites sur le matériel coûtent finalement bien plus cher ...
Ton retour et les autres me font penser à Netflix et à sa philosphie du Dystopia as a service [1] et à leur Chaos Monkey Engineer [2] ; en gros ils embrassent l'échec et se préparent à ça plutot que de le nier et les Chaos Monkey Engineers sont en gros payés pour faire tomber la prod et évaluer la résilience de leur plateforme. Reste que ça demande une certaine maturité d'en arriver là et une remise en cause de nos pratiques/cultures actuelles. [1] http://fr.slideshare.net/adrianco/dystopia-as-a-service [2] http://techblog.netflix.com/2014/09/introducing-chaos-engineering.html
participants (11)
-
Alexandre Legrix -
Alexis Lameire -
Arnaud Launay -
Emmanuel Thierry -
Frederic Dhieux -
Greg -
Manu -
Nicolas Steinmetz -
Raphael Mazelier -
Wallace -
Xavier Beaudouin