Le membre du mois – Avril 2015

Chaque mois, le GUSS met en avant un membre de la communauté. C'est une bonne occasion pour vous de découvrir les différents métiers autour de SQL Server.

Ce mois-ci, nous vous proposons de vous faire découvrir un DBA production au travers de cette interview avec Gilles Ducassou.

Depuis quand fais-tu du SQL server ? Sur quelle version ? Que faisais-tu au début ou comment cela a commencé ?

J’ai contracté le virus SQL Server au début de l’année 2006, en étant exposé à SQL Server 2005 Enterprise. A l’époque, mon rôle était d’exploiter une plateforme de fidélisation d’un groupe bancaire dont la mise en production était prévue quelques semaines plus tard : j’ai donc commencé avec une plateforme vierge en phase pilote comportant quelques centaines d’utilisateurs et quelques GB de données, pour arriver peu de temps après avec plusieurs millions d’utilisateurs et plusieurs To de données. En l’absence de compétence SQL au sein de mon équipe et sur une version RTM prometteuse mais qui n’était pas exempte de bugs, les problèmes de performances n’ont pas tardé à apparaître aussi bien sur le transactionnel que sur le décisionnel. L’impact de ces problèmes sur le business a fait que je m’y suis plongé la tête la première, et j’ai rapidement aimé ça ! Au bout d’un an, je savais que je voulais devenir DBA.

En quelques mots, mon métier de DBA expliqué à mon entourage ?

Lorsque j’explique mon métier, notamment à des personnes allergiques à l’informatique, la première question qui revient invariablement est « Mais c’est quoi une base de données ??? ». Afin de vulgariser et désacraliser cette chose bizarre, j’utilise souvent une analogie avec un placard rempli de tiroirs où on stocke ses vêtements et tout devient facile.

• C’est quoi une table heap ? c’est la manière quelque peu masculine de ranger dans ce placard… rapide pour « ranger » mais beaucoup moins pour retrouver ce qu’on y cherche.
• C’est quoi un clustered index ? c’est la manière de ranger un peu plus féminine… bien rangé, bien ordonné, efficace pour retrouver ses habits, mais qui nécessite forcément un peu plus de temps de rangement.

Et le DBA dans tout ça ? Il définit le nombre et la forme des rangements, identifie le type de placard ou de dressing nécessaire, s’assure d’installer une serrure et de positionner de l’antimite, et donne quelques conseils de rangement afin qu’on soit sûr à 200% de retrouver ses habits intacts quoi qu’il arrive.

Aujourd’hui, comment utilises-tu SQL Server ?

J'utilise SQL Server au quotidien pour héberger de nombreuses bases de données, principalement sur des architectures cluster virtuelles ou physiques. J'utilise également beaucoup SSIS pour automatiser un certain nombre de tâches, et notamment les restaurations hebdomadaires des bases de production vers les environnements de développement/recette/préproduction. Enfin, je mets en œuvre SSRS pour des besoins de reporting sur l'ensemble de notre infrastructure, ainsi que pour du reporting fonctionnel.

Quelle est ta fonctionnalité SQL Server préférée ?

Difficile de choisir, il y en a tellement… Mais j’opterai pour l’une des plus risquées. Elle permet parfois de faire des miracles quand tout semble perdu. Elle passe souvent comme une forme de magie étant donné sa mise en œuvre, en un clin d’œil, ou comme une forme de malédiction lorsqu’on oublie de la documenter rigoureusement : j’ai nommé, la mise en œuvre de plan guides ! Bien évidemment, c’est aussi une de celle qui ne pardonne pas, qu’on réserve aux cas désespérés et qui reste dangereuse même utilisée à bon escient… Mais il est toujours tentant d’essayer, juste pour voir ! Au final, je pense n’en avoir mis en place que 3 plans guide en production ces 10 dernières années, mais ça m’a réellement sorti de l’impasse.

Selon toi comment évoluera le métier de DBA avec l'essor de la sous-traitance et du cloud ces dernières années ?

De mon point de vue, le métier de DBA est en constante évolution et ce depuis le début ; l'essor de la sous traitance et l'avènement du cloud sont deux éléments moteurs de l'évolution actuelle, mais ne signeront en aucun cas la disparition de ce métier. Des éléments moteurs d'évolution, il y en a eu d'autres : les avancées technologiques en matière de stockage et de puissance machine, internet et le e-commerce, etc. Certes, le cloud va profondément transformer le quotidien de nombreux DBA de production, mais c'est une bonne chose : soyons lucides, qui ne rêvait pas il y a 20 ans de pouvoir déployer en quelques minutes une instance  SQL pleinement opérationnelle, en quelques clics ? Certes la sous-traitance va modifier le nombre et le type de poste à pourvoir dans les différentes zones géographiques, mais il restera toujours des choses qu'on ne sous traite pas... Notamment les choses plus complexes/risquées/intéressantes ! Personnellement, je suis ravi de pouvoir héberger des solutions dans le cloud et de pouvoir sous traiter des incidents N1/N2 : ça ne me laisse que plus de temps à consacrer à ce qui me passionne réellement dans mon métier. Ainsi, j'espère, et je pense sincèrement, que le métier de DBA continuera d'évoluer vers un métier qui restera unique et passionnant.

Quel est ton plus beau challenge technique autour de SQL Server ?

