1 – INTRODUCTION
Cette page a pour but de vous expliquer la réalisation suivante : “Gestion des incidents Google Cloud des entreprises”, cependant, avant de détailler cette réalisation, nous allons définir le terme “cloud”.
De nos jours, nous parlons beaucoup de cloud, mais qu’en est-il réellement ? Il s’agit de déporter ou de concevoir une infrastructure dont la gestion de l’hébergement est confiée à une entreprise experte tierce et dont la plupart des coûts financiers sont évalués à la seconde, de plus, cette infrastructure doit-être très facilement évolutive via API (Application Programing Interface) et peut-être définie « as code » et supporter des demandes de ressources conséquentes.
Ainsi le cloud, c’est bien plus que le simple fait de réaliser l’hébergement du stockage ou des différents traitements du système d’information d’une entreprise (machines virtuelles, commutateurs, routeurs, etc.) dans le datacenter d’une entreprise tierce. En effet, quand aujourd’hui nous parlons de cloud, cela implique que la plupart des coûts de traitement et de stockage sont facturés à la seconde, que l’ensemble des services proposés par l’hébergeur possèdent des API nous permettant de réaliser de l’infrastructure as code via des solutions comme Terraform.
Dans cette réalisation, nous allons pouvoir voir quelles ont été mes interventions lors de trois incidents différents survenus chez l’entreprise UKG (Ultimate Kronos Group).
2 – LES DIFFÉRENTS TYPES DE CLOUD COMPUTING
Les clouds Privés : conçus par les entreprises pour leur propre utilisation.
Les clouds Publics : conçus pour les particuliers et les entreprises de différentes tailles allant des PME aux entreprises membres du CAC 40.
Les clouds Hybrides : interconnexions de plusieurs clouds (privés comme publics) pour améliorer les performances d’une application ou profiter de services très spécifiques existants uniquement chez un seul fournisseur de cloud. Les clouds hybrides permettent également de réaliser du cloud Burst, qui consiste en l’utilisation des ressources disponibles sur un cloud public quand un cloud privé ne peut plus supporter la demande de traitement ou de stockage.
Ces trois types de cloud impliquent tous de procéder à une gestion de la sécurité très minutieuse, car déporter un système d’information vers un cloud public implique une perte de contrôle de la gestion de la data.
3 – LES INCIDENTS CLOUD
Maintenant que nous avons défini ce qu’était le cloud et ses différentes utilisations, nous allons pouvoir définir ce qu’est un incident cloud et quand celui-ci ce produit. Nous parlons d’incident cloud quand un service proposé par un CSP (Cloud Service Provider ou Fournisseur de Service Cloud en français) ne fonctionne pas comme prévu, quand celui-ci est défaillant ou a été mal configuré. Laisser un utilisateur posséder plus de droits que ceux dont il doit bénéficier réellement, représente un incident de sécurité. Autre exemple, une machine virtuelle sur le cloud qui ne se comporterait pas exactement comme nous le voudrions, s’avérerait être un incident cloud dû à une mauvaise configuration.
Après avoir défini ce qu’était un incident cloud, nous allons nous intéresser à leurs fréquences de parutions. En effet, un incident cloud, qu’il impacte le bon fonctionnement d’un service ou qu’il représente une faille de sécurité rendant vulnérable le système d’information d’une entreprise, peut être causé de trois manières distinctes.
Il existe 3 causes possibles pour qu’un incident cloud se produise :
- Un incident cloud peut être provoqué volontairement par une personne membre de l’entreprise concernée ou non. Les raisons de ces types de menaces peuvent être variées comme la volonté de nuire à l’entreprise par vengeance ou alors pour diffuser des revendications idéologiques (politiques, écologiques, économiques) mais également pour entacher son image.
- La seconde possibilité concerne un manque de vigilance ou de compétences qui engendre une faille de sécurité ou une erreur de configuration, cela est fréquent, car les administrateurs cloud qui configurent les différents services ne sont pas infaillibles.
- La dernière possibilité d’un incident cloud concerne simplement une défaillance matérielle ; en effet, les différents services que nous louons peuvent tous être interrompus à cause d’une défaillance logicielle ou matérielle (problème d’hypervision, problème électrique, problème d’accès aux ressources à cause d’un incident d’authentification généralisé chez le Cloud Service Provider, feu dans un datacenter, etc.) c’est pourquoi nous devons toujours utiliser les outils cloud qui sont à notre disposition pour réaliser de la redondance afin qu’une ou plusieurs pannes matérielles et ou logicielles, ne perturbent pas l’expérience utilisateur.
4 – OBJECTIFS
L’objectif principal de cette réalisation était d’aider les particuliers et les entreprises qui rencontrent des difficultés en matière de cloud.
Je me suis intéressé aux entreprises qui rencontrent des problèmes uniquement sur le CSP Google Cloud. En effet, j’ai pour objectif de devenir Architecte Google Cloud et c’est en travaillant dans des vrais contextes d’entreprise que je peux monter en compétences.
J’ai cherché à développer ma réflexion en matière de cloud pour atteindre mon objectif en septembre 2024 qui est la date prévisionnelle d’obtention de mon Master d’Expert en ingénierie des systèmes d’information.
Je consacre beaucoup de temps chaque semaine depuis 2021 pour me former aux technologies liées au cloud afin d’assister les entreprises ou des particuliers qui rencontrent des difficultés sur Google Cloud.
5 – CONTEXTE HUMAIN
Pour me permettre d’atteindre mes objectifs, j’ai fait le choix en 2021 de réaliser une auto-formation spécialisée dans le cloud. Malgré le nombre de livres que je lisais pour parfaire mes compétences (“Official Google Cloud Certified Associate Cloud Engineer Study Guide” et “Official Google Cloud Certified Professional Cloud Architect Study Guide” rédigés par Dan SULLIVAN) , cet enseignement restait théorique et n’était pas suffisant pour appréhender le contexte d’entreprise ; c’est pourquoi, de manière occasionnelle, je me suis rapproché de celles et ceux (particuliers ou professionnels) qui rencontraient des difficultés sur leurs environnements de production grâce au serveur Discord (réseau social) nommé “Google Cloud Community Unoffical”.
Grâce à ce réseau social, j’ai déjà pu aider plusieurs entreprises à procéder à la remise en route d’un service qui ne fonctionnait pas, ou aiguiller des personnes qui n’arrivaient pas à choisir entre deux services similaires proposés par Google Cloud.
Les bénéficiaires de cette réalisation sont des professionnels ou des particuliers qui cherchent de l’aide pour répondre à un besoin technique ou architectural (choisir entre plusieurs services similaires par exemple).
Parce que je souhaite faire de Google Cloud ma spécialité, ces échanges ont été pour moi très importants, car ils m’ont permis de travailler dans des contextes d’entreprises où l’erreur n’est pas permise.
De plus, ces échanges m’ont aidé à acquérir de la pratique sur certains services de Google Cloud pour lesquels je n’avais encore acquis que la théorie.
6 – CONTEXTE TECHNIQUE
Comme nous l’avons vu précédemment, un CSP (Cloud Service Provider) nous fournit des ressources de manière instantanée que nous payons à la seconde et dont la puissance et le stockage est illimité (moyennant finance).
Pour interagir avec Google Cloud, nous avons trois possibilités : l’interface graphique (très simple d’utilisation), le SDK (Software Development Kit) qui nous permet d’interagir avec Google Cloud en ligne de commande ; et les API qui permettent l’interaction entre le CSP et un contexte technique extérieur, cela permet, par exemple, de monitorer si l’ensemble de nos machines virtuelles sont en fonctionnement.
D’un point de vue technique, Google Cloud est bien plus qu’un simple hébergeur de données. Ce CSP loue un très grand éventail de services que je vais vous résumer en trois grandes catégories :
- Infrastructure As A Service (IAAS)
L’infrastructure en tant que service comporte l’ensemble des services de Google Cloud où le client est responsable de la configuration du système d’exploitation et des logiciels qu’il installe dessus. Dans ce cadre technique, le CSP est responsable de la gestion de la virtualisation, du réseau, de l’accès à Internet, de l’interconnexion des équipements et de la redondance du stockage ; en somme, de toutes les couches inférieures à la gestion du système d’exploitation des serveurs. La principale solution d’Infrastructure As A Service chez Google Cloud est Compute Engine. Il s’agit d’un service nous permettant de louer des machines virtuelles à la seconde.
- Platform As A service (PAAS)
La plateforme en tant que service, c’est l’ensemble des services de Google Cloud où le client va louer une plateforme technique et y intégrer uniquement ses applications et ses données. Les trois services les plus importants sont App Engine, Cloud Run et Cloud Fonction. App Engine est une plateforme entièrement gérée par Google qui nous permet de déployer des applications Web et de gérer leurs versions très facilement. Cloud Run est un service qui permet d’exécuter des applications conteneurisées de manière très aisée. Cloud Function est un service qui exécute du code.
- SERVERLESS
Les solutions Serverless ou “sans serveur” en français, désignent un ensemble de produits où aucun serveur n’est à installer, configurer ou sauvegarder côté utilisateur du cloud. Par exemple, nous pouvons choisir d’utiliser le service Google Cloud BigTable comme base de données non relationnelle. Étant serverless, cette solution a pour avantage principal de ne pas avoir de limites. Si je souhaite stocker 40 To (téraoctets), je ne rencontrerai aucun problème. Ces données seront stockées et mises en redondance de manière intelligente par Google Cloud et facturées à l’utilisateur. Concernant la facturation, celle-ci est principalement réalisée “à la seconde”. Ainsi, si nous avons besoin de stocker de la data pendant une heure, seulement une heure d’utilisation sera facturée. Les services Serverless apportent une réelle flexibilité pour les entreprises.
7 – ENJEUX ET RISQUES
7.1 – Les enjeux
Dans le cadre de cette réalisation, j’ai défini deux enjeux majeurs : la satisfaction clientèle et l’amélioration de mon expertise dans le domaine du cloud.
La satisfaction clientèle était pour moi l’un des enjeux les plus importants, en effet, travaillant directement sur les environnements de production de différentes entreprises, j’ai dû faire preuve de professionnalisme dans mes démarches. J’ai toujours expliqué au client chaque action que je réalisais sur ses interfaces Google Cloud. Quelques fois, j’ai dû procéder au redémarrage de certaines machines virtuelles, pour cela, j’ai demandé la permission au client et celui-ci a également fait passer une demande de permission auprès de sa hiérarchie. J’ai ainsi pu réaliser des actions sensibles tout en préservant la satisfaction client.
Le maintien de mon expertise en matière de cloud était un enjeu qui me tenait à cœur. J’ai eu l’occasion de découvrir certains incidents que je n’avais jamais rencontrés. Il m’a fallu lire beaucoup de documentation en ligne pour solutionner certains problèmes.
7.2 – Les risques
Aider les entreprises quand elles rencontrent des difficultés sur Google Cloud comporte des risques. C’est un constat que j’ai pu faire au fil du temps, mais que je n’avais pas mesuré au début.
Dans le cadre de cette réalisation, j’ai pu rencontrer différents types de risques, les financiers et ceux liés à la sensibilité des environnements sur lesquels j’ai pu intervenir.
- Risques financiers
Quand nous utilisons un service de cloud comme celui de Google, nous sommes dans l’impossibilité de contester le moindre problème financier. Peu importe le problème, celui-ci viendra de l’utilisateur qui se sera trompé dans sa façon de calculer le prix des services qu’il loue, c’est pourquoi nous devons maîtriser parfaitement le prix de chaque service que l’on utilise et faire extrêmement attention aux détails de facturation. Après avoir étudié le contexte technique pour une tierce personne, je ne vais pas simplement l’informer de quel service Google Cloud elle pourrait utiliser, je vais lui expliquer qu’utiliser un service x ou y comporte un prix que je vais lui détailler. Je peux également lui donner accès à des documentations de coûts rédigées par mes soins ou simplement une documentation officielle de Google Cloud pour que cette personne puisse être parfaitement informée. Pour donner un exemple concret concernant ma façon de me préparer face à ce risque, j’ai lu intégralement les conditions d’utilisation de Google Cloud avant d’y créer un compte et à chaque fois que j’ai besoin d’utiliser un service, je consulte toujours les documentations officielles de Google Cloud concernant les détails des coûts. Malgré ça, il m’est arrivé de me tromper, par exemple, j’utilisais les “health checks” (ou vérifications d’état en français) de Google Cloud pour être notifié si l’un de mes différents sites web n’était plus accessible. Cela me permettait également d’être informé du temps de réponse de chacun d’entre eux. Ces services sont présentés comme gratuits cependant, un jour, j’ai vu la facture augmenter de plus en plus et je n’arrivais pas à trouver d’où venait le surcoût. Après quelques investigations, j’ai pu constater que cela venait de ces health checks pourtant indiqués comme gratuits. Aujourd’hui, j’ai quelques suspicions sur quelle partie de la configuration m’a été surfacturée, (possiblement les notifications par SMS) mais je n’en suis pas encore parfaitement sûr. Cet incident m’a coûté plus d’une vingtaine d’euros et m’a appris que la coûtenance d’un projet doit être extrêmement minutieuse, car une mauvaise gestion de celle-ci peut engendrer des conséquences financières, vraiment exorbitantes selon les contextes.
- Risques liés à la sensibilité des environnements
Opérer dans des contextes de production implique forcément la prise en compte de leur sensibilité. Cette sensibilité se manifeste en deux catégories, la première est relative à la sensibilité liée à l’information et la seconde aux permissions que l’on m’accorde.
- La sensibilité liée à l’information
Pour que je puisse procéder au mieux à tout type d’aide ou d’intervention sur une erreur Google Cloud que rencontre une entreprise, un échange préalable avec le demandeur est nécessaire. Dans le cadre de cet entretien certaines données sensibles de l’entreprise peuvent être communiquées. Cet ensemble d’informations peut comprendre : le nom de l’entreprise, le nombre de clients, les versions des systèmes d’exploitation, les logiciels impactés par la panne, etc.
- Les permissions accordées
Après l’échange initial me permettant de comprendre la problématique en cours, si la situation le demande, il est arrivé plusieurs fois que l’on me donne directement accès à l’interface d’administration cloud d’une entreprise. Cette étape est celle que je préfère, car c’est celle où l’on m’accorde le plus de confiance et de responsabilités. Du fait que je sois directement connecté aux interfaces d’administration de Google Cloud pour l’entreprise concernée, cela m’accorde presque tous les droits. Ce qui veut dire que j’ai la possibilité de regarder n’importe quelle interface. Cette “liberté” peut me faire entrevoir des informations sensibles d’entreprise comme des adresses IP de balanceurs de charge, celles des machines virtuelles, la liste des utilisateurs Google Cloud, etc. J’ai volontairement mis entre guillemets le fait que j’étais libre sur cette interface, car ces actions sont constamment réalisées en visioconférence. La personne que j’aide me surveille dans chaque action que je réalise sur son interface cloud, ce qui est tout à fait normal. Pour simplifier l’échange, j’explique toujours la méthodologie que je compte suivre pour solutionner son problème.
Dans le cadre de cet accès à l’interface d’administration Google Cloud de la personne que j’assiste, je dispose entièrement ou partiellement des permissions d’administrateur. C’est pourquoi je dois procéder à une vérification minutieuse de l’infrastructure cloud de la personne que j’aide. Dans un tel contexte, je dois envisager toutes les conséquences que peuvent engendrer chaque action que j’exécute sur l’interface en tant qu’administrateur. Si je réalise une action qui ne produit pas le résultat que j’espérais de part un manque de formation ou de pratique, cela peut engendrer des incidents cloud supplémentaires. Si je me trompe dans une commande et que je supprime une machine virtuelle, cela peut engendrer une coupure de service plus ou moins longue et des frais financiers pour l’entreprise que je devais aider. Cet exemple montre à quel point il est important que je maîtrise de la manière la plus optimale possible les services Google Cloud pour pouvoir être complètement sûr de chacune de mes actions. Ce besoin de connaître la plateforme et la console d’administration Google Cloud est d’autant plus important, car des erreurs de traduction persistent et certains mots affichés sur les interfaces graphiques ne correspondent pas à la vraie fonction des boutons associés.
8 – ÉTAPES DU PROJET
8.1 – Premier contact avec le cloud
J’ai découvert le concept de cloud en cours d’automatisation avec mon enseignant Monsieur José GIL dans le cadre de mon BTS SIO. J’ai rapidement été passionné par le principe du paiement à la seconde et par le concept d’avoir une puissance de calcul infinie grâce au cloud. Je n’ai pas retenu le fournisseur cloud Microsoft Azure, car l’interface utilisateur m’a déplu de par sa complexité. J’ai très vite trouvé un cloud qui me correspondait : Google Cloud, car l’interface est très simple et le niveau technique très élevé. Dès le début de l’année 2021, j’ai ainsi commencé à tester les différentes fonctionnalités de Google Cloud.
8.2 – Approfondissement et interactions
Après de nombreuses heures d’approfondissement de mes connaissances en matière de cloud (le détail du procédé de cet approfondissement se trouve dans la compétence cloud computing), j’ai eu envie d’aider les personnes rencontrant des difficultés en matière d’incident cloud.
J’ai pour cela rejoint le serveur Discord nommé Google Cloud Community Unofficial. Ce serveur regroupe différentes personnes toutes passionnées ou simplement concernées par Google Cloud. Pour simplifier, ce serveur est une sorte de forum d’entraide centré sur Google Cloud. Chacun peut s’y rendre et poser des questions ou consulter des questions posées par d’autres utilisateurs et publier une réponse.
C’est à cet emplacement que je me rends pour visualiser les dernières demandes publiées par les utilisateurs. Si cela n’a pas été déjà fait, j’apporte une solution en anglais. Cependant, je ne propose pas de réponse sur des sujets que je ne maîtrise pas. Selon le niveau technique et le degré de compréhension dont dispose la personne qui émet le ticket ou la demande, il m’arrive de définir un rendez-vous avec elle dans un délai plus ou moins court, dans le but de mieux comprendre sa problématique.
9 – TRAVAIL RÉALISÉ
Dans le cadre de cette réalisation, je vais vous présenter les différentes interventions effectuées pour l’entreprise américaine UKG.
UKG est une entreprise américaine conceptrice de logiciels spécialisés dans la gestion de la comptabilité et des ressources humaines.
Grâce au serveur Discord, j’ai pu rencontrer Phillip MIKHAIL qui est senior CDB (Cloud Database Engineer) chez UKG (Ultimate Kronos Group). Nous avons échangé sur trois incidents tous techniquement différents.
Le premier fut un problème de permissions lié au service Compute Engine, le second était lié à un problème d’espace disque et enfin, le troisième était un problème de permissions sur le service cloud Functions. Nous n’avons pas traité ces incidents simultanément. Après avoir fait connaissance à l’occasion du premier incident lié aux problèmes de permissions sur le service Compute Engine, nous avons continué à échanger concernant Google Cloud à de nombreuses reprises. Le motif de ces échanges était souvent lié à des problèmes de droits ou à des menus spécifiques que je lui avais montrés lors de nos entretiens, mais qu’il ne retrouvait plus.
9.1 – Permissions Compute Engine et Monitoring
Le premier incident dont Monsieur MIKHAIL m’a fait part est survenu sur le Service Compute Engine. Comme nous l’avons vu précédemment, Compute Engine est l’un des services principaux de Google Cloud. Il permet de louer à la seconde des machines virtuelles avec un choix très varié en matière de puissance et de stockage.
Pour bien comprendre l’incident survenu, il faut savoir que Google met gratuitement à disposition un service serverless nommé “Monitoring” permettant la collecte, l’inventaire et l’affichage des métriques. Les métriques sont des relevés réalisés sur les composants physiques ou logiciels des différents services disponibles sur Google Cloud dans le but d’évaluer leur santé. Il a pour but de simplifier la visibilité sur les différents services et actifs loués sur Google Cloud. L’incident que nous allons détailler est survenu sur la liaison entre les services Compute Engine et Monitoring. Pour améliorer le niveau de surveillance des machines virtuelles sur Compute Engine, un logiciel supplémentaire (appelé agent) doit être installé sur chacune des VM (machines virtuelles). Ce logiciel va envoyer de manière périodique des métriques au service Monitoring.
L’incident concernait un problème rencontré lors de l’installation de cet agent sur l’une des machines virtuelles de l’entreprise UKG dans le service Compute Engine. Pour procéder à l’installation de cet agent sur une VM Compute Engine, le processus a été semi-automatisé par Google. Pour installer l’agent, il suffit d’utiliser une fonction automatique qui le réalise pour nous, cependant, Monsieur MIKHAIL a rencontré des difficultés durant cette installation qui semblait simple. Son tableau de bord qui installe et monitore les agents de monitoring reportait que l’agent n’était pas détecté par Google Cloud. C’est à ce moment précis que Monsieur MIKHAIL a demandé de l’aide sur le forum Discord.
Après avoir échangé sur différents aspects techniques pour tenter de résoudre le problème par messages instantanés, je lui ai proposé de l’appeler pour simplifier les échanges. Lors de cette communication, il m’a donné accès à son infrastructure Google Cloud pour que je puisse intervenir. Après une investigation minutieuse, j’ai réussi à déterminer qu’il s’agissait d’un problème de permissions.
Pour déterminer la source du problème, j’ai procédé à trois investigations distinctes : vérifications des permissions de l’utilisateur d’administration, du bon fonctionnement de l’agent de monitoring et des permissions accordées à la machine virtuelle.
Première vérification
La première vérification que j’ai effectuée a été de consulter la liste des permissions accordées à Monsieur MIKHAIL dans la console Google Cloud. J’ai considéré que l’installation étant automatisée par Google, un problème de droits pouvait être en cause. J’ai donc navigué au travers de la Google Cloud Console pour accéder à l’interface IAM qui permet l’administration des permissions. Dans cette interface, je suis allé consulter la liste des permissions accordées à l’utilisateur. Cette liste confirmait qu’il disposait bien des droits d’administration sur les services Compute Engine et Monitoring. Un problème de permission n’était pas la cause du dysfonctionnement.
Seconde vérification
Je l’ai effectuée directement sur la machine virtuelle posant problème. Je me suis dit que si l’utilisateur était parfaitement dans ses droits pour déployer l’agent (un logiciel permettant de réaliser l’exportation de métriques vers une solution de monitoring) sur la machine, l’agent avait peut-être rencontré des difficultés. J’ai alors vérifié si le fichier de configuration par défaut avait bien été créé à l’emplacement “/etc/google-Cloud-ops-agent/config.yaml”. J’ai par la suite regardé que les trois services responsables de la liaison entre Compute Engine et Monitoring soient tous présents et démarrés sur le système. Ces services sont respectivement : “google-Cloud-ops-agent-diagnostics”, “google-Cloud-ops-agent-fluent-bit” et “google-Cloud-ops-agent-opentelemetry-collector”.
Sur la machine virtuelle, ils étaient tous démarrés et fonctionnels, cependant, les journaux d’événements m’ont appris que les services en question étaient en échec, car ils leur manquaient des droits. Cela m’a amené à procéder à la dernière vérification.
Troisième vérification
Ma troisième vérification portait sur les permissions que possède la machine virtuelle elle-même. Sur Google Cloud, une machine virtuelle possède un ensemble de permission lui permettant d’interagir avec l’environnement Google Cloud. Ces permissions sont affectées à l’aide d’un compte de service.
Pour tenter de corriger le problème de permissions constaté précédemment, je me suis rendu sur le panneau d’administration de la machine virtuelle et j’ai affiché ses détails de sécurité. J’ai pu constater que celle-ci n’utilisait pas le compte de service défini par défaut par Google Cloud. En discutant avec Monsieur MIKHAIL celui-ci m’a expliqué que pour des raisons de sécurité, il avait préféré n’accorder qu’une petite quantité de permissions en affectant à cette VM un compte de service créé par ses soins. A ce moment-là, nous avions trouvé la cause du problème.
J’ai ensuite discuté avec Monsieur MIKHAIL pour lui proposer une solution. Je lui ai expliqué que selon-moi, pour corriger le problème de la manière la plus efficace, il suffisait de modifier les permissions du compte de service personnalisé, cependant, je lui en ai détaillé les conséquences, en effet, nous allions accorder de nouveaux privilèges à l’ensemble des machines virtuelles utilisant le compte de service en question. Ce changement ferait forcément baisser le niveau de cloisonnement des machines virtuelles en permettant à la machine virtuelle de contacter les API de Google Cloud monitoring. Monsieur MIKHAIL m’a assuré comprendre le risque et être parfaitement d’accord pour réaliser cette modification.
Pour appliquer ce changement, nous nous sommes rendus sur l’interface d’administration des permissions dans Google Cloud nommé “IAM et administration” et nous sommes allés dans la rubrique “comptes de service”. Puis, nous avons modifié le compte de service concerné en lui affectant des droits de lecture et d’écriture sur les services de monitoring.
Pour confirmer le bon fonctionnement de ce changement, nous avons attendu quelques minutes et puis nous sommes allés sur l’interface de gestion des agents OPS (agents de monitoring Google Cloud) et nous avons vérifié l’état de l’agent installé sur la machine virtuelle concernée. L’écran de monitoring nous a alors indiqué que l’agent était bien installé et fonctionnel sur la machine virtuelle en question.
Ceci est donc la méthodologie que j’ai employée afin de corriger le tout premier vrai incident Google Cloud que j’avais à résoudre pour le compte d’une entreprise.
9.2 – Espace Disque
Le second incident sur lequel j’ai pu intervenir est survenu plusieurs semaines après le premier. Monsieur MIKHAIL m’a contacté pour une assistance concernant un problème de disques durs sur le service Compute Engine. Ce problème concernait la possibilité d’étendre les capacités des disques durs des machines virtuelles. Compute Engine étant très personnalisable, il est possible pour un usager d’augmenter la taille des disques durs d’une machine virtuelle. Monsieur MIKHAIL m’a donc informé qu’après avoir changé la taille d’un disque dur sur l’une de ses machines virtuelles de production (dont le système d’exploitation était Linux), aucun espace disque dur ne fut mis à jour par Google Cloud. Pour corriger cet incident, j’ai procédé en trois étapes.
Premièrement, j’ai cherché à confirmer la présence du problème et à en comprendre l’origine en discutant avec Monsieur MIKHAIL. La première action que j’ai réalisée dans le cadre de cet incident a été de chercher à confirmer que celui-ci était bien fondé, pour ce faire, je me suis rendu sur Compute Engine pour consulter la configuration définie de la machine virtuelle. Sur le détail de la configuration de la machine virtuelle, j’ai pu afficher les différents disques durs qui étaient affectés à la machine virtuelle qui dysfonctionnait. Grâce à cet affichage, j’ai pu corréler en temps réel le volume de stockage configuré dans les paramètres Google Cloud et celui présent dans la machine virtuelle en production. J’ai ainsi pu confirmer que l’incident cloud était avéré. Après avoir confirmé l’existence du dysfonctionnement, je me suis entretenu avec Monsieur MIKHAIL pour trouver la source du problème, car je ne comprenais pas comment une telle situation pouvait se produire.
Dans un schéma classique, nous procédons au changement d’espace disque sur l’interface d’administration de Google Cloud et après le redémarrage de la machine virtuelle, le changement est appliqué automatiquement. En effet, cette façon de faire fait partie des grandes qualités de Google Cloud, c’est pourquoi j’ai souhaité que Monsieur MIKHAIL me réexplique en détail tout le procédé qu’il a appliqué pour réaliser le changement de volume de disque sur sa machine virtuelle. Il m’a donc expliqué qu’il avait procédé au changement sur l’interface d’administration de Google Cloud et qu’il avait attendu un certain temps, mais que rien n’y faisait, qu’aucun changement du volume des disques n’était constaté sur sa machine virtuelle. Grâce à ses explications, j’ai pu lui demander si un redémarrage de la machine virtuelle avait été effectué après l’application des changements. Monsieur MIKHAIL m’a alors informé que la machine virtuelle n’avait pas été redémarrée car celle-ci était sensible. À ce moment-là, j’ai pu comprendre pourquoi nous étions dans un tel scénario. En effet, le fait de redémarrer la machine virtuelle fait partie intégrante du processus d’augmentation des tailles de disques durs.
Après avoir trouvé la source du problème, j’ai dû déterminer quel plan d’action serait le plus pertinent à appliquer. J’ai expliqué à Monsieur MIKHAIL qu’actuellement, son entreprise payait déjà pour ce surplus d’espace et que le fait d’appliquer ces changements représentait un vrai gain financier et technique. Monsieur MIKHAIL n’avait pas l’autorité nécessaire pour redémarrer une machine virtuelle de cette sensibilité. Celui-ci s’est donc absenté de notre visioconférence afin d’aller demander la permission à sa hiérarchie. Après l’avoir obtenue, nous avons procédé au redémarrage de la machine virtuelle. Nous avons alors constaté que l’action effectuée avait bien corrigé l’incident de disque. Pour ce faire, nous avons affiché les détails des disques durs de la machine virtuelle et ils nous ont révélé que celle-ci possédait bien l’espace manquant et nous avons ainsi corrigé l’incident de production lié aux problèmes d’espace des disques durs.
9.3 – Permissions Google Cloud Functions
Le troisième et dernier incident que Monsieur MIKHAIL m’a confié à résoudre concernait l’interconnexion des services Google Cloud Functions avec Google Cloud SQL.
Avant de nous pencher sur l’incident, je vais vous présenter les deux services concernés. Le premier est Google Cloud Functions. Ce service, qui est Serverless, permet à un utilisateur de déclencher du code en fonction de différents événements produits sur Google Cloud. Par exemple, je peux choisir de vouloir compresser automatiquement n’importe quelle image uploadée sur un bucket Google Cloud en configurant une fonction Google Cloud qui se déclenchera à chaque fois que l’envoi d’un fichier sera finalisé. Google Cloud Functions permet d’automatiser des tâches de gestion dans le cloud.
Google Cloud SQL est un service de bases de données relationnelles complètement géré par Google Cloud ce qui en fait une solution PAAS (Platform as a service). L’utilisateur n’a pas à se soucier de la redondance ou des sauvegardes, car tout est géré par Google, il n’a qu’à spécifier son besoin précis.
L’incident que nous rencontrions concernait l’interconnexion de Google Cloud Functions avec Google Cloud SQL. Dans son utilisation de Google Cloud, Monsieur MIKHAIL a décidé d’utiliser une fonction Google Cloud pour procéder à une sauvegarde externalisée des bases de données de Google Cloud SQL. Dans un premier temps, je lui ai exprimé mes doutes face à ce choix d’architecture et je lui ai montré la gestion des backups auto-gérés par Google Cloud. Il m’a informé qu’il souhaitait tout de même procéder à des sauvegardes externes. Il avait créé une fonction qui procédait périodiquement à une extraction de ses bases de données, mais la fonction était systématiquement en échec. Les logs de la fonction lui indiquaient qu’il ne disposait pas des permissions suffisantes pour réaliser l’extraction des données sur Google Cloud SQL.
Le problème de permissions ayant été défini au préalable, j’ai pu réaliser une investigation très simple, car je savais exactement ce que je cherchais. Je me suis rendu dans les détails de la fonction Google Cloud et je suis allé regarder le compte de service que celle-ci utilisait. Je suis allé ensuite dans les tableaux de gestion des comptes de service dans Google Cloud IAM et j’ai consulté la liste des permissions attribuées au compte de service concerné. Comme je le pensais, aucune permission d’exportation des données de Google Cloud SQL n’avait été attribuée à ce compte de service. Je lui ai donc indiqué qu’il fallait y remédier. Après que Monsieur MIKHAIL ait appliqué la solution que je lui ai indiquée, la fonction Google Cloud a été fonctionnelle.
10 – FIN DU PROJET ET PERSPECTIVES D’AVENIR
Le fait d’aider les personnes en difficulté sur Google Cloud m’a permis d’appliquer mes connaissances dans des vrais contextes techniques. Cela m’a rendu plus minutieux dans chacune de mes réponses techniques. Ces échanges m’ont fait progresser en compréhension et expression orale et écrite en anglais et m’ont donné la possibilité de rencontrer d’autres professionnels et d’échanger sur des sujets de veille technologique par exemple.
J’envisage de continuer d’assister des personnes en difficulté avec Google Cloud, car cela me permet de rester à jour sur les différentes technologies de cette plateforme.
J’ai pour perspectives d’avenir de progresser encore davantage en compétences liées au cloud afin de mieux maîtriser les environnements techniques que je rencontre. J’ai également besoin d’affermir mes compétences eu égard au fait que je suis junior en informatique.
11 – CE QUE JE RETIENS
L’environnement de production étant très sensible, je dois maîtriser les solutions sur lesquelles j’interviens. Il est très important pour moi d’avoir une bonne maîtrise des solutions techniques rencontrées pour trois raisons : gain en crédibilité, pertinence des réponses techniques et pour éviter de commettre des erreurs.
Maîtriser les solutions techniques sur lesquelles j’interviens pour apporter une réponse technique à un incident m’apporte un gain en crédibilité. En tant que junior, rien ne m’empêche de répondre à un incident sur un forum, cependant si je ne maîtrise pas le sujet, comment pourrais-je y répondre pertinemment ? Comprendre les technologies me permet de répondre dans la bonne direction, mais pas toujours précisément. En tant que Junior, j’ai encore beaucoup à apprendre. Comprendre les contextes techniques me permet ainsi d’être pertinent dans mes réponses et de gagner en confiance. Comprendre mon environnement technique me permet aussi d’éviter de faire des erreurs. J’expliquais précédemment que chaque clic que je réalise sur la Google Cloud Console peut engendrer des conséquences potentiellement désastreuses pour les entreprises, car même si je suis de bonne volonté, je dois continuer à pratiquer pour progresser toujours plus.
Les utilisations du cloud étant diverses, je dois m’adapter aux contextes et aux choix réalisés par des Seniors. Nous avons l’exemple du choix qu’a fait Monsieur MIKHAIL concernant l’externalisation de ses sauvegardes Google Cloud SQL alors que celles-ci peuvent être entièrement gérées par le fournisseur cloud. Dans ce contexte, j’ai tout de même fait valoir mon point de vue, mais tout en étant conscient qu’en tant que Junior, je n’ai pas une visibilité aussi pointue que celle d’un senior. J’ai donc proposé une solution (utiliser les sauvegardes internes à Google Cloud SQL) qui a été déclinée par Monsieur MIKHAIL, car celui-ci souhaitait rester maître de ses sauvegardes. Aujourd’hui, après avoir pris un peu de recul sur cette question, je comprends le choix réalisé, car le fait de visualiser des fichiers SQL créés chaque jour et de pouvoir les consulter à tout moment permet de rassurer l’administrateur cloud.
Les échanges techniques sont un vrai moyen de monter en compétences. En effet, j’ai pu dialoguer avec beaucoup d’autres informaticiens plus ou moins passionnés par Google Cloud. J’ai pu rencontrer des personnes qui ne pensaient pas comme moi. Cela m’a notamment permis certaines fois de reconsidérer mon avis et de changer ma façon de penser. Ayant encore beaucoup à apprendre, je cherche vraiment les échanges avec d’autres informaticiens pour mieux appréhender l’informatique de demain.
Je suis réellement content de la confiance que Monsieur MIKHAIL m’a accordée. Celui-ci m’a donné accès à son interface d’administration Google Cloud et cela m’a permis de m’exercer sur des problèmes de production qui m’ont vraiment fait monter en compétences. Par exemple, je n’avais jamais cherché à savoir ce qui était réellement installé par l’agent de monitoring dans les machines virtuelles, mais pour résoudre son souci, j’ai dû me documenter pour répondre au mieux à l’incident rencontré.