{"id":34597,"date":"2019-10-31T21:59:16","date_gmt":"2019-10-31T18:59:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/istoriya-vykatki-kotoraya-zatragivala-vsyo\/"},"modified":"2019-10-31T21:59:16","modified_gmt":"2019-10-31T18:59:16","slug":"istoriya-vykatki-kotoraya-zatragivala-vsyo","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/istoriya-vykatki-kotoraya-zatragivala-vsyo","title":{"rendered":"Die Geschichte der Bereitstellung, die alles betraf","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Die Geschichte der Bereitstellung, die alles betraf\" src=\"\/wp-content\/uploads\/2019\/05\/5003abbd5c0d10a0a0719b4eec96ab21.svg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i><noindex><a rel=\"nofollow\" href=\"https:\/\/www.deviantart.com\/f1x-2\/art\/Enemies-of-Reality-563259583\">Feinde der Realit\u00e4t<\/a><\/noindex> von 12f-2<\/i><\/p>\n<p>Ende April, w\u00e4hrend die Wei\u00dfen Wanderer Winterfell belagerten, hatten wir etwas Interessanteres \u2013 wir f\u00fchrten ein etwas ungew\u00f6hnliches Rollout durch. Im Grunde genommen bringen wir st\u00e4ndig neue Funktionen in die Produktion (wie alle anderen auch). Aber dieses Rollout war anders als die anderen. Der Umfang war so gro\u00df, dass jede potenzielle Fehlentscheidung, die wir treffen k\u00f6nnten, alle unsere Dienste und Nutzer betroffen h\u00e4tte. Letztendlich haben wir alles nach Plan umgesetzt, innerhalb des angek\u00fcndigten Zeitrahmens ohne Auswirkungen auf den Betrieb. Der Artikel handelt davon, wie wir das erreicht haben und wie Interessierte dies zu Hause nachmachen k\u00f6nnen.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nIch werde jetzt nicht die von uns getroffenen architektonischen und technischen Entscheidungen beschreiben oder erkl\u00e4ren, wie alles funktioniert. Vielmehr handelt es sich um Anmerkungen am Rande, wie eines der komplexesten Rollouts, die ich je gesehen habe und an dem ich direkt beteiligt war, ablief. Ich beanspruche nicht die Vollst\u00e4ndigkeit oder technischen Details; diese werden m\u00f6glicherweise in einem anderen Artikel erscheinen.<\/p>\n<h2>Vorgeschichte + was f\u00fcr eine Funktionalit\u00e4t das ist<\/h2>\n<p>\nWir bauen eine Cloud-Plattform <noindex><a rel=\"nofollow\" href=\"https:\/\/mcs.mail.ru\/\">Mail.ru Cloud L\u00f6sungen<\/a><\/noindex> (MCS), wo ich als technischer Direktor arbeite. Nun ist es an der Zeit, unserer Plattform IAM (Identity and Access Management) hinzuzuf\u00fcgen, die ein zentrales Management aller Benutzerkonten, Nutzer, Passw\u00f6rter, Rollen, Dienste und mehr erm\u00f6glicht. Die Notwendigkeit daf\u00fcr im Cloud-Umfeld liegt auf der Hand: Hier wird alle Benutzerinformation gespeichert.<\/p>\n<p>Solche Dinge werden normalerweise in der Anfangsphase jeder Projekte entwickelt. Aber bei MCS hat sich das historisch etwas anders entwickelt. MCS wurde in zwei Teilen aufgebaut: <\/p>\n<ul>\n<li>OpenStack mit einem eigenen Autorisierungsmodul namens Keystone,<\/li>\n<li>Hotbox (S3-Speicher) basierend auf dem Projekt Cloud Mail.ru,<\/li>\n<\/ul>\n<p>\num die herum dann neue Dienste entstanden.<\/p>\n<p>Im Grunde genommen waren das zwei verschiedene Arten der Autorisierung. Au\u00dferdem haben wir einige separate Entwicklungen von Mail.ru verwendet, wie etwa das allgemeine Passwortspeicher von Mail.ru, sowie einen selbst entwickelten OpenID-Connector, der die SSO (Single Sign-On) im Horizon-Dashboard der virtuellen Maschinen (natives UI von OpenStack) erm\u00f6glichte. <\/p>\n<p>Die Erstellung von IAM bedeutete f\u00fcr uns, alles in ein einheitliches System zu integrieren, das vollst\u00e4ndig uns geh\u00f6rte. Dabei wollten wir keinen Funktionsverlust riskieren und gleichzeitig eine Grundlage f\u00fcr die Zukunft schaffen, die es uns erlaubt, es transparent weiterzuentwickeln, ohne umfangreiche Refaktorisierungen vorzunehmen und die Funktionalit\u00e4t zu skalieren. Zu Beginn erhielten die Benutzer au\u00dferdem ein Rollenmodell f\u00fcr den Zugriff auf die Dienste (zentraler RBAC, role-based access control) sowie einige weitere kleine Funktionen. <\/p>\n<p>Die Aufgabe stellte sich als alles andere als trivial heraus: Python und Perl, mehrere Backends, unabh\u00e4ngig entwickelte Dienste, mehrere Entwicklungsteams und Administratoren. Und vor allem \u2013 Tausende von aktiven Benutzern auf einem Produktionssystem. All dies musste geschrieben und, was am wichtigsten ist, ohne Verluste implementiert werden.<\/p>\n<h2>Was wir bereitgestellt haben<\/h2>\n<p>\nWenn man es sehr grob betrachtet, haben wir in etwa 4 Monaten Folgendes vorbereitet:<\/p>\n<ul>\n<li>Wir haben einige neue Daemons entwickelt, die Funktionen aggregieren, die zuvor in verschiedenen Teilen der Infrastruktur arbeiteten. Den anderen Diensten haben wir ein neues Backend in Form dieser Daemons zugewiesen. <\/li>\n<li>Wir haben unser zentrales Passwort- und Schl\u00fcssel-Repository geschrieben, das f\u00fcr all unsere Dienste zug\u00e4nglich ist und das wir nach Belieben modifizieren k\u00f6nnen. <\/li>\n<li>Wir haben von Grund auf 4 neue Backends f\u00fcr Keystone entwickelt (Benutzer, Projekte, Rollen, Rollenzuweisungen), die im Grunde seine Datenbank ersetzt haben und nun als zentrales Repository f\u00fcr unsere Benutzerpassw\u00f6rter dienen.<\/li>\n<li>Wir haben all unsere OpenStack-Dienste so konfiguriert, dass sie ihre Richtlinien von einem externen Dienst abrufen, anstatt diese lokal von jedem Server zu lesen (ja, genau, OpenStack funktioniert standardm\u00e4\u00dfig so!).<\/li>\n<\/ul>\n<p>\nEine so umfassende Umgestaltung erfordert gro\u00dfe, komplexe und vor allem synchronisierte \u00c4nderungen in mehreren Systemen, die von verschiedenen Entwicklungsteams erstellt wurden. Nach dem Rollout muss das gesamte System reibungslos funktionieren. <\/p>\n<p>Wie man solche \u00c4nderungen einf\u00fchrt, ohne zu scheitern? Zun\u00e4chst haben wir beschlossen, einen kleinen Blick in die Zukunft zu werfen.<\/p>\n<h2>Rollout-Strategie<\/h2>\n<p><\/p>\n<ul>\n<li>Man k\u00f6nnte den Rollout in mehreren Phasen durchf\u00fchren, aber das w\u00fcrde die Entwicklungszeit um das Dreifache verl\u00e4ngern. Au\u00dferdem h\u00e4tten wir f\u00fcr einige Zeit eine vollst\u00e4ndige Desynchronisierung der Daten in den Datenbanken. Wir m\u00fcssten unsere eigenen Synchronisierungstools schreiben und eine lange Zeit mit mehreren Datenspeichern leben. Das birgt eine Vielzahl von Risiken.<\/li>\n<li>Alles, was wir f\u00fcr die Benutzer transparent vorbereiten konnten, wurde im Voraus erledigt. Daf\u00fcr haben wir zwei Monate ben\u00f6tigt. <\/li>\n<li>Wir haben uns f\u00fcr einige Stunden Downtime entschieden \u2013 nur f\u00fcr die Operationen der Nutzer zur Erstellung und \u00c4nderung von Ressourcen. <\/li>\n<li>F\u00fcr den Betrieb aller bereits erstellten Ressourcen war eine Downtime nicht akzeptabel. Wir haben eingeplant, dass die Ressourcen beim Rollout ohne Downtime und Auswirkungen f\u00fcr die Kunden funktionieren m\u00fcssen.<\/li>\n<li>Um die Auswirkungen auf unsere Kunden zu minimieren, falls etwas schiefgeht, haben wir uns entschieden, am Sonntagabend zu rollen. Nachts besch\u00e4ftigen sich weniger Kunden mit der Verwaltung virtueller Maschinen.<\/li>\n<li>Wir haben alle unsere Kunden dar\u00fcber informiert, dass w\u00e4hrend des vorgesehenen Rollout-Zeitraums die Verwaltung der Services nicht verf\u00fcgbar sein wird.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Ein Einschub: Was ist ein Rollout?<\/h2>\n<p>\n<i>&lt;\u043e\u0441\u0442\u043e\u0440\u043e\u0436\u043d\u043e, \u0444\u0438\u043b\u043e\u0441\u043e\u0444\u0438\u044f&gt;<\/i><\/p>\n<p>Jeder ITler kann leicht beantworten, was ein Rollout ist. Man installiert CI\/CD und alles wird automatisch in die Produktion geliefert. \ud83d\ude42<\/p>\n<p>Das stimmt auf jeden Fall. Allerdings besteht die Herausforderung darin, dass bei modernen Automatisierungstools das Verst\u00e4ndnis f\u00fcr die Bereitstellung oft verloren geht. Man vergisst fast die Bedeutung der Erfindung des Rades, wenn man sich modernen Verkehrsmitteln gegen\u00fcbersieht. Alles ist so stark automatisiert, dass die Bereitstellung h\u00e4ufig ohne ein umfassendes Verst\u00e4ndnis des gesamten Ablaufs erfolgt. <\/p>\n<p>Das Gesamtbild ist folgendes: Die Bereitstellung besteht aus vier wesentlichen Aspekten:<\/p>\n<ol>\n<li>Die Bereitstellung von Code, einschlie\u00dflich der Daten\u00e4nderungen. Zum Beispiel deren Migration.<\/li>\n<li>Die R\u00fcckg\u00e4ngigmachung des Codes \u2013 die M\u00f6glichkeit, zur\u00fcckzukehren, falls etwas schiefgeht. Zum Beispiel durch die Erstellung von Backups.<\/li>\n<li>Die Dauer jeder Bereitstellungs-\/R\u00fcckg\u00e4ngigmachung. Es ist wichtig, das Timing jeder der ersten beiden Punkte zu verstehen.<\/li>\n<li>Der betroffene Funktionsumfang. Es ist unerl\u00e4sslich, sowohl die potenziell positiven als auch die m\u00f6glichen negativen Effekte zu beurteilen. <\/li>\n<\/ol>\n<p>\nAlle diese Aspekte sind f\u00fcr eine erfolgreiche Bereitstellung zu ber\u00fccksichtigen. Normalerweise werden nur der erste und im besten Fall der zweite Punkt bewertet, und dann gilt die Bereitstellung als erfolgreich. Doch der dritte und vierte Punkt sind sogar noch wichtiger. Welcher Benutzer w\u00fcrde sich freuen, wenn die Bereitstellung 3 Stunden anstatt einer Minute dauert? Oder wenn w\u00e4hrend der Bereitstellung etwas anderes betroffen ist? Oder wenn die Ausfallzeit eines Dienstes zu unvorhersehbaren Folgen f\u00fchrt?<\/p>\n<h2>Akt 1..n, Vorbereitung auf das Release<\/h2>\n<p>\nZuerst dachte ich daran, unsere Treffen kurz zu beschreiben: das gesamte Team, seine Teile, viele Diskussionen in den Kaffee-Punkten, Streitigkeiten, Tests, Brainstormings. Dann dachte ich, das w\u00e4re \u00fcberfl\u00fcssig. Vier Monate Entwicklung bestehen immer aus solchen Momenten, besonders wenn man nicht das entwickelt, was kontinuierlich ausgeliefert werden kann, sondern eine gro\u00dfe Funktion f\u00fcr ein aktives System. Diese betrifft alle Dienste, aber f\u00fcr die Benutzer sollte sich nichts \u00e4ndern, au\u00dfer \"einem Knopf im Web-Interface\".<\/p>\n<p>Unsere Erkenntnisse dar\u00fcber, wie man Rollouts effektiv gestaltet, haben sich bei jedem neuen Treffen erheblich ver\u00e4ndert. Zum Beispiel planten wir ein Update unserer gesamten Abrechnungsdatenbank. Doch als wir die Zeit kalkulierten, stellte sich heraus, dass es nicht m\u00f6glich war, dies in einem vern\u00fcnftigen Rollout-Zeitraum umzusetzen. Wir ben\u00f6tigten fast eine zus\u00e4tzliche Woche, um die Abrechnungsdatenbank zu sharden und zu archivieren. Und als die erwartete Rollout-Geschwindigkeit danach immer noch nicht zufriedenstellend war, bestellten wir zus\u00e4tzliche leistungsst\u00e4rkere Hardware, um die gesamte Datenbank dorthin zu migrieren. Es war nicht so, dass wir das nicht fr\u00fcher h\u00e4tten tun wollen, aber die aktuellen Rollout-Anforderungen lie\u00dfen uns keine andere Wahl.<\/p>\n<p>Als einer von uns Bedenken \u00e4u\u00dferte, dass der Rollout die Verf\u00fcgbarkeit unserer virtuellen Maschinen beeintr\u00e4chtigen k\u00f6nnte, nahmen wir uns eine Woche Zeit f\u00fcr Tests, Experimente und die Analyse des Codes. So erhielten wir ein klares Verst\u00e4ndnis, dass dies in unserer Produktionsumgebung nicht der Fall sein w\u00fcrde, und selbst die skeptischsten Personen stimmten dem zu.<\/p>\n<p>In der Zwischenzeit haben die Kollegen aus dem technischen Support unabh\u00e4ngige Experimente durchgef\u00fchrt, um den Kunden Anleitungen zu den neuen Verbindungsm\u00f6glichkeiten zu schreiben, die sich nach dem Deployment \u00e4ndern sollten. Sie haben die Benutzererfahrung optimiert, Anleitungen erstellt und pers\u00f6nliche Beratungen angeboten.<\/p>\n<p>Wir haben alle m\u00f6glichen Operationen im Zusammenhang mit dem Deployment automatisiert. Jede Operation wurde skriptiert, selbst die einfachste, und wir haben st\u00e4ndig Tests durchgef\u00fchrt. Wir haben dar\u00fcber diskutiert, wie der Dienst am besten deaktiviert werden kann \u2013 durch das Stoppen des Dienstes oder durch das Sperren des Zugangs \u00fcber die Firewall. Ein Checkliste f\u00fcr jedes Schritt des Deployments wurde erstellt und kontinuierlich aktualisiert. Zudem haben wir ein Gantt-Diagramm f\u00fcr alle Deployment-Arbeiten erstellt und stetig aktualisiert, mit Zeitvorgaben. <\/p>\n<p>Und nun\u2026<\/p>\n<h2>Der finale Akt, vor dem Deployment<\/h2>\n<p>\n\u2026 ist die Zeit f\u00fcr das Deployment gekommen.<\/p>\n<p>Wie man so sch\u00f6n sagt, ein Kunstwerk kann man nicht vollenden, man kann nur aufh\u00f6ren, daran zu arbeiten. Man muss den Willen aufbringen, zu verstehen, dass man nicht alles findet, aber zu glauben, dass man alle sinnvollen Annahmen getroffen, alle m\u00f6glichen F\u00e4lle bedacht, alle kritischen Bugs behoben und alle Beteiligten ihr Bestes gegeben haben. Je mehr Code man ausrollt, desto schwieriger wird es, sich selbst davon zu \u00fcberzeugen (au\u00dferdem versteht jeder, dass es unm\u00f6glich ist, alles vorherzusehen).<\/p>\n<p>Wir haben entschieden, dass wir bereit sind, live zu gehen, als wir uns dessen sicher waren, dass wir alles M\u00f6gliche getan haben, um alle Risiken f\u00fcr unsere Nutzer in Bezug auf unerwartete Effekte und Ausfallzeiten zu minimieren. Das hei\u00dft \u2013 dass alles schiefgehen kann, au\u00dfer:<\/p>\n<ol>\n<li>Dem Einfluss (der f\u00fcr uns heiligen, wertvollsten) Nutzerinfrastruktur.<\/li>\n<li>Funktionalit\u00e4ten: Die Nutzung unseres Dienstes nach dem Rollout muss dieselbe sein wie davor.<\/li>\n<\/ol>\n<p><\/p>\n<h2>Rollout<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Die Geschichte der Bereitstellung, die alles betraf\" src=\"\/wp-content\/uploads\/2019\/05\/c43ebcaea7436b95ee19812776547af6.svg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Zwei rollen, acht st\u00f6ren nicht<\/i><\/p>\n<p>Wir haben f\u00fcr alle Anfragen von Nutzern w\u00e4hrend 7 Stunden eine Ausfallzeit eingeplant. F\u00fcr diese Zeit haben wir sowohl einen Rollout- als auch einen Rollback-Plan. <\/p>\n<ul>\n<li>Der Rollout selbst dauert etwa 3 Stunden.<\/li>\n<li>2 Stunden sind f\u00fcr das Testing eingeplant. <\/li>\n<li>2 Stunden \u2013 Puffer f\u00fcr m\u00f6gliche R\u00fcck\u00e4nderungen. <\/li>\n<\/ul>\n<p>\nEin Gantt-Diagramm wurde f\u00fcr jede Aktivit\u00e4t erstellt, das zeigt, wie viel Zeit sie in Anspruch nimmt, welche Aktivit\u00e4ten sequenziell ablaufen und welche parallel durchgef\u00fchrt werden.<\/p>\n<p><img decoding=\"async\" alt=\"Die Geschichte der Bereitstellung, die alles betraf\" src=\"\/wp-content\/uploads\/2019\/05\/361c14ebf0db5e598d4c5dc8bdb814e7.svg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Ausschnitt aus dem Gantt-Diagramm der Version, eine der fr\u00fchen Versionen (ohne parallele Ausf\u00fchrung). Ein wertvolles Synchronisationswerkzeug.<\/i><\/p>\n<p>F\u00fcr alle Beteiligten wurde ihre Rolle im Rollout definiert, welche Aufgaben sie \u00fcbernehmen und wof\u00fcr sie verantwortlich sind. Wir streben an, jeden Schritt zu automatisieren, Rollouts durchzuf\u00fchren, Feedback zu sammeln und erneut zu starten.<\/p>\n<h3>Chronik der Ereignisse<\/h3>\n<p>\nAm Sonntag, den 29. April, um 22 Uhr kamen insgesamt 15 Personen zur Arbeit. Neben den Schl\u00fcsselmitgliedern kamen einige einfach zur Unterst\u00fctzung des Teams, wof\u00fcr wir ihnen besonders danken.<\/p>\n<p>Es ist erw\u00e4hnenswert, dass unser leitender Tester im Urlaub ist. Ein Rollout ohne Tests ist nicht m\u00f6glich, wir pr\u00fcfen Alternativen. Eine Kollegin erkl\u00e4rt sich bereit, aus dem Urlaub zu testen, wof\u00fcr wir ihr im Namen des gesamten Teams unermessliche Dankbarkeit aussprechen.<\/p>\n<p><b>00:00. Halt<\/b><br \/>\nWir stoppen die Benutzeranfragen und bringen ein Schild an, dass technische Arbeiten durchgef\u00fchrt werden. Das Monitoring schl\u00e4gt Alarm, aber alles l\u00e4uft nach Plan. Wir \u00fcberpr\u00fcfen, dass nichts abgest\u00fcrzt ist, au\u00dfer dem, was sollte. Und wir beginnen mit der Migration. <\/p>\n<p>Alle haben einen ausgedruckten Rollout-Plan mit den einzelnen Punkten, jeder wei\u00df, wer was zu welchem Zeitpunkt macht. Nach jeder Aktion \u00fcberpr\u00fcfen wir die Zeitplanung, um sicherzustellen, dass wir im Zeitrahmen bleiben und alles nach Plan verl\u00e4uft. Diejenigen, die zu diesem Zeitpunkt nicht direkt am Rollout beteiligt sind, bereiten sich vor, indem sie ein Online-Spiel (Xonotic, so \u00e4hnlich wie 3D-Shooter) starten, um die Kollegen nicht zu st\u00f6ren. \ud83d\ude42<\/p>\n<p><b>02:00. Rollout abgeschlossen<\/b><br \/>\nEine angenehme \u00dcberraschung \u2014 wir beenden den Rollout eine Stunde fr\u00fcher dank der Optimierung unserer Datenbanken und Migration-Skripte. Ein allgemeiner Ruf \u201eRollout abgeschlossen!\u201c Alle neuen Funktionen sind live, aber im Interface sehen es vorerst nur wir. Alle schalten in den Testmodus um, bilden Gruppen und beginnen zu \u00fcberpr\u00fcfen, was letztendlich entstanden ist.<\/p>\n<p>Das Ergebnis ist nicht optimal, das merken wir etwa nach 10 Minuten, als in den Projekten der Teammitglieder nichts verbunden ist und nicht funktioniert. Schneller Sync, wir kommunizieren unsere Probleme, setzen Priorit\u00e4ten, bilden Teams und gehen in die Fehlersuche.<\/p>\n<p><b>02:30. Zwei gro\u00dfe Probleme gegen vier Augen<\/b><br \/>\nWir entdecken zwei gro\u00dfe Probleme. Uns ist aufgefallen, dass die Auftraggeber einige verbundene Services nicht sehen und es zu Problemen mit den Partnerkonten kommt. Beide h\u00e4ngen mit der Unvollkommenheit der Migrationsskripte f\u00fcr einige Randf\u00e4lle zusammen. Das muss jetzt behoben werden. <\/p>\n<p>Wir schreiben Anfragen, die das beheben, mindestens mit vier Augen. Wir testen im Staging, um sicherzustellen, dass sie funktionieren und nichts kaputt machen. Danach kann es weitergehen. Parallel dazu l\u00e4uft unser normales Integrationstestverfahren, das noch einige weitere Probleme entdeckt. Alle sind klein, m\u00fcssen aber ebenfalls behoben werden.<\/p>\n<p><b>03:00. -2 Probleme +2 Probleme<\/b><br \/>\nDie beiden vorherigen gro\u00dfen Probleme sind behoben, fast alle kleinen ebenfalls. Alle, die nicht mit Fixes besch\u00e4ftigt sind, arbeiten aktiv in ihren Konten und berichten, was sie finden. Wir priorisieren, verteilen es auf die Teams und lassen nicht kritische Sachen bis zum Morgen. <\/p>\n<p>Wir starten die Tests erneut, und sie entdecken zwei neue gro\u00dfe Probleme. Nicht alle Service-Richtlinien wurden richtig \u00fcbertragen, sodass einige Benutzeranfragen nicht autorisiert werden. Zudem gibt es ein neues Problem mit den Partnerkonten. Wir schauen uns das an.<\/p>\n<p><b>03:20. Notfall-Sync<\/b><br \/>\nEin neues Problem wurde behoben. F\u00fcr das zweite Problem organisieren wir einen Notfall-Sync. Wir verstehen, was passiert: Der vorherige Fix hat ein Problem gel\u00f6st, aber ein neues geschaffen. Wir machen eine Pause, um herauszufinden, wie wir es richtig und ohne negative Folgen angehen.<\/p>\n<p><b>03:30. Sechs Augen<\/b><br \/>\nWir sind uns bewusst, wie der endg\u00fcltige Zustand der Datenbank aussehen sollte, damit alles f\u00fcr alle Partner gut funktioniert. Wir schreiben eine Anfrage an 6 Augen, f\u00fchren es in der Pre-Production durch, testen es und bringen es in die Produktion.<\/p>\n<p><b>04:00. Alles funktioniert<\/b><br \/>\nAlle Tests sind bestanden, kritische Probleme sind nicht sichtbar. Gelegentlich funktioniert bei jemandem im Team etwas nicht, und wir reagieren sofort. Meistens sind die Bedenken unbegr\u00fcndet. Aber manchmal hat etwas nicht funktioniert, eine bestimmte Seite arbeitet nicht. Wir sitzen zusammen, fixen, fixen, fixen. Ein separates Team startet das letzte gro\u00dfe Feature - das Billing.<\/p>\n<p><b>04:30. Der Wendepunkt<\/b><br \/>\nDer Zeitpunkt des Unumkehrbaren n\u00e4hert sich, das hei\u00dft, der Moment, in dem wir, falls wir zur\u00fcckrollen m\u00fcssen, die vorgegebene Ausfallzeit nicht einhalten k\u00f6nnen. Es gibt Probleme mit der Abrechnung, die zwar alles wissen und protokollieren, aber hartn\u00e4ckig kein Geld von den Kunden abbuchen wollen. Einige Bugs auf bestimmten Seiten, Aktionen und Status sind vorhanden. Die Hauptfunktionen laufen, alle Tests sind erfolgreich. Wir entscheiden, dass das Rollout erfolgreich war und keine R\u00fcckrolle stattfinden wird.<\/p>\n<p><b>06:00. Wir \u00f6ffnen die UI f\u00fcr alle.<\/b><br \/>\nBugs wurden behoben. Einige, die die Nutzer nicht betreffen, werden auf sp\u00e4ter verschoben. Wir \u00f6ffnen die Benutzeroberfl\u00e4che f\u00fcr alle. Wir arbeiten weiter am Abrechnungssystem und warten auf das Feedback der Nutzer sowie die Ergebnisse des Monitorings.<\/p>\n<p><b>07:00. Probleme mit der API-Auslastung.<\/b><br \/>\nEs wird klar, dass wir die Last auf unserer API und das Testen dieser Last etwas falsch eingeplant haben, was das Problem nicht aufdecken konnte. Infolgedessen scheitern etwa 5 % der Anfragen. Wir mobilisieren uns und suchen nach der Ursache.<\/p>\n<p>Das Billing macht weiterhin Probleme und funktioniert ebenfalls nicht. Wir verschieben es, um die \u00c4nderungen in Ruhe durchf\u00fchren zu k\u00f6nnen. Das hei\u00dft, alle Ressourcen werden angesammelt, aber die Abbuchungen bei den Kunden erfolgen nicht. Nat\u00fcrlich ist das ein Problem, aber im Vergleich zu den allgemeinen Deployments scheint es nicht so entscheidend zu sein.<\/p>\n<p><b>08:00. API Fix<\/b><br \/>\nWir haben einen Fix f\u00fcr die Lastausgleichung ausgerollt, die Fehler sind verschwunden. Wir fangen an, nach Hause zu gehen.<\/p>\n<p><b>10:00. Alles<\/b><br \/>\nAlles ist behoben. Im Monitoring und bei den Kunden ist Ruhe eingekehrt, das Team zieht sich allm\u00e4hlich zum Schlafen zur\u00fcck. Das Billing bleibt, wir werden es morgen wiederherstellen.<\/p>\n<p>Im Laufe des Tages gab es Rollouts, die die Logs, Benachrichtigungen, R\u00fcckgabecodes und Anpassungen f\u00fcr einige unserer Kunden behoben haben.<\/p>\n<p>Also, der Rollout war erfolgreich! Es h\u00e4tte nat\u00fcrlich besser sein k\u00f6nnen, aber wir haben Lehren daraus gezogen, was uns gefehlt hat, um Perfektion zu erreichen.<\/p>\n<h2>Gesamt<\/h2>\n<p>\nIn den 2 Monaten aktiver Vorbereitung auf den Rollout wurden 43 Aufgaben erledigt, die von ein paar Stunden bis zu mehreren Tagen dauerten.<\/p>\n<p>W\u00e4hrend des Rollouts:<\/p>\n<ul>\n<li>neue und ge\u00e4nderte Daemons \u2013 5 St\u00fcck, die 2 Monolithen ersetzt haben;<\/li>\n<li>\u00c4nderungen innerhalb der Datenbanken \u2013 alle 6 unserer Benutzerdatenbanken waren betroffen, Exporte aus drei alten Datenbanken in eine neue wurden durchgef\u00fchrt;<\/li>\n<li>komplett \u00fcberarbeitete Frontend;<\/li>\n<li>Die Menge des ausgegebenen Codes betr\u00e4gt 33.000 Zeilen neuen Codes, \u2248 3.000 Zeilen Testcode, \u2248 5.000 Zeilen Migrationscode;<\/li>\n<li>Alle Daten sind intakt, niemand der virtuellen Maschinen des Kunden wurde beeintr\u00e4chtigt. \ud83d\ude42<\/li>\n<\/ul>\n<p><\/p>\n<h2>Gute Praktiken f\u00fcr ein erfolgreiches Rollout<\/h2>\n<p>\nDiese haben uns in dieser komplexen Situation geleitet. Grunds\u00e4tzlich sind sie jedoch bei jedem Rollout n\u00fctzlich. Je komplizierter das Rollout ist, desto wichtiger sind sie.<\/p>\n<ol>\n<li>Das erste, was wichtig ist \u2014 zu verstehen, wie das Rollout die Benutzer beeinflussen kann oder beeinflussen wird. Kommt es zu Ausfallzeiten? Wenn ja, wodurch? Wie wirkt sich das auf die Benutzer aus? Was sind die m\u00f6glichen besten und schlechtesten Szenarien? Und die Risiken ber\u00fccksichtigen.<\/li>\n<li>Alles planen. In jeder Phase muss man alle Aspekte des Rollouts verstehen:\n<ul>\n<li>Codeauslieferung;<\/li>\n<li>Code-Rollback;<\/li>\n<li>Zeit jeder Operation;<\/li>\n<li>Betroffene Funktionalit\u00e4t.<\/li>\n<\/ul>\n<\/li>\n<li>Szenarien durchspielen, bis alle Phasen des Rollouts und die Risiken in jeder Phase offensichtlich werden. Wenn Zweifel bestehen, ist es m\u00f6glich, eine Pause einzulegen und den fraglichen Schritt separat zu untersuchen.<\/li>\n<li>Jeder Schritt kann und sollte verbessert werden, wenn es unseren Nutzern hilft, beispielsweise um die Ausfallzeiten zu reduzieren oder Risiken zu minimieren.<\/li>\n<li>Rollback-Tests sind weitaus wichtiger als das Testing des Code-Deployments. Es muss sichergestellt werden, dass das System nach einem Rollback in den urspr\u00fcnglichen Zustand zur\u00fcckkehrt und dies durch Tests best\u00e4tigt wird.<\/li>\n<li>Alles, was automatisiert werden kann, sollte automatisiert werden. Was nicht automatisiert werden kann, sollte im Voraus als Erinnerung festgehalten werden.<\/li>\n<li>Den Erfolgskriterium festlegen. Welche Funktionalit\u00e4ten sollten zu welchem Zeitpunkt verf\u00fcgbar sein? Wenn dies nicht gegeben ist, aktivieren Sie den Rollback-Plan.<\/li>\n<li>Und am wichtigsten sind die Menschen. Jeder sollte wissen, was er tut, warum und welche Auswirkungen sein Handeln w\u00e4hrend des Deployments hat.<\/li>\n<\/ol>\n<p>\nIn einem Satz zusammengefasst: Mit guter Planung und Vorbereitung kann man alles ohne negative Folgen f\u00fcr die Produktion ausrollen, selbst Dinge, die alle Ihre Dienste in der Produktion betreffen.<br \/>\n<br \/>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/453364\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>Enemies of Reality by 12f-2 \u0412 \u043a\u043e\u043d\u0446\u0435 \u0430\u043f\u0440\u0435\u043b\u044f, \u043f\u043e\u043a\u0430 \u0431\u0435\u043b\u044b\u0435 \u0445\u043e\u0434\u043e\u043a\u0438 \u043e\u0441\u0430\u0436\u0434\u0430\u043b\u0438 \u0412\u0438\u043d\u0442\u0435\u0440\u0444\u0435\u043b\u043b, \u0443 \u043d\u0430\u0441 \u043f\u0440\u043e\u0438\u0437\u043e\u0448\u043b\u043e \u043a\u043e\u0435-\u0447\u0442\u043e \u043f\u043e\u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u0435\u0435, \u043c\u044b \u0441\u0434\u0435\u043b\u0430\u043b\u0438 \u043d\u0435 \u0441\u043e\u0432\u0441\u0435\u043c \u043e\u0431\u044b\u0447\u043d\u0443\u044e \u0432\u044b\u043a\u0430\u0442\u043a\u0443. \u0412 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u0435 \u043c\u044b \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u043e \u043a\u0430\u0442\u0438\u043c \u043d\u043e\u0432\u044b\u0435 \u0444\u0438\u0447\u0438 \u0432 \u043f\u0440\u043e\u0434 (\u043a\u0430\u043a \u0438 \u0432\u0441\u0435). \u041d\u043e \u044d\u0442\u0430 \u0431\u044b\u043b\u0430 \u043d\u0435 \u0442\u0430\u043a\u0430\u044f, \u043a\u0430\u043a \u0432\u0441\u0435. \u041c\u0430\u0441\u0448\u0442\u0430\u0431 \u0435\u0451 \u0431\u044b\u043b \u0442\u0430\u043a\u043e\u0432, \u0447\u0442\u043e \u043b\u044e\u0431\u044b\u0435 \u043f\u043e\u0442\u0435\u043d\u0446\u0438\u0430\u043b\u044c\u043d\u044b\u0435 \u043e\u0448\u0438\u0431\u043a\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u044b \u043c\u043e\u0433\u043b\u0438 \u0434\u043e\u043f\u0443\u0441\u0442\u0438\u0442\u044c, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34597","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"Enemies of Reality by 12f-2 \u0412 \u043a\u043e\u043d\u0446\u0435 \u0430\u043f\u0440\u0435\u043b\u044f, \u043f\u043e\u043a\u0430 \u0431\u0435\u043b\u044b\u0435 \u0445\u043e\u0434\u043e\u043a\u0438 \u043e\u0441\u0430\u0436\u0434\u0430\u043b\u0438 \u0412\u0438\u043d\u0442\u0435\u0440\u0444\u0435\u043b\u043b, \u0443 \u043d\u0430\u0441 \u043f\u0440\u043e\u0438\u0437\u043e\u0448\u043b\u043e \u043a\u043e\u0435-\u0447\u0442\u043e \u043f\u043e\u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u0435\u0435, \u043c\u044b \u0441\u0434\u0435\u043b\u0430\u043b\u0438 \u043d\u0435 \u0441\u043e\u0432\u0441\u0435\u043c \u043e\u0431\u044b\u0447\u043d\u0443\u044e \u0432\u044b\u043a\u0430\u0442\u043a\u0443. \u0412 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u0435 \u043c\u044b \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u043e \u043a\u0430\u0442\u0438\u043c \u043d\u043e\u0432\u044b\u0435 \u0444\u0438\u0447\u0438 \u0432 \u043f\u0440\u043e\u0434 (\u043a\u0430\u043a \u0438 \u0432\u0441\u0435). \u041d\u043e \u044d\u0442\u0430 \u0431\u044b\u043b\u0430 \u043d\u0435 \u0442\u0430\u043a\u0430\u044f, \u043a\u0430\u043a \u0432\u0441\u0435. \u041c\u0430\u0441\u0448\u0442\u0430\u0431 \u0435\u0451 \u0431\u044b\u043b \u0442\u0430\u043a\u043e\u0432, \u0447\u0442\u043e \u043b\u044e\u0431\u044b\u0435 \u043f\u043e\u0442\u0435\u043d\u0446\u0438\u0430\u043b\u044c\u043d\u044b\u0435 \u043e\u0448\u0438\u0431\u043a\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u044b \u043c\u043e\u0433\u043b\u0438 \u0434\u043e\u043f\u0443\u0441\u0442\u0438\u0442\u044c,\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/istoriya-vykatki-kotoraya-zatragivala-vsyo\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0418\u0441\u0442\u043e\u0440\u0438\u044f \u0432\u044b\u043a\u0430\u0442\u043a\u0438, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0437\u0430\u0442\u0440\u0430\u0433\u0438\u0432\u0430\u043b\u0430 \u0432\u0441\u0451 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"Enemies of Reality by 12f-2 \u0412 \u043a\u043e\u043d\u0446\u0435 \u0430\u043f\u0440\u0435\u043b\u044f, \u043f\u043e\u043a\u0430 \u0431\u0435\u043b\u044b\u0435 \u0445\u043e\u0434\u043e\u043a\u0438 \u043e\u0441\u0430\u0436\u0434\u0430\u043b\u0438 \u0412\u0438\u043d\u0442\u0435\u0440\u0444\u0435\u043b\u043b, \u0443 \u043d\u0430\u0441 \u043f\u0440\u043e\u0438\u0437\u043e\u0448\u043b\u043e \u043a\u043e\u0435-\u0447\u0442\u043e \u043f\u043e\u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u0435\u0435, \u043c\u044b \u0441\u0434\u0435\u043b\u0430\u043b\u0438 \u043d\u0435 \u0441\u043e\u0432\u0441\u0435\u043c \u043e\u0431\u044b\u0447\u043d\u0443\u044e \u0432\u044b\u043a\u0430\u0442\u043a\u0443. \u0412 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u0435 \u043c\u044b \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u043e \u043a\u0430\u0442\u0438\u043c \u043d\u043e\u0432\u044b\u0435 \u0444\u0438\u0447\u0438 \u0432 \u043f\u0440\u043e\u0434 (\u043a\u0430\u043a \u0438 \u0432\u0441\u0435). \u041d\u043e \u044d\u0442\u0430 \u0431\u044b\u043b\u0430 \u043d\u0435 \u0442\u0430\u043a\u0430\u044f, \u043a\u0430\u043a \u0432\u0441\u0435. \u041c\u0430\u0441\u0448\u0442\u0430\u0431 \u0435\u0451 \u0431\u044b\u043b \u0442\u0430\u043a\u043e\u0432, \u0447\u0442\u043e \u043b\u044e\u0431\u044b\u0435 \u043f\u043e\u0442\u0435\u043d\u0446\u0438\u0430\u043b\u044c\u043d\u044b\u0435 \u043e\u0448\u0438\u0431\u043a\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u044b \u043c\u043e\u0433\u043b\u0438 \u0434\u043e\u043f\u0443\u0441\u0442\u0438\u0442\u044c,\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/istoriya-vykatki-kotoraya-zatragivala-vsyo\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:59:16+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:59:16+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Geschichte der Bereitstellung, die alles betraf | ProHoster","description":"Feinde der Realit\u00e4t von 12f-2 Am Ende April, w\u00e4hrend die Wei\u00dfen Wanderer Winterfell belagerten, gab es bei uns etwas Interessanteres: eine etwas ungew\u00f6hnliche Bereitstellung. Im Grunde bringen wir st\u00e4ndig neue Features in die Produktion (wie alle). Aber diese war anders als die anderen. Ihr Umfang war so gro\u00df, dass alle potenziellen Fehler, die wir machen k\u00f6nnten,","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/istoriya-vykatki-kotoraya-zatragivala-vsyo","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0418\u0441\u0442\u043e\u0440\u0438\u044f \u0432\u044b\u043a\u0430\u0442\u043a\u0438, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0437\u0430\u0442\u0440\u0430\u0433\u0438\u0432\u0430\u043b\u0430 \u0432\u0441\u0451 | ProHoster","og:description":"Enemies of Reality by 12f-2 \u0412 \u043a\u043e\u043d\u0446\u0435 \u0430\u043f\u0440\u0435\u043b\u044f, \u043f\u043e\u043a\u0430 \u0431\u0435\u043b\u044b\u0435 \u0445\u043e\u0434\u043e\u043a\u0438 \u043e\u0441\u0430\u0436\u0434\u0430\u043b\u0438 \u0412\u0438\u043d\u0442\u0435\u0440\u0444\u0435\u043b\u043b, \u0443 \u043d\u0430\u0441 \u043f\u0440\u043e\u0438\u0437\u043e\u0448\u043b\u043e \u043a\u043e\u0435-\u0447\u0442\u043e \u043f\u043e\u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u0435\u0435, \u043c\u044b \u0441\u0434\u0435\u043b\u0430\u043b\u0438 \u043d\u0435 \u0441\u043e\u0432\u0441\u0435\u043c \u043e\u0431\u044b\u0447\u043d\u0443\u044e \u0432\u044b\u043a\u0430\u0442\u043a\u0443. \u0412 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u0435 \u043c\u044b \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u043e \u043a\u0430\u0442\u0438\u043c \u043d\u043e\u0432\u044b\u0435 \u0444\u0438\u0447\u0438 \u0432 \u043f\u0440\u043e\u0434 (\u043a\u0430\u043a \u0438 \u0432\u0441\u0435). \u041d\u043e \u044d\u0442\u0430 \u0431\u044b\u043b\u0430 \u043d\u0435 \u0442\u0430\u043a\u0430\u044f, \u043a\u0430\u043a \u0432\u0441\u0435. \u041c\u0430\u0441\u0448\u0442\u0430\u0431 \u0435\u0451 \u0431\u044b\u043b \u0442\u0430\u043a\u043e\u0432, \u0447\u0442\u043e \u043b\u044e\u0431\u044b\u0435 \u043f\u043e\u0442\u0435\u043d\u0446\u0438\u0430\u043b\u044c\u043d\u044b\u0435 \u043e\u0448\u0438\u0431\u043a\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u044b \u043c\u043e\u0433\u043b\u0438 \u0434\u043e\u043f\u0443\u0441\u0442\u0438\u0442\u044c,","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/istoriya-vykatki-kotoraya-zatragivala-vsyo","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:59:16+00:00","article:modified_time":"2019-10-31T18:59:16+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34597","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 19:51:39","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:18:36","updated":"2026-01-21 19:51:39"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/34597","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=34597"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/34597\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=34597"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=34597"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=34597"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}