Es ist gut, die Statusseite aus Verfügbarkeitsgründen auf einer separaten Domain zu haben, aber es ist nicht besonders hilfreich, wenn diese Statusseite nicht aktualisiert wird, wenn die Kerndomain ausfällt
Solche Seiten werden überraschend oft manuell aktualisiert. Häufig macht das auch noch die On-Call-Person, die eigentlich dringendere Dinge zu erledigen hat
Vielleicht ist auch die Infrastruktur zum Aktualisieren der Statusseite mit ausgefallen
Es fühlt sich so an, als gäbe es solche Ausfälle fast alle zwei Wochen. Was ist in letzter Zeit eigentlich bei GitHub los?
Es wirkt, als würde man neue Funktionen wie Copilot hinzufügen, ohne genug in die Zuverlässigkeit der Website zu investieren
Wenn es keine Änderungen gibt, lässt sich ein System durch Bugfixes allein relativ stabil halten. Änderungen, also neue Funktionen, bringen neue Bugs und neue Last mit sich
Wahrscheinlich hat jemand vergessen, node_modules in .gitignore aufzunehmen
Vielleicht haben sich die Leute, die nicht zum Microsoft-Stil gepasst haben, inzwischen neue Jobs gesucht?
Testen sie gerade gpt4-ops?
Microsoft-Inkompetenz + DDoS?
Vielleicht ist es doch keine gute Idee, unser gesamtes Open Source an einem Ort zu bündeln >_<
Vielleicht besteht der einzige echte Unterschied irgendwann darin, dass man sich wünscht, lieber auf der anderen Seite zu sein
Intuitiv wirkt es besser, wenn 1 % des Ganzen zu 100 % der Zeit ausfällt, statt 100 % des Ganzen zu 1 % der Zeit, aber was davon in der Praxis wirklich nützlicher ist, weiß ich nicht. Spiegelung ist natürlich möglich, wenn man will, aber darum geht es hier eigentlich nicht
Der Punkt eines verteilten Versionsverwaltungssystems ist, dass jede Person mit einem git clone eine vollständige Kopie des gesamten Repositories hat und die meisten Arbeiten erledigen kann, ohne mit einem zentralen Server zu kommunizieren
Kurze Ausfälle betreffen meist eher die Infrastruktur rund um den eigentlichen Code, also Workflows, Issues usw.
Ehrlich gesagt ist es besser, wenn alles an einem Ort zusammenkommt. Es ist besser, wenn die ganze Branche gleichzeitig stillsteht, als wenn zufällige Leute zu zufälligen Zeiten betroffen sind
So ähnlich wie wenn us-east-1 ausfällt. Alle sitzen im selben Boot, also machen alle gleichzeitig Pause, und man hat eine gute Ausrede, sich kurz entspannt zurückzulehnen
Den gesamten Firmen-Code dort zu haben, ist eine gute Idee. Das sorgt für eine kostenlose Pause
Der eigentliche Kern von GitHub war nie Dezentralität. Als ich 2008 beigetreten bin, war es eher ein soziales Netzwerk für Entwickler
Scheint wieder da zu sein. Ich würde gern eine gründliche Analyse der jüngsten Ausfälle sehen und die Zusicherung hören, dass Stabilität Vorrang vor neuen Funktionen bekommt
Ich habe vor ein paar Monaten mit jemandem aus dem Support gesprochen, und dort wurde fast alles auf die vielen kundenspezifischen Anpassungen für große Kunden geschoben, die die Stabilität beeinträchtigen. Insgesamt wirkt es, als hätte sich eine enorme technische Schuld angesammelt
Um eine GitHub Enterprise-Instanz zu betreiben, braucht man ungefähr 64 GB RAM. Das Ding ist ein absolutes Monster
Solche Anpassungen können durchaus zu Fehlern oder dem Ausfall einzelner Funktionen führen. Aber dass die ganze Website ausfällt, insbesondere sogar statische Inhalte wie GH Pages, ist klar ein SRE-Problem
Wahrscheinlicher ist ein Problem beim Netzwerk-Routing oder ein anderer Fehler auf Schicht 4 oder darunter. Die meisten Änderungen an Anwendungen werden schrittweise und per Canary-Rollout ausgerollt, und wenn etwas schiefläuft, kann man ziemlich schnell zurückrollen
Dieser Ausfall scheint auch GitHub Pages zu betreffen. .github.io-Seiten zeigen die Unicorn-503-Seite an
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.
Wow, ich kann nicht einmal die Statusseite laden. Es wirkt, als sei das ganze Web ausgefallen, und ich kann mich nicht erinnern, wann zuletzt wirklich alles gleichzeitig down war
Bei mir öffnet sich die Statusseite, zeigt aber fälschlicherweise alles als normal an: https://www.githubstatus.com/
Was nutzt ihr, um euch gegen solche Probleme abzusichern? Einen Cache für Lesezugriffe hinzuzufügen, scheint sinnvoll zu sein und verbessert auch die Performance. Es wäre interessant, von Fällen zu hören, in denen jemand die Auswirkungen erfolgreich vermeiden konnte
In der „GitOps“-Konfiguration einer Organisation bei meinem früheren Arbeitgeber wurde GitLab nach AWS CodeCommit gespiegelt, und das wurde als Single Source of Truth für die Automatisierung verwendet
Diese Entscheidung hat sich mehrfach als klug erwiesen, und ich kann mich nicht erinnern, dass es jemals nennenswerte Probleme mit CodeCommit gab. Wenn man GitHub im eigentlichen Entwicklungsprozess aber als Forge nutzt und Dinge wie den Issue-Tracker oder PRs für Reviews verwendet, kenne ich ehrlich gesagt keinen guten Weg, sich davon unabhängig zu machen
Bei meinem früheren Arbeitgeber gab es ein lokal gehostetes GitHub Enterprise, und immer wenn auf Twitter alle schrieben „GitHub ist down! Heute Feierabend!“, war ich jedes Mal etwas neidisch :(
Klar, es war immer noch nervig, wenn irgendein Tool verlangte, Abhängigkeiten zu aktualisieren, die auf gewöhnlichem GitHub lagen, aber wenigstens liefen Deployment-bezogene Arbeiten weiter
Kaffeepause
git ist von Grund auf dafür gedacht, auch offline nutzbar zu sein, also verwende ich einfach die lokalen Klone, die ich bereits habe
Die Statusseite wurde gerade aktualisiert:
Investigating - We are currently experiencing an outage of GitHub products and are investigating.
Jun 29, 2023 - 17:52 UTC
Jetzt ist sogar Lesen komplett rot. Ich glaube, ich sehe zum ersten Mal auf einer Statusseite, dass alle Einträge rot sind
1 Kommentare
Hacker-News-Kommentare
https://downdetector.com/status/github/
Wenn es keine Änderungen gibt, lässt sich ein System durch Bugfixes allein relativ stabil halten. Änderungen, also neue Funktionen, bringen neue Bugs und neue Last mit sich
node_modulesin.gitignoreaufzunehmenIntuitiv wirkt es besser, wenn 1 % des Ganzen zu 100 % der Zeit ausfällt, statt 100 % des Ganzen zu 1 % der Zeit, aber was davon in der Praxis wirklich nützlicher ist, weiß ich nicht. Spiegelung ist natürlich möglich, wenn man will, aber darum geht es hier eigentlich nicht
git cloneeine vollständige Kopie des gesamten Repositories hat und die meisten Arbeiten erledigen kann, ohne mit einem zentralen Server zu kommunizierenKurze Ausfälle betreffen meist eher die Infrastruktur rund um den eigentlichen Code, also Workflows, Issues usw.
So ähnlich wie wenn us-east-1 ausfällt. Alle sitzen im selben Boot, also machen alle gleichzeitig Pause, und man hat eine gute Ausrede, sich kurz entspannt zurückzulehnen
Ich habe vor ein paar Monaten mit jemandem aus dem Support gesprochen, und dort wurde fast alles auf die vielen kundenspezifischen Anpassungen für große Kunden geschoben, die die Stabilität beeinträchtigen. Insgesamt wirkt es, als hätte sich eine enorme technische Schuld angesammelt
Wahrscheinlicher ist ein Problem beim Netzwerk-Routing oder ein anderer Fehler auf Schicht 4 oder darunter. Die meisten Änderungen an Anwendungen werden schrittweise und per Canary-Rollout ausgerollt, und wenn etwas schiefläuft, kann man ziemlich schnell zurückrollen
.github.io-Seiten zeigen die Unicorn-503-Seite anDiese Entscheidung hat sich mehrfach als klug erwiesen, und ich kann mich nicht erinnern, dass es jemals nennenswerte Probleme mit CodeCommit gab. Wenn man GitHub im eigentlichen Entwicklungsprozess aber als Forge nutzt und Dinge wie den Issue-Tracker oder PRs für Reviews verwendet, kenne ich ehrlich gesagt keinen guten Weg, sich davon unabhängig zu machen
Klar, es war immer noch nervig, wenn irgendein Tool verlangte, Abhängigkeiten zu aktualisieren, die auf gewöhnlichem GitHub lagen, aber wenigstens liefen Deployment-bezogene Arbeiten weiter
gitist von Grund auf dafür gedacht, auch offline nutzbar zu sein, also verwende ich einfach die lokalen Klone, die ich bereits habeInvestigating - We are currently experiencing an outage of GitHub products and are investigating.
Jun 29, 2023 - 17:52 UTC