{"id":32958,"date":"2019-10-31T21:49:56","date_gmt":"2019-10-31T18:49:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/pyat-problem-v-protsessah-ekspluatatsii-i-podderzhki-highload-it-sistem\/"},"modified":"2019-10-31T21:49:56","modified_gmt":"2019-10-31T18:49:56","slug":"pyat-problem-v-protsessah-ekspluatatsii-i-podderzhki-highload-it-sistem","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/pyat-problem-v-protsessah-ekspluatatsii-i-podderzhki-highload-it-sistem","title":{"rendered":"F\u00fcnf Probleme in den Prozessen der Nutzung und Unterst\u00fctzung von Highload IT-Systemen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo, Habr! Seit zehn Jahren unterst\u00fctze ich Highload-IT-Systeme. Ich werde in diesem Artikel nicht \u00fcber die Probleme bei der Konfiguration von nginx f\u00fcr den Betrieb im Modus 1000+ RPS oder andere technische Dinge schreiben. Ich werde meine Beobachtungen zu den Problemen in den Prozessen teilen, die bei der Unterst\u00fctzung und dem Betrieb solcher Systeme auftreten. <\/a><\/noindex><\/p>\n

\u00dcberwachung<\/h2>\n

\nDer technischen Support wartet nicht, bis ein Ticket mit dem Inhalt \"Warum\u2026 funktioniert die Website wieder nicht?\" eintrifft. Der Support sollte bereits eine Minute nach dem Ausfall der Website das Problem sehen und mit dessen L\u00f6sung beginnen. Aber die Website ist die Spitze des Eisbergs.<\/b>Ihre Verf\u00fcgbarkeit wird als eines der ersten Dinge \u00fcberwacht.<\/p>\n

Wie geht man mit der Situation um, wenn die Best\u00e4nde im Online-Shop nicht mehr aus dem ERP-System kommen? Oder wenn das CRM-System, das Rabatte f\u00fcr Kunden berechnet, nicht mehr reagiert? Die Website scheint ja zu funktionieren. Das hypothetische Zabbix erh\u00e4lt seinen 200-Antwortcode. Die Bereitschaftsschicht hat keine Benachrichtigungen vom Monitoring erhalten und schaut sich fr\u00f6hlich die erste Episode der neuen Staffel von \"Game of Thrones\" an.<\/p>\n

Oft beschr\u00e4nkt sich das Monitoring nur auf die Messung des Speicher, des RAM und der Prozessorlast. Server<\/a>.<\/b> F\u00fcr das Gesch\u00e4ft ist es jedoch viel wichtiger, die Verf\u00fcgbarkeit der Produkte auf der Website zu erhalten. Ein hypothetischer Ausfall einer virtuellen Maschine im Cluster f\u00fchrt dazu, dass der Verkehr auf diese nicht mehr geleitet wird und die Last auf andere Server steigt. Das Unternehmen verliert dabei kein Geld.<\/p>\n

Daher m\u00fcssen neben dem Monitoring der technischen Parameter von Betriebssystemen auf Servern auch Gesch\u00e4ftsmetriken eingerichtet werden. Metriken, die direkten Einfluss auf das Geld haben. Verschiedene Interaktionen mit externen Systemen (CRM, ERP und andere). Die Anzahl der Bestellungen \u00fcber einen bestimmten Zeitraum. Erfolgreiche oder nicht erfolgreiche Kundenanmeldungen und andere Metriken.<\/p>\n

Interaktion mit externen Systemen<\/h2>\n

\nJede Website oder mobile Anwendung mit einem Jahresumsatz von \u00fcber einer Milliarde Rubel interagiert mit externen Systemen. Angefangen bei den oben genannten CRM- und ERP-Systemen bis hin zur \u00dcbermittlung von Verkaufsdaten an ein externes Big Data-Analyse-System, das dem Kunden ein Produkt vorschl\u00e4gt, das er definitiv kaufen wird (in Wirklichkeit nicht). Jedes dieser Systeme hat ihren eigenen Support. Und oft verursacht die Kommunikation mit diesen Systemen Schmerz. Besonders wenn das Problem global ist und es notwendig ist, es in verschiedenen Systemen zu analysieren.<\/p>\n

Einige Systeme geben die Telefonnummer oder den Telegram-Account ihrer Administratoren an. Manchmal muss man E-Mails an die Manager schreiben oder in die Bugtracker dieser externen Systeme gehen. Selbst innerhalb eines gro\u00dfen Unternehmens arbeiten verschiedene Systeme oft in unterschiedlichen Ticketsystemen. Den Status eines Antrags zu verfolgen, wird manchmal unm\u00f6glich. Du erh\u00e4ltst einen Antrag in einer hypothetischen Jira und setzt dann im Kommentar dieser ersten Jira einen Link zur Aufgabe in einer anderen Jira. In der zweiten Jira schreibt jemand bereits einen Kommentar, dass man den hypothetischen Admin Andrei anrufen muss, um das Problem zu l\u00f6sen.<\/b> Und so weiter.<\/p>\n

Die optimale L\u00f6sung f\u00fcr dieses Problem w\u00e4re die Schaffung eines einheitlichen Kommunikationsraums, beispielsweise in Slack. Alle Beteiligten am Betrieb der externen Systeme sollten eingeladen werden. Au\u00dferdem sollte es einen gemeinsamen Tracker geben, um Doppelantr\u00e4ge zu vermeiden. Antr\u00e4ge m\u00fcssen an einem Ort verfolgt werden, beginnend bei den Benachrichtigungen des Monitorings bis hin zur Bereitstellung der L\u00f6sungen f\u00fcr Bugs in der Produktion. Du wirst sagen, dass das unrealistisch ist und es historisch so entstand, dass wir in einem Tracker arbeiten und sie in einem anderen. Verschiedene Systeme entstanden, die ihre eigenen autonomen IT-Teams hatten. Ich stimme zu, und daher muss das Problem auf der Ebene von CIO oder Produktinhaber gel\u00f6st werden.<\/p>\n

Jedes System, mit dem Sie interagieren, sollte Support als Dienstleistung mit klaren SLAs f\u00fcr die L\u00f6sung von Problemen nach Priorit\u00e4ten bieten. Und nicht nur, wenn der hypothetische Admin Andrei einen Moment Zeit f\u00fcr Sie findet.<\/p>\n

Mensch - Flaschenhals<\/h2>\n

\nGibt es nicht in jedem Projekt (oder Produkt) jemanden, dessen Urlaub bei der F\u00fchrungsebene Unruhe ausl\u00f6st? Das k\u00f6nnte ein DevOps-Ingenieur, Analyst oder Entwickler sein. Denn nur der DevOps-Ingenieur wei\u00df, auf welchen Servern welche Container installiert sind, wie man einen Container im Falle eines Problems neu startet, und jede komplexe Problemstellung kann ohne ihn nicht gel\u00f6st werden. Der Analyst ist der Einzige, der wei\u00df, wie Ihr komplexer Mechanismus funktioniert. Welche Datenstr\u00f6me wohin gehen. Unter welchen Parameteranfragen in welche Dienste, welche Antworten wir erhalten werden.
\nWer versteht schnell, warum es Fehler in den Logs gibt und behebt zeitnah einen kritischen Bug in der Produktion? Nat\u00fcrlich der Entwickler. Es gibt auch andere, aber nur er versteht, wie die verschiedenen Module des Systems aufgebaut sind.<\/p>\n

Die Wurzel dieses Problems ist das Fehlen von Dokumentation.<\/b>. Denn wenn alle Dienste Ihres Systems beschrieben w\u00e4ren, k\u00f6nnte man das Problem auch ohne Analysten l\u00f6sen. Wenn DevOps ein paar Tage aus seinem vollen Zeitplan herausgenommen und alle Server, Dienste und Anleitungen zur L\u00f6sung typischer Probleme dokumentiert h\u00e4tte, k\u00f6nnte man das Problem in seiner Abwesenheit auch ohne ihn l\u00f6sen. Es ist nicht n\u00f6tig, im Urlaub schnell sein Bier am Strand zu trinken und nach WLAN zu suchen, um das Problem zu l\u00f6sen.<\/p>\n

Kompetenz und Verantwortung der Supportmitarbeiter<\/h2>\n

\nIn gro\u00dfen Projekten scheut das Unternehmen nicht, den Entwicklern hohe Geh\u00e4lter zu zahlen. Sie suchen teure Mid-Level- oder Senior-Entwickler von \u00e4hnlichen Projekten. Bei der Unterst\u00fctzung sieht die Situation etwas anders aus. Diese Ausgaben versucht man auf jede m\u00f6gliche Weise zu reduzieren. Unternehmen stellen g\u00fcnstige, ehemalige Junior-Mitarbeiter ein und gehen mutig in die Schlacht. Eine solche Strategie ist m\u00f6glich, wenn es sich um die Website einer Visitenkarte eines Werkes in Tscherepowez handelt.<\/p>\n

Wenn es sich um einen gro\u00dfen Online-Shop handelt, kostet jede Stunde Stillstand mehr als das monatliche Gehalt eines Junior-Administrators. Nehmen wir einen Ausgangspunkt von 1 Milliarde Rubel Jahresumsatz. Das ist der minimale Umsatz eines jeden Online-Shops aus dem Ranking TOP-100 f\u00fcr 2018<\/a><\/noindex>. Teilen wir diesen Betrag durch die Anzahl der Stunden im Jahr, erhalten wir mehr als 100.000 Rubel reine Verluste. Und wenn wir die Nachtstunden nicht z\u00e4hlen, k\u00f6nnen wir die Summe problemlos verdoppeln.<\/p>\n

Aber Geld ist doch nicht alles, oder?<\/b> (nein, nat\u00fcrlich ist es wichtig) Es gibt auch den Verlust an Reputation. Eine Stunde Ausfall eines bekannten Online-Shops kann sowohl eine Welle von Beschwerden in sozialen Medien ausl\u00f6sen als auch Ver\u00f6ffentlichungen in Fachmedien nach sich ziehen. Und die Gespr\u00e4che von Freunden in der K\u00fcche im Stil von \u201eKaufe dort nichts, deren Seite funktioniert st\u00e4ndig nicht\u201c sind \u00fcberhaupt nicht messbar.<\/p>\n

Nun zur Verantwortung. In meiner Praxis gab es einen Fall, als der diensthabende Administrator nicht rechtzeitig auf die Warnung des \u00dcberwachungssystems \u00fcber die Nichterreichbarkeit der Website reagierte. An einem angenehmen sommerlichen Freitagabend war die Website eines bekannten Online-Shops in Moskau einfach offline. Am Samstagmorgen verstand der Produktverantwortliche dieser Website nicht, warum die Seite nicht l\u00e4dt, und in den Support- und Notifikations-Chats in Slack war es still. Ein solcher Fehler kostete uns einen sechsstelligen Betrag und diesem diensthabenden Mitarbeiter seinen Job.<\/p>\n

Verantwortung ist eine F\u00e4higkeit, die schwer zu entwickeln ist. <\/b>Ein Mensch hat entweder Verantwortung oder hat sie nicht. Daher versuche ich in Vorstellungsgespr\u00e4chen, sie durch verschiedene Fragen herauszufinden, die indirekt zeigen, ob die Person bereit ist, Verantwortung zu \u00fcbernehmen. Wenn jemand sagt, er habe die Hochschule gew\u00e4hlt, weil es die Eltern gesagt haben, oder die Arbeit wechse, weil die Frau gesagt hat, dass er zu wenig verdient, ist es besser, solche Personen zu meiden.<\/p>\n

Zusammenarbeit mit dem Entwicklungsteam<\/h2>\n

\nWenn bei den Nutzern im produktiven Einsatz einfache Probleme auftreten, l\u00f6st der Support diese selber. Er versucht, das Problem nachzustellen, analysiert Logs und so weiter. Aber was tun, wenn ein Bug im produktiven System auftaucht? In diesem Fall leitet der Support eine Anfrage an die Entwickler weiter, und hier beginnt das Interessante.<\/p>\n

Entwickler sind st\u00e4ndig \u00fcberlastet.<\/b> Sie sind damit besch\u00e4ftigt, neue Funktionen zu erstellen. Bugs im Produkt zu beheben, ist nicht gerade die spannendste Aufgabe. Die Fristen f\u00fcr den Abschluss des n\u00e4chsten Sprints brennen. Und dann kommen unangenehme Personen vom Support und sagen: \u201eH\u00f6r sofort mit allem auf, wir haben Probleme\u201c. Die Priorit\u00e4t solcher Aufgaben ist minimal. Besonders wenn das Problem nicht kritisch ist und die Hauptfunktionen der Website funktionieren, und wenn der Release-Manager nicht mit weit aufgerissenen Augen heruml\u00e4uft und sagt: \u201eF\u00fcge diese Aufgabe dringend in das n\u00e4chste Release oder Hotfix ein.\u201c<\/p>\n

Aufgaben mit normaler oder niedriger Priorit\u00e4t werden von Release zu Release verschoben. Auf die Frage \u201eWann wird die Aufgabe abgeschlossen sein?\u201c erh\u00e4ltst du Antworten wie: \u201eTut mir leid, es sind zurzeit viele Aufgaben, frag die Teamleiter oder den Release-Manager.\"<\/p>\n

Probleme in der Produktivumgebung haben eine h\u00f6here Priorit\u00e4t als die Erstellung neuer Funktionen. Schlechte Bewertungen lassen nicht lange auf sich warten, wenn die Nutzer st\u00e4ndig auf Bugs sto\u00dfen. Es ist schwierig, einen besch\u00e4digten Ruf wiederherzustellen.<\/p>\n

Die Fragen der Zusammenarbeit zwischen Entwicklung und Support werden von DevOps gel\u00f6st.<\/b> Diese Abk\u00fcrzung wird oft in Form einer konkreten Person verwendet, die hilft, Testumgebungen f\u00fcr die Entwicklung zu erstellen, CI\/CD-Pipelines aufzubauen und getesteten Code schnell in die Produktion zu bringen. DevOps ist ein Ansatz zur Softwareentwicklung, bei dem alle Beteiligten eng zusammenarbeiten und sich gegenseitig unterst\u00fctzen, um schneller Softwareprodukte und Dienstleistungen zu entwickeln und zu aktualisieren. Ich spreche von Analysten, Entwicklern, Testern und dem Support.<\/p>\n

Die Unterst\u00fctzung und Entwicklung in diesem Ansatz sind keine verschiedenen Abteilungen mit eigenen Zielen und Aufgaben. Die Entwicklung ist in den Betrieb eingebunden und umgekehrt. Der ber\u00fchmte Satz verteilten Teams: \u201eDas Problem liegt nicht auf meiner Seite\u201c wird in Chats nicht mehr so h\u00e4ufig verwendet, und die Endbenutzer werden ein kleines bisschen gl\u00fccklicher.
\n
Quelle: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0414\u0435\u0441\u044f\u0442\u044c \u043b\u0435\u0442 \u044f \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u044e Highload \u0418\u0422 \u0441\u0438\u0441\u0442\u0435\u043c\u044b. \u041d\u0435 \u0431\u0443\u0434\u0443 \u043f\u0438\u0441\u0430\u0442\u044c \u0432 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043e \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u0445 \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0438 nginx \u0434\u043b\u044f \u0440\u0430\u0431\u043e\u0442\u044b \u0432 \u0440\u0435\u0436\u0438\u043c\u0435 1000+ RPS \u0438\u043b\u0438 \u0434\u0440\u0443\u0433\u0438\u0435 \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u0438\u0435 \u0432\u0435\u0449\u0438. \u041f\u043e\u0434\u0435\u043b\u044e\u0441\u044c \u043d\u0430\u0431\u043b\u044e\u0434\u0435\u043d\u0438\u044f\u043c\u0438 \u043e \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u0445 \u0432 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430\u0445, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u044e\u0442 \u0432 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0435 \u0438 \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438 \u0442\u0430\u043a\u0438\u0445 \u0441\u0438\u0441\u0442\u0435\u043c. \u041c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433 \u0422\u0435\u0445\u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0430 \u043d\u0435 \u0436\u0434\u0435\u0442 \u043f\u043e\u043a\u0430 \u043f\u0440\u0438\u043b\u0435\u0442\u0438\u0442 \u0437\u0430\u044f\u0432\u043a\u0430 \u0441 \u0441\u043e\u0434\u0435\u0440\u0436\u0430\u043d\u0438\u0435\u043c \u00ab \u041a\u0430\u043a\u043e\u0433\u043e \u041f\u043e\u0447\u0435\u043c\u0443\u2026 […]<\/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-32958","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47F\u00fcnf Probleme in den Prozessen des Betriebs und der Unterst\u00fctzung von Highload IT-Systemen | ProHoster","description":"Hallo, Habr! Seit zehn Jahren unterst\u00fctze ich Highload IT-Systeme. In diesem Artikel werde ich nicht \u00fcber die Probleme bei der Konfiguration von nginx f\u00fcr den Betrieb im Modus 1000+ RPS oder andere technische Dinge schreiben.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/pyat-problem-v-protsessah-ekspluatatsii-i-podderzhki-highload-it-sistem","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\u041f\u044f\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c \u0432 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430\u0445 \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438 \u0438 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0438 Highload \u0418\u0422 \u0441\u0438\u0441\u0442\u0435\u043c | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0414\u0435\u0441\u044f\u0442\u044c \u043b\u0435\u0442 \u044f \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u044e Highload \u0418\u0422 \u0441\u0438\u0441\u0442\u0435\u043c\u044b. \u041d\u0435 \u0431\u0443\u0434\u0443 \u043f\u0438\u0441\u0430\u0442\u044c \u0432 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043e \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u0445 \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0438 nginx \u0434\u043b\u044f \u0440\u0430\u0431\u043e\u0442\u044b \u0432 \u0440\u0435\u0436\u0438\u043c\u0435 1000+ RPS \u0438\u043b\u0438 \u0434\u0440\u0443\u0433\u0438\u0435 \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u0438\u0435 \u0432\u0435\u0449\u0438.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/pyat-problem-v-protsessah-ekspluatatsii-i-podderzhki-highload-it-sistem","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:49:56+00:00","article:modified_time":"2019-10-31T18:49:56+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"32958","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-02-09 17:02:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:49:37","updated":"2026-02-09 17:02:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/32958","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=32958"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/32958\/revisions"}],"predecessor-version":[{"id":158569,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/32958\/revisions\/158569"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=32958"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=32958"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=32958"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}