<\/a><\/noindex>Als wir den Dienst starteten, wussten wir, dass das Wichtigste darin besteht, Ausfallsicherheit, Zuverl\u00e4ssigkeit und st\u00e4ndige Verf\u00fcgbarkeit des Dienstes zu gew\u00e4hrleisten, denn wenn Sie eine einfache Website haben, beispielsweise einen Online-Shop, und sie st\u00fcrzt ab und bleibt eine Stunde lang offline, leiden nur Sie selbst, Sie verlieren Auftr\u00e4ge, Sie verlieren Kunden, aber f\u00fcr den Kunden selbst ist das nicht sehr kritisch. Er ist nat\u00fcrlich entt\u00e4uscht, aber er geht und kauft auf einer anderen Website. Wenn es sich jedoch um eine Anwendung handelt, von der die gesamte Arbeit im Unternehmen abh\u00e4ngt, Kommunikation und Entscheidungen, dann ist das Wichtigste, das Vertrauen der Benutzer zu gewinnen, d.h. sie nicht im Stich zu lassen und nicht abzust\u00fcrzen. Denn die gesamte Arbeit kann stillstehen, wenn etwas im Inneren nicht funktioniert.<\/p>\n
Bitrix24 als SaaS<\/h4>\n \nDen ersten Prototypen haben wir ein Jahr vor dem \u00f6ffentlichen Launch im Jahr 2011 zusammengestellt. Wir haben ihn in etwa einer Woche zusammengebaut, angesehen und ausprobiert \u2013 er war sogar schon funktionsf\u00e4hig. Das hei\u00dft, man konnte in das Formular gehen, den Namen des Portals eingeben, und es wurde ein neues Portal erstellt, und eine Benutzerdatenbank angelegt. Wir haben uns das angeschaut, das Produkt grunds\u00e4tzlich bewertet, es verworfen und ein ganzes Jahr weiter daran gearbeitet. Denn wir hatten eine gro\u00dfe Herausforderung: Wir wollten keine zwei verschiedenen Codebasen erstellen, wir wollten kein separates Box-Produkt und separate Cloud-L\u00f6sungen unterst\u00fctzen \u2013 wir wollten all das innerhalb eines Codes umsetzen. <\/p>\n
Wir haben die Anforderungen formuliert: Es muss m\u00f6glich sein, sich an verschiedenen Standorten zu platzieren, Replikation zu unterst\u00fctzen, idealerweise in geografisch verteilten Rechenzentren untergebracht zu werden. Die Logik des Produkts von der Datenlagerung zu trennen. Dynamisch skalierbar zu sein je nach Last, statische Daten vollst\u00e4ndig auszulagern. Aus diesen \u00dcberlegungen ergaben sich letztlich die Anforderungen an das Produkt, das wir im Laufe des Jahres entwickelt haben. W\u00e4hrend dieser Zeit haben wir in der Plattform, die uns eine Einheitlichkeit bot \u2013 sowohl f\u00fcr Box-L\u00f6sungen als auch f\u00fcr unseren eigenen Dienst \u2013 die Unterst\u00fctzung f\u00fcr die Dinge integriert, die wir ben\u00f6tigten. Unterst\u00fctzung f\u00fcr MySQL-Replikation auf Produktebene: das hei\u00dft, der Entwickler, der den Code schreibt, muss sich keine Gedanken dar\u00fcber machen, wie seine Anfragen verteilt werden, er nutzt unsere API, und wir k\u00f6nnen die Anfragen zum Schreiben und Lesen zwischen Master- und Slave-Datenbanken korrekt verteilen. <\/p>\n
Wir haben auf Produktebene die Unterst\u00fctzung f\u00fcr verschiedene Cloud-Objektspeicher eingerichtet: Google Storage, Amazon S3 \u2013 plus die Unterst\u00fctzung f\u00fcr OpenStack Swift. Daher war es sowohl f\u00fcr uns als Dienstleister als auch f\u00fcr die Entwickler, die mit der Box-L\u00f6sung arbeiten, praktisch: Wenn sie einfach unsere API nutzen, brauchen sie sich keine Gedanken dar\u00fcber zu machen, wo die Datei letztendlich gespeichert wird, ob lokal im Dateisystem oder im objektorientierten Dateispeicher.<\/p>\n
Letztendlich haben wir uns sofort entschieden, dass wir uns auf der Ebene eines gesamten Rechenzentrums reservieren werden. 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. Uns hat angezogen, dass es in jeder Region bei Amazon mehrere Verf\u00fcgbarkeitszonen gibt \u2013 im Wesentlichen (in ihrer Terminologie) mehrere Rechenzentren, die mehr oder weniger unabh\u00e4ngig voneinander sind und uns erm\u00f6glichen, auf der Ebene eines gesamten Rechenzentrums zu reservieren: Wenn eines pl\u00f6tzlich ausf\u00e4llt, werden die Datenbanken master-master repliziert, die Webanwendungsserver sind reserviert, und die Statische wird in den Objektspeicher S3 ausgelagert. Die Last wird verteilt \u2013 zu diesem Zeitpunkt mit Amazons ELB, aber etwas sp\u00e4ter haben wir eigene Lastenausgleicher entwickelt, da wir komplexere Logiken ben\u00f6tigten. <\/p>\n
Was wir wollten, das haben wir auch bekommen...<\/h4>\n \nAlle grundlegenden Dinge, die wir absichern wollten \u2013 die Ausfallsicherheit der Server, der Webanwendungen und der Datenbanken \u2013 funktionierten gut. Das einfachste Szenario: Wenn eines unserer Webanwendungen ausf\u00e4llt, ist es einfach \u2013 sie werden aus der Lastverteilung entfernt. <\/p>\n
Wir arbeiten weltweit, die Lastenspitzen unserer Kunden sind absolut unterschiedlich, und im Idealfall sollten wir in der Lage sein, zu jeder Zeit Wartungsarbeiten an beliebigen Komponenten unseres Systems unbemerkt f\u00fcr die Kunden durchzuf\u00fchren. Deshalb haben wir die M\u00f6glichkeit, die Datenbank abzuschalten und die Last auf ein zweites Rechenzentrum umzuleiten. <\/p>\n
Wie funktioniert das alles? \u2014 Wir leiten den Traffic auf ein funktionierendes Rechenzentrum um \u2014 wenn es sich um einen Ausfall im Rechenzentrum handelt, dann vollst\u00e4ndig, wenn es sich um geplante Wartungsarbeiten an einer bestimmten Datenbank handelt, dann leiten wir einen Teil des Traffics, der diese Kunden bedient, auf das zweite Rechenzentrum um, die Replikation wird pausiert. Wenn wir neue Maschinen f\u00fcr Webanwendungen ben\u00f6tigen, da die Last im zweiten Rechenzentrum gestiegen ist, werden sie automatisch gestartet. Die Arbeiten werden abgeschlossen, die Replikation wird wiederhergestellt, und wir geben die gesamte Last zur\u00fcck. Wenn wir spiegelbildlich Arbeiten im zweiten Rechenzentrum durchf\u00fchren m\u00fcssen, zum Beispiel systemweite Updates installieren oder Einstellungen in der zweiten Datenbank \u00e4ndern, wiederholen wir im Grunde alles genau so, nur in die andere Richtung. Und wenn es sich um einen Ausfall handelt, handeln wir ganz banal: Im \u00dcberwachungssystem verwenden wir einen Event-Handler-Mechanismus. Wenn mehrere \u00dcberpr\u00fcfungen ausl\u00f6sen und der Status auf kritisch wechselt, wird dieser Handler, der eine bestimmte Logik ausf\u00fchren kann, aktiviert. F\u00fcr jede Datenbank haben wir festgelegt, welcher Server f\u00fcr sie als Failover dient und wohin der Traffic im Fall ihrer Nichterreichbarkeit umgeleitet werden muss. Wir verwenden \u2013 so hat es sich historisch ergeben \u2013 in irgendeiner Form Nagios oder eines seiner Forks. Prinzipiell sind solche Mechanismen in praktisch jedem \u00dcberwachungssystem vorhanden, etwas Komplexeres verwenden wir derzeit nicht, aber m\u00f6glicherweise werden wir das irgendwann tun. Momentan reagiert die \u00dcberwachung auf Nichterreichbarkeit 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, viele Kunden, die n\u00e4her am Osten sind \u2013 Japan, Singapur und so weiter. Nat\u00fcrlich ist ein gro\u00dfer Teil der Kunden in Russland. Das hei\u00dft, die Arbeit findet nicht nur in einer Region statt. Die Benutzer w\u00fcnschen sich eine schnelle Reaktion, es gibt Anforderungen zur Einhaltung verschiedener lokaler Gesetze, und innerhalb jeder Region reservieren wir uns zwei Rechenzentren. Au\u00dferdem gibt es einige zus\u00e4tzliche Dienste, die ebenfalls bequem innerhalb einer Region platziert werden k\u00f6nnen \u2013 f\u00fcr Kunden, die in dieser Region arbeiten. REST-Handler und Autorisierungsserver sind f\u00fcr die Gesamtfunktionalit\u00e4t des Kunden weniger kritisch; man kann mit ihnen bei einer geringen akzeptablen Verz\u00f6gerung umschalten, aber wir m\u00f6chten das Rad nicht neu erfinden, wie man sie \u00fcberwacht und was man mit ihnen macht. Daher versuchen wir, so weit wie m\u00f6glich, bestehende L\u00f6sungen zu nutzen und nicht intern eine Kompetenz f\u00fcr zus\u00e4tzliche Produkte zu entwickeln. Und manchmal nutzen wir einfach DNS-Wechsel, wobei die Verf\u00fcgbarkeit des Dienstes ebenfalls \u00fcber die DNS ermittelt wird. Bei Amazon gibt es den Dienst Route 53, aber das ist nicht einfach nur ein DNS, in das man Eintr\u00e4ge einf\u00fcgen kann \u2013 es ist viel flexibler und benutzerfreundlicher. Dar\u00fcber hinaus kann man geo-verteilte Dienste mit Geolokalisierungen aufbauen, wenn man mit seiner Hilfe bestimmt, von wo der Kunde kommt, und ihm die entsprechenden Eintr\u00e4ge gibt \u2013 damit kann man Failover-Architekturen erstellen. Dieselben Health-Checks werden direkt in Route 53 konfiguriert; man gibt den zu \u00fcberwachenden Endpunkt an, definiert Metriken und legt fest, nach welchen Protokollen die \u201eLebendigkeit\u201c des Dienstes bestimmt werden soll \u2013 TCP, HTTP, HTTPS; man gibt die H\u00e4ufigkeit der Pr\u00fcfungen an, die bestimmen, ob der Dienst lebendig ist oder nicht. Und in den DNS selbst gibt man an, was primary und was secondary sein wird sowie wohin umgeschaltet wird, wenn ein Health-Check innerhalb von Route 53 aktiviert wird. All dies kann auch mit anderen Werkzeugen erledigt werden, aber der Vorteil ist, dass man es einmal konfiguriert und dann \u00fcberhaupt nicht mehr dar\u00fcber nachdenken muss, wie unsere Pr\u00fcfungen durchgef\u00fchrt werden und wie der Umschaltung erfolgt: alles funktioniert automatisch.<\/p>\n
Das erste \u201eAber\u201c<\/b>: Aber wie sollte man Route 53 sichern? Man wei\u00df ja nie, was passieren kann. Gl\u00fccklicherweise sind wir bisher nicht in diese Falle getappt, aber ich werde bald erz\u00e4hlen, warum wir dachten, dass eine Sicherung notwendig ist. Hier legen wir uns schon mal vornedran etwas zur\u00fcck. Mehrmals t\u00e4glich machen wir eine vollst\u00e4ndige Sicherung aller Zonen, die wir in Route 53 eingerichtet haben. Die API von Amazon erlaubt es, diese problemlos im JSON-Format zu \u00fcbergeben, und wir haben mehrere Backup-Server eingerichtet, auf die wir das umwandeln und als Konfigurationen speichern, um, grob gesagt, eine Backup-Konfiguration zu haben. Im Notfall k\u00f6nnen wir sie schnell manuell wiederherstellen, sodass wir die DNS-Einstellungen nicht verlieren.<\/p>\n
Zweites \u201eaber\u201c<\/b>: was in diesem Bild noch nicht reserviert ist? Der Load Balancer! Unsere Verteilung der Kunden nach Regionen erfolgt sehr einfach. Wir haben Domains wie bitrix24.ru, bitrix24.com, .de \u2013 insgesamt sind es jetzt etwa 13 verschiedene, die in den unterschiedlichsten Zonen arbeiten. Wir sind zu folgendem gekommen: In jeder Region gibt es eigene Load Balancer. Das erleichtert die Verteilung je nach regionaler Auslastung. Wenn ein einzelner Load Balancer ausf\u00e4llt, wird er einfach au\u00dfer Betrieb genommen und aus den DNS entfernt. Wenn es ein Problem mit einer Gruppe von Load Balancern gibt, werden diese auf anderen Plattformen reserviert, und der Wechsel zwischen ihnen erfolgt mithilfe von Route 53, da der Wechsel aufgrund der kurzen TTL maximal innerhalb von 2, 3, 5 Minuten stattfindet. <\/p>\n
Drittes \u201eaber\u201c<\/b>: was ist noch nicht reserviert? S3, richtig. Als wir die Dateien, die wir bei den Nutzern in S3 speichern, hochluden, waren wir \u00fcberzeugt, dass es eine zuverl\u00e4ssige L\u00f6sung ist und keine Reservierungen notwendig sind. Aber die Geschichte zeigt, dass es anders kommt. Im Allgemeinen beschreibt Amazon S3 als einen grundlegenden Service, weil Amazon selbst S3 zur Speicherung von Maschinenbildern, Konfigurationen, AMI-Images, Snapshots usw. verwendet. Und wenn S3 ausf\u00e4llt, wie es einmal in diesen 7 Jahren, in denen wir Bitrix24 nutzen, der Fall war, zieht es eine Menge Dinge mit sich \u2013 die Unzug\u00e4nglichkeit des Starts von VMs, St\u00f6rungen in der API usw. <\/p>\n
Und es kann passieren, dass S3 ausf\u00e4llt \u2013 das ist einmal passiert. Deshalb sind wir zu folgendem Schema gekommen: vor einigen Jahren gab es in Russland keine ernsthaften objektbasierten \u00f6ffentlichen Speichern, und wir haben dar\u00fcber nachgedacht, etwas Eigenes zu machen\u2026 Gl\u00fccklicherweise haben wir damit nicht begonnen, denn wir h\u00e4tten uns in eine Expertise vergraben, die wir nicht besitzen, und h\u00e4tten sicherlich Fehler gemacht. Jetzt gibt es S3-kompatible Speicher bei Mail.ru, bei Yandex und auch bei einigen anderen Anbietern. Schlie\u00dflich kamen wir zu dem Schluss, dass wir, erstens, eine Sicherung ben\u00f6tigen und, zweitens, die M\u00f6glichkeit haben wollen, mit lokalen Kopien zu arbeiten. F\u00fcr die spezifische russische Region nutzen wir den Service Mail.ru Hotbox, der \u00fcber API mit S3 kompatibel ist. Wir ben\u00f6tigten keine bedeutenden Anpassungen des Codes innerhalb der Anwendung, und wir haben folgenden Mechanismus entwickelt: In S3 gibt es Trigger, die bei der Erstellung\/L\u00f6schung von Objekten aktiviert werden, und Amazon hat einen solchen Service namens Lambda \u2013 das ist serverloses Ausf\u00fchren von Code, der genau beim Ausl\u00f6sen dieser Trigger ausgef\u00fchrt wird.<\/p>\n
Auf Code-Ebene sind f\u00fcr jeden Kunden beide Speicher definiert: einer wird als prim\u00e4r betrachtet, der andere als Backup. Wenn alles gut l\u00e4uft, arbeiten wir mit dem Speicher, der uns n\u00e4her ist: Das hei\u00dft, unsere Kunden in Amazon nutzen S3, w\u00e4hrend jene in Russland mit Hotbox arbeiten. Wenn das Flag aktiviert wird, muss unser Failover aktiviert werden, und wir schalten die Kunden auf einen anderen Speicher um. Dieses Flag k\u00f6nnen wir unabh\u00e4ngig nach Regionen setzen und die Kunden hin und her umschalten. In der Praxis haben wir es bisher nicht genutzt, aber wir haben diesen Mechanismus vorgesehen und glauben, dass wir irgendwann auf dieses Umschalten angewiesen sein werden. Es ist bereits einmal passiert. <\/p>\n
Oh, und euer Amazon ist abgehauen\u2026<\/h4>\n \nIn diesem April j\u00e4hrt sich die Einf\u00fchrung der Telegramm-Sperren in Russland. Der am st\u00e4rksten betroffene Anbieter, der darunter gelitten hat, ist Amazon. Leider haben vor allem russische Unternehmen, die weltweit t\u00e4tig waren, mehr schadhaft unter den Blockaden gelitten. <\/p>\n
Wenn ein Unternehmen global t\u00e4tig ist und Russland nur einen sehr kleinen Marktanteil von 3-5% hat \u2013 ja, dann kann man sie irgendwie opfern. <\/p>\n
Wenn es sich um ein rein russisches Unternehmen handelt \u2013 dann bin ich mir sicher, dass man lokal agieren muss \u2013 es w\u00e4re f\u00fcr die Nutzer einfach bequemer, komfortabler, mit weniger Risiken. <\/p>\n
Und wenn es sich um ein Unternehmen handelt, das global t\u00e4tig ist und etwa gleich viele Kunden aus Russland und anderen Teilen der Welt hat? Die Anbindung der Segmente ist wichtig, und sie m\u00fcssen miteinander arbeiten. <\/p>\n
Bereits Ende M\u00e4rz 2018 hat die Roskomnadzor den gr\u00f6\u00dften Anbietern ein Schreiben geschickt, in dem sie ank\u00fcndigten, mehrere Millionen IP-Adressen von Amazon zu sperren, um\u2026 den Messenger Zello zu blockieren. Dank dieser Provider wurde das Schreiben erfolgreich an alle weitergeleitet, und es entstand das Bewusstsein, dass die Anbindung an Amazon zusammenbrechen k\u00f6nnte. Es war ein Freitag, und wir rannten in Panik zu den Kollegen von servers.ru mit den Worten: 'Freunde, wir brauchen ein paar Server, die nicht in Russland, nicht in Amazon stehen, sondern zum Beispiel irgendwo in Amsterdam', um zumindest irgendwie die M\u00f6glichkeit zu haben, dort eigene zu platzieren. vpn<\/a> und einen Proxy f\u00fcr bestimmte Endpunkte, auf die wir keinen Einfluss haben, wie zum Beispiel die Endpunkte von S3 \u2014 es ist nicht m\u00f6glich, einen neuen Dienst zu starten und eine andere IP-Adresse zu bekommen, wir m\u00fcssen trotzdem darauf zugreifen. Innerhalb weniger Tage haben wir diese Server eingerichtet und in der Tat waren wir bis zum Zeitpunkt der ersten Blockierungen gut vorbereitet. Interessanterweise hat die Aufsichtsbeh\u00f6rde, nachdem sie den Aufruhr und die Panik gesehen hatte, gesagt: \u201eNein, wir werden jetzt nichts blockieren.\u201c (Aber das war genau bis zu dem Punkt, als sie mit der Blockierung von Telegram begannen.) Nachdem wir die Umgehungsma\u00dfnahmen eingerichtet hatten und feststellten, dass die Blockierung nicht eingef\u00fchrt wurde, haben wir jedoch beschlossen, das Ganze nicht weiter zu zerlegen. Sozusagen f\u00fcr alle F\u00e4lle. <\/p>\n
Und wie reserviert man\u2026 einen ganzen Anbieter?<\/h4>\n \nAktuell haben wir kein Szenario f\u00fcr den Ausfall von Amazon. F\u00fcr Russland haben wir ein \u00e4hnliches Szenario. Wir haben uns in Russland bei einem Anbieter in zwei verschiedenen Rechenzentren platziert. Vor einem Jahr hatten wir ein Problem: Auch wenn es zwei Rechenzentren sind, k\u00f6nnen bereits auf der Ebene der Netzwerkkonfiguration des Anbieters Probleme auftreten, die beide Rechenzentren betreffen. Dies kann zu Ausf\u00e4llen an beiden Standorten f\u00fchren. Genau das ist passiert. Wir haben die interne Architektur daraufhin \u00fcberdacht. Sie hat sich nicht grundlegend ver\u00e4ndert, aber jetzt haben wir in Russland zwei Standorte bei zwei unterschiedlichen Anbietern. Wenn einer ausf\u00e4llt, k\u00f6nnen wir auf den anderen umschalten.<\/p>\n
Hypothetisch ziehen wir f\u00fcr Amazon in Betracht, auf einer anderen Anbieter-Ebene Reservierungen vorzunehmen; vielleicht Google, vielleicht irgendwann auch andere\u2026 Aber bis jetzt haben wir in der Praxis beobachtet, dass Ausf\u00e4lle bei Amazon auf der Ebene einer Availability Zone zwar vorkommen, aber Ausf\u00e4lle auf regionaler Ebene sind eher selten. Daher haben wir theoretisch die Vorstellung, dass wir eventuell Reservierungen zwischen \"Amazon und Nicht-Amazon\" vornehmen, aber in der Praxis gibt es so etwas noch nicht. <\/p>\n
Ein paar Worte zur Automatisierung<\/h4>\n \nIst Automatisierung immer notwendig? Hier ist es angebracht, den Dunning-Kruger-Effekt zu erw\u00e4hnen. Auf der x-Achse haben wir unser Wissen und unsere gesammelten Erfahrungen, auf der y-Achse das Vertrauen in unser Handeln. Zuerst wissen wir nichts und sind v\u00f6llig ungewiss. Dann wissen wir ein wenig und werden mega-sicher \u2013 das ist der sogenannte \u201eGipfel der Dummheit\u201c, gut veranschaulicht durch das Bild \u201eTorheit und Mut\u201c. Danach haben wir schon ein wenig gelernt und sind bereit, in den Kampf zu ziehen. Dann treten wir auf einige mega-ernste Fallen und gelangen ins Tal der Verzweiflung, wo wir zwar etwas wissen, aber in Wirklichkeit wissen wir noch sehr viel weniger. Mit zunehmender Erfahrung werden wir dann selbstbewusster.<\/p>\n
Fazit<\/h4>\n \nIn 7 Jahren sind wir von dem Punkt gekommen, als etwas ausfiel \u2013 da war Panik-Panik, zu dem Verst\u00e4ndnis, dass es keine Probleme gibt, nur Aufgaben, die gel\u00f6st werden m\u00fcssen \u2013 und die kann man l\u00f6sen. Wenn Sie einen Service aufbauen, schauen Sie ihn aus einer h\u00f6heren Perspektive an, bewerten Sie alle Risiken, die auftreten k\u00f6nnten. Wenn Sie sie sofort sehen \u2013 planen Sie im Voraus Redundanz und die M\u00f6glichkeit, eine fehlertolerante Infrastruktur aufzubauen, denn jeder Punkt, der ausfallen kann und zu einem Ausfall des Services f\u00fchrt, wird es zwangsl\u00e4ufig tun. Und selbst wenn es Ihnen so scheint, als ob einige Elemente der Infrastruktur nicht ausfallen werden \u2013 wie das gleiche s3 \u2013 denken Sie daran, dass sie es trotzdem k\u00f6nnen. Und zumindest theorisch sollten Sie eine Vorstellung davon haben, was Sie mit ihnen tun werden, falls doch etwas passiert. Haben Sie einen Plan zur Risikominderung. Wenn Sie dar\u00fcber nachdenken, alles automatisiert oder manuell zu erledigen \u2013 bewerten Sie die Risiken: Was passiert, wenn die Automatisierung alles umschaltet \u2013 f\u00fchrt das nicht zu einem noch schlimmeren Szenario als bei einem Notfall? M\u00f6glicherweise ist es in einigen F\u00e4llen sinnvoll, einen vern\u00fcnftigen Kompromiss zwischen dem Einsatz von Automatisierung und der Reaktion des Bereitschaftsingenieurs zu finden, der das reale Bild beurteilt und versteht, ob er sofort etwas umschalten muss oder \u201eja, aber nicht jetzt\u201c.<\/p>\n
Ein vern\u00fcnftiger Kompromiss zwischen Perfektionismus und den realen Ressourcen, der Zeit und dem Geld, die Sie f\u00fcr das Schema aufwenden k\u00f6nnen, das Sie letztendlich haben werden.<\/p>\n
Dieser Text ist eine erg\u00e4nzte und erweiterte Version des Berichts von Alexander Demidov auf der Konferenz. Uptime Tag 4<\/a><\/noindex>.<\/i> 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
![\"\u201eBitrix24\u201c:](\"\/wp-content\/uploads\/2019\/06\/973fa076fc654237aa869d0ecb0dae9a.jpeg\")