{"id":22387,"date":"2021-11-16T17:13:23","date_gmt":"2021-11-16T17:13:23","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/2021\/11\/16\/sre-prinzipien-die-7-grundregeln\/"},"modified":"2026-06-15T15:45:15","modified_gmt":"2026-06-15T15:45:15","slug":"sre-prinzipien-die-7-grundregeln","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/de\/sre-prinzipien-die-7-grundregeln\/","title":{"rendered":"SRE-Prinzipien: Die 7 Grundregeln"},"content":{"rendered":"\t\t<div data-elementor-type=\"wp-post\" data-elementor-id=\"22387\" class=\"elementor elementor-22387 elementor-22375\" data-elementor-settings=\"{&quot;ha_cmc_init_switcher&quot;:&quot;no&quot;}\" data-elementor-post-type=\"post\">\n\t\t\t\t\t\t<section class=\"elementor-section elementor-top-section elementor-element elementor-element-7ba9d136 elementor-section-boxed elementor-section-height-default elementor-section-height-default\" data-id=\"7ba9d136\" data-element_type=\"section\" data-e-type=\"section\" data-settings=\"{&quot;jet_parallax_layout_list&quot;:[],&quot;_ha_eqh_enable&quot;:false}\">\n\t\t\t\t\t\t<div class=\"elementor-container elementor-column-gap-default\">\n\t\t\t\t\t<div class=\"elementor-column elementor-col-100 elementor-top-column elementor-element elementor-element-36cba459\" data-id=\"36cba459\" data-element_type=\"column\" data-e-type=\"column\">\n\t\t\t<div class=\"elementor-widget-wrap elementor-element-populated\">\n\t\t\t\t\t\t<div class=\"elementor-element elementor-element-616e1a2b elementor-widget elementor-widget-text-editor\" data-id=\"616e1a2b\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<p>In einem unserer <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/2021\/10\/06\/what-is-a-site-reliability-engineer-sre\/\">vorherigen Artikel<\/a>haben wir besprochen, was ein SRE ist, was er tut und einige der gemeinsamen Verantwortlichkeiten, die ein typischer SRE haben kann, wie z. B. die Unterst\u00fctzung von Operationen, den Umgang mit Trouble Tickets und Incident Response sowie die allgemeine System\u00fcberwachung und -beobachtbarkeit. In diesem Artikel werden wir einen tieferen Einblick in die verschiedenen SRE-Prinzipien und -Richtlinien geben, die ein Site Reliability Engineer in seiner Rolle praktiziert. Wie DevOps dienen diese SRE-Prinzipien als Leitfaden, um die Ausrichtung in Bezug auf die Ausrichtung, Erf\u00fcllung und Unterst\u00fctzung der Ziele der Organisation voranzutreiben.<\/p><p>Google war das erste Unternehmen, das die Rolle des Site Reliability Engineering geschaffen, angenommen und unterst\u00fctzt hat. Seitdem hat sich die SRE-Rolle weiterentwickelt, da sich die Branche ver\u00e4ndert und von den traditionellen monolithischen Strukturen zu gro\u00dfen, weit verteilten Netzwerken und Microservices verlagert hat. Eines ist jedoch weitgehend gleich geblieben \u2013 die Prinzipien, an die sich SREs halten. Diese SRE-Kernprinzipien konzentrieren sich auf eine Sache: Fahrsystem und Servicezuverl\u00e4ssigkeit. Lassen Sie uns tiefer in diese Kernprinzipien der SRE eintauchen.<\/p><h2 id='sre-grunds\u00e4tze'  id=\"boomdevs_1\">SRE-Grunds\u00e4tze<\/h2><h3 id='risiken-annehmen-und-managen'  id=\"boomdevs_2\">Risiken annehmen und managen<\/h3><p>Die Akzeptanz von Risiken ist tats\u00e4chlich eines der Kernprinzipien von SRE, und es ist leicht zu verstehen, warum. Um ein System zuverl\u00e4ssiger zu machen, m\u00fcssen Sie &#8220;Was-w\u00e4re-wenn&#8221;-Szenarien in Betracht ziehen und aus potenziellen Fehlern lernen. Kein System ist jemals zu 100 % zuverl\u00e4ssig und irgendwann muss etwas schief gehen. Leider wissen die meisten Nutzer nichts \u00fcber diese Realit\u00e4t Bescheid (oder k\u00fcmmern sich nicht besonders darum). Sie wollen nur, dass die Dinge funktionieren, und das Erreichen dieser Zuverl\u00e4ssigkeit hat immer ihren Preis, sei es in Bezug auf Geld, Zeit oder sogar die Aufrechterhaltung des Kundenvertrauens.<\/p><p>F\u00fcr SREs ist es wichtig, sich auf Risiken zu konzentrieren und aus Fehlern zu lernen, um widerstandsf\u00e4hige Systeme aufzubauen. Aber es gibt immer Kompromisse, die man abw\u00e4gen muss. Die Maximierung der Zuverl\u00e4ssigkeit kann bedeuten, das Tempo neuer Funktionen zu verlangsamen, oder sie kann zu h\u00f6heren Kosten f\u00fchren, ohne dass der Umsatz stark gesteigert wird. Die Idee ist nicht, ein System zuverl\u00e4ssiger zu machen, als es eigentlich sein m\u00fcsste. Denn wenn der zus\u00e4tzliche Aufwand und die Ressourcen keinen sinnvollen Mehrwert bringen, sollten sie besser an anderer Stelle ausgegeben werden. Bei SRE geht es darum, das &#8220;genau richtige&#8221; Ma\u00df an Zuverl\u00e4ssigkeit zu finden, das Kosten, Geschwindigkeit und Wert in Einklang bringt.<\/p><h3 id='service-level-ziele'  id=\"boomdevs_3\">Service-Level-Ziele<\/h3><p>Das Prinzip der Risikobereitschaft ist eng mit den Service Level Objectives (SLOs) verbunden. Um es aufzuschl\u00fcsseln: SLOs sind spezifische Leistungsziele innerhalb eines Service Level Agreements (SLA), die an Service Level Indicators (SLIs) gemessen werden, den eigentlichen Metriken, die die Leistung Ihres Service verfolgen. Wenn Ihr SLO beispielsweise angibt, dass die Betriebszeit 99,9 % betragen sollte, misst das SLI, ob Sie diese Marke erreichen. Diese SLIs werden kontinuierlich von SREs \u00fcberwacht, so dass das Team benachrichtigt wird und schnell reagieren kann, wenn die Leistung unter den vereinbarten Schwellenwert f\u00e4llt. Bei SLIs geht es letztendlich darum, was f\u00fcr die Benutzer am wichtigsten ist, und Teams dabei zu helfen, Serviceaspekte zu priorisieren, die sich direkt auf die Benutzererfahrung auswirken.<\/p><p>Hier ist eine kurze Aufschl\u00fcsselung dieser Begriffe:<\/p><ul><li>SLAs: Die allgemeinen Vereinbarungen mit Kunden oder Kunden \u00fcber das zu erbringende Serviceniveau.<\/li><li>SLOs: Bestimmte Leistungsziele innerhalb der SLA, z. B. Betriebszeit, Reaktionszeit oder Sicherheitsstandards.<\/li><li>SLIs: Die tats\u00e4chlichen Leistungsmessungen, mit denen die Einhaltung der SLOs verfolgt wird.<\/li><\/ul><p>Im Wesentlichen erm\u00f6glichen SLOs den Teams, die reale Leistung anhand des SLA zu messen und klare Erwartungen an die Servicequalit\u00e4t zu setzen. Diese Struktur unterstreicht, dass es eine vereinbarte Risikotoleranz gibt, indem sie definiert, wie viel Variabilit\u00e4t oder Ausfallzeit ein Dienst aushalten kann, w\u00e4hrend er gleichzeitig die Benutzerbed\u00fcrfnisse und Gesch\u00e4ftsziele erf\u00fcllt.<\/p><p><strong>Lesen Sie:<\/strong>Erfahren Sie mehr \u00fcber <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/2020\/06\/16\/sla-compliance-for-saas-businesses\/\">die Verwaltung der SLA-Compliance<\/a> in Ihrem Unternehmen.<\/p><h3 id='beseitigen-sie-die-arbeit'  id=\"boomdevs_4\">Beseitigen Sie die Arbeit<\/h3><p>Arbeit, wie sie mit dem Umfang der SRE-Rolle definiert ist, ist der Umfang an manueller Arbeit, der erforderlich ist, um sicherzustellen, dass Dienste ausgef\u00fchrt werden. Eines der Hauptziele eines SRE ist es, so viel Arbeit wie m\u00f6glich zu automatisieren. Dadurch k\u00f6nnen SREs mehr Zeit f\u00fcr wichtigere Aufgaben er\u00f6ffnen. Und wenn Sie dar\u00fcber nachdenken, sollte die Verringerung der Arbeit wirklich ein Teil der Arbeit eines jeden sein. Je weniger Zeit f\u00fcr redundante Aufgaben ben\u00f6tigt wird, desto mehr Produktivit\u00e4t wird auf lange Sicht sichergestellt. Jedes Mal, wenn ein Zuverl\u00e4ssigkeitsingenieur am Standort sich wiederholende manuelle Aktivit\u00e4ten ausf\u00fchren muss, da er sich auf die Verwaltung des Produktionsdienstes bezieht, kann dies als M\u00fche bezeichnet werden.<\/p><p>In vielen F\u00e4llen kann es Vorkommen geben, in denen ein SRE manuelle, zeitaufw\u00e4ndige Aktivit\u00e4ten ausf\u00fchren muss, aber nicht alle sollten als Arbeit definiert werden. Es ist jedoch wichtig zu definieren, welche Aktivit\u00e4ten innerhalb des SRE-Teams die meiste Zeit in Anspruch nimmt. Identifizieren Sie von dort aus, wo Verbesserungen vorgenommen werden k\u00f6nnen, um die Menge an Arbeit f\u00fcr eine bessere Arbeitsbalance zu reduzieren. Als Google zum ersten Mal die Rolle von SRE einf\u00fchrte, setzten sie sich das Ziel, dass sich die H\u00e4lfte der Zeit eines SREs darauf konzentrieren sollte, die zuk\u00fcnftige betriebliche Arbeit zu reduzieren oder Servicefunktionen hinzuzuf\u00fcgen. Die Entwicklung neuer Funktionen korreliert mit der Verbesserung von Metriken wie Zuverl\u00e4ssigkeit und Leistung, was letztendlich die potenzielle Arbeit auf der anderen Linie reduziert.<\/p><h3 id='\u00fcberwachung'  id=\"boomdevs_5\">\u00dcberwachung<\/h3><p>Bei Dotcom-Monitor dreht sich alles um <a href=\"https:\/\/www.dotcom-monitor.com\/solutions\/\">\u00dcberwachungsl\u00f6sungen<\/a> zur Verfolgung von Betriebszeit, Verf\u00fcgbarkeit, Funktionalit\u00e4t und Rundum-Performance von Servern, Websites, Diensten und Anwendungen. Monitoring ist eines der wichtigsten SRE-Prinzipien innerhalb der Rolle. Die kontinuierliche \u00dcberwachung stellt sicher, dass die Dienste wie vorgesehen funktionieren und kann dazu beitragen, den Moment zu identifizieren, in dem Probleme auftreten, damit sie sofort behoben werden k\u00f6nnen. Wie bereits im vorherigen Abschnitt erw\u00e4hnt, ist die Einhaltung dieser SLOs der Schl\u00fcssel zu den definierten Gesch\u00e4fts-SLAs und letztendlich zu den Benutzern. Die \u00dcberwachung kann SREs und Teams einen historischen Leistungstrend liefern und Einen Einblick in ein einmaliges Problem im Vergleich zu einem umfassenderen, systemischen Problem geben. Wie von der Google SRE-Initiative definiert, umfassen die vier goldenen Signale der \u00dcberwachung die folgenden Metriken:<\/p><ul><li><strong>Latenz<\/strong>. Latenz ist die Zeit oder Verz\u00f6gerung, die ein Dienst ben\u00f6tigt, um auf eine Anforderung zu antworten. Es ist klar, dass langsame Reaktionszeiten die wahrgenommene Benutzererfahrung beeinflussen. \u00dcberwachung kann eine M\u00f6glichkeit bieten, zwischen<\/li><li><strong>Verkehr<\/strong>. Datenverkehr bezieht sich auf die Menge der Benutzernachfrage oder -last auf dem System. Dies kann durch HTTP-Anfragen pro Sekunde oder abh\u00e4ngig vom tats\u00e4chlichen Dienst gemessen werden.<\/li><li><strong>Fehler<\/strong>. Fehler beziehen sich auf die Rate, mit der Anforderungen an den Dienst fehlschlagen. F\u00fcr SRE-Teams ist es jedoch wichtig, zwischen harten Ausf\u00e4llen wie 500 Serverfehlern und weichen Fehlern wie einer Antwort von 200 OK zu unterscheiden, bei der eine Zeit \u00fcberschritten wurde, weil ein bestimmter Leistungsschwellenwert festgelegt wurde. Es ist wichtig zu \u00fcberlegen, wie diese verschiedenen Szenarien wie diese angemessen \u00fcberwacht werden k\u00f6nnen.<\/li><li><strong>S\u00e4ttigung<\/strong>. Bei der S\u00e4ttigung geht es darum, zu messen, wie viele Systemressourcen ein bestimmter Dienst hat. Bis zu einem bestimmten Punkt wird es bei den meisten Diensten zu Leistungseinbu\u00dfen kommen. Zu verstehen, wo dies geschieht, kann helfen, \u00dcberwachungsziele und -ziele richtig zu definieren, so dass Korrekturma\u00dfnahmen durchgef\u00fchrt werden k\u00f6nnen.<\/li><\/ul><h3 id='automatisierung'  id=\"boomdevs_6\">Automatisierung<\/h3><p>Automatisieren, automatisieren, automatisieren. Wir haben dieses Prinzip vorhin angesprochen, als wir \u00fcber die Verringerung der Arbeit diskutiert haben, aber es kann nicht untersch\u00e4tzt werden. Die Art der SRE-Rolle ist so vielf\u00e4ltig, wie eine Rolle sein kann. Um das Potenzial f\u00fcr manuelle Eingriffe in alle Facetten ihrer Verantwortlichkeiten zu reduzieren, ist die Automatisierung von Aufgaben der Schl\u00fcssel zu einem erfolgreichen Unternehmen. Da Services skaliert und immer weiter verteilt werden, wird es viel schwieriger zu verwalten. Durch die Automatisierung sich wiederholender Aufgaben auf breiter Front, sei es beim Testen, bei der Softwarebereitstellung, bei Vorf\u00e4llen oder einfach bei der Kommunikation zwischen Teams, bietet die Automatisierung unmittelbare Vorteile, Effizienz und vor allem Konsistenz. Seit der Konzeption der SRE-Rolle hat sich die Art und Weise, wie Entwicklungs-, QA- und Operationsteams zusammenarbeiten, ver\u00e4ndert. Um diese neue DevOps-Umgebung und -Praktiken zu unterst\u00fctzen, wurden verschiedene Plattformen und Tools entwickelt.<\/p><p><strong>Lesen<\/strong>Sie: <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/2021\/10\/20\/top-13-site-reliability-engineer-sre-tools\/\">Top 13 Site Reliability (SRE) Tools<\/a>.<\/p><h3 id='release-engineering'  id=\"boomdevs_7\">Release-Engineering<\/h3><p>Release-Engineering. Klingt nach einem komplexen Thema, aber in Wirklichkeit ist es nur eine einfache M\u00f6glichkeit, zu definieren, wie Software erstellt und bereitgestellt wird. W\u00e4hrend Release Engineering an sich sein eigener Titel und seine eigene Rolle ist, bedeutet dies innerhalb des Konzepts von SRE, Dienste bereitzustellen, die stabil, konsistent und nat\u00fcrlich wiederholbar sind. Dies geht auf den vorherigen Abschnitt \u00fcber Automatisierung zur\u00fcck. Wenn Sie etwas tun, tun Sie es richtig UND k\u00f6nnen Sie das bei Bedarf konsequent wiederholen. Der Aufbau einer Reihe von einmaligen Diensten ist zeitaufwendig und verursacht unn\u00f6tige M\u00fchen.<\/p><p>Wenn wir auf die Geschichte der SRE-Position bei Google zur\u00fcckgehen, hatten sie engagierte Release-Ingenieure, die direkt mit SREs arbeiteten. Release-Ingenieure haben in der Regel die Aufgabe, Best Practices f\u00fcr die Entwicklung von Softwarediensten, die Bereitstellung von Updates, kontinuierliche Tests und die Behebung von Softwareproblemen sowie viele andere Verantwortlichkeiten zu definieren. Diese Rolle wird immer wichtiger, wenn Sie dar\u00fcber nachdenken, wie Sie Dienste skalieren und schnell bereitstellen k\u00f6nnen. Eine Reihe von Best Practices und Tools (und deren Durchsetzung) ist unerl\u00e4sslich, um diese Anforderungen erf\u00fcllen zu k\u00f6nnen, und gibt den SRE-Teams Sicherheit, sobald dieser Build in Produktion geht.<\/p><h3 id='einfachheit'  id=\"boomdevs_8\">Einfachheit<\/h3><p>Mit einer Position, die scheinbar kein Ende der Anzahl der Verantwortlichkeiten und Erwartungen hat, wie die SRE-Rolle, ist das letzte Prinzip ironischerweise Einfachheit. Vielleicht leichter gesagt als getan in der Praxis, konzentriert sich dieses Prinzip auf die Idee, ein System oder eine Dienstleistung zu entwickeln, die nur so komplex wie n\u00f6tig ist. W\u00e4hrend das auf den ersten Blick kontraintuitiv erscheinen mag, l\u00e4uft es wirklich darauf hinaus, ein System zu wollen, das zuverl\u00e4ssig, konsistent und vorhersehbar ist. Das mag langweilig klingen, aber f\u00fcr einen SRE ist das eines der ultimativen Endziele.<\/p><p>SREs streben nach einem System oder Service, der nicht komplex oder schwer zu verwalten ist. SREs wollen eine, die einfach die Arbeit erledigt, f\u00fcr die sie entwickelt wurde. Aus der Sicht eines Benutzers kann ein Dienst, der viele Funktionen bietet, jedoch auch viele Vorteile bieten, aber f\u00fcr einen SRE bedeutet das nur mehr potenzielle Kopfschmerzen. \u00c4nderungen sind jedoch immer unvermeidlich, wenn Sie einem Webdienst neue Funktionen hinzuf\u00fcgen m\u00f6chten, tun Sie dies mit Bedacht. Kleinere, inkrementelle \u00c4nderungen sind einfacher (und einfacher) zu verwalten, als viele Funktionen gleichzeitig aufzubauen und zu versenden. SREs m\u00fcssen auch die Bed\u00fcrfnisse und Ziele des Unternehmens ber\u00fccksichtigen.<\/p><h2 id='sre-prinzipien-die-7-grundregeln-abschlie\u00dfende-gedanken'  id=\"boomdevs_9\">SRE-Prinzipien: Die 7 Grundregeln &#8211; Abschlie\u00dfende Gedanken<\/h2><p>Die SRE-Rolle konzentriert sich auf den Aufbau, die Bereitstellung und die Wartung zuverl\u00e4ssiger Systeme und Dienste in gro\u00dfem Ma\u00dfstab. Diese sieben Kernprinzipien helfen bei der Definition der Praktiken f\u00fcr SREs, die dazu beitragen, die Ausrichtung innerhalb der DevOps-Praktiken zu f\u00f6rdern und die Ziele des Unternehmens zu unterst\u00fctzen. Es ist eine komplexe Rolle, die versucht, Zuverl\u00e4ssigkeit mit Feature-Releases in Einklang zu bringen und gleichzeitig ein au\u00dfergew\u00f6hnliches Qualit\u00e4tsniveau beizubehalten.<\/p><p>Die Dotcom-Monitor-Plattform bietet SREs alle <a href=\"https:\/\/www.dotcom-monitor.com\/features\/\">\u00dcberwachungsfunktionen,<\/a> die sie ben\u00f6tigen, um die Kontinuit\u00e4t ihrer Dienste zu gew\u00e4hrleisten. Von konfigurierbaren Warnungen und Berichten bis hin zu Echtzeit-Dashboards und -Berichten bietet die Plattform die wesentlichen Tools, die erforderlich sind, um die Leistung aller ihrer Dienste langfristig zu verwalten. Erstellen Sie beispielsweise Webanwendungsskripts basierend auf Benutzerverhalten, Aktionen und Pfaden und richten Sie <a href=\"\/blog\/de\/what-is-synthetic-monitoring\/\">synthetische \u00dcberwachungsaufgaben<\/a> ein, um eine konsistente Erfahrung im Laufe der Zeit sicherzustellen. Unabh\u00e4ngig davon, wie wichtig die \u00dcberwachung Ihres Teams ist, gibt es eine L\u00f6sung, die Ihren Anforderungen entspricht.<\/p><p>Starten Sie kostenlos mit der <a href=\"https:\/\/userauth.dotcom-monitor.com\/Account\/FreeTrialSignUp\">kostenlosen Testversion von Dotcom-Monitor<\/a> oder vereinbaren Sie einen Termin f\u00fcr eine <a href=\"https:\/\/www.dotcom-monitor.com\/demo\/\">Demo<\/a> mit einem unserer Performance-Ingenieure.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"<p>In einem unserer vorherigen Artikelhaben wir besprochen, was ein SRE ist, was er tut und einige der gemeinsamen Verantwortlichkeiten, die ein typischer SRE haben kann, wie z. B. die Unterst\u00fctzung von Operationen, den Umgang mit Trouble Tickets und Incident Response sowie die allgemeine System\u00fcberwachung und -beobachtbarkeit. In diesem Artikel werden wir einen tieferen Einblick in [&hellip;]<\/p>\n","protected":false},"author":21,"featured_media":22380,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[914,1132,908,914,909,909,910,910],"tags":[],"class_list":{"0":"post-22387","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","6":"hentry","7":"category-web-app-funktionalitat","8":"category-uberwachung-der-netzwerkdienste","9":"category-performance-tech-tipps","11":"category-website-performance-nachrichten","13":"category-website-betriebszeit"},"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/posts\/22387","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/comments?post=22387"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/posts\/22387\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/media\/22380"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/media?parent=22387"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/categories?post=22387"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/tags?post=22387"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}