Hallo, Habr! Seit zehn Jahren unterstütze ich Highload-IT-Systeme. In diesem Artikel werde ich nicht über die Probleme bei der Konfiguration von Nginx für einen Betrieb mit über 1000 RPS oder andere technische Dinge schreiben. Stattdessen teile ich meine Beobachtungen zu den Herausforderungen in den Prozessen, die im Support und Betrieb solcher Systeme auftreten.
Überwachung
Der Support wartet nicht darauf, dass eine Anfrage mit dem Inhalt "Warum… funktioniert die Website schon wieder nicht?" eintrifft. Der Support sollte bereits eine Minute nach dem Ausfall der Website das Problem erkennen und mit der Lösung beginnen. Die Website ist jedoch nur die Spitze des Eisbergs.Ihre Verfügbarkeit wird als eine der ersten Metriken überwacht.
Wie geht man mit der Situation um, wenn die Lagerbestände des Online-Shops aus dem ERP-System nicht mehr aktualisiert werden? Oder wenn das CRM-System, das Rabatte für Kunden berechnet, nicht mehr antwortet? Die Website selbst sieht dabei funktionsfähig aus. Ein hypothetisches Zabbix erhält seine 200-Antwort. Der Bereitschaftsdienst hat keine Benachrichtigungen vom Monitoring erhalten und schaut sich glücklich die erste Episode der neuen Staffel von "Game of Thrones" an.
Oft beschränkt sich das Monitoring lediglich auf die Messung des Zustands von Speicher, RAM und der CPU-Auslastung. Server. Für Unternehmen ist es viel wichtiger, die Verfügbarkeit der Produkte auf der Website sicherzustellen. Ein vorübergehender Ausfall einer virtuellen Maschine im Cluster kann dazu führen, dass der Traffic stoppt und die Last auf andere Server ansteigt. Das Unternehmen wird dabei keine finanziellen Einbußen erleiden.
Deshalb ist es notwendig, neben der Überwachung der technischen Parameter der Betriebssysteme auf den Servern auch Geschäftskennzahlen zu konfigurieren. Diese Kennzahlen haben direkten Einfluss auf finanzielle Aspekte. Dazu gehören verschiedene Interaktionen mit externen Systemen (wie CRM, ERP usw.), die Anzahl der Bestellungen in einem bestimmten Zeitraum, erfolgreiche oder gescheiterte Kundenanmeldungen und weitere Kennzahlen.
Interaktion mit externen Systemen
Jede Website oder mobile Anwendung mit einem Jahresumsatz von über einer Milliarde Rubel interagiert mit externen Systemen. Von den bereits erwähnten CRM- und ERP-Systemen bis hin zur Datenübertragung über Verkäufe an externe Big-Data-Analyse-Systeme, die dem Kunden ein Produkt vorschlagen, das er definitiv kaufen wird (in Wirklichkeit jedoch nicht). Jedes dieser Systeme verfügt über eigenen Support. Oft ist die Kommunikation mit diesen Systemen schmerzhaft. Besonders wenn es sich um ein globales Problem handelt, das in verschiedenen Systemen analysiert werden muss.
Einige Systeme bieten eine Telefonnummer oder Telegram-Kontakt für ihre Administratoren an. An anderen Orten muss man E-Mails an Manager schreiben oder in den Bug-Trackern dieser externen Systeme nachsehen. Selbst in einem großen Unternehmen arbeiten unterschiedliche Systeme oft in verschiedenen Ticketverwaltungssystemen. Den Status eines Tickets nachzuverfolgen, kann manchmal unmöglich sein. Du erhältst ein Ticket in einem hypothetischen Jira. Dann fügst du in den Kommentaren zu diesem ersten Jira einen Link zu einem Ticket in einem anderen Jira hinzu. In diesem zweiten Jira hinterlässt bereits jemand einen Kommentar, dass man den hypothetischen Administrator Andrey anrufen muss, um das Problem zu lösen. Und so weiter.
Eine optimale Lösung für dieses Problem wäre die Schaffung eines einheitlichen Kommunikationsraums, beispielsweise in Slack. Alle Beteiligten am Betrieb externer Systeme sollten eingeladen werden, und es sollte einen gemeinsamen Tracker geben, um Anfragen nicht zu duplizieren. Alle Anfragen müssen an einem zentralen Ort verfolgt werden, beginnend von den Alarmmeldungen des Monitorings bis hin zur Behebung von Bugs in der Produktion. Sie könnten sagen, dass dies unrealistisch ist, weil es historisch so gewachsen ist, dass wir in einem Tracker arbeiten, während andere in einem anderen System. Es gab verschiedene Systeme, und jede hatte ihre eigenen autonomen IT-Teams. Ich stimme zu, und daher muss das Problem auf der Ebene des CIO oder Product Owners angegangen werden.
Jedes System, mit dem Sie interagieren, sollte Support als Dienstleistung anbieten, mit klaren SLAs zur Problemlösung nach Prioritäten. Und nicht erst, wenn der Administrator Andrej einen Moment Zeit für Sie findet.
Der Mensch ist die Engstelle.
Gibt es bei Ihrem Projekt (oder Produkt) jemanden, dessen Abwesenheit im Urlaub das Management in Aufregung versetzt? Das könnte ein DevOps-Ingenieur, ein Analyst oder ein Entwickler sein. Nur der DevOps-Ingenieur weiß schließlich, auf welchen Servern welche Container installiert sind und wie man einen Container bei Problemen neu startet. Und generell lässt sich ohne ihn kein komplexes Problem lösen. Der Analyst ist der Einzige, der versteht, wie Ihr kompliziertes System funktioniert — wo die Datenströme hingehen, welche Anfrageparameter an welche Dienste gesendet werden und welche Antworten wir erhalten.
Wer wird schnell verstehen, warum es Fehler in den Logs gibt und umgehend einen kritischen Bug in der Produktion beheben? Natürlich der Entwickler. Es gibt auch andere, aber nur er versteht, wie die verschiedenen Module des Systems eingerichtet sind.
Wurzel dieses Problems ist der Mangel an Dokumentation.. Wenn alle Dienste Ihres Systems dokumentiert wären, könnte das Problem auch ohne Analyst gelöst werden. Wenn DevOps ein paar Tage aus seinem vollen Zeitplan befreien würde, um alle Server, Dienste und Anweisungen zur Lösung typischer Probleme zu beschreiben, könnte das Problem auch in seiner Abwesenheit gelöst werden. Man muss im Urlaub nicht schnell sein Bier am Strand trinken und nach Wi-Fi suchen, um ein Problem zu lösen.
Kompetenz und Verantwortung der Support-Mitarbeiter
Bei großen Projekten spart das Unternehmen nicht bei den Gehältern der Entwickler. Sie suchen gezielt nach teuren Mid-Level- oder Senior-Entwicklern aus ähnlichen Projekten. Bei der Unterstützung sieht die Situation etwas anders aus. Diese Kosten werden nach Kräften versucht zu minimieren. Unternehmen stellen preiswerte, frisch ausgebildete Techniker ein und gehen mutig in die Offensive. Eine solche Strategie ist möglich, wenn es sich um die Visitenkarte einer Fabrik in Zelenograd handelt.
Spricht man von einem großen Online-Shop, dann kostet jede Stunde Standzeit mehr als das monatliche Gehalt eines Admin-Technikers. Nehmen wir einen Jahresumsatz von 1 Milliarde Rubel als Ausgangspunkt. Das ist der Mindestumsatz eines jeden Online-Shops aus dem Ranking Teilen wir diesen Betrag durch die Anzahl der Stunden im Jahr, ergeben sich mehr als 100.000 Rubel an reinen Verlusten. Wenn wir die Nachtstunden außer Betracht lassen, kann man diesen Betrag sogar verdoppeln.
Aber Geld ist doch nicht alles, oder? (nein, natürlich ist es wichtig) Es gibt auch reputative Verluste. Eine Stunde Ausfallzeit eines bekannten Online-Shops kann sowohl eine Flut von Kommentaren in sozialen Medien als auch Veröffentlichungen in Fachzeitschriften auslösen. Und Gespräche von Freunden am Küchentisch wie „Kauf dort nichts, deren Website funktioniert ständig nicht“ sind überhaupt nicht messbar.
Kommen wir nun zur Verantwortung. In meiner Erfahrung gab es einen Fall, in dem der diensthabende Administrator nicht rechtzeitig auf die Meldung des Überwachungssystems über die Unerreichbarkeit der Website reagierte. An einem angenehmen Sommerfreitagabend lag die Website eines bekannten Online-Shops in Moskau still. Am Samstagmorgen verstand der Produktmanager dieser Website nicht, warum die Seite nicht geöffnet werden kann, während in den Support-Chats und dringenden Slack-Benachrichtigungen komplette Stille herrschte. Dieser Fehler kostete uns einen sechsstelligen Betrag, und der diensthabende Administrator verlor seinen Job.
Verantwortung ist eine Fähigkeit, die schwer zu entwickeln ist. Es ist eine Frage von persönlicher Verantwortung. Deshalb versuche ich in Vorstellungsgesprächen, diese Verantwortung durch verschiedene Fragen zu ermitteln, die indirekt zeigen, ob jemand bereit ist, Verantwortung zu übernehmen. Wenn jemand sagt, er habe sich für die Universität entschieden, weil es die Eltern gesagt haben, oder den Job wechselt, weil die Frau meint, er verdient zu wenig, dann sollte man mit solchen Personen besser nicht zusammenarbeiten.
Zusammenarbeit mit dem Entwicklungsteam
Wenn bei den Nutzern im Produktivbetrieb kleinere Probleme auftreten, löst der Support diese selbstständig. Er versucht, das Problem nachzustellen, analysiert Protokolle und so weiter. Aber was passiert, wenn ein Fehler im Produktionsbetrieb auftritt? In diesem Fall eröffnet der Support ein Ticket für die Entwickler, und hier wird es richtig interessant.
Die Entwickler sind ständig überlastet. Das Entwicklerteam konzentriert sich auf die Entwicklung neuer Funktionen. Bugs in der Produktion zu beheben ist, sagen wir, nicht die spannendste Aufgabe. Die Fristen zur Fertigstellung des aktuellen Sprints sind knapp. Doch dann kommen unangenehme Leute aus dem Support und sagen: 'Hör sofort auf alles, wir haben Probleme.' Der Prioritätsgrad solcher Aufgaben ist minimal. Besonders, wenn das Problem nicht kritisch ist, die Hauptfunktionen der Website jedoch funktionieren und der Release-Manager nicht mit weit aufgerissenen Augen umherläuft und sagt: 'Bitte fügt diese Aufgabe schnell in den nächsten Release oder Hotfix ein.'
Aufgaben mit normaler oder niedriger Priorität werden von Release zu Release verschoben. Auf die Frage 'Wann wird die Aufgabe erledigt sein?' bekommst du Antworten wie: 'Tut mir leid, im Moment sind viele Aufgaben, frag die Teamleiter oder den Release-Manager.'
Probleme in der Produktionsumgebung haben eine höhere Priorität als die Erstellung neuer Funktionen. Schlechte Bewertungen lassen nicht lange auf sich warten, wenn die Benutzer ständig auf Bugs stoßen. Es ist schwierig, einen beschädigten Ruf wiederherzustellen.
Die Fragen zur Zusammenarbeit zwischen Entwicklung und Support werden von DevOps gelöst. Diese Abkürzung wird oft in Form einer konkreten Person verwendet, die hilft, Testumgebungen für die Entwicklung zu erstellen, CICD-Pipelines zu strukturieren und getesteten Code schnell in die Produktion zu bringen. DevOps ist ein Ansatz zur Softwareentwicklung, bei dem alle Beteiligten eng zusammenarbeiten und dabei helfen, Softwareprodukte und -dienste schneller zu erstellen und zu aktualisieren. Ich spreche hier von Analysten, Entwicklern, Testern und dem Support.
Support und Entwicklung sind in diesem Ansatz keine separaten Abteilungen mit eigenen Zielen und Aufgaben. Die Entwicklung ist in den Betrieb eingebunden und umgekehrt. Der berühmte Satz in verteilten Teams: „Das Problem liegt nicht auf meiner Seite“ wird in Chats nicht mehr so häufig verwendet, und die Endbenutzer sind ein wenig glücklicher geworden.
Quelle: habr.com
