Im Sommer nehmen sowohl die Einkaufsaktivität als auch die Intensität der Änderungen in der Infrastruktur von Webprojekten traditionell ab, so Captain Evidence. Nur weil sogar IT-Leute Urlaub machen. Und CTO auch. Es ist umso schwieriger für diejenigen, die auf dem Posten bleiben, aber jetzt nicht darüber: Vielleicht ist der Sommer deshalb die beste Zeit, um das bestehende Reservierungsschema zu durchlaufen und einen Plan für dessen Verbesserung zu erstellen. Dabei profitieren Sie von der Erfahrung von Yegor Andreev von AdminDivision , über die er auf der Uptime Day- Konferenz gesprochen hat.Während des Baus von Reservaten gibt es während der Reservierung mehrere Fallen, in die Sie fallen können. Und in sie hineinzufallen ist absolut unmöglich. Und uns in all dem und in vielen anderen Dingen, Perfektionismus und ... Faulheit zu ruinieren. Wir versuchen alles - alles - alles ist perfekt, aber Sie müssen es nicht perfekt machen! Es ist nur notwendig, bestimmte Dinge zu tun, aber sie richtig zu machen, um sie zum Ende zu bringen, damit sie normal funktionieren.
Failover ist keine lustige Sache. Es ist eine Sache, die genau eines tun sollte - Ausfallzeiten zu reduzieren, damit der Service, das Unternehmen, weniger Geld verliert. Und bei allen Reservierungsmethoden schlage ich vor, im folgenden Kontext zu denken: Wo ist das Geld?
Die erste Falle : Wenn wir große, zuverlässige Systeme erstellen und Backups erstellen, reduzieren wir die Anzahl der Unfälle. Dies ist ein schrecklicher Irrtum. Wenn wir Backups durchführen, erhöhen wir höchstwahrscheinlich die Anzahl der Unfälle. Und wenn wir alles richtig machen, reduzieren wir gemeinsam Ausfallzeiten. Es wird mehr Unfälle geben, aber sie werden zu geringeren Kosten auftreten. Was ist Redundanz? Ist eine Komplikation des Systems. Jede Komplikation ist schlimm: Wir bekommen mehr Zahnräder, mehr Zahnräder, mit einem Wort, mehr Elemente - und damit eine höhere Ausfallwahrscheinlichkeit. Und sie brechen wirklich. Und sie werden öfter brechen. Ein einfaches Beispiel: Nehmen wir an, wir haben eine Website mit PHP, MySQL. Und er muss dringend reserviert werden.
Shtosh (c) Wir nehmen den zweiten Standort, wir bauen ein identisches System ... Die Komplexität wird doppelt so groß - wir haben zwei Einheiten. Außerdem rollen wir eine bestimmte Logik der Datenübertragung von einer Plattform auf eine andere von oben - dh Datenreplikation, Kopieren von Statiken usw. Daher ist die Replikationslogik normalerweise sehr komplex, und daher ist die Gesamtkomplexität des Systems möglicherweise nicht 2, sondern 3, 5, 10 Mal höher.
Die zweite Falle : Wenn wir wirklich große komplexe Systeme bauen, phantasieren wir, was wir am Ende erreichen wollen. Voila: Wir möchten ein äußerst zuverlässiges System, das ohne Ausfallzeiten funktioniert, in einer halben Sekunde (oder besser im Allgemeinen sofort) umschaltet und beginnt, Träume in die Realität umzusetzen. Es gibt aber auch eine Nuance: Je kürzer die gewünschte Schaltzeit ist, desto komplexer wird die Systemlogik. Je schwieriger wir diese Logik ausführen müssen, desto häufiger bricht das System zusammen. Und Sie können in eine sehr unangenehme Situation geraten: Wir tun unser Bestes, um die Ausfallzeiten zu reduzieren, aber tatsächlich erschweren wir die Dinge, und wenn etwas schief geht, werden die Ausfallzeiten länger sein. Hier ertappt man sich oft beim Denken: Hier ... wäre es besser, wenn sie nicht reserviert worden wären. Es wäre besser, wenn es alleine mit einer verständlichen Ausfallzeit funktionieren würde.
Wie gehe ich damit um? Wir müssen aufhören, uns selbst anzulügen, aufhören, uns zu schmeicheln, dass wir hier ein Raumschiff bauen werden, aber angemessen verstehen, wie viel das Projekt hinlegen kann. Und für diese maximale Zeit werden wir wählen, mit welchen Methoden wir tatsächlich die Zuverlässigkeit unseres Systems erhöhen.
Es ist Zeit für "Geschichten aus w" ... natürlich aus dem Leben.
Beispiel Nummer eins
Stellen Sie sich die Standortkarte des Rohrwalzwerks Nr. 1 der Stadt N vor. Sie ist in großen Buchstaben darauf geschrieben - PIPELINE PLANT Nr. 1. Etwas tiefer - der Slogan: "Unsere Pfeifen sind die rundesten Pfeifen in N". Und unter der Telefonnummer des CEO und seinem Namen. Wir verstehen, dass Sie reservieren müssen - das ist eine sehr wichtige Sache! Wir beginnen zu verstehen, woraus es besteht. HTML-Statik - das sind ein paar Bilder, auf denen der General tatsächlich am Tisch im Bad mit seinem Partner über einen nächsten Deal spricht. Wir beginnen über Ausfallzeiten nachzudenken. Es fällt mir ein: Sie müssen fünf Minuten dort liegen, nicht mehr. Und dann ist die Frage: Wie viel Umsatz von dieser Website waren im Allgemeinen? Wie viel wie viel? Was bedeutet Null? Und das heißt: Weil der General im vergangenen Jahr alle vier Transaktionen am selben Tisch getätigt hat und dieselben Personen, mit denen sie ins Badehaus gehen, am Tisch sitzen. Und wir verstehen, dass es nichts Schreckliches geben wird, selbst wenn sich die Site für einen Tag hinlegt.
Basierend auf der Einführung gibt es einen Tag, um diese Geschichte anzusprechen. Wir beginnen über das Backup-Schema nachzudenken. Und wir wählen das idealste Sicherungsschema für dieses Beispiel aus: Wir verwenden keine Redundanz. Diese ganze Sache steigt von jedem Administrator für eine halbe Stunde mit Rauchpausen auf. Das Einlegen eines Webservers und das Einfügen von Dateien ist alles. Es wird funktionieren. Sie müssen nichts befolgen, Sie müssen nichts Besonderes beachten. Das heißt, die Schlussfolgerung aus Beispiel Nummer eins ist ziemlich offensichtlich: Dienste, die Sie nicht reservieren müssen, werden nicht benötigt.
Beispiel Nummer zwei
Firmenblog: Speziell geschulte schreiben dort Nachrichten, also haben wir an so und so einer Ausstellung teilgenommen, aber hier haben wir ein weiteres neues Produkt veröffentlicht und so weiter. Nehmen wir an, dies ist Standard-PHP mit WordPress, einer kleinen Datenbank und etwas Statik. Natürlich fällt mir wieder ein, dass du niemals lügen solltest - "nicht mehr als fünf Minuten!", Das ist alles. Aber lasst uns weiter überlegen. Was macht dieser Blog? Sie kommen von Yandex, von Google auf einige Anfragen, auf Bio. Wow. Und haben Verkäufe überhaupt etwas mit ihm zu tun? Einblick: nicht wirklich. Der Werbeverkehr geht zur Hauptseite, die sich auf einem anderen Computer befindet. Wir beginnen über das Reservierungsschema für Broschüren nachzudenken. Auf eine gute Weise muss es in ein paar Stunden angehoben werden, und es wäre schön, sich darauf vorzubereiten. Es wäre vernünftig, einen Computer in ein anderes Rechenzentrum zu bringen, die Umgebung darauf zu steuern, dh einen Webserver, PHP, WordPress, MySQL, und ihn liegen zu lassen. In dem Moment, in dem wir verstehen, dass alles kaputt ist, müssen zwei Dinge getan werden: Rollen Sie den MySQL-Dump auf 50 Meter, er wird in einer Minute dorthin fliegen und einige Bilder aus dem Backup dort rollen. Auch das sind dort keine guten Nachrichten. So steigt in einer halben Stunde das Ganze auf. Keine Replikationen oder Gott vergib mir, automatisches Failover. Fazit: Was wir schnell aus dem Backup herausholen können, muss nicht reserviert werden.
Beispiel Nummer drei, komplizierter
Online-Shop. PhP mit offenem Herzen ist ein bisschen abgelegt, MySQL mit einer festen Basis. Ziemlich statisch (schließlich hat der Online-Shop wunderschöne HD-Bilder und all diesen Jazz), Redis für die Sitzung und Elasticsearch für die Suche. Wir beginnen über Ausfallzeiten nachzudenken. Und hier ist es natürlich offensichtlich, dass ein Online-Shop den Tag nicht schmerzlos suhlen kann. Denn je länger es liegt, desto mehr Geld verlieren wir. Es lohnt sich zu beschleunigen. Wie viel? Ich glaube, wenn wir uns eine Stunde hinlegen, wird niemand verrückt. Ja, wir werden etwas verlieren, aber wenn wir anfangen zu eifern, wird es nur noch schlimmer. Wir bestimmen die zulässige Leerlaufzeit pro Stunde.
Wie kann das alles reserviert werden? Eine Maschine wird auf jeden Fall benötigt: Eine Stunde Zeit ist ziemlich viel. MySQL: Replikation, Live-Replikation ist hier bereits erforderlich, da in einer Stunde 100 GB in einem Dump höchstwahrscheinlich nicht fließen werden. Statik, Bilder: Auch in einer Stunde haben 500 GB möglicherweise keine Zeit zum Zusammenführen. Daher ist es besser, Bilder sofort zu kopieren. Redis: interessanter hier. Die Sitzungen finden in Redis statt - wir können es einfach nicht nehmen und begraben. Weil es nicht sehr gut sein wird: Alle Benutzer werden abgemeldet, Körbe geleert und so weiter. Personen werden gezwungen sein, ihren Benutzernamen und ihr Passwort erneut einzugeben, und viele Personen können sich möglicherweise trennen und den Kauf nicht abschließen. Auch hier wird die Konvertierung fallen. Auf der anderen Seite ist Redis direkt eins zu eins relevant, wobei die zuletzt angemeldeten Benutzer wahrscheinlich auch nicht benötigt werden. Ein guter Kompromiss besteht darin, Redis zu nehmen und es gestern aus dem Backup wiederherzustellen, oder, wenn Sie es jede Stunde tun, vor einer Stunde. Der Vorteil der Wiederherstellung aus dem Backup besteht darin, dass eine Datei kopiert wird. Und die interessanteste Geschichte ist Elasticsearch. Wer hat jemals die MySQL-Replikation ausgelöst? Wer hat jemals die Elasticsearch-Replikation ausgelöst? Und nach wem hat sie normal gearbeitet? Was mache ich: Wir sehen eine bestimmte Entität in unserem System. Es scheint nützlich zu sein - aber es ist kompliziert.
Komplex in dem Sinne, dass unsere Kollegen keine Erfahrung damit haben. Oder es gibt eine negative Erfahrung. Oder wir verstehen, dass dies bisher eine ziemlich neue Technologie mit Nuancen oder Feuchtigkeit ist. Wir denken ... Verdammt, elastisch ist auch gesund, es dauert auch lange, bis es aus dem Backup wiederhergestellt ist. Was soll ich tun? Wir verstehen, dass in unserem Fall Gummiband für die Suche verwendet wird. Und wie verkauft sich unser Online-Shop? Wir gehen zu Vermarktern und fragen, woher die Leute kommen. Sie antworten: "90% des Yandex-Marktes kommen direkt auf die Produktkarte." Und entweder kaufen oder nicht. Daher benötigen 10% der Benutzer eine Suche. Und um eine elastische Replikation aufrechtzuerhalten, insbesondere zwischen verschiedenen Rechenzentren in verschiedenen Zonen, gibt es wirklich viele Nuancen. Was ist der Ausweg? Wir nehmen Gummiband auf einer reservierten Seite und machen nichts damit. Wenn sich der Fall hinzieht, werden wir ihn wahrscheinlich eines Tages ansprechen, aber das ist nicht sicher. Tatsächlich ist die Plus- oder Minus-Schlussfolgerung dieselbe: Wir reservieren wiederum keine Dienstleistungen, die keinen Einfluss auf das Geld haben. Um die Schaltung einfacher zu halten.
Beispiel Nummer vier, noch schwieriger
Integrator: Blumen verkaufen, Taxi rufen, Waren verkaufen, im Allgemeinen alles. Eine ernste Sache, die für eine große Anzahl von Benutzern rund um die Uhr funktioniert. Mit einem vollwertigen interessanten Stapel, wo es interessante Grundlagen, Lösungen, eine hohe Last gibt und vor allem tut es ihm weh, mehr als 5 Minuten zu liegen. Nicht nur und nicht so sehr, weil die Leute nicht kaufen werden, sondern weil die Leute sehen werden, dass dieses Ding nicht funktioniert, werden sie verärgert sein und möglicherweise nicht zum zweiten Mal zurückkommen.
Okay Fünf Minuten. Was machen wir damit? In diesem Fall sind wir erwachsen, mit all dem Geld bauen wir eine echte Backup-Site auf, mit der Replikation von allem und jedem, und automatisieren vielleicht sogar den maximalen Wechsel zu dieser Site. Und außerdem darf man nicht vergessen, eine wichtige Sache zu tun: Schreiben Sie den Schaltplan. Vorschriften können sehr einfach sein, selbst wenn Sie alles automatisiert haben. Klicken Sie in der Serie "Führen Sie so und so ein ansibles Skript aus" auf "Klicken Sie so und so auf Route 53" usw. - dies sollte jedoch eine genaue Liste der Aktionen sein.
Und alles scheint klar zu sein. Das Wechseln der Replikation ist eine triviale Aufgabe, oder sie wechselt von selbst. Schreiben Sie einen Domainnamen in DNS neu - aus derselben Serie. Das Problem ist, dass bei einem Absturz eines ähnlichen Projekts Panik einsetzt und selbst die mächtigsten bärtigen Administratoren dazu neigen können. Ohne eine klare Anweisung „Öffnen Sie ein Terminal, kommen Sie hierher, die Adresse auf unserem Server ist immer noch so“ ist die für die Wiederbelebung zugewiesene Laufzeit von 5 Minuten schwer aufrechtzuerhalten. Wenn wir diese Vorschriften verwenden, ist es außerdem einfach, einige Änderungen in der Infrastruktur zu beheben und die Vorschriften entsprechend zu ändern.
Wenn das Backup-System sehr komplex ist und wir irgendwann einen Fehler gemacht haben, können wir auch unsere Reserveseite einrichten und außerdem die Daten an beiden Seiten in einen Kürbis verwandeln - das wird wirklich traurig.
Beispiel Nummer fünf, voller Hardcore
Ein internationaler Dienst mit Hunderten Millionen Nutzern weltweit. Alle Zeitzonen, die nur existieren, Hochlast bei maximaler Geschwindigkeit, sollten Sie überhaupt nicht lügen. Eine Minute - und es wird traurig sein. Was zu tun ist? Reservieren Sie erneut in vollem Umfang. Sie haben alles getan, was im vorherigen Beispiel erwähnt wurde, und noch ein bisschen mehr. Eine ideale Welt und unsere Infrastruktur - nach allen Konzepten des IaaC-Devopa. Das heißt, alles im Allgemeinen in Git, und klicken Sie einfach auf die Schaltfläche.
Was fehlt? Eines ist die Lehre. Sie können nicht ohne sie auskommen. Es scheint, dass bei uns alles perfekt ist, alles im Allgemeinen unter Kontrolle ist. Wir drücken den Knopf, alles passiert. Selbst wenn dies so ist - und wir verstehen, dass dies nicht der Fall ist -, interagiert unser System mit einigen anderen Systemen. Dies sind beispielsweise DNS aus Route 53, S3-Speicher, Integration mit einigen APIs. Wir werden in diesem spekulativen Experiment nicht alles vorhersehen können. Und bis wir wirklich den Schalter ziehen, wissen wir nicht, ob es funktionieren wird oder nicht.
Das ist wahrscheinlich alles. Sei nicht faul und übertreibe es nicht. Und möge die Betriebszeit bei Ihnen sein!