{"id":12793,"date":"2021-03-14T20:36:01","date_gmt":"2021-03-14T19:36:01","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=12793"},"modified":"2023-06-18T18:03:29","modified_gmt":"2023-06-18T16:03:29","slug":"black-swans-in-it-systemen-und-ausfalle-2020","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2021\/03\/14\/black-swans-in-it-systemen-und-ausfalle-2020\/","title":{"rendered":"Black Swans in IT-Systemen und Ausf\u00e4lle 2020"},"content":{"rendered":"\n
\"\"<\/a><\/figure>\n\n\n\n

Seit \u00fcber einem Jahr sorgt die Coronapandemie f\u00fcr t\u00e4gliche Berichterstattung und vielerlei Einschr\u00e4nkungen. Kontakte werden auf ein Minimum begrenzt, Gastronomien und Gro\u00dfteile des Einzelhandels geschlossen und Freizeit- sowie Kulturveranstaltungen abgesagt. Mehr Zeit als je zuvor verbringen die Menschen in ihren eigenen vier W\u00e4nden und nutzen IT-Systeme, um im Home-Office zu arbeiten, \u00fcber Lernplattformen zu lernen oder durch Videokonferenzsysteme soziale Kontakte herzustellen. Auch die daf\u00fcr ben\u00f6tigten, cloudbasierten IT-Systeme erfahren dadurch Auslastungen, die zuvor nur schwer vorstellbar waren. Dieser Mehraufwand und die daf\u00fcr erforderliche Skalierung der Systeme, sorgte im vergangenen Jahr 2020 f\u00fcr Ausf\u00e4lle (Outages), von welchen auch die “Big-Player” des Cloud-Computings nicht verschont blieben. Einer Microsoft Azure Einschr\u00e4nkung im M\u00e4rz folgte im November der Ausfall einiger AWS-Dienste des Cloud-Marktf\u00fchrers Amazon, ehe im Dezember zahlreiche Google-Dienste wie YouTube oder GoogleDrive f\u00fcr einige Stunden unerreichbar waren. M\u00f6gliche Ursachen solcher Ausf\u00e4lle wurden bereits 2018 in Laura Nolans USENIX-Konferenzbeitrag “What Breaks Our Systems: A Taxonomy of Black Swans”<\/a> thematisiert und in sechs Muster kategorisiert [2]. Der folgende Blogbeitrag stellt diese Kategorien, die Ursachen schwarzer Schw\u00e4ne in IT Systemen dar (Seite 1<\/a>), ordnet einige Ausf\u00e4lle aus dem vergangenen Jahr in diese ein (Seite 2<\/a>) und zeigt m\u00f6gliche Pr\u00e4ventionsma\u00dfnahmen auf (Seite 3<\/a>).<\/p>\n\n\n\n\n\n\n\n

Black Swans in IT-Systemen<\/h2>\n\n\n\n

Black-Swan-Ereignisse wurden bereits 2007 von Nassim Nicholas Taleb im Buch “The Black Swan: The Impact of the Highly Improbable<\/em>” [4]<\/a> beschrieben und sind unvorhersehbare Ereignisse mit potenziell schwerwiegenden Folgen. Au\u00dferdem zeichnen sich diese durch ihre extreme Seltenheit und die weit verbreitete Denke aus, dass sie im Nachhinein offensichtlich waren. Bekannte Beispiele f\u00fcr Black-Swan-Ereignisse au\u00dferhalb der Informationstechnologie sind 9\/11, die Bankenkrise 2008 oder, als aktuellstes Beispiel, auch die Coronapandemie. All diese Ereignisse waren so nicht vorhersehbar, hatten bzw. haben schwerwiegende Folgen und sind im Nachhinein – trotz der Seltenheit des einzelnen Ereignisses – eigentlich offensichtlich. Mit diesen Zusammenh\u00e4ngen und Mustern im Kontext gro\u00dfer, verteilter IT-Systeme, besch\u00e4ftigt sich Laura Nolan und definierte an der USENIX-Konferenz 2018 folgende Muster f\u00fcr schwerwiegende Ausf\u00e4lle:<\/p>\n\n\n\n

Hitting Limit<\/strong><\/p>\n\n\n\n

Hitting Limit umschreibt Fehler, die durch Erreichen einer bestimmten Kapazit\u00e4t dazuf\u00fchren, dass die Systeme ausfallen. Limits in Ultra-Large-Scale (ULS) Systemen k\u00f6nnen System-Ressourcen (z.B. RAM, Speicher etc.), logische Ressourcen (z.B. Puffergr\u00f6\u00dfen) oder auch von Dateisystemen oder Providern definierte Limits sein (siehe Beispiel Instapaper 2017 [5]<\/a>). Diese Limits gibt es an allen m\u00f6glichen Stellen und es handelt sich dabei sehr oft um harte Limits, die oft nur schwer zu erweitern und manchmal auch unbekannt sind, weshalb diese Art der Ursache immer wieder zu Ausf\u00e4llen der komplexen Systeme f\u00fchrt.<\/p>\n\n\n\n

Spreading Slowness<\/strong><\/p>\n\n\n\n

Spreading Slowness (dt. Ausbreitungsverz\u00f6gerung) beschreibt einen Ausfall des Systems durch verlangsamtes Verarbeiten von Aufrufen einer Ressource, die dann in der Masse dazuf\u00fchren, dass das System kollabiert. Spreading Slowness kann demnach auch als ungeplante Slowloris-Attacke – z.B. 2009 bei den Pr\u00e4sidentschaftswahlen im Iran durchgef\u00fchrt [6]<\/a> – bezeichnet werden. Bei dieser DoS-Attacke (Denial of Service) werden Webserver durch kontinuierliche und parallele HTTP-Anfragen, die niemals abgeschlossen werden, lahmgelegt. H\u00e4ufig treten Spreading-Slowness Probleme in Verbindung mit Microservices auf, wodurch Ausf\u00e4lle von einzelnen Microservices, Spreading Slownes anderer Dienste herbeif\u00fchren (z.B. Spotify 2013 [7]<\/a>). Spreading-Slowness ist dabei nicht auf die Anfragen eines Dienstes beschr\u00e4nkt und kann auch zwischen den verschiedenen Diensten eines Systems auftreten.<\/p>\n\n\n\n

Thundering Herds<\/strong><\/p>\n\n\n\n

Thundering Herds (dt. Donnernde Herde) dr\u00fcckt den Zustand aus der entsteht, wenn in kurzer Zeit eine zu hohe Anzahl an Anfragen auf eine Ressource treffen und diese dadurch \u00fcberlasten. Diese Art des Fehlers kann nahezu jeden Internetdienst betreffen, da es nie vorherzusehen ist, welche Anzahl an Anfragen zeitgleich auf einem System eintreffen. Bekannte Thundering Herds Beispiele sind Web-Shops, die eine gro\u00dfe Anzahl an Besuchern zeitgleich aufrufen und dadurch \u00fcberlasten (z.B. Black-Friday oder Neuerscheinungen im Shop). Oft kommen Thundering Herds jedoch nicht nur durch die gro\u00dfe Anzahl der Benutzer oder Besucher eines Systems zu Stande, sondern auch durch die Systeme selbst. Beispiele hierf\u00fcr sind gro\u00dfe Batch-Jobs, die automatisiert ablaufen (z.B. MapReduce) oder Abh\u00e4ngigkeiten andere Dienste die – wie im Beispiel CircleCI 2015 [8]<\/a> – dazuf\u00fchren, dass Thundering Herds nach Zur\u00fcckkehren eines zuvor ausgefallenen Dienstes auftreten.<\/p>\n\n\n\n

Automation Interactions<\/strong><\/p>\n\n\n\n

Automatisierung ist ein zentraler Bestandteil aller Ultra Large Scale (ULS) Systeme und findet in vielerlei Bereichen der komplexen, verteilten System – oft im Zusammenspiel mit k\u00fcnstlichen Intelligenzen und Machine Learning – Verwendung. Automatisierte Skalierung der Serverressourcen in einer Cloud ist dabei genauso \u00fcblich, wie Netzwerk-Automatisierungen oder automatisierte Wartungsereignisse in Rechenzentren. F\u00fchren solche Automatisierungen zu einem Ausfall des Systems, f\u00e4llt dies in die Unterkategorie der Automation Interactions. Diese Kategorie ist aufgrund der h\u00e4ufigen Automatisierung in ULS-Systemen auch im Zusammenspiel anderer Kategorien h\u00e4ufig Mitausl\u00f6ser eines Black-Swans. So z.B. auch bei einem Reddit Outage 2016 [9]<\/a>, wodurch ein automatisierter Start des AutoScalers bei einer Zookeeper Migration zu einem 90-min\u00fctigen Ausfall f\u00fchren sollte.<\/p>\n\n\n\n

Cyberattacks<\/strong><\/p>\n\n\n\n

Sorgen Hacker oder andere Angreifer von au\u00dferhalb daf\u00fcr, dass ein gesamtes System ausf\u00e4llt, ist von Cyberattacks die Rede. Diese nutzen Schwachstellen der Informationssicherheit (Sicherheit der Systeme gegen externe Bedrohungen), um sich Zugriff zu einem System zu verschaffen, weiten diesen Zugriff aus und gef\u00e4hrden so das gesamte System. G\u00e4ngige Attacke sind Denial of Service (DoS) Attacken, die gesamte Infrastrukturen lahmlegen oder Schadsoftware die – wie am Beispiel Emotet [10] <\/a>– Zugriffe \u00fcber ein gesamtes System erlangt, dieses verschl\u00fcsselt und die Opfer anschlie\u00dfend mit der Entschl\u00fcsselung erpresst.<\/p>\n\n\n\n

Dependency Problems<\/strong><\/p>\n\n\n\n

Wachsen Systeme \u00fcber einen langen Zeitraum, sind Abh\u00e4ngigkeiten zwischen einzelnen Teilsystemen kaum zu vermeiden. F\u00fchren solche Abh\u00e4ngigkeiten, beispielsweise bei einem “Reboot from Scratch” zu Problemen und einem Ausfall des Systems, ist dies in die Kategorie Dependency Problems einzuordnen. Beispiele hierf\u00fcr sind Abh\u00e4ngigkeiten zwischen Speicher und Monitoring oder – wie im Beispiel GitHub 2016 [11]<\/a> – Abh\u00e4ngigkeiten zwischen Redis-Clustern (Remote Dictionary Server Cluster f\u00fcr Caching, Sitzungen etc.) und dem Data Center. Ein, durch einen Stromausfall notwendiger, Neustart f\u00fchrte aufgrund der vorhandenen Abh\u00e4ngigkeit zu einem 2-st\u00fcndigen Ausfall GitHubs, da das Data Center durch die vorhandene Abh\u00e4ngigkeit zu den ebenfalls heruntergefahrenen Redis-Clustern nicht mehr korrekt hochgefahren werden konnte.<\/p>\n\n\n\n

Wie weitreichende IT-Systemausf\u00e4lle aus dem vergangenen Jahr zu Stande kamen und wie diese in die beschriebenen Muster eingeordnet werden k\u00f6nnen, wird auf Seite 2<\/a> des Blogeintrags beschrieben.<\/p>\n\n\n\n\n\n\n\n

Ausf\u00e4lle 2020<\/h2>\n\n\n\n

Wie bereits dargestellt, hatten nicht nur die Menschen, sondern auch die ULS-Systeme erh\u00f6hte Belastungen durch die Pandemie. So stiegen t\u00e4glicher Nutzerzahlen bekannter Videokonferenzsysteme wie Microsoft Teams (75 Mio auf 115 Mio) oder Zoom (10 Mio auf 300 Mio) innerhalb weniger Monate rapide an und sorgen f\u00fcr eine dementsprechend kurzfristig notwendige Skalierung. Auch auf Kollaborationstools wie Slack oder g\u00e4ngige Cloud Anbieter wie AWS, Microsoft Azure oder Google wirkte sich dieser Nutzerzuwachs aus, weshalb es im vergangenen Jahr vermehrte Ausf\u00e4lle verschiedener ULS-Systeme gab. Diese Ausf\u00e4lle werden von den betroffenen Unternehmen in sogenannten “Post-Mortem”-Berichten beschrieben und analysiert. Vier dieser Berichte des Jahres 2020 werden im Folgenden zusammengefasst und in die zuvor beschriebenen Muster eingeordnet.<\/p>\n\n\n\n

Azure – M\u00e4rz 2020<\/h3>\n\n\n\n

Zu erheblichen Problemen in Europa und Gro\u00dfbritannien kam es f\u00fcr die Benutzer der Microsoft Cloud-Computing-Plattform Azure zwischen dem 24. und 26. M\u00e4rz 2020. Durch die Lockdowns und das stark ansteigende Home-Office in Europa, nahm die Anfrage virtueller Windows und Linux Maschinen (VMs) derart zu, dass es bei den zu verarbeitenden Pipeline-Jobs, die dem Benutzer eine VM zur Verf\u00fcgung stellen, zu erheblichen Verz\u00f6gerungen von bis zu 9 Stunden kam. Jeder dieser Pipeline-Jobs stellt in der Regel eine neue, virtuelle Maschine aus dem gehosteten Agent-Pool bereit. Diese Anzahl der bereitzustellenden VMs stieg w\u00e4hrend der Rush-Hours auf ca. 30.000 Anfragen pro Stunde, wodurch das maximale Limit des Agent-Pools erreicht wurde. Da bei einer fehlerhaften Zuweisung jedoch versucht wurde, die Zuweisung erneut durchzuf\u00fchren, verlangsamte sich die Zeit des Hochfahrens eines neuen Agents im Pool erheblich. Die Gesamtzahl der Agenten im Pool war zu gering, um die Anzahl der Anfragen zu bedienen, trotzdem wurde aber weiterhin versucht, VMs bereitzustellen. Dies wiederum f\u00fchrte zu Warteschlangen und der beschriebenen Pipeline-Verz\u00f6gerung, welche erst nach 2 Tagen und durch folgende Anpassungen beseitigt wurde.<\/p>\n\n\n\n

Durch die Verwendung von ephemeren OS-Disks, die bei Linux VMs zuk\u00fcnftig die VM-Allocations-\/Deallocation Operationen pro Pipeline-Job durch eine Re-Image-Operation ersetzen, wurde dieses Problem bei Linux VMs behoben. Da dies bei Windows VMs so nicht m\u00f6glich ist, wurden hier gr\u00f6\u00dferer Azure-VMs und verschachtelte Virtualisierungen eingef\u00fchrt, um die erh\u00f6hte Nachfrage zu bew\u00e4ltigen. Jedoch zeigt der Ausfall die Wichtigkeit von Monitoring und wie die von Laura Nolan beschriebenen Muster auch in Kombination dazuf\u00fchren, dass Systeme ausfallen. Das Erreichen der VM-Kapazit\u00e4t (Hitting Limit) f\u00fchrte durch dann Auftretendes Thundering Herds zum verlangsamten Hochfahren der Agents (Spreading Slowness), die wiederum das gesamte System \u00fcber Tage beeintr\u00e4chtigten.<\/p>\n\n\n\n

Mehr Infos zum Outage: Azure Post-Mortem Bericht [14]<\/a><\/p>\n\n\n\n

Slack – Mai 2020<\/h3>\n\n\n\n

Als “Terrible, Horrible, No-Good, Very Bad Day” beschreibt die Kollaborationsplattform Slack den 12.05.2020, welcher einen stundenlangen Ausfall der Plattform herbeif\u00fchren sollte. Grund daf\u00fcr war ein Bug in der von Slack entwickelten Schnittstelle (server-state-management), welche die Synchronisation zwischen Hostliste und den HAProxy (High Availability Proxy) Instanzen steuert (siehe Abbildung 2). Diese HAProxy Instanzen (auf verschiedene AWS Availability Zones verteilt) sind Slots, die wiederum durch WebApp Instanzen belegt werden, um je nach Bedarf mit Auto-Scaling zu Skalieren. Durch das vervielfachte Home-Office, sowie einer am Vormittag durchgef\u00fchrte und innerhalb kurzer Zeit zur\u00fcckgerollten Konfigurations\u00e4nderung, trat ein hoher Bedarf an WebApp Instanzen auf, wodurch dieser Bug zum gro\u00dfen Problem werden sollte. Durch fehlerhafte Programmlogik der Schnittstelle versuchte diese zuerst einen Slot f\u00fcr neue Webapp-Instanzen zu finden, ehe sie veraltete Slots freigab, die von nicht mehr laufenden Webapp-Instanzen belegt waren. Dieser Bug trat bis zu diesem “Terrible, Horrible Day” nicht auf, da in allen Phasen des Auto-Scalings freie Slos verf\u00fcgbar waren. Durch den erh\u00f6hten Traffic f\u00fchrte dies zur vollst\u00e4ndigen Belegung alle verf\u00fcgbaren Instanzen und die laufenden HAProxy-Instanzen konnten ihren Status nicht aktualisieren. Dadurch wurde die Liste der Backends im HAProxy-Status immer \u00e4lter und f\u00fchrte am Nachmittag, als durch das AutoScaling weitere, noch nicht veraltete Slots reduziert wurden, zum Ausfall. <\/p>\n\n\n\n

Durch einen Neustart der HAProxies wurde das Problem zwar schnell behoben, jedoch h\u00e4tte daf\u00fcr vorgesehenes Monitoring, welches ebenfalls nicht geplant funktionierte, diesen Ausfall verhindern m\u00fcssen. Auch an diesem Fall zeigt sich, dass die Kombination aus Black-Swan-Mustern h\u00e4ufig f\u00fcr Ausf\u00e4lle der IT-Systeme verantwortlich ist. Im Beispiel Slack wird das Limit der maximalen WebApp Instanzen erreicht (Hitting Limit) und f\u00fchrt dazu, dass ein Bug den eigentlichen Ausfall ausl\u00f6st. Das AutoScaling, welches die letzten verf\u00fcgbaren und nicht veralteten Slots am Nachmittag reduzierte, sollte dann zum Ausfall des bis dahin schon beeintr\u00e4chtigen Systems f\u00fchren (Autonomous Interactions).<\/p>\n\n\n\n

Mehr Infos zum, ebenfalls von Laura Nolan ver\u00f6ffentlichten, Outage-Bericht: Slack Post-Mortem [15]<\/a><\/p>\n\n\n\n

\"\"<\/a>
Abbildung 2 [15]: Die Grafik zeigt das Ergebnis des Bugs, also die veralteten WebApp-Instanzen, die in den Slots den HAProxy Slots und den Host-Lists nicht aktualisiert wurden und am Nachmittag zum Ausfall des Systems f\u00fchrten.<\/figcaption><\/figure>\n\n\n\n

AWS – November 2020<\/h3>\n\n\n\n

Auch Cloud-Marktf\u00fchrer AWS blieb von Vorf\u00e4llen im Jahr 2020 nicht verschont und musste einen gravierenden Outage (ca 17 Stunden) vieler AWS Dienste am 26. November hinnehmen. Grund daf\u00fcr war eine Kapazit\u00e4tserweiterung der Front-End-Fleets einiger Kinesis-Server, die die Echtzeitverarbeitung von gro\u00dfen Streams bei AWS erm\u00f6glichen. Diese Server werden von vielen AWS-Services (z.B. DynamoDB, EC2, Aurora, Cognito ) f\u00fcr die Verarbeitung der Streams verwendet, wodurch AWS-Kunden wie Autodesk, AdobeSpark oder Flickr durch den Ausfall nicht uneingeschr\u00e4nkt verf\u00fcgbar waren. Das Front-End des Kinesis-Servers \u00fcbernimmt dabei die Authentifizierung sowie die Drosselung und verteilt den Workload der Stream-Verarbeitung \u00fcber einen Datenbankmechanismus (Sharding) auf einem Back-End-Cluster. Dieses Back-End-Cluster sind die “Workhorses” des Kinesis-Dienstes und sorgen f\u00fcr die Verteilung, den Zugriff und die Skalierbarkeit der Stream Verarbeitung. F\u00fcr die Kommunikation zwischen den Servern erstellt jeder Front-End-Server Threads, die f\u00fcr jeden anderen Server in der Front-End-Fleet auf den Servern angelegt werden. Bei jeder Kapazit\u00e4tserweiterung erfahren die Server, die bereits Mitglieder der Fleet sind, dass neue Server hinzukommen und richten die entsprechenden Threads ein. Durch das Erweitern zus\u00e4tzlicher Server in den Front-End-Fleets wurde die maximale Anzahl Threads, die die Betriebssystemkonfiguration zulie\u00df, \u00fcberschritten. Dadurch konnte der Cache der Front-End-Server nicht korrekt gebildet werden, wodurch die Server nutzlose Shardmaps speicherten. Dadurch wurde es f\u00fcr die Front-End-Server wiederum unm\u00f6glich, Anfragen an die Back-End-Cluster weiterzuleiten, wodurch die “Workhorses” keine Streams mehr verarbeiten konnten und die Kineses-Dienste nicht mehr funktionierten. <\/p>\n\n\n\n

Die zus\u00e4tzliche Front-Fleet-Kapazit\u00e4t wurde zur L\u00f6sung des Problems anschlie\u00dfend wieder entfernt, wodurch die die Caches wieder korrekt gebildet werden konnten. Die betroffenen AWS Dienste erholten sich nach und nach und waren nach ca. 17 Stunden wieder vollst\u00e4ndig verf\u00fcgbar. Durch dass Ausl\u00f6sen der Thread-Grenze des Betriebssystem, kann dieser Ausfall der Kategorie “Hitting Limit” zugeordnet werden.<\/p>\n\n\n\n

Mehr Infos zum Ausfall: <\/a>Summary of the Amazon Kinesis Event in the Northern Virginia (US-EAST-1) Region<\/a><\/p>\n\n\n\n

Google – Dezember 2020<\/h3>\n\n\n\n

Nur 3 Wochen nachdem mit AWS ein “Big-Player” der Cloud Anbieter die beschriebenen Kinesis-Probleme hatte, legte auch Internetrie\u00dfe Google nach und vermeldete am 14. Dezember einen knapp einst\u00fcndigen Ausfall vieler seiner Dienste (u.a. YoutTube, Gmail, GoogleDrive). Verantwortlich daf\u00fcr waren Probleme mit Googles User-ID-Service, der die Authentifizierungsdaten f\u00fcr Tokens (OAuth-Tokens) und Cookies verwaltet und dabei Anfragen ablehnt, wenn veraltete Daten festgestellt werden. Eine Migration dieses User-ID-Services auf ein neues Quota-System, f\u00fchrte hier durch die automatisierte Ressourceverwaltung Googles zum Fehler. Da ein Teil des Services auf dem alten System bestehen blieb, wurde von diesem alten System f\u00e4lschlicherweise ein Quota = 0 durch Googles automatisierte Ressourceverwaltung festgelegt, da auf diesem System keine Anfragen eingingen. Dienste mit Quota = 0 hindern den Paxos-Leader, der \u00fcber das gleichnamige Paxos-Protokoll die Aktualisierung der Kontodaten steuert, neue Daten zu \u00fcbermitteln. Dadurch erkannte die Mehrzahl der Leseoperationen veraltete Daten, was wie beschrieben, zur Ablehnung der Anfragen f\u00fchrte. Der User-ID-Service konnte dadurch nicht angefragt und die Dienste, die diesen ben\u00f6tigen, demnach nicht zur Verf\u00fcgung gestellt werde. <\/p>\n\n\n\n

Das Problem wurde von Google dadurch gel\u00f6st, dass die automatisierte Quota-Erzwingung deaktiviert und der Dienst dadurch wiederhergestellt werden konnte. Da diese automatisierte Ressourceverwaltung f\u00fcr den Service-Ausfall verantwortlich ist, kann der Ausfall dem Muster Automation Interactions zugeordnet werden.<\/p>\n\n\n\n

Mehr Infos zum Outage: Google Cloud Infrastructure Components Incident #20013<\/a><\/p>\n\n\n\n

\u00dcbersicht<\/h3>\n\n\n\n

Folgende \u00dcbersicht ordnet die beschriebenen Ausf\u00e4lle in die sechs von Laura Nolan definierten Muster der Black-Swans ein:<\/p>\n\n\n\n

<\/td>Hitting
Limit<\/td>		Spreading
Slowness<\/td>		Thunder.
Herds<\/td>		Autom.
Interact.<\/td>		Cyber
Attacks<\/td>		Depend.
Problems<\/td><\/tr>
Azure<\/td>X<\/td>X<\/td>X<\/td><\/td><\/td><\/td><\/tr>
Slack<\/td>X<\/td><\/td><\/td>X<\/td><\/td><\/td><\/tr>
AWS<\/td>X<\/td><\/td><\/td><\/td><\/td><\/td><\/tr>
Google<\/td><\/td><\/td><\/td>X<\/td><\/td><\/td><\/tr><\/tbody><\/table>
Tabelle 1: Outages 2020 und Einordnung in die Black-Swan-Muster der IT-Systeme<\/figcaption><\/figure>\n\n\n\n

<\/p>\n\n\n\n

Nach diesen Mustern geordnete Pr\u00e4ventionsma\u00dfnahmen, um solche Black-Swans in IT-Systemen zu vermeiden, werden auf Seite 3<\/a> des Blogeintrags thematisiert.<\/p>\n\n\n\n\n\n\n\n

Pr\u00e4ventionsma\u00dfnahmen<\/h2>\n\n\n\n

Auch wenn Black-Swans nach Definition unvorhersehbare Ereignisse sind, kann mit bestimmten Prozessen oder Ma\u00dfnahmen gegen solche Ausf\u00e4lle vorgegangen werden. Die beschriebenen Muster k\u00f6nnen dabei helfen pr\u00e4ventiv entgegenzuwirken, da je nach Ursache und Muster eines Ausfalls \u00e4hnliche M\u00f6glichkeiten zur Vermeidung existieren. <\/p>\n\n\n\n

Betrachtet man die Muster der Ausf\u00e4lle in 2020 f\u00fchrt in drei der vier F\u00e4lle das Erreichen einer Kapazit\u00e4t (Hitting Limit<\/strong>) zum Ausfall. Hier kann eine \u00dcberschreitung durch umfangreiches Monitoring sowie ein Monitoring-Alert, also ein Alarm beim Erreichen bestimmter Kapazit\u00e4ten, vor der Beeintr\u00e4chtigung des Systems festgestellt werden. Dies h\u00e4tte sowohl beim AWS Thread Limit, als auch bei Azures VM-Pool zu einer vorzeitigen Erkennung des Problems gef\u00fchrt und den Ausfall durch dann getroffene Ma\u00dfnahmen verhindert. Auch bei Slack h\u00e4tte funktionierendes Monitoring, wie bereits beschrieben, den Ausfall des Systems verhindert, da der Bug dadurch fr\u00fchzeitiger erkannt worden w\u00e4re. Zus\u00e4tzlich helfen Last- und Kapazit\u00e4tstests die bis dahin unbekannte Limits eines Systems \u00fcberhaupt erst zu erkennen. Als weitere Ma\u00dfnahme kann durch ausgepr\u00e4gte und einheitliche Dokumentationen vermieden werden, dass Limits ignoriert werden. So bleibt das Wissen \u00fcber Limits auch bei Ver\u00e4nderungen der Systemverantwortlichkeiten bestehen und kann dann beachtet werden.<\/p>\n\n\n\n

Um Ausf\u00e4lle aufgrund von Spreading Slowness<\/strong> zu vermeiden, ist wiederum “Failing-Fast” der Teilsysteme das Stichwort, um Ausf\u00e4lle des gesamten Systems zu verhindern. Wenn Systeme mit einer riesigen Warteschlange von Anfragen vorliegen und die Puffer voll sind, ist das gef\u00e4hrlich f\u00fcr das gesamte System. Die dadurch entstehenden, blockierten Systeme sind nur schwer zu entwirren, um wieder einen betriebsf\u00e4higen Zustand herzustellen. Dies zeigte sich auch am Beispiel Azure, welches durch Failing Fast des Dienstes ab dem Zeitpunkt der Kapazit\u00e4tsgrenze die gesamte Verlangsamung des Systems verhindern h\u00e4tten k\u00f6nnen. Nur die VM-Anfragen nach Erreichen der Kapazit\u00e4t w\u00e4ren demnach fehlerhaft gewesen. Au\u00dferdem sind Deadlines f\u00fcr Anfragen sowohl bei Zugriffen auf das System, als auch f\u00fcr die Kommunikation zwischen Microservices eine M\u00f6glichkeit, Spreading Slowness pr\u00e4ventiv zu vermeiden.<\/p>\n\n\n\n

Um Thundering Herds<\/strong> entgegenzuwirken, ist gezielt und beabsichtigt eingesetzter Jitter als “Tool” denkbar, der zeitgleiche Anfragen einer Ressource entzerrt. Zudem sollten Thundering-Herds durch Chaos-Testing ermittelt und dabei beobachtet werden, wie das System auf eine unrealistisch wirkende Anzahl an Anfragen reagiert. Hier h\u00e4tte im beschriebenen Ausfall Azures die M\u00f6glichkeit bestanden, die Auswirkungen einer gro\u00dfen VM Nachfrage zu ermitteln, um die nachtr\u00e4glich umgesetzten Anpassungen bereits pr\u00e4ventiv zu implementieren. Thundering-Herds k\u00f6nnen, wie bereits beschrieben, jeden im Internet zur Verf\u00fcgung gestellten Dienst betreffen und m\u00fcssen dementsprechend regelm\u00e4\u00dfig getestet und durch geeignete Ma\u00dfnahmen in ihrer Auswirkung verringert werden.<\/p>\n\n\n\n

Gegen die in allen ULS-Systemen verwendeten Automatisierungstechniken zu kontrollieren, sollten diese Automatisierungen durch Beschr\u00e4nkungen kontrollierbar und im Falle eines Fehlers auch abschaltbar sein (siehe auch Control Automation AWS [18]<\/a>). Nur wenn automatisierte, komplexe Systeme durch Menschen steuerbar sind, k\u00f6nnen Black-Swans durch Automation Interactions<\/strong> vermieden werden. Dies nutzte Google, um den beschriebenen Ausfall schnell festzustellen und innerhalb kurzer Zeit zu beheben. Auch bei Slack h\u00e4tte es geholfen das AutoScaling kurzfristig manuell zu \u00fcbernehmen, ehe der Bug (durch funktionierendes Monitoring) und die Ursachen der veralteten HAProxy-Slots gefunden werden konnte.<\/p>\n\n\n\n

Weitere Ma\u00dfnahmen, um gegen Muster der Black-Swan vorzugehen werden in Laura Nolans USENIX-Konferenzbeitrag [2]<\/a> beschrieben. Dabei werden auch Pr\u00e4ventionsma\u00dfnahmen f\u00fcr Cyberattacks<\/strong> und Dependency Problems<\/strong> n\u00e4her beschrieben, die in den genannten Ausf\u00e4llen 2020 nicht als Muster auftauchen, <\/p>\n\n\n\n

Fazit<\/h2>\n\n\n\n

Die beschriebenen Ausf\u00e4lle des vergangenen Jahres zeigen, dass die von Laura Nolan definierten Muster durchaus auch in aktuellen Ausf\u00e4llen auftauchen und dadurch auch Muster der Pr\u00e4vention aufzeigen. Vor allem gegen Limits, die in drei der vier Ausf\u00e4llen mit ausschlaggebend waren, sollte dementsprechend durch Monitoring und Kapazit\u00e4tstest vorgegangen werden. Zudem f\u00e4llt auf, dass Muster in Kombinationen auftreten bzw. Muster wie zum Beispiel das Erreichen eines Limits, wiederum andere Muster (z.B. Spreading Slowness oder Thundering Herds) ausl\u00f6sen, die dann zum Ausfall eines Systems f\u00fchren. <\/p>\n\n\n\n

Es wird zus\u00e4tzlich deutlich, dass \u00c4nderungen innerhalb des Systems eine h\u00e4ufige Ursache der Ausf\u00e4lle darstellt. Dies best\u00e4tigt sowohl Googles Incidents-Analyse von Sue Lueder [18]<\/a>, als auch drei der vier beschrieben Ausf\u00e4lle 2020. F\u00fchrte die \u00c4nderung der Datenbank am Vormittag bei Slack zum erh\u00f6hten Traffic und war dadurch zwar nicht ausschlaggebend aber mitverantwortlich f\u00fcr den Ausfall, waren bei AWS und Google \u00c4nderungen des Systems Hauptursachen der Ausf\u00e4lle. Bei AWS die Erh\u00f6hung der Front-Fleet Kapazit\u00e4t, bei Google der Umzug des User-ID-Services auf ein neues Quota-System. Um solchen Ausf\u00e4llen entgegenzuwirken, sollten \u00c4nderungen immer auf kleinen Prozents\u00e4tzen (z.B: 5%) eines Produktivsystems durchgef\u00fchrt und nicht direkt auf ein gesamtes System ausgerollt werden. Dann ist ein genaues Beobachten dieses Teilbereichs m\u00f6glich und kann genau auf Fehler analysiert und ggf. durch “Fast Roll Back” r\u00fcckg\u00e4ngig gemacht werden. Dieser “Smal Subset First” Ansatz wird von Laura Nolan auch als “Canarying” beschrieben. “Schwarzen Schw\u00e4nen” also mit “Kanarienv\u00f6geln” zu begegnen, stellt hier einen vielversprechenden Ansatz dar.<\/p>\n\n\n\n

Denn auch wenn Black-Swans nach Definition nicht vorhersehbar sind, gibt es die beschriebenen M\u00f6glichkeiten um diese durch geeignete Architekturen und Prozesse innerhalb eines Systems zu vermeiden oder zumindest Auswirkungen zu reduzieren. Trotzdem wird auch das Jahr 2021 Ausf\u00e4lle und ggf. auch weitere Black-Swans in IT Systemen hervorbringen und es bleibt spannend, welche weiteren Muster herausgefiltert werden k\u00f6nnen. Denkbare Erweiterungen der sechs beschriebenen Muster w\u00e4ren beispielsweise Missverst\u00e4ndnisse innerhalb der Systemadministration oder Cache-Probleme, die durchaus auch zu Ausf\u00e4llen gro\u00dfer, verteilter Systeme f\u00fchren k\u00f6nnen.<\/p>\n\n\n\n

Quellen:<\/h2>\n\n\n\n

[1] https:\/\/www.einkaeufer-akademie.de\/gratis-knowhow\/tipp-des-monats\/tipp-des-monats-archiv\/maerz-2020-was-ist-ein-black-swan-ereignis\/<\/a><\/p>\n\n\n\n

[2] https:\/\/www.usenix.org\/conference\/lisa18\/presentation\/nolan<\/a><\/p>\n\n\n\n

[3] https:\/\/www.investopedia.com\/terms\/b\/blackswan.asp<\/a><\/p>\n\n\n\n

[4] http:\/\/citeseerx.ist.psu.edu\/viewdoc\/download?doi=10.1.1.695.4305&rep=rep1&type=pdf<\/a><\/p>\n\n\n\n

[5] https:\/\/medium.com\/making-instapaper\/instapaper-outage-cause-recovery-3c32a7e9cc5f<\/a><\/p>\n\n\n\n

[6] https:\/\/www.imperva.com\/learn\/ddos\/slowloris\/<\/a><\/p>\n\n\n\n

[7] https:\/\/engineering.atspotify.com\/2013\/06\/04\/incident-management-at-spotify\/<\/a><\/p>\n\n\n\n

[8] https:\/\/circleci.statuspage.io\/incidents\/hr0mm9xmm3x6<\/a><\/p>\n\n\n\n

[9] https:\/\/www.reddit.com\/r\/announcements\/comments\/4y0m56\/why_reddit_was_down_on_aug_11\/<\/a><\/p>\n\n\n\n

[10] https:\/\/www.bka.de\/DE\/Presse\/Listenseite_Pressemitteilungen\/2021\/Presse2021\/210127_pmEmotet.html<\/a><\/p>\n\n\n\n

[11] https:\/\/github.blog\/2016-02-03-january-28th-incident-report\/<\/a><\/p>\n\n\n\n

[12] https:\/\/www.theverge.com\/2020\/10\/27\/21537286\/microsoft-teams-115-million-daily-active-users-stats<\/a><\/p>\n\n\n\n

[13] https:\/\/blog.zoom.us\/90-day-security-plan-progress-report-april-22\/<\/a><\/p>\n\n\n\n

[14] https:\/\/status.dev.azure.com\/_event\/181122901\/post-mortem<\/a><\/p>\n\n\n\n

[15] https:\/\/slack.engineering\/a-terrible-horrible-no-good-very-bad-day-at-slack\/<\/a><\/p>\n\n\n\n

[16] https:\/\/aws.amazon.com\/de\/message\/11201\/<\/a><\/p>\n\n\n\n

[17] https:\/\/status.cloud.google.com\/incident\/zall\/20013<\/a><\/p>\n\n\n\n

[18] https:\/\/www.youtube.com\/watch?v=O8xLxNje30M<\/a><\/p>\n\n\n\n

[19] https:\/\/www.usenix.org\/conference\/srecon15\/program\/presentation\/lueder<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Seit \u00fcber einem Jahr sorgt die Coronapandemie f\u00fcr t\u00e4gliche Berichterstattung und vielerlei Einschr\u00e4nkungen. Kontakte werden auf ein Minimum begrenzt, Gastronomien und Gro\u00dfteile des Einzelhandels geschlossen und Freizeit- sowie Kulturveranstaltungen abgesagt. Mehr Zeit als je zuvor verbringen die Menschen in ihren eigenen vier W\u00e4nden und nutzen IT-Systeme, um im Home-Office zu arbeiten, \u00fcber Lernplattformen zu lernen […]<\/p>\n","protected":false},"author":1004,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1,26],"tags":[461,462,217],"ppma_author":[816],"class_list":["post-12793","post","type-post","status-publish","format-standard","hentry","category-allgemein","category-secure-systems","tag-black-swans","tag-outages-2020","tag-uls"],"aioseo_notices":[],"jetpack_featured_media_url":"","jetpack-related-posts":[{"id":23713,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2022\/11\/17\/vom-uni-projekt-in-den-app-store\/","url_meta":{"origin":12793,"position":0},"title":"Vom Uni-Projekt in den App Store","author":"Fabian Hiller","date":"17. November 2022","format":false,"excerpt":"An der HdM arbeiten jedes Semester unz\u00e4hlige Studierende an verschiedenen Ideen. Von Apps \u00fcber Videoproduktionen bis hin zu Verpackungstechnik ist dabei alles zu finden. Kaum eine Idee besteht jedoch \u00fcber das Semester hinaus. Mit der Abgabe zur Benotung enden leider bereits die meisten Projekte. Dieser Beitrag soll Inspiration bieten, falls\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/11\/unisex-app-screenshots.jpg?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/11\/unisex-app-screenshots.jpg?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/11\/unisex-app-screenshots.jpg?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/11\/unisex-app-screenshots.jpg?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/11\/unisex-app-screenshots.jpg?resize=1050%2C600&ssl=1 3x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/11\/unisex-app-screenshots.jpg?resize=1400%2C800&ssl=1 4x"},"classes":[]},{"id":25129,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2023\/07\/31\/cyberangriffe-zum-anfassen-schutz-physischer-systeme-im-iot\/","url_meta":{"origin":12793,"position":1},"title":"Cyberangriffe zum Anfassen – Schutz physischer Systeme im IoT","author":"Alexander Kraus","date":"31. July 2023","format":false,"excerpt":"Das Internet of Things (IoT) - ein faszinierendes Konzept, das unser Leben und unsere Arbeitsweise revolutioniert. Es verspricht eine Welt in der nahezu alles miteinander vernetzt ist, von unseren Haushaltsger\u00e4ten bis hin zu komplexen industriellen Anlagen. Eine Zukunft, in der Effizienz und Produktivit\u00e4t in der Wirtschaft steigen und unser Alltag\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/07\/vecteezy_8136210-1280.jpg?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/07\/vecteezy_8136210-1280.jpg?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/07\/vecteezy_8136210-1280.jpg?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/07\/vecteezy_8136210-1280.jpg?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/07\/vecteezy_8136210-1280.jpg?resize=1050%2C600&ssl=1 3x"},"classes":[]},{"id":26895,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2025\/02\/22\/parallel-sysplex-wie-ibm-z-kontinuierliche-verfugbarkeit-durch-ras-und-innovationen-des-z16-sicherstellt\/","url_meta":{"origin":12793,"position":2},"title":"Parallel SysPlex: Wie IBM Z kontinuierliche Verf\u00fcgbarkeit durch RAS und Innovationen des z16 sicherstellt","author":"Luca Walz","date":"22. February 2025","format":false,"excerpt":"Note: Dieser Blogpost wurde f\u00fcr das Modul Enterprise IT (113601a) verfasst. Kurzfassung In einer zunehmend digitalisierten Welt ist hohe Verf\u00fcgbarkeit eines Systems essenziell f\u00fcr gesch\u00e4ftskritische Anwendungen. Hierbei erm\u00f6glicht eine, von IBM f\u00fcr das IBM Z-Mainframe entwickelte, Cluster Technologie eine nahezu kontinuierliche Verf\u00fcgbarkeit, welche durch dynamische Lastenverteilung, redundante Architektur und Echtzeit\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":28654,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2026\/02\/28\/multiplayer-arena-dynamische-game-sessions-mit-docker-fastapi\/","url_meta":{"origin":12793,"position":3},"title":"Multiplayer-Arena: Dynamische Game-Sessions mit Docker & FastAPI","author":"Emre Kalkan","date":"28. February 2026","format":false,"excerpt":"Game: https:\/\/46.101.127.20.sslip.io\/ (online bis 31. M\u00e4rz 2026) (beachte Readme im Git!) Git Repo: https:\/\/github.com\/ek101-collab\/ArenaGame-with-ContainerSessions Einleitung und Motivation Im Rahmen der Vorlesung \"System Engineering und Management\" bestand die Kernaufgabe darin, ein Projekt zu konzipieren und umzusetzen, das moderne Web- und Cloud-Technologien nutzt. Zu Beginn der Projektphase lag mein Fokus auf einer\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/mainmenu.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/mainmenu.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/mainmenu.png?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/mainmenu.png?resize=700%2C400&ssl=1 2x"},"classes":[]},{"id":20729,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2021\/08\/25\/digital-ghostbusters-der-malware-auf-der-spur\/","url_meta":{"origin":12793,"position":4},"title":"Digital Ghostbusters – Der Malware auf der Spur","author":"Tobias M\u00fcller","date":"25. August 2021","format":false,"excerpt":"Die Suche nach Malware der Cyberkriminellen im Darknet: Welche Absichten stecken hinter den globalen Ransomware-Angriffen und besteht ein Zusammenhang zwischen Hacker und Regierungen?","rel":"","context":"In "Secure Systems"","block_context":{"text":"Secure Systems","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/system-designs\/secure-systems\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/08\/Ransomware_russlandfreundlich_Bild2.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/08\/Ransomware_russlandfreundlich_Bild2.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/08\/Ransomware_russlandfreundlich_Bild2.png?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/08\/Ransomware_russlandfreundlich_Bild2.png?resize=700%2C400&ssl=1 2x"},"classes":[]},{"id":28461,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2026\/02\/20\/das-alltagliche-automatisieren-das-menschliche-perfektionieren-die-transformation-des-scrum-masters-und-der-team-kommunikation-im-ki-gestutzten-agilen-umfeld\/","url_meta":{"origin":12793,"position":5},"title":"Das Allt\u00e4gliche automatisieren, das Menschliche perfektionieren: Die Transformation des Scrum-Masters und der Team-Kommunikation im KI-gest\u00fctzten agilen Umfeld","author":"Alice Ginnen","date":"20. February 2026","format":false,"excerpt":"Abstract Die zunehmende Nutzung von KI in der Softwareentwicklung ver\u00e4ndert grundlegend die bew\u00e4hrten agilen Methoden. In der vorliegenden Arbeit wird untersucht, inwiefern sich die Rolle des Scrum Masters und die Teamkommunikation durch den Einsatz von Large Language Models (LLMs) und autonomen Agenten ver\u00e4ndern. Die Analyse ergibt, dass ein zunehmender Anteil\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"jetpack_sharing_enabled":true,"authors":[{"term_id":816,"user_id":1004,"is_guest":0,"slug":"pb075","display_name":"Patrick Brenner","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/b213c59a7e07cd78fd7c79b1ccb623b0d7cc9bac646f893343aa8a5e2105d584?s=96&d=mm&r=g","0":null,"1":"","2":"","3":"","4":"","5":"","6":"","7":"","8":""}],"_links":{"self":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/12793","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/users\/1004"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/comments?post=12793"}],"version-history":[{"count":51,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/12793\/revisions"}],"predecessor-version":[{"id":13154,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/12793\/revisions\/13154"}],"wp:attachment":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/media?parent=12793"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/categories?post=12793"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/tags?post=12793"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/ppma_author?post=12793"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}