|
|
|
2017.06.06
カテゴリ：カテゴリ未分類
Le 8 août, la compagnie aérienne Delta Airlines connaissait la panne la plus importante de son histoire : plus de 2 100 vols annulés, d’innombrables retards, une image sévèrement écornée et des millions de dollars perdus. Selon les explications du Pdg de l’entreprise, Ed Bastian, ce chaos qui a duré 2 jours et demi est dû à la simple défaillance d’un équipement électrique et à une erreur dans l’exploitation du datacenter : 300 serveurs qui n’étaient pas reliés à l’alimentation de secours.Associé du cabinet de conseils Duquesne Group et spécialiste de continuité d’activité, Emmanuel Besluau revient sur cette panne. Et pointe les zones d’ombre du scénario dessiné par le Pdg de Delta.Silicon.fr : Quels enseignements tirez-vous de la panne qui a handicapé le fonctionnement de la compagnie aérienne Delta pendant 2 jours et demi ? besluauEmmanuel Besluau : J’observe d’abord que deux versions ont circulé. La première expliquait que la panne trouvait son origine dans un équipement électrique passif, un power switch. Puis, on a parlé d’un module de contrôle de l’électricité, un équipement qui va répartir les arrivées électriques pour optimiser la consommation ou l’ajuster au besoin. Ce type d’équipements pourrait effectivement constituer un point unique de défaillance dans un datacenter si l’on n’y prend pas garde. Mais ce qui est plus surprenant, c’est qu’on nous explique que ce module a pris feu. Ce qui est assez inhabituel. J’ai certes déjà connu un cas similaire, mais c’était dans une petite salle informatique. Dans un grand datacenter comme doit en posséder Delta, cela soulève quelques questions. Car, avant de prendre feu, la température de l’équipement a dû augmenter, pendant un certain temps ce qui a dû se voir. Or, on a l’impression que Delta prend conscience du problème au moment de l’incendie. Y-a-il eu une défaillance dans le monitoring de la salle, ce qui pourrait expliquer que cette augmentation de température soit restée indétectée ? Difficile de répondre catégoriquement à cette question, mais on peut observer que la panne intervient en pleine nuit, dans le courant du mois d’août, période de l’année où des compétences clefs au sein des entreprises sont habituellement en congés…
Passée cette défaillance de l’équipement électrique, les conséquences paraissent exagérément élevées. Aller jusqu’à une coupure par Georgia Power (le fournisseur d’électricité de Delta, NDLR), cela signifie l’existence d’une surtension ou d’un autre problème : comment cela a-t-il bien pu se produire ? Est-ce un effet ou une cause ? En tous cas, la réaction de Georgia Power semble, dans le cas présent, normale : le fournisseur d’électricité détecte une surtension, ce qui provoque la coupure de l’alimentation primaire du datacenter.Au-delà de l’origine électrique de la panne elle-même, Delta explique que ses difficultés opérationnelles sont nées du fait que 300 de ses serveurs n’étaient pas reliés à l’alimentation de secours. N’est-ce pas surprenant ?E.B. : C’est un autre point intéressant. En effet, dans les datacenters modernes, chaque châssis ou serveur est relié à au moins deux alimentations électriques parallèles, chacune étant capable de faire face à une coupure de sa jumelle. Parfois, comme c’est le cas en France, le fournisseur d’électricité est unique, mais les deux voies sont de toute façon reliées à des onduleurs et des générateurs différents. Dans le scénario Delta, certains serveurs – les fameuses 300 machines évoquées par le Pdg – n’étaient manifestement pas reliés à deux voies, mais à une seule. C’est une pratique courante, à laquelle on a recours afin de réaliser des économies. Il y a alors bien une seule alimentation, mais un switch assure le basculement entre la source d’énergie primaire et une source alternative en cas de panne. Par ailleurs, cette solution est réservée aux serveurs non critiques. C’est pourquoi le scénario décrit par Delta comporte des zones d’ombre et me surprend quelque peu. Car même sur des serveurs mono-alimentés, les onduleurs et les batteries devaient alimenter toutes les voies et auraient dû offrir aux exploitants un temps de latence suffisant pour pour que les générateurs diesel démarrent et prennent le relais afin d’éviter un arrêt des serveurs. Généralement, cette autonomie varie entre 10 minutes et une heure. La panne décrite n’aurait donc pas dû avoir ces conséquences. Dès lors, comment un tel scénario a-t-il pu se produire ? Difficile de se prononcer. Mais on peut imaginer une proximité trop importante entre certains équipements, le feu causé par le module défectueux ayant alors pu endommager d’autres éléments. On a souvent l’impression que les exploitants ne réfléchissent pas suffisamment aux risques de ce type dans l’agencement de leurs salles. Des équipements redondants sont parfois placés l’un au-dessus de l’autre… Une autre hypothèse, c’est que l’incident n’a pas été bien détecté, et que les générateurs (ou l’un d’entre eux) n’ont pas démarré dans le temps imparti.Toujours est-il que la séquence d’événements telle que présentée, aboutissant à 300 serveurs non alimentés par le secours, est très curieuse et ne peut pas se produire dans un datacenter de type III par exemple. Ou alors Delta a laissé la situation dégénérer avec des générateurs en panne ou sous-dimensionnés… Comment expliquer que l’arrêt de ces 300 serveurs, qui devaient être les moins critiques de l’entreprise en théorie, ait provoqué une telle pagaille dans l’ensemble du système d’information ?E.B. : Le Pdg de Delta évoque la dépendance du système d’information aux systèmes mis à l’arrêt. Peut-être, au fil du temps, les équipes IT ont-elles introduit des dépendances aux applications placées sur ces serveurs mal protégés électriquement, par exemple en déplaçant des VM ? J’ai par exemple déjà vu deux bases de données en réplication active qui s’attendaient l’une l’autre, annulant tout bénéfice de la protection mise en place. Des choix d’architecture peuvent créer des dépendances qu’on souhaitait éviter à l’origine. C’est pourquoi, quand on déplace une VM, il faut toujours connaître les caractéristiques de continuité du serveur sur lesquels on va les positionner.Le temps nécessaire pour redémarrer l’activité vous a-t-il surpris ?
E.B. : On est ici dans un monde, l’aérien, où les affectations de vols, celles des personnels, l’embarquement des passagers, etc., sont gérés totalement via des systèmes d’information. Dès que ces systèmes ne sont plus synchronisés avec le réel, avec ce qui se passe sur le terrain, la remise en marche peut devenir d’une complexité diabolique. Surtout si on repart d’une sauvegarde ancienne. Il faut parfois écrire certains champs à la main, directement dans la base de données, pour contourner les blocages applicatifs. Je dirais même que repartir en 2 jours et demi, c’est plutôt bien ! Même si j’ai tendance à penser que la restauration des systèmes n’était pas totalement achevée au moment où la compagnie a déclaré l’incident terminé. Reprendre les activités sur un système qui s’est crashé – comme c’est le cas ici -, cela n’a rien à voir avec le test d’un plan de continuité d’activité (PCA), exercice où on prend la peine de fermer proprement les applications et bases de données avant de tester leur redémarrage… Par contre, je suis un peu plus surpris de constater que le Pdg de Delta semble découvrir les correspondances entre les exigences métier de son entreprise et les moyens techniques mis en œuvre. Comme si l’analyse de criticité des systèmes d’information (ou BIA) n’avait pas été menée. Quand je lis ses déclarations dans la presse américaine, je relève 5 ou 6 problèmes de non-conformité à la norme ISO 22301 (norme internationale de continuité de l’activité, NDLR).En dehors de cette étude de criticité, quels facteurs s’avèrent critiques dans le redémarrage de l’activité après une panne de cette nature ? E.B. : La prise de conscience des conséquences d’un incident d’exploitation et la rapidité de celle-ci sont essentielles pour limiter les dégâts. Pour un exploitant informatique, c’est un exercice très difficile. Dans ce genre de cas, la capacité à dresser un bilan fiable, 15 minutes après la panne, des systèmes qui fonctionnent et de ceux qui ne fonctionnent pas s’avère crucial. Dans le cas de Delta, je serais curieux de savoir qui a été le premier averti du problème sur les systèmes opérationnels de la compagnie. En espérant que ce ne soit pas un passager via les écrans des aéroports… Apple pourrait livrer une seconde édition de sa Watch à la rentrée, un terminal plus autonome et proposant des fonctions de géolocalisation plus poussées. La Watch 1 serait également rénovée.L’été est pauvre en actualités et particulièrement propice au lancement de rumeurs. Ming-chi Kuo, analyste chez KGI Securities, livre ses prédictions concernant la seconde génération de montre connectée d’Apple.Une Watch de première génération améliorée devrait être lancée au cours du second semestre 2016. Au menu, une étanchéité renforcée et un processeur gravé en 16 nm par TSMC, ce qui devrait permettre d’améliorer l’autonomie de cette montre.Dans le même temps, la Watch 2 sera proposée au public, avec des changements plus marquants. L’analyste annonce l’intégration d’un GPS et d’un baromètre. Deux éléments qui amélioreront les fonctions de géolocalisation de la montre. Une batterie d’une taille plus conséquente devrait également être proposée. La Watch 2 sera donc plus autonome… mais pas plus compacte que la première mouture.Ming-chi Kuo estime que ces changements permettront à Apple d’écouler entre 10 et 11 millions de montres connectées en 2016.En 2017, des changements plus importants pourraient être proposés par la firme de Cupertino, comme l’intégration d’un modem 4G LTE, qui rendra la Watch toujours plus indépendante de l’iPhone. Le prélude à des évolutions encore plus radicales, attendues pour 2018, assure l’analyste. Le DTEK50 est le nouveau smartphone de BlackBerry. Un milieu de gamme classique, bien équipé et correctement sécurisé. Une offre un peu trop sage.BlackBerry poursuit son aventure dans le monde des smartphones Android avec le DTEK50. Un terminal de milieu de gamme annoncé comme le plus sécurisé au monde. D’ores et déjà accessible en précommande au prix de 339 euros TTC, il sera expédié à partir de la semaine du 8 août indique le constructeur canadien.La sécurité est assurée par l’application DTEK, déjà proposée sur le Priv. Elle permet de faire le point sur les paramètres du système, mais aussi sur les droits accordés aux applications. Malheureusement, cet outil se borne à indiquer ce que les apps font de vos données personnelles. Il ne permet pas de bloquer ces accès.La société propose d’autres outils de sécurité au sein du DTEK50, comme l’application Password Keeper. BlackBerry promet également une diffusion rapide des correctifs de sécurité d’Android sur le DTEK50. C’est Android 6.0 Marshmallow qui est aux commandes de ce smartphone.Le DTEK50 reste un smartphone de milieu de gamme. Pourvu d’un processeur Snapdragon 617, il propose 8 cœurs ARM 64 bits Cortex-A53 (4 à 1,5 GHz et 4 à 1,2 GHz), épaulés par 3 Go de RAM et 16 Go de mémoire flash. 4G, WiFi 802.11ac et Bluetooth 4.2 sont de la partie. Le DAS reste mesuré : 0,377 W/kg. お気に入りの記事を「いいね！」で応援しよう
最終更新日
2017.06.06 10:57:21
コメント(0) | コメントを書く |
