La seconde supplémentaire que les ordinateurs n'ont jamais été conçus pour aimer
Les horloges atomiques, socle du chronométrage moderne, battent avec une précision inébranlable. La rotation de la Terre, cependant, est tout sauf constante, ralentissant et accélérant de manière imprévisible. Pour réconcilier ce décalage, des leap seconds (secondes intercalaires) ont historiquement été insérées dans le Temps Universel Coordonné (UTC), le maintenant à moins de 0,9 seconde du rythme céleste de la planète.
Depuis leur introduction en 1972, 27 leap seconds positives ont été ajoutées. Lors de ces rares occasions, l'horloge passe de 23:59:59 à une valeur sans précédent, 23:59:60, avant de finalement basculer à minuit. Cette seconde supplémentaire pose un défi unique aux systèmes informatiques.
Unix time, une mesure fondamentale, suppose par définition que chaque journée contient précisément 86 400 secondes, n'offrant aucune représentation native pour 23:59:60. Les systèmes d'exploitation comme Linux gèrent traditionnellement cela en répétant une seconde, faisant effectivement reculer l'horloge pour jouer deux fois 23:59:59.
Cet ajustement temporel "non monotone", où l'heure affichée semble momentanément reculer, viole une hypothèse fondamentale de nombreuses applications logicielles. De telles perturbations ont provoqué à plusieurs reprises des défaillances critiques, notamment la tristement célèbre panne de Reddit en 2012, soulignant la fragilité inhérente d'un système construit sur une seconde que les ordinateurs n'ont jamais été conçus pour aimer.
Comment une seconde répétée a mis Reddit à genoux
Un exemple frappant de cette réaction en chaîne s'est produit le 30 juin 2012. Ce jour-là, l'insertion d'une leap second a déclenché un bug critique dans le noyau Linux. Au lieu de s'ajuster en douceur, le code hrtimer du noyau, interagissant avec les timers futex, a provoqué le réveil répété et instantané des processus. Cela a poussé l'utilisation du CPU à 100 %, bloquant efficacement les systèmes.
Reddit, une plateforme en ligne majeure, a subi de plein fouet cet ajustement subtil du chronométrage. Ses services sont devenus indisponibles pendant environ 30 à 40 minutes, démontrant comment une seule seconde répétée pouvait se répercuter sur l'infrastructure de production et mettre à genoux une application largement utilisée.
Cet incident, et d'autres similaires, ont mis en lumière une leçon d'ingénierie fondamentale : le wall-clock time (heure réelle) n'est pas toujours monotone. Il peut avancer, reculer ou se répéter, défiant l'hypothèse implicite dans une grande partie des logiciels selon laquelle le temps progresse toujours de manière linéaire.
Pour des systèmes robustes, les développeurs doivent concevoir une logique pour le temps écoulé et l'ordonnancement des événements qui ne dépend pas aveuglément de time.Now(). Au lieu de cela, ils doivent tenir compte des discontinuités potentielles. Cela implique l'utilisation de monotonic clocks (horloges monotones) pour les mesures de durée et une gestion prudente des séquences d'événements où le temps peut sembler reculer.
La panique du temps négatif chez Cloudflare — et la solution de contournement par « smear »
Une leap second différente, le jour du Nouvel An 2017, a paralysé le DNS de Cloudflare. Leur code Go calculait les durées de recherche DNS en soustrayant un timestamp de début d'un timestamp de fin. Lorsque l'horloge a reculé, le calcul a donné une durée négative, qu'une fonction attendant un argument non négatif a reçue, déclenchant une panique fatale.
Cet incident a mis en lumière une faille fondamentale : de nombreux systèmes logiciels supposent que le temps avance toujours, une hypothèse contredite par l'ajustement standard de la seconde intercalaire. Comme l'a expliqué Cloudflare, le « temps de résolution perçu sera négatif », entraînant des plantages inattendus. Pour plus de détails, consultez How and why the leap second affected Cloudflare DNS.
Pour contourner de tels sauts temporels brusques, des opérateurs majeurs comme Google et Meta utilisent une technique appelée leap smearing. Au lieu d'insérer une seconde complète d'un coup, ils ralentissent subtilement leurs horloges système sur plusieurs heures, distribuant progressivement la seconde supplémentaire. Cela garantit que le temps ne semble jamais reculer pour leurs systèmes internes.
Le smearing évite la discontinuité brutale qui provoque la rupture des logiciels, mais il introduit un nouveau défi. Différentes organisations peuvent utiliser des calendriers de smearing différents, ce qui amène leurs systèmes à diverger temporairement sur les relevés d'horloge. Cela nécessite une coordination minutieuse des sources de temps pour maintenir la cohérence au sein d'une infrastructure distribuée.
Cet article vous plaît ? Recevez-en un comme celui-ci chaque matin.
un e-mail par jour · désinscription en deux clics · aucun traqueur tiers
Les secondes intercalaires sont en voie de disparition, mais le temps nécessite toujours de l'attention
Les organismes internationaux de métrologie ont désormais décidé d'éliminer la seconde intercalaire, le changement devant prendre pleinement effet d'ici ou avant 2035. Ce changement monumental permet une divergence plus importante entre le Coordinated Universal Time (UTC) et le temps de rotation de la Terre, mettant fin à un demi-siècle de ces ajustements perturbateurs. La décision reflète un consensus croissant sur le fait que les risques l'emportent sur les avantages.
Un moteur essentiel de ce changement est la rotation récente et légèrement accélérée de la Terre. Cela a soulevé le spectre sans précédent d'une seconde intercalaire négative, où une seconde devrait être supprimée de l'UTC. Un tel ajustement, jamais mis en œuvre auparavant, poserait des défis encore plus grands pour les logiciels qui ont historiquement eu du mal avec l' ajout d'une seconde.
Pour les développeurs, cela signifie que la menace immédiate des secondes intercalaires finira par s'estomper, mais que les principes fondamentaux d'un chronométrage robuste demeurent. Utilisez toujours des monotonic clocks pour mesurer les durées et les délais d'attente, qui garantissent que le temps ne fait qu'avancer. Gardez les horodatages civils, souvent liés à l'UTC, distincts des mesures de temps écoulé.
Enfin, testez rigoureusement toutes les hypothèses sur le comportement de l'horloge. Même sans secondes intercalaires, les systèmes peuvent toujours rencontrer :
- Des échecs de synchronisation temporelle
- Une latence réseau
- Des ajustements manuels de l'horloge
Une conception et une validation minutieuses restent primordiales pour des systèmes distribués fiables.
Foire aux questions
Qu'est-ce qu'une seconde intercalaire ?
Une seconde intercalaire est une seconde supplémentaire ajoutée occasionnellement à l'UTC pour la maintenir approximativement alignée avec la rotation irrégulière de la Terre.
Pourquoi une seconde intercalaire peut-elle casser un logiciel ?
Certains systèmes répètent ou ajustent une seconde d'horloge, perturbant les logiciels qui supposent que le temps avance toujours ou que chaque jour compte exactement 86 400 secondes.
Quelle est la cause du problème DNS de Cloudflare en 2017 ?
Un ajustement d'horloge vers l'arrière a produit une durée négative dans un code qui attendait une valeur non négative, déclenchant une erreur critique dans une fonction de nombre aléatoire.
Les développeurs doivent-ils toujours utiliser des monotonic clocks ?
Oui. Utilisez des monotonic clocks pour mesurer le temps écoulé ; les horloges murales peuvent toujours être ajustées et sont mieux adaptées aux horodatages et au temps calendaire.