Bloc d'activités : Exploitation de la solution (infrastructure systèmes et réseaux)

Exploiter l'infrastructure et ou système d'information de l'entreprise

Entreprise : Ministère de la Défense

Client : idem

Projet : Administration de l'infrastructure de l'antenne de Versailles Satory (DCMAT)

Dates/Durée : 2009 – 2011 / 2 ans

Réalisation : Administration de l'infrastructure système de l'antenne de Versailles/Satory

Second : RFC Consulting ASP (Application Service Provider), CEDICAT MinDef, Darfeuilles Associés...

Source documentaire :

La réalisation majeure

Définition du projet ou de la réalisation

C'est en tant que TSEF (Tech. Sup. d'Etude et de Fab.) que j'ai intégré la section administration système de l'antenne SIC de Versailles-Satory (78) du CIRISI (Centre Interarmées des Réseaux d'Infrastructure et des Systèmes d'Information) rattachée au camps des Loges anciennement.

Cette section était auparavant dépendante de la DCMAT (Direction Central du Matériel de l'Armée de Terre).

Cette entité, dirigée par Thierry Aubert (IEF : Ingénieur d’Étude et de Fab., chef de l'antenne CIRISI) était chargée d’assurer l'exploitation du système d’information.

Objectifs, contexte, enjeu, risques, opportunités

Notre équipe de 5 personnes était chargée de soutenir les serveurs informatiques des différents organismes de Versailles-Satory.

Cela représentait un volume de plus de 120 serveurs (Windows 2000, 2003, Centos, RedHat) tous répartis sur 3 bâtiments distants, et reliés par des fibres optique.

De la rigueur et qualité de notre travail dépendait le quotidien de plus de 4000 utilisateurs quand à la disponibilité d'applications bureautiques mais surtout métiers.

En effet ces dernières pouvant bloquer la mise en oeuvre de systèmes d'armement (Ex. SIMAT Système d'Information de la Maintenance de l'Armée de Terre) en cas indisponibilité.

Par exemple nous avions aussi en charge les serveurs et réseaux de l'école Militaire de Saint-Cyr avec une problématique scolaire comme par exemple l'exploitation de la plate-forme PRO-NOTES (Windows 2000 serveur).

Étapes

L'administration système (et réseau) d'une infrastructure complète sous Windows 2003 Active Directory et GNU/Linux implique l’exécution d'un certain nombre de gestes et tâches exécutés quotidiennement avec rigueur et assiduité.

Voici un exemple de tâches que je devais réaliser :

  • Prise de service à 08H00,

  • Vérification auprès de mon collègue (Alban ?) du bon déroulement des sauvegardes, journalières (test de restauration mensuel sur un lot de données pris au hasard),

  • Gestion des utilisateurs et groupes de sécurité (création, modification, suppression, blocage ...),

  • Gestion des droits d'accès au système d’information (fichiers, applications ...) via des ACL et groupes de sécurité,

  • Gestion de la sécurité (pare-feu, réseau, serveurs, station de travail, audit...)

  • Support de niveau 3,

  • Installation de nouveaux serveurs, dispositifs réseau ou de sécurité,

  • Maintenance matériels : mise en rack serveurs (HP, DELL, FUJITSU), câblage, brassage, serveurs "blade" (HP), upgrade hardware, firmware,

  • Gestion de projets interne pour le conception de solutions (tests, validations, migrations ..),

  • Gestion d'un SAN (Storage Area Network) HP EVA 4400 fibré, avec haute disponibilité sur deux sites distants,

  • Gestion d'un cluster Microsoft (Exchange, partage de fichiers SMB, MS-SQL, IIS, MySQL),

  • Gestion de solution de virtualisation, évolution allant de Virtual server 2005 à vSphere VMWare,

  • Devops : déploiement d'applicatifs, scripting, industrialisation ...

  • Rédaction de procédures d'exploitation associées,

  • Consigner les actions : l'équipe disposait à ce titre d'un logiciel de ticket pour gérer les incidents et demandes ainsi que de documentations types,

  • Assurer une veille technologique,

  • Optimiser et améliorer en permanence notre système d'information.

Mes actions

J'ai réalisé personnellement toutes les étapes mentionnées ci-dessus avec mes collègues de la section administration système de l'antenne SIC (Systèmes d'information et Communication) de Versailles-Satory

Acteurs et interactions au sein du projet

Comme indiqué ci-dessus j'ai mené ces tâches d'administration système et réseau au sein d'une équipe de 5 personnes. Avec une répartition des tâches en fonction du niveau de compétence de chacun.

Résultats (pour moi, pour l'entreprise)

Les résultats furent ceux escomptés. En effet cette organisation du travail nous a permis de remplir les objectifs fixés par notre responsable, Thierry Aubert, en assurant une disponibilité maximale du système d'information de la DCMAT (devenue SIMMT puis externalisation des personnel SIC vers la DIRISI) et des établissements militaire de Versailles-Satory.

Lendemains du projet

L'exploitation et la production informatique implique des lendemains fait de veilles technologique et formations sur les nouveaux produits mais aussi de suivre le rythme imposé par les éditeurs de logiciels propriétaires.

Mon regard critique sur le projet ou la réalisation

Ce fut une expérience intéressante où, avec un responsable (Thierry Aubert) compétent et ayant un très bon niveau en réseau et système, j'ai pu apprendre de nouvelles méthodes et approches dans cette compétence.

La compétence : autocritique et évolution

Mon niveau de maîtrise de la compétence

J'ai un niveau expert dans la compétence.

Place, importance, priorité de cette compétence dans mon profil d'Expert en Ingénierie ou dans mon métier actuel

Actuellement cette compétence me sert surtout quand je dois faire du support niveau 3 ou venir épauler l'équipe des administrateurs systèmes sur certains projets de migration. Cette compétence me permet aussi de prendre du recul sur les projets d'architecture système qui me sont confiés car elle m'aide à anticiper les difficultés que pourront rencontrer les administrateurs systèmes lors d'une migration ou d'un changement.

Mon évolution

Avec notre passage de la DCMAT vers la DIRISI mon responsable, Thierry AUBERT, m' a permis d'accéder au poste de chef de l'équipe des administrateurs système de l'antenne de Versailles-Satory.

De plus j'ai eu la responsabilité de penser, concevoir enfin déployer le nouveau Datacenter (VMWare vSphere) de l'antenne de la DIRISI, lequel devait couvrir tous les besoins, en terme de virtualisation de serveurs et de réseaux, de l'antenne de Versailles-Satory.

Place de la compétence dans mon projet personnel

Ayant atteint un niveau expert dans cette compétence, je continue néanmoins à m'améliorer car les méthodes d'administration d'une production évoluent en permanence, on parle aussi de DevOps maintenant ...

Exploiter et faire tourner une production de serveurs physiques n'est pas exactement la même chose que de le faire sur une infrastructure complément virtualisée ... et l'est encore moins avec des infrastructures de type IaaS ,PaaS voir hyperconvergée.

Cependant les fondamentaux de l’exploitation restent, eux, inchangés  : la sauvegarde , la haute disponibilité , le service rendu.

Niveau que je souhaite atteindre dans cette compétence à moyen terme

Bien qu'étant expert dans cette compétence je découvre toujours des nouvelles technologies qui me permettent d'augmenter mon niveau.

Les technologies mise en œuvre, que ce soit au niveau :

matériel,

logiciel,

des concepts.

... se renouvellent ou/et se recyclent sans cesse : il n'y a pas de place pour la routine.

Formation ou autoformation en cours ou à venir, sur cette compétence

une veille technologique constante et active.

Je participe aussi à des forums et des bétas tests (Ex .:Proxmox Backup Server).

Réaliser des scripts d'automatisation de l'exploitation de l'infrastructure

Entreprise : iLinux

Client : idem

Projet : Solution de sauvegarde (iLinux V1)

Dates/Durée : mai 2019 / 2 semaines

Réalisation : Développement des scripts de pilotage de la solution de sauvegarde Borg Backup

Source documentaire :

https://borgbackup.readthedocs.io/en/stable/

La réalisation majeure

Définition du projet ou de la réalisation

Dans le cadre de la création de mon hébergeur iLinux, membre du collectif CHATONS, j'ai eu à mettre au point une méthode de sauvegarde des données de nos adhérents.

Objectifs, contexte, enjeu, risques, opportunités

Au sein d'une architecture hyperconvergée, exclusivement à base de logiciels libres comme brique système et réseau, j'ai eu à imaginer et mettre en place une solution de sauvegarde des données.

L’objectif était de sauvegarder l'ensemble des conteneurs de type LXC de la production d'iLinux.

L'enjeu fut de respecter les contraintes suivantes :

  • Logiciel libre et modulaire,

  • Sauvegardes incrémentielles,

  • Dé-duplication des données,

  • Compression des sauvegardes,

  • Temps de sauvegarde, donc d'indisponibilité le plus court possible,

  • Rétention des sauvegardes de 15 jours, puis 1 fois par mois enfin 1 fois par an sur 5 ans,

  • Sauvegarde sur un réseau dédié en mode "pull" pour plus de sécurité,

  • Chiffrement des sauvegardes,

  • Facilité et granularité de la restauration des données,

  • Remontée des alertes, temps et volumétries de sauvegarde,

  • Suivi de version pour le code utilisé pour la sauvegarde (partie DevOps).

Ci-contre un exemple des conteneurs LXC à sauvegarder chaque nuit.

Étapes

Pour parvenir à l'objectif du projet j'ai du :

  • Me documenter sur les solutions existantes à base de logiciel libre,

  • Effectuer des tests de faisabilité avec l'architecture d'iLinux v1 de l'outil choisi : BorgBackup,

BorgBackup est un outil de sauvegarde incrémentielle en ligne de commande écrit en Python. C'est un fork d'Attic mais un peu plus en avance puisqu'il corrige pas mal de bug d'Attic et propose des fonctionnalités supplémentaires (choix de la compression, par exemple). En outre le projet est très actif et en constante évolution. Une des particularités de BorgBackup est qu'il supporte la dé-duplication, c'est-à-dire que les fichiers sauvegardés sont découpés en une multitude de tronçons, et BorgBackup ne sauvegarde que les tronçons qui ont été modifiés depuis la dernière sauvegarde, d'où une économie substantielle en termes d'espace disque et un gain lors de transfert des sauvegardes distantes.

  • Adapter le serveur de sauvegarde principal en basculant ce dernier d'un conteneur LXC à une machine virtuelle (KVM+QEMU) afin de pouvoir monter localement un système de fichiers distants via le protocole sécurisé SSH (SshFS fuse),

  • Développer les scripts d'automatisation et d'exploitation de la sauvegarde en réutilisant du code ayant fait ses preuves en environnement de production,

  • Tester et valider la solution,

  • Monter un conteneur chargé du suivi de version du code Git : Gitea,

  • Mettre en place un serveur permettant d'externaliser la sauvegarde via le logiciel Rsync,

  • Contrôler quotidiennement le bon fonctionnement de la sauvegarde de l'infrastructure via les alertes et informations envoyées par courriel :

Mes actions

J'ai réalisé personnellement toutes les étapes mentionnées ci-dessus.

Acteurs et interactions au sein du projet

Étant le président de l'association mais aussi le seul technicien avec les compétences requises pour mener à bien ce type de projet il n‘y a pas eu d'autre acteur ni d'interaction. De plus iLinux n'avait pas d’adhérent à cette époque hormis les 2 membres fondateurs.

Résultats (pour moi, pour l'entreprise)

Les résultats furent ceux attendus. En effet cette réalisation m'a permis de remplir les objectifs fixés en début de projet.

Lendemains du projet

Cette technologie étant maîtrisée et opérationnelle, j'ai commencé à m'intéresser à une autre manière d'assurer la sauvegarde des données qui elle proposerait plus de souplesse : la sauvegarde par clichés instantanés.

Méthode que je connaissais déjà fort bien avec Microsoft Backup Server via la technologie VSS.

Le choix d'un système de stockage est primordial pour la gestion amont de la sauvegarde, de ce fait ZFS a été envisagé, mais j'ai finalement choisit CEPH : plus prometteur.

Mon regard critique sur le projet ou la réalisation

Je me suis rendu compte que, avec le temps, la volumétrie augmentait et que les temps d’indisponibilité de nos services, bien que se situant vers 02H00 du matin, commenceraient à poser de réels soucis en cas d'arrivée massive d'autre adhérents ou d'accroissement conséquent des données hébergées.

La méthode de sauvegarde n'était pas la seule responsable, le matériel utilisé pour supporter le système de fichiers distribués CEPH était aussi une des causes. Ce dernier requérant beaucoup de bande passante réseau pour tenir à jour les répliques d'objets.

La compétence : autocritique et évolution

Mon niveau de maîtrise de la compétence

J'ai un niveau expert pour cette compétence.

Place, importance, priorité de cette compétence dans mon profil d'Expert en Ingénierie ou dans mon métier actuel

Je développe toujours des scripts d'automatisation, mais j'ai poussé l'automatisation beaucoup plus loin en me formant sur Ansible, qui a d’ailleurs été totalement intégré à l’infrastructure iLinux v2, mais aussi chez mon employeur à l'OFB. Notamment lors de l'industrialisation de l’infrastructure GNU/Linux de cet établissement.

Mon évolution

Je compte maintenant me former à des outils d’automatisation permettant de monter des infrastructures complètes via du code, des scripts : Kubernetes, Terraform, Vagrant, Helm, Docker compose, Cloud Init etc.

Place de la compétence dans mon projet personnel

Cette compétence est toujours omniprésente dans mon projet personnel.

Niveau que je souhaite atteindre dans cette compétence à moyen terme

Bien qu'étant expert dans cette compétence je découvre toujours des nouvelles technologies qui me permettent d'augmenter mon niveau dans cette compétence.

Formation ou autoformation en cours ou à venir, sur cette compétence

Je parcours régulièrement des forums à la recherche de scripts, codes ... en vue d'automatiser notre exploitation.

Mettre en œuvre les technologies de sauvegarde et de haute disponibilité

Entreprise : iLinux

Client : idem

Projet : Solution de sauvegarde hautement disponible (ilinuxV2)

Dates/Durée : septembre 2020 / 5 jours

Réalisation : Déploiement de la solution de sauvegarde hautement disponible Proxmox Backup Serveur (PBS)

Source documentaire :

https://www.proxmox.com/en/proxmox-backup-server

La réalisation majeure

Définition du projet ou de la réalisation

Lors de la migration de l'infrastructure iLinux v1 vers la v2, j'ai souhaité améliorer notre système de sauvegarde afin de rendre notre infrastructure hautement disponible et plus sécurisée. Pour ce faire j'ai opté pour l'intégration du tout nouveau produit de Proxmox : Proxmox Backup Server (PBS), qui n'était qu'en phase BÊTA (0.9) lors de la conception de notre nouvelle infrastructure.

Objectifs, contexte, enjeu, risques, opportunités

Avec notre infrastructure en version 1 nous faisions les sauvegardes de nos conteneurs en arrêtant les services qu'ils hébergeaient, ce qui générait un temps d'indisponibilité certes acceptable mais qui, à terme, allait devenir pénalisant pour nos adhérents.

Le but était d'avoir des sauvegardes cohérentes et synchrones entre le système de fichiers et les bases de données entrant en jeux : ce que permettait la solution de sauvegarde initiale.

Avec la version 2 de l'infrastructure iLinux j'ai souhaité, tout en conservant les avantages de la solution précédente, me fixer les objectifs suivants  :

  • Augmentation des performances et de l'intégrité de nos sauvegardes,

  • Sécurisation renforcée de l’infrastructure de sauvegarde,

  • Supprimer complètement les interruptions de service durant nos sauvegardes : de ce fait rendre le système hautement disponible,

  • Exploitation des clichés instantanés que permettaient nos systèmes de fichiers natifs CEPH et ZFS,

  • Faciliter l'exploitation de la solution de sauvegarde via une interface WEB tout en conservant la possibilité de travailler en ligne de commande (CCLILI) ou via une API d'automatisation,

  • Intégration dans la solution de virtualisation Proxmox VE,

  • Architecture client-serveur de la solution.

Le risque majeur fut de se lancer dans la mise en production d'un produit encore en version BÊTA lors de mes tests.

Rappel : Solution de sauvegarde iLinux v1

  • Logiciel libre et modulaire,

  • Sauvegardes incrémentielles,

  • Dé-duplications des données,

  • Compressions des sauvegardes,

  • Temps de sauvegarde, donc d'indisponibilité le plus court possible,

  • Rétention des sauvegardes de 15 jours, puis 1 fois par mois enfin 1 fois par an sur 5 ans,

  • Sauvegarde sur un réseau dédié en mode "pull" pour plus de sécurité,

  • Chiffrement des sauvegardes,

  • Remontée des alertes, temps et volumétries de sauvegarde,

  • Suivi de version pour le code utilisé pour la sauvegarde.

Étapes

Pour atteindre les objectifs du projet j'ai du :

  • Faire de la veille technologique pour découvrir les solutions disponibles sur le marché,

  • Me documenter sur la solution qui m'a semblé la plus intéressante pour notre problématique : Proxmox Backup Server (PBS),

  • Monter et configurer une maquette de test de la solution PBS dans une infrastructure de test (sous VirtualBox),

  • Effectuer des tests et valider la solution,

  • Installer et configurer la la solution sur l'infrastructure de production, avec un système de fichiers local ZFS (RAIDZ - zPool4 et zPool1) :

  • Mettre en place la solution de sauvegarde externalisée sur un autre serveur distant PBS avec,lui aussis, un système de fichiers local ZFS (RAIDZ - zRAIDZ) :

  • Mettre en place les notifications et le monitoring de la solution de sauvegarde interne et celle externalisée :

Mes actions

J'ai réalisé toutes les étapes mentionnées ci-dessus.

Acteurs et interactions au sein du projet

Étant le président de l'association mais aussi le seul technicien avec les compétences requises pour mener à bien ce type de projet il n‘y a pas eu d'autre acteur ni d'interaction avec les autres adhérents.

Résultats (pour moi, pour l'entreprise)

Les résultats furent ceux escomptés. En effet cette réalisation nous a permis de remplir les objectifs fixés en début de projet.

Lendemains du projet

Pour l'instant cette solution est en place depuis octobre 2020, elle donne entière satisfaction et à déjà permis de restaurer partie ou l'intégrité de machine virtuelle ou conteneur de production.

Mon regard critique sur le projet ou la réalisation

Il me reste cependant à parfaire mes connaissances concernant la ligne de commande et l'API du produit Proxmox Backup Server. Il permet en effet d'avoir une granularité complète en permettant de restaurer des données parcellaires de l'objet sauvegardé.

De plus il sera intéressant à l'avenir d'intégrer le monitoring de la sauvegarde dans notre outil de dédié qui est externalisé chez OVH : Zabbix.

La compétence : autocritique et évolution

Mon niveau de maîtrise de la compétence

J'ai un niveau expert pour cette compétence.

Place, importance, priorité de cette compétence dans mon profil d'Expert en Ingénierie ou dans mon métier actuel

Dans mon travail actuel je ne gère plus directement la problématique des sauvegardes.

Néanmoins je suis souvent consulté pour l'architecture globale de cette dernière ou bien pour les questions de haute disponibilité du SI.

Mon évolution

Concernant la haute disponibilité j'ai du plancher récemment sur une solution concernant nos sites internet et intranet : cela m'a conduit à concevoir, tester puis mettre en œuvre une solution de reverse proxy HAProxy (Aloha et Fusion control Plane).

Place de la compétence dans mon projet personnel

Cette compétence est omniprésente dans mon projet personnel, car le volume des demandes en terme de :

... du SI ne baissent pas

Niveau que je souhaite atteindre dans cette compétence à moyen terme

Bien qu'étant expert dans cette compétence je découvre toujours des nouvelles technologies qui me permettent d'augmenter mon niveau dans cette compétence.

Formation ou autoformation en cours ou à venir, sur cette compétence

Je suis toujours en veille technologique concernant cette compétence, notamment en consultant des forums et en participants à des bêtas tests (Ex. Proxmox Backup Serveur).

S'organiser pour mettre en place une activité de veille technologique

Entreprise : OFB

Client : idem

Projet : veille technologique système et réseau

Dates/Durée : mars 2020 / actuel

Réalisation : Veille techno Kubernetes (K8S)

Second : Veille technologique sur la plate-forme Windows server 2012 (EDF), ou SD-WAN

Source documentaire :

La réalisation majeure

Définition du projet ou de la réalisation

J'ai du organiser la mise en place de la veille technologique concernant une plateforme de gestion des applications qui se devait d'être :

  • perenne,

  • scalable,

  • modulaire,

  • éprouvée.

Remarque : Pour la suite Kubernetes = K8S

Objectifs, contexte, enjeu, risques, opportunités

Suite à la fusion des 2 établissements ONCFS et AFB, l'équipe d'administrateur système ayant les compétences GNU/Linux s'est vu confiée comme mission d'internaliser un ensemble d'applicatifs dans des délais très courts.

Un délai de moins de 2 mois ne permettait pas de mettre en place une infrastructure complète en partant depuis le début, qui plus est avec une équipe non experte dans le domaine de l'assemblage des briques open source d'un SI complet.

Je suis le seul à avoir une expérience significative dans cette compétence.

J'ai donc créer, en accord avec ma hierarchie, un groupe de travail pour mettre en place très rapidement les bases d'une architecture système à base de brique open source sans prendre de risque quand aux technologies expoitées : qui devaient être connues de toute l'équipe.

Comme vous pouvez le voir sur le schèma conceptuel suivant seuls les éléments essentiels ont été répertoriés, sans notion de site ou réseau :

Vous aurez remarqué que j'ai volontairement laissé une place pour un orchestrateur de conteneur : Kubernetes, concernant, dans un premier temps, de nos développeurs.

En effet, une fois l'internalisation des machines virtuelles, issue de nos prestataires FlowLine et DRI, terminée j'ai repris la brique Kubernetes afin d'organiser et mettre en place une veille technologique dessus.

Étapes

Pour réaliser la mise en place de l'activité de veille technologique Kubernetes j'ai du procéder comme suit :

  • organiser des réunions de lancement d'un atelier K8S administrateurs système GNU/Linux,

  • demander à chacun de se documenter un minimum sur cette brique système, via de l'auto-formation, des discussions , des recherches sur les forums , tutoriels ...(XAVKI),

  • organiser des séances de réstitution pour la mise en commun des savoirs, afin d'aborder sereinement l'étape de la mise en place d'un POC (Proof Of Concept),

  • déployer un POC : une plateforme de test K8S, sur un de nos DataCenter via notre outil d'industrialisation de notre production Ansible (GUI Rundeck):

  • demander de formation exprimée en 2020, en 2021 et redemandé en 2022 : on n'y croit encore ....

Vous trouverez plus de détail dans l'Annexe : S'organiser pour mettre en place une activité de veille technologique sur Kubernetes (K8S)

Mes actions

J'ai réalisé et participé à la plupart des étapes mentionnées ci-dessus.

Acteurs et interactions au sein du projet

L'équipe des administrateurs système GNU/Linux qui a participé à cette veille tehchnologique était composé de :

  • Frédéric Dumont,

  • Cédric Serra,

  • Zakaria Sokrane,

  • Eric Dumas (non permanent).

j'ai réalisé 25% des étapes avec les collégues de notre équipe administrateurs système GNU/Linux, et pour 75% du temps ce fut des recherches personnelles.

Enfin nous avons mis en place le cluster K8S sur un de nos DataCenter situé à Saint-Benoit en Yvelines (78).

Résultats (pour moi, pour l'entreprise)

Les résultats furent ceux escomptés. En effet cette veille technologique nous a permis de remplir les objectifs fixés en début de projet

Elle nous a permis de pouvoir reprendre, de manière plus sereine et libre de toutes pressions calendaire, la mise en place de notre plateforme K8S de développement.

Lendemains du projet

En terme technique l'équipe a évolué vers une meilleur connaissance d'une infrastructure à base d'orchestrateur de conteneurs.

Bien que cela reste avant tout une initiation, certains collgègues ont apprécié de s'approprier une nouvelle technologie via cette veille.

Mon regard critique sur le projet ou la réalisation

J'ai un regard plutot positif et emballé sur cette activité de veille technologique Kubernetes , au point que j'ai demandé pour la troisième fois à mon responsable d'avoir une formation plus poussée sur Kubernetes.

La compétence : autocritique et évolution

Mon niveau de maîtrise de la compétence

J'ai un niveau confirmé dans la compétence, car ma carrière s'est avant tout construite sur l'auto-formation et donc une quantité de veille technologique assez conséquente.

Place, importance, priorité de cette compétence dans mon profil d'Expert en Ingénierie ou dans mon métier actuel

Je continue de développer cette compétence dans mon métier actuel.

Mon évolution

Je suis toujours à la recherche de nouveaux moyens de m'auto-former et par conséquent d'organiser une veille technologique passive ou active dans le cadre d'un futur projet.

Place de la compétence dans mon projet personnel

Cette compétence est, par essence, omniprésente dans mon métier, je la pratique chaque jour.

Niveau que je souhaite atteindre dans cette compétence à moyen terme

Bien qu'étant expert dans cette compétence je découvre toujours des nouvelles technologies qui me permettent d'augmenter mon niveau dans cette compétence.

Formation ou autoformation en cours ou à venir, sur cette compétence

J'ai demandé à mon responsable une formation K8S orienté architecture système (ou Cloud architect),