Contexte et incidents d'août 2026

Le mois d'août 2026 a été marqué par une interruption de 10 heures 42 minutes (06 août, 15:22 UTC) déclenchée par un déploiement de routine d'un service interne GitHub Actions. La réduction temporaire du nombre de pods a saturé le maillage de services, entraînant un throttling CPU et des redémarrages OOM des sidecars. La saturation s'est propagée aux caches, DNS et API, créant un effet domino. Un bug latent dans le chemin d'assignation des jobs a ensuite ralenti la récupération en bloquant des runners sur des tâches révoquées.

Migrations de bases de données vers Azure

Le 11 août, GitHub a exécuté pour la première fois un primaire MySQL en production sur Azure, avec un impact d'écriture négligeable et aucune interruption client. Deux migrations supplémentaires ont suivi le 27 août, suivant un schéma de montée en complexité. Ces migrations visent à augmenter la capacité globale et à réduire la dépendance aux bases partagées. Le déplacement du cohort de 24 tables d'authentification hors du serveur mysql1 a éliminé environ 1 million de requêtes par seconde des réplicas, tandis que des nettoyages de requêtes ont retiré 120 000 qps supplémentaires, économisant 59 000 secondes de travail inutile chaque heure.

Optimisations de capacité et résilience

GitHub Actions a bénéficié d'une réallocation de 33 % des jobs vers une capacité excédentaire, faisant baisser l'utilisation maximale du CPU cache de 98 % à 80 % et créant trois mois de marge supplémentaire. L'isolation des pull‑requests a permis d'atteindre 100 % de lectures authentifiées pour le premier cohort en production. La protection contre la surcharge de Git a supporté 6,4 % de trafic supplémentaire, tout en améliorant le 95ᵉ percentile de durée de 24 % et le délai maximal de 78 %. Au niveau du trafic de lecture, les services migrés ont atteint 60,4 % de part, le monolithe 64,3 % en Azure, et les lectures Git 54 %.

Analyse des causes et mesures correctives

Les retours d'expérience ont conduit à trois axes majeurs : ajouter du headroom et activer l’autoscaling du maillage d’entrée, éviter toute réduction de capacité pendant les déploiements, et renforcer la surveillance des conditions de saturation et des proxys de bases de données. Des correctifs ont été déployés pour empêcher les runners de réessayer des jobs révoqués, et les limites de taux internes ont été relevées afin d’accélérer la vidange des files d’attente. Depuis le 21 août, la détection d’incidents à fort impact combine les signaux du support client avec la télémétrie du service, tandis que le monitoring API a été recalibré sur 30 jours, réduisant le bruit et améliorant la pertinence des alertes. Ces actions visent à réduire la probabilité de saturation lors de déploiements futurs et à accélérer la récupération en cas de panne.