Dans mon organisation, je travaille avec un groupe d'employés du CNO, des ingénieurs débutants en herbe et une poignée d'ingénieurs seniors; tous avec un accent sur Linux. Une étape intéressante dans la façon dont l'entreprise développe ses talents est qu'il existe un chemin du CNO vers les rangs supérieurs de l'ingénierie. En considérant le bassin de talents comme un nouveau venu relatif, je constate qu'il y a une division des compétences qui tend à augmenter avec le temps ...
- Il y a des ingénieurs qui connaissent bien une ou plusieurs technologies particulières et sont constamment immergés ... par exemple MySQL, pare-feu, stockage SAN, équilibreurs de charge ...
- Il y en a d'autres qui sont généralistes et peuvent naviguer dans plusieurs technologies.
- Tous apprennent suffisamment Linux (commandes, processus) pour faire ce dont ils ont besoin et utiliser au quotidien.
Un facteur de différenciation entre certains membres du personnel est la façon dont ils adoptent les méthodologies de script, d'automatisation et de gestion de la configuration. Par exemple, nous avons deux ingénieurs qui effectuent la majeure partie du travail d'Amazon AWS CloudFormation , et un autre qui gère la plupart de l' infrastructure Puppet . Peut-être qu'un quart des ingénieurs sont adeptes des scripts shell BASH.
En regardant cela dans le contexte de la demande incroyablement élevée de compétences DevOps sur le marché du travail , je suis curieux de voir comment d'autres organisations favorisent le développement de ces compétences et développent leur talent interne. Les scripts ne semblent pas être un concept particulièrement enseignable.
- Comment un administrateur système améliore-t-il ses scripts shell?
- Y a-t-il encore une place pour les ingénieurs qui ne suivent pas / ne peuvent pas suivre le paradigme DevOps?
- Doit-on simplement supposer que certaines personnes seront laissées pour compte à mesure que ces technologies évolueront? Est-ce OK?
Réponses:
J'ai l'avantage de comprendre la taille et la complexité de votre environnement. Étant donné que vous travaillez pour un fournisseur de cloud / d'hébergement, il est sûr de supposer que vous avez un grand nombre d'environnements de petite à moyenne taille (10 à 100 serveurs). Il y a certainement des tâches quotidiennes qui sont effectuées par le jr. les ingénieurs et le personnel du CNO qui sont répétitifs (création de comptes utilisateurs, configuration d'agents de sauvegarde, etc.). De même, il y a probablement des choses manuelles qui sont faites par le sr. les ingénieurs aiment installer ESXi sur un nouveau matériel ou configurer des choses comme MPIO ou installer des modules VMware pour des ensembles spécifiques de matériel. Toutes ces choses peuvent et doivent être automatisées.
Si votre personnel est capable d'exécuter la majeure partie de sa charge de travail sans automatiser, vous êtes à mon avis sureffectif. Tout personnel informatique capable de travailler une journée entière composée principalement de processus manuels n'a aucune motivation à automatiser. Pourquoi apprendre une nouvelle compétence qui n'est pas considérée comme nécessaire et qui pourrait même faire peur ? Après tout, la nécessité est la mère de l'innovation.
Donc, à un moment donné de votre organisation, vous atteindrez une taille où vous pataugerez et vous vous effondrerez, ou vous commencerez à automatiser presque tout et à exceller. Certes, les ingénieurs seniors devraient diriger la charge ici, et peut-être même travailler avec les ingénieurs juniors et le personnel du CNO pour automatiser une partie de leur charge de travail. Cela donne le jr. les ingénieurs ont la possibilité d'avoir le cadre de nombreux scripts pour travailler avec, qu'ils peuvent modifier pour chaque locataire et nouvelle révision du matériel si nécessaire. Cela supprime la pensée intimidante de "Oh mon dieu, où dois-je même commencer?" de l'équation et leur donne un point de départ pour résoudre un problème réel . Ce qui m'amène à mon dernier point. Les livres et les exemples vont bien, mais il y aproblème auquel ils sont confrontés. Donnez-leur un objectif, comme tous les nouveaux serveurs pour le locataire x, certains modules ESXi doivent être installés, puis travaillez avec eux pour l'accomplir. Adaptez ensuite le script pour qu'il fonctionne dans un environnement mutualisé.
En ayant besoin , comme décrit ci-dessus.
Bien sûr, il existe de nombreuses organisations qui ne peuvent pas ou ne veulent pas passer à la méthodologie DevOps. Ils semblent être des options de plus en plus ennuyeuses , mais ce sont néanmoins des options.
Comme pour toute nouvelle technologie - oui.
tl; dr Vous n'aurez jamais personne vraiment investi dans son apprentissage tant qu'il ne verra pas sa valeur. S'ils peuvent accomplir leurs tâches quotidiennes manuellement, alors vous êtes en sureffectif et il n'y a aucune incitation.
la source
you'll start automating almost everything *in* excel.Pratique, mélangé avec lecteur. Cela semble banal, mais vous devez vouloir vous améliorer, en plus de vous entraîner. Si vous n'aimez pas vraiment l'écriture de scripts, vous pouvez être forcé de le faire pendant des années quand vous le devez et jamais vraiment bien. Si vous ne voulez pas vous améliorer, vous pouvez vous asseoir à côté du meilleur scripteur du monde chaque jour au travail et ne pas acquérir une fraction des compétences que vous pourriez avoir.
Je connais ces gens qui, malgré leur travail dans l'informatique, refusent obstinément d'apprendre toute sorte de script. Il n'y aura bientôt plus de place pour ces gens dans cette industrie. Ils font partie d'une génération mourante.
( Je ne parle pas des personnes âgées, je veux dire au figuré.: P )
Nan. Tout ce qu'ils font peut être et sera éventuellement automatisé.
Je dirais que nous n'aurions peut-être jamais dû les appeler «ingénieurs» de toute façon. Il est assez mauvais que l'industrie informatique approprié le mot « ingénieur » pour nous - mêmes, qui à mon avis est un peu insultant pour les véritables ingénieurs qui ont passé des années dans les programmes d'enseignement supérieur et obtenir des certifications juridiques afin qu'ils puissent concevoir des ponts, des gratte - ciel, hadronique , etc ... ce sont les vrais ingénieurs.
Mais il y a une similitude ... Si vous voulez vous appeler un «ingénieur» dans l'industrie informatique, cela signifie au moins que vous créez des choses. Vous êtes inventif et vous connectez les points d'une manière nouvelle à laquelle personne n'a jamais pensé auparavant. Vous construisez des choses que personne d'autre ne savait à quel point ce serait précieux jusqu'à ce que vous le fassiez.
Si vous ne codez pas ou ne scriptez pas, vous ne pouvez pas faire grand-chose avec les ordinateurs en plus de simplement les entretenir et peut-être installer un ou deux logiciels. Peut-être jeter un nouveau disque dur dans le vieux MSA. Et dans ce cas, je vous appellerais un administrateur, bien sûr, mais pas nécessairement un ingénieur. Et je dirais qu'une grande partie de votre travail risque d'être automatisée.
Le marché s'adaptera. Il se peut que certaines personnes ne fassent pas un salaire à 6 chiffres alors qu'elles ne le méritent pas, ce qui arrive assez souvent dans cette industrie.
Je trouve que la créativité, et pas seulement les compétences de codage / script, est un facteur clé. C'est cette créativité que vous devez vous dire: " Oh, hé, je pourrais automatiser cela! " Et la compétence n'entre en jeu qu'après cela. Si vous vous retrouvez à écrire quelque chose seulement après que votre patron vous l'ait demandé, alors vous pourriez ne pas avoir cette motivation ou cette créativité dont je parlais ... et ce sont deux qualités qui sont très difficiles, voire impossibles, à enseigner.
la source
Comment peut-on s'améliorer dans quelque chose? Lisez des livres, assistez à des cours, puis appliquez les principes appris. (Ou une combinaison des méthodes.) C'est intentionnellement simplifié car il n'y a rien de spécial dans l'apprentissage des scripts par rapport à l'apprentissage de la cuisine ou de la réparation d'une voiture.
Il est difficile de répondre dans le cadre de ce site (où il est nécessaire de fournir des réponses claires / définies aux questions posées.) Nous pouvons prédire que ce sera le cas, mais il y a des problèmes avec le modèle DevOps. Je pense qu'il est très difficile pour une personne d'être extrêmement compétente dans les deux disciplines. Les économies de coûts d'un employé 2 pour 1 sont très intéressantes pour les entreprises en ce moment, mais il est difficile de dire si cette tendance est là pour durer. C'est certainement pour le court terme.
Au rythme actuel de la façon dont les choses se passent, oui. La plupart d'entre vous l'observent probablement dans vos propres lieux de travail. Vous devriez certainement suivre les offres d'emploi et savoir ce que le marché exige actuellement. (Il y a beaucoup d'offres d'emploi pour Hadoop dans votre région? Apprenez Hadoop.) Si vous ne suivez pas le marché, vous risquez d'être laissé pour compte.
la source
On n'envoie généralement pas d'ingénieurs débutants dans un environnement de production complexe qui est essentiel à la mission. Vous avez des ingénieurs seniors pour cela. Les rangs juniors devraient être autorisés à travailler dans des bacs à sable de développement / test.
Si vous avez besoin d'un ingénieur pour la technologie X et que vous souhaitez remplir le rôle en interne, trouvez quelqu'un prêt à l'apprendre, trouvez une formation structurée et combinez les deux.
Déterminez les compétences dont vous avez besoin dans un département. Trouvez quelqu'un prêt à les apprendre. Enseigner / distribuer de l'argent pour la formation.
la source
"devops" n'est qu'un nouveau mot pour quelque chose que les administrateurs système font depuis des décennies.
Plutôt l'inverse. Au fil du temps, le besoin de techniciens est de plus en plus grand. Toute personne possédant toutes sortes de connaissances en ingénierie et de compétences techniques aura un endroit pour travailler.
la source