Hallo, Habr! Seit zehn Jahren unterstütze ich Highload-IT-Systeme. Ich werde in diesem Artikel nicht über die Probleme bei der Konfiguration von nginx für den Betrieb im Modus 1000+ RPS 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 technischen Support wartet nicht, bis ein Ticket mit dem Inhalt "Warum… funktioniert die Website wieder nicht?" eintrifft. Der Support sollte bereits eine Minute nach dem Ausfall der Website das Problem sehen und mit dessen Lösung beginnen. Aber die Website ist die Spitze des Eisbergs.Ihre Verfügbarkeit wird als eines der ersten Dinge überwacht.
Wie geht man mit der Situation um, wenn die Bestände im Online-Shop nicht mehr aus dem ERP-System kommen? Oder wenn das CRM-System, das Rabatte für Kunden berechnet, nicht mehr reagiert? Die Website scheint ja zu funktionieren. Das hypothetische Zabbix erhält seinen 200-Antwortcode. Die Bereitschaftsschicht hat keine Benachrichtigungen vom Monitoring erhalten und schaut sich fröhlich die erste Episode der neuen Staffel von "Game of Thrones" an.
Oft beschränkt sich das Monitoring nur auf die Messung des Speicher, des RAM und der Prozessorlast. Server. Für das Geschäft ist es jedoch viel wichtiger, die Verfügbarkeit der Produkte auf der Website zu erhalten. Ein hypothetischer Ausfall einer virtuellen Maschine im Cluster führt dazu, dass der Verkehr auf diese nicht mehr geleitet wird und die Last auf andere Server steigt. Das Unternehmen verliert dabei kein Geld.
Daher müssen neben dem Monitoring der technischen Parameter von Betriebssystemen auf Servern auch Geschäftsmetriken eingerichtet werden. Metriken, die direkten Einfluss auf das Geld haben. Verschiedene Interaktionen mit externen Systemen (CRM, ERP und andere). Die Anzahl der Bestellungen über einen bestimmten Zeitraum. Erfolgreiche oder nicht erfolgreiche Kundenanmeldungen und andere Metriken.
Interaktion mit externen Systemen
Jede Website oder mobile Anwendung mit einem Jahresumsatz von über einer Milliarde Rubel interagiert mit externen Systemen. Angefangen bei den oben genannten CRM- und ERP-Systemen bis hin zur Übermittlung von Verkaufsdaten an ein externes Big Data-Analyse-System, das dem Kunden ein Produkt vorschlägt, das er definitiv kaufen wird (in Wirklichkeit nicht). Jedes dieser Systeme hat ihren eigenen Support. Und oft verursacht die Kommunikation mit diesen Systemen Schmerz. Besonders wenn das Problem global ist und es notwendig ist, es in verschiedenen Systemen zu analysieren.
Einige Systeme geben die Telefonnummer oder den Telegram-Account ihrer Administratoren an. Manchmal muss man E-Mails an die Manager schreiben oder in die Bugtracker dieser externen Systeme gehen. Selbst innerhalb eines großen Unternehmens arbeiten verschiedene Systeme oft in unterschiedlichen Ticketsystemen. Den Status eines Antrags zu verfolgen, wird manchmal unmöglich. Du erhältst einen Antrag in einer hypothetischen Jira und setzt dann im Kommentar dieser ersten Jira einen Link zur Aufgabe in einer anderen Jira. In der zweiten Jira schreibt jemand bereits einen Kommentar, dass man den hypothetischen Admin Andrei anrufen muss, um das Problem zu lösen. Und so weiter.
Die optimale Lösung für dieses Problem wäre die Schaffung eines einheitlichen Kommunikationsraums, beispielsweise in Slack. Alle Beteiligten am Betrieb der externen Systeme sollten eingeladen werden. Außerdem sollte es einen gemeinsamen Tracker geben, um Doppelanträge zu vermeiden. Anträge müssen an einem Ort verfolgt werden, beginnend bei den Benachrichtigungen des Monitorings bis hin zur Bereitstellung der Lösungen für Bugs in der Produktion. Du wirst sagen, dass das unrealistisch ist und es historisch so entstand, dass wir in einem Tracker arbeiten und sie in einem anderen. Verschiedene Systeme entstanden, die ihre eigenen autonomen IT-Teams hatten. Ich stimme zu, und daher muss das Problem auf der Ebene von CIO oder Produktinhaber gelöst werden.
Jedes System, mit dem Sie interagieren, sollte Support als Dienstleistung mit klaren SLAs für die Lösung von Problemen nach Prioritäten bieten. Und nicht nur, wenn der hypothetische Admin Andrei einen Moment Zeit für Sie findet.
Mensch - Flaschenhals
Gibt es nicht in jedem Projekt (oder Produkt) jemanden, dessen Urlaub bei der Führungsebene Unruhe auslöst? Das könnte ein DevOps-Ingenieur, Analyst oder Entwickler sein. Denn nur der DevOps-Ingenieur weiß, auf welchen Servern welche Container installiert sind, wie man einen Container im Falle eines Problems neu startet, und jede komplexe Problemstellung kann ohne ihn nicht gelöst werden. Der Analyst ist der Einzige, der weiß, wie Ihr komplexer Mechanismus funktioniert. Welche Datenströme wohin gehen. Unter welchen Parameteranfragen in welche Dienste, welche Antworten wir erhalten werden.
Wer versteht schnell, warum es Fehler in den Logs gibt und behebt zeitnah einen kritischen Bug in der Produktion? Natürlich der Entwickler. Es gibt auch andere, aber nur er versteht, wie die verschiedenen Module des Systems aufgebaut sind.
Die Wurzel dieses Problems ist das Fehlen von Dokumentation.. Denn wenn alle Dienste Ihres Systems beschrieben wären, könnte man das Problem auch ohne Analysten lösen. Wenn DevOps ein paar Tage aus seinem vollen Zeitplan herausgenommen und alle Server, Dienste und Anleitungen zur Lösung typischer Probleme dokumentiert hätte, könnte man das Problem in seiner Abwesenheit auch ohne ihn lösen. Es ist nicht nötig, im Urlaub schnell sein Bier am Strand zu trinken und nach WLAN zu suchen, um das Problem zu lösen.
Kompetenz und Verantwortung der Supportmitarbeiter
In großen Projekten scheut das Unternehmen nicht, den Entwicklern hohe Gehälter zu zahlen. Sie suchen teure Mid-Level- oder Senior-Entwickler von ähnlichen Projekten. Bei der Unterstützung sieht die Situation etwas anders aus. Diese Ausgaben versucht man auf jede mögliche Weise zu reduzieren. Unternehmen stellen günstige, ehemalige Junior-Mitarbeiter ein und gehen mutig in die Schlacht. Eine solche Strategie ist möglich, wenn es sich um die Website einer Visitenkarte eines Werkes in Tscherepowez handelt.
Wenn es sich um einen großen Online-Shop handelt, kostet jede Stunde Stillstand mehr als das monatliche Gehalt eines Junior-Administrators. Nehmen wir einen Ausgangspunkt von 1 Milliarde Rubel Jahresumsatz. Das ist der minimale Umsatz eines jeden Online-Shops aus dem Ranking . Teilen wir diesen Betrag durch die Anzahl der Stunden im Jahr, erhalten wir mehr als 100.000 Rubel reine Verluste. Und wenn wir die Nachtstunden nicht zählen, können wir die Summe problemlos verdoppeln.
Aber Geld ist doch nicht alles, oder? (nein, natürlich ist es wichtig) Es gibt auch den Verlust an Reputation. Eine Stunde Ausfall eines bekannten Online-Shops kann sowohl eine Welle von Beschwerden in sozialen Medien auslösen als auch Veröffentlichungen in Fachmedien nach sich ziehen. Und die Gespräche von Freunden in der Küche im Stil von „Kaufe dort nichts, deren Seite funktioniert ständig nicht“ sind überhaupt nicht messbar.
Nun zur Verantwortung. In meiner Praxis gab es einen Fall, als der diensthabende Administrator nicht rechtzeitig auf die Warnung des Überwachungssystems über die Nichterreichbarkeit der Website reagierte. An einem angenehmen sommerlichen Freitagabend war die Website eines bekannten Online-Shops in Moskau einfach offline. Am Samstagmorgen verstand der Produktverantwortliche dieser Website nicht, warum die Seite nicht lädt, und in den Support- und Notifikations-Chats in Slack war es still. Ein solcher Fehler kostete uns einen sechsstelligen Betrag und diesem diensthabenden Mitarbeiter seinen Job.
Verantwortung ist eine Fähigkeit, die schwer zu entwickeln ist. Ein Mensch hat entweder Verantwortung oder hat sie nicht. Daher versuche ich in Vorstellungsgesprächen, sie durch verschiedene Fragen herauszufinden, die indirekt zeigen, ob die Person bereit ist, Verantwortung zu übernehmen. Wenn jemand sagt, er habe die Hochschule gewählt, weil es die Eltern gesagt haben, oder die Arbeit wechse, weil die Frau gesagt hat, dass er zu wenig verdient, ist es besser, solche Personen zu meiden.
Zusammenarbeit mit dem Entwicklungsteam
Wenn bei den Nutzern im produktiven Einsatz einfache Probleme auftreten, löst der Support diese selber. Er versucht, das Problem nachzustellen, analysiert Logs und so weiter. Aber was tun, wenn ein Bug im produktiven System auftaucht? In diesem Fall leitet der Support eine Anfrage an die Entwickler weiter, und hier beginnt das Interessante.
Entwickler sind ständig überlastet. Sie sind damit beschäftigt, neue Funktionen zu erstellen. Bugs im Produkt zu beheben, ist nicht gerade die spannendste Aufgabe. Die Fristen für den Abschluss des nächsten Sprints brennen. Und dann kommen unangenehme Personen vom Support und sagen: „Hör sofort mit allem auf, wir haben Probleme“. Die Priorität solcher Aufgaben ist minimal. Besonders wenn das Problem nicht kritisch ist und die Hauptfunktionen der Website funktionieren, und wenn der Release-Manager nicht mit weit aufgerissenen Augen herumläuft und sagt: „Füge diese Aufgabe dringend in das nächste Release oder Hotfix ein.“
Aufgaben mit normaler oder niedriger Priorität werden von Release zu Release verschoben. Auf die Frage „Wann wird die Aufgabe abgeschlossen sein?“ erhältst du Antworten wie: „Tut mir leid, es sind zurzeit viele Aufgaben, frag die Teamleiter oder den Release-Manager."
Probleme in der Produktivumgebung haben eine höhere Priorität als die Erstellung neuer Funktionen. Schlechte Bewertungen lassen nicht lange auf sich warten, wenn die Nutzer ständig auf Bugs stoßen. Es ist schwierig, einen beschädigten Ruf wiederherzustellen.
Die Fragen der 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, CI/CD-Pipelines aufzubauen und getesteten Code schnell in die Produktion zu bringen. DevOps ist ein Ansatz zur Softwareentwicklung, bei dem alle Beteiligten eng zusammenarbeiten und sich gegenseitig unterstützen, um schneller Softwareprodukte und Dienstleistungen zu entwickeln und zu aktualisieren. Ich spreche von Analysten, Entwicklern, Testern und dem Support.
Die Unterstützung und Entwicklung in diesem Ansatz sind keine verschiedenen Abteilungen mit eigenen Zielen und Aufgaben. Die Entwicklung ist in den Betrieb eingebunden und umgekehrt. Der berühmte Satz verteilten Teams: „Das Problem liegt nicht auf meiner Seite“ wird in Chats nicht mehr so häufig verwendet, und die Endbenutzer werden ein kleines bisschen glücklicher.
Quelle: habr.com
