Wir haben einmal einem Kunden in einer Einrichtung ein elektronisches Dokumentenmanagementsystem geliefert. Und dann zu einem anderen Objekt. Und einer mehr. Und am vierten und am fünften. Wir waren so begeistert, dass wir 10 verteilte Objekte erreichten. Es hat sich als beeindruckend erwiesen, vor allem, als wir die Änderungen umsetzen mussten. Im Rahmen der Übergabe an den Produktionskreislauf waren für 5 Szenarien des Testsystems letztendlich 10 Stunden und 6-7 Mitarbeiter erforderlich. Diese Kosten zwangen uns dazu, so selten wie möglich zu liefern. Nach drei Betriebsjahren hielten wir es nicht mehr aus und beschlossen, das Projekt mit einer Prise DevOps aufzupeppen.
Jetzt finden alle Tests in 3 Stunden statt und 3 Personen nehmen daran teil: ein Ingenieur und zwei Tester. Die Verbesserungen kommen deutlich in Zahlen zum Ausdruck und führen zu einer Reduzierung des beliebten TTM. Unserer Erfahrung nach gibt es viel mehr Kunden, die von DevOps profitieren können, als diejenigen, die überhaupt davon wissen. Um den Menschen DevOps näher zu bringen, haben wir daher einen einfachen Konstruktor entwickelt, auf den wir in diesem Beitrag ausführlicher eingehen werden.
Lassen Sie uns es Ihnen nun genauer erzählen. Ein Energieunternehmen führt in zehn großen Anlagen ein technisches Dokumentenmanagementsystem ein. Es ist nicht einfach, Projekte dieser Größenordnung ohne DevOps zu bewältigen, da ein großer Anteil manueller Arbeit die Arbeit erheblich verzögert und auch die Qualität mindert – jede manuelle Arbeit ist mit Fehlern behaftet. Andererseits gibt es Projekte, bei denen zwar nur eine Installation vorhanden ist, aber alles automatisch, konstant und fehlerfrei funktionieren muss – zum Beispiel die gleichen Dokumentenflusssysteme in großen monolithischen Organisationen. Andernfalls nimmt jemand die Einstellungen manuell vor, vergisst die Bereitstellungsanweisungen – und in der Produktion gehen die Einstellungen verloren und alles bricht zusammen.
Normalerweise arbeiten wir vertraglich mit dem Kunden zusammen, wobei in diesem Fall unsere Interessen leicht auseinandergehen. Der Kunde betrachtet das Projekt streng im Rahmen des Budgets und der technischen Spezifikationen. Es kann schwierig sein, ihm die Vorteile verschiedener DevOps-Praktiken zu erklären, die nicht in den technischen Spezifikationen enthalten sind. Was ist, wenn er an schnellen Releases mit Mehrwert für das Unternehmen oder am Aufbau einer Automatisierungspipeline interessiert ist?
Wenn mit vorab genehmigten Kosten gearbeitet wird, wird dieses Interesse leider nicht immer gefunden. In unserer Praxis gab es einen Fall, in dem wir die Entwicklung eines skrupellosen und nachlässigen Auftragnehmers übernehmen mussten. Es war schrecklich: Es gab keine aktuellen Quellcodes, die Codebasis desselben Systems war auf verschiedenen Installationen unterschiedlich, die Dokumentation fehlte teilweise und war teilweise von schrecklicher Qualität. Natürlich hatte der Kunde keine Kontrolle über den Quellcode, die Assembly, die Releases usw.
Bisher kennt nicht jeder DevOps, aber sobald wir über seine Vorteile, über echte Ressourceneinsparungen sprechen, leuchten die Augen aller Kunden. Daher nimmt die Anzahl der Anfragen, die DevOps beinhalten, mit der Zeit zu. Um hier problemlos mit Kunden die gleiche Sprache sprechen zu können, müssen wir Geschäftsprobleme und DevOps-Praktiken schnell miteinander verbinden, um eine geeignete Entwicklungspipeline aufzubauen.
Wir haben also einerseits eine Reihe von Problemen, andererseits verfügen wir über DevOps-Wissen, -Praktiken und -Tools. Warum nicht die Erfahrung mit allen teilen?
Erstellen eines DevOps-Konstruktors
Agile hat ein eigenes Manifest. ITIL verfügt über eine eigene Methodik. DevOps hat weniger Glück – es verfügt noch nicht über Vorlagen und Standards. Obwohl Bestimmen Sie den Reifegrad von Unternehmen anhand einer Bewertung ihrer Entwicklung und betrieblichen Praktiken.
Glücklicherweise hat das bekannte Unternehmen Gartner im Jahr 2014 und analysierte wichtige DevOps-Praktiken und die Beziehungen zwischen ihnen. Auf dieser Grundlage habe ich eine Infografik veröffentlicht:
Wir haben es als Grundlage für unsere genommen . Jeder der vier Bereiche verfügt über eine Reihe von Tools – wir haben sie in einer Datenbank gesammelt, die beliebtesten identifiziert, Integrationspunkte und geeignete Optimierungsmechanismen identifiziert. Im Großen und Ganzen hat es geklappt 36 Praktiken und 115 Tools, ein Viertel davon sind Open-Source- oder freie Software. Als nächstes sprechen wir darüber, was wir in den einzelnen Bereichen erreicht haben und beispielhaft darüber, wie dies in dem Projekt zur Erstellung eines technischen Dokumentenmanagements umgesetzt wurde, mit dem wir den Beitrag begonnen haben.
Prozesse
Im berüchtigten EDMS-Projekt wurde das technische Dokumentationsmanagementsystem nach dem gleichen Schema an jedem der 10 Objekte eingesetzt. Die Installation umfasst 4 Server: Datenbankserver, Anwendungsserver, Volltextindizierung und Content Management. In der Installation arbeiten sie innerhalb eines einzigen Knotens und befinden sich im Rechenzentrum der Einrichtungen. Alle Objekte unterscheiden sich geringfügig in der Infrastruktur, was die globale Interaktion jedoch nicht beeinträchtigt.
Zuerst haben wir gemäß den DevOps-Praktiken die Infrastruktur lokal automatisiert, dann haben wir die Lieferung an den Testkreis und dann an das Produkt des Kunden weitergeleitet. Jeder Prozess wurde Schritt für Schritt erarbeitet. Die Umgebungseinstellungen werden im Quellcodesystem festgelegt, wobei berücksichtigt wird, dass das Distributionskit für die automatische Aktualisierung kompiliert ist. Bei Konfigurationsänderungen müssen Ingenieure lediglich die entsprechenden Änderungen am Versionskontrollsystem vornehmen – und schon erfolgt die automatische Aktualisierung problemlos.
Dank dieses Ansatzes wurde der Testprozess erheblich vereinfacht. Zuvor gab es im Projekt Tester, die nichts anderes taten, als Stände manuell zu aktualisieren. Jetzt kommen sie einfach, schauen, dass alles funktioniert und erledigen weitere nützliche Dinge. Jedes Update wird automatisch getestet – von der Oberflächenebene bis zur Automatisierung von Geschäftsszenarien. Die Ergebnisse werden als separate Berichte in TestRail veröffentlicht.
Kultur
Kontinuierliches Experimentieren lässt sich am besten am Beispiel des Testdesigns erklären. Ein System zu testen, das noch nicht existiert, ist kreative Arbeit. Wenn Sie einen Testplan schreiben, müssen Sie verstehen, wie Sie richtig testen und welchen Zweigen Sie folgen müssen. Und finden Sie auch ein Gleichgewicht zwischen Zeit und Budget, um die optimale Anzahl an Kontrollen zu ermitteln. Es ist wichtig, genau die erforderlichen Tests auszuwählen, darüber nachzudenken, wie der Benutzer mit dem System interagieren wird, und die Umgebung und mögliche externe Faktoren zu berücksichtigen. Ohne kontinuierliches Experimentieren geht es nicht.
Nun zur Kultur der Interaktion. Bisher gab es zwei gegensätzliche Seiten – Ingenieure und Entwickler. Die Entwickler sagten: „Es ist uns egal, wie es gestartet wird. Sie sind Ingenieure, Sie sind schlau, sorgen dafür, dass es störungsfrei funktioniert.“. Die Ingenieure antworteten: „Ihr Entwickler seid zu nachlässig. Lasst uns vorsichtiger sein und eure Veröffentlichungen seltener spielen. Denn jedes Mal, wenn Sie uns einen undichten Code geben, ist uns nicht klar, wie wir interagieren sollen.“. Dies ist ein Problem der kulturellen Interaktion, das aus DevOps-Perspektive anders strukturiert ist. Hier sind sowohl Ingenieure als auch Entwickler Teil eines einzigen Teams, das sich auf ständig wechselnde, aber gleichzeitig zuverlässige Software konzentriert.
Innerhalb desselben Teams sind Spezialisten entschlossen, sich gegenseitig zu helfen. Wie war es vorher? Beispielsweise wurden einige dicke Bereitstellungsanweisungen erstellt, etwa 50 Seiten lang. Der Ingenieur las sie, verstand etwas nicht, fluchte und bat den Entwickler um drei Uhr morgens um einen Kommentar. Der Entwickler kommentierte und fluchte auch – am Ende war niemand glücklich. Außerdem gab es natürlich auch ein paar Fehler, weil man sich nicht alles in der Anleitung merken kann. Und jetzt schreibt der Ingenieur zusammen mit dem Entwickler ein Skript für die automatisierte Bereitstellung der Anwendungssoftware-Infrastruktur. Und sie sprechen praktisch in derselben Sprache miteinander.
Leute
Die Größe des Teams richtet sich nach dem Umfang des Updates. Das Team wird während der Zusammenstellung der Lieferung rekrutiert und umfasst Interessenten aus dem allgemeinen Projektteam. Anschließend wird mit den Verantwortlichen für jede Phase ein Aktualisierungsplan erstellt und das Team berichtet über den Fortschritt. Alle Teammitglieder sind austauschbar. Im Team haben wir auch einen Backup-Entwickler, der sich aber fast nie einschalten muss.
der Technik
Im Technologiediagramm sind einige Punkte hervorgehoben, aber darunter gibt es eine Reihe von Technologien – mit deren Beschreibungen könnte man ein ganzes Buch veröffentlichen. Deshalb heben wir die interessantesten hervor.
Infrastruktur als Code
Nun wird dieses Konzept wahrscheinlich niemanden überraschen, aber bisher ließen die Beschreibungen der Infrastrukturen zu wünschen übrig. , die Testumgebungen waren einzigartig, sie wurden geschätzt und geschätzt, Staubpartikel wurden von ihnen weggeblasen.
Heutzutage hat niemand mehr Angst vor Experimenten. Es gibt grundlegende Images virtueller Maschinen und vorgefertigte Szenarien für die Bereitstellung von Umgebungen. Alle Vorlagen und Skripte werden in einem Versionskontrollsystem gespeichert und zeitnah aktualisiert. Wenn es bisher notwendig war, ein Paket an einen Stand zu liefern, entstand eine Konfigurationslücke. Jetzt müssen Sie nur noch eine Zeile zum Quellcode hinzufügen.
Zur Dokumentation kommt neben Infrastrukturskripten und Pipelines auch der Documentation as a Code-Ansatz zum Einsatz. Dadurch ist es einfach, neue Leute an das Projekt anzuschließen, sie anhand der beispielsweise im Testplan beschriebenen Funktionen an das System heranzuführen und auch Testfälle wiederzuverwenden.
Kontinuierliche Lieferung und Überwachung
Zum Thema DevOps sprachen wir darüber, wie wir Tools für die Implementierung von Continuous Delivery und Monitoring ausgewählt haben. Oft muss nichts neu geschrieben werden – es reicht aus, zuvor geschriebene Skripte zu verwenden, die Integration zwischen Komponenten korrekt aufzubauen und eine gemeinsame Verwaltungskonsole zu erstellen. Und alle Prozesse können per Knopfdruck oder Zeitplan gestartet werden.
Im Englischen gibt es unterschiedliche Konzepte, Continuous Delivery und Continuous Deployment. Beides kann mit „kontinuierliche Lieferung“ übersetzt werden, tatsächlich gibt es jedoch einen kleinen Unterschied zwischen ihnen. In unserem Projekt für den technischen Dokumentenfluss eines dezentralen Energieunternehmens wird eher „Lieferung“ verwendet – wenn die Installation für die Produktion auf Befehl erfolgt. Bei der Bereitstellung erfolgt die Installation automatisch. Continuous Delivery ist in diesem Projekt generell geworden zentraler Bestandteil von DevOps.
Im Allgemeinen können Sie durch das Sammeln bestimmter Parameter klar verstehen, warum DevOps-Praktiken nützlich sind. Und vermitteln Sie dies dem Management, das Zahlen wirklich liebt. Die Gesamtzahl der Starts, die Ausführungszeit von Skriptphasen, der Anteil erfolgreicher Starts – all dies wirkt sich direkt auf die von allen bevorzugte Markteinführungszeit aus, d. h. auf die Zeit von der Übergabe an das Versionskontrollsystem bis zur Veröffentlichung einer Version auf einem Produktionsumfeld. Mit der Implementierung der notwendigen Tools erhalten Ingenieure wertvolle Indikatoren per E-Mail und der Projektmanager sieht sie auf dem Dashboard. So können Sie den Nutzen neuer Tools sofort beurteilen. Und Sie können sie mit dem DevOps-Designer in Ihrer Infrastruktur ausprobieren.
Wer wird unsere brauchen ?
Machen wir uns nichts vor: Erstens hat er sich für uns als nützlich erwiesen. Wie wir bereits gesagt haben, müssen Sie mit dem Kunden die gleiche Sprache sprechen, und mit Hilfe des DevOps-Designers können wir schnell die Grundlage für ein solches Gespräch skizzieren. Betriebswirte können ihre Bedürfnisse selbst einschätzen und sich so schneller weiterentwickeln. Wir haben versucht, den Designer so detailliert wie möglich zu gestalten und eine Reihe von Beschreibungen hinzuzufügen, damit jeder Benutzer versteht, was er wählt.
Das Format des Designers ermöglicht es Ihnen, die bestehenden Entwicklungen des Unternehmens in den Bereichen Bauprozesse und Automatisierung zu berücksichtigen. Es besteht keine Notwendigkeit, alles abzureißen und neu aufzubauen, wenn Sie nur Lösungen wählen können, die sich gut in bestehende Prozesse integrieren und die Lücken einfach schließen können.
Vielleicht ist Ihre Entwicklung bereits auf ein höheres Niveau gestiegen und unser Tool erscheint Ihnen zu „kapitänsmäßig“. Aber wir finden es nützlich für uns selbst und hoffen, dass es einigen Lesern nützlich sein wird. Wir erinnern Sie daran an den Designer - wenn überhaupt, erhalten Sie das Diagramm sofort nach Eingabe der Ausgangsdaten. Für Rückmeldungen und Ergänzungen sind wir Ihnen dankbar.
Source: habr.com