{"id":35092,"date":"2019-10-31T22:02:18","date_gmt":"2019-10-31T19:02:18","guid":{"rendered":"https:\/\/prohoster.info\/blog\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim\/"},"modified":"2019-10-31T22:02:18","modified_gmt":"2019-10-31T19:02:18","slug":"bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","title":{"rendered":"\u00abBitrix24\u00bb: \u00abSchnell aufgestellte Dinge gelten nicht als gefallen\u00bb","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bis heute verf\u00fcgt der Dienst \u201eBitrix24\u201c nicht \u00fcber Hunderte von Gigabit-Traffic und hat keinen riesigen Serverpark (obwohl es nat\u00fcrlich eine betr\u00e4chtliche Anzahl an vorhandenen Servern gibt). F\u00fcr viele Kunden ist er jedoch das zentrale Arbeitswerkzeug im Unternehmen und ein wirklich gesch\u00e4ftskritisches Anwendung. Ein Ausfall ist also absolut inakzeptabel. Was aber, wenn es doch zu einem Ausfall kommt, der Dienst sich aber so schnell erholt, dass es niemand bemerkt? Und wie gelingt es, dabei ein Failover ohne Qualit\u00e4tseinbu\u00dfen und Verlust von Kunden umzusetzen? Alexander Demidov, Direktor der Cloud-Services bei \u201eBitrix24\u201c, erl\u00e4uterte in unserem Blog, wie sich das System der Reservierung in den letzten sieben Jahren seit der Einf\u00fchrung des Produkts weiterentwickelt hat.<\/p>\n

\"\u00abBitrix24\u00bb:
\n<\/a><\/noindex>
\nAls SaaS haben wir \u201eBitrix24\u201c vor 7 Jahren gestartet. Die gr\u00f6\u00dfte Herausforderung bestand wahrscheinlich darin, dass dieses Produkt vor dem \u00f6ffentlichen Launch als SaaS nur in Form einer Boxl\u00f6sung existierte. Die Kunden kauften es bei uns, installierten es auf ihren Servern, richteten ein Unternehmensportal ein \u2014 eine gemeinsame L\u00f6sung f\u00fcr die Kommunikation der Mitarbeiter, die Speicherung von Dateien, das Aufgabenmanagement, CRM, all das. Bis 2012 hatten wir beschlossen, es als SaaS zu launchen, autonom zu verwalten und Ausfallsicherheit sowie Zuverl\u00e4ssigkeit zu gew\u00e4hrleisten. Wir sammelten Erfahrungen w\u00e4hrend des Prozesses, da wir zuvor einfach keine hatten \u2013 wir waren lediglich Softwarehersteller und keine Dienstleister. <\/p>\n

Als wir den Service starteten, war uns klar, dass das Wichtigste die Gew\u00e4hrleistung von Ausfallsicherheit, Zuverl\u00e4ssigkeit und st\u00e4ndiger Verf\u00fcgbarkeit ist. Denn wenn Sie eine ganz normale Webseite, beispielsweise einen Shop, haben und diese f\u00e4llt aus und liegt eine Stunde lang, leidet nur Ihr Unternehmen darunter. Sie verlieren Bestellungen und Kunden, aber f\u00fcr den Kunden selbst ist es nicht so kritisch. Nat\u00fcrlich ist er entt\u00e4uscht, aber er geht und kauft auf einer anderen Webseite. Wenn es sich jedoch um eine Anwendung handelt, die f\u00fcr die gesamte interne Unternehmensarbeit, die Kommunikation und Entscheidungen entscheidend ist, besteht der Schl\u00fcssel darin, das Vertrauen der Nutzer zu gewinnen, das hei\u00dft, sie nicht im Stich zu lassen und nicht auszufallen. Denn die gesamte Arbeit kann stillstehen, wenn etwas intern nicht funktioniert.<\/p>\n

Bitrix24 als SaaS<\/h4>\n

\nDer erste Prototyp wurde ein Jahr vor dem \u00f6ffentlichen Launch im Jahr 2011 zusammengebaut. Wir haben ihn etwa eine Woche lang entwickelt, getestet und sogar zum Laufen gebracht. Man konnte die Form eingeben, den Namen des Portals eintragen, und ein neues Portal wurde aufgesetzt, eine Benutzerdatenbank wurde erstellt. Wir schauten es an, bewerteten das Produkt im Prinzip, stellten es ein und arbeiteten ein ganzes Jahr weiter daran. Denn wir hatten eine gro\u00dfe Aufgabe: Wir wollten keine zwei verschiedenen Codebasen erstellen, wir wollten kein separates Boxprodukt und separate Cloud-L\u00f6sungen unterst\u00fctzen \u2013 wir wollten alles innerhalb eines Codes umsetzen. <\/p>\n

\"\u00abBitrix24\u00bb:
\n
\nZu diesem Zeitpunkt war eine typische Webanwendung ein Server, auf dem ein PHP-Code l\u00e4uft, eine MySQL-Datenbank, Dateien werden hochgeladen, Dokumente und Bilder werden in einen Upload-Ordner gelegt \u2013 und das war's. Leider ist es unm\u00f6glich, einen kritisch stabilen Webservice auf dieser Basis zu starten. Verteiltes Caching und Datenbank-Replikation werden dort nicht unterst\u00fctzt. <\/p>\n

Wir haben die Anforderungen formuliert: die F\u00e4higkeit, an verschiedenen Standorten gehostet zu werden, die Unterst\u00fctzung von Replikation und idealerweise die Platzierung in geografisch verteilten Rechenzentren. Die Trennung der Produktlogik und der Datenspeicherung. Die M\u00f6glichkeit, dynamisch nach Last zu skalieren und statische Inhalte auszulagern. Aus diesen \u00dcberlegungen entstanden die Anforderungen an das Produkt, das wir im Laufe des letzten Jahres weiterentwickelt haben. W\u00e4hrend dieser Zeit haben wir eine einheitliche Plattform geschaffen \u2013 sowohl f\u00fcr Boxl\u00f6sungen als auch f\u00fcr unseren eigenen Service \u2013 und haben die erforderlichen Funktionen integriert. Die Unterst\u00fctzung der MySQL-Replikation auf Produktebene: Das hei\u00dft, der Entwickler, der Code schreibt, muss sich keine Gedanken dar\u00fcber machen, wie seine Anfragen verteilt werden. Er nutzt unsere API, und wir wissen, wie wir Lese- und Schreibanfragen richtig zwischen Master- und Slave-Datenbanken verteilen. <\/p>\n

Wir haben die Produktunterst\u00fctzung f\u00fcr verschiedene Cloud-Objektstorage-L\u00f6sungen implementiert: Google Storage, Amazon S3 \u2014 sowie die Unterst\u00fctzung f\u00fcr OpenStack Swift. Das macht es sowohl f\u00fcr uns als Dienstleister als auch f\u00fcr die Entwickler, die mit unserer Boxl\u00f6sung arbeiten, bequem: Wenn sie einfach unsere API nutzen, m\u00fcssen sie sich nicht darum k\u00fcmmern, wo die Datei letztendlich gespeichert wird \u2014 ob lokal im Dateisystem oder im objektbasierten Dateispeicher.<\/p>\n

Letztendlich haben wir uns sofort entschieden, auf der Ebene eines gesamten Rechenzentrums zu redundieren. Im Jahr 2012 haben wir vollst\u00e4ndig auf Amazon AWS gestartet, da wir bereits Erfahrung mit dieser Plattform hatten \u2013 unsere eigene Website war dort gehostet. Wir waren von der Tatsache angezogen, dass es in jeder Region von Amazon mehrere Verf\u00fcgbarkeitszonen gibt \u2013 im Grunde genommen, (in ihrer Terminologie) mehrere Rechenzentren, die mehr oder weniger unabh\u00e4ngig voneinander sind und es uns erm\u00f6glichen, auf der Ebene eines gesamten Rechenzentrums zu redundieren: Falls dieses pl\u00f6tzlich ausf\u00e4llt, werden die Datenbanken master-master repliziert, die Webanwendungsserver sind reserviert, und die statischen Inhalte werden in den Objektspeicher S3 ausgelagert. Die Last wird ausgeglichen \u2014 damals mit Amazon's ELB, aber etwas sp\u00e4ter haben wir unsere eigenen Load-Balancer entwickelt, weil wir eine komplexere Logik ben\u00f6tigten. <\/p>\n

Was wir wollten, haben wir bekommen\u2026<\/h4>\n

\nAlle grundlegenden Dinge, die wir sicherstellen wollten \u2013 die Ausfallsicherheit der Server, der Webanwendungen, der Datenbanken \u2013 haben gut funktioniert. Das einfachste Szenario: Wenn eines unserer Webanwendungen ausf\u00e4llt, ist es ganz einfach \u2013 sie werden aus der Lastverteilung entfernt. <\/p>\n

\"\u00abBitrix24\u00bb:
\n
\nDie ausgefallenen Maschinen des Load Balancers (damals war es ein Amazon ELB) wurden selbst als ungesund markiert und die Lastverteilung auf sie deaktiviert. Der Amazon Auto Scaling war aktiv: Wenn die Last anstieg, wurden neue Maschinen zur Auto Scaling-Gruppe hinzugef\u00fcgt, und die Last wurde auf die neuen Maschinen verteilt \u2013 alles lief gut. Bei unseren Load Balancern funktioniert die Logik \u00e4hnlich: Wenn etwas mit dem Anwendungsserver passiert, entfernen wir die Anfragen von ihm, nehmen diese Maschinen aus dem Betrieb, starten neue und arbeiten weiter. Die Vorgehensweise hat sich \u00fcber die Jahre etwas ver\u00e4ndert, funktioniert aber weiterhin: Sie ist einfach, verst\u00e4ndlich und es gibt keine Schwierigkeiten damit. <\/p>\n

Wir arbeiten weltweit, die Lastspitzen unserer Kunden sind sehr unterschiedlich, und im Idealfall sollten wir die M\u00f6glichkeit haben, Wartungsarbeiten an beliebigen Komponenten unseres Systems jederzeit durchzuf\u00fchren \u2013 ohne dass die Kunden etwas davon mitbekommen. Daher haben wir die M\u00f6glichkeit, die Datenbank abzuschalten und die Last auf das zweite Rechenzentrum umzuverteilen. <\/p>\n

Wie funktioniert das alles? \u2014 Wir leiten den Datenverkehr auf ein betriebsbereites Rechenzentrum um \u2013 im Falle eines Ausfalls des Rechenzentrums komplett; wenn es sich um unsere planm\u00e4\u00dfigen Arbeiten an einer bestimmten Datenbank handelt, leiten wir einen Teil des Datenverkehrs, der diese Kunden bedient, auf das zweite Rechenzentrum um, die Replikation wird eingestellt. Wenn neue Maschinen f\u00fcr Webanwendungen ben\u00f6tigt werden, weil die Last im zweiten Rechenzentrum gestiegen ist, starten sie automatisch. Nach Abschluss der Arbeiten wird die Replikation wiederhergestellt, und wir leiten die gesamte Last zur\u00fcck. Wenn wir bestimmte Arbeiten im zweiten Rechenzentrum spiegeln m\u00fcssen, zum Beispiel Systemupdates installieren oder die Einstellungen der zweiten Datenbank \u00e4ndern, machen wir im Grunde das Gleiche, nur in umgekehrter Reihenfolge. Bei einem Ausfall handeln wir ganz einfach: Im \u00dcberwachungssystem verwenden wir den Mechanismus der Event-Handler. Wenn mehrere \u00dcberpr\u00fcfungen ausgel\u00f6st werden und der Status auf kritisch wechselt, wird dieser Handler aktiviert, der eine bestimmte Logik ausf\u00fchren kann. F\u00fcr jede Datenbank haben wir festgelegt, welcher Server als Failover dient und wohin der Datenverkehr im Falle ihrer Nichterreichbarkeit umgeschaltet werden muss. Historisch bedingt verwenden wir in irgendeiner Form Nagios oder dessen Forks. Solche Mechanismen sind in praktisch jedem \u00dcberwachungssystem vorhanden, etwas Komplexeres verwenden wir derzeit nicht, aber m\u00f6glicherweise werden wir das irgendwann tun. Derzeit l\u00f6st die \u00dcberwachung bei Nichterreichbarkeit aus und hat die M\u00f6glichkeit, etwas umzuleiten.<\/p>\n

Haben wir alles reserviert?<\/h4>\n

\nWir haben viele Kunden aus den USA, viele Kunden aus Europa und viele Kunden, die n\u00e4her am Osten wohnen \u2013 Japan, Singapur und so weiter. Nat\u00fcrlich gibt es auch eine gro\u00dfe Anzahl von Kunden in Russland. Das bedeutet, dass unsere T\u00e4tigkeit nicht auf eine einzige Region beschr\u00e4nkt ist. Den Nutzern ist eine schnelle Reaktion wichtig, es gibt Anforderungen zur Einhaltung verschiedener lokaler Gesetze, und innerhalb jeder Region reservieren wir zwei Rechenzentren. Zudem gibt es zus\u00e4tzliche Dienste, die, wiederum, praktisch innerhalb einer Region platziert werden \u2013 f\u00fcr Kunden, die in dieser Region arbeiten. REST-Handler und Authentifizierungsserver sind weniger kritisch f\u00fcr die allgemeine Funktionsweise des Kunden; hier kann man mit einer akzeptablen Verz\u00f6gerung wechseln. Aber man m\u00f6chte nicht das Rad neu erfinden, indem man sich \u00fcber das Monitoring und die Handhabung Gedanken macht. Deshalb versuchen wir, soweit wie m\u00f6glich, bereits bestehende L\u00f6sungen zu nutzen und nicht eigene Kompetenzen f\u00fcr zus\u00e4tzliche Produkte zu entwickeln. An einigen Stellen verwenden wir einfach DNS-Umleitungen, wobei die Verf\u00fcgbarkeit des Dienstes ebenfalls \u00fcber DNS bestimmt wird. Amazon bietet den Dienst Route 53, der nicht nur ein einfaches DNS ist, in das man Eintr\u00e4ge eingeben kann \u2013 es ist deutlich flexibler und benutzerfreundlicher. \u00dcber ihn lassen sich geo-verteilte Dienste mit Geolokalisierungen aufbauen, bei denen man mithilfe von Route 53 feststellt, woher der Kunde kommt, und ihm entsprechende Eintr\u00e4ge bereitstellt \u2013 mithilfe dessen kann man Failover-Architekturen erstellen. Auch die Health-Checks werden direkt in Route 53 konfiguriert; man gibt Endpunkte an, die \u00fcberwacht werden, definiert Metriken und legt fest, nach welchen Protokollen die \u201eLebendigkeit\u201c des Dienstes \u00fcberpr\u00fcft werden soll \u2013 tcp, http, https, und legt die H\u00e4ufigkeit der Pr\u00fcfungen fest, die bestimmen, ob der Dienst aktiv ist oder nicht. Und im DNS legt man fest, was Primary und was Secondary sein wird und wohin umgeschaltet werden soll, wenn der Health-Check innerhalb von Route 53 anspringt. Das alles l\u00e4sst sich mit anderen Tools realisieren, aber der gro\u00dfe Vorteil ist, dass man einmal konfiguriert und danach gar nicht mehr dar\u00fcber nachdenken muss, wie die \u00dcberpr\u00fcfungen ausgef\u00fchrt werden und wie der Wechsel funktioniert: es l\u00e4uft einfach.<\/p>\n

Das erste \u201eAber\u201c<\/b>: \u0430 \u043a\u0430\u043a \u0438 \u0447\u0435\u043c \u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441\u0430\u043c route 53? \u041c\u0430\u043b\u043e \u043b\u0438, \u0432\u0434\u0440\u0443\u0433 \u0441 \u043d\u0438\u043c \u0447\u0442\u043e-\u0442\u043e \u0441\u043b\u0443\u0447\u0438\u0442\u0441\u044f? \u041c\u044b, \u043a \u0441\u0447\u0430\u0441\u0442\u044c\u044e, \u043d\u0438 \u0440\u0430\u0437\u0443 \u043d\u0430 \u044d\u0442\u0438 \u0433\u0440\u0430\u0431\u043b\u0438 \u043d\u0435 \u043d\u0430\u0441\u0442\u0443\u043f\u0430\u043b\u0438, \u043d\u043e \u043e\u043f\u044f\u0442\u044c \u0436\u0435, \u0432\u043f\u0435\u0440\u0435\u0434\u0438 \u0443 \u043c\u0435\u043d\u044f \u0431\u0443\u0434\u0435\u0442 \u0440\u0430\u0441\u0441\u043a\u0430\u0437, \u043f\u043e\u0447\u0435\u043c\u0443 \u043c\u044b \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u043b\u0438\u0441\u044c, \u0447\u0442\u043e \u0432\u0441\u0451-\u0442\u0430\u043a\u0438 \u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u043d\u0430\u0434\u043e. \u0417\u0434\u0435\u0441\u044c \u043c\u044b \u0441\u0442\u0435\u043b\u0435\u043c \u0441\u0435\u0431\u0435 \u0441\u043e\u043b\u043e\u043c\u043a\u0443 \u0437\u0430\u0440\u0430\u043d\u0435\u0435. \u041d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0440\u0430\u0437 \u0432 \u0441\u0443\u0442\u043a\u0438 \u043c\u044b \u0434\u0435\u043b\u0430\u0435\u043c \u043f\u043e\u043b\u043d\u0443\u044e \u0432\u044b\u0433\u0440\u0443\u0437\u043a\u0443 \u0432\u0441\u0435\u0445 \u0437\u043e\u043d, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0443 \u043d\u0430\u0441 \u0432 route 53 \u0437\u0430\u0432\u0435\u0434\u0435\u043d\u044b. API Amazon’a \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u0435\u0442 \u0438\u0445 \u0441\u043f\u043e\u043a\u043e\u0439\u043d\u043e \u043e\u0442\u0434\u0430\u0432\u0430\u0442\u044c \u0432 JSON, \u0438 \u0443 \u043d\u0430\u0441 \u043f\u043e\u0434\u043d\u044f\u0442\u043e \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u044b\u0445 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432, \u043a\u0443\u0434\u0430 \u043c\u044b \u044d\u0442\u043e \u043a\u043e\u043d\u0432\u0435\u0440\u0442\u0438\u0440\u0443\u0435\u043c, \u0432\u044b\u0433\u0440\u0443\u0436\u0430\u0435\u043c \u0432 \u0432\u0438\u0434\u0435 \u043a\u043e\u043d\u0444\u0438\u0433\u043e\u0432 \u0438 \u0438\u043c\u0435\u0435\u043c, \u0433\u0440\u0443\u0431\u043e \u0433\u043e\u0432\u043e\u0440\u044f, \u0431\u044d\u043a\u0430\u043f\u043d\u0443\u044e \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u044e. \u0412 \u0441\u043b\u0443\u0447\u0430\u0435 \u0447\u0435\u0433\u043e \u043c\u044b \u043c\u043e\u0436\u0435\u043c \u0431\u044b\u0441\u0442\u0440\u043e \u0440\u0430\u0437\u0432\u0435\u0440\u043d\u0443\u0442\u044c \u0435\u0451 \u0432\u0440\u0443\u0447\u043d\u0443\u044e, \u043d\u0435 \u043f\u043e\u0442\u0435\u0440\u044f\u0435\u043c \u0434\u0430\u043d\u043d\u044b\u0435 \u043d\u0430\u0441\u0442\u0440\u043e\u0435\u043a dns.<\/p>\n

Das zweite \u201eAber\u201c<\/b>: was in diesem Bild noch nicht reserviert ist? Nur der Load Balancer! Wir haben die Verteilung der Kunden nach Regionen sehr einfach gestaltet. Wir haben Domains wie bitrix24.ru, bitrix24.com, .de \u2013 derzeit sind es etwa 13 verschiedene, die in den verschiedensten Zonen funktionieren. Unser Ansatz ist: In jeder Region gibt es eigene Load Balancer. So ist es einfacher, je nach Spitzenlast im Netzwerk regional zu verteilen. Wenn es einen Ausfall bei einem einzelnen Load Balancer gibt, wird er einfach au\u00dfer Betrieb genommen und aus dem DNS entfernt. Tritt ein Problem mit einer Gruppe von Load Balancern auf, werden sie auf anderen Plattformen reserviert, und der Wechsel zwischen ihnen erfolgt \u00fcber das gleiche Route53, da der Wechsel dank der kurzen TTL maximal innerhalb von 2, 3, 5 Minuten geschieht. <\/p>\n

Das dritte \u201eaber\u201c<\/b>: Was ist noch nicht reserviert? S3, richtig. Als wir Dateien speicherten, die bei den Nutzern in S3 abgelegt waren, waren wir aufrichtig \u00fcberzeugt, dass es unverwundbar ist und man dort nichts reservieren muss. Aber die Geschichte zeigt, dass es anders kommt. Amazon beschreibt S3 tats\u00e4chlich als einen grundlegenden Dienst, weil Amazon selbst S3 f\u00fcr die Speicherung von Maschinen-Images, Konfigurationen, AMI-Images, Snapshots usw. verwendet. Und wenn S3 ausf\u00e4llt, wie es in den letzten 7 Jahren, in denen wir Bitrix24 nutzen, einmal geschehen ist, zieht es eine ganze Reihe von Problemen mit sich \u2014 die Unzug\u00e4nglichkeit des Starts von virtuellen Maschinen, API-Ausf\u00e4lle und so weiter. <\/p>\n

Und S3 kann ausfallen \u2013 das ist schon einmal passiert. Daher haben wir uns folgende Strategie \u00fcberlegt: Vor einigen Jahren gab es in Russland keine ernsthaften \u00f6ffentlichen Objektspeicher, und wir haben dar\u00fcber nachgedacht, etwas Eigenes zu entwickeln... Gl\u00fccklicherweise haben wir das nicht getan, denn wir h\u00e4tten uns mit einem Fachwissen auseinandersetzen m\u00fcssen, das uns fehlt, und h\u00e4tten sicherlich Fehler gemacht. Jetzt gibt es S3-kompatible Speicher bei Mail.ru, bei Yandex und bei einigen anderen Anbietern. Letztendlich sind wir zu dem Schluss gekommen, dass wir, erstens, Redundanz und, zweitens, die M\u00f6glichkeit zur Arbeit mit lokalen Kopien haben wollen. F\u00fcr den speziellen russischen Raum nutzen wir den Service Mail.ru Hotbox, der \u00fcber eine API mit S3 kompatibel ist. Es waren keine ernsthaften Anpassungen am Code innerhalb der Anwendung erforderlich, und wir haben den folgenden Mechanismus implementiert: In S3 gibt es Trigger, die bei der Erstellung\/L\u00f6schung von Objekten aktiviert werden, und Amazon hat einen Service namens Lambda \u2013 das ist serverloses Codeausf\u00fchren, das genau bei der Ausl\u00f6sung der genannten Trigger ausgef\u00fchrt wird.<\/p>\n

\"\u00abBitrix24\u00bb:
\n
\nWir haben es ganz einfach gemacht: Wenn unser Trigger ausgel\u00f6st wird, f\u00fchren wir den Code aus, der das Objekt in den Speicher von Mail.ru kopiert. Um die Arbeit mit lokalen Datenkopien vollst\u00e4ndig zu starten, ben\u00f6tigen wir au\u00dferdem eine R\u00fccksynchronisation, damit Kunden im russischen Sektor mit dem Speicher, der ihnen n\u00e4her ist, arbeiten k\u00f6nnen. Mail wird bald die Trigger in ihrem Speicher fertigstellen \u2014 dann k\u00f6nnen wir bereits auf Infrastruktur-Ebene die R\u00fccksynchronisation durchf\u00fchren, momentan machen wir das auf Ebene unseres eigenen Codes. Wenn wir sehen, dass ein Kunde eine Datei hochgeladen hat, setzen wir auf unserer Code-Ebene ein Ereignis in die Warteschlange, verarbeiten es und f\u00fchren die R\u00fcckreplication durch. Das ist das Problem: Wenn wir f\u00fcr unsere Objekte au\u00dferhalb unseres Produkts mit externen Mitteln arbeiten, ber\u00fccksichtigen wir das nicht. Daher warten wir, bis die Trigger auf der Ebene des Speichers verf\u00fcgbar sind, damit unabh\u00e4ngig davon, von wo wir den Code ausgef\u00fchrt haben, das Objekt, das zu uns gelangt, in die andere Richtung kopiert wird. <\/p>\n

Auf der Code-Ebene haben wir f\u00fcr jeden Kunden beide Speicherorte definiert: einem wird als der Hauptspeicher betrachtet, der andere als Backup. Wenn alles gut funktioniert, arbeiten wir mit dem Speicherort, der uns n\u00e4her ist: Das hei\u00dft, unsere Kunden, die in Amazon sind, arbeiten mit S3, w\u00e4hrend diejenigen, die in Russland sind, mit Hotbox arbeiten. Wenn ein Schalter aktiviert wird, muss unser Failover aktiviert werden, und wir schalten die Kunden auf einen anderen Speicherort um. Wir k\u00f6nnen diesen Schalter unabh\u00e4ngig nach Regionen setzen und sie hin und her wechseln. In der Praxis haben wir dies noch nicht genutzt, aber wir haben diesen Mechanismus vorgesehen und denken, dass wir irgendwann dieses Umschalten ben\u00f6tigen werden. Einmal ist es bereits passiert. <\/p>\n

Oh, ist euer Amazon verschwunden\u2026<\/h4>\n

\nDiesen April j\u00e4hrt sich der Beginn der Telegramm-Sperren in Russland. Der am st\u00e4rksten betroffene Anbieter, der darunter leidet, ist Amazon. Und leider haben vor allem russische Unternehmen, die global t\u00e4tig waren, noch st\u00e4rkere Sch\u00e4den erlitten. <\/p>\n

Wenn ein Unternehmen global ist und Russland f\u00fcr es einen ganz kleinen Markt darstellt, 3-5% \u2014 nun, so oder so, kann man diese opfern. <\/p>\n

Wenn es sich um ein rein russisches Unternehmen handelt, bin ich mir sicher, dass eine lokale Pr\u00e4senz erforderlich ist \u2013 einfach weil es f\u00fcr die Nutzer bequem und komfortabel w\u00e4re, und die Risiken geringer w\u00e4ren. <\/p>\n

Und wenn es sich um ein Unternehmen handelt, das global t\u00e4tig ist und etwa gleich viele Kunden aus Russland hat wie aus anderen Teilen der Welt? Die Verbindung der Segmente ist wichtig, und sie sollten in irgendeiner Form zusammenarbeiten m\u00fcssen. <\/p>\n

Bereits Ende M\u00e4rz 2018 hat die Roskomnadsor den gr\u00f6\u00dften Betreibern einen Brief geschickt, in dem sie dar\u00fcber informieren, dass sie planen, mehrere Millionen IP-Adressen von Amazon zu blockieren, um\u2026 den Messenger Zello zu sperren. Danke an diese Anbieter \u2013 sie haben den Brief erfolgreich allen zugespielt, und es wurde klar, dass die Verbindung zu Amazon zusammenbrechen k\u00f6nnte. Es war Freitag, und wir sind in Panik zu unseren Kollegen von servers.ru gelaufen, mit den Worten: \u201eFreunde, wir brauchen ein paar Server, die nicht in Russland, nicht bei Amazon stehen, sondern zum Beispiel irgendwo in Amsterdam\u201c, um die M\u00f6glichkeit zu haben, dort zumindest irgendwie eigene zu platzieren. vpn<\/a> \u0438 proxy \u0434\u043b\u044f \u043a\u0430\u043a\u0438\u0445-\u0442\u043e endpoint’\u043e\u0432, \u043d\u0430 \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u044b \u043d\u0438\u043a\u0430\u043a \u043d\u0435 \u043c\u043e\u0436\u0435\u043c \u0432\u043b\u0438\u044f\u0442\u044c, \u043d\u0430\u043f\u0440\u0438\u043c\u0435\u0440 endpont’\u044b \u0442\u043e\u0433\u043e \u0436\u0435 s3 \u2014 \u043d\u0435\u043b\u044c\u0437\u044f \u043f\u043e\u043f\u044b\u0442\u0430\u0442\u044c\u0441\u044f \u043f\u043e\u0434\u043d\u044f\u0442\u044c \u043d\u043e\u0432\u044b\u0439 \u0441\u0435\u0440\u0432\u0438\u0441 \u0438 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u0434\u0440\u0443\u0433\u043e\u0439 ip, \u043d\u0430\u043c \u0432\u0441\u0435 \u0440\u0430\u0432\u043d\u043e \u043d\u0443\u0436\u043d\u043e \u0442\u0443\u0434\u0430 \u0434\u043e\u0441\u0442\u0443\u0447\u0430\u0442\u044c\u0441\u044f. \u0417\u0430 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0434\u043d\u0435\u0439 \u043c\u044b \u044d\u0442\u0438 \u0441\u0435\u0440\u0432\u0435\u0440\u044b \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u043b\u0438, \u043f\u043e\u0434\u043d\u044f\u043b\u0438, \u0438 \u0432 \u043e\u0431\u0449\u0435\u043c, \u043a \u043c\u043e\u043c\u0435\u043d\u0442\u0443 \u043d\u0430\u0447\u0430\u043b\u0430 \u0431\u043b\u043e\u043a\u0438\u0440\u043e\u0432\u043e\u043a \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u0438\u043b\u0438\u0441\u044c. \u041b\u044e\u0431\u043e\u043f\u044b\u0442\u043d\u043e, \u0447\u0442\u043e \u0420\u041a\u041d, \u043f\u043e\u0441\u043c\u043e\u0442\u0440\u0435\u0432 \u043d\u0430 \u0448\u0443\u043c\u0438\u0445\u0443 \u0438 \u043f\u043e\u0434\u043d\u044f\u0442\u0443\u044e \u043f\u0430\u043d\u0438\u043a\u0443, \u0441\u043a\u0430\u0437\u0430\u043b: \u00ab\u041d\u0435, \u043c\u044b \u0441\u0435\u0439\u0447\u0430\u0441 \u0431\u043b\u043e\u043a\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u043d\u0438\u0447\u0435\u0433\u043e \u043d\u0435 \u0431\u0443\u0434\u0435\u043c\u00bb. (\u041d\u043e \u044d\u0442\u043e \u0440\u043e\u0432\u043d\u043e \u0434\u043e \u0442\u043e\u0433\u043e \u043c\u043e\u043c\u0435\u043d\u0442\u0430, \u043a\u043e\u0433\u0434\u0430 \u043d\u0430\u0447\u0430\u043b\u0438 \u0431\u043b\u043e\u043a\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0442\u0435\u043b\u0435\u0433\u0440\u0430\u043c.) \u041d\u0430\u0441\u0442\u0440\u043e\u0438\u0432 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0438 \u043e\u0431\u0445\u043e\u0434\u0430 \u0438 \u043f\u043e\u043d\u044f\u0432, \u0447\u0442\u043e \u0431\u043b\u043e\u043a\u0438\u0440\u043e\u0432\u043a\u0443 \u043d\u0435 \u0432\u0432\u0435\u043b\u0438, \u043c\u044b, \u0442\u0435\u043c \u043d\u0435 \u043c\u0435\u043d\u0435\u0435, \u043d\u0435 \u0441\u0442\u0430\u043b\u0438 \u0432\u0441\u0435 \u044d\u0442\u043e \u0434\u0435\u043b\u043e \u0440\u0430\u0437\u0431\u0438\u0440\u0430\u0442\u044c. \u0422\u0430\u043a, \u043d\u0430 \u0432\u0441\u044f\u043a\u0438\u0439 \u0441\u043b\u0443\u0447\u0430\u0439. <\/p>\n

\"\u00abBitrix24\u00bb:
\n
\nUnd so leben wir im Jahr 2019 tats\u00e4chlich in einer Umgebung mit Einschr\u00e4nkungen. Ich habe letzte Nacht geschaut: Rund eine Million IP-Adressen werden weiterhin blockiert. Zwar wurden fast alle Amazon-Adressen freigegeben, in der Spitze waren es bis zu 20 Millionen Adressen\u2026 Die Realit\u00e4t ist, dass Konnektivit\u00e4t, gute Konnektivit\u00e4t \u2014 die kann pl\u00f6tzlich fehlen. Sie kann aus technischen Gr\u00fcnden wegfallen \u2014 Br\u00e4nde, Bagger, solche Dinge. Oder, wie wir gesehen haben, aus nicht ganz technischen Gr\u00fcnden. Daher kann jemand Gro\u00dfes und Bedeutendes, mit eigenen AS-Systemen, das vielleicht auf andere Weise steuern \u2014 direkte Verbindungen und \u00e4hnliche Dinge bereits auf der L2-Ebene. Aber im einfacheren Fall, wie wir oder kleinere Anbieter, sollte man zur Sicherheit eine Reserve auf der Ebene von Servern haben, die irgendwo anders aufgestellt sind, mit vorab konfigurierten VPNs, Proxys, mit der M\u00f6glichkeit, schnell auf sie umzuschalten in den Bereichen, in denen die Konnektivit\u00e4t kritisch f\u00fcr uns ist. Das hat uns mehrfach geholfen, als die Amazon-Blockierungen begannen; wir haben so im schlimmsten Fall den S3-Verkehr dar\u00fcber geleitet, aber schlussendlich hat sich alles gekl\u00e4rt.<\/p>\n

Und wie reserviert man\u2026 einen ganzen Anbieter?<\/h4>\n

\nDerzeit haben wir kein Szenario f\u00fcr den Totalausfall von Amazon. Wir verf\u00fcgen jedoch \u00fcber ein \u00e4hnliches Szenario f\u00fcr Russland. Dort haben wir uns bei einem Anbieter platziert, der mehrere Standorte anbietet. Vor einem Jahr hatten wir ein Problem: Selbst wenn es sich um zwei Rechenzentren handelt, k\u00f6nnen bereits auf der Ebene der Netzwerkkonfiguration des Anbieters Probleme auftreten, die beide Rechenzentren betreffen. Dadurch kann es zu Ausf\u00e4llen an beiden Standorten kommen. Und genau das ist passiert. Letztendlich haben wir die Architektur \u00fcberdacht. Sie hat sich nicht grundlegend ge\u00e4ndert, aber f\u00fcr Russland haben wir nun zwei Standorte, die nicht bei einem einzigen Anbieter liegen, sondern bei zwei verschiedenen. Wenn einer ausf\u00e4llt, k\u00f6nnen wir auf den anderen umschalten.<\/p>\n

Hypothetisch ziehen wir f\u00fcr Amazon in Betracht, eine Reservierung auf der Ebene eines anderen Anbieters vorzunehmen; vielleicht Google, vielleicht jemand anderes\u2026 Aber in der Praxis haben wir bisher beobachtet, dass, wenn bei Amazon Ausf\u00e4lle in einer Verf\u00fcgbarkeitszone auftreten, umfassende Ausf\u00e4lle auf der Ebene einer Region eher selten sind. Daher haben wir theoretisch eine Vorstellung davon, dass wir m\u00f6glicherweise eine Reservierung von \"Amazon \u2014 nicht Amazon\" vornehmen k\u00f6nnten, aber bisher gibt es so etwas nicht in der Praxis. <\/p>\n

Ein paar Worte zur Automatisierung<\/h4>\n

\nIst Automatisierung immer notwendig? Hier ist der Dunning-Kruger-Effekt relevant. Auf der x-Achse haben wir unser Wissen und die Erfahrung, die wir sammeln, und auf der y-Achse unser Vertrauen in unser Handeln. Zuerst wissen wir nichts und sind \u00fcberhaupt nicht sicher. Dann wissen wir ein bisschen und werden mega-sicher \u2014 das ist der sogenannte \"Peak of Stupidity\", gut veranschaulicht durch das Bild \"Dummheit und Tapferkeit\". Danach haben wir ein bisschen gelernt und sind bereit, in den Kampf zu ziehen. Dann treten wir auf einige mega ernste H\u00fcrden und fallen ins Tal der Verzweiflung, wenn wir zwar denken, etwas zu wissen, aber in Wirklichkeit wissen wir viel zu wenig. Mit zunehmender Erfahrung werden wir dann zuversichtlicher.<\/p>\n

\"\u00abBitrix24\u00bb:
\n
\nUnsere Logik \u00fcber verschiedene Umschaltungen bei bestimmten St\u00f6rungen l\u00e4sst sich sehr gut durch dieses Diagramm erkl\u00e4ren. Wir haben angefangen \u2013 wir hatten keine Ahnung, nahezu alle Arbeiten wurden manuell durchgef\u00fchrt. Dann haben wir erkannt, dass wir alles automatisieren k\u00f6nnen, um uns beruhigt zur\u00fccklehnen zu k\u00f6nnen. Und pl\u00f6tzlich treten wir in ein gro\u00dfes Fettn\u00e4pfchen: Wir erleben einen False Positive, und wir schalten den Verkehr hin und her, obwohl es eigentlich nicht n\u00f6tig gewesen w\u00e4re. Dadurch bricht die Replikation oder etwas \u00c4hnliches zusammen \u2013 das ist das Tal der Verzweiflung. Danach kommen wir zu der Erkenntnis, dass man alles mit Bedacht angehen sollte. Das hei\u00dft, es macht Sinn, sich auf die Automatisierung zu verlassen, jedoch mit der M\u00f6glichkeit eines Fehlalarms. Aber! Wenn die Folgen katastrophal sein k\u00f6nnten, ist es besser, dies den Bereitschaftsteams, den diensthabenden Ingenieuren zu \u00fcberlassen, die sicherstellen, kontrollieren, dass es tats\u00e4chlich eine St\u00f6rung gibt, und die erforderlichen Ma\u00dfnahmen manuell durchf\u00fchren.<\/p>\n

Fazit<\/h4>\n

\nIn den letzten sieben Jahren haben wir den Weg von Panik, wenn etwas ausfiel, zu einem Verst\u00e4ndnis zur\u00fcckgelegt, dass es keine Probleme gibt, sondern nur Aufgaben, die gel\u00f6st werden m\u00fcssen \u2014 und auch gel\u00f6st werden k\u00f6nnen. Wenn Sie einen Service aufbauen, betrachten Sie ihn aus einer \u00dcberblicksperspektive und bewerten Sie alle Risiken, die auftreten k\u00f6nnen. Wenn Sie diese Risiken schnell identifizieren, planen Sie im Voraus f\u00fcr Redundanz und die M\u00f6glichkeit, eine ausfallsichere Infrastruktur zu schaffen, denn jeder Punkt, der ausfallen kann und den Dienst beeintr\u00e4chtigt, wird definitiv ausfallen. Und selbst wenn Sie denken, dass bestimmte Infrastrukturkomponenten wie S3 niemals ausfallen, sollten Sie dennoch im Hinterkopf behalten, dass sie es k\u00f6nnen. Haben Sie zumindest theoretisch einen Plan, was Sie tun werden, falls etwas passiert. Entwickeln Sie einen Risiko-Management-Plan. Wenn Sie dar\u00fcber nachdenken, alles automatisiert oder manuell zu erledigen, bewerten Sie die Risiken: Was passiert, wenn die Automatisierung anf\u00e4ngt, alles umzustellen \u2014 f\u00fchrt das m\u00f6glicherweise zu einer noch schlimmeren Situation im Vergleich zu einem Ausfall? M\u00f6glicherweise ist es an manchen Stellen notwendig, einen vern\u00fcnftigen Kompromiss zwischen der Nutzung von Automatisierung und der Reaktion eines Ingenieurs zu finden, der die tats\u00e4chliche Situation bewertet und entscheidet, ob sofortige \u00c4nderungen notwendig sind oder ob es besser ist, zu warten und nichts zu tun.<\/p>\n

Ein vern\u00fcnftiger Kompromiss zwischen Perfektionismus und den realen Ressourcen, Zeit und Geld, die Sie f\u00fcr das endg\u00fcltige Konzept aufwenden k\u00f6nnen.<\/p>\n

Dieser Text ist eine erweiterte und erg\u00e4nzte Version des Vortrags von Alexander Demidov auf der Konferenz. Uptime Tag 4<\/a><\/noindex>.<\/i>
\n
Quelle: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0439 \u0434\u0435\u043d\u044c \u0443 \u0441\u0435\u0440\u0432\u0438\u0441\u0430 \u00ab\u0411\u0438\u0442\u0440\u0438\u043a\u044124\u00bb \u043d\u0435\u0442 \u0441\u043e\u0442\u0435\u043d \u0433\u0438\u0433\u0430\u0431\u0438\u0442 \u0442\u0440\u0430\u0444\u0438\u043a\u0430, \u043d\u0435\u0442 \u043e\u0433\u0440\u043e\u043c\u043d\u043e\u0433\u043e \u043f\u0430\u0440\u043a\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 (\u0445\u043e\u0442\u044f \u0438 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445, \u043a\u043e\u043d\u0435\u0447\u043d\u043e, \u043d\u0435\u043c\u0430\u043b\u043e). \u041d\u043e \u0434\u043b\u044f \u043c\u043d\u043e\u0433\u0438\u0445 \u043a\u043b\u0438\u0435\u043d\u0442\u043e\u0432 \u043e\u043d \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u043c \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u043e\u043c \u0440\u0430\u0431\u043e\u0442\u044b \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u044d\u0442\u043e \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0435 business-critical \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u043f\u0430\u0434\u0430\u0442\u044c \u2014 \u043d\u0443, \u043d\u0438\u043a\u0430\u043a \u043d\u0435\u043b\u044c\u0437\u044f. \u0410 \u0447\u0442\u043e \u0435\u0441\u043b\u0438 \u043f\u0430\u0434\u0435\u043d\u0438\u0435 \u0432\u0441\u0435-\u0442\u0430\u043a\u0438 \u0441\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c, \u043d\u043e \u00ab\u0432\u043e\u0441\u0441\u0442\u0430\u043b\u00bb \u0441\u0435\u0440\u0432\u0438\u0441 \u0442\u0430\u043a \u0431\u044b\u0441\u0442\u0440\u043e, \u0447\u0442\u043e \u043d\u0438\u043a\u0442\u043e \u043d\u0438\u0447\u0435\u0433\u043e \u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26389,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35092","post","type-post","status-publish","format-standard","has-post-thumbnail","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\udd47\u201eBitrix24\u201c: \u201eSchnell wiederhergestellt z\u00e4hlt nicht als ausgefallen\u201c | ProHoster","description":"Der Dienst \u201eBitrix24\u201c verf\u00fcgt heute nicht \u00fcber Hunderte von Gigabit Traffic und keine riesige Serverfarm (wenngleich es nat\u00fcrlich einige gibt). Aber f\u00fcr viele Kunden ist er das wichtigste Arbeitsinstrument im Unternehmen, eine echte gesch\u00e4ftskritische Anwendung. Daher ist ein Ausfall nicht akzeptabel. Aber was ist, wenn es dennoch zu einem Ausfall kommt, der Dienst aber so schnell wiederhergestellt wird, dass niemand etwas bemerkt?","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","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\u00ab\u0411\u0438\u0442\u0440\u0438\u043a\u044124\u00bb: \u00ab\u0411\u044b\u0441\u0442\u0440\u043e \u043f\u043e\u0434\u043d\u044f\u0442\u043e\u0435 \u043d\u0435 \u0441\u0447\u0438\u0442\u0430\u0435\u0442\u0441\u044f \u0443\u043f\u0430\u0432\u0448\u0438\u043c\u00bb | ProHoster","og:description":"\u041d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0439 \u0434\u0435\u043d\u044c \u0443 \u0441\u0435\u0440\u0432\u0438\u0441\u0430 \u00ab\u0411\u0438\u0442\u0440\u0438\u043a\u044124\u00bb \u043d\u0435\u0442 \u0441\u043e\u0442\u0435\u043d \u0433\u0438\u0433\u0430\u0431\u0438\u0442 \u0442\u0440\u0430\u0444\u0438\u043a\u0430, \u043d\u0435\u0442 \u043e\u0433\u0440\u043e\u043c\u043d\u043e\u0433\u043e \u043f\u0430\u0440\u043a\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 (\u0445\u043e\u0442\u044f \u0438 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445, \u043a\u043e\u043d\u0435\u0447\u043d\u043e, \u043d\u0435\u043c\u0430\u043b\u043e). \u041d\u043e \u0434\u043b\u044f \u043c\u043d\u043e\u0433\u0438\u0445 \u043a\u043b\u0438\u0435\u043d\u0442\u043e\u0432 \u043e\u043d \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u043c \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u043e\u043c \u0440\u0430\u0431\u043e\u0442\u044b \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u044d\u0442\u043e \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0435 business-critical \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u043f\u0430\u0434\u0430\u0442\u044c \u2014 \u043d\u0443, \u043d\u0438\u043a\u0430\u043a \u043d\u0435\u043b\u044c\u0437\u044f. \u0410 \u0447\u0442\u043e \u0435\u0441\u043b\u0438 \u043f\u0430\u0434\u0435\u043d\u0438\u0435 \u0432\u0441\u0435-\u0442\u0430\u043a\u0438 \u0441\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c, \u043d\u043e \u00ab\u0432\u043e\u0441\u0441\u0442\u0430\u043b\u00bb \u0441\u0435\u0440\u0432\u0438\u0441 \u0442\u0430\u043a \u0431\u044b\u0441\u0442\u0440\u043e, \u0447\u0442\u043e \u043d\u0438\u043a\u0442\u043e \u043d\u0438\u0447\u0435\u0433\u043e \u0438","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","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-31T19:02:18+00:00","article:modified_time":"2019-10-31T19:02:18+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35092","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-04 14:51:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:10:27","updated":"2026-02-04 14:51: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\/35092","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=35092"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/35092\/revisions"}],"predecessor-version":[{"id":156668,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/35092\/revisions\/156668"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/26389"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=35092"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=35092"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=35092"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}