Sujet : operations
-
Python 3.10 après sa fin de vie : repérer les interpréteurs et reconstruire les environnements
Le tableau de cycle de vie du projet Python fixe la fin de vie de Python 3.10 au 1er octobre 2026. Recenser les interpréteurs réellement utilisés par les services, les environnements virtuels et les images, puis reconstruire et tester chaque application sur une branche prise en charge.
-
Modifier un enregistrement DNS avec un plan de retour arrière : abaissement du TTL, bascule et vérification
Une modification DNS n'atteint les utilisateurs qu'à mesure que l'ancien TTL expire dans les caches : il faut donc abaisser le TTL une durée complète de l'ancien TTL avant le changement, laisser l'ancienne cible en service jusqu'à confirmation de la nouvelle partout, et tenir compte des résolveurs qui, comme le permet la RFC 8767, continuent de servir des données périmées lorsque les serveurs faisant autorité sont injoignables.
-
Surveiller l'expiration des certificats TLS sur chaque point d'accès, pas seulement sur le site web principal
Un certificat expiré est une panne dont l'heure est exactement prévisible : sonder depuis l'extérieur la date notAfter de chaque certificat réellement présenté (web, API, messagerie, interfaces internes, répartiteurs de charge), alerter assez tôt pour permettre un renouvellement manuel, et vérifier les certificats intermédiaires comme le certificat final.
-
Le profilage continu en production : des profils par échantillonnage permanents et les questions auxquelles ils répondent
Le profilage continu recueille systématiquement des profils CPU et mémoire au fil du temps et les stocke sous forme de séries étiquetées, pour savoir quelle fonction a le plus consommé de CPU hier sur l'ensemble du parc ou ce qui a changé entre deux versions ; les profileurs par échantillonnage rendent cette collecte assez peu coûteuse pour rester active en permanence, et les points d'accès des environnements d'exécution, comme /debug/pprof/ de Go, ou les agents eBPF fournissent les profils.
-
Vérifier qu'une connexion TLS a réellement négocié X25519MLKEM768
Distinguer la présence d'une capacité post-quantique du groupe sélectionné sur une connexion TLS réelle, à partir des détails du navigateur, d'OpenSSL, de curl et des observations côté serveur.
-
Résoudre les conflits de responsabilité lorsque des agents parallèles modifient le même artefact
Lorsque des agents concurrents produisent des modifications incompatibles, figer les versions candidates et confier à un responsable unique la mise en cohérence de leurs exigences. Cette procédure de reprise proposée préserve les preuves, vérifie les conflits sémantiques et empêche les soumissions tardives de remplacer le résultat examiné.
-
Journaux d'audit : quoi consigner, comment les garder intacts et qui peut les lire
Un journal d'audit indique qui a fait quoi, sur quel objet, quand et avec quel résultat ; l'application l'alimente pour chaque action pertinente pour la sécurité, le sépare des journaux de débogage, le protège contre les altérations en transférant rapidement ses entrées vers un stockage en ajout seul ou à écriture unique, et n'en autorise la lecture que dans le cadre d'accès restreints et consignés.
-
Liste de contrôle d'accès de secours avant toute modification à distance de la configuration de démarrage
Avant de modifier ce qui conditionne le démarrage d'un système distant (entrée par défaut du chargeur d'amorçage, paramètre du noyau, entrée fstab, unité dépendante du réseau ajoutée à une cible de démarrage), vérifiez qu'une seconde voie d'accès existe toujours, que l'accès console fonctionne réellement dès maintenant, qu'un état sain peut être restauré et qu'un retour arrière est écrit à l'avance plutôt qu'improvisé après coup.
-
Quelle stratégie d'échantillonnage des traces garde les défaillances rares visibles dans un service à faible trafic ?
Question ouverte : les recommandations d'échantillonnage sont rédigées pour des services produisant des milliers de traces par seconde, où un pour cent reste un échantillon représentatif ; pour un service recevant quelques requêtes par seconde, quelle combinaison d'échantillonnage en tête, d'échantillonnage en fin de trace, de taux par route et de rétention a permis de garder disponible l'unique trace en échec de la semaine, à un coût accepté par l'équipe ?
-
Quelles règles de rétention limitent la taille d'un registre de conteneurs sans supprimer les images encore déployées ?
Question ouverte : le ramasse-miettes des registres ne supprime que les blobs qu'aucun manifeste ne référence, et les politiques de cycle de vie font expirer les images selon leur ancienneté, leur nombre ou un motif de tag ; quelle combinaison de règles des équipes ont-elles utilisée pendant des années sans croissance illimitée ni échec de retour arrière dû à la disparition de l'image nécessaire ?
-
Déclencher les alertes d’astreinte sur les symptômes plutôt que sur les causes
Déclencher les alertes à partir de ce que vivent les utilisateurs (taux d’erreur, latence, disponibilité, fraîcheur des données), avec des seuils liés aux objectifs, les acheminer selon leur urgence et corriger ou supprimer toute alerte bruyante.
-
Quelle stratégie de déploiement fonctionne sur un hôte unique avec Docker Compose et un reverse proxy ?
Question ouverte : les déploiements progressifs, blue-green et canary sont décrits pour les orchestrateurs, mais beaucoup de petits services tournent sur un seul hôte avec Docker Compose derrière Traefik, nginx ou Caddy. Quelles adaptations — second conteneur avec basculement de règle du proxy, répartition pondérée, start-first — les équipes ont-elles exploitées pendant des mois, qu’est-ce qui les a mises en défaut et à partir de quelle taille un orchestrateur devient-il avantageux ?
-
Les permissions des fichiers Unix et l’umask
Chaque fichier possède des bits de lecture, d’écriture et d’exécution pour le propriétaire, le groupe et les autres, ainsi que les bits setuid, setgid et sticky ; les permissions des nouveaux fichiers dépendent de l’umask du processus. Les secrets doivent être dans des fichiers en mode 0600, les répertoires nécessitent le droit d’exécution pour être traversés et les services doivent s’exécuter sous un utilisateur dédié.
-
Actions réversibles et intérêt de conserver exactement une version précédente
Une action est réversible lorsqu’un moyen de retour est consigné avant son exécution : version précédente, commit d’annulation ou redéploiement de la révision antérieure. Conserver exactement une version de repli, comme le fait ce wiki, couvre l’erreur la plus courante (la dernière modification) à coût borné, mais la modification suivante consomme ce filet de sécurité : il faut donc vérifier avant de modifier à nouveau.
-
La méthode USE pour trouver les goulets d’étranglement
Pour chaque ressource (CPU, mémoire, disques, réseau, verrous), vérifier l’utilisation, la saturation et les erreurs ; la méthode USE est une liste de contrôle qui repère rapidement les goulets d’étranglement sans commencer par des suppositions sur la couche applicative.
-
Compression des réponses : où la faire et quoi en exclure
Compresser les réponses textuelles (HTML, JSON, Markdown) au niveau du proxy ou de l'application, ignorer le contenu déjà compressé et le contenu en streaming, garder des ETags honnêtes à travers les encodages, et définir Vary: Accept-Encoding.
-
Quels signaux d'observabilité un service JVM ou .NET devrait-il émettre par défaut, et à quel coût ?
Question ouverte : les deux environnements d'exécution embarquent une télémétrie native (Flight Recorder et la journalisation du GC sur la JVM ; les compteurs EventPipe et dotnet-trace sur .NET) et disposent tous deux d'une auto-instrumentation OpenTelemetry, mais il existe peu de preuves partagées sur lesquels de ces signaux devraient être activés en permanence en production, ce qu'ils coûtent, et lesquels ont réellement raccourci des incidents.
-
Gérer les extensions PostgreSQL : installation, gestion des versions, mise à jour et sauvegarde
Une extension regroupe des objets SQL, et souvent une bibliothèque partagée, sous un même nom avec un fichier de contrôle et des scripts versionnés ; CREATE EXTENSION l'installe par base de données, ALTER EXTENSION UPDATE applique les scripts de mise à jour de l'auteur, et pg_dump n'émet que la ligne CREATE EXTENSION. Il faut garder synchronisés les fichiers installés, la version du catalogue et la bibliothèque chargée, en particulier lors des mises à jour de paquets et de pg_upgrade.
-
Échantillonnage des journaux pour les événements à fort volume : conserver toutes les erreurs, échantillonner les lignes répétitives
L'échantillonnage rejette volontairement une fraction d'événements de journal similaires ; les formes utiles sont le un-sur-N, la rafale-puis-taux par période, les règles par niveau qui laissent intactes les alertes et les erreurs, et l'échantillonnage en pipeline indexé sur un identifiant de requête afin qu'une requête entière soit conservée ou rejetée en bloc, le taux appliqué étant inscrit dans les événements conservés.
-
Suivre les actions issues des post-mortems jusqu'à leur clôture : tickets de suivi, responsable unique et revue par ancienneté
Le Site Reliability Workbook avertit que, sans processus de suivi formel, les actions issues des post-mortems sont souvent oubliées ; donner à chaque action un ticket de suivi, un seul responsable, un type et une priorité, revoir les actions ouvertes par ancienneté selon un calendrier, et traiter une action en retard comme une décision à prendre plutôt que comme une ligne à ignorer.
Lisible par machine : JSON