Fenêtres de maintenance¶

Planifier les creneaux de changement, communiquer aux parties prenantes et gérer les periodes de gel — pour éviter les conflits et les surprises.

Pourquoi planifier des fenêtres de maintenance¶

Exécuter un changement au mauvais moment peut multiplier l'impact d'un incident. Une fenêtre de maintenance sert à :

• concentrer les changements sur des periodes à faible trafic ou faible activité métier
• informer les parties prenantes en amont pour éviter les surprises
• disposer d'une équipe complète et disponible pendant l'exécution
• limiter l'impact utilisateur en cas de panne ou de dégradation

Types de fenêtres¶

Planification des creneaux¶

Le choix du creneau doit prendre en compte plusieurs facteurs simultanément.

Critères de sélection d'une fenêtre¶

• Courbe de trafic : identifier les heures creuses via les métriques de production (requests/s, connexions actives)
• Contraintes métier : éviter les periodes critiques (fin de mois pour la comptabilité, periodes de soldes pour l'e-commerce)
• Disponibilité équipe : assurer la présence de toutes les compétences nécessaires (infra, dev, DBA selon le changement)
• Durée estimée + buffer : prévoir 30 a 50 % de marge pour les imprevu, plus le temps de rollback complet si nécessaire

Timeline d'une fenêtre type¶

gantt
    title Fenetre de maintenance type (3h)
    dateFormat HH:mm
    axisFormat %H:%M

    section Preparation
    Verification pre-changement    :done, 22:00, 20m
    Communication "debut fenetre"  :done, 22:20, 5m

    section Execution
    Execution du changement        :active, 22:25, 60m
    Point de verification go/no-go :22:25, 90m

    section Verification
    Smoke tests                    :23:55, 20m
    Monitoring 15 min              :00:15, 15m

    section Cloture
    Communication "fin fenetre"    :00:30, 5m
    Cloture RFC                    :00:35, 10m

Communication aux parties prenantes¶

Une bonne communication de maintenance respecte trois temps : avant, pendant et après.

Template de notification pre-maintenance¶

OBJET : [MAINTENANCE] <Service> — <Date> <Heure debut>-<Heure fin>

Bonjour,

Une maintenance est planifiee sur <service> :

Date : <date>
Heure : <heure debut> — <heure fin> (<fuseau horaire>)
Impact : <description de l'impact attendu : indisponibilite / degradation / aucun>
Raison : <description courte du changement>

Actions requises de votre part : <aucune / sauvegarder vos travaux / etc.>

En cas de probleme apres la fenetre : <contact / canal de support>

Cordialement,
<Equipe>

Template de notification post-maintenance¶

OBJET : [MAINTENANCE TERMINEE] <Service> — Statut : <Succes / Echec>

La maintenance planifiee sur <service> est terminee.

Statut : <Succes / Echec avec rollback / Succes partiel>
Heure de fin reelle : <heure>
Notes : <ecarts eventuels, actions de suivi>

Le service est <disponible / en cours de restauration>.

Freeze periods¶

Une freeze period est une periode pendant laquelle les changements en production sont interdits ou fortement limites.

Quand geler les changements¶

Communiquer le calendrier de freeze¶

Le calendrier de freeze doit être communique au moins 4 semaines à l'avance, inclus dans le calendrier de change centralise et accessible à toutes les équipes.

Calendrier de change centralise¶

Un calendrier de change unique et visible par toutes les équipes permet de :

• détecter les conflits de planification (deux changements sur le même système le même soir)
• visualiser la charge de changements sur une periode
• identifier les periodes surchargées et redistribuer
• intégrer les freeze periods et les événements métier

Contenu d'une entree de calendrier¶

Outils¶