Get best of the week

Profession DevOps-engineer: une vue de l'administrateur système



Je travaille en tant qu'ingénieur DevOps chez Parallels. J'accompagne le développement de différents services, j'écris des scripts pour leur déploiement automatique, je communique étroitement avec l'équipe de développement. Je vais vous dire comment le travail est organisé, combien ils paient et à quoi sert l'approche DevOps pour le développement de logiciels.

Tout a commencé avec le fait que c'était devenu ennuyeux pour moi de travailler en tant qu'administrateur système, je voulais quelque chose de nouveau. J'ai essayé de développer 1C, mais j'ai rapidement réalisé que ce n'était pas le mien. Il a appris Python, amélioré ses compétences sur les systèmes Unix et s'est rendu pour une interview chez Parallels. Ensuite, je ne savais presque rien de DevOps, je suis juste venu et j'ai dit: je veux travailler pour vous. Deux mois plus tard, ils m'ont emmené.

Qu'est-ce que DevOps?


Si vous demandez à 5 personnes ce qu'est DevOps, vous obtenez 5 réponses différentes. Pour les évangélistes, c'est une culture, ou même plutôt une transformation de la pensée. Pour les ingénieurs, un ensemble de solutions et d'outils. Pour les managers, une méthodologie. Pour les recruteurs - une profession. Et pour tout le monde, ce n'est probablement qu'un mot à la mode.

La vérité, comme d'habitude, se situe quelque part entre les deux. DevOps est tout ce qui précède, pris ensemble. Sa tâche principale est d'accélérer la livraison du produit de l'entreprise au consommateur. Le terme lui-même a été inventé par le consultant informatique indépendant Patrick Debois il y a environ douze ans. Il voulait briser le mur métaphorique entre les développeurs (dev) et les administrateurs système (ops), les combiner en une seule unité efficace, qui peut créer des logiciels plus rapidement, déployer les versions plus souvent et avec moins d'erreurs.

Par conséquent, au cœur de DevOps est l'idée de responsabilité partagée, il n'y a pas de division des pouvoirs. Le programmeur peut participer à la configuration s'il sait mieux écrire la configuration de son service, et l'administrateur système en développement. Lorsqu'un problème survient, il n'est pas transféré d'un employé à un autre, comme une balle de ping-pong, mais devient courant. Tout le monde est impliqué dans son élimination.



Une minute de statistiques ennuyeuses. Selon la recherche DORA (DevOps Research and Assessment), les équipes interfonctionnelles utilisant l'approche DevOps:

  • 208 fois plus souvent déployer du code;
  • 106 fois réduire le temps entre la validation et le déploiement;
  • Des systèmes de restauration 2.604 fois plus rapides après les pannes;
  • 7 fois plus faible le risque d'échec en raison de changements.

Bien sûr, la combinaison de dev et d'ops à elle seule ne conduit pas à une telle efficacité. L'approche DevOps comprend l'utilisation de nombreux nouveaux outils de développement, de test et de déploiement pour organiser CI \ CD (le concept d'intégration et de livraison continues). Parmi les plus connus:

  • Git et GitHub - systèmes de gestion de code source;
  • Jenkins - un serveur d'automatisation pour la création de pipelines CI / CD;
  • Docker - logiciel pour automatiser le déploiement et la gestion des applications dans des environnements avec prise en charge de la conteneurisation;
  • Kubernetes - un système d'orchestration de conteneurs ouvert;
  • Chef, Puppet et Ansible - outils de configuration et de déploiement automatiques;
  • Sélénium - solution d'automatisation des tests;
  • Prometheus et Nagios - logiciel de surveillance de serveur;
  • Grafana est une solution de collecte et d'analyse de métriques.

Dans le même temps, il n'existe pas un ensemble universel d'outils adaptés à chaque entreprise, et il n'existe pas de chemin unique vers DevOps. Il n'y a que ce qui fonctionne ou, inversement, ne fonctionne pas dans votre infrastructure. J'assiste régulièrement à des conférences et à divers événements, communique avec des collègues d'autres entreprises et je peux dire que 80% des choses qu'ils utilisent dans Parallels ne sont pas particulièrement applicables.

Chaque organisation a son propre produit, sa propre pile technologique et ses goulots d'étranglement. Par conséquent, l'approche de l'optimisation est très différente. Parfois, vous devez changer l'architecture des services eux-mêmes, certains sont si complexes ou inflexibles qu'il est difficile de leur transférer l'approche DevOps.

L'essence de l'ingénieur DevOps


À un niveau de base, un ingénieur DevOps est un spécialiste technique qui comprend toutes les principales étapes du cycle de vie du développement logiciel, corrige les goulots d'étranglement dans les processus et ajuste l'environnement:

  • Écrit du code pour le déploiement automatisé d'applications
  • partiellement responsable de leur disponibilité, non pas personnellement en tant qu'administrateur système, mais avec son équipe;
  • porte un devoir sur son infrastructure (comprend les erreurs, parfois avec un programmeur).

