Témoignages

Joris FILLINGER, Ingénieur Informatique

Formation

DUT Mesures Physiques option MCPC par alternance

Entreprise/Collectivité

BP2I (Une Joint Venture entre IBM et BNP PARIBAS)

Description du poste

Je travaille pour BP2I, une entreprise née d’un partenariat entre IBM et BNP PARIBAS. BP2I a pour seul but l’hébergement et la gestion de toute l’informatique de BNP PARIBAS et de ses filiales. On peut donc voir BP2I comme une entreprise vendant un service et la BNP et ses filiales comme nos clients. Comme tout client, la BNP s’attend à ce que le service rendu soit conforme à ses attentes, c’est-à-dire que ses données et ses applications soient disponibles et en état de marche 24H/7J. Imaginez que le client final (quiconque traitant avec la BNP ou une de ses filiales) n’ai plus accès à ses comptes ou ne puisse plus faire de transaction bancaire, la banque pourrait perdre beaucoup en très peu de temps.
Pour rendre ce service, BP2I gère l’informatique de la BNP via différentes technologies, dont le Mainframe (similaire à un serveur avec un OS propriétaire IBM : le z/OS) qui est le produit sur lequel je travaille. Il y a différentes équipes qui travaillent de concert pour maintenir les parcs informatiques de la BNP opérationnels, comme l’équipe stockage, dans laquelle je travaille. Comme son nom l’indique, l’équipe stockage s’occupe de la gestion des données et de l’espace de stockage des données. Ce métier contient différents aspects :

  • Tout d’abord la gestion de l’espace de stockage, nous devons nous assurer d’avoir suffisamment de disque et bandes magnétique dans nos baies pour répondre au besoin des clients (Ils peuvent à tout moment demander quelques To supplémentaires).

  • Ensuite vient la notion de disponibilité et d’intégrité des données : leurs données doivent toujours être disponibles et en bon état (ce serait dommage qu’un zéro disparaisse sur le solde de votre compte…). Pour ce faire, nous répliquons leurs données sur plusieurs baies qui sont géographiquement dispersées. Ainsi si l’une d’entre elle venait à dysfonctionner, nous avons des backups.

  • En troisième vient la gestion des données : lorsque qu’un fichier est créé, beaucoup de paramètre sont à définir : au bout de combien de temps on le supprime ? On enregistre le fichier sur disque ou sur bande magnétique ?  On l’enregistre sur combien de disques ? Qui est autorisé à le consulter/modifier ? Toutes ces questions définissent le cycle de vie de la donnée, et c’est à nous de maintenir les scripts qui gèrent tout ça avec les demandes de nos clients.

  • En dernier vient le support : si un problème survient nous devons le résoudre dans les plus brefs délais. Nous nous occupons uniquement du support de niveaux 3 avec des astreintes d’une durée d’une semaine.

Travail au quotidien

Voilà qui explique succinctement mon métier sans trop rentrer dans les détails. Pour les plus courageux et intéressés d’entre vous, voici un exemple de projet sur lequel je travaille en ce moment :

Le projet consiste à migrer une partition (appelons la Robin), avec ses données et ses applications, dans une autre partition (appelons celle-ci Jeanne). Plusieurs questions se posent alors :
Tout d’abord qu’elles sont les données et les applications à transférer, tout n’est pas forcément utile. Il faut donc entrer en relation avec le client pour savoir de quoi il a besoin exactement. De même, certaines données sont en doublon sur les deux partitions, il faut choisir lesquelles conserver avec le client.
Une fois ceci fait nous avons une idée de la volumétrie à transférer sur la partition Jeanne. Il faut maintenant voir si cette dernière est capable d’absorber cette volumétrie et commander des disques le cas échéant (attention la partition Jeanne est répliqué sur 3 baies, il faut donc voir si les 3 baies peuvent l’absorber).
Ensuite vient la gestion des données, la gestion n’est peut-être pas la même sur les deux partitions, il faut donc adapter celles de Jeanne pour qu’elle prenne en compte la gestion des données qui était défini sur Robin.
En parallèle à ces tâches, il faut définir un scénario de migration. De quelle manière va-t-on transférer les données ? Le scénario est à choisir en prenant en comptes les risques et les dégradations de performances (le temps de la migration) qui en résulte, puis le client valide ou non le scénario.
Une fois le scénario validé, il faut choisir une date pour cette migration. On ne peut le faire n’importe quand. Cette migration n’inclue aucune gradation des performances mais le risque zéro n’existe pas. La date pour la migration est définie par le client, en générale ces « opérations » sont effectuées le week-end (moment de la semaine ou il y aurai le moins d’impact en cas de problème), et en dehors des « frozen zone ». Les frozen zone sont les moments de l’année où il est interdit de faire des opérations (comme par exemple la période de noël où il y a énormément de transactions bancaires).