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 1000+ RPS-Modus oder andere technische Dinge schreiben. Ich werde Beobachtungen zu Problemen in den Prozessen teilen, die bei der Unterstützung und dem Betrieb solcher Systeme auftreten.
Überwachung
Der technische Support wartet nicht, bis eine Anwendung mit dem Inhalt "
Warum, warum ... die Website ist wieder inaktiv?" Eintrifft. Der Support sollte eine Minute nach dem Absturz der Site das Problem bereits erkennen und mit der Lösung beginnen.
Aber der Ort ist die Spitze des Eisbergs . Die Verfügbarkeit ist eine der ersten, die überwacht wird.
Was ist mit der Situation, in der die Reste der Waren des Online-Shops nicht mehr aus dem ERP-System stammen? Oder hat das CRM-System, das Rabatte für Kunden berechnet, nicht mehr reagiert? Gleichzeitig funktioniert die Site. Der bedingte Zabbix erhält seine 200 Antwort. Die Schicht im Dienst erhielt keine Benachrichtigungen von der Überwachung und inspiziert gerne die erste Episode der neuen Staffel von Game of Thrones.
Häufig wird die Überwachung nur durch Messen des Speicherstatus, des Arbeitsspeichers und der Auslastung der Serverprozessoren eingeschränkt. Für Unternehmen ist es jedoch viel wichtiger, die Verfügbarkeit von Waren auf der Website zu ermitteln. Ein bedingter Ausfall einer virtuellen Maschine im Cluster führt dazu, dass der Datenverkehr nicht mehr zu ihr fließt und die Last auf anderen Servern zunimmt. Das Unternehmen wird kein Geld verlieren.
Daher müssen Sie neben der Überwachung der technischen Parameter von Betriebssystemen auf Servern auch Geschäftsmetriken konfigurieren. Metriken, die sich direkt auf Geld auswirken. Verschiedene Interaktionen mit externen Systemen (CRM, ERP und andere). Die Anzahl der Bestellungen für einen bestimmten Zeitraum. Erfolgreiche oder erfolglose Clientberechtigungen 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. Ausgehend von dem oben genannten CRM und ERP und endend mit der Übertragung von Verkaufsdaten an ein externes Big Data-System, um Einkäufe zu analysieren und dem Kunden das Produkt anzubieten, das er definitiv kaufen wird (tatsächlich nein). Jedes dieser Systeme hat seine eigene Unterstützung. Und oft verursacht die Kommunikation mit diesen Systemen Schmerzen. Besonders wenn das Problem global ist und Sie es in verschiedenen Systemen analysieren müssen.
Einige Systeme geben das Telefon oder Telegramm an ihre Administratoren weiter. Irgendwo müssen Sie Briefe an Manager schreiben oder zu den Bug-Trackern dieser externen Systeme gehen. Selbst im Kontext eines großen Unternehmens funktionieren unterschiedliche Systeme häufig in unterschiedlichen Anwendungsbuchhaltungssystemen. Manchmal ist es unmöglich, den Status einer Anwendung zu verfolgen. Sie erhalten eine Bewerbung in einem bedingten Jira. Dann setzen Sie in den Kommentaren dieser ersten Jira einen Link zu der Aufgabe in eine andere Jira. Im zweiten Jira in der Anwendung schreibt bereits jemand einen Kommentar, den
Sie den bedingten Administrator Andrei anrufen müssen, um das Problem zu lösen. Usw.
Die beste Lösung für dieses Problem wäre die Schaffung eines einzigen Kommunikationsraums, beispielsweise in Slack. Einladung aller Teilnehmer am Betrieb externer Systeme. Sowie ein einzelner Tracker, um Anwendungen nicht zu duplizieren. Anwendungen sollten an einem Ort überwacht werden, angefangen von der Überwachung von Warnungen bis hin zur Anzeige von Fehlern in Produkten. Sie werden sagen, dass dies unrealistisch ist und historisch so passiert ist, dass wir in einem Tracker arbeiten und sie in einem anderen. Verschiedene Systeme erschienen, sie hatten ihre eigenen autonomen IT-Teams. Ich stimme zu und daher muss das Problem von oben auf der Ebene des CIO oder des Produktbesitzers gelöst werden.
Jedes System, mit dem Sie interagieren, sollte Support als Service mit einer eindeutigen SLA bereitstellen, um Probleme vorrangig zu lösen. Und nicht, wenn der bedingte Administrator Andrey eine Minute für Sie hat.
Mann - Engpass
Hat jeder im Projekt (oder Produkt) eine solche Person, deren Abreise in den Urlaub die Behörden zu Krämpfen veranlasst? Es kann ein Entwickler, Analyst oder Entwickler sein. Schließlich weiß nur ein Entwickler, welche Container auf welchen Servern installiert sind, wie der Container im Falle eines Problems neu geladen werden kann, und tatsächlich kann ein komplexes Problem ohne dieses Problem nicht gelöst werden. Der Analyst ist der einzige, der weiß, wie Ihr komplexer Mechanismus funktioniert. Welche Datenströme gehen wohin? Bei welchen Parametern von Anfragen zu welchen Diensten erhalten wir Antworten.
Wer wird schnell verstehen, warum es Fehler in den Protokollen gibt und schnell einen kritischen Fehler im Produkt beheben? Natürlich der gleiche Entwickler. Es gibt andere, aber aus irgendeinem Grund versteht nur er, wie die verschiedenen Module des Systems angeordnet sind.
Die Wurzel dieses Problems ist der Mangel an Dokumentation . Wenn alle Dienste Ihres Systems beschrieben würden, wäre es schließlich möglich, das Problem ohne einen Analysten zu lösen. Wenn Entwickler ein paar Tage aus ihrem vollen Terminkalender ausgewählt und alle Server, Dienste und Anweisungen zur Lösung typischer Probleme beschrieben haben, könnte ein Problem in Abwesenheit ohne sie gelöst werden. Sie müssen im Urlaub nicht schnell Ihr Bier am Strand trinken und nach WLAN suchen, um das Problem zu lösen.
Kompetenz und Verantwortung des Support-Personals
Bei großen Projekten sparen Unternehmen nicht an Gehältern für Entwickler. Sie jagen teure Zwischenhändler oder Senioren aus ähnlichen Projekten. Mit Unterstützung ist die Situation etwas anders. Sie versuchen auf jede erdenkliche Weise, diese Kosten zu senken. Unternehmen stellen die kostengünstige Enikeyshikov von gestern ein und treten mutig in die Schlacht. Eine solche Strategie ist möglich, wenn es um einen Visitenkartenstandort eines Werks in Zelenograd geht.
Wenn es sich um einen großen Online-Shop handelt, kostet jede Stunde Ausfallzeit mehr als das monatliche Gehalt eines Administrator-Enikeik. Nehmen wir als Ausgangspunkt 1 Milliarde Rubel Jahresumsatz. Dies ist der Mindestumsatz eines Online-Shops ab dem
TOP-100- Rating
für 2018 . Teilen Sie diesen Betrag durch die Anzahl der Stunden pro Jahr und erhalten Sie mehr als 100.000 Rubel Nettoverluste. Und wenn Sie die Nachtstunden nicht zählen, können Sie den Betrag sicher verdoppeln.
Aber Geld ist nicht die Hauptsache, oder? (Nein, natürlich die Hauptsache) Es gibt immer noch Reputationsverluste. Die Stunde des Herbstes des bekannten Online-Shops kann sowohl eine Welle von Bewertungen in sozialen Netzwerken als auch Veröffentlichungen in thematischen Medien hervorrufen. Und die Gespräche von Freunden in der Küche im Stil von "Kaufen Sie dort nichts, ihre Website ist ständig inaktiv" eignen sich überhaupt nicht für Messungen.
Jetzt verantwortlich. In meiner Praxis gab es einen Fall, in dem der diensthabende Administrator nicht rechtzeitig auf die Benachrichtigung des Überwachungssystems über die Unzugänglichkeit der Site reagierte. An einem angenehmen Sommer-Freitagabend lag die Seite eines bekannten Online-Shops in Moskau ruhig. Am Samstagmorgen verstand das Produkt dieser Website nicht, warum die Website nicht geöffnet wurde, und es herrschte Stille in den Support-Chats und dringenden Warnungen in Slack. Ein solcher Fehler kostete uns einen sechsstelligen Betrag, und dieser Dienstoffizier arbeitete.
Verantwortung ist eine Fähigkeit, die schwer zu entwickeln ist. Eine Person hat es entweder oder nicht. Daher versuche ich in Interviews, seine Präsenz mit verschiedenen Fragen zu identifizieren, die indirekt zeigen, ob eine Person es gewohnt ist, Verantwortung zu übernehmen. Wenn jemand antwortet, dass er eine Universität gewählt hat, weil seine Eltern dies gesagt haben, oder seinen Job wechselt, weil seine Frau gesagt hat, dass er nicht viel erhält, ist es besser, sich nicht auf solche Menschen einzulassen.
Interaktion mit dem Entwicklungsteam
Wenn Benutzer während des Betriebs einfache Probleme mit dem Produkt haben, werden diese vom Support selbst gelöst. Es versucht, das Problem zu reproduzieren, analysiert die Protokolle und so weiter. Aber was tun, wenn ein Fehler auf dem Produkt auftritt? In diesem Fall startet der Support die Aufgabe für Entwickler, und hier beginnt der Spaß.
Entwickler sind ständig überlastet. Sie schaffen neue Funktionen. Beheben Sie Fehler mit einer Verkaufsstunde, sagen Sie nicht die interessantesten. Die Fristen für den nächsten Sprint sind abgelaufen. Und dann kommen unangenehme Leute von der Unterstützung und sagen: "Dringend alles fallen lassen, wir haben Probleme." Die Priorität solcher Aufgaben ist minimal. Insbesondere, wenn das Problem nicht das kritischste ist und die Hauptfunktionalität der Site funktioniert und wenn der Release-Manager nicht mit großen Augen ausgeführt wird und nicht schreibt: "Es ist dringend erforderlich, diese Aufgabe auf die nächste Version oder den nächsten Hotfix zu übertragen."
Aufgaben mit normaler oder niedriger Priorität werden von Release zu Release ausgeführt. Auf die Frage "Wann wird die Aufgabe abgeschlossen sein?" Sie erhalten Antworten im Stil von: "Es tut mir leid, jetzt gibt es viele Aufgaben, fragen Sie die Teamleiter oder einen Release-Manager."
Probleme mit dem Produkt haben eine höhere Priorität als das Erstellen neuer Funktionen. Schlechte Bewertungen lassen Sie nicht warten, wenn Benutzer ständig auf Fehler stoßen. Es ist schwierig, einen beschädigten Ruf wiederherzustellen.
Probleme der Interaktion zwischen Entwicklung und Support werden von DevOps gelöst. Diese Abkürzung wird häufig als eine bestimmte Person verwendet, die beim Erstellen von Testumgebungen für die Entwicklung hilft, CI / CD-Pipelines erstellt und den getesteten Code in der Produktion schnell anzeigt. DevOps ist ein Ansatz für die Softwareentwicklung, bei dem alle Teilnehmer des Prozesses eng miteinander interagieren und dabei helfen, Softwareprodukte und -dienste schnell zu erstellen und zu aktualisieren. Ich meine Analysten, Entwickler, Tester und Support.
Unterstützung und Entwicklung in diesem Ansatz sind keine unterschiedlichen Abteilungen mit ihren Zielen. Die Entwicklung ist am Betrieb beteiligt und umgekehrt. Der berühmte Satz verteilter Teams: „Das Problem ist nicht auf meiner Seite“ wird in Chatrooms nicht so oft gesehen, und Endbenutzer werden ein bisschen glücklicher.