In diesem Frühling herrschten sehr fröhliche Bedingungen. Aufgrund der Pandemie wurde klar, dass unsere Sommerkonferenzen online stattfinden mussten. Und um sie online effizient durchzuführen, waren vorgefertigte Softwarelösungen für uns nicht geeignet, wir mussten unsere eigenen schreiben. Und dafür hatten wir drei Monate Zeit.
Es ist klar, dass es aufregende drei Monate waren. Doch von außen ist es nicht ganz klar: Was ist eine Online-Konferenzplattform? Aus welchen Teilen besteht es? Deshalb habe ich auf der letzten DevOops-Sommerkonferenz die Verantwortlichen für diese Aufgabe gefragt:
- Nikolay Molchanov – technischer Direktor der JUG Ru Group;
- Vladimir Krasilshchik ist ein pragmatischer Java-Programmierer, der am Backend arbeitet (seine Berichte konnten Sie auch auf unseren Java-Konferenzen sehen);
- Artyom Nikonov ist für unser gesamtes Videostreaming verantwortlich.
Übrigens werden wir auf den Herbst-Winter-Konferenzen eine verbesserte Version derselben Plattform verwenden – so werden weiterhin viele Habra-Leser ihre Benutzer sein.
Großes Bild
— Wie war die Zusammensetzung des Teams?
Nikolay Molchanov: Wir haben einen Analysten, einen Designer, einen Tester, drei Front-Ender und ein Back-End. Und natürlich ein T-förmiger Spezialist!
— Wie sah der Prozess im Allgemeinen aus?
Nikolay: Bis Mitte März hatten wir überhaupt nichts für das Internet bereit. Und am 15. März begann sich das gesamte Online-Karussell zu drehen. Wir haben mehrere Repositories eingerichtet, geplant, die grundlegende Architektur besprochen und alles in drei Monaten erledigt.
Dies durchlief natürlich die klassischen Phasen der Planung, Architektur, Funktionsauswahl, Abstimmung für diese Funktionen, Richtlinien für diese Funktionen, deren Design, Entwicklung und Tests. Infolgedessen haben wir am 6. Juni alles in die Produktion gebracht. . Für alles gab es 90 Tage.
— Haben wir es geschafft, das zu erreichen, was wir uns vorgenommen haben?
Nikolay: Da wir jetzt online an der DevOops-Konferenz teilnehmen, bedeutet das, dass es geklappt hat. Ich persönlich habe mich der Hauptsache verschrieben: Ich werde den Kunden ein Tool zur Verfügung stellen, mit dem sie eine Online-Konferenz durchführen können.
Die Herausforderung bestand darin, uns ein Tool zur Verfügung zu stellen, mit dem wir unsere Konferenzen an Ticketinhaber übertragen können.
Die gesamte Planung wurde in mehrere Phasen unterteilt und alle Funktionen (ca. 30 global) wurden in 4 Kategorien unterteilt:
- was wir auf jeden Fall tun werden (ohne sie können wir nicht leben),
- was wir zweitens tun werden,
- was wir niemals tun werden,
- und was wir niemals tun werden.
Wir haben alle Features aus den ersten beiden Kategorien erstellt.
— Ich weiß, dass insgesamt 600 JIRA-Vorgänge erstellt wurden. In drei Monaten haben Sie 13 Microservices erstellt, und ich vermute, dass sie nicht nur in Java geschrieben wurden. Sie haben unterschiedliche Technologien verwendet, Sie haben zwei Kubernetes-Cluster in drei Verfügbarkeitszonen und 5 RTMP-Streams in Amazon.
Schauen wir uns nun jede Komponente des Systems einzeln an.
Streamen
— Beginnen wir damit, dass wir bereits ein Videobild haben und es an einige Dienste übertragen wird. Artyom, erzähl uns, wie dieses Streaming passiert?
Artjom Nikonow: Unser allgemeines Schema sieht so aus: Bild von der Kamera -> unser Kontrollraum -> lokaler RTMP-Server -> Amazon -> Videoplayer. Mehr Details auf Habré im Juni.
Im Allgemeinen gibt es zwei globale Möglichkeiten, dies zu tun: entweder auf Hardware oder basierend auf Softwarelösungen. Wir haben uns für den Software-Weg entschieden, weil dieser bei entfernten Lautsprechern einfacher ist. Es ist nicht immer möglich, Hardware zu einem Lautsprecher in ein anderes Land zu bringen, aber die Lieferung von Software an den Lautsprecher scheint einfacher und zuverlässiger zu sein.
Aus Hardware-Sicht haben wir eine bestimmte Anzahl an Kameras (in unseren Studios und an entfernten Lautsprechern), eine bestimmte Anzahl an Fernbedienungen im Studio, die manchmal während der Übertragung direkt unter dem Tisch repariert werden müssen.
Signale von diesen Geräten gelangen in Computer mit Capture-Karten, Eingabe-/Ausgabekarten und Soundkarten. Dort werden die Signale gemischt und zu Layouts zusammengesetzt:
Beispiel eines Layouts für 4 Lautsprecher
Beispiel eines Layouts für 4 Lautsprecher
Darüber hinaus wird eine kontinuierliche Übertragung mit Hilfe von drei Computern gewährleistet: Es gibt abwechselnd einen Hauptcomputer und zwei Arbeitscomputer. Der erste Computer sammelt den ersten Bericht, der zweite – die Pause, der erste – den nächsten Bericht, der zweite – die nächste Pause und so weiter. Und die Hauptmaschine mischt das erste mit dem zweiten.
Dadurch entsteht eine Art Dreieck, und wenn einer dieser Knoten ausfällt, können wir schnell und ohne Qualitätsverlust weiterhin Inhalte an Kunden liefern. Wir hatten so eine Situation. In der ersten Konferenzwoche haben wir ein Gerät repariert und ein- und ausgeschaltet. Die Menschen scheinen mit unserer Widerstandsfähigkeit zufrieden zu sein.
Als nächstes gehen die Streams von den Computern an einen lokalen Server, der zwei Aufgaben hat: RTMP-Streams weiterleiten und Backups aufzeichnen. Wir haben also mehrere Aufnahmepunkte. Die Videostreams werden dann an den Teil unseres Systems gesendet, der auf Amazon SaaS-Diensten basiert. Wir gebrauchen ,S3,CloudFront.
Nikolay: Was passiert dort, bevor das Video das Publikum erreicht? Irgendwie muss man es schneiden, oder?
Artjom: Wir komprimieren das Video unsererseits und senden es an MediaLive. Wir bringen dort Transcoder auf den Markt. Sie transkodieren Videos in Echtzeit in verschiedene Auflösungen, sodass die Leute sie auf ihren Handys, über schlechtes Internet im Land usw. ansehen können. Dann werden diese Ströme zerschnitten , so funktioniert das Protokoll . Wir senden eine Playlist an das Frontend, die Verweise auf diese Chunks enthält.
— Verwenden wir eine 1080p-Auflösung?
Artjom: Die Breite unseres Videos entspricht 1080p – 1920 Pixel, und die Höhe ist etwas geringer, das Bild ist länglicher – dafür gibt es Gründe.
Spieler
— Artyom beschrieb, wie das Video in Streams gelangt, wie es in verschiedene Playlists für unterschiedliche Bildschirmauflösungen verteilt, in Stücke geschnitten und in den Player gelangt. Kolya, sag mir jetzt, was für ein Player das ist, wie er den Stream verbraucht, warum HLS?
Nikolay: Wir haben einen Player, den alle Konferenzzuschauer ansehen können.
Im Wesentlichen handelt es sich hierbei um eine Hülle um die Bibliothek , auf dem viele andere Spieler geschrieben sind. Aber wir brauchten eine ganz bestimmte Funktionalität: Zurückspulen und Markieren des Ortes, an dem sich die Person befindet und welchen Bericht sie gerade ansieht. Außerdem brauchten wir eigene Layouts, allerlei Logos und alles andere, was bei uns eingebaut wurde. Deshalb haben wir uns entschieden, unsere eigene Bibliothek (einen Wrapper über HLS) zu schreiben und sie in die Site einzubetten.
Dies ist die Root-Funktionalität und wurde daher fast zuerst implementiert. Und dann wuchs alles darum herum.
Tatsächlich erhält der Player durch Autorisierung vom Backend eine Playlist mit Links zu Chunks, die mit Zeit und Qualität korrelieren, lädt die benötigten herunter und zeigt sie dem Benutzer, wobei er nebenbei etwas „Magie“ ausführt.
Beispiel für eine Zeitleiste
— Direkt in den Player ist eine Schaltfläche integriert, um eine Zeitleiste aller Berichte anzuzeigen ...
Nikolay: Ja, wir haben das Problem der Benutzernavigation sofort gelöst. Mitte April haben wir beschlossen, nicht jede unserer Konferenzen auf einer separaten Website zu übertragen, sondern alles auf einer zu bündeln. Damit können Benutzer von Full-Pass-Tickets frei zwischen verschiedenen Konferenzen wechseln: sowohl Live-Übertragungen als auch Aufzeichnungen vergangener Konferenzen.
Und um Benutzern das Navigieren im aktuellen Stream und das Wechseln zwischen Titeln zu erleichtern, haben wir beschlossen, eine Schaltfläche „Gesamte Übertragung“ und horizontale Berichtkarten zum Wechseln zwischen Titeln und Berichten zu erstellen. Es gibt eine Tastatursteuerung.
— Gab es dabei technische Schwierigkeiten?
Nikolay: Sie verfügten über eine Bildlaufleiste, auf der die Startpunkte verschiedener Berichte markiert waren.
— Haben Sie diese Markierungen letztendlich in der Bildlaufleiste implementiert, bevor YouTube etwas Ähnliches getan hat?
Artjom: Damals gab es die Betaversion. Es scheint, dass dies eine ziemlich komplexe Funktion ist, da sie im letzten Jahr teilweise mit Benutzern getestet wurde. Und jetzt ist es im Verkauf.
Nikolay: Aber wir haben es tatsächlich schneller zum Verkauf gebracht. Ehrlich gesagt, hinter dieser einfachen Funktion steckt eine Menge Backend, Frontend, Berechnungen und Mathematik im Player.
Frontend
— Lassen Sie uns herausfinden, wie dieser von uns angezeigte Inhalt (Sprachkarte, Redner, Website, Zeitplan) ins Frontend gelangt.
Vladimir Krasilshchik: Wir verfügen über mehrere interne IT-Systeme. Es gibt ein System, in das alle Berichte und alle Referenten eingetragen werden. Es gibt einen Prozess, bei dem ein Redner an einer Konferenz teilnimmt. Der Referent reicht einen Antrag ein, das System erfasst ihn, dann gibt es eine bestimmte Pipeline, nach der der Bericht erstellt wird.
So sieht der Sprecher die Pipeline
Dieses System ist unsere interne Entwicklung.
Als nächstes müssen Sie einen Zeitplan aus einzelnen Berichten erstellen. Wie Sie wissen, ist dies ein NP-schweres Problem, aber wir lösen es irgendwie. Dazu starten wir eine weitere Komponente, die einen Zeitplan generiert und ihn auf den Cloud-Dienst Contentful des Drittanbieters hochlädt. Dort sieht alles wie eine Tabelle aus, in der die Tage der Konferenz stehen, in den Tagen Zeitfenster und in den Zeitfenstern Berichte, Pausen oder Sponsoringaktivitäten. Der Inhalt, den wir sehen, befindet sich also in einem Drittanbieterdienst. Und die Aufgabe besteht darin, es auf die Website zu übertragen.
Es scheint, dass die Site nur eine Seite mit einem Player ist, und hier gibt es nichts Kompliziertes. Außer, dass es das nicht ist. Das Backend hinter dieser Seite geht zu Contentful, holt sich von dort den Zeitplan, generiert einige Objekte und sendet ihn an das Frontend. Über eine Websocket-Verbindung, die jeder Kunde unserer Plattform herstellt, senden wir ihm ein Update des Zeitplans vom Backend zum Frontend.
Realer Fall: Der Redner wechselte direkt während der Konferenz den Job. Wir müssen den Firmenausweis seines Arbeitgebers ändern. Wie passiert das vom Backend aus? Über den Websocket wird ein Update an alle Clients gesendet und anschließend zeichnet das Frontend selbst die Timeline neu. Das alles geschieht nahtlos. Die Kombination aus dem Cloud-Service und mehreren unserer Komponenten gibt uns die Möglichkeit, all diese Inhalte zu generieren und an die Front bereitzustellen.
Nikolay: An dieser Stelle ist es wichtig klarzustellen, dass es sich bei unserer Seite nicht um eine klassische SPA-Anwendung handelt. Dabei handelt es sich sowohl um eine auf Layout basierende, gerenderte Website als auch um ein SPA. Google betrachtet diese Website tatsächlich als gerendertes HTML. Dies ist gut für SEO und für die Bereitstellung von Inhalten für den Benutzer. Es wartet nicht darauf, dass 1,5 Megabyte JavaScript geladen sind, bevor die Seite angezeigt wird, sondern sieht sofort die bereits gerenderte Seite und Sie spüren es jedes Mal, wenn Sie den Bericht wechseln. Alles geschieht in einer halben Sekunde, da der Inhalt bereits fertig und an der richtigen Stelle gepostet ist.
— Lassen Sie uns einen Schlussstrich unter all dem ziehen, indem wir die Technologien auflisten. Tyoma sagte, dass wir 5 Amazon-Streams haben und dort Video und Ton liefern. Wir haben dort Bash-Skripte, wir verwenden sie zum Starten und Konfigurieren ...
Artjom: Dies geschieht über die AWS-API, dort gibt es viele weitere technische Nebendienste. Wir haben unsere Verantwortlichkeiten so aufgeteilt, dass ich sie erfülle , und Front-End- und Back-End-Entwickler nehmen es von dort aus. Wir verfügen über eine Reihe eigener Bindungen, um das Layout von Inhalten zu vereinfachen, die wir dann in 4K usw. erstellen. Da die Fristen sehr knapp waren, haben wir dies fast vollständig auf AWS erledigt.
— Dann geht das alles über das Backend-System in den Player. Wir haben TypeScript, React, Next.JS in unserem Player. Und im Backend haben wir mehrere Dienste in C#, Java, Spring Boot und Node.js. Dies alles wird mithilfe von Kubernetes und der Yandex.Cloud-Infrastruktur bereitgestellt.
Ich möchte auch anmerken, dass es einfach war, mich mit der Plattform vertraut zu machen: Alle Repositories sind auf GitLab, alles ist gut benannt, Tests sind geschrieben, es gibt Dokumentation. Das heißt, selbst im Notfallmodus haben sie sich um solche Dinge gekümmert.
Geschäftsbeschränkungen und Analysen
— Basierend auf den Geschäftsanforderungen haben wir 10 Benutzer angesprochen. Es ist Zeit, über die geschäftlichen Einschränkungen zu sprechen, die wir hatten. Wir mussten eine hohe Arbeitsbelastung sicherstellen und die Einhaltung des Gesetzes zur Aufbewahrung personenbezogener Daten sicherstellen. Und was noch?
Nikolay: Zunächst gingen wir von den Videoanforderungen aus. Das Wichtigste ist die weltweit verteilte Videospeicherung für eine schnelle Lieferung an den Kunden. Andere bieten eine 1080p-Auflösung sowie einen Rücklauf, den viele andere im Live-Modus nicht implementieren. Später haben wir die Möglichkeit hinzugefügt, die 2-fache Geschwindigkeit zu aktivieren, mit deren Hilfe Sie die Live-Übertragung „einholen“ und die Konferenz weiterhin in Echtzeit verfolgen können. Und nebenbei erschien die Funktionalität zur Timeline-Markierung. Außerdem mussten wir fehlertolerant sein und der Belastung von 10 Verbindungen standhalten. Aus Backend-Sicht sind dies etwa 000 Verbindungen multipliziert mit 10 Anfragen für jede Seitenaktualisierung. Und das sind bereits 000 RPS/Sek. Ziemlich viel.
— Gab es weitere Voraussetzungen für eine „virtuelle Ausstellung“ mit Online-Ständen von Partnern?
Nikolay: Ja, das musste recht schnell und flächendeckend geschehen. Wir hatten für jede Konferenz bis zu 10 Partnerunternehmen und alle mussten in ein bis zwei Wochen abgeschlossen sein. Ihr Inhalt unterscheidet sich jedoch geringfügig im Format. Es wurde jedoch eine bestimmte Template-Engine erstellt, die diese Seiten praktisch ohne weitere Entwicklungsbeteiligung im Handumdrehen zusammenstellt.
— Es gab auch Anforderungen für die Analyse von Echtzeitansichten und -statistiken. Ich weiß, dass wir dafür Prometheus nutzen, aber erzählen Sie uns bitte genauer: Welche Anforderungen erfüllen wir an Analytics und wie wird dies umgesetzt?
Nikolay: Zunächst haben wir Marketinganforderungen für das Sammeln von A/B-Tests und das Sammeln von Informationen, um zu verstehen, wie wir dem Kunden in Zukunft die besten Inhalte richtig liefern können. Es bestehen auch Anforderungen für einige Analysen zu Partneraktivitäten und die Analysen, die Sie sehen (Besuchszähler). Alle Informationen werden in Echtzeit erfasst.
Wir können diese Informationen auch den Rednern in aggregierter Form zur Verfügung stellen: wie viele Personen Sie zu einem bestimmten Zeitpunkt gesehen haben. Gleichzeitig werden Ihr persönliches Konto und Ihre persönlichen Daten zur Einhaltung des Bundesgesetzes 152 in keiner Weise verfolgt.
Die Plattform verfügt bereits über Marketingtools und unsere Metriken zur Messung der Benutzeraktivität in Echtzeit (wer hat sich welche Sekunde des Berichts angesehen), um Diagramme der Anwesenheit bei den Berichten zu erstellen. Basierend auf diesen Daten wird geforscht, um die nächsten Konferenzen besser zu machen.
Betrug
— Verfügen wir über Mechanismen zur Betrugsbekämpfung?
Nikolay: Aufgrund des engen Zeitrahmens aus betriebswirtschaftlicher Sicht wurde zunächst nicht die Aufgabe gestellt, unnötige Verbindungen sofort zu sperren. Wenn sich zwei Benutzer unter demselben Konto anmelden, können sie den Inhalt anzeigen. Aber wir wissen, wie viele gleichzeitige Aufrufe es von einem Konto gab. Und wir haben mehrere besonders böswillige Verstöße verboten.
Vladimir: Man muss ihm zugute halten, dass einer der gesperrten Benutzer verstanden hat, warum das passiert ist. Er kam, entschuldigte sich und versprach, ein Ticket zu kaufen.
— Damit all dies geschieht, müssen Sie alle Benutzer vom Eingang bis zum Ausgang vollständig verfolgen und immer wissen, was sie tun. Wie funktioniert dieses System?
Vladimir: Ich möchte über Analytics und Statistiken sprechen, die wir dann für den Erfolg des Berichts analysieren oder dann Partnern zur Verfügung stellen können. Alle Clients sind über eine Websocket-Verbindung mit einem bestimmten Backend-Cluster verbunden. Es steht da . Jeder Kunde sendet zu jedem Zeitpunkt, was er tut und welchen Titel er ansieht. Anschließend werden diese Informationen mithilfe schneller Hazelcast-Jobs aggregiert und an alle zurückgesendet, die sich diese Titel ansehen. Wir sehen in der Ecke, wie viele Leute jetzt bei uns sind.
Die gleichen Informationen werden in gespeichert und geht zu unserem Datensee, aus dem wir die Möglichkeit haben, ein interessanteres Diagramm zu erstellen. Es stellt sich die Frage: Wie viele einzelne Benutzer haben diesen Bericht angesehen? Wir gehen zu , es gibt Pings aller Leute, die über die ID dieses Berichts gekommen sind. Wir haben einzigartige gesammelt und aggregiert, und jetzt können wir sie verstehen.
Nikolay: Gleichzeitig erhalten wir aber auch Echtzeitdaten von Prometheus. Es richtet sich gegen alle Kubernetes-Dienste, gegen Kubernetes selbst. Es sammelt absolut alles und mit Grafana können wir beliebige Diagramme in Echtzeit erstellen.
Vladimir: Einerseits laden wir diese für die weitere OLAP-Verarbeitung herunter. Und für OLTP lädt die Anwendung das Ganze auf Prometheus und Grafana herunter und die Diagramme konvergieren sogar!
- Dies ist der Fall, wenn die Graphen konvergieren.
Dynamische Veränderungen
— Sagen Sie uns, wie dynamische Änderungen umgesetzt werden: Wie sieht die Aktionskette aus, wenn der Bericht 6 Minuten vor Beginn abgebrochen wurde? Welche Pipeline funktioniert?
Vladimir: Die Pipeline ist sehr bedingt. Es gibt mehrere Möglichkeiten. Das erste ist, dass das Programm zur Zeitplanerstellung funktionierte und den Zeitplan änderte. Der geänderte Zeitplan wird auf Contentful hochgeladen. Danach versteht das Backend, dass es Änderungen für diese Konferenz in Contentful gibt, nimmt sie und erstellt sie neu. Alles wird per Websocket gesammelt und versendet.
Die zweite Möglichkeit, wenn alles in rasender Geschwindigkeit passiert: Der Redakteur ändert die Informationen in Contentful manuell (Link zu Telegram, Referentenpräsentation usw.) und es funktioniert die gleiche Logik wie beim ersten Mal.
Nikolay: Alles geschieht ohne Aktualisierung der Seite. Alle Änderungen erfolgen für den Kunden absolut reibungslos. Das Gleiche gilt für Wechselberichte. Wenn es soweit ist, ändern sich der Bericht und die Benutzeroberfläche.
Vladimir: Außerdem gibt es Zeitgrenzen für den Beginn von Berichten in der Zeitleiste. Ganz am Anfang gibt es nichts. Und wenn man mit der Maus über den roten Streifen fährt, dann erscheinen irgendwann, dank des Sendeleiters, Cutoffs. Der Regisseur stellt den richtigen Beginn der Übertragung ein, das Backend übernimmt diese Änderung, berechnet die Start- und Endzeiten der Präsentationen des gesamten Tracks gemäß dem Konferenzplan, sendet sie an unsere Kunden und der Player zeichnet die Cutoffs auf. Jetzt kann der Benutzer problemlos zum Anfang und Ende des Berichts navigieren. Es war eine strenge geschäftliche Anforderung, sehr praktisch und nützlich. Sie verschwenden keine Zeit damit, die tatsächliche Startzeit für den Bericht herauszufinden. Und wenn wir eine Vorschau machen, wird es absolut wunderbar sein.
Einsatz
— Ich möchte eine Frage zum Einsatz stellen. Kolya und das Team haben zu Beginn viel Zeit damit verbracht, die gesamte Infrastruktur aufzubauen, in der sich alles für uns abspielt. Sag mir, woraus besteht das Ganze?
Nikolay: Aus technischer Sicht hatten wir zunächst die Anforderung, dass das Produkt möglichst abstrakt von jedem Anbieter sein sollte. Kommen Sie zu AWS, um Terraform-Skripte speziell aus AWS, oder speziell aus Yandex, oder aus Azure usw. zu erstellen. hat nicht wirklich gepasst. Irgendwann mussten wir irgendwohin umziehen.
In den ersten drei Wochen waren wir ständig auf der Suche nach einer Möglichkeit, dies besser zu machen. Infolgedessen kamen wir zu dem Schluss, dass Kubernetes in diesem Fall unser Ein und Alles ist, da es uns ermöglicht, automatisch skalierende Dienste zu erstellen, automatisch einzuführen und fast alle Dienste sofort einsatzbereit zu machen. Natürlich mussten alle Dienste für die Arbeit mit Kubernetes und Docker geschult werden, und auch das Team musste lernen.
Wir haben zwei Cluster. Test und Produktion. Sie sind hinsichtlich Hardware und Einstellungen absolut identisch. Wir implementieren Infrastruktur als Code. Alle Dienste werden mithilfe einer automatischen Pipeline automatisch in drei Umgebungen aus Feature-Branches, Master-Branches, Test-Branches und GitLab ausgerollt. Dies ist maximal in GitLab integriert, maximal integriert in Elastic, Prometheus.
Wir haben die Möglichkeit, Änderungen schnell (für das Backend innerhalb von 10 Minuten, für das Frontend innerhalb von 5 Minuten) in jede Umgebung mit allen Tests, Integrationen, der Ausführung von Funktionstests, Integrationstests in der Umgebung und auch Tests mit aktivierten Lasttests einzuführen Eine Testumgebung, die ungefähr das Gleiche ist, was wir in der Produktion erreichen möchten.
Über Tests
— Du testest fast alles, es ist kaum zu glauben, wie du alles geschrieben hast. Können Sie uns etwas über die Backend-Tests erzählen: Wie viel wird alles abgedeckt, welche Tests?
Vladimir: Es wurden zwei Arten von Tests geschrieben. Die ersten sind Komponententests. Hubhöhentests der gesamten Federanwendung und des Sockels . Dies ist ein Test der Geschäftsszenarien auf höchstem Niveau. Ich teste keine Funktionen. Wir testen nur einige große Dinge. Beispielsweise wird direkt im Test der Anmeldevorgang eines Benutzers nachgeahmt, die Anfrage des Benutzers nach Tickets für den Ort, an den er gehen kann, und eine Anfrage nach Zugang zum Ansehen des Streams. Sehr klare Benutzerszenarien.
Etwa das Gleiche wird bei den sogenannten Integrationstests umgesetzt, die tatsächlich auf der Umgebung laufen. Tatsächlich laufen beim nächsten Einsatz in der Produktion auch echte Basisszenarien in der Produktion ab. Dieselbe Anmeldung, Tickets anfordern, Zugriff auf CloudFront anfordern, überprüfen, ob der Stream wirklich mit meinen Berechtigungen verbunden ist, die Schnittstelle des Regisseurs überprüfen.
Im Moment habe ich etwa 70 Komponententests und etwa 40 Integrationstests an Bord. Die Abdeckung liegt bei nahezu 95 %. Dies gilt für Komponenten, weniger für Integrationen, es wird einfach nicht so viel benötigt. Wenn man bedenkt, dass das Projekt alle Arten der Codegenerierung umfasst, ist dies ein sehr guter Indikator. Es gab keine andere Möglichkeit, das zu schaffen, was wir in drei Monaten geschafft haben. Denn wenn wir manuell testen würden, indem wir unserer Testerin Funktionen zur Verfügung stellen würden und sie Fehler findet und sie zur Behebung an uns zurücksendet, dann wäre dieser Hin- und Rückweg zum Debuggen des Codes sehr langwierig und wir würden keine Fristen einhalten.
Nikolay: Um beim Ändern einer Funktion eine Regression auf der gesamten Plattform durchzuführen, muss man herkömmlicherweise zwei Tage lang überall herumstochern.
Vladimir: Daher ist es ein großer Erfolg, dass ich bei der Schätzung einer Funktion sage, dass ich 4 Tage für zwei einfache Stifte und 1 Websocket benötige, Kolya erlaubt es. Er ist bereits daran gewöhnt, dass diese 4 Tage zwei Arten von Tests beinhalten, und dann wird es höchstwahrscheinlich klappen.
Nikolay: Ich habe auch 140 Tests geschrieben: Komponente + Funktion, die das Gleiche tun. Dieselben Szenarien werden in der Produktion, im Test und in der Produktion getestet. Wir haben kürzlich auch funktionale grundlegende UI-Tests hinzugefügt. Auf diese Weise decken wir die grundlegendsten Funktionen ab, die auseinanderfallen können.
Vladimir: Natürlich lohnt es sich, über Belastungstests zu sprechen. Es war notwendig, die Plattform unter einer realitätsnahen Belastung zu testen, um zu verstehen, wie alles ist, was mit Rabbit passiert, was mit den JVMs passiert und wie viel Speicher tatsächlich benötigt wird.
— Ich weiß nicht genau, ob wir irgendetwas auf der Stream-Seite testen, aber ich erinnere mich, dass es bei unseren Treffen Probleme mit Transcodern gab. Haben wir die Streams getestet?
Artjom: Iterativ getestet. Organisieren von Treffen. Im Zuge der Organisation von Meetups gab es etwa 2300 JIRA-Tickets. Das sind nur allgemeine Dinge, die Leute tun, um Treffen zu organisieren. Wir haben Teile der Plattform auf eine separate Seite für Meetups gebracht, die von Kirill Tolkachev betrieben wurde ().
Ehrlich gesagt gab es keine großen Probleme. Wir haben buchstäblich ein paar Mal Caching-Fehler auf CloudFront festgestellt und diese recht schnell behoben – wir haben einfach die Richtlinien neu konfiguriert. Es gab deutlich mehr Fehler in den Streaming-Systemen der Website.
Während der Konferenzen musste ich mehrere weitere Exporteure anschreiben, um mehr Ausrüstung und Dienstleistungen abzudecken. An manchen Orten musste ich aus reinen Maßstäben meine eigenen Fahrräder bauen. Die Welt der AV-Hardware (Audio-Video) ist nicht sehr rosig – Sie haben eine Art „API“ von Geräten, auf die Sie einfach keinen Einfluss haben. Und es ist keineswegs eine Tatsache, dass Sie in der Lage sein werden, die Informationen zu erhalten, die Sie benötigen. Hardware-Anbieter sind sehr langsam und es ist fast unmöglich, von ihnen das zu bekommen, was Sie wollen. Insgesamt gibt es mehr als 100 Hardwareteile, die nicht das zurückgeben, was Sie benötigen, und Sie schreiben seltsame und überflüssige Exporter, dank derer Sie das System zumindest irgendwie debuggen können.
Ausrüstung
— Ich erinnere mich, wie wir vor Beginn der Konferenzen teilweise zusätzliche Ausrüstung angeschafft haben.
Artjom: Wir haben Computer, Laptops und Akkus gekauft. Im Moment können wir 40 Minuten ohne Strom leben. Im Juni gab es in St. Petersburg heftige Gewitter – wir hatten also einen solchen Blackout. Gleichzeitig kommen mehrere Anbieter mit optischen Verbindungen von unterschiedlichen Punkten zu uns. Das sind in Wirklichkeit 40 Minuten Gebäudestillstand, in denen wir Licht, Ton, Kameras usw. in Betrieb haben.
— Wir haben eine ähnliche Geschichte mit dem Internet. In dem Büro, in dem sich unsere Studios befinden, haben wir ein starkes Netz zwischen den Etagen gezogen.
Artjom: Wir haben 20 Gbit Glasfaser zwischen den Etagen. Weiter unten auf den Etagen gibt es irgendwo Optik, irgendwo keine Optik, aber es gibt immer noch weniger Kanäle als Gigabit-Kanäle – wir lassen zwischen den Titeln der Konferenz Videos darauf laufen. Im Allgemeinen ist es sehr bequem, an der eigenen Infrastruktur zu arbeiten, bei Offline-Konferenzen vor Ort ist dies selten möglich.
— Bevor ich bei der JUG Ru Group arbeitete, habe ich gesehen, wie über Nacht Hardware-Räume bei Offline-Konferenzen eingerichtet wurden, in denen es einen großen Monitor mit allen Metriken gab, die man in Grafana erstellt. Jetzt gibt es auch einen Hauptsitzraum, in dem das Entwicklungsteam sitzt, das während der Konferenz einige Fehler behebt und Funktionen entwickelt. Gleichzeitig gibt es ein Überwachungssystem, das auf einem großen Bildschirm angezeigt wird. Artyom, Kolya und andere Leute sitzen da und sorgen dafür, dass nicht alles herunterfällt und alles wunderbar funktioniert.
Kuriositäten und Probleme
— Sie haben gut darüber gesprochen, dass wir Streaming mit Amazon haben, es einen Player mit dem Web gibt, alles in verschiedenen Programmiersprachen geschrieben ist, Fehlertoleranz und andere Geschäftsanforderungen bereitgestellt werden, einschließlich eines persönlichen Kontos, das für juristische Personen und unterstützt wird Einzelpersonen, und wir können uns mit jemandem integrieren, der OAuth 2.0 verwendet, es gibt Betrugsbekämpfung und Benutzerblockierung. Wir können Änderungen dynamisch einführen, weil wir es gut gemacht haben und alles getestet wurde.
Mich interessiert, welche Kuriositäten dabei waren, dass etwas in Gang kam. Gab es seltsame Situationen, als Sie ein Backend oder Frontend entwickelten, etwas Verrücktes dabei herauskam und Sie nicht wussten, was Sie damit machen sollten?
Vladimir: Es scheint mir, dass dies erst seit drei Monaten der Fall ist. Täglich. Wie Sie sehen können, wurden mir alle Haare ausgerissen.
Vladimir Krasilshchik nach 3 Monaten, als sich ein Spiel herausstellte und niemand verstand, was man damit machen sollte
Jeden Tag gab es so etwas, wenn es diesen Moment gab, in dem man es in die Hand nimmt und sich die Haare ausreißt oder merkt, dass es niemanden sonst gibt und nur man es schaffen kann. Unsere erste große Veranstaltung war TechTrain. Am 6. Juni um 2 Uhr morgens hatten wir die Produktionsumgebung noch nicht ausgerollt, Kolya war gerade dabei, sie einzuführen. Und das persönliche Konto funktionierte mit OAuth2.0 nicht als Autorisierungsserver. Wir haben daraus einen OAuth2.0-Anbieter gemacht, um die Plattform damit zu verbinden. Ich hatte wahrscheinlich 18 Stunden am Stück gearbeitet, ich schaute auf den Computer und sah nichts, ich verstand nicht, warum es nicht funktionierte, und Kolya schaute sich meinen Code aus der Ferne an und suchte nach einem Fehler in der Spring-Konfiguration , habe es gefunden und der LC funktionierte, und auch in der Produktion.
Nikolay: Und eine Stunde vor TechTrain erfolgte die Veröffentlichung.
Hier waren viele Sterne ausgerichtet. Wir hatten großes Glück, denn wir hatten ein super Team und alle waren von der Idee, es online zu machen, begeistert. In all diesen drei Monaten waren wir von der Tatsache getrieben, dass wir „YouTube gemacht“ haben. Ich erlaubte mir nicht, mir die Haare auszureißen, sondern sagte allen, dass alles klappen würde, denn eigentlich sei alles schon vor langer Zeit berechnet worden.
Über Leistung
— Können Sie mir sagen, wie viele Personen auf einer Strecke auf der Baustelle waren? Gab es Leistungsprobleme?
Nikolay: Es gab, wie bereits erwähnt, keine Leistungsprobleme. Die maximale Anzahl der Personen, die an einem Bericht teilnahmen, betrug 1300 Personen, dies ist auf Heisenbug.
— Gab es Probleme mit der lokalen Anzeige? Und ist es möglich, eine technische Beschreibung mit Diagrammen zu haben, wie das Ganze funktioniert?
Nikolay: Wir werden später einen Artikel darüber verfassen.
Sie können Streams sogar lokal debuggen. Als die Konferenzen begannen, wurde es noch einfacher, weil es Produktionsstreams gab, die wir jederzeit ansehen können.
Vladimir: Soweit ich weiß, arbeiteten Frontend-Entwickler lokal mit Mocks, und da die Zeit für die Bereitstellung an die Entwickler im Frontbereich ebenfalls kurz ist (5 Minuten), gibt es keine Probleme, zu überprüfen, was mit den Zertifikaten los ist.
— Alles wird getestet und debuggt, auch lokal. Das heißt, wir schreiben einen Artikel mit allen technischen Besonderheiten, zeigen Ihnen, erzählen Ihnen alles mit Diagrammen, wie es war.
Vladimir: Sie können es nehmen und wiederholen.
- In 3 Monaten.
Ergebnis
— Alles zusammen beschrieben klingt cool, wenn man bedenkt, dass es von einem kleinen Team in drei Monaten geschafft wurde.
Nikolay: Ein großes Team würde das nicht tun. Aber eine kleine Gruppe von Menschen, die recht eng und gut miteinander kommunizieren und sich einigen können, könnte das schaffen. Sie haben keine Widersprüche, die Architektur wurde in zwei Tagen erfunden, wurde fertiggestellt und hat sich eigentlich nicht verändert. Es gibt eine sehr strikte Erleichterung eingehender Geschäftsanforderungen im Hinblick auf die Anhäufung von Funktionsanfragen und Änderungen.
— Was stand auf Ihrer Liste weiterer Aufgaben, als die Sommerkonferenzen bereits stattgefunden hatten?
Nikolay: Zum Beispiel Credits. Schleichende Linien im Video, Pop-ups an einigen Stellen im Video, abhängig vom gezeigten Inhalt. Beispielsweise möchte der Redner dem Publikum eine Frage stellen, und auf dem Bildschirm erscheint eine Abstimmung, die anhand der Abstimmungsergebnisse wieder an den Redner selbst weitergegeben wird. Eine Art soziale Aktivität in Form von Likes, Herzen und Bewertungen des Berichts während der Präsentation selbst, damit Sie im richtigen Moment Feedback geben können, ohne später durch Feedback-Formulare abgelenkt zu werden. Anfangs so.
Und zusätzlich zur gesamten Plattform, mit Ausnahme von Streaming und Konferenz, auch ein Post-Konferenz-Status. Dabei handelt es sich um Playlists (auch von Nutzern zusammengestellte), ggf. Inhalte aus anderen vergangenen Konferenzen, eingebunden, gekennzeichnet, für den Nutzer zugänglich und auch auf unserer Website abrufbar ().
— Leute, vielen Dank für eure Antworten!
Wenn unter den Lesern diejenigen sind, die an unseren Sommerkonferenzen teilgenommen haben, teilen Sie uns bitte Ihre Eindrücke vom Spieler und der Übertragung mit. Was war praktisch, was hat Sie irritiert, was würden Sie gerne in Zukunft sehen?
Wenn Sie sich für die Plattform interessieren und sie „im Kampf“ sehen möchten, verwenden wir sie erneut auf unserem . Es gibt eine ganze Reihe davon, sodass mit ziemlicher Sicherheit eines dabei ist, das zu Ihnen passt.
Source: habr.com