Was braucht es, damit ein IT-Unternehmen im Jahr 2019 erfolgreich ist? Dozenten auf Konferenzen und Treffen sagen viele laute Worte, die für normale Menschen nicht immer verständlich sind. Der Kampf um Bereitstellungszeit, Microservices, Abkehr vom Monolithen, DevOps-Transformation und vieles mehr. Wenn wir verbale Schönheit aufgeben und direkt und auf Russisch sprechen, läuft alles auf eine einfache These hinaus: ein qualitativ hochwertiges Produkt herzustellen und dies mit Komfort für das Team.
Letzteres ist von entscheidender Bedeutung geworden. Die Wirtschaft ist mittlerweile zu dem Schluss gekommen, dass ein komfortabler Entwicklungsprozess die Produktivität steigert und dass, wenn alles debuggt ist und wie am Schnürchen funktioniert, auch in kritischen Situationen Spielraum bleibt. Es war einmal, dass sich für dieses Manöver ein gewisser kluger Mensch Backups ausgedacht hat, aber die Branche entwickelt sich weiter, und wir kamen zu DevOps-Ingenieuren – Menschen, die den Prozess der Interaktion zwischen Entwicklung und externer Infrastruktur in etwas Angemessenes verwandeln hat nichts mit Schamanismus zu tun.
Diese ganze „modulare“ Geschichte ist wunderbar, aber ... Es kam so vor, dass einige der Administratoren plötzlich DevOps genannt wurden und von DevOps-Ingenieuren selbst zumindest die Fähigkeiten der Telepathie und des Hellsehens verlangt wurden.
Bevor wir über moderne Probleme der Bereitstellung von Infrastruktur sprechen, wollen wir definieren, was wir unter diesem Begriff verstehen. Im gegenwärtigen Moment hat sich die Situation so entwickelt, dass wir die Dualität dieses Konzepts erreicht haben: Infrastruktur kann bedingt extern und bedingt intern sein.
Unter externer Infrastruktur verstehen wir alles, was die Funktionalität der Dienstleistung oder des Produkts gewährleistet, die das Team entwickelt. Hierbei handelt es sich um Anwendungs- oder Websiteserver, Hosting und andere Dienste, die die Funktionalität des Produkts sicherstellen.
Zur internen Infrastruktur gehören Dienste und Geräte, die vom Entwicklungsteam selbst und anderen Mitarbeitern, von denen es in der Regel viele gibt, genutzt werden. Dabei handelt es sich um interne Server von Codespeichersystemen, einen lokal bereitgestellten Task-Manager und alles, alles, alles, was im Unternehmensintranet vorhanden ist.
Was macht ein Systemadministrator in einem Unternehmen? Neben der Verwaltungsarbeit dieses Unternehmens-Intranets lastet oft auch die Last ökonomischer Belange, die Funktionsfähigkeit der Bürogeräte sicherzustellen. Der Administrator ist derselbe Typ, der schnell eine neue Systemeinheit oder einen einsatzbereiten Ersatzlaptop aus dem Hinterzimmer schleppt, eine neue Tastatur herausgibt und auf allen Vieren durch die Büros kriecht und dabei das Ethernet-Kabel spannt. Ein Administrator ist ein lokaler Eigentümer und Herrscher nicht nur interner und externer Server, sondern auch ein Geschäftsführer. Ja, einige Administratoren können nur auf der Systemebene ohne Hardware arbeiten. Sie sollten in eine separate Unterklasse der „Infrastruktursystemadministratoren“ unterteilt werden. Und manche spezialisieren sich ausschließlich auf die Wartung von Bürogeräten; glücklicherweise endet die Arbeit nie, wenn das Unternehmen mehr als hundert Mitarbeiter hat. Aber keiner von ihnen ist ein Entwickler.
Wer sind DevOps? Devops sind Leute, die über die Interaktion der Softwareentwicklung mit externer Infrastruktur sprechen. Genauer gesagt sind moderne Entwickler viel tiefer in die Entwicklungs- und Bereitstellungsprozesse involviert, als es jemals Administratoren waren, die lediglich Updates auf FTP hochgeladen haben. Eine der Hauptaufgaben eines DevOps-Ingenieurs besteht heute darin, einen komfortablen und effektiv strukturierten Prozess der Interaktion zwischen Entwicklungsteams und Produktinfrastruktur sicherzustellen. Es sind diese Leute, die für die Bereitstellung von Rollback- und Deployment-Systemen verantwortlich sind; es sind diese Leute, die Entwickler entlasten und sich so weit wie möglich auf ihre äußerst wichtige Aufgabe konzentrieren. Gleichzeitig werden Entwickler niemals ein neues Kabel verlegen oder einen neuen Laptop aus dem Hinterzimmer herausgeben (c) KO
Was ist der Haken?
Auf die Frage „Wer ist DevOps?“ Die Hälfte der Außendienstmitarbeiter fängt an, etwas zu antworten wie „Nun, kurz gesagt, das ist der Administrator, der ...“ und weiter im Text. Ja, es war einmal, als der Beruf des DevOps-Ingenieurs gerade erst unter den talentiertesten Administratoren in Sachen Servicewartung entstand, da waren die Unterschiede zwischen ihnen nicht für jeden offensichtlich. Aber jetzt, wo die Funktionen von Entwicklern und Administratoren im Team radikal unterschiedlich geworden sind, ist es inakzeptabel, sie miteinander zu verwechseln oder gar gleichzusetzen.
Aber was bedeutet das für das Geschäft?
Bei der Einstellung kommt es darauf an.
Sie eröffnen eine Stelle als „Systemadministrator“ und die dort aufgeführten Anforderungen lauten „Interaktion mit Entwicklung und Kunden“, „CI/CD-Bereitstellungssystem“, „Wartung der Server und Geräte des Unternehmens“, „Verwaltung interner Systeme“ und so weiter An; Sie verstehen, dass der Arbeitgeber Unsinn redet. Der Haken ist, dass die Stellenbezeichnung statt „Systemadministrator“ „DevOps Engineer“ lauten sollte, und wenn diese Bezeichnung geändert wird, passt alles zusammen.
Doch welchen Eindruck gewinnt man, wenn man eine solche Stellenausschreibung liest? Dass das Unternehmen einen Multi-Maschinen-Operator sucht, der sowohl ein Versionskontroll- als auch ein Überwachungssystem einsetzt und den Twister mit seinen Zähnen ausquetscht …
Um jedoch den Grad der Drogenabhängigkeit auf dem Arbeitsmarkt nicht zu erhöhen, reicht es aus, offene Stellen beim richtigen Namen zu nennen und klar zu verstehen, dass ein DevOps-Ingenieur und ein Systemadministrator zwei verschiedene Einheiten sind. Doch der unbändige Wunsch einiger Arbeitgeber, einem Kandidaten einen möglichst breiten Anforderungskatalog zu präsentieren, führt dazu, dass „klassische“ Systemadministratoren nicht mehr verstehen, was um sie herum passiert. Was, der Beruf verändert sich und sie sind hinter der Zeit zurück?
Nein, nein und noch einmal nein. Infrastrukturadministratoren, die die internen Server des Unternehmens verwalten oder L2/L3-Supportpositionen besetzen und anderen Mitarbeitern helfen, sind nicht verschwunden und werden auch nicht verschwinden.
Können diese Spezialisten DevOps-Ingenieure werden? Natürlich können sie das. Tatsächlich handelt es sich hierbei um eine verwandte Umgebung, die Systemadministrationsfähigkeiten erfordert, aber darüber hinaus kommt noch die Arbeit mit Überwachung, Bereitstellungssystemen und im Allgemeinen eine enge Interaktion mit dem Entwicklungs- und Testteam hinzu.
Ein weiteres DevOps-Problem
Tatsächlich beschränkt sich alles nicht nur auf die Einstellung von Mitarbeitern und die ständige Verwirrung zwischen Administratoren und Entwicklern. Irgendwann stand das Unternehmen vor dem Problem, Updates bereitzustellen und das Entwicklungsteam mit der endgültigen Infrastruktur zu interagieren.
Vielleicht war es, als ein Onkel mit funkelnden Augen auf der Bühne einer Konferenz stand und sagte: „Wir machen das und nennen es DevOps.“ Diese Jungs werden alle Ihre Probleme lösen“ – und begann zu erzählen, wie gut das Leben im Unternehmen nach der Implementierung von DevOps-Praktiken ist.
Es reicht jedoch nicht aus, einen DevOps-Ingenieur zu engagieren, damit alles so funktioniert, wie es sollte. Das Unternehmen muss eine vollständige DevOps-Transformation durchlaufen, das heißt, die Rolle und Fähigkeiten unserer DevOps müssen auch auf Seiten des Produktentwicklungs- und Testteams klar verstanden werden. Wir haben eine „wunderbare“ Geschichte zu diesem Thema, die die Brutalität, die an manchen Orten geschieht, voll und ganz veranschaulicht.
Situation. DevOps ist erforderlich, um ein Versions-Rollback-System bereitzustellen, ohne sich wirklich mit der Funktionsweise auseinanderzusetzen. Nehmen wir an, dass es im Benutzersystem separate Felder für Vorname, Nachname und Passwort gibt. Eine neue Version des Produkts erscheint, aber für Entwickler ist ein „Rollback“ nur ein Zauberstab, der alles repariert, und sie wissen nicht einmal, wie es funktioniert. So haben die Entwickler beispielsweise im nächsten Patch die Felder für Vor- und Nachnamen kombiniert und es in die Produktion eingeführt, aber die Version ist aus irgendeinem Grund langsam. Was ist los? Das Management kommt zu Devops und sagt „Drücken Sie den Schalter!“, das heißt, es fordert ihn auf, zur vorherigen Version zurückzukehren. Was machen Entwickler? Es wird auf die vorherige Version zurückgesetzt, aber da die Entwickler nicht herausfinden wollten, wie dieses Rollback durchgeführt wurde, teilte niemand dem Entwicklerteam mit, dass auch die Datenbank zurückgesetzt werden musste. Dadurch stürzt bei uns alles ab und statt einer langsamen Website sehen Nutzer einen „500“-Fehler, weil die alte Version nicht mit den Feldern der neuen Datenbank funktioniert. Devops weiß davon nichts. Die Entwickler schweigen. Das Management beginnt, die Nerven und das Geld zu verlieren, erinnert sich an die Backups und bietet an, sie zurückzusetzen, damit „zumindest etwas funktioniert“. Dadurch verlieren Benutzer mit der Zeit alle ihre Daten.
Die Nüsse gehen natürlich an Entwickler, die „kein richtiges Rollback-System entwickelt haben“, und es interessiert niemanden, dass die Elche in dieser Geschichte Entwickler sind.
Die Schlussfolgerung ist einfach: Ohne einen normalen Ansatz für DevOps als solchen nützt es wenig.
Das Wichtigste, woran Sie sich erinnern sollten: Ein DevOps-Ingenieur ist kein Zauberer, und ohne hochwertige Kommunikation und wechselseitige Interaktion mit der Entwicklung wird er seine Aufgaben nicht bewältigen. Entwickler können nicht mit ihren „Problemen“ allein gelassen werden oder den Befehl bekommen: „Misch dich nicht in die Entwickler ein, ihre Aufgabe ist es, zu programmieren“ und dann hoffen, dass in einem kritischen Moment alles so funktioniert, wie es sollte. So geht es nicht.
Im Wesentlichen ist DevOps eine Kompetenz an der Grenze zwischen Management und Technologie. Darüber hinaus ist es alles andere als offensichtlich, dass in diesem Cocktail mehr Technologie als Management enthalten sein sollte. Wenn Sie wirklich schnellere und effizientere Entwicklungsprozesse aufbauen möchten, müssen Sie Ihrem Entwicklerteam vertrauen. Er kennt die richtigen Werkzeuge, er hat ähnliche Projekte umgesetzt, er weiß, wie es geht. Helfen Sie ihm, hören Sie auf seinen Rat, versuchen Sie nicht, ihn in eine Art autonome Einheit zu isolieren. Wenn Administratoren selbstständig arbeiten können, sind Entwickler in diesem Fall nutzlos; sie können Ihnen nicht dabei helfen, besser zu werden, wenn Sie selbst diese Hilfe nicht annehmen möchten.
Und noch eine letzte Sache: Hören Sie auf, Infrastrukturadministratoren zu beleidigen. Sie haben ihre eigene, äußerst wichtige Arbeitsfront. Ja, ein Administrator kann DevOps-Ingenieur werden, dies sollte jedoch auf Wunsch der Person selbst und nicht unter Druck geschehen. Und es ist nichts Falsches daran, dass ein Systemadministrator Systemadministrator bleiben möchte – das ist sein eigener Beruf und sein Recht. Wenn Sie sich beruflich verändern wollen, dürfen Sie nie vergessen, dass Sie nicht nur technische, sondern auch Managementkompetenzen aufbauen müssen. Höchstwahrscheinlich liegt es an Ihnen als Führungskraft, all diese Menschen zusammenzubringen und ihnen beizubringen, in derselben Sprache zu kommunizieren.
Source: habr.com