Sondage Quelle formation pertinente pour un sysadmin ?

Posté par  . Licence CC By‑SA.
Étiquettes :
3
7
fév.
2020

Bonjour,
Ce sondage s’adresse aux administrateurs système orientés GNU/Linux, Open Source, etc.
Dans le milieu professionnel, laquelle de ces formations trouvez-vous la plus pertinente pour vous ?
Merci pour vos réponses !
Mat

  • RHEL 8 :
    118
    (11.6 %)
  • LPI :
    76
    (7.4 %)
  • Red Hat Satellite :
    5
    (0.5 %)
  • Puppet :
    33
    (3.2 %)
  • Ansible :
    219
    (21.4 %)
  • Docker :
    94
    (9.2 %)
  • Kubernetes :
    138
    (13.5 %)
  • AWS :
    38
    (3.7 %)
  • Google Cloud Platform :
    15
    (1.5 %)
  • Je ne suis pas adminsys, je ne suis pas dans le milieu pro, ça ne m’intéresse pas, qui êtes-vous d’ailleurs ? :
    285
    (27.9 %)

Total : 1021 votes

La liste des options proposées est volontairement limitée : tout l’intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix. Les réponses multiples sont interdites pour les mêmes raisons. Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées ou de l’impossibilité de choisir plusieurs réponses. 76,78 % des personnes sondées estiment que ces sondages sont ineptes.

  • # Il manque :

    Posté par  (Mastodon) . Évalué à 10.

  • # Un peu vague la question

    Posté par  (Mastodon) . Évalué à 9.

    Tout dépend de l'environnement dans lequel tu travail et sur quel sujets. Ça ne sert à rien de faire une formation RHEL ou RH satellite si tu bosses dans un environnement debianesque. Peut-être pas besoin de passer une formation ansible ou puppet si ta boite ne déploie que sur Amazon et que tes collègues ont déjà investi du temps dans cloudformation.

    Etc. Etc.

    Par ailleurs tout ces projets sont relativement bien documentés donc une formation, mais pourquoi faire ? Moi je passe en général une formation si :
    - la qualité de la doc de l'éditeur en question est pourrave
    - j'ai des nouvelles fonctions qui m'imposent de prendre en main très rapidement un outil, donc passer 3 à 5 jours en formation va accélérer le processus et palier à mon manque d'expérience.

    Bref, si tu ne sais pas ce que tu vas en faire, ça ne sert à rien de faire une formation juste pour faire une formation à mon humble avis.

    • [^] # Re: Un peu vague la question

      Posté par  . Évalué à 1.

      Ce sondage montre aussi quelle sont les technologies les plus utilisées. Red Hat Satellite semble très peu utilisé, alors qu'Ansible l'est davantage.

      • [^] # Re: Un peu vague la question

        Posté par  . Évalué à 1. Dernière modification le 08 février 2020 à 13:30.

        Il faut voir que Redhat Satellite, en dessous, c'est du puppet ou de l'ansible pour la gestion des configurations et applications.

        Après, il y a aussi d'autres trucs dedans (il me semble qu'il y a du kubernetes aussi).

        C'est pas vraiment un outil à part entière mais plutôt un portail de gestion de plusieurs outils.

      • [^] # Re: Un peu vague la question

        Posté par  (Mastodon) . Évalué à 2.

        C'est surtout que ansible a un spectre d'utilisation bien plus large que redhat satellite.

    • [^] # Re: Un peu vague la question

      Posté par  . Évalué à 2. Dernière modification le 21 février 2020 à 14:31.

      Par ailleurs tout ces projets sont relativement bien documentés donc une formation, mais pourquoi faire ?

      Pour avoir le temps de t'investir sur le sujet en question ?

      Dans certains endroits, la sursollicitation est tele qu'il est diffiocile de se prendre du temps pour s'autoformer à un sujet.

      Après si par "formation" on pense à un cours online que tu dois suivre en plus du travail que tu as à faire, je t'accorde que ça n'a que peu d'intéret.

  • # ça dépend

    Posté par  (site web personnel) . Évalué à 9.

    Perso : ansible, terraform, centos 7 (la 8 n'a pas l'air près d'arriver), ubuntu 18, kubernetes, prometheus, mongodb, ELK, grafana, kafka, rabbitmq, docker, etc. Ça reste assez dépendant de l'infra et du projet. Au final j'attache plus d'importance à pourquoi on fait les choses (pourquoi de la répartition de charge, du code pour l'infra, de l'idempotence, etc.) qu'à comment/quel outil en particulier (ce qui change toutes les x années).

    • [^] # Re: ça dépend

      Posté par  . Évalué à 2.

      La centos 8 est sortie. Tu veux peut-être dire arrivée en entreprise…

      • [^] # Re: ça dépend

        Posté par  . Évalué à 1.

        Quand je me suis posé la question de passer à la v8 en septembre dernier, j'ai regardé quels étaient les problèmes connus pour la MàJ. Le fait qu'il manquait des paquets EPEL ça ma refroidi.

        Et je n'ai pas tout compris comment les "Application Streams" de RedHat allaient permettre d'obtenir une version drécente de Git dans CentOS 8 puisque IUS ne supportera pas cette version.

  • # Et SuSE SLES 15, et Cobbler, et...

    Posté par  (site web personnel) . Évalué à 2.

    Sondage intéressant qui montre pour moi que le métier d'adminsys est compliqué à définir car très dépendant de l'époque, des tendances, du milieu où on l'exerce, des choix et stratégies suivis, etc.
    Comment comparer un adminsys dans un groupe international avec beaucoup de Legacy (traduction : des applis qui marchent encore, mais sur des os / du matos / des technos obsolètes), des centres informatiques privés et une grande atomisation des métiers (os, produits, réseau, stockage, matériel, etc.) avec un adminsys de PME ou d'association qui fera tout ça à la fois et aura le choix entre un rack dans un cagibi et le cloud ?

    Par contre, je veux bien reconnaître la puissance et la pertinence de Red Hat dans l'open source, mais je préférerais qu'on oublie pas SuSE ou les versions commerciales d'Ubuntu ou d'autres distrib dans le paysage. Sinon, à quoi bon râler depuis des années contre l'hégémonie de Microsoft si c'est pour en faire naître une autre dans les os open source ?

  • # Certification BSD

    Posté par  (site web personnel, Mastodon) . Évalué à 4.

    Pour ceux qui recherchent une certification, ne pas oublier la certification BSD. Même pour ceux qui travaillent peu avec du BSD, cette certification (et sa préparation) donne à mon avis une bonne ouverture sur l’ensemble des systèmes UNIX.

  • # Ansible

    Posté par  . Évalué à 2.

    Je dis ansible mais en fait la réalité c'est que le sysadmin d'aujourd'hui se doit de savoir gérer un outil de gestion de configuration.
    Ansible ou un autre, ça importe assez peu. mais il faut vraiment apprendre à gérer un serveur sans avoir à se connecter dessus.
    Un sysadmin qui maitrise Ansible (ou un autre) et un bon langage de scripting (python? ) a tout ce qu'il faut pour gérer une infra moderne, reproductible, et versionnable.

    En priorité 2, je partirais sur les couches infra, via terraform et les technos de containerisation.

  • # Bases

    Posté par  . Évalué à 1.

    J'avoue que je ne comprends pas la spécialisation sur un de ces outils/une de ces plateformes.
    En effet, ça occulte les bases nécessaires pour reprendre du legacy, chose à laquelle on est confrontés dans le quotidien.
    Même, au pire, si on se forme sur un outil tel qu'Ansible, mais qu'on ne sait pas débugger, ni on ne comprend le système "managé" au bout, on se retrouve coincé.
    C'est ce dont on se rend compte sur les projets où arrivent des profils fraîchement formés sur la "secu", ou profil "devops", alors qu'ils ne savent pas gérer les logs, les contextes de sécurités, les règles firewall, la gestion des paquets, etc.

  • # Pas d'Open Source chez nous

    Posté par  . Évalué à 1.

    Malheureusement pas d'Open Source chez nous (excepté GLPI). C'est pas faute d'en parler souvent mais certains DSI sont toujours craintif avec l'Open Source.

  • # Et GIT ?

    Posté par  . Évalué à 2.

    Dans un monde ou on s'oriente vers de l'infrastructure as code, et ou tant les devs que les admins ont besoin de stocker des fichiers versionnés, ça ne me parraît pas être un luxe : tous les admins ne connaissent pas GIT.

    Je verrais aussi des outils de CI/CD tels que Jenkins par exemple. Mais il est important que le formation soit plus une formation d'utilisation d'outil CI/CD et que Jenkins (ou l'outil) soit un moyen de voir les principes, plutôt que de se concentrer sur des "recettes" pour faire tel ou tel truc avec Jenkins.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.