Tous les jeunes veulent travailler dans la tech et rêvent de devenir développeurs ou développeuses.
C'est pas étonnant parce que le métier de dev, c'est celui qui est le plus représenté dans les médias ou dans la culture populaire.
Pourtant, il y a des tas d'autres métiers dans le numérique.
Aujourd'hui, je suis avec Kevin Davin et ensemble, on va parler de son rôle d'ingénieur de fiabilité du site ou site Reliability Engineer en mauvais anglais.
Si le DevOps n'est pas un métier, le SRE, lui, est un métier DevOps et je dirais même le métier DevOps par excellence.
En tout cas, c'est la pression que j'ai de loin. Donc il faut qu'on en parle.
Bienvenue sur Radio DevOps, la balade aux diffusions des compagnons du DevOps.
Si c'est la première fois que tu nous écoutes, abonne-toi pour ne pas rater les futurs épisodes. C'est parti !
Bonjour à toi chers compagnons et bienvenue dans ce nouvel épisode dans ma partie, l'émission où je m'entretiens avec un invité.
Alors pour fêter le lancement de mon jobboard avec My Little Team, j'ai décidé de faire une série d'entrevues pour parler des métiers de la production, de l'exploitation, de l'infrastructure.
Mais on reparlera de mon jobboard en fin de vidéo donc reste bien jusqu'à la fin si tu cherches du taf dans le milieu du numérique.
Avant de commencer, je te rappelle que j'ai créé et que j'anime une communauté en ligne francophone dédiée au cloud et au DevOps qui est une communauté de professionnels.
On est déjà plus de 1000 à échanger et à partager tous les jours. Donc si tu veux pas rester seul face à tes questions, rejoigne-nous.
C'est le premier lien en description pour t'inscrire.
Ou alors tu peux aller sur le site compagnon-devops.fr.
Alors bonjour, Kevin. Merci d'avoir répondu à mon appel à témoignage. Est-ce que tu peux justement te présenter en quelques mots et nous dire ce que tu fais dans la vie ?
Bonjour d'abord.
Je suis chez Gradel, je travaille en tant que backend engineer et je suis un peu plus sur la partie qui va gérer ou être en lien avec la prod.
Donc l'application elle-même, mais comment l'application doit tourner en prod et doit bien réagir dans cette environnement-là parce que c'est bien de développer des choses.
C'est mieux si ça tourne en prod parce que je sais pas toi, mais moi en tout cas, les applications, si elles sont pas délivrées en prod, un jour elles servent à réagir.
Et à côté de ça, je suis sur pas mal de sujets. GitLab Vero, j'adore mon outil GitLab et je me promet le plus possible.
Je travaille sur ma partie Google Cloud aussi, où je suis développeur advocate, expert plutôt, si je peux utiliser le bon terme.
Et, vu que j'ai un gros background de dev, je suis gdo aussi sur la partie copy.
Ouais, tout à fait. Je suis d'accord avec toi, si on développe une application, c'est bien qu'elle tourne en prod.
Et d'ailleurs, je trouve que la prod, on en parle pas assez pendant les études.
En tout cas, moi, j'ai découvert ça au moment où je me suis lancé dans la vie professionnelle.
Alors, j'ai perdu mes petites notes, je vais les retrouver.
Alors, tout d'abord, je vais te poser une de mes questions rituelles.
C'est quoi, pour toi, ta propre définition du DevOps ?
Alors, définition du DevOps, je l'ai appris au fur et à mesure du temps.
Pour moi, d'abord, c'est une philosophie.
On voit plein de jobs sortir partout, ingénieurs DevOps.
Pour moi, ingénieurs DevOps, c'est philosophie.
Donc, je n'aime pas du tout cette appellation d'origine.
Pour moi, le DevOps, c'est vraiment ce fait que les équipes de dev et de prod vont travailler ensemble.
Ça va intégrer la série, ce qui est au milieu pour déployer.
Ça va prendre aussi des éléments qui viennent de la prod, pour le monitorer, des gens de choses.
C'est vraiment ça pour moi.
La philo DevOps, c'est avoir tous ces éléments-là ensemble pour intégrer en amont les choses de l'appli,
mais aussi à posteriori, c'est-à-dire prendre en compte un besoin de prod dans ton appli.
L'ingénieur de prod est autant un client que le futur client.
Si tu n'esfeux d'appli mais que tu ne peux pas la monitorer, tu vas être un peu en défi.
Et du coup, pour aller avec ça, comment tu as rencontré le DevOps et qu'est-ce que ça a changé dans ta vie ?
Comment je l'ai rencontré majoritairement par des expériences, je travaillais dans le service avant.
Petite expérience, petit à petit, en fait, il y avait quasiment un shadow-it intern, là où je bossais,
où les services nominaux n'étaient pas cohérents avec ce qu'on voulait.
C'était du S-Vein quand on voulait du Git.
C'était, je ne citerai pas le nom alors qu'on voulait du GitLab.
Donc on a commencé à livrer et utiliser quelque chose d'autre.
Et à partir de là, il y a une prod.
Il y a des utilisateurs, c'est-à-dire un système et d'oeuvre.
Ça veut dire que tout est dev, ils sont observés, ils ne peuvent pas travailler.
Donc tu vas perdre du temps.
Donc pour moi, c'est là que j'ai commencé à découvrir la prod.
Et au fur et à mesure du fait de mon grand-grand dev,
j'ai toujours voulu mêler ma logique de dev de comment gérer les choses avec ma gestion de la prod.
Et derrière, GitLab.
GitLab est promue la philosophie des DevOps à travers l'équipe.
Et je l'ai découvert et utilisé au fur et à mesure des nouvelles versions GitLab.
C'est vrai que moi aussi, ça m'est arrivé.
Au début de ma carrière, j'étais développeur et puis je suis passé petit à petit vers la prod.
J'ai même bagon.
J'ai cette envie aussi d'automater les choses.
Et je m'étais posé ces questions là aussi.
Moi, j'ai vu en fait les murs de la compréhension au sein des boîtes où j'étais.
Alors, maintenant, on va rentrer dans le vif du sujet.
Vous avez justement le métier de SRE.
Alors, tu m'as dit que tu n'avais pas officiellement le titre SRE.
Mais que tu faisais ce qui se rapprochait du SRE.
Alors, le SRE, c'est un métier qui a été popularisé par Google.
Si je ne me trompe pas.
Et est-ce que tu peux nous en parler un petit peu plus et le définir ?
Parce que, comme je t'ai dit en introduction, moi, je ne le connais pas.
Pour le définir, j'aime bien, généralement, qu'on peut présenter, utiliser des termes que j'en connais un peu plus.
Par exemple, si on prend le métier d'Admin 6.
En fait, le SRE, c'est logiquement l'évolution d'Admin 6 qui a pris les bonnes pratiques du dev et qui les a intégrées dans son fonctionnement.
Donc, je ne parle pas.
Ça ressemble beaucoup au DevOps.
Et d'ailleurs, dans les définitions, très souvent, il est dit que le SRE est une implémentation de la philosophie DevOps.
Donc, c'est comment, en vrai, on va gérer ce genre de choses.
Quand DevOps est une philo, la SRE, c'est une mise en application.
Et dans ce métier, tu peux être amené à gérer beaucoup de choses.
Majoritairement, on va avoir des sujets autour de la disponibilité des services, suivi des performances, de la latence, de l'efficacité, de savoir si tout fonctionne correctement.
Ça, c'est quand tu vivres et que tu n'as plus tour.
Mais aussi, si tu n'as pas l'appli, tu ne la vives pas qu'une fois.
Donc, savoir gérer tout ce qui est le change management, le monitoring, savoir ce qu'il faut faire quand un système tombe.
Et essayer aussi d'aider les équipes de DevOps à avoir conscience de tout ça.
Et que quand ton petit service Rédyse de cache qui se trouve dans un bouton d'infrastructure tombe, ça ne passe pas tomber tout le reste.
Donc, ça va être aussi, moi, je le fais pas mal chez Gradle, mais je le fais aussi beaucoup en tant que GBE sur la partie cloud,
sur aider les personnes à comprendre ce genre de choses pour ne pas développer des gros monolithes distribués à la façon Kubernetes que beaucoup font.
Donc, pour moi, ça va vraiment être ça.
Savoir gérer les applications et amener tous les éléments positifs du Dev dans la philosophie du travail de la Linux 6 pour en faire un étude de SR.
Donc, du coup, ce que tu me dis, en fait, c'est que le fameux poste qui, pour moi, n'en est pas un d'ingénieur DevOps, c'est en fait SR tout simplement.
Ça se rapproche beaucoup plus.
En tout cas, lui, c'est un vrai titre.
Ok, on est d'accord.
Du coup, je le profite parce que ça fait écho à un podcast que j'ai sorti il y a quelques temps qui s'appelle l'admin 6 DevOps.
On a discuté avec Ludovic Pio justement de ce poste-là qui est sorti officiellement.
Et donc, je pense que c'est un prémisse du SR, ou en tout cas, c'est une partie de la transposition parce que c'est pas niveau back plus 5, mais c'est un niveau back plus 3, je crois, la min 6 DevOps.
Est-ce que tu penses que c'est justement un prémisse à ça qu'on va voir arriver une fiche de poste un jour, je le dis, officielle ?
Pour moi, les fiches de poste sont aussi énormément teintées par la mode DevOps.
Une mode qui a fait apparaître énormément de fiches de poste, dingé DevOps, qui voulait tout et rien dire.
Des fois, c'est celui qui s'occupait de la sial, des fois, c'est celui qui communiquait entre les DevOps.
Pour moi, le SR, je commence à voir la même chose arriver en termes de buzzword et d'utilisation du terme.
Donc, on va pouvoir y trouver derrière un peu tout et parfois n'importe quoi.
Même certains qui m'ont entendu le définir, peut-être ne seront pas d'accord avec la définition que j'en ai donnée.
Je pense que ça arrivera. En tout cas, pour moi, il y a besoin d'avoir ce poste-là qui soit quand même une extension de la min 6
qui va plus loin que je démarre la pli et si ça marche pas, je vais juste contacter les deux.
Oui, alors j'aurais peut-être dû utiliser le terme de titre RNCP plutôt que fiches de poste parce que c'est ça dont je faisais référence.
C'est un titre officiel pour valider des études.
Et après, la fiche de poste ou ça, des entreprises, des entreprises à chose qu'elles veulent, on a bien vu ce que ça donnait.
Du coup, j'ai quand même l'impression que c'est un métier qui est très peu connu en France. Est-ce que tu confirmes ça ?
Ça commence à arriver. Ils viennent de plus en plus tendants.
Je connais des personnes par exemple chez Dr.Lib qui ont ce titre-là et ils utilisent ce titre depuis un ou deux ans maintenant.
Donc sur les entreprises franco-françaises ou au minimum européenne, ça commence à apparaître.
C'est beaucoup plus présent côté Amérique forcément.
Je pense que ça va grimper assez vite parce que avec le cloud, on commence à avoir de plus en plus de mise en prod, des choses qui vont de plus en plus vite.
Et il y a besoin d'avoir la personne au bout de cette chaîne qui sait gérer et faire redescendre des choses.
Oui. C'est vrai que quand je parlais d'entreprises français, je parlais plus de manière générale parce que là, les exemples que tu m'as cité, c'est des entreprises techs à la pointe, on va dire.
Et donc c'est le sommet de l'iceberg pour moi.
Et quand on sait, et justement ça va faire partie de ma deuxième question, quand on sait qu'il y a beaucoup d'entreprises en France qui ne sont même pas encore passées au DevOps,
moi ça m'étonne à moitié que justement le SRO ne soit pas plus répandu que ça.
Et ma question, du coup, c'est est-ce que tu penses qu'une entreprise qui n'a pas rejoint le mouvement DevOps, qui n'a pas mis en pratique la philosophie, etc.
Est-ce qu'elle peut avoir quand même des SRO au sein de ses équipes ?
Je dirais que non. Pour moi, c'est très compliqué parce que étant donné par définition de départ que le SRE est une implementation DevOps,
si tu n'as pas cette philosophie au départ, ça va être compliqué d'être en application.
Et je pense par rapport à la réponse que tu m'as donnée, donc que des entreprises moins tech que ce que j'ai cité,
elles vont potentiellement plus se tourner vers les solutions et les éléments de manager qui vont en fait déporter le SRE chez quelqu'un d'autre.
En fait, quand tu payes un service manager d'une database manager, d'un Kubernetes manager, peu importe,
en fait, il y a des SRE derrière qui dose pour toi. Tu ne les vois pas.
Il t'assure juste que ton service va être disponible avec 99,99. Tu n'as jamais de contact avec eux, mais ils te l'assurent.
Et en fait, eux sont là pour toi. Si ton entreprise n'a pas les moyens, la philosophie, la culture et tout ça pour le faire,
elle prend un service jusqu'à OSA, qui le fera pour toi.
Oui, enfin, il faut quand même des compétences pour gérer le SACE. Je vois que j'ai des gros clients.
Je ne vais pas les citer ici, mais dans la grande distribution, notamment, ils ont eux-mêmes leur propre data center.
Ils passent petit à petit au cloud, voire à des cloud internes. Ces gens-là, ils ne sont pas encore passés au DevOps.
Pourtant, ils ont 200 à 300 informaticiens qui gèrent leur prod.
Je sais que c'est dur pour eux de passer au DevOps parce que tous les clients objectifs qui ont cette taille-là,
c'est hyper compliqué, ce n'est pas dans leur culture. Et quand ils y vont, ils essaient d'y passer par l'automatisation,
en oubliant la partie culture et en se disant qu'ils peuvent y arriver tout seul. Ça, c'est un autre sujet.
Est-ce qu'ils vont être tentés d'embaucher des SRE, justement, parce qu'ils vont aller vers l'automatisation ?
C'était aussi sale, sans ce de ma question.
Je pense qu'ils vont y aller, comme ils nous ont essayés, et je l'ai vécu aussi dans le régime de ne s'y trépar.
Ils ont embauché des ingénieurs DevOps qui ont mis responsables de la scie.
Donc je pense qu'ils feront la même chose parce que la culture, la tendance et même les décideurs,
ça va être un mot-clé qui va apparaître de plus en plus, vont essayer de recruter ce type de profil.
Et peut-être ils les mettront dans une position qui sera celle de l'entreprise et qui sera pas celle de la définition même de SRE.
Ils feront peut-être de l'aluminium si ça v'ancienne, ils feront par exactement ce que la philo DevOps slash SRE que l'année.
Mais pour moi ils y viendront parce que si tu as une prod que tu tiens et que tu as besoin d'aller vite, tu as besoin de ce type d'équipe.
Après si ce sont des entreprises qui ont un rythme malgré le DevOps très avec une réaliste ou tous les 3 mois par exemple,
tu as peut-être moins besoin de personnes en charge de ce genre de choses.
Il y a moins de chances, ce n'est pas qu'il n'y en a pas.
Mais logiquement, si tu ne mets pas un jour ton application 10 fois par jour,
il y a 10 fois moins de raisons d'avoir des problèmes.
Tout à fait.
Du coup, on va rentrer un petit peu dans le quotidien de ton métier.
Qu'est-ce que tu fais finalement au jour le jour ?
C'est quoi tes tâches récurrentes dans ton métier ?
Alors je vais dire de SRE parce que c'est pas le titre officiel mais on a bien confié que c'est ça ce que tu faisais.
Tu fais quoi finalement régulièrement ?
Alors ça va vraiment dépendre.
Dépendre beaucoup de choses comme un peu la réponse universelle dans la formatique.
Normalement, un SRE, et j'essaye de me rapprocher de ça,
mais encore une fois, on n'a pas adopté à 100% ce modèle-là,
c'est d'avoir 50% du temps que tu vas régler des problèmes.
Ça veut dire que tu n'as pas de la preuve qui tombe, tu as des services où tu vois que...
Alors je vais utiliser des acronymes propres au domaine SRE,
c'est des femmes SLO et SLE, c'est nos indicateurs.
Est-ce que le système marche ?
On sait si il marche à 90%, à 99%.
Et en fait, on va passer notre temps à suivre ça
et à intervenir si ça ne marche plus pour le régler.
Et par contre, les 50 autres pourcents du temps,
on va passer notre temps à améliorer le système
pour que les 50 premiers pourcents diminuent.
Donc au final, on ait des interventions à faire plus que 30% du temps.
Et en fait, c'est se battre continuellement pour que tu en fasses le moins possible.
C'est en fait le boulot qui, par définition,
crée si la branche sur laquelle il est assis de son propre travail.
Mais si tu as tout fait, tu n'as plus rien à faire.
Après, dans la génération, on sait qu'on a toujours des choses à faire,
donc ça n'a pas de problème.
Et donc ça va vraiment être cette dualité,
c'est de régler des problèmes qui arrivent
et aussi trouver les solutions pour que ces problèmes n'arrivent plus.
Justement, en parlant d'acronyme,
je rappelle un autre auditeur, un autre auditrice.
Au moment où on enregistre le podcast, c'est pas sorti,
mais au moment où celui-ci sera publié,
le podcast sur les astreintes et la production Radio DevOps sera sorti.
On parle justement de tous ces acronymes.
Donc vous pouvez aller faire un tour sur ce podcast-là
pour avoir le vocabulaire et tout ça.
Parce qu'on parle des astreintes.
D'ailleurs, il y a eu une question qui n'était peut-être pas dans mes notes,
mais est-ce qu'un SRA, il fait des astreintes,
est-ce qu'il est possible qu'il fasse des astreintes justement ?
Il peut, dans la définition et dans le livre officiel que vous devez faire,
c'est pour décrire le « Citrus Ability Engineering »
et ils en parlent.
Après, la volonté n'est pas de cramer les personnes.
Donc ça va être vraiment dans un mode géré.
C'est-à-dire que tu ne vas pas faire ta journée standard
plus les astreintes derrière,
parce que les astreintes et les humains surtout,
on a une façon de réfléchir qui va être particulière.
Donc quand on va être fatigué,
on va être beaucoup moins attentif
et on va se dire que c'est ça la solution au problème de Prod,
et puis, à l'instant, généralement,
tu vas te baser sur les 10 derniers problèmes que tu as eu.
Peut-être que cette fois-là, c'est pas la bonne.
Donc on ne peut pas avoir des personnes qui soient errantées
en fin d'astreinte à gérer des problèmes de Prod,
si en plus ton système ramène énormément d'argent,
vaut mieux avoir des personnes fraîches pour travailler à ces moments-là.
Donc tu peux en faire.
C'est pas forcément...
J'ai toujours cette vision de la «streinte négative »
de tu fais ta journée et en plus t'enchaîne 6 heures derrière.
Pour moi, on doit au-delà de réparer dans ce modèle-là.
Clairement pas.
Pour l'avoir fait, je sais que je l'ai fait pendant 4 ans
et ça m'a laissivé.
J'ai fini par pas paraître tout le temps fatigué.
J'ai quitté la mission, mais...
Enfin, j'ai demandé à quitter la mission.
Mais non, c'est la «streinte négative »
Vu comme ça, non, il ne faut pas.
Est-ce que tu peux avoir...
Parce qu'on sait que le monde de l'infrastructure,
il est vaste, tu peux avoir l'infrastructure et du code,
tu peux avoir la configuration de ton monitoring
ou de ta supervision, etc.
Est-ce qu'il y a des spécialités chez vous?
Parce que j'imagine que vous êtes une équipe de SRE,
n'était pas tout seul.
Et est-ce qu'il y a des spécialités?
Est-ce que vous travaillez en binôme?
Est-ce que vous faites tout auquel cas vous êtes très fort?
Bravo.
Alors, et que ce soit par goût ou par compétence,
chez nous en tout cas, on ne fait pas tout tout.
C'est-à-dire qu'il y a des personnes qui vont être plus moi,
par exemple, je l'assume, je ne suis pas du tout calé
sur la partie terraformes, c'est quelque chose que je gère moins.
Je sais gérer des infrastructures,
mais pas au travers des terraformes par exemple.
Et j'ai des personnes qui savent mieux le faire que moi,
mieux l'architecturer, mieux l'organiser, mieux le coller.
Et là, au final, c'est ce sens de cette personne
qui vont plus gérer ça.
Par contre, on est continuellement en discussion
sur les travaux qu'on doit faire.
Moi, je vais être beaucoup plus de part mon passif
sur la partie Kubernetes.
Je travaille sur Kube depuis 2016.
Donc au final, j'ai un grand-monde dessus
qui me permet d'être celui qui va dire
l'application, il faut qu'elle change à ce niveau-là
parce que ça permettra de mieux fonctionner
à l'échelle quand l'application scolera
ou quoi que ce soit.
Et par contre, après, d'ailleurs, je peux demander
aux personnes qui sont un peu plus à même
sur la partie infra de gérer la création des Node.Pool,
la création des informations, les éléments qui vont gagner
qui sont en souterne pour la particule.
Donc je suis un peu consommateur et un peu celui aussi
qui va dire aux autres ce qu'on pourrait améliorer
et des fois même, je vais travailler dessus
pour moi-même, et je vais faire un petit peu tout.
Et dans l'équipe, on sait répartir les tâches.
Mais par contre, on est un peu tous capables
d'intervenir sur les tâches des autres.
Je peux modifier terraformes.
Ça ne porte mieux si je ne le fais pas,
mais si il y a besoin, je le fais.
Oui, vous partagez les connaissances, mais c'est vrai
que du coup, la spécialité, il y en a plusieurs.
Vous êtes combien dans votre équipe, par exemple?
Alors aujourd'hui, 1, 2, 3, 4, 5 avec notre Team Lead
qui est à l'immeur dans le coin bouillé,
aussi souvent que moi quasiment, donc, oui,
les monnaies de 5.
Vous gérer une grosse production?
Chez Gradle, en fait, on fournit notre service
Gradle Enterprise, que ce soit en fait,
on gère la Prod.
Pour moi, Prod, c'est tout.
Ça veut dire que l'instance qui tourne
pour les développeurs en interne pour tous les jours,
ça a la même priorité que l'instance de Prod principal
qui est sur ScalsGuardle.com
parce que, en les deux cas, s'il y a un problème,
il y a des gens qui vont être impactés.
Pour moi, ça, c'est la Prod.
Et aujourd'hui, on gère pas mal d'instances.
Oui, on doit, je pense,
on tourne d'une vingtaine d'instances de notre produit
parce qu'on donne accès à des instances gratuites
pour les projets OpelSource.
Donc, au final, un projet OpelSource y a accès.
Spray, X-Wheel, qui est plein d'autres,
on accélère ça et profitent.
Donc, il ne faut pas les impacter.
Est-ce que tu peux nous raconter
un problème de production que tu as vécu
et que tu as pu résoudre soit grâce à l'automatisation,
soit grâce aux DevOps, soit en utilisant les techniques
que tu as appris dans le métier de SRE, justement.
Alors, il y en a un très...
Je le cite souvent que je parle de l'observe d'habitité.
Pour moi, c'est vraiment un des éléments clés
de la partie SRE.
Mais pour moi, c'est qu'il faut que...
On est là quand notre système tombe,
il faut qu'on soit capable de savoir pourquoi je l'ai tombé.
Il n'est pas juste j'ai une 503, le système est bas.
Et donc l'observe d'habitité,
ça m'a aidé dans un petit vol de code,
un truc tout bête de mutabilité
d'un constructeur, d'un builder
qui avait été utilisé de méthodes concurrentes.
Donc, au final, un bug qui ne se passait que
dans certaines conditions vraiment très spécifiques.
Si ça, ça avait été géré en mode...
C'est pas péjoratif, mais admis si ça l'entienne,
ça ne marche pas,
et vous, vous, vous donnez le log,
on ne s'en serait jamais sorti.
Là, en fait, ce qu'on a permis de faire,
c'est qu'on avait, sur Google Cloud,
on avait les traces et les logs distribués.
C'est-à-dire que pour chaque requête,
on était capable de voir
où le code, dans le code,
où la requête passait
et quel bout du code a été impacté.
Grâce à cette forte observabilité,
on a pu détecter ce problème de mutabilité
et de comprendre pourquoi un système était,
en plus, encore plus visieux que ça,
il n'était pas d'ordre.
Il envoyait les données au mauvais endroit.
Pour derrière le détecter, c'était encore plus compliqué.
Et de ça, on a appris,
c'est aussi la boucle vertueuse SRE DevOps,
on a appris de ça
et ça nous a permis de donner
des nouvelles métriques de monitoring
pour vérifier que les systèmes
continuent à fonctionner correctement,
s'il y a une régression,
quoi que ce soit donc.
C'est super intéressant, merci.
Du coup, je voulais savoir
quelles études tu avais faites
et selon toi, quel type d'études
il faudrait, c'est quoi le panel d'études
pour pouvoir faire ce métier-là ?
Alors, quelle étude j'ai fait ?
Ça remonte un peu maintenant.
J'ai fait une licence d'infos
dans les années 2000,
fin des années 2000, oui,
fin des années 2000,
une licence d'informatique
suivie d'un master
qui est élevé
et était beaucoup plus liée
à la sécurité des systèmes d'information
que au baccan pure.
Mais par contre, ça m'a permis
d'avoir déjà une multi-capacité
sur cette partie-là.
Et en fait, tout le reste,
je l'ai appris par l'expertise,
par les expériences.
C'est à bâtir que tu veux tester ça,
c'est peut-être certain de diriger
pas la bonne chose,
est-ce que tu veux tester ça ?
Ouais, on va essayer.
On va voir. Peut-être que ça ne me plaira pas
et je serai capable de le dire.
Peut-être que je vais apprécier,
je vais continuer.
Mais en fait, au fur et à mesure des expériences,
je me suis spécialisé
sur ces éléments-là
et c'est même malgré moi
où je me suis rendu compte
qu'en lisant la définition
d'esthérieux et de ce que j'aime faire,
j'étais plus proche de ça
lorsque je veux faire tous les jours
que d'un simple,
que d'un développeur d'accanes plutôt
qui est juste un clément de la fiture.
C'est top.
Moi, j'adore l'adrénaline de la prod.
Sur comment le devenir,
aujourd'hui, je ne saurais pas tout.
C'est...
Pour moi, il faut avoir...
En tout cas, ce que je trouve important
et avec les personnes
avec lesquelles je travaille, c'est le cas,
c'est avoir une connaissance
sur le baccan, comment le code fonctionne,
comment ça tourne.
C'est-à-dire avoir la curiosité
d'aller voir et de vouloir trouver un bêtien.
On est passé dans telle branche de code,
ça a fait ça à tel moment
et là, ah, si il y a peut-être
cette petite chose-là
qui est peut-être à synchrone
et qui a déclenché un autre problème.
Savoir avoir ça, pour moi,
il faut avoir quand même
mon baccan de développeur,
au sens-là, je le développeur, en tout cas.
Et ensuite, avoir la conscience
et apprendre
et avoir l'amuser
en fait dans ce qu'on fait
et tester plein de choses.
Je sais que beaucoup n'ont pas
la capacité le temps
de tester des choses à la maison
parce qu'on a tous des vies
mais c'est vrai que pour découvrir,
moi, j'ai passé un temps fou
mais que j'apprécie et que j'ai choisi
à installer mon propre cluster cube
à la maison et tester des choses.
Parce que c'est en les testant,
c'est-à-dire dans des cas concrets
que j'arrive à m'en rendre compte
que ça, c'est la bonne solution.
Ce n'est pas parce que c'est le produit
en voie du moment,
c'est parce que là, ça résout un problème
qui m'est important.
Et ça, c'est vraiment par rapport
à cette question
ce que je dis généralement
aux juniors qui arrivent dans ce domaine.
C'est apprenez vraiment
les idées principales des outils
sur Kubernetes, par exemple,
apprendre la finie de l'outil
plutôt que de suite
se lancer dans le premier chart Elm.
Ça n'a aucun intérêt.
Apprenez vraiment l'outil,
apprenez la filo de ceux qui l'ont créé.
Il y a des très bons livres là-dessus,
très didactiques, pour comprendre.
Et ensuite, si vous avez compris le concept,
généralement, l'un plein,
elle va toute seule.
Donc vraiment,
ce sont plus ce genre de choses-là
qu'aujourd'hui des études
que je saurais conseiller,
plus que je n'ai pas tout le panneille
de ce qui se fait.
Je suis assez d'accord.
En plus, je vois souvent
les jeunes se jeter sur les tutos.
Et en fait, les tutos,
ça ne fait que vous tenter
de reproduire quelque chose.
Et en fait, si on ne comprend pas la logique,
c'est dur de faire des choses.
Par exemple, je conseille toujours,
au jour avec qui je travaille,
qui ont moins d'expérience,
comment on fait de l'automatisation
d'infrastructure.
C'est d'abord, dans un premier temps,
de le faire manuellement une première fois,
pour comprendre tout les trucs.
Et après, de l'automatiser,
parce qu'en plus,
tu sauras alors refaire manuellement.
Exactement.
Et ce que j'aime beaucoup chez Diclabs,
c'est que tu gardes cette impression
de cet infichier qui décrit
ce que j'aurais fait manuellement.
Très souvent, il nous est arrivé de...
On n'avait pas notre siyaïre prête.
On avait notre fichier
d'automatisation côté Diclabs.
On copiait les commandes
pour les exécuter nous-mêmes.
Et ça nous permettait de livrer
si notre instance Diclabs
était la seule en charge de faire
l'infligérisation était d'en.
Et on pouvait quand même livrer
en juste suivant
ce cahier de recette.
Exactement.
Et l'autre truc avec lequel je suis d'accord avec toi,
moi aussi finalement,
j'ai un background developer back.
Vu que j'étais proche de la machine
et je développais des démons, on sait.
Je crois qu'on ne peut pas faire plus back-end
que ça.
L'intérêt du developer back-end,
c'est qu'il est proche de la machine
où ça va s'exécuter le développeur front.
Lui, il va tourner dans un navigateur,
sauf que dans l'infrastructure
des navigateurs, on n'en gère pas vraiment.
Et en fait,
avant les concepts de développement,
la logique, l'algorithmie,
va nous pousser aussi à l'automatisation.
Et en faisant de la prod,
on va avoir des problèmes
qu'on peut résoudre avec l'automatisation.
Mais pour moi,
j'ai l'impression dans tout ce que tu me dis
et ça confirme ce dont on discutait
avec justement Ludovic
dans ce fameux épisode de podcast
sur Admin 6 DevOps.
On ne peut pas vraiment
embrasser complètement le DevOps
si on n'a pas fait plusieurs rôles
dans l'entreprise,
développeurs, exploitants, Admin 6,
pour avoir une vue périphérique
de tout le SI.
Même si,
à titre perso, j'essaie de donner
une vue périphérique du SI
à mes élèves quand je donne des cours,
ça ne remplacera jamais
l'expérience qu'ils auront en entreprise.
Tout à fait.
Et il y a des fois,
il y a des choses que tu n'imagines même pas
tant que tu n'as pas livré ton application
parce que si tu veux faire des choses
avec les serveurs, si on est généralement
liés à des problèmes à l'échelle
avec des services déployés dans le monde entier,
tu ne t'en penses pas au départ
de te dire, ah mais mon cluster cube
il dépend peut-être d'un
registre d'image qui, lui,
est dans une seule région et peut-être que
si lui tombe, ok ton cluster y marche
et si ça doit être mis à jour en même temps,
si ton service
passe à la télé et très demandé, ça va se quitter,
les résultats, bah ton registre d'image
il va pas servir et donc ton service
n'a pas marché alors que tout s'évare
sauf un truc que tu n'as pas pensé.
Donc c'est vrai que c'est l'expérience
généralement et c'est une phrase
que j'utilise souvent dans des présentations
c'est on apprend des échecs
et dans les serreux, il y a une philosophie
qui va aussi avec la logique des lobes
du post mortel. On apprend
en
faisant des erreurs et en les rédigeant.
On rédige quelque chose pour ne pas l'oublier.
Moi je suis un poisson rouge, je suis en tour de vocal
j'ai oublié ce que j'avais fait la veille.
En relisant des fois des post mortels que j'ai écrits,
je me suis dit, ah ça on s'est planté
pour ça. Donc on va l'améliorer
et au moins on aura l'information
de pourquoi on s'est planté. Qu'est-ce qu'on a fait mal au départ ?
C'est important ce que tu dis parce que moi aussi
je m'aperçois que j'ai ma mémoire qui défaille.
Alors je ne sais pas si c'est ma mémoire
qui défaille ou si c'est
aussi, parce que
je me rappelle quand j'étais plus jeune
on n'était pas inondés
d'autant d'informations, que ce soit au boulot
ou ailleurs. Mais je pense
que nos cerveaux sont sur sollicités
et que c'est pas forcément un problème
de mémoire qu'on a, mais que
juste le cerveau il n'arrive plus à suivre
et que là aujourd'hui
c'est plus possible. Et au boulot
même si on se contente que des informations du boulot
avec l'isla, avec les trucs
le nombre de technos qu'on doit gérer
ça devient compliqué en fait.
Et donc si on oublie
c'est pas grave
si on l'a marqué quelque part.
Exactement. Moi je le reconnais
quand je dis que je suis un poisson rouge
je le cultive aussi, c'est-à-dire que je préviens tout le monde.
Dites-moi quelque chose
une seule fois comme ça et ne le tracez nulle part
je l'aurais oublié par contre
faisant les choses bien pour que tout le monde
s'en rappelle, c'est important.
C'est pour ça que c'est aussi important
le ASCOD, parce que
ça écrit dans le code informatique
ce qu'on doit faire.
Et la documentation
aussi doit être dans le code.
Et pour moi la DOC
et les postmortems en font partie
et dans ma précédente mission
et là aujourd'hui on le fait mais
on démarre tout juste sur cette partie-là
tous les postmortems sont avec le code
et l'avantage c'est qu'ils sont versionnés
donc tu peux remonter à la version
du jour où tu as eu le problème
mais ça c'est inestimable.
Alors ça on ne me fait pas
typiquement pour Frogit
je pense que tu connais Frogit
mais pour l'instant
on a des fichiers markdown qu'on garde
sur un xCloud
et à chaque fois qu'on a un incident on en fait un nouveau
sauf que ça c'est
c'est bien mais bon
pour la beta en tout cas c'est bien mais
de plus en plus
je me dis on va utiliser les issues
incident de GeekLab
parce que GeekLab a sorti ça donc du coup on va utiliser
les issues incident pour garder
une trace de nos incidents
alors certes ils ne seront pas dans le code
mais ils seront dans le dépôt
je sais pas ce que tu penses de cette approche toi
j'aime beaucoup GeekLab
mais là sur ce coup je préfère encore le code
parce que quand je suis dans le flow
de mon IDE
de mon environnement de développement
où je vais avoir toutes les infos
passer d'un lien qui se trouve dans le code
dans le postmortem
un bout de code qui se trouve dans le même IDE
avec le même endroit
avec la même version du code
mais beaucoup plus intéressante que deux outils
au perso, très bien GeekLab l'est fait
ça va être en certain moment de besoin
je préfère encore me retrouver
exactement dans mon code à la date
que je veux et je peux remonter dans le temps
si je veux pour tomber sur le postmortem
qui va bien par exemple
d'accord mais du coup
ça veut dire que tu ouvres une merge
réquest à chaque incident mais que
si tu as un update de l'incident
il va falloir que tu reviennes sur
un bout de markdown qui a déjà été
fusionné d'une version
oui potentiellement dans la file sre
logiquement c'est
tu rédiges ça pendant que ton problème arrive
donc là tu peux être dans un google drive
ou quoi que ce qu'il y a d'important
qui te permet d'être collaboratif
et par contre ton postmortem
donc le truc que tu vas figer
et permettre la consultation pour les autres
va être donc, moi c'est plus dans
ce modèle là plutôt que
le fait de l'éditer
à chaque fois que tu modifias un convergule
dans le cas sorté
ok bah merci alors
j'ai une question
c'est quel conseil tu donneras à novice
donc soit un jeune qui débute
soit quelqu'un qui veut se reconvertir
qu'est ce
enfin
qu'est ce qu'il pourrait faire pour se lancer dans ce métier
alors tu l'as dit testez des trucs mais
quel autre petit truc
quel autre conseil tu pourrais donner
vraiment
je pense
sans répéter globalement ce que j'ai dit
sur expérimenter
vraiment et prendre
n'hésitez pas alors que ce sont des ressources
qui peuvent être un peu plus chers
que le simple tuto sur internet
mais les livres on a
vraiment dans notre domaine technologique
des ouvrages qui sont de très très bonne qualité
généralement édité par ceux qui ont écrit
le code que ce soit de cube
de listio pour ce jeu
sur lequel je travaille
et c'est heureux de vous c'est-à-dire
d'un jeu de Google qui ont écrit le livre
l'idée c'est la base
en fait tous les articles de blog des couves
généralement de ces choses là
donc c'est peut-être moins accessible en termes de coups
mais par contre c'est très très très important
de mon point de vue
et après ça va être hyper bateau
mais entourer vous de personnes
qui partagent des informations
c'est-à-dire que moi j'adore bosser
avec des personnes qui me vivons
qui me permettent d'apprendre et auquel
je vais pouvoir
donner et rendre ce que j'ai appris aussi
donc c'est comme ça que tu vas le mieux
monter en technologie
pour apprendre
faire ma phrase de vieux
au près du vieux singe celui qui a connu
déjà la progne et les problèmes et qui va dire non
ça ne touche pas, ça ne marche pas
et la plus importante des choses c'est
pourquoi on ne touche pas
c'est pas juste je lui fais confiance il m'a dit
touche pas à ça, regarde le post mortem qu'on a écrit
parce que peut-être que depuis on a
néguléré des choses qui sont écrits dans ce post mortem
et donc on va pouvoir changer
et ça m'est arrivé très souvent de dire ça
à des personnes plus juniors que moi
et au final, discussion m'a rendu
à néguler le système
donc vraiment pour moi apprendre à partir
des bonnes ressources
et j'en suis vraiment revenu
des tutos Hello World qui font des lignes
droites qui te présentent juste le truc
qui tournent à la fin
et avoir des personnes avec qui partager
et aujourd'hui il y a des meet-ups, il y a des confs qui reprennent
merci à période comme enceinte
plus propice, profitez vraiment
de tout ça
ça me fait penser à deux choses
alors la première, je vais forcément aller dans ton sens
sur entourez-vous
c'est pas pour rien que j'ai écrit les compagnons du DevOps
c'est pour nous entourer
il y a le compagnonnage, en plus je trouve que
cette méthode d'apprentissage
comme tu viens de le dire, trouver quelqu'un
qui nous mentor et nous-mêmes
trouver quelqu'un à mentorer parce que
ça marche aussi dans l'autre sens quand on apprend
quelque chose à quelqu'un, on renforce
ses compétences donc entourez-vous
si vous êtes dans une société
trouver un mentor interne
c'est super important
ça peut être votre manager
mais ça peut être n'importe qui
en fait quelqu'un qui a plus d'expérience que vous
et ce que tu dis
sur les bouquins, ça me fait tiquer à chaque fois
tu dis que c'est un peu plus cher
alors quand j'étais plus jeune
je réfléchissais comme ça
et puis à un moment donné dans ma vie
il y a eu un switch en fait
parce que en plus j'ai été
éditeur de bouquins
de jeux de rôle
les jeux de rôle c'est cher aussi
et donc j'ai su pourquoi est-ce que les bouquins
d'informatique étaient aussi chers
déjà ils sont vendus à peu d'exemplaires
donc pour payer les auteurs c'est serrude
mais
là où je vais revenir c'est pas
si cher que ça parce que même un bouquin
à 60 balles
si j'ai acheté des bouquins à 55€
sur docker par exemple
je veux dire on a des salaires
qui nous permettent de
nous acheter des bouquins comme ça ou d'acheter
des formations
ou je les ferais acheter par la boîte
alors oui j'allais y venir ou de les faire acheter par la boîte
mais même sans ça
nos salaires nous permettent même
d'acheter des bouquins ou de nous acheter des formations
mais le plus important
votre boîte
elle y pense peut-être pas
mais vous pouvez très bien aller voir la boîte
et lui dire bah ouais y a ce bouquin qui est super intéressant
il coûte 50€
honnêtement
moi en tant que employeur
mon employé vient me voir et me dit
y a ce bouquin qui a l'air super il coûte 50€
et l'employé qui me dit
y a cette formation qui a l'air très bien
elle coûte 3500€ parce que c'est ça
le prix des formations dans la tech
je vais dire bah ok le bouquin
vas-y achète-le
la formation
attend on va en discuter un petit peu avant parce que
ou même une formation
par internet qui coûte 200, 300, 400€
ça reste encore
largement
achetable par une société
donc demandez à vos sociétés
mais aussi si vous avez des salaires
à 3000, 4000€
honnêtement
vous en pêchez pas
d'apprendre si vous avez envie
pour te donner le feedback
soit des juniors
qui je donne ce conseil et ce pourquoi
je teinte un peu en disant que parfois c'est un peu cher
c'est que j'ai vu
des juniors donc
embaucher à des salaires assez bas
vraiment
en notre domaine à tendance à monter maintenant
mais avec des salaires qui à l'époque étaient pas très vaux
et qui en plus me disaient bah c'est top
je vais acheter ce livre là, il est dans 6 mois
il y a la nouvelle version du frayement
recul de la ligne, du machin
du truc qui sera sorti
si le temps que je finisse le livre peut-être que ça s'y appliquera plus
et c'est là où il faut faire comme une attention
dans ces choix, oui
sur quelque chose qui est extrêmement mauvais
mais c'est le temps, c'est peut-être pas le livre
qui va vous permettre de tout apprendre
mais sur des éléments qui commencent à être fondateurs pour votre boulot
je les cite Kubernetes encore
mais si vous l'utilisez
généralement vous n'êtes pas sur la dernière version
et ce genre d'outils ils évident de tout l'été
d'une version à l'autre donc vous pouvez investir
mais c'est vrai que
j'ai eu le cas avec des personnes qui disaient
mais c'est trop cher
je ne peux pas me permettre ce genre de choses
et je les redirigeais généralement vers mon surprise
et en rationalisant que
parfois si votre boss refuse
le temps qu'il a mis à écrire le mail de refus
c'est le prix du bouquin dans son salaire
donc au final
s'il n'y a pas de discussion, des fois ça coûte moins cher
Exactement, alors moi je fais partie de ces gens
qui ont commencé avec des bassaires
parce que moi j'ai commencé avec un BTS
alors j'ai commencé à 8000 francs
c'était des francs
alors 8000 francs je ne sais pas combien ça fait d'euros
mais bon c'est pas beaucoup
en 2000
un peu avant 2000
et en effet comme tu le dis
ça vaut pas le prix du bouquin
le temps que la personne a mis à écrire
non honnêtement un bouquin à 50 euros
même moi je dis
enfin je veux dire à nos salariés je leur dis
voilà vous avez un budget de 50 euros par mois
si vous voulez, si vous avez envie de vous acheter des trucs
allez-y, ne me demandez pas surtout
parce que mon temps est plus précieux que ça
si eux ils estiment
qu'ils doivent acheter un bouquin
à 50 euros, ils le font
et surtout
Excuse moi, il y avait une présentation très bien
qui a été fait par des personnes de l'une attaque
il y a quelques années
elle les trouve là sur Youtube qui explique
dans notre domaine, les devs, on a cette volonté
de toujours optimiser les choses
et on va optimiser aussi
les coûts
et au final on a toujours
en comparaison le tuto qui est disponible gratuitement
sur internet vers ce que le prix du bouquin
et donc les devs
quand un devs te demande un livre
c'est peut-être une généralité
c'est qu'il en a besoin
c'est à dire qu'il va pas te créer, laissez-lui la carte bleue
il va pas te la cramer en ayant acheté tout le
le ralsec mais plus de plateforme qui est dix
toutes les udmi et compagnie
généralement il va choisir
en faisant attention
donc pour moi c'est
et côté Gradle on a
ce qu'on appelle pareil une bourse
pour l'Armigaine Development
dédié à ça et vous pouvez l'utiliser
pour livrer, reformer
sur une autre certaine
bon ben on va avancer un petit peu
d'après toi, quel type
d'évolution on peut avoir au métier
je parle pas de l'évolution du métier lui-même
mais quelqu'un qui fait ce métier, s'il veut évoluer
dans sa carrière, qu'est-ce qu'il peut faire
après plusieurs années d'expérience
est-ce que t'en as déjà une idée ou pas
ben là clairement, j'en veux
aucune idée, c'est pour moi
en fait, je suis très ancré dans la tech
donc je sais que certains
c'est de devenir chef de l'équipe
et ce genre de choses
devenir chef ou faire 1, 2
c'est pas dans notre tripe
donc c'est vrai que pour moi l'évolution
c'est l'évolution par la responsabilité de ce que tu vas gérer
au sens technologique du terme
c'est-à-dire que ton service
c'est plus un élément qui tourne
comme ça, tu vas être dans l'équipe
assez heureux de celui
de l'élément qui va représenter
plus d'importance pour l'entreprise
qui va être plus critique à tous les niveaux
même les employés à travers le monde
donc vraiment pour moi c'est plus
ce côté là, j'ai aucune idée de
ce que je ferai dans 5 ans
déjà qu'il y a 5 ans j'avais du mal à définir
que j'aimais ce métier là
dans 5 ans ou plus loin
qu'est-ce qu'on peut faire, malheureusement
je ne peux pas te répondre
c'est pas grave
écoute
je vais te poser une autre question
qui est un petit peu en rapport mais est-ce que tu penses
qu'il peut y avoir des SRE frilances
ou est-ce que c'est un petit peu antinomique
j'ai beaucoup réfléchi
surtout quand je me suis posé la question
de est-ce que je voulais faire
passer côté frilances
je pense que certains frilances
qui s'étentent assez heureux te disent
oui forcément, ils vont défendre le truc
moi je trouve que c'est bizarre
effectivement parce que
déjà ça ne peut pas marcher sur une mission courte
ou alors tu vas juste prodiguer la bonne parole
disant si, si, si, si, ça
mais pour moi c'est vraiment un voire
quand t'es assez heureux c'est
avoir la connaissance sur le système
sur comment on fonctionne dans la boîte
sur ce qu'on veut faire vers où on veut aller aussi
parce que tu vas pas régler les problèmes de la même manière
et savoir
qu'est-ce qui est critique, qu'est-ce qui est le cas
situé de passage
sur une mission courte
moi ça c'est
compliqué
moi en lien long terme je trouve qu'en fait
t'es quasiment un frilance employé de la boîte
avec juste un titre différent
et pour moi il faut être vraiment impliqué
dans le système pour pouvoir
être assez heureux, c'est bon
je partage un peu
ton point de vue
parce que selon moi
d'après ce que tu m'as dit
le SRE il doit quand même
avoir
un objectif qui est aligné
avec celui de la boîte
et donc s'il n'a pas des intérêts alignés
parce qu'un frilance il a sa boîte
son client, ses intérêts ils sont pas forcément alignés
avec ceux de son client
je pense qu'il y a un petit truc
mais je pense qu'il peut y avoir
des formateurs de SRE
des conseils de SRE, des mentors
de SRE qui sait, peut-être
ça peut être la réponse
c'est la question précédente, c'est qu'est-ce que tu fais après
tu peux former les études assez heureux
et ce genre de choses
oui apporter un petit peu d'huile
les faire évoluer etc
c'est un peu fait
on en a un peu parlé
mais d'après toi
c'est quoi finalement la différence
entre
l'admin 6 cloud devops
et le SRE
est-ce qu'il y a une différence ou est-ce que c'est la même chose
l'admin 6 cloud devops
peut-être le numéro de version
c'est quasiment ça
puisque je l'ai décrit que le SRE
c'est peut-être le admin 6 2.0
là-dessus
c'est vrai que j'ai regardé la définition
et quand tu mets
admin 6 cloud devops
on semble c'est
la seule différence peut-être
être au niveau de la partie comment on va gérer
et réagir
à un problème
si on met vraiment le terme admin 6
tu ne vas pas utiliser
les éléments de la tech
au sens développement
et toutes les bonnes pratiques de développement
au service de ton fonctionnement
et si il y a devops qui peut dire l'inverse
donc pour moi ça reste vraiment très proche
et je pense qu'on peut même être sur un synone
mais j'aurais du mal à utiliser admin 6 cloud devops
dans une phrase de toute façon
oui parce que tu es soit admin cloud devops
soit admin 6 devops
sauf que
quand tu fais de l'administration cloud
souvent tu fais l'administration système
je me posais la question
avant de discuter avec toi justement c'était quoi la différence
entre les deux et j'ai vraiment
l'impression que resserrose c'est le terme
pour tout ça en fait
ça peut et après tu vas aussi avoir beaucoup
et peut-être que ça le fera
ça les peut-être moins dans admin cloud
6 devops
c'est cette capacité à donner du feedback
aux équipes
de devs pour améliorer le système
et même participer à cette amélioration continue
alors encore une fois
mais sur la continuation de la formation devops
donc ça peut en faire partie
mais je vais tendance à dire que dans cette file OSRE
tu vas avoir beaucoup plus ce genre de choses
c'est ce que j'allais dire
pour moi je colle devops
pour moi c'est un adjectif que je colle au métier
pour montrer comment on fait ce métier
et du coup quand tu colles devops
c'est admiration continue etc
eh bah écoute on arrive vers la fin de ce podcast
je vais te demander si tu as une ressource
un livre, un article
une conférence à conseiller alors
s'il te plaît ne conseille pas le livre OSRE
de google parce que de toute façon je le mettrais
en lien
je mettrai le site de OSRE de google
mais si tu as autre chose de moins évident
à nous partager
ou même un blog je ne sais pas
vraiment pour moi c'est une bible
ce beau qu'un de google
en fait s'il y en a 3
des fois les gens oublient qu'il y a deux autres
donc potentiellement les deux autres sites
qui sont des cas appliqués
sur la version web
qui vont pouvoir même être rendus de voir
ok, il y a cette situation comment on réagit, comment on gère
ça c'est vraiment top et ils ont sorti une nouvelle
édition qui a impruit la sécurité
donc ça aussi ça peut être très intéressant
parce que il faut bien me lére tout ça
quand on délivre en proche
il faut que notre système s'en conduise plus vite qu'on conduise moins sécurire
hormis ça
moi je travaille énormément dans le monde du cloud
et de Kubernetes
donc je voudrais tendance à conseiller
le livre
de base sur kubu qui est Kubernetes Yardway
de KLC et Toer
qui fait partie de ceux qui
ont pensé et fait à la base
et qui
va vraiment apprendre les concepts
pour pouvoir faire correctement dans le système
donc
une ressource ne pouvant pas citer le bouquin
et ses roches quand on est plutôt le Kubernetes Yardway
il va bien se compléter
je vais très des liens en description
si
les auditrices et auditeurs veulent
discuter avec toi
ou est-ce qu'ils te retrouvent je sais que t'as un twitter
qu'on échange beaucoup et à l'une
que dînes est-ce que tu veux que je mette les deux
un seul d'autres choses
partout
vous trouvez d'avent Kevin tout accroché
vous pouvez me contacter non twitter
leuikdine j'ai un blog sur dev2
je fais pas mal de contes
et après de tout à temps je suis disponible
si vous voulez je suis sur twitter par mail
ou quoi que ce soit des questions je réponds
volontiers donc aucun problème
et ben écoute merci pour ta participation
à ce témoignage on en a appris
un peu plus sur le SRE
et je sais pas si toi
tu fais partie des compagnons du dev2
si tu t'es inscrit
sur cette partie-là je ne pense pas
mettre inscrit là ça m'entend tout le monde
et ben écoute si tu cherches à échanger en tout cas
si toi cher auditeur tu cherches à échanger je te l'ai dit
en introduction mais tu peux nous rejoindre
sur les compagnons et on discutera justement
des métiers puisque avec ce podcast
sur un sujet
sur le forum on va discuter justement
des métiers et ben je te remercie
de ta participation et en tout cas
je te dis à très bientôt
merci pour la invitation
mylittleteam m'a proposé
de créer un job board avec eux
et comme j'aime leur façon de faire
je leur ai dit oui
alors si tu cherches un job
fais très attention à ce que je vais te dire
ce job board me permet
de te proposer des équipes que j'ai
présélectionnées sur recommandations
de mylittle team
en effet elles ont une culture
qui te permettra de t'épanouir
et tu sais à quel point la culture est importante
pour moi
passé par mon job board c'est aussi
pour toi l'assurance d'être accompagné
par mylittle team dans ton parcours
de recrutement
et en plus tu me soutiens
car ce job board me permet de gagner
de l'argent et donc de financer
les podcasts que tu aimes tant
donc rendez vous
sur vue.fr
slash jobboard-devops
mais sinon
tu trouveras le lien en description
attends
si tu es manager, DSI
ou directeur d'entreprise
et que tu cherches à recruter
des personnes qui sont intéressées par le DevOps
tu leur as compris puisque
t'écoutes ce podcast c'est l'endroit idéal
n'hésite pas
à déposer tes offres d'emploi sur mon job board
c'est sur vue.fr
slash jobboard-devops-recrutes
mais
c'est pas grave le lien est aussi
en description
tu peux aussi le partager
ça nous aidera à le diffuser et à rendre le mouvement
plus visible
si tu as envie de discuter du mouvement
alors rejoins nous dans la communauté
des compagnons du DevOps
à bientôt
la baladeau diffusion des compagnons du DevOps
est produite par l'Hydra