Auf der letztjährigen Konferenz
DevOpsDays Moscow berichtete der Betriebsleiter des Banki.ru-Portals Andrei Nikolsky über Waisendienste: Wie man ein Waisenkind in der Infrastruktur identifiziert, was schlechte Waisendienste sind, was man mit ihnen macht und wie man ist, wenn nichts hilft.
Unter dem Schnitt befindet sich die Textversion des Berichts.
Hallo Kollegen! Mein Name ist Andrey, ich leite die Operation bei Banki.ru.
Wir haben großartige Dienstleistungen, dies sind monolithische Dienstleistungen, es gibt Dienstleistungen im klassischen Sinne, es gibt sehr kleine. In der Terminologie meiner Arbeiter und Bauern sage ich, wenn der Dienst einfach und klein ist, dann ist er mikro, und wenn er nicht sehr einfach und nicht klein ist, dann ist er nur ein Dienst.
Service-Profis
Ich werde schnell auf die Vorteile von Diensten eingehen.
Der erste ist die Skalierung. Sie können schnell etwas für den Service tun und mit der Produktion beginnen. Sie sind im Verkehr angekommen, Sie haben den Dienst geklont. Du hast immer noch Verkehr, du hast immer noch geklont und lebst damit. Dies ist ein guter Bonus, und als wir anfingen, wurde er im Prinzip als der wichtigste unter uns angesehen, warum wir das alles tun.
Zweitens: Isolierte Entwicklung, wenn Sie mehrere Entwicklungsteams, mehrere verschiedene Entwickler in jedem Team und jedes Team eine Art Service sehen.
Es gibt eine Nuance mit den Teams. Entwickler sind anders. Und es gibt zum Beispiel
Menschen-Schneeflocken . Ich habe das zum ersten Mal bei Maxim Dorofeev gesehen. Manchmal haben Leute in einigen Teams Schneeflocken, andere nicht. Dies macht die verschiedenen Dienste, die im Unternehmen verwendet werden, etwas ungleichmäßig.
Schauen Sie sich das Bild an: Er ist ein guter Entwickler, er hat große Hände, er kann viel. Das Hauptproblem ist, woher diese Hände wachsen.
Dienste ermöglichen die Verwendung verschiedener Programmiersprachen, die für verschiedene Aufgaben besser geeignet sind. Einige Dienste auf Go, einige auf Erlang, einige auf Ruby, einige auf PHP, einige auf Python. Im Allgemeinen können Sie sich sehr breit umdrehen. Hier gibt es auch Nuancen.
Bei der serviceorientierten Architektur geht es hauptsächlich um Entwickler. Das heißt, wenn Sie keine Automatisierung haben, gibt es keinen Bereitstellungsprozess. Wenn Sie mit Ihren Händen konfigurieren, können sich Ihre Konfigurationen von einer Dienstinstanz zu einer Instanz ändern, und Sie müssen dorthin gehen, um etwas zu tun, dann sind Sie in der Hölle.
Zum Beispiel haben Sie 20 Dienste, und Sie müssen mit Ihren Händen bereitstellen, Sie haben 20 Konsolen und Sie drücken gleichzeitig die Eingabetaste, wie ein Ninja. Das ist nicht sehr gut.
Wenn Sie nach dem Testen einen Dienst haben (wenn es natürlich Tests gibt) und Sie ihn auch mit einer Datei beenden müssen, damit er in der Produktion funktioniert, habe ich auch schlechte Nachrichten für Sie.
Wenn Sie sich auf die spezifischen Dienste von Amazon verlassen und in Russland arbeiten, hatten Sie vor zwei Monaten auch die Meldung "Alles brennt, mir geht es gut, alles ist cool."
Wir verwenden Ansible für die Bereitstellungsautomatisierung, Puppet für die Konvergenz, Bamboo für die Bereitstellungsautomatisierung und Confluence, um alles irgendwie zu beschreiben.
Ich werde nicht im Detail darauf eingehen, da es in dem Bericht mehr um die Praxis von Interaktionen und nicht um die technische Umsetzung geht.
Zum Beispiel hatten wir Probleme, dass Puppet auf dem Server mit Ruby 2 funktioniert, und einige Anwendungen wurden unter Ruby 1.8 geschrieben, und zusammen funktionieren sie nicht. Dort passiert eine Art Pfosten. Und wenn Sie mehrere Versionen von Ruby auf demselben Computer behalten müssen, treten normalerweise Probleme auf.
Zum Beispiel geben wir jedem Entwickler eine Plattform, auf der es fast alles gibt, was wir haben, alle Dienste, die entwickelt werden können, damit er eine isolierte Umgebung hat. Er kann sie aufteilen und nach Belieben erstellen.
Es kommt vor, dass Sie eine Art speziell kompiliertes Paket benötigen, das dort etwas unterstützt. Das ist hart genug. Ich habe mir einen Bericht angehört, in dem das Docker-Image 45 GB wiegt. Unter Linux ist es natürlich einfacher, dort ist alles kleiner, aber es wird sowieso nicht genug Plätze geben.
Nun, es gibt widersprüchliche Abhängigkeiten, wenn Sie einen Teil eines Projekts in Abhängigkeit von der Bibliothek einer Version, einen anderen Teil des Projekts in einer anderen Version haben und Bibliotheken überhaupt nicht zusammengestellt werden.
Wir haben Websites und Dienste in PHP 5.6, wir schämen uns dafür, aber was zu tun ist. Dies ist unsere einzige Seite. Es gibt Websites und Dienste in PHP 7, es gibt mehr davon, wir schämen uns nicht dafür. Und jeder Entwickler hat seine eigene Basis, in der er gerne sägt.
Wenn Sie im Unternehmen in einer Sprache schreiben, dann drei virtuelle Maschinen pro Entwickler - das klingt normal. Wenn Sie verschiedene Programmiersprachen haben, verschlechtert sich die Situation.
Sie haben Websites und Dienste auf dieser, auf einer anderen Plattform für Go, einer Plattform für Ruby und einer weiteren Redis auf der Seite. Infolgedessen wird all dies zu einem großen Feld für die Unterstützung, und währenddessen kann ein Teil davon brechen.
Aus diesem Grund haben wir die Brötchen der Programmiersprache durch die Verwendung unterschiedlicher Frameworks ersetzt, da die Frameworks in PHP sehr unterschiedlich sind, unterschiedliche Funktionen, unterschiedliche Communitys und unterschiedliche Unterstützung haben. Und Sie können einen Dienst schreiben, damit Sie bereits etwas dafür bereit haben.
Jeder Dienst hat ein eigenes Team.
Unser Hauptvorteil, der sich über mehrere Jahre herauskristallisierte, ist, dass jeder Service sein eigenes Team hat. Dies ist praktisch für ein großes Projekt. Sie können Zeit bei der Dokumentation sparen. Die Manager sind sich ihres Projekts bewusst.
Aufgaben vom Support können perfekt geworfen werden. Zum Beispiel ist der Versicherungsdienst zusammengebrochen. Und sofort geht das Versicherungsteam zur Reparatur.
Neue Funktionen werden schnell erstellt, denn wenn Sie einen Atomdienst haben, können Sie schnell etwas hineinschrauben.
Und wenn Sie Ihren Dienst unterbrochen haben und dies unweigerlich passiert, haben Sie die Dienste anderer nicht verletzt, und Entwickler mit Teilen anderer Teams greifen nicht auf Sie zurück und sagen nicht: "Aw, tun Sie das nicht."
Wie immer gibt es Nuancen. Wir haben stabile Teams, Manager sind an das Team gebunden. Es gibt klare Dokumente, Manager überwachen dies alles genau. Jedes Team mit einem Manager verfügt über mehrere Dienste, und es gibt einen bestimmten Kompetenzpunkt.
Wenn die Teams schweben (dies wird manchmal auch bei uns verwendet), gibt es eine gute Methode, die als Sternenkarte bezeichnet wird.
Sie haben eine Liste von Diensten und Personen. Ein Sternchen bedeutet, dass eine Person ein Experte für diesen Dienst ist. Ein Buch bedeutet, dass eine Person diesen Dienst studiert. Die Aufgabe des Menschen ist es, ein kleines Buch gegen ein Sternchen auszutauschen. Und wenn gegenüber dem Dienst nichts geschrieben steht, beginnen Probleme, über die ich weiter sprechen werde.
Wie erscheinen verwaiste Dienste?
Das erste Problem, der erste Weg, um ein Service-Waisenkind in Ihre Infrastruktur zu bringen, besteht darin, Menschen zu entlassen. Ist jemals jemand passiert, wenn Fristen aus dem Geschäft eintreffen, bevor sie Aufgaben bewerten? Manchmal kommt es vor, dass die Fristen knapp sind und einfach nicht genug Zeit für die Dokumentation bleibt. "Wir müssen den Service an die Produktion übergeben, dann werden wir ihn hinzufügen."
Wenn das Team klein ist, gibt es einen Entwickler, der alles schreibt, der Rest ist in den Startlöchern. "Ich habe die grundlegende Architektur geschrieben, Sie geben mir die Schnittstellen." Dann geht der Manager zum Beispiel irgendwann. In dieser Zeit, in der der Manager gegangen ist und noch kein neuer ernannt wurde, entscheiden die Entwickler selbst, wohin der Service verlegt wird und was dort vor sich geht. Und wie wir wissen (lassen Sie uns ein paar Folien zurückgehen), gibt es in einigen Teams Menschen-Schneeflocken, manchmal einen Schneeflocken-Timlid. Dann gibt er auf und wir bekommen eine Dienstwaise.
Gleichzeitig verschwinden Aufgaben aus dem Support und aus dem Geschäft nicht, sondern werden im Rückstand erledigt. Wenn während der Entwicklung des Dienstes Architekturfehler aufgetreten sind, werden diese auch im Rückstand berücksichtigt. Der Service verschlechtert sich langsam.
Wie identifiziere ich eine Waise?
Diese Liste beschreibt die Situation gut. Wer hat etwas in der Infrastruktur gelernt?
Zu den dokumentierten Workarounds: Es gibt einen Service, der im Allgemeinen funktioniert. Er enthält ein zweiseitiges Handbuch, wie man damit arbeitet, aber niemand weiß, wie es im Inneren funktioniert.
Oder es gibt zum Beispiel eine Art Link-Shortener. Zum Beispiel verwenden wir jetzt drei Link-Shortener für verschiedene Zwecke in verschiedenen Diensten. Das sind die Konsequenzen.
Jetzt werde ich der Hauptmann der Beweise sein. Was muss getan werden? Zunächst müssen Sie den Service an einen anderen Manager oder ein anderes Team übertragen. Wenn Ihr Teamleiter noch nicht gekündigt hat, müssen Sie in diesem anderen Team, wenn Sie verstehen, dass der Dienst wie eine Waise ist, jemanden einbeziehen, der zumindest etwas über ihn versteht.
Die Hauptsache: Sie müssen blutgeschriebene Übertragungsverfahren haben. In unserem Fall folge ich normalerweise dem, weil ich das brauche, um zu funktionieren. Manager brauchen dies, um schnell geliefert zu werden, und was später mit ihm geschehen wird, ist für sie nicht so wichtig.
Der nächste Weg, um eine Waise zu machen, ist: "Lass es uns auslagern, es wird schneller und dann werden wir es an das Team übertragen." Es ist klar, dass jeder einige Pläne im Team hat, der Warteschlange. Oft glaubt ein Geschäftskunde, dass ein Outsourcer dasselbe tut wie die technische Abteilung im Unternehmen. Obwohl ihre Motivatoren unterschiedlich sind. Outsourcing hat seltsame technologische Lösungen und seltsame algorithmische Lösungen.
Zum Beispiel hatten wir einen Dienst, bei dem sich Sphinx an verschiedenen unerwarteten Orten befand. Ich werde dir später sagen, was ich tun musste.
Outsourcer haben selbstgeschriebene Rahmenbedingungen. Dies ist nur nacktes PHP mit Copy-Paste aus dem vorherigen Projekt, wo Sie alles finden können. Große Krücken in Bereitstellungsskripten, wenn Sie mehrere Zeilen in einer Datei mit einigen komplexen Bash-Skripten ändern müssen, während diese Bereitstellungsskripten von einem dritten Skript aufgerufen werden. Infolgedessen ändern Sie das Bereitstellungssystem, wählen etwas anderes aus, hüpfen und Ihr Dienst funktioniert nicht. Weil es 8 weitere Links zwischen verschiedenen Ordnern gab. Oder es kommt vor, dass tausend Datensätze funktionieren, aber hunderttausend weg sind.
Ich werde weiterhin Kapitän. Das Akzeptieren eines Dienstes aus dem Outsourcing ist ein Verfahren, das erforderlich ist. Wer ist passiert, dass ein Service von einem Outsourcer eintrifft, der aber nirgendwo akzeptiert wird? Dies ist natürlich nicht so beliebt wie ein Dienstwaisenkind, aber dennoch.
Der Dienst muss überprüft werden, der Dienst muss überprüft werden, die Passwörter müssen geändert werden. Wir hatten einen Fall, als der Dienst uns warf, dort ist das Admin-Panel "if login == 'admin' && password == 'admin' ..." direkt in den Code geschrieben. Wir sitzen und denken, und die Leute schreiben das im Jahr 2018?
Das Testen des Speichervolumens ist ebenfalls ein Muss. Sie müssen sich ansehen, was auf hunderttausend Datensätzen passieren wird, noch bevor Sie diesen Service irgendwo in der Produktion starten.
Senden Sie den Dienst zur Überarbeitung sollte sich nicht schämen. Wenn Sie sagen: „Wir werden diesen Service nicht annehmen, wir haben 20 Aufgaben, erledigen sie, dann werden wir annehmen“, ist dies normal. Das Gewissen sollte nicht dadurch schaden, dass Sie einen Manager ersetzen oder dass ein Unternehmen Geld ausgibt. Das Geschäft wird dann mehr ausgeben.
Wir hatten einen Fall, als wir beschlossen, ein Pilotprojekt zum Thema Outsourcing durchzuführen.
Es wurde pünktlich geliefert, und dies war das einzige Qualitätskriterium. Deshalb haben sie ein weiteres Pilotprojekt durchgeführt, nicht einmal ein Pilotprojekt. Diese Dienste wurden akzeptiert, sagten sie auf administrative Weise, hier ist Ihr Code, hier ist ein Team, hier ist Ihr Manager. Dienstleistungen haben wirklich bereits begonnen, Gewinn zu machen. Darüber hinaus blieben sie tatsächlich Waisen, niemand versteht, wie sie arbeiten, und Manager lehnen ihre Aufgaben in jeder Hinsicht ab.
Es gibt ein weiteres hervorragendes Konzept - die Partisanenentwicklung. Wenn eine Abteilung in der Regel eine Marketingabteilung ist, möchten sie eine Hypothese testen und den gesamten Service auslagern. Der Verkehr beginnt auf ihn zu strömen, sie schließen Dokumente, unterschreiben Gesetze mit dem Auftragnehmer, treten in Betrieb und sagen: „Leute, wir haben hier einen Dienst, er hat bereits Verkehr, er bringt uns Geld, lass es uns nehmen.“ Wir sind: "Oppa, wie so."
Und noch ein Weg, um einen Waisendienst zu erhalten: Wenn ein Team plötzlich geladen wird, sagt das Management: „Lassen Sie uns den Dienst dieses Teams auf ein anderes Team übertragen, es hat weniger Last.“ Und dann werden wir zum dritten Team wechseln und den Manager wechseln. Und am Ende haben wir wieder eine Waise.
Was ist das Problem mit Waisenkindern?
Wer weiß nicht, dies war das Schiff der Linie Wasa, das in Schweden angehoben wurde und berühmt dafür ist, dass es 5 Minuten nach dem Start gesunken ist. Und der König von Schweden hat übrigens niemanden dafür hingerichtet. Es wurde von zwei Generationen von Ingenieuren gebaut, die solche Schiffe nicht bauen konnten. Die natürliche Wirkung.
Das Schiff könnte übrigens viel schlimmer sinken, wenn der König es irgendwo im Sturm reiten würde. Und so ertrank er sofort, laut Ajail ist es gut, früh zu scheitern.
Wenn wir früh versagen, gibt es normalerweise keine Probleme. Zum Beispiel haben sie während der Annahme zur Überarbeitung geschickt. Und wenn wir bereits in der Produktion gescheitert sind, wenn das Geld investiert wird, kann es Probleme geben. Die Konsequenzen, wie sie im Geschäft genannt werden.
Warum gefährliche Waisendienste:
- Der Service kann plötzlich unterbrochen werden.
- Service wird für eine lange Zeit repariert oder überhaupt nicht repariert.
- Sicherheitsprobleme.
- Probleme mit Verbesserungen und Updates.
- Wenn ein wichtiger Service ausfällt, leidet der Ruf des Unternehmens.
Was tun mit Waisendiensten?
Noch einmal, was zu tun ist. Erstens sollte es eine Dokumentation geben. 7 Jahre lang wurde mir bei Banki.ru beigebracht, dass Tester kein Wort für Entwickler und Betrieb kein Wort für alle haben sollten. Es ist notwendig zu überprüfen.
Zweitens müssen Interaktionsschemata geschrieben werden, da Dienste, die nicht gut aufgenommen werden, Abhängigkeiten enthalten, über die niemand gesprochen hat. Zum Beispiel setzen die Entwickler den Dienst auf ihren Schlüssel zu einigen Yandex.Maps oder zu Dadata. Sie haben kein freies Limit mehr, alles ist kaputt und Sie wissen gar nicht, was passiert ist. Alle diese Rechen sollten beschrieben werden: Der Dienst verwendet Dadata, SMS, etwas anderes.
Drittens arbeiten mit der technischen Verschuldung. Wenn Sie Krücken bauen oder den Service annehmen und sagen, dass etwas getan werden muss, müssen Sie sicherstellen, dass sie es tun. Denn dann kann sich herausstellen, dass das kleine Loch nicht so klein ist und Sie dort hinfallen.
Bei architektonischen Aufgaben hatten wir eine Geschichte über Sphinx. In einem der Dienste wurde Sphinx verwendet, um Listen einzugeben. Nur eine Paginierungsliste, die aber jede Nacht neu indiziert wurde. Es wurde aus zwei Indizes zusammengestellt: Einer wurde jede Nacht groß indiziert, und es gab immer noch einen kleinen Index, der daran angeschraubt war. Jeden Tag, mit einer Wahrscheinlichkeit von 50%, wird der Index während der Berechnung entweder bombardiert oder nicht, und die Nachrichten wurden auf der Hauptseite nicht mehr aktualisiert. Zuerst waren es 5 Minuten, während der Index neu indiziert wurde, dann wuchs der Index und irgendwann begann er 40 Minuten neu zu indizieren. Als wir es herausschnitten, atmeten wir erleichtert auf, denn es war klar, dass etwas mehr Zeit vergehen würde und unser Index ganztägig neu indiziert werden würde. Es wird eine Datei für unser Portal sein, acht Stunden gibt es keine Neuigkeiten - das war's, das Geschäft ist aufgestanden.
Arbeitsplan mit einem Waisendienst
In der Tat ist es sehr schwierig, weil es bei Devops um Kommunikation geht. Ich möchte in guten Beziehungen zu meinen Kollegen stehen, und wenn Sie Kollegen und Manager mit Vorschriften auf den Kopf schlagen, haben sie möglicherweise widersprüchliche Gefühle für diejenigen, die dies tun.
Zusätzlich zu all diesen Punkten gibt es noch eine weitere wichtige Sache: Für jeden bestimmten Dienst, für jeden bestimmten Abschnitt des Bereitstellungsverfahrens sollten bestimmte Personen verantwortlich sein. Wenn es keine Leute gibt und man andere Leute anziehen muss, um das Ganze zu studieren, wird es schwierig.
Wenn all dies nicht hilft und das Dienstwaisenkind immer noch ein Waisenkind ist, niemand es zu Ihnen bringen möchte, die Dokumentation nicht geschrieben ist, das Team, das zu diesem Dienst gerufen wurde, sich weigert, etwas zu tun, gibt es eine einfache Möglichkeit, alles zu wiederholen .
Das heißt, Sie nehmen die Serviceanforderungen neu und schreiben einen neuen Service, besser, auf einer besseren Plattform, ohne seltsame technologische Lösungen. Und im Kampf dorthin migrieren.
Wir hatten eine Situation, als wir den Dienst auf Yii 1 in Anspruch nahmen und feststellten, dass wir ihn nicht weiterentwickeln können, da wir keine Entwickler mehr haben, die gut auf Yii 1 schreiben können. Alle Entwickler schreiben gut auf dem dritten Symfony. Was zu tun ist? Wir haben uns die Zeit genommen, das Team zugewiesen, den Manager zugewiesen, das Projekt neu geschrieben und den Datenverkehr reibungslos darauf umgestellt.
Danach kann der alte Dienst gelöscht werden. Dies ist mein Lieblingsverfahren, wenn Sie einen Dienst aus dem Konfigurationsmanagementsystem entfernen und bereinigen und dann überprüfen müssen, ob alle Fahrzeuge in der Produktion zurückgezahlt wurden, damit die Entwickler keine Spuren mehr haben. Das Repository im Git bleibt erhalten.
Das ist alles, worüber ich sprechen wollte, ich bin bereit zu diskutieren, das Thema ist ganzheitlich, viele schwebten darin.
Auf den Folien ging es um die Tatsache, dass Sie Sprachen vereinheitlicht haben. Ein Beispiel war die Größenänderung von Bildern. Aber ist es wirklich notwendig, hart auf eine Sprache zu sprechen? Da Sie die Größe von Bildern in PHP ändern können, können Sie dies auch in Golang tun.Tatsächlich ist dies nicht wie bei allen Praktiken erforderlich. Vielleicht in einigen Fällen sogar unerwünscht. Aber Sie müssen verstehen, dass wenn Sie 50 Leute in der technischen Abteilung haben, 45 von ihnen PHP-Entwickler sind, weitere 3 Entwickler, die Python, Ansible, Puppet und so etwas können, und nur einer von ihnen schreibt über einige Gehen Sie zum Service, um die Größe von Bildern zu ändern. Wenn er geht, geht die Prüfung mit ihm. Gleichzeitig müssen Sie nach einem marktspezifischen Entwickler suchen, der diese Sprache kennt, insbesondere wenn sie selten ist. Das ist aus organisatorischer Sicht problematisch. Aus Sicht der Entwickler müssen Sie nicht nur einige vorgefertigte Playbooks klonen, die Sie zum Bereitstellen von Diensten verwenden, sondern diese auch erneut schreiben.
Wir sehen jetzt den Dienst auf Node.js und es wird nur eine Plattform in der Nähe für jeden Entwickler mit einer eigenen Sprache sein. Aber wir saßen da und dachten, dass das Spiel die Kerze wert war. Das heißt, die Frage hier ist, zu sitzen und nachzudenken.
Wie überwachen Sie Ihre Dienste? Wie sammeln und verfolgen Sie Protokolle?Wir sammeln Protokolle in Elasticsearch und legen sie in Kibana ab. Je nach Produktions- oder Testumgebung werden dort verschiedene Kollektoren verwendet. Irgendwo Holzfäller, irgendwo anders etwas, an das ich mich nicht mehr erinnere. Und es gibt immer noch einige Stellen in bestimmten Diensten, an denen wir Telegraf und Kugel getrennt woanders ablegen.Wie lebe ich mit Puppet und Ansible in einer Umgebung?Tatsächlich haben wir jetzt zwei Umgebungen, eine ist Puppet, die andere ist Ansible. Wir arbeiten daran, sie zu hybridisieren. Ansible ist eine gute Umgebung für die Ersteinrichtung, Puppet ist eine schlechte Umgebung für die Ersteinrichtung, da Hände erforderlich sind, um direkt mit der Site zu arbeiten, und Puppet eine Konvergenz der Konfiguration bietet. Dies bedeutet, dass die Site selbst auf dem neuesten Stand gehalten wird. Damit der ansiblisierte Computer auf dem neuesten Stand gehalten werden kann, müssen Sie Playbooks in beliebiger Häufigkeit damit verfolgen. Hier ist so ein Unterschied.Wie erhalten Sie die Kompatibilität aufrecht? Haben Sie Konfigurationen in Ansible und Puppet?Dies ist unser großer Schmerz, wir behalten die Kompatibilität mit unseren Händen bei und denken, als ob wir uns jetzt von all dem irgendwo wegbewegen würden. Es stellt sich heraus, dass Puppet Pakete rollt und dort einige Links unterstützt, während Ansible beispielsweise den Code rollt und dort neue Anwendungskonfigurationen steuert.Die Präsentation befasste sich mit verschiedenen Versionen von Ruby. Was ist die Lösung?Wir sind an einem Ort damit konfrontiert, und wir müssen dies die ganze Zeit im Auge behalten. Wir haben gerade den Teil deaktiviert, der auf dem Ruby funktioniert hat, der mit Anwendungen nicht kompatibel war, und ihn getrennt gehalten.Dieses Jahr findet die DevOpsDays- Konferenz in Moskau am 7. Dezember in Technopolis statt. Bis zum 11. November akzeptieren wir Bewerbungen für Berichte. Mailen Sie uns, wenn Sie sprechen möchten.
Die Registrierung für Teilnehmer ist offen, mach mit!