RethinkIT

Florian Courtain · rethink-it.fr

Les 90 premières minutes d'une mission DBR

Voilà ce que je fais quand j'arrive sur une nouvelle mission Database Reliability : la méthode, dans l'ordre, sur les 90 premières minutes. Pas un produit séparé, pas un audit à acheter à la carte. C'est le standard d'exécution que vous retrouverez à chaque démarrage de mission avec moi.

Pourquoi 90 minutes

C'est ma première séance de travail. Trois objectifs :

  • Comprendre où ça coince vraiment avant de toucher quoi que ce soit. Écarter les hypothèses sympathiques mais fausses.
  • Sortir avec 3 à 5 priorités qui pilotent la suite de la mission. Pas une liste exhaustive de tout ce qui pourrait être amélioré.
  • Vous donner un avis honnête sur l'effort résiduel : ce qui mérite qu'on s'y attarde, ce qui peut attendre.

À la fin de ces 90 minutes, j'ai une note structurée, des actions priorisées avec estimations, et nous avons une feuille de route pour la suite. Si je pense qu'il faut plus de temps, je le dis. Si je pense que ce n'est pas mon créneau, je le dis aussi.

Ce qu'il me faut avant

Trois choses, simples :

  1. Un accès en lecture sur l'instance (DMV système, vues msdb, compteurs Windows si possible). Pas de droit d'écriture, je n'exécute aucune modification pendant cette première séance.
  2. 30 à 45 minutes du référent technique pour les questions ciblées. Idéalement la personne qui répond aux astreintes.
  3. Le contexte métier en 5 lignes : criticité, fenêtres de maintenance autorisées, RPO/RTO attendus (mesurés ou théoriques).

Si vous ne savez pas répondre à un de ces points, c'est déjà une information utile pour la suite.

Les six phases

1. Cadrage métier (15 min)

Je n'attaque pas par la technique. Je cherche d'abord à comprendre :

  • Quelle est la criticité réelle de l'instance (vs. celle qu'elle a sur le papier) ?
  • Quels sont les 2 ou 3 incidents qui ont marqué les 12 derniers mois ?
  • Qu'est-ce qui inquiète le DSI ou la DSI aujourd'hui ?
  • Quelle est la fenêtre d'intervention acceptable, et celle qui est tolérée en cas de crise ?

À la sortie de cette phase, j'ai une vraie liste de douleurs, pas la liste exhaustive de tout ce qui pourrait être amélioré. C'est cette liste qui pilote les 75 minutes restantes.

2. État de santé de l'instance (15 min)

Trois angles, en parallèle :

  • Wait stats (sys.dm_os_wait_stats) : où SQL Server "perd son temps". Top 5 par catégorie, normalisés temps signal vs. ressource. Un instantané, idéalement un échantillon sur 24-48 h via capture régulière.
  • Compteurs de performance clés : Buffer Cache Hit Ratio, Page Life Expectancy, Batch Requests/sec, ratio Compilations/Recompilations, latences disque (Avg. Disk sec/Read et /Write).
  • Configuration : sp_configure. Alertes sur les défauts laissés en place : MAXDOP, cost threshold for parallelism, max server memory, optimize for ad hoc workloads.

Ce n'est pas un diagnostic complet. Mais en 15 minutes, on sait si l'instance est en souffrance ou pas, et sur quel axe.

3. Sauvegarde et restauration (10 min)

Le point le moins glamour mais le plus structurant.

  • Couverture : msdb.dbo.backupset. Quand est la dernière FULL ? la dernière DIFF ? les LOG sont-ils en chaîne continue ?
  • Test de restauration : a-t-il été fait dans les 6 derniers mois ? Sur une instance autre que la prod ? Combien de temps il a pris ?
  • RPO/RTO mesurés : si je dois restaurer maintenant, point-in-time, combien de minutes de données perdues ? Combien d'heures de restauration ?

Un seul "non" à une de ces questions, et c'est une priorité immédiate dans la synthèse. Une sauvegarde non testée n'est pas une sauvegarde.

4. Haute disponibilité (10 min)

