In meiner Organisation arbeite ich mit einer Gruppe von NOC-Mitarbeitern, angehenden Junior-Ingenieuren und einer Handvoll erfahrener Ingenieure zusammen; alle mit Schwerpunkt auf Linux. Ein interessanter Schritt in der Art und Weise, wie das Unternehmen Talente fördert, ist, dass es einen Weg vom NOC in die höheren Ingenieursränge gibt. Wenn ich mir den Talentpool als relativer Neuling ansehe, sehe ich, dass es eine Kluft in den Fähigkeiten gibt, die mit der Zeit tendenziell größer wird ...
- Es gibt Ingenieure, die sich mit einer oder mehreren bestimmten Technologien gut auskennen und ständig in diese Bereiche eintauchen, z. B. MySQL, Firewalls, SAN-Speicher, Lastenausgleich …
- Andere wiederum sind Generalisten und kennen sich mit mehreren Technologien aus.
- Alle lernen genügend Linux (Befehle, Prozesse), um das zu tun, was sie täglich brauchen und nutzen.
Ein Unterscheidungsmerkmal einiger Mitarbeiter ist, wie gut sie Skripting-, Automatisierungs- und Konfigurationsmanagementmethoden beherrschen. Wir haben beispielsweise zwei Ingenieure, die den Großteil der Amazon-AWS CloudFormationArbeit, und ein anderer, der den Großteil derMarionetteInfrastruktur. Vielleicht ein Viertel der Ingenieure sind versiert im Umgang mit BASH-Shell-Skripten.
Betrachtet man dies im Kontext derunglaublichhohe Nachfrage nachDevOps-Kenntnisse auf dem Arbeitsmarkt, ich bin gespannt, wie andere Organisationen die Entwicklung dieser Fähigkeiten fördern und ihre internen Talente ausbauen. Scripting scheint kein besonders lehrbares Konzept zu sein.
- Wie verbessert ein Systemadministrator seine Shell-Skripte?
- Gibt es noch einen Platz für Ingenieure, die im DevOps-Paradigma nicht mithalten können/wollen?
- Müssen wir einfach davon ausgehen, dass bei der Weiterentwicklung dieser Technologien einige Menschen auf der Strecke bleiben? Ist das in Ordnung?
Antwort1
Ich habe den Vorteil, die Größe und Komplexität Ihrer Umgebung zu kennen. Da Sie für einen Cloud-/Hosting-Anbieter arbeiten, kann man davon ausgehen, dass Sie eine große Anzahl kleiner bis mittelgroßer Umgebungen (10-100 Server) haben. Es gibt sicherlich tägliche Aufgaben, die von den Junior-Ingenieuren und dem NOC-Personal ausgeführt werden und die sich wiederholen (Erstellen von Benutzerkonten, Konfigurieren von Backup-Agenten usw.). Ebenso gibt es wahrscheinlich einige manuelle Aufgaben, die von den Senior-Ingenieuren ausgeführt werden, wie das Installieren von ESXi auf neuer Hardware oder das Konfigurieren von Dingen wie MPIO oder das Installieren von VMware-Modulen für bestimmte Hardwaresätze. All diese Dinge können und sollten automatisiert werden.
Wenn Ihr Personal in der Lage ist, den Großteil seiner Arbeitslast ohne Automatisierung zu erledigen, dann sind Sie meiner Meinung nach überbesetzt. Jeder IT-Mitarbeiter, der einen ganzen Tag lang hauptsächlich manuelle Prozesse erledigen kann, hat keine Motivation zur Automatisierung. Warum sollte er eine neue Fähigkeit erlernen, die nicht alsnotwendigund könnte sogarbeängstigend– Schließlich ist Not die Mutter der Innovation.
Irgendwann wird Ihre Organisation also eine Größe erreichen, bei der Sie ins Straucheln geraten und auseinanderfallen, oder Sie beginnen, fast alles zu automatisieren und sich hervorzutun. Natürlich sollten die erfahrenen Ingenieure hier die Führung übernehmen und vielleicht sogar mit den Junior-Ingenieuren und dem NOC-Personal zusammenarbeiten, um einen Teil ihrer Arbeitslast zu automatisieren. Dies gibt den Junior-Ingenieuren die Möglichkeit, mit einem Rahmen aus vielen Skripten zu arbeiten, die sie bei Bedarf für jeden Mieter und jede neue Hardwarerevision optimieren können. Dies beseitigt den entmutigenden Gedanken „Oh mein Gott, wo fange ich überhaupt an?“ aus der Gleichung und gibt ihnen einen Vorsprung bei der Lösung einesrealProblem. Damit komme ich zu meinem letzten Punkt. Bücher und Beispiele sind gut und schön, aber nichts kann das Erfolgserlebnis ersetzen, das man hat, wenn man eintatsächlichProblem, mit dem sie konfrontiert sind. Geben Sie ihnen ein Ziel, z. B. sollten auf allen neuen Servern für Mandant x bestimmte ESXi-Module installiert sein, und arbeiten Sie dann mit ihnen zusammen, um dieses Ziel zu erreichen. Passen Sie dann das Skript an, damit es in einer Umgebung mit mehreren Mandanten funktioniert.
Wie verbessert ein Systemadministrator seine Shell-Skripte?
Vonbrauchenzu, wie oben beschrieben.
Gibt es noch einen Platz für Ingenieure, die im DevOps-Paradigma nicht mithalten können/wollen?
Sicher, es gibt viele Organisationen, die nicht auf die DevOps-Methodik umsteigen können oder wollen. Sie scheinen immer mehrlangweiligOptionen, aber es sind dennoch Optionen.
Müssen wir einfach davon ausgehen, dass bei der Weiterentwicklung dieser Technologien einige Menschen abgehängt werden?
Wie bei jeder neuen Technologie: ja.
tl;dr Sie werden nie jemanden dazu bringen, wirklich in das Lernen zu investieren, bis er den Wert darin erkennt. Wenn sie ihre täglichen Aufgaben manuell erledigen können, sind Sie überbesetzt und es gibt keinen Anreiz.
Antwort2
• Wie verbessert ein Systemadministrator seine Shell-Skripte?
Übung, gemischt mit Antrieb. Es klingt abgedroschen, aber man musswollenum besser zu werden, zusätzlich zur Übung. Wenn Ihnen das Skripten nicht wirklich Spaß macht, kann es sein, dass Sie gezwungen sind, es jahrelang zu tun, wenn Sie müssen, und nie wirklich gut darin werden. Wenn Sie nichtwollenUm besser zu werden, könnten Sie jeden Tag bei der Arbeit neben dem besten Skriptautor der Welt sitzen und würden nicht einmal einen Bruchteil der Fähigkeiten erwerben, die Sie besitzen könnten.
Ich kenne Leute, die sich trotz ihrer Arbeit in der IT hartnäckig weigern, Scripting zu lernen. Für diese Leute wird es in dieser Branche bald keinen Platz mehr geben. Sie gehören einer aussterbenden Generation an.
(Ich rede nicht von alten Leuten, ich meine das im übertragenen Sinn. :P)
• Gibt es noch einen Platz für Ingenieure, die im DevOps-Paradigma nicht mithalten können/wollen?
Nein. Alles, was sie tun, kann und wird irgendwann automatisiert werden.
Ich würde behaupten, dass wir sie vielleicht sowieso nie „Ingenieure“ hätten nennen sollen. Es ist schlimm genug, dass die IT-Industrie das Wort „Ingenieur“ für sich selbst angeeignet hat, was meiner Meinung nach eine Beleidigung für dietatsächlichIngenieure, die jahrelang an Hochschulen studiert und juristische Zertifikate erworben haben, damit sie Brücken, Wolkenkratzer, Hadronenbeschleuniger usw. entwerfen können... das sind dierealIngenieure.
Aber es gibt eine Ähnlichkeit... Wenn Sie sich in der IT-Branche als „Ingenieur“ bezeichnen wollen, dann bedeutet das zumindest, dass SieerstellenDinge. Du bisterfinderischund Sie verbinden die Punkte auf neue Weise, an die noch niemand zuvor gedacht hat. Sie bauen Dinge, von denen niemand wusste, wie wertvoll sie sein würden, bis Sie sie gemacht haben.
Wenn Sie weder programmieren noch Skripte schreiben, können Sie mit Computern nicht viel anfangen, außer sie zu warten und vielleicht ein oder zwei Softwarepakete zu installieren. Vielleicht können Sie eine neue Festplatte in das alte MSA einbauen. Und in diesem Fall würde ich Sie natürlich als Administrator bezeichnen, aber nicht unbedingt als Ingenieur. Und ich würde sagen, dass ein Großteil Ihrer Arbeit in Gefahr ist, durch Automatisierung wegfallen zu können.
• Müssen wir einfach davon ausgehen, dass bei der Weiterentwicklung dieser Technologien einige Menschen zurückgelassen werden?
Der Markt wird sich anpassen. Es kann sein, dass manche Leute keine sechsstelligen Gehälter mehr verdienen, obwohl sie diese eigentlich nicht verdienen, was in dieser Branche ziemlich häufig vorkommt.
Ich finde, dass Kreativität und nicht nur Programmier-/Skriptkenntnisse ein Schlüsselfaktor sind. Es ist diese Kreativität, die Sie sich selbst sagen müssen: „Oh, hey, ich könnte das automatisieren!" und dann kommt die Fähigkeit erst danach ins Spiel. Wenn Sie feststellen, dass Sie etwas skriptennurnachdem Ihr Chef es Ihnen gesagt hat, dann verfügen Sie möglicherweise nicht über den Antrieb oder die Kreativität, von der ich gesprochen habe ... und das sind zwei Eigenschaften, die sehr schwer, wenn nicht sogar unmöglich zu vermitteln sind.
Antwort3
Wie verbessert ein Systemadministrator seine Shell-Skripte?
Wie wird man in irgendetwas besser? Lesen Sie Bücher, besuchen Sie Kurse und wenden Sie dann die erlernten Prinzipien an. (Oder eine Kombination der Methoden.) Dies ist absichtlich stark vereinfacht, da es nichts Besonderes ist, Skripting zu lernen, anstatt zu lernen, wie man kocht oder ein Auto repariert.
Gibt es noch einen Platz für Ingenieure, die im DevOps-Paradigma nicht mithalten können/wollen?
Dies ist im Rahmen dieser Site (auf der klare/definierte Antworten auf gestellte Fragen erforderlich sind) schwer zu beantworten. Wir können voraussagen, dass dies der Fall sein wird, aber das DevOps-Modell hat seine Probleme. Ich habe das Gefühl, dass es sehr schwierig ist, wenn eine Person in beiden Disziplinen über hervorragende Kenntnisse verfügt. Die Kosteneinsparungen durch einen 2-für-1-Mitarbeiter sind für Unternehmen derzeit sehr attraktiv, aber es ist schwer zu sagen, ob dieser Trend von Dauer ist. Kurzfristig ist er es jedenfalls.
Müssen wir einfach davon ausgehen, dass bei der Weiterentwicklung dieser Technologien einige Menschen abgehängt werden?
So wie sich die Dinge derzeit entwickeln, ja. Die meisten von Ihnen beobachten dies wahrscheinlich an Ihrem eigenen Arbeitsplatz. Sie sollten auf jeden Fall die Stellenangebote im Auge behalten und wissen, was der Markt derzeit verlangt. (Es gibt in Ihrer Gegend viele Stellenangebote für Hadoop? Lernen Sie Hadoop kennen.) Wenn Sie nicht mit dem Markt Schritt halten, laufen Sie Gefahr, abgehängt zu werden.
Antwort4
Gibt es noch einen Platz für Ingenieure, die im DevOps-Paradigma nicht mithalten können/wollen?
„DevOps“ ist nur ein neues Wort für etwas, was Systemadministratoren seit Jahrzehnten tun.
Müssen wir einfach davon ausgehen, dass bei der Weiterentwicklung dieser Technologien einige Menschen abgehängt werden?
Ganz im Gegenteil. Mit der Zeit wird der Bedarf an technischen Fachkräften immer größer. Jeder mit technischen Kenntnissen und Fähigkeiten wird einen Arbeitsplatz haben.