Hallo alle zusammen! Mein Name ist Timur Gilmullin, ich bin der stellvertretende Leiter der Abteilung für Technologien und Entwicklungsprozesse bei Positive Technologies, ich beschäftige mich mit Automatisierung und setze die Ideen von DevOps um. Heute erzähle ich Ihnen, wie ich in den Beruf gekommen bin, wie wir in unserer Abteilung die Karriere eines DevOps-Ingenieurs sehen, was eine Kompetenzkarte ist und wie sie dazu beiträgt, das Mitarbeiterwachstum sicherzustellen.Haftungsausschluss
Dieser Artikel ist kein Versuch, den idealen Karriereweg eines DevOps-Ingenieurs zu beschreiben. Unser Ziel ist es, Erfahrungen auszutauschen und zu erzählen, wie es bei uns funktioniert. Es gibt spezialisierte Unternehmen ( Express 42 , Flant ) und Communities ( Devops Deflope ), die einen wesentlichen Beitrag zur Entwicklung von DevOps-Ideen in Russland leisten, und wir haben einen Stapel von Technologien und Techniken ausgewählt, die für uns geeignet sind.Wie wir DevOps-Ideen in unserer Abteilung und im Unternehmen entwickelt haben, lesen Sie auf Habré:Und jetzt lass uns gehen!Warum brauchen wir DevOps?
Jedes Unternehmen hat seine eigenen Besonderheiten der Automatisierungsabteilung. In der Regel werden Aufgaben, die auf der Ebene mehrerer separater Abteilungen schwierig oder zu kostspielig sind, an eine zentrale Gruppe oder Automatisierungsabteilung übertragen. In unserem Unternehmen besteht das globale Ziel der Umsetzung von DevOps-Ideen darin, die Produktionskosten und den Produkt-Support quantitativ (Mann- oder Maschinenstunden, CPU, RAM) konsequent zu senken.Basierend auf diesem Ziel wird die Rolle der Automatisierungsabteilung auf der Ebene des gesamten Unternehmens hervorgehoben - dies dient dazu, die Kosten für die Ausführung typischer serieller Aufgaben in allen Produktionsphasen zu minimieren.Wie es funktioniert
Die funktionalen Verantwortlichkeiten der Automatisierungsabteilungen hängen auch stark von den Besonderheiten eines bestimmten Unternehmens ab. Unser Unternehmen ist Entwickler und Anbieter von Informationssicherheitslösungen. Die Automatisierungsabteilung ist für den Produktionsförderer verantwortlich - von der Montage einzelner Produktkomponenten bis hin zum Senden und Testen von Updates an die Infrastruktur des Kunden. Wir helfen bei der Automatisierung der wichtigsten Entwicklungsprozesse in Teams und stellen die Leistung unserer Systeme sicher (kontinuierliche Integration und kontinuierliche Lieferung (CI / CD)).Unsere Arbeit ist in mehrere Funktionsbereiche unterteilt. Die Richtung der kontinuierlichen Integration unterstützt Montage- und Testpipelines für Entwickler und Tester. Die Richtung der Infrastruktur befasst sich mit dem Betrieb und der Optimierung der Nutzung aller "Eisen" -Ressourcen der Abteilung sowie mit der Automatisierung der Bereitstellung virtueller Maschinen und ihrer Umgebung (Infrastruktur als Code). Die Überwachungsrichtung ermöglicht die Kontrolle der täglichen Verfügbarkeit von Diensten. Wir bieten auch Monitoring als Service für Entwickler an (Monitoring als Service).Die Workflow-Richtung bietet Teams Tools zum Verwalten von Entwicklungs- und Testprozessen, zum Analysieren des Codezustands und zum Abrufen von Projektanalysen. Schließlich bietet webdev Veröffentlichungsversionen auf Unternehmens-Update-Servern (GUS und FLUS) sowie Lizenzierungsprodukte über den License Lab-Dienst.Zur Unterstützung der Produktionspipeline haben wir viele verschiedene Support-Services für Entwickler eingerichtet und verwaltet. Geschichten über einige von ihnen sind auf unseren alten Mitaps zu hören: Op! DevOps! 2016 und Op! DevOps! 2017 . Wir entwickeln auch interne Automatisierungstools, einschließlich DevOpsHQ .
Die Erfahrung unserer Ingenieure
Die Mitarbeiter unserer Automatisierungsabteilung (der Einfachheit halber informell DevOps-Abteilung genannt) haben einen völlig anderen Hintergrund: Es gibt ehemalige Tester, Programmierer, Ingenieure und IT-Administratoren. Ich bin Diplomlehrer in Mathematik und Informatik. Wie sich herausstellte, konnten wir dank der Vielfalt der Erfahrungen die Aufgaben aller unserer Bereiche bewältigen.In unserer Abteilung gibt es keinen einzigen Ingenieur, der alle Probleme in allen Bereichen im Alleingang lösen könnte. Aber zusammen sind wir als Verwaltungseinheit damit SRE(nur keine Site, ein Service Reliability Engineers, da wir Services für Entwickler unterstützen), die HR-Spezialisten in der Person eines Ingenieurs erfolglos suchen. Wir glauben, dass eine Vielzahl von Produktaufgaben des Unternehmens nur als Teil eines Teams diversifizierter Ingenieure gelöst werden kann.Wir haben sehr viele technische Fälle für die Implementierung der Automatisierung. Die Hauptsache ist jedoch, den Menschen zu erklären, warum sie diese Automatisierung benötigen. Der einfachste Weg ist, wenn die technische Aufgabe aus dem Geschäft kommt, dh wenn Leute, die Geld in das Unternehmen bringen, ein klares Verständnis haben: Was, wie und wann zu tun oder zu optimieren. Ich schlage vor, Sie sehen sich unsere Automatisierungsfälle an: " Persönliche Erfahrung: Wie unser Continuous Integration-System aussieht ."Über eine Karriere in unserer DevOps-Abteilung
Ich möchte sagen, dass alles im Voraus fertig und geplant war, aber das ist nicht so. Anfangs hatten wir nichts in unseren Plänen für Wachstum und Entwicklung. Als ich 2014 in die Abteilung für Technologie- und Entwicklungsprozesse wechselte, lebte die Produktentwicklung im Geiste eines Startups: Hier und jetzt muss alles getan werden, langfristige Pläne wurden nicht akzeptiert, es gab viel „Vermächtnis“. Damals gab es vier Ingenieure, und wir hatten viele technische Aufgaben: Wir mussten dringend CI ausführen, die Montagelinie skalieren, vorher natürlich diese Linie erstellen und auch die Interaktion mit unseren internen Kunden aufbauen - Programmierern aus den Entwicklungsabteilungen.Im Laufe der Zeit verbesserten sich jedoch die Prozesse und die Abteilung wuchs. Zusammen mit ihm wuchs das Verständnis dafür, was unsere Ingenieure wissen wollten: Welche Entwicklungsperspektiven haben sie als Spezialisten, was kann die Abteilung für neue Ingenieure bieten? Das erste, was sich logischerweise daraus ergibt, ist, dass wir eine Wachstumstabelle für die Positionen und Kategorien von Ingenieuren benötigen. Wie das Sprichwort sagt: Wenn die Gesellschaft keine Farbdifferenzierung von Hosen hat, dann gibt es keinen Zweck! Und wenn es kein Ziel gibt ...Wir haben alles so einfach wie möglich gemacht. Die interne Organisationsstruktur unserer Abteilung besteht aus drei Führungspositionen (Abteilungsleiter, stellvertretender Leiter und Gruppenleiter) und vier Führungspositionen (Junior-, reguläre, Senior- und führende Software-Ingenieure), die wiederum in jeweils drei Kategorien unterteilt sind. Die Personalabteilung verwendet häufig eine ähnliche Berufsbezeichnung, jedoch ohne Unterteilung in Kategorien. Für unsere Abteilung haben die Kategorien dazu beigetragen, ein reibungsloseres und allmählicheres Wachstum der Mitarbeiter zu gewährleisten, da ihre Verantwortungs- und Arbeitsbereiche zunahmen.
Für jede Kategorie entwickelten wir Dokumente mit Stellenbeschreibungen, in denen die Funktionen und Rollen der Mitarbeiter vorgeschrieben waren und auch die Verantwortungsbereiche der Mitarbeiter für Dienstleistungen und Arbeitsbereiche angegeben wurden.Da wir aber neben dem Engineering auch gerne programmieren und keiner von uns gerne langweilige Dokumente liest, haben wir auch hier unser Leben ein wenig vereinfacht. Wir haben nicht jede Anweisung in Word geschrieben, sondern in Form von einfachem Text, der mit einer speziellen Markdown- Markup-Sprache formatiert ist . Gleichzeitig geht die Lesbarkeit einer Person in einem Editor nicht verloren. Danach haben wir diese Texte in unserem GitLab-Repository gespeichert. GitLab selbst kann verschiedene Dokumentformate, einschließlich Markdown-Zeichnungen, sehr schön anzeigen, so dass es nicht von Word unterschieden werden kann. Und der Standard-Git-Client verfügt über viele zusätzliche Funktionen, z. B. kann er Unterschiede zwischen zwei Dokumenten anzeigen.Dies vereinfacht das Leben eines Ingenieurs erheblich, der herausfinden möchte, welche formalen Anforderungen er erfüllen muss, um zum nächsten Schritt (Kategorie) des persönlichen Wachstums in unserer Abteilung überzugehen. Um den Unterschied zwischen den formalen Anforderungen der beiden Jobbeschreibungen herauszufinden, müssen Sie einige einfache Schritte ausführen: Laden Sie das Repository mit Jobbeschreibungen aus unserem GitLab herunter, suchen Sie Dokumente, führen Sie den Befehl Git in der Konsole aus, um einen Vergleich der beiden Dateien anzuzeigen. Beispielsweise können Sie den Unterschied zwischen einem leitenden Ingenieur der 2. und 1. Kategorie wie folgt erkennen:git --no-pager diff --no-index
level_08__DevOps_Senior_Software_Engineer_2nd_category.md
level_09__DevOps_Senior_Software_Engineer_1st_category.md
In der Konsole, an die alle Softwareentwickler gewöhnt sind, stehen das Minuszeichen und die rote Farbe für Anforderungen, die geändert oder gelöscht wurden, und die hinzugefügten Zeilen zeichnen sich durch ein Pluszeichen und eine grüne Farbe aus: Jede Zeile ist plus eine neue Anforderung.Ja, wir sind ein kleiner Technikfreak, aber dann schien es uns eine großartige Lösung zu sein:
DevOps Engineer-Kompetenzkarte
Als sich unsere Abteilung weiterentwickelte und die Anzahl der von uns unterstützten Produktförderer zunahm, stellten wir fest, dass es für jeden Arbeitsbereich, in dem wir tätig sind, nicht möglich sein wird, eine einzigartige Rolle zu beschreiben und einen geeigneten Ingenieur auf dem Markt zu finden. Wir haben unsere eigenen Arbeitsspezifikationen und benötigen zum Beispiel keinen hochqualifizierten Programmierer-Softwareentwickler, um CI-Probleme zu lösen. Dennoch muss ein CI-Ingenieur in der Lage sein, kleine Module und Skripte in Python auf einem akzeptablen Niveau zu programmieren. Ebenso benötigen wir keinen mega-qualifizierten Linux-Administrator, aber wir benötigen eine Person mit ausreichenden Kenntnissen des Debian- oder Ubuntu-Betriebssystems, damit er die GitLab CI-Build-Agenten installieren und diese Arbeiten noch besser über SaltStack, Ansible oder andere Tools automatisieren kann.Was sollte ein DevOps-Ingenieur in unserer Abteilung tun können? Dazu müssen Sie zunächst feststellen, welche Kenntnisse, Fähigkeiten und Fertigkeiten (abgekürzt ZUN ) im allgemeinen Sinne vorhanden sind.- Wissen ist das Hauptgesetz des Fachgebiets, das es einer Person ermöglicht, bestimmte produktive, wissenschaftliche und andere Probleme zu lösen, dh Fakten, Konzepte, Urteile, Bilder, Beziehungen, Schätzungen, Regeln, Algorithmen, Heuristiken sowie Entscheidungsstrategien in diesem Bereich. Wissen ist auch Informationselemente, die miteinander und mit der Außenwelt verbunden sind.
- Fähigkeiten - Sie werden von einer Person als beherrscht verstanden, wie man eine Handlung ausführt, die mit einem bestimmten Wissensbestand ausgestattet ist. Die Fähigkeit drückt sich in der Fähigkeit aus, Wissen in der Praxis bewusst anzuwenden.
- — , . , , , , .
Wenn wir den ZUN genauer in Bezug auf die im Unternehmen entwickelten Produkte definieren, erhalten wir eine allgemeine Liste der Kompetenzen. Ohne die Beherrschung dieser Kompetenzen kann der Ingenieur in unserer Abteilung nicht qualitativ arbeiten. Die Liste erwies sich als sehr lang, da sie die Besonderheiten der Arbeit in allen Bereichen, Technologien und Produkten sofort berücksichtigt.Daher mussten wir alle unsere Anforderungen an einen Ingenieur in tabellarischer Form beschreiben und klassifizieren, und wir haben eine „ DevOps Engineers 1.0 Competency Map “. Es sieht so aus: Die Tabelle ist in vier große Abschnitte unterteilt:
- Beschreibung der allgemeinen Kompetenzen der Mitarbeiter unserer DevOps-Abteilung, die für die erfolgreiche Lösung alltäglicher Aufgaben erforderlich sind.
- Wissen ist das spezifische, produktorientierte Wissen der DevOps-Ingenieure.
- — ; .
- — ; , .
In den Zellen der Tabelle werden qualitative Bewertungen angegeben: Auf welcher Ebene sollte ein Ingenieur ungefähr die eine oder andere Kompetenz haben. Leider kann ich mir hier nicht die Vollversion der Tabelle vorstellen, aber dies ist nicht erforderlich, da jedes Unternehmen und jede Abteilung unter Berücksichtigung der Besonderheiten der Arbeit eine eigene ähnliche Tabelle erstellen muss.2018 haben meine Kollegen und ich die sogenannte technologische Karte des Produktionsprozesses entwickelt und erstellt (lesen Sie den Artikel über das Habr „ Chaos Management: Wir ordnen die Dinge mithilfe der technologischen Karte “). Dank ihr haben wir es geschafft, einen Wachstums- und Entwicklungsvektor für die Kompetenzen der DevOps-Ingenieure zu schaffen, der vom Produkt, den darin verwendeten Technologien und den Phasen des Produktförderers abhängt.
Eine solche Karte beschreibt alle Phasen und Schritte, aus denen sich der technologische Förderer für die Herstellung unserer Produkte zusammensetzt. Aus Produktsicht ist es wichtig zu verstehen, wie viele Ingenieure, welche Qualifikationen und mit welchen Kompetenzen wir benötigen, um den kontinuierlichen Betrieb dieses Förderers sicherzustellen. Besser noch: Planen und sichern Sie Mitarbeiter so, dass sie trotz der Unterstützung kritischer Dienste beispielsweise ruhig in den Urlaub fahren können und wissen, dass es in der Abteilung jemanden gibt, der über Kompetenzen verfügt und diese ersetzen kann.Alles in allem sollte uns dies zur „DevOps Engineers 2.0 Competency Map“ führen, in der der ZUN je nach Produkt und den erforderlichen Kompetenzen für die Automatisierungsarbeiten in diesem Produkt klar beschrieben wird. Das heißt, es sollte eine gewisse Bindung der Stufen auf der technologischen Karte an die Karte der Kompetenzen der Ingenieure auftreten. Im nächsten Artikel werde ich versuchen, Ihnen zu sagen, was daraus geworden ist.PS Der Artikel wurde basierend auf der Geschichte des Januar-Treffens geschrieben, zu dem Kollegen von Hays uns freundlicherweise zum Erfahrungsaustausch eingeladen haben (Sie können die Präsentation und den Text sehen ).Verfasser : Timur Gilmullin- Stellvertreter. Leiter Technologie- und Entwicklungsprozesse (DevOps), Positive Technologien.