Lassen Sie uns die AWS-Ereignisse als einige Operationen eines AIGC-Startup-SREs einfach zusammenfassen, in der Hoffnung, dass es allen helfen kann. Seit meinem Eintritt in das Unternehmen habe ich festgestellt, dass sich unsere Hauptcluster in USE1 befinden, und ich habe mit einigen Vorbereitungen begonnen. Die Hauptaufgaben, die ich erledigt habe, sind die folgenden: 1. Ich habe mehrere unserer Kern-Datenbanken an verschiedenen Standorten gesichert, sodass wir Backups in USE1, Tokio und SG haben. So verlieren wir im Extremfall einen Teil der Daten, können aber den Dienst weiterhin gewährleisten. 2. Ich habe unser Testcluster in SG von einem einfach selbst aufgebauten K3S auf EC2 in ein standardmäßiges AWS EKS-Cluster umgebaut. So können wir im Katastrophenfall schnell ein Cluster hochfahren und bestehende AWS-Komponenten wiederverwenden. Die Kosten für Änderungen am Manifest werden auf ein Minimum reduziert. 3. Ich habe ein einfaches SOP (Standard Operating Procedure) erstellt, das Benutzerankündigungen, DNS-Umschaltungen, Versionseinschränkungen usw. umfasst. Zurück zu heute: Ich habe etwa 10 Minuten nach dem Vorfall bei AWS festgestellt, dass wir in unseren Containern neue Pods haben, die nicht eingerichtet werden können. Nachdem ich mit dem AWS-Support bestätigt hatte, dass es ein Problem mit USE1 gibt, wurde mir klar, dass das ECR-Ereignis mit den anderen Ereignissen verbunden sein muss. Daher habe ich entschlossen, mit der Bearbeitung gemäß meinem eigenen geplanten Tier-1-Ereignis zu beginnen (für SREs gilt: Bei solchen Dingen lieber falsch handeln, als etwas zu verpassen). T+0 min: Ich habe eine Mitteilung an alle veröffentlicht und den Notfallmodus aktiviert. Ich habe ein öffentliches Meeting für alle eingerichtet, an dem alle jederzeit teilnehmen können. T+2 min: Ich habe bestätigt, dass das Ereignis wie erwartet zunimmt, und ich habe zwei Anweisungen gegeben: 1. Vollständiges Verbot von Code-Integrationen/Commits (hauptsächlich um zu vermeiden, dass neu erstellte Ressourcen Pods rotieren und den Datenverkehr beeinträchtigen), 2. Bitte bereiten Sie eine Ankündigung vor, liebe Betriebsmitarbeiter. T+3 min: Ich habe gemäß SOP mit der Wiederherstellung der Datenbanken in der SG-Region begonnen und abhängige Dienste wie OpenSearch/Redis usw. erstellt. T+5 min: Wir haben begonnen, die spezifischen Probleme der Abhängigkeiten zu bestätigen und festgestellt, dass ein neu eingeführter Kernservice betroffen ist. T+10 min: Wir haben die Mitteilung über die Dienstunterbrechung und die Mitteilung über die betroffenen Dienste veröffentlicht. T+10 min: Ich habe zwei weitere Kollegen gebeten, bei der Einrichtung eines neuen ECR zu helfen und die vorhandenen Ressourcen in der Testumgebung zu bereinigen, und ich habe den CTO informiert. Im Extremfall könnten wir Entscheidungen treffen, die die Benutzererfahrung bewahren, aber Daten verlieren. T+15 min: Wir haben schließlich bestätigt, dass die derzeit erstellten Ressourcen und die Richtung des Datenverkehrs nicht stark betroffen sind. Der Umschaltplan wurde ausgesetzt, aber wir bereiten weiterhin die entsprechenden Ressourcen vor. T+30 min: Unsere erste Datenbank wurde wiederhergestellt. T+40 min: Unsere zweite Datenbank wurde wiederhergestellt. T+1h: Alle unsere zugehörigen Kerninfrastrukturen, RDS/ES/Redis, sind im Standby-Modus und wir haben Optimierungsoptionen wie Master-Slave-Setups gemäß der Produktionsarchitektur eingerichtet. Gleichzeitig haben wir begonnen, neue Dienste in einem neuen Cluster zu starten. Glücklicherweise hat der AWS-Absturz unsere gesamten Dienste nicht beeinträchtigt. Wir mussten uns nicht mit der komplexen Datenwiederherstellung nach dem Umschalten des Datenverkehrs auseinandersetzen. Etwa T+2h bis T+3h später habe ich offiziell allen mitgeteilt, dass der Notfallstatus aufgehoben ist. Zur Sicherheit haben wir heute Abend weiterhin die Funktionen eingeschränkt. Rückblickend auf den gesamten Vorfall gibt es noch mehr, was ich hätte tun können: 1. Ich hätte das extreme Fall-SOP, das ich zuvor für mich selbst vorbereitet habe, allen zugänglich machen können. So wäre sichergestellt, dass, selbst wenn ich nicht online bin, jemand meine Aufgaben übernehmen kann. 2. Wir könnten einige vorzeitige Übungen durchführen. 3. Die Anweisungen könnten etwas entschlossener erteilt werden. Das ist ungefähr alles, eine kleine Teilung, ich hoffe, es kann allen helfen.

Eine gewagte Aussage Mit dem Aufkommen der AI-Ära wird der Code und die Architektur in einem noch nie dagewesenen Tempo kontinuierlich verfallen. Das wird bedeuten, dass Stabilität immer schwieriger zu erreichen ist. Viele zuvor ignorierte Details zur Stabilität und Best Practices werden in der AI-Ära verstärkt in den Vordergrund treten. Immer mehr Startups stoßen früher als erwartet auf ihre architektonischen Engpässe oder stehen vor der Rückzahlung ihrer technischen Schulden. Eine weitere Dimension der zunehmenden Schwierigkeiten bei der Stabilität ist, dass es immer weniger Menschen gibt, die Stabilität gewährleisten können. Und in einer Zeit, in der Vibe-Coding vorherrscht, gibt es immer weniger, die sich die Zeit nehmen, um Stabilität zu schaffen und die Kennzahlen zu erfüllen.