C’est bien d’avoir une page de statut sur un domaine séparé pour des raisons de disponibilité, mais ne pas mettre à jour cette page quand le domaine principal tombe, c’est bof
Ce genre de page est mis à jour manuellement plus souvent qu’on ne le pense. Et c’est souvent fait par la personne d’astreinte, qui a déjà bien assez d’autres priorités
Il est possible que la tuyauterie qui sert à mettre à jour la page de statut soit elle aussi tombée
J’ai l’impression que ce genre de panne arrive presque toutes les deux semaines. Qu’est-ce qui se passe chez GitHub en ce moment ?
On dirait qu’ils ajoutent de nouvelles fonctionnalités comme Copilot sans investir suffisamment dans la fiabilité du site
S’il n’y a pas de changements, il est relativement facile de garder quelque chose stable en corrigeant juste les bugs. Les changements, c’est-à-dire les nouvelles fonctionnalités, apportent de nouveaux bugs et de nouvelles charges
Quelqu’un a dû oublier d’ajouter node_modules à .gitignore
Peut-être que ceux qui n’étaient pas compatibles avec la gestion à la Microsoft ont trouvé un nouveau boulot ?
Ils testent gpt4-ops ?
Incompétence de Microsoft + DDoS ?
Ce n’est peut-être pas une bonne idée de regrouper tout notre open source au même endroit >_<
En pratique, la seule différence est peut-être qu’à un moment on se met à souhaiter être « de l’autre côté »
Intuitivement, 1 % de l’ensemble en panne 100 % du temps semble préférable à 100 % de l’ensemble en panne 1 % du temps, mais je ne sais pas vraiment ce qui est le plus pratique en réalité. Bien sûr, on peut faire du mirroring si on le veut, mais ce n’est pas le cœur du sujet puisque c’est déjà possible aujourd’hui
L’intérêt d’un système de gestion de versions distribué, c’est que toute personne ayant fait un git clone possède une copie complète du dépôt et peut effectuer la plupart des tâches sans communiquer avec un serveur central
Une courte panne affecte surtout l’infrastructure autour du code lui-même, c’est-à-dire le workflow, les issues, etc.
Honnêtement, c’est mieux quand tout est centralisé. Il vaut mieux que tout le secteur s’arrête en même temps plutôt que des personnes aléatoires à des moments aléatoires
C’est comme quand us-east-1 tombe. Tout le monde est dans le même bateau, donc tout le monde fait une pause en même temps, et on a une excuse parfaitement valable pour lever un peu le pied
Mettre tout le code de l’entreprise là-dessus, c’est une bonne idée. Ça donne des pauses gratuites
L’argument de vente principal de GitHub n’a jamais été la distribution. Quand je me suis inscrit en 2008, c’était davantage un réseau social où les développeurs se retrouvaient
On dirait que c’est revenu. J’aimerais voir une analyse approfondie des pannes récentes et être rassuré sur le fait que la stabilité passera avant les nouvelles fonctionnalités
J’ai parlé il y a quelques mois avec quelqu’un du support client, et il mettait presque la faute sur toutes les personnalisations faites pour les gros clients, en disant que cela nuisait à la stabilité. Au final, ça donne l’impression d’une énorme dette technique accumulée
Faire tourner une instance de GitHub Enterprise demande dans les 64 Go de RAM. C’est un monstre absolu
Ce genre de personnalisations peut provoquer des erreurs ou des défaillances partielles de certaines fonctionnalités. Mais une panne complète du site, en particulier si même du contenu statique comme GH Pages tombe, c’est entièrement un problème SRE
Il est plus probable qu’il s’agisse d’un problème de routage réseau ou d’une autre erreur au niveau de la couche 4 ou en dessous. La plupart des changements applicatifs sont déployés progressivement avec rolling deployments et canary deployments, et s’il y a un souci on peut généralement rollback assez vite
Cette panne semble aussi affecter GitHub Pages. Les pages en .github.io affichent la page licorne 503
We're having a really bad day.
The Unicorns have taken over. We're doing our best to get them under control and get GitHub back up and running.
Waouh, je n’arrive même pas à charger la page de statut. On dirait que tout le web est tombé, et je ne me souviens même plus de la dernière fois où tout a été complètement indisponible comme ça
Qu’utilisez-vous pour vous isoler de ce type de problème ? Ajouter un cache pour les lectures semble judicieux et améliore aussi les performances. Si quelqu’un a réussi à éviter l’impact, je serais curieux d’avoir un retour
Dans mon ancien travail, la configuration « GitOps » d’une organisation répliquait GitLab vers AWS CodeCommit et s’en servait comme source unique de vérité pour l’automatisation
Cette décision s’est révélée judicieuse à plusieurs reprises, et je ne me souviens pas de problèmes notables sur CodeCommit. En revanche, si votre vrai processus de développement utilise GitHub comme forge, avec l’issue tracker et les PR pour la revue, je ne vois pas vraiment de bonne manière de s’en isoler
Dans mon précédent poste, on avait un GitHub Enterprise hébergé en local, et chaque fois que tout le monde sur Twitter disait « github est down ! on finit plus tôt aujourd’hui ! », j’étais toujours dégoûté :(
Bien sûr, c’était encore pénible quand un outil demandait de mettre à jour des dépendances présentes sur le GitHub public, mais au moins tout ce qui touchait aux déploiements continuait de fonctionner
Pause café
git est à l’origine un outil conçu pour fonctionner aussi hors ligne, donc j’utilise simplement les clones locaux que j’ai déjà
La page de statut vient de changer :
Investigating - We are currently experiencing an outage of GitHub products and are investigating.
Jun 29, 2023 - 17:52 UTC
Même la lecture est en rouge. Je crois que c’est la première fois que je vois tous les éléments en rouge sur une page de statut
1 commentaires
Avis sur Hacker News
https://downdetector.com/status/github/
S’il n’y a pas de changements, il est relativement facile de garder quelque chose stable en corrigeant juste les bugs. Les changements, c’est-à-dire les nouvelles fonctionnalités, apportent de nouveaux bugs et de nouvelles charges
node_modulesà.gitignoreIntuitivement, 1 % de l’ensemble en panne 100 % du temps semble préférable à 100 % de l’ensemble en panne 1 % du temps, mais je ne sais pas vraiment ce qui est le plus pratique en réalité. Bien sûr, on peut faire du mirroring si on le veut, mais ce n’est pas le cœur du sujet puisque c’est déjà possible aujourd’hui
git clonepossède une copie complète du dépôt et peut effectuer la plupart des tâches sans communiquer avec un serveur centralUne courte panne affecte surtout l’infrastructure autour du code lui-même, c’est-à-dire le workflow, les issues, etc.
C’est comme quand us-east-1 tombe. Tout le monde est dans le même bateau, donc tout le monde fait une pause en même temps, et on a une excuse parfaitement valable pour lever un peu le pied
J’ai parlé il y a quelques mois avec quelqu’un du support client, et il mettait presque la faute sur toutes les personnalisations faites pour les gros clients, en disant que cela nuisait à la stabilité. Au final, ça donne l’impression d’une énorme dette technique accumulée
Il est plus probable qu’il s’agisse d’un problème de routage réseau ou d’une autre erreur au niveau de la couche 4 ou en dessous. La plupart des changements applicatifs sont déployés progressivement avec rolling deployments et canary deployments, et s’il y a un souci on peut généralement rollback assez vite
.github.ioaffichent la page licorne 503Cette décision s’est révélée judicieuse à plusieurs reprises, et je ne me souviens pas de problèmes notables sur CodeCommit. En revanche, si votre vrai processus de développement utilise GitHub comme forge, avec l’issue tracker et les PR pour la revue, je ne vois pas vraiment de bonne manière de s’en isoler
Bien sûr, c’était encore pénible quand un outil demandait de mettre à jour des dépendances présentes sur le GitHub public, mais au moins tout ce qui touchait aux déploiements continuait de fonctionner
gitest à l’origine un outil conçu pour fonctionner aussi hors ligne, donc j’utilise simplement les clones locaux que j’ai déjàInvestigating - We are currently experiencing an outage of GitHub products and are investigating.
Jun 29, 2023 - 17:52 UTC