Le plus beau challenge technique a été de remettre à flot et de sécuriser une infrastructure hébergeant de milliers de bases, dont les caractéristiques principales étaient :

• Absence de plan de maintenance (sauvegarde/restauration)
• Pas de haute disponibilité (ni de PRA/PCA)
• Aucun environnement autre que ceux de production
• Pas de mise à jour (OS, SQL, Server, hardware, etc)
• Passwords "sa" connu de tous et en dur dans les applicatifs

Il a fallu tout repenser, concevoir, et implémenter, migrer... Il m'a également fallu acquérir et mettre en oeuvre des compétences techniques variées, organiser un changement dans la douceur pour les développeurs et le plus transparent possible pour nos clients. Après environ 2 années de travail, l'entreprise est à nouveau sereine vis-à-vis de ses bases de données, et 2 années de plus ont démontré le bienfait du changement apporté : désormais, SQL Server ou pas, il est devenu naturel pour les administrateurs et chefs de projets de penser backup/disponibilité/sécurité/déploiement dès la phase de conception des nouveaux produits. C'était un sacré challenge !

Te sens-tu faire partie de la communauté SQL ? Pourquoi ?

Oui tout à fait ! J'ai vraiment l'impression qu'il existe une communauté formée de gens passionnés par SQL Server, qu'ils soient DBA, développeurs ou architectes. Beaucoup de membres de cette communauté sont disponibles pour apporter une aide ou des réponses à quiconque en a besoin, beaucoup d'autres sont présents pour poser les bonnes questions ou mettre en œuvre des choses intéressantes et inédites autour de SQL Server et surtout partager leur savoir. Et puis si cette dynamique et l'enthousiasme autour de SQL n'existaient pas, je n'aurai probablement jamais eu l'envie de devenir DBA, et je n'y sera probablement pas arrivé seul. Au vu de tout ce qui caractérise cette communauté, oui j'en fait partie, et oui j'en suis heureux !

Quel est ton meilleur souvenir au GUSS ?

Les Journées SQL Server dont je garde toujours un excellent souvenir : très convivial, bien organisé, concentrant beaucoup de compétences et de passionnés SQL. C'est un événement que je fais en sorte de ne pas manquer : vivement le prochain !

Quels sont les sites/blogs que tu suis régulièrement et ton e-book de chevet ?

• http://www.sqlservercentral.com/
• http://www.sqlskills.com/blogs/paul/
• https://www.sqlskills.com/blogs/jonathan/
• http://www.brentozar.com/blog/

E-book de chevet : "Pro SQL Server Internals" de Dmitri Korotkevitch

Tu peux nous décrire la dernière fois où tu as transpiré des dents, lors d'un incident majeur ?

C’était il y quelque temps déjà mais le souvenir reste bien présent. D’un côté, un SAN de production vieillissant, hébergeant plusieurs centaines de VMs et quelques milliers de bases de données SQL 2000 dispatchées sur des instances standalone et bien évidemment sans aucun plan de reprise d'activité. De l’autre côté, un cluster SQL 2008 R2 flambant neuf en cours de recette, supporté par un nouveau SAN très confortablement dimensionné, avec un plan de migration à chaud à échéance dans quelques mois… et un batterie de tests prévus pour valider que mon design était aussi efficace sur le papier qu’en réalité. Le plan était parfait, mais il y avait une inconnue dans l’équation : l’ancien SAN survivrait-il jusqu’à sa retraite bien méritée ?

Réponse : Et bien non ! Le SAN récalcitrant a rendu l’âme – i.e. irréparable et données irrécupérables – un soir à 19h, bien plus tôt que prévu. Une seule solution : restaurer toutes sauvegardes disponibles vers le futur environnement et prier pour qu’il n’y ait pas de trou dans la raquette… Et à faire à l’arrache, en une nuit, ce qui était normalement cadré sur plusieurs semaines ! La « nuit » fut longue – environ 37h – mais on s’en est sortis avec les honneurs et une très très grosse frayeur !

Quel est le cas le plus aberrant que tu aies relevé en production ?

Lors d’un audit base de données pour le compte d’un client, je découvre une instance SQL dont les bases de données n’ont jamais connu la moindre sauvegarde depuis leur création et ce depuis plusieurs années : c’est vrai aussi bien pour les bases de production, que les pour les bases de test/développement/bricolage hébergées sur cette même instance. Or, en évoquant ce point avec le responsable de cette plateforme, celui-ci m'a rétorqué « Pourquoi faire des sauvegardes ? Nous n’avons jamais fait et ça a toujours très bien fonctionné… ». J’avoue être resté perplexe quelques instants !

Quel est la frontière en l'étude et la production pour un DBA ?

Lors de mes expériences professionnelles passées, il m’a toujours semblé naturel pour le bien des projets d’avoir un pied de chaque côté de cette frontière.  En effet, les contraintes de production et les options possibles pour les aténuer sont souvent étroitement liées à des choix qui ont été faits côté étude. En outre, un DBA de production a besoin de connaître au mieux le fonctionnement du système dans son ensemble (fonctionnel/business compris). Cette frontière est de la même nature que celle entre développeurs et opérationnels : indéniablement présente dans les esprits, mais avec un fondement discutable en pratique.

Mise en situation d'un DBA :

Quand j'aide un jeune codeur à fixer ses requêtes

http://www.commitstrip.com/fr/2014/08/01/when-i-help-a-rookie-coder-fix-his-queries