Am Vorabend von DevOps Conf Russia 2018 sprachen wir mit dem technischen Direktor von Uchi.ru, Alexei Vakhov, über die Entwicklungsstufen der Plattform, welche Tools sie verwenden und wie viel DevOps ovo vorhanden ist.
Alexey Vakhov - Technischer Direktor von Uchi.ru. Er arbeitete als C ++ - Entwickler an riesigen Systemen (zig Millionen Codezeilen). Die beliebteste Servertechnologie - Ruby on Rails - gehört zu den Top 100 Mitwirkenden. Er liebt die Organisation der IT-Produktion, den Betrieb und die Architektur von Webanwendungen.
Uchi.ru ist eine russische Bildungsplattform, auf der Schüler der Klassen 1 bis 11 auf unterhaltsame und unterhaltsame Weise Schulfächer lernen. Die Plattform wird von mehr als 2,5 Millionen Schülern und 220.000 Lehrern in Russland, den USA, Brasilien, Indien, Südafrika und China genutzt. Es belegt den 36. Platz im globalen Ranking der E-Learning-Plattformen. Das Unternehmen beschäftigt mehr als 400 Mitarbeiter.- Wie hat alles angefangen? Wie viele Personen waren bei Ihrer Ankunft in der Firma?- Ich wurde 2012, also vor sechs Jahren, in das Unternehmen eingeladen. Zu dieser Zeit war ich der fünfte oder sechste Mitarbeiter und der einzige Entwickler. Ich habe gesetzt und Serverentwicklung gemacht. Wir haben die erste Webanwendung erstellt und auf Heroku veröffentlicht.
"Wie geht es jetzt?" Wie viele Teams und welche Größen? Wie unabhängig? Wie interagieren sie miteinander?- Heute haben wir mehr als 400 Mitarbeiter, von denen etwa 100 Ingenieure sind, die in etwa 20 verschiedenen Teams zusammengefasst sind. Wir haben zwei große Richtungen: Produktionsentwicklung und Entwicklung interaktiver Aufgaben.
Separate Teams verfügen über eine eigene isolierte Umgebung, spezielle Build-Systeme, die für die vom Team ausgeführten Aufgaben geschärft sind, eigene Server und Quellcodes. Sie kommunizieren nur bei Bedarf miteinander.
- Schaffst du es mit dieser Wachstumsrate des Unternehmens, dein eigenes Wiki zu erstellen? Wie unterstützt du sie?- Wir haben mehrere Wissensbasen. Es gibt ein Wiki in Form von Zusammenfluss, in dem es allgemeine und thematische Abschnitte gibt und jedes Team seinen eigenen Abschnitt hat. In jedem Repository unterstützen wir Readme und zusätzliche White Papers. In jedem Fall wird jedem Team sein eigener Raum zugewiesen, sein eigenes Stück in Jira, im Zusammenfluss, all dies wird nach den Wünschen des Teams angeordnet. Wir haben kein Diktat und keine Standardisierung für das Design.
- Ein starker Anstieg ist mit einem Kontrollverlust verbunden. Wie gehst du damit um? Wie koordinieren Sie die Arbeit so vieler Teams?- Die allgemeine Koordination wird durch den Aufbau einer Managementhierarchie erreicht. Wir haben Überweisungskoordinatoren und jedes Team hat seinen eigenen Leiter. Hier ist alles einfach.
Wenn Sie diese Frage aus technologischer Sicht beantworten, halten sich die Teams an allgemeine Regeln, z. B. werden Tests mit jedem Repository verbunden, die gesamte Entwicklung geht in neue Zweige, die überprüft, in die Testumgebung und dann in die Produktion eingeführt werden.
- Welche Phasen der Unternehmensgründung wählen Sie für sich aus?- Ich mag den Ansatz, über den ich in einem interessanten Buch gelesen habe, wonach die Krise ist, wenn das übliche Wertesystem zusammenbricht. In unserem Fall gab es aufgrund eines so schnellen Krisenwachstums viele Krisen, von denen jede die weitere Bewegung bestimmt.
Die erste Krise kam, als wir in einem Raum eng wurden und auf zwei expandieren mussten. Zu diesem Zeitpunkt erschienen Informationen, die nicht mehr allen bekannt waren. Die zweite und nachfolgende Krise kam, als Entwickler sich in Produktteams aufteilen mussten. Wieder war unser großes und freundliches Team gezwungen, sich zu trennen und sich aus verschiedenen Blickwinkeln zu trennen.
Alle Änderungen, die bei uns vorgenommen wurden, wurden notwendigerweise durch zeitnahe und relevante technologische Innovationen unterstützt. Gleiches gilt für die DevOps-Methodik. Wir können sagen, dass ich selbst erst vor kurzem angefangen habe zu verstehen, was kulturelle Werte sind und warum sie in großen Teams wichtig sind. Es gab zum Beispiel eine Zeit, in der niemand eine Frage hatte, wer für die Stabilität der Website verantwortlich ist. Jeder verstand, dass derjenige, der den Dienst einführte, für ihn verantwortlich war. Wir haben eine Person eingestellt, die eigentlich nur für den Server verantwortlich sein sollte - und die Konfrontation „Entwickler gegen Administratoren“ begann am selben Tag. Es war unglaublich, wie ein Buch.
- Erzähl mir mehr über jede der Stufen. Welche Werkzeuge haben Sie für sich genommen, welche mussten Sie ablehnen? Nach meinem Verständnis aus der Ankündigung Ihrer Leistung auf der DevOpsConf 2018 wird Ihre gesamte Infrastruktur in Docker-Containern in den Clouds bereitgestellt. Warum bist du zu einer solchen Entscheidung gekommen? Seit wann könnten Sie nicht ohne Container leben?- Zuerst gab es nichts, nicht einmal einen Tracker. Nur Rollout für Heroku: Git Push, und alle sind glücklich. Aber Heroku hörte schnell auf, uns zu befriedigen, da es vorher ziemlich viel Ping gab und sie die Last nicht tolerierten. Wir zogen zu normalen Eisenservern und stellten Berater ein. Im Laufe der Zeit ist der Server stark verschmutzt. Zu diesem Zeitpunkt haben wir den Datenverkehr, die Anzahl der Produktions-, internen und externen Services erheblich erhöht. Wir haben Server über Chef konfiguriert. Eines schönen Tages fielen wir unter Last und am Abend zogen wir mit Ansible in die Cloud. Das Gefühl, zu Ansible zu wechseln, war einfach kosmisch. Es stellte sich als einfach und verständlich heraus, insbesondere bei solch kleinen Infrastrukturen.
Ausgehend von ungefähr 60 Anwendungen hat sich unsere Infrastruktur zu separaten, wie wir sie nennen, „Standorten“ entwickelt. Dies sind isolierte Wolken mit eigenen Subnetzen, eigener Terraform und ansiblen Konfigurationen.
Mit der wachsenden Anzahl von Anwendungen und Servern begann unsere Konfiguration zu schweben, da vor dem Starten einer einfachen Anwendung auf RoR viele Dinge zu beachten sind. Außerdem befand sich ein Teil der Rollout-Konfiguration im Repository mit der Anwendung, ein Teil in den Ensemble-Rezepten. Die Entwickler begannen, geheime Magie zu verwenden, Links zu Ordnern herzustellen und eine Art Synchronisation durchzuführen. Infolgedessen wurde es völlig unmöglich zu warten.
Als wir ungefähr hundert Anwendungen in verschiedenen Clouds hatten, begannen wir, uns Docker genauer anzusehen. Das war letzten Sommer. In ungefähr 10 Monaten haben wir alle unsere Anwendungen auf Docker-Cluster übertragen, und zu diesem Zeitpunkt waren es ungefähr 150. Dies ist für uns zu einer echten Rettung geworden. Wir wurden von der Überwachung von Versionen und Abfällen von Umgebungen auf Servern verschont. Alles wurde viel bequemer und einfacher: Die Anwendung konnte leicht in einem Docker-Cluster platziert, leicht von dort entfernt werden, sie hatte ihre eigenen Metainformationen, aus denen hervorgeht, aus welchen Diensten die Anwendung besteht, welche Kronen, Hintergrundjobs usw. gestartet werden.
- Wie fest stehen Sie auf dem ursprünglichen DevOps-Ansatz? Passt alles zu dir oder hast du etwas für dich geändert? War es schwierig, das Team wieder aufzubauen?- Ich selbst habe keine genaue Antwort auf die Frage, was DevOps ist. Bei der Arbeit gehe ich immer vom einfachen gesunden Menschenverstand aus. Und die Leute sagen, dass sich herausstellt, dass hier DevOps gewachsen ist. Tatsächlich brauche ich den theoretischen Teil von DevOps fast nicht, weil das Unternehmen mich nach Ergebnissen fragt. Mit anderen Worten, wenn ich es ihnen schön erzähle und nichts tue, wird es sehr schlecht sein, und wenn ich es tue, aber nicht über Schönheit erzähle, wird es immer noch gut sein.
Mein Verständnis von DevOps ist wie folgt. Zum Beispiel gibt es ein großes Unternehmen, das digitale Produkte herstellen möchte oder bereits herstellt. Digitale Produkte sind immer schnelles Feedback vom Markt. Die kontinuierliche Bereitstellung erfolgt automatisch, die Grenzen zwischen Entwicklung und Support verschwimmen, die DevOps-Kultur wird verschärft, wodurch die Regeln der guten Form zwischen den Personen interpretiert werden, die für die Einführung, das Testen und den Support verantwortlich sind. Infolgedessen ermöglichen solche Beziehungen ihnen, sich untereinander zu einigen, um ein gemeinsames Ziel zu erreichen, und den Fokus von ihrer persönlichen Verantwortung auf ein gemeinsames Ergebnis zu verlagern. In einem großen und etablierten Unternehmen kommt es zu Veränderungen in Prozessen, deren Bruch.
Da wir kein etabliertes Unternehmen hatten, sind wir sehr schnell mit Arbeitsprinzipien aufgewachsen. Darüber hinaus hat uns das Geschäft ständig neue Aufgaben gestellt, sodass wir unsere Infrastruktur in erster Linie auf der Grundlage des gesunden Menschenverstandes und der internen Anforderungen aufgebaut haben.
Das Wort DevOps bedeutete mir wenig. Aber jetzt, als wir das alles durchgingen, als ich die Entstehung von Konfliktpunkten und die Verwischung von Verantwortlichkeiten sah, wurde mir klar, dass DevOps wie ein kultureller Aspekt der Interaktion zwischen Menschen für einen gemeinsamen Zweck ist. Gemeinsame Ziele bei digitalen Produkten sind es, neue Funktionen zu entwickeln und diese so schnell wie möglich einzuführen.
- Es wäre interessant zu erfahren, wie schwierig es für Anfänger ist, mit so vielen modernen Werkzeugen an Ihrer Arbeit teilzunehmen. Wie ist Ihre Arbeit mit Menschen organisiert?- Wir haben Anpassungsprogramme. Wir erzählen dem neuen Mitarbeiter, wie wir uns entwickelt haben und wie alles jetzt arrangiert ist. Wir binden ihm einen Mentor bei. Am ersten Tag helfen wir ihm, die Umgebung einzurichten und einen Kampf zu führen, aber keine sehr schwierige Aufgabe. Der Mentor begleitet ihn mehrere Monate, hilft bei der Anpassung.
- Erzählen Sie uns von den Plänen des Unternehmens. Wo wollen Sie wachsen und welche Bereiche sollen Sie entwickeln? Bietet der aktuelle Technologie-Stack die Grundlage für weiteres Wachstum oder müssen Sie ihn erneut ändern?- Geschäftspläne sind ehrgeizig. Heute besuchen regelmäßig mehr als zwei Millionen Schüler Uchi.ru, was etwa 30% aller Grundschüler im ganzen Land entspricht. Wir werden weiterhin neue Benutzer für die Plattform in Russland gewinnen und uns an der internationalen Entwicklung beteiligen.
Technisch gesehen haben wir 15 isolierte Docker-Cluster, und es wird ziemlich viel Zeit für den Wechsel von einem zum anderen aufgewendet. Die Wartung und Aktualisierung ist schwierig geworden. Die Anforderungen an Änderungsgeschwindigkeit und Zuverlässigkeit wachsen immer mehr. Daher gibt es eine Reserve, aber wir werden auch aktualisieren.
Freunde, wenn Sie an Alexeys Erfahrungen interessiert sind, laden wir Sie schnell zu unserer
DevOps Conf Russia 2018 ein , die vom 1. bis
2. Oktober stattfinden wird. In seinem Bericht wird er über die Erfahrungen mit der Verwendung von Clouds, die Anwendung der DevOps-Methodik, die Werte und Prinzipien seines Teams sprechen.
Abonnieren Sie den Ontiko DevOps Themed Newsletter, um Programmaktualisierungen zu erhalten, sobald diese verfügbar sind. Wir versuchen, die Briefe nützlich und nicht aufdringlich zu gestalten. Wir senden Konferenznachrichten, Abschriften von Berichten und frische Videos.
Das Video kann übrigens separat auf dem YouTube-Kanal überwacht werden - es wurden alle Videos der letzten Jahre gesammelt und die Liste wird ständig aktualisiert.