Hallo, Habr! Ich betreue seit zehn Jahren Highload-IT-Systeme. Ich werde in diesem Artikel nicht über die Probleme beim Einrichten von Nginx für den Betrieb im 1000+ RPS-Modus oder andere technische Dinge schreiben. Ich werde meine Beobachtungen zu den Problemen in den Prozessen teilen, die bei der Unterstützung und dem Betrieb solcher Systeme auftreten.
Überwachung
Der technische Support wartet nicht, bis eine Anfrage mit dem Inhalt „Was warum... die Website funktioniert wieder nicht?“ eintrifft. Innerhalb einer Minute nach dem Absturz der Website sollte der Support das Problem bereits erkennen und mit der Lösung beginnen. Doch die Seite ist nur die Spitze des Eisbergs. Seine Verfügbarkeit ist eine der ersten, die überwacht wird.
Was tun, wenn die Restware eines Online-Shops nicht mehr aus dem ERP-System ankommt? Oder reagiert das CRM-System, das Rabatte für Kunden berechnet, nicht mehr? Die Seite scheint zu funktionieren. Bedingter Zabbix erhält seine 200-Antwort. Der Diensthabende hat keine Benachrichtigungen von der Überwachung erhalten und schaut sich voller Freude die erste Folge der neuen Staffel von Game of Thrones an.
Die Überwachung beschränkt sich oft nur auf die Messung des Zustands von Speicher, RAM und Serverprozessorauslastung. Für Unternehmen ist es jedoch viel wichtiger, die Produktverfügbarkeit auf der Website anzuzeigen. Der bedingte Ausfall einer virtuellen Maschine im Cluster führt dazu, dass der Datenverkehr nicht mehr dorthin geleitet wird und die Belastung anderer Server zunimmt. Das Unternehmen wird kein Geld verlieren.
Daher müssen Sie zusätzlich zur Überwachung der technischen Parameter von Betriebssystemen auf Servern auch Geschäftsmetriken konfigurieren. Kennzahlen, die sich direkt auf das Geld auswirken. Diverse Interaktionen mit externen Systemen (CRM, ERP und andere). Die Anzahl der Bestellungen für einen bestimmten Zeitraum. Erfolgreiche oder fehlgeschlagene Client-Autorisierungen und andere Metriken.
Interaktion mit externen Systemen
Jede Website oder mobile Anwendung mit einem Jahresumsatz von mehr als einer Milliarde Rubel interagiert mit externen Systemen. Angefangen beim oben erwähnten CRM und ERP bis hin zur Übertragung der Verkaufsdaten an ein externes Big-Data-System zur Analyse von Käufen und zum Angebot des Kunden an ein Produkt, das er definitiv kaufen wird (eigentlich nicht). Jedes dieser Systeme verfügt über seine eigene Unterstützung. Und oft verursacht die Kommunikation mit diesen Systemen Schmerzen. Vor allem, wenn das Problem global ist und Sie es in verschiedenen Systemen analysieren müssen.
Einige Systeme stellen ihren Administratoren eine Telefonnummer oder ein Telegramm zur Verfügung. Irgendwo müssen Sie Briefe an Manager schreiben oder zu den Bugtrackern dieser externen Systeme gehen. Selbst im Kontext eines großen Unternehmens laufen oft unterschiedliche Systeme in unterschiedlichen Anwendungsbuchhaltungssystemen. Manchmal ist es unmöglich, den Status einer Bewerbung zu verfolgen. Sie erhalten eine Anfrage in einem bedingten Jira. Dann fügen Sie im Kommentar dieses ersten Jira einen Link zum Problem in einem anderen Jira ein. Im zweiten Jira in der Anwendung schreibt bereits jemand einen Kommentar dazu Sie müssen den bedingten Administrator Andrey anrufen, um das Problem zu beheben. Und so weiter.
Die beste Lösung für dieses Problem wäre die Schaffung eines einzigen Raums für die Kommunikation, beispielsweise in Slack. Wir laden alle am Betrieb externer Systeme Beteiligten zur Teilnahme ein. Und auch ein einzelner Tracker, um doppelte Anwendungen zu vermeiden. Anwendungen sollten an einem Ort verfolgt werden, von Überwachungsbenachrichtigungen bis hin zur Ausgabe von Fehlerlösungen in der Zukunft. Sie werden sagen, dass dies unrealistisch ist und es in der Vergangenheit vorgekommen ist, dass wir in einem Tracker arbeiten und sie in einem anderen. Es erschienen verschiedene Systeme, sie hatten ihre eigenen autonomen IT-Teams. Ich stimme zu und daher muss das Problem von oben auf der CIO- oder Product Owner-Ebene gelöst werden.
Jedes System, mit dem Sie interagieren, sollte Support als Service mit einem klaren SLA zur Lösung von Problemen nach Priorität bereitstellen. Und nicht, wenn der bedingte Administrator Andrey eine Minute für Sie hat.
Flaschenhals-Mann
Gibt es bei jedem, der an einem Projekt (oder Produkt) beteiligt ist, eine Person, deren Urlaub bei ihren Vorgesetzten für Aufregung sorgt? Dies kann ein DevOps-Ingenieur, Analyst oder Entwickler sein. Denn nur ein DevOps-Ingenieur weiß, auf welchen Servern welche Container installiert sind, wie er den Container im Falle eines Problems neu starten kann, und im Allgemeinen kann kein komplexes Problem ohne ihn gelöst werden. Der Analytiker ist der Einzige, der weiß, wie Ihr komplexer Mechanismus funktioniert. Welche Datenströme gehen wohin? Unter welchen Parametern von Anfragen zu welchen Diensten erhalten wir Antworten.
Wer versteht schnell, warum es Fehler in den Protokollen gibt und behebt einen kritischen Fehler im Produkt umgehend? Natürlich derselbe Entwickler. Es gibt noch andere, aber aus irgendeinem Grund versteht nur er, wie die verschiedenen Module des Systems funktionieren.
Die Ursache dieses Problems liegt in der fehlenden Dokumentation. Denn wenn alle Dienste Ihres Systems beschrieben wären, wäre es möglich, das Problem ohne einen Analysten zu lösen. Wenn sich Entwickler ein paar Tage Zeit nehmen würden, um alle Server, Dienste und Anweisungen zur Lösung typischer Probleme zu beschreiben, könnte das Problem in seiner Abwesenheit auch ohne ihn gelöst werden. Sie müssen im Urlaub nicht schnell Ihr Bier am Strand austrinken und nach WLAN suchen, um das Problem zu lösen.
Kompetenz und Verantwortung des Supportpersonals
Bei großen Projekten sparen Unternehmen nicht an den Entwicklergehältern. Sie suchen teure Mittel- oder Senioren aus ähnlichen Projekten. Bei der Unterstützung ist die Situation etwas anders. Sie versuchen, diese Kosten auf jede erdenkliche Weise zu reduzieren. Unternehmen stellen günstig die Enikey-Arbeiter von gestern ein und ziehen mutig in die Schlacht. Diese Strategie ist möglich, wenn es sich um eine Visitenkarten-Website eines Werks in Selenograd handelt.
Wenn es sich um einen großen Online-Shop handelt, kostet jede Stunde Ausfallzeit mehr als das Monatsgehalt eines Enikey-Administrators. Nehmen wir als Ausgangspunkt 1 Milliarde Rubel Jahresumsatz. Dies ist der Mindestumsatz eines jeden Online-Shops aus der Bewertung . Teilen Sie diesen Betrag durch die Anzahl der Stunden pro Jahr und erhalten Sie einen Nettoverlust von mehr als 100 Rubel. Und wenn Sie die Nachtstunden nicht mitzählen, können Sie den Betrag getrost verdoppeln.
Aber Geld ist nicht die Hauptsache, oder? (Nein, natürlich die Hauptsache) Es gibt auch Reputationsverluste. Der Untergang eines bekannten Online-Shops kann sowohl eine Welle von Rezensionen in sozialen Netzwerken als auch Veröffentlichungen in thematischen Medien auslösen. Und die Gespräche von Freunden in der Küche im Stile „Kauft dort nichts, ihre Website ist immer down“ sind überhaupt nicht messbar.
Nun zur Verantwortung. In meiner Praxis gab es einen Fall, in dem der diensthabende Administrator nicht rechtzeitig auf eine Benachrichtigung des Überwachungssystems über die Nichtverfügbarkeit der Website reagierte. An einem angenehmen Sommerfreitagabend lag die Website eines bekannten Online-Shops in Moskau ruhig da. Am Samstagmorgen verstand der Produktmanager dieser Site nicht, warum die Site nicht geöffnet wurde, und es herrschte Stille in den Support- und dringenden Benachrichtigungschats in Slack. Ein solcher Fehler kostete uns einen sechsstelligen Betrag und diesen diensthabenden Beamten seinen Job.
Verantwortung ist eine schwierig zu entwickelnde Fähigkeit. Entweder hat jemand es oder nicht. Deshalb versuche ich in Vorstellungsgesprächen, das Vorhandensein dieser Funktion anhand verschiedener Fragen festzustellen, die indirekt zeigen, ob eine Person es gewohnt ist, Verantwortung zu übernehmen. Wenn jemand antwortet, dass er sich für eine Universität entschieden hat, weil seine Eltern es so gesagt haben, oder den Job wechselt, weil seine Frau gesagt hat, dass er nicht genug verdient, dann ist es besser, sich nicht auf solche Leute einzulassen.
Interaktion mit dem Entwicklungsteam
Wenn Anwender im laufenden Betrieb mit einem Produkt auf einfache Probleme stoßen, löst der Support diese selbstständig. Versucht, das Problem zu reproduzieren, analysiert die Protokolle usw. Aber was tun, wenn ein Fehler im Produkt auftritt? In diesem Fall weist der Support den Entwicklern die Aufgabe zu und schon beginnt der Spaß.
Entwickler sind ständig überlastet. Sie erstellen neue Funktionen. Das Beheben von Fehlern beim Verkauf ist nicht die interessanteste Aktivität. Die Fristen für den Abschluss des nächsten Sprints rücken näher. Und dann kommen unangenehme Leute vom Support und sagen: „Kündigt sofort alles, wir haben Probleme.“ Die Priorität solcher Aufgaben ist minimal. Vor allem, wenn das Problem nicht das kritischste ist und die Hauptfunktionalität der Site funktioniert, und wenn der Release-Manager nicht mit großen Augen herumläuft und schreibt: „Fügen Sie diese Aufgabe dringend zum nächsten Release oder Hotfix hinzu.“
Probleme mit normaler oder niedriger Priorität werden von Release zu Release verschoben. Auf die Frage „Wann wird die Aufgabe erledigt sein?“ Sie erhalten Antworten im Stil von: „Es tut uns leid, es gibt gerade viele Aufgaben, fragen Sie Ihren Teamleiter oder Release-Manager.“
Produktivitätsprobleme haben eine höhere Priorität als die Erstellung neuer Funktionen. Schlechte Bewertungen werden nicht lange auf sich warten lassen, wenn Benutzer ständig auf Fehler stoßen. Ein beschädigter Ruf lässt sich nur schwer wiederherstellen.
Probleme der Interaktion zwischen Entwicklung und Support werden durch DevOps gelöst. Diese Abkürzung wird häufig in Form einer bestimmten Person verwendet, die beim Erstellen von Testumgebungen für die Entwicklung hilft, CICD-Pipelines erstellt und getesteten Code schnell in die Produktion bringt. DevOps ist ein Ansatz zur Softwareentwicklung, bei dem alle Prozessbeteiligten eng miteinander interagieren und dabei helfen, Softwareprodukte und -dienste schnell zu erstellen und zu aktualisieren. Ich meine Analysten, Entwickler, Tester und Support.
Bei diesem Ansatz sind Support und Entwicklung keine unterschiedlichen Abteilungen mit eigenen Zielen und Vorgaben. Die Entwicklung ist am Betrieb beteiligt und umgekehrt. Der berühmte Satz verteilter Teams: „Das Problem liegt nicht auf meiner Seite“ taucht in Chats nicht mehr so oft auf und die Endbenutzer werden etwas zufriedener.
Source: habr.com