L'automatisation est ce qui incombe en premier lieu à un ingénieur DevOps. La création d'un produit informatique avec l'approche traditionnelle est la suivante: le programmeur écrit son code, le compile dans un certain format et le donne au sysadmin. Il va sur le serveur, installe et configure tout avec ses mains. En même temps, ils se battent pour différentes choses: l'administrateur système - pour la stabilité, le programmeur - pour leurs changements, ce qui, bien sûr, complique le travail de chacun d'eux.

Dans DevOps, cela fonctionne un peu différemment. L'application est déployée à l'aide de scripts. L'ingénieur DevOps définit une certaine séquence d'actions qui amène le code écrit par le programmeur, d'abord au serveur de test, puis au serveur de combat (s'il est décidé que les modifications peuvent être publiées). Ainsi, le développeur a la possibilité de vérifier son code au moins toutes les 15 minutes et de le faire même à trois heures du matin d'un simple clic sur un bouton.

Les responsabilités spécifiques, ainsi que les compétences nécessaires, dépendent fortement du lieu de travail. Chez Parallels, nous avons une grande partie de notre infrastructure, les parties les plus critiques ne sont pas dans les clouds publics, mais sur nos propres serveurs physiques dans plusieurs centres de données. Et parfois, il y a des mises à jour majeures concernant le matériel et les logiciels sur ces serveurs, et une migration est requise périodiquement.

C'est aussi mon travail.


J'essaie d'automatiser tout au maximum pour que le processus soit moins pénible. La dernière fois, dans le cadre de tests de sauvegardes croisées et de tolérance aux pannes d'infrastructure, il a été possible de transférer des services des États-Unis vers la Suisse en 10 minutes et de mettre à jour tout ce qui était nécessaire en cours de route. Pour la technologie moderne, ce n'est bien sûr pas une énorme réussite. Mais pour nous - un grand pas en avant.

L'héritage est également un défi certain pour les ingénieurs DevOps. Même dans les entreprises avec des workflows bien construits, il existe des services qui ont été écrits depuis très longtemps, et personne ne se souvient pleinement de la façon dont ils ont été configurés, car il était souvent fait manuellement, et les personnes qui y travaillaient ne travaillaient plus dans l'organisation. S'il s'agit d'un service important, de nombreuses recherches sont entreprises - vous devez le comprendre dans la moindre nuance comment il fonctionne, écrire du code pour le déploiement, le couvrir de surveillance et de métriques.

Cela vaut la peine de le faire, même si le code d'application ne change pas très activement. Pourquoi, si tout fonctionne comme ça? Afin de pouvoir le reproduire en cas de panne, installez des mises à jour de sécurité, trouvez et corrigez des problèmes que personne ne connaît peut-être. Récemment, je viens d'écrire des scripts pour un tel service avec une longue histoire. Des changements dans son code étaient nécessaires, le travail n'est pas encore terminé, mais les progrès sont importants. Il est très intéressant de recueillir une image complète de l'application à partir de pièces disparates, il est agréable de regarder le résultat plus tard.

Et, bien sûr, la mise en œuvre de l'approche DevOps est étroitement liée à la mesure. Dans quelle mesure le temps de réponse a-t-il changé? À quelle fréquence les erreurs voulues se produisent-elles? Avant, un administrateur système ne savait souvent pas comment mesurer ces choses. Les applications étaient des boîtes noires, seules les caractéristiques les plus élémentaires restaient: la charge du processeur, la consommation de mémoire, le trafic. Et lorsque la nouvelle version a été déployée, ni l'administrateur système ni le programmeur n'ont pu déterminer rapidement que tout ne se passait pas exactement comme prévu. Il restait à attendre les appels en colère du support technique.

Avec l'approche DevOps, c'est du passé. Vous pouvez configurer la collection de métriques d'application réelles, les comparer à la consommation de ressources, et pour cette raison, il est préférable et plus rapide de trouver des problèmes, d'optimiser, d'améliorer la qualité des produits et pas seulement la disponibilité du serveur.

Combien gagnent les ingénieurs DevOps?


Le salaire d'un ingénieur DevOps dépend des compétences, du lieu de travail et de la région de résidence. Le salaire d'un spécialiste travaillant à Moscou est le plus élevé de Russie, 130-350 mille roubles par mois. Les entreprises de Saint-Pétersbourg offrent 100 à 300 000 roubles dans cette position. Dans d'autres régions de notre pays, ils sont prêts à payer 70 à 120 000 roubles.

Le revenu annuel moyen aux États-Unis, comme le disent certains RH, varie de 100 à 125 000 dollars américains, selon les données publiées par Puppet. En Australie et en Nouvelle-Zélande - 75-100 mille dollars américains. En Europe - 50-75 mille dollars américains. En Asie, les ingénieurs DevOps ne reçoivent pas plus de 25 000 dollars américains par an.

More articles:


All Articles