Si une architecture HA est en place (AlwaysOn Availability Group, FCI, mirroring, replicas) :

  • Topologie réelle vs. topologie documentée. L'écart fait souvent peur.
  • État courant des replicas : synchronisation, latence, dernier failover réussi.
  • Procédure de failover documentée et testée ? Par qui ? Sur quelle base ?

Sans HA : on regarde si le besoin existe (RTO incompatible avec un restore standard), et on chiffre l'écart.

5. Performance ciblée (25 min)

La phase la plus dense. Je cible 3 à 5 requêtes ou problèmes prioritaires, identifiés via :

  • Top requêtes par CPU, lectures logiques, durée moyenne, fréquence (sys.dm_exec_query_stats + sys.dm_exec_query_plan). Un mix de "ce qui coûte le plus" et "ce qui coûte le plus souvent".
  • Plans d'exécution suspects : seek qui devrait être scan (ou inverse), sort ou hash inutile, parameter sniffing, missing indexes critiques flaggés par le moteur.
  • Indexation : fragmentation sur les indexes les plus utilisés, missing indexes avec impact estimé, indexes redondants ou jamais utilisés.
  • tempdb : nombre de fichiers data vs cœurs, contentions sur les allocations (PAGELATCH_UP sur les fichiers GAM/SGAM/PFS), version store si snapshot isolation est actif.

Le but n'est pas l'exhaustivité. C'est de remonter 3 à 5 problèmes réels et actionnables.

6. Synthèse et actions (15 min)

Pas de finalisation à froid. On termine ensemble.

  • 3 à 5 actions priorisées. Quick wins en haut, structurel en bas.
  • Pour chaque action : effort estimé (en jours), impact estimé (perf, fiabilité, risque évité), prérequis éventuels (fenêtre de maintenance, accès, etc.).
  • Hand-off : note Markdown structurée que vous gardez dans votre wiki, ou simple discussion + envoi par mail. À votre préférence.

Si une action déborde clairement du périmètre 90 min (par exemple "il faut refondre l'archi HA"), je le dis explicitement et on cadre la phase suivante.

Livrables types

  • Note structurée (Markdown, environ 5 à 10 pages). Lisible dans Confluence, GitHub, Notion ou n'importe quel éditeur Markdown.
  • Tableau d'actions priorisées : action, effort jours, impact, prérequis.
  • Scripts de reproduction des findings (si applicable). Pour que vos équipes puissent re-vérifier après mes corrections.

Pas de slides, pas de diagrammes décoratifs. Vous repartez avec quelque chose d'exécutable.

À l'issue de ces 90 minutes

Vous avez :

  • Une photographie ciblée de l'instance (santé, perf, HA, sauvegarde)
  • Une liste d'actions priorisées avec estimations d'effort
  • Un avis externe franc sur ce qu'il reste à creuser
  • Une feuille de route pour la suite de la mission

Ce qu'on creuse ensuite

La suite dépend des priorités identifiées. Selon les cas, on attaque :

  • Optimisation perf en profondeur : implémentation des actions, tests A/B sur réplica, validation des gains.
  • Renforcement HA : revue archi, mise en place AlwaysOn/FCI, tests failover, procédures documentées.
  • Stratégie sauvegarde : refonte couverture, automatisation des tests restore, RPO/RTO mesurés.
  • Industrialisation : IaC PowerShell DSC ou Ansible, plans de maintenance, monitoring.
  • Sortie d'incident : si la première séance révèle une situation critique, on bascule en intervention.

Hors périmètre

Quelques sujets que je ne traite pas, pour cadrer dès le départ :

  • Audit de sécurité complet (permissions, surface d'attaque, hardening) : il faut un expert sécurité dédié.
  • Conformité réglementaire (RGPD, ISO 27001) : autre métier.
  • Benchmark workload / capacity planning à grande échelle : autre format de mission.
  • NoSQL pur (Mongo, Cassandra) : un spécialiste sera plus pertinent.

Discutons de votre mission

Si cette méthode résonne avec votre situation, le premier échange de 30 minutes reste offert. Pas de speech commercial, juste les bonnes questions pour cadrer.

TJM et conditions sur rethink-it.fr.