Dev Ops Le magazine et observatoire du Dev Ops
Bonjour à toutes et à tous, Dev Admin 6, Dev Ops, ça sert au testeur intégrateur de
tout bord, de tout lieu, de toute culture et de toutes opinions.
Bienvenue dans un podcast que l'on espère bienveillant et varié.
Aujourd'hui, même équipe qu'à la dernière fois, promis, on essaiera de faire un effort
avec un peu plus de diversité.
Alors, à ma gauche, on a Victor.
Salut.
En face de moi, on a Bartelémy.
Hello.
Et à ma droite, on a Marc.
Bonjour.
Alors, aujourd'hui, on va faire un peu différent de la dernière fois, mais promis, on va faire
au mieux.
Alors, Dev Ops, saison 1, épisode 2, c'est parti.
Au programme, et pour toi, c'est quoi le Dev Ops ? On aura le cube, qu'est-ce que c'est ?
On aura l'ASLA, on aura Doiton Tout Automatisé et enfin, les risques du Dev Ops.
On est partis avec toi, Victor, pour une définition du Dev Ops et toi, qu'est-ce que
c'est ? Ok.
Alors, pour moi, le Dev Ops, c'est avant tout créer une culture de collaboration à travers
tous les silos dans une organisation.
Historiquement, il s'agit bien entendu des silos, développement et opération qui partageaient
que peu d'intérêt et de compétences en commun jusqu'à il n'y a pas si longtemps,
générant par la même occasion énormément de frictions au quotidien.
En améliorant la collaboration entre ces silos historiques, le Dev Ops tend à réduire
la frustration et le rejet de la faute sur l'organisation ou la personne.
Tout en améliorant les résultats liés au business et en rendant la tâche plus facile
au développement et à l'opération pour mener à bien leurs intérêts communs.
Si vous ne devez retenir qu'une chose, retenez donc le terme collaboration et donnez-vous
comme mission de l'appliquer en toute cirquantance et sans a priori négatif et vous verrez que
ça peut tout changer.
Il faut noter aussi que ce concept peut être rendu à d'autres silos historiques comme
par exemple le business ou la sécurité.
On parlera alors de Bees Ops ou Sec Ops.
Super, donc définition concise.
Voilà, assez court.
Voilà, alors on va essayer de garder cette chronique à chaque fois pour que vous ayez
en permanence des définitions différentes et que vous arriviez à appréhender un peu
mieux l'esprit du Dev Ops.
Donc maintenant on va passer à une partie débat que je vais introduire avec Kubernetes.
Je vais vous présenter un peu Kubernetes et après on va pouvoir en discuter tous ensemble
pour voir un peu les différentes avis sur la question.
Donc Kubernetes ou QTS ou Qube, alors de quoi parle-on ? Déjà un bref historique.
Le premier jour, l'informatique créale monolithe, simple et efficace.
Le second jour ébloui par les bases de données, l'informatique créale et architecture 3
tiers.
Le troisième jour, l'accès de voir son service tomber, l'informatique créale et
cluster.
Le quatrième jour, débordé par les opérations manuelles, l'informatique créale et l'automatisation.
Le cinquième jour, dépassé par le nombre de machines, l'informatique créale et ordonnanceur
et de nouveaux nuages.
Le sixième jour, l'accès par la programmation au objet et l'informatique créale et microservice.
Enfin, le septième jour, pour se reposer ne plus avoir à se faire réveiller par les
astreintes, l'informatique créale Kubernetes.
Alors Kubernetes, c'est un projet qui a été initié mi-2014 par des ingénieurs de Google
qui travaillait eux en interne sur Borg, l'orchestrateur maison.
Le nom original de Kubernetes est en interne au projet 7, en référence au personnage
de Star Trek qui est un Borg devenu amical.
La version 1.0 sans juillet 2015 et le projet est dit dogmatique.
Les briques de base sont posées, pod, label, service, contrôleur et surtout API First.
Pourquoi je l'en parle aujourd'hui ?
C'est vu les actualités récentes.
En fait, on a vu que tous les derniers projets qui s'étaient créés ces dernières années
maintenant rejoignent un peu la sœur Kubernetes.
On a eu l'annonce très récente de Docker qui a décidé vraiment d'embrasser Kubernetes
de manière plané entière, c'est-à-dire qu'ils vont garder Swarm mais aussi avoir une compadibilité
cube.
On a depuis très longtemps OpenShift 3 qui est passée en coussoujassante à cube.
En fait, on l'a vu dans un peu partout.
On a K-Nonicol maintenant qui travaille dessus, qui fait pas mal d'interventions pour que
toutes leurs solutions soient compatibles.
C'est vraiment pour placer un peu le contexte.
Je ne sais pas si quelqu'un veut parler de son utilisation ou si en tout cas on veut
parler de la main-mise de cube qui peut avoir sur l'industrie à l'heure actuelle dans notre
secteur.
J'ai une question pour toi.
Tu as parlé un peu de cube, de son historique, tout ça.
Mais qu'est-ce qui pour toi fait que cube a vraiment pris autant d'importance et
surpasse d'autres projets qu'on pourrait qualifier de similaires qui existaient avant
cube ?
Déjà, les projets similaires, on pourrait noter pour information Swarm, Mesa ou Nomad,
par exemple.
Je suis sûr qu'il y en a encore plein d'autres.
Cube, à mon avis, ce qui a fait sa force, c'est un peu ce que je dis, c'est que c'est
un projet très dogmatique.
C'est-à-dire qu'en fait, dès le début, quand on arrive dans une architecture cube,
on sert un peu l'or où on met les pieds.
C'est-à-dire que tout se ressemble beaucoup et donc il y a une grosse notion de rejeux
possible.
Ce qui était la force de Dockers, par exemple, à la base, c'était de se dire qu'un conteneur
qui tourne sur une machine tournera ailleurs.
Avec Cube, on a un peu la même chose.
C'est-à-dire que quand on arrive sur une infra cube, on peut avoir une rejouabilité
des scénarios possibles.
Je trouve que c'est ça, en fait.
Et ça, c'est dû, à mon sens, à la notion d'API très forte et de composants qui sont
très maturs.
Par exemple, la forme de Pod est une forme qui maintenant a pris son essor dans les
autres framors, mais Zeus, par exemple, l'a ajouté pas très récemment, mais récemment.
Donc, en fait, c'était cette force-là d'avoir quelque chose qui était dès le début avec
une vraie vision qui a pu bien normer les choses, en fait, à mon sens.
Moi, je n'ai pas une grande expérience du Kubernetes.
Je vais être amené à en faire de plus en plus de mon métier.
Pour moi, oui, Kubernetes, c'est vraiment ce qui va un petit peu cristalliser tous
les forts des containers et ce qui a vraiment été initié par Docker il y a trois, quatre
ans maintenant.
J'aurais vraiment tendance à dire qu'ils ont gagné la guerre entre guillemets des
schedulers, des orchestrateurs.
Mais pour le coup, c'est pas comme en finir cette phrase, désolé.
OK, il n'y a pas de problème.
T'as expliqué l'origine de Kubernetes.
T'as expliqué que tout le monde faisait du Kubernetes, qu'il y avait un mouvement
global de convergence vers cette solution technique.
Mais t'as pas vraiment exprimé en quoi, qu'est-ce que proposait en plus cet API
là par rapport à d'autres APIs qui pouvaient préexister, notamment, je ne sais pas, les
APIs de Mesos ou les APIs Docker ou les APIs proposées par Hicorp.
Je n'ai pas saisi, alors moi non plus, je n'ai pas une énorme expérience de
cube.
Cela dit, je suis un fervent convaincu, enfin je suis un fervent convaincu, mais je ne
pense pas que nos auditeurs, ils aient bien saisi la profondeur de la solution.
Donc est-ce que tu peux développer un peu plus ce point là ?
C'était la question que j'attendais.
Alors oui, en effet, alors Kubernetes, déjà, c'est vraiment quelque chose qui existait
depuis longtemps, parce que je l'ai même dit dès le cinquième jour, on avait déjà
le droit à des ordres de lanceurs typiquement dû Amazon, ou on allait demander à avoir
des infras.
En fait, cube, ce que ça va permettre, c'est vraiment d'avoir la notion totale de cycle
de vie d'un produit.
C'est-à-dire là, on est plus au niveau d'une machine, comme pouvait faire avant les ordres
de lanceurs du type Amazon, on demandait à faire bouter une machine, qui après faisait
ce qu'on avait décidé que c'est en face.
Là, ici avec cube, on va réussir à faire des notions de...
En fait, c'est un patchwork de tout ce qui a été fait avant.
C'est-à-dire, par exemple, un pod, en fait, c'est la décomposition la plus minimale
d'une instance, en fait, de quelque chose qui va travailler et qui va faire un besoin.
Ça va être un assemblage de plusieurs containers.
Container, sachant qu'il faut le voir à la vision Docker, c'est-à-dire un container,
c'est une application mise dans un contexte.
C'est un peu une évolution de tout ce qu'on va voir avant avec le vendeurine.
Là, on a vraiment quelque chose qui est dans le pod.
On va pouvoir associer ensemble des composants, un peu comme une architecture
3 tiers, mais vraiment, bonne lelizé, c'est l'application peut être liée à un proxy,
peut être liée à une autre base de données si jamais ça devient cohérent.
C'est-à-dire, si jamais il n'y a pas besoin de resondances, il faut voir.
Voilà, on peut tout faire avec un pod, il faut pas tout faire.
Mais donc, on a cette unité de base et après cette unité de base-là, on va pouvoir après
dire à Kubernetes d'aller généraliser aussi bien la scale en,
mais pas obligatoirement, il peut aussi juste sur un monitoring dessus et aller la reproduire ailleurs.
En fait, ça, c'est des choses qu'on avait déjà vues avant dans Meso,
c'est dans plein d'autres frameworks, comme je dis avant.
Ce qui est la force en mode cube, c'est d'abord la simplicité,
c'est-à-dire d'avoir des éléments de base qu'on va pouvoir combiner les uns avec les autres.
Il y a une notion aussi très forte là pour le coup qui vient de l'expérience de Google,
qui est la notion des labels, c'est-à-dire pour aller pointer sur un service.
Ce service va présenter des labels et on va pouvoir, au lieu de faire quelque chose de très déclaratif,
enfin, au lieu d'aller pointer explicitement sur quelque chose, on va faire du déclaratif.
C'est-à-dire, on va aller un service expose comme faisant partie d'un label et on va pouvoir aller pointer dessus.
Donc en fait, vraiment, c'est pour ça que je disais que c'est vraiment le septième jour qu'on invente cube.
Cube réunit un peu toutes ces notions d'ordonnanceurs,
prend à bras le corps la notion des microservices, c'est-à-dire que tous les services peuvent communiquer entre eux via des labels.
Ça va permettre aussi, ça, c'était une discussion qu'on avait dans la précédente émission,
tout ce qui était l'AB testing et le Bluegrind deployment.
En fait, avec Cube, avec cette notion de label-là, on va pouvoir avoir vraiment une granularité forte.
Sachant que vraiment, ça prend du début de cycle de vie du produit,
ça veut dire, enfin, pas du développement forcément, mais en mise en prod.
C'est-à-dire comment on met en prod, mais aussi comment on maintient et aussi comment on y accède via des ingresses,
c'est-à-dire qu'on définit les moyens d'accès à son application.
Donc, et tout ça, et c'est ça qui est très fort, c'est que, en plus, c'est, comme je disais, dogmatique,
dans le sens où tout passe par une API, mais ils ne sont pas aussi dogmatiques qu'on pourrait le croire,
c'est que les implementations après, elles sont libres et plogables.
C'est-à-dire que demain, si quelqu'un pense que l'orchestrateur de inclus d'Encubernétie ce n'est pas bon,
il peut très bien le remplacer et le remplacer par un autre.
Voilà, je ne sais pas si ça répond à ta question.
Oh oui, oui, oui.
Est-ce que tu peux... tu parlais d'API ?
Est-ce que tu peux donner des exemples qui...
Enfin, notamment sur le cycle de vie,
parce que t'as parlé de pod, de capacité, en fait, je vais presque dire statique,
mais bon, on est très loin du statique, de l'aspect statique,
mais dans la gestion du cycle de vie, de ce qui est possible de faire avec les primitives standards de Kubernetes.
Alors, les primitives standards sont assez basiques, les primitives de base,
comme je disais, c'était Pod Service et des contrôleurs,
et encore des contrôleurs simples à la base dans la version 1.0.
En fait, une fois qu'on a ces primitives-là,
ils ont été ajoutés aussi bien par la communauté ou dans le projet en lui-même,
des primitives un peu plus compliqués.
Par exemple, à la base, on avait les replication de contrôleurs,
cette primitive de base toujours définie via une API,
permettant de dire « je veux X instances de tel pod ».
Et si jamais une tombe, l'autre, une nouvelle est remplacée.
Un problème qui s'est posé, c'était de savoir comment on remplace ces pods-là.
C'est-à-dire comment on déploie une nouvelle version.
À la base, c'était fait côté client,
c'est-à-dire en jouant sur deux replication contrôleurs
qu'on crée, une à une version 1 et une à une version 2,
et on faisait baisser d'un côté, on faisait augmenter de l'autre,
comme on avait la notion de label,
devant les frontaux qui envoyaient le trafic,
ne voyaient qu'une seule application.
C'était en interne pour Cube, que c'était différent.
Maintenant, on a la notion de deployment qui existe,
c'est-à-dire que vraiment, dans la notion de deployment,
on garde une version de chaque application,
et c'est le cluster en lui-même qui gère la migration
via des temporisations, via plein de choses
qu'on peut avoir et même rajouter.
Ça, c'est des primitives de base,
mais on peut même voir encore des choses encore plus élevées,
et ça, c'est la communauté qui a commencé à en faire.
C'est toute la notion de contrôleur maintenant,
et d'opérateur plutôt dans une notion CoreOS,
qui est vraiment de contrôler une base de données.
Ce qui était compliqué avant, dans Cube,
puisque ces primitives de base de pods ne permettent pas de faire du stateful,
c'était peut-être ça ce que tu disais.
C'est éloigné, mais c'est vrai que j'y pensais.
C'était assez compliqué de faire du stateful en Cube de base
avec cette notion de pod,
et de choses vraiment très conteneurs.
On entend encore partout des gens qui disent
« Mes data-bases, je ne les mets pas dans des conteneurs,
ou dans d'au cœur, etc. ».
Là, en fait, avec les notions d'opérateur,
c'est qu'on a un logiciel qui va connaître la base de données
et va permettre de la gérer de manière propre.
On a un CoreOS par défaut créé,
qui est celui d'Oticity,
qui permet de gérer un cluster Oticity
en le déclarant vraiment en format API,
comme n'importe quelle autre ressource Kubernetes,
et de lui mettre des contraintes de taille de cluster.
Et après, c'est l'opérateur qui va se charger
d'aller sponner les pods,
d'aller vérifier la réplication entre les différentes instances,
et de gérer vraiment le cluster en totalité.
Voir même, il est capable de gérer les backup
et les reprises sur backup.
On est presque sur des SAS,
on est sur du juju, on est sur des choses
où on va demander une brie,
qu'on va demander à la pays,
« donne-moi une base de données MySQL »
en lui disant juste « component de points MySQL ».
Exactement.
Et c'est ça un peu la force peut-être de Kubernetes,
c'est d'avoir pris le problème par le bon côté.
C'est-à-dire, en ayant répondu d'abord
aux problématiques sous-jacentes,
les problématiques de comment on se ponde un conteneur
et comment ça marche bien
et comment on peut avoir confiance dans ce comportement-là.
Deçus après, on a été créé pas mal de choses
qui vont revenir par-dessus.
On a même Rook par exemple,
qui est un logiciel qui existe
pour déployer un CEPH simplement
sur un cluster cube.
C'est-à-dire que vraiment,
CEPH qui était pourtant un logiciel
et je suis bien placé pour le connaître.
Difficile à installer parce que multi-composants,
parce qu'avec besoin d'avoir des clés partagés, etc.
Là, on a un logiciel qui est au-dessus,
un opérateur qui permet de faire ces choses-là.
C'est-à-dire que lui,
à la connaissance du logiciel
et par contre que d'un logiciel en particulier.
Voilà.
Je vais peut-être prendre...
Là, ça y est, j'enfile mes habits d'avocats du diable,
installer une base de données,
installer un CEPH, installer plein de choses,
faire des backups, gérer le lifecycle.
C'est compliqué.
Donc ça l'a été,
ça le sera toujours.
Elle est où la complexité dans Kubernetes ?
Qu'est-ce qui va être compliqué de faire
avec Kubernetes ?
Parce que dans tous les cas,
il y a un travail qu'il faudra faire.
C'est quoi le...
Quel est le piège ?
Le piège, en mon avis,
c'est quelque chose aussi dont je parlais.
C'était ce qu'on appelait avant le cloud ready
ou la claudification des applications.
En fait, en mon avis,
il y a des applications qui ne seront jamais prévues
pour être prévues dans le cube.
On l'a vu par exemple,
dans Prometheus,
pourtant un projet fait en partie du CNCF.
On a vu que là,
dans la version 2.0,
qui sont en train de créer,
en fait, le storage est complètement adapté à cube.
C'est-à-dire qu'ils ont repensé leur application
et la façon ontistique à les donner
en sachant que derrière les prémitifs sous-jacents
allaient être différentes.
On l'a vu par exemple,
dans un projet comme Vitesse,
qui est donc une base de données
créée par YouTube,
qui a comme...
comme principe sous-jacent,
le fait qu'ils allaient être sur Kubernetes
c'est qu'ils allaient avoir
une sorte d'opérateur.
Et donc en fait,
c'est du MySQL,
mais complètement remanié
en pensant à Kubernetes par défaut.
C'est-à-dire que je ne pense pas
que demain on pourra faire passer
des applications historiques
sur un cluster compliqué,
Galera par exemple,
de manière simple sur un Kubernetes.
Je pense qu'il faut
qu'il faut que ça se pense en fait en amont.
Par contre, de mettre une application simple,
un MySQL simple,
sur Kubernetes avec un volume de stockage
distribué par exemple,
ça ne me paraît pas très compliqué.
Mais voilà, on va avoir en fait
cette espèce de transition à l'heure actuelle.
C'est collé d'avoir tous nos os dans le même panier
où on gérait de la même façon
des bases à plusieurs...
Enfin, très très gros,
c'est des bases pour un petit projet.
Là, on aura vraiment
une différenciation des choses
et je pense, bah pour le coup,
c'est vraiment le rôle du DevOps.
Il va y avoir un shift culturel
et je pense qu'il y a quand même
des gens qui ne feront pas le shift.
Donc, la stratégie de passer
par un orchestrateur
et la stratégie de ne pas y passer
vont cohabiter pendant...
Ah mais comme aujourd'hui,
des gens ne veulent toujours pas faire du cloud.
C'est toujours cette logique-là.
Je pense qu'on aura toujours
ces gens qui sont perdues,
mais là, à l'heure actuelle,
vu l'importance qu'après CUBE,
ça va être compliqué
pour pas mal de projets
de pas y passer.
C'est bon, mais...
C'est un truc de sujet.
Mais comme tu dis,
il y a des efforts à faire
des deux côtés au final.
Aussi bien du côté de CUBE
pour avoir peut-être plus de primitives,
pour avoir plus de cas d'usage.
Et du côté des projets
qui veulent se mettre sur CUBE
pour qu'ils...
J'y pense.
...t'utilisent ces primitives.
Je pense pas,
parce que justement,
le but de vraiment de CUBE,
c'est d'avoir un projet d'idogmatique,
c'est-à-dire vraiment
d'avoir quelque chose qui fonctionne
et de ne pas faire
vraiment de transigence là-dessus,
d'avoir des primitives fortes.
Et après,
t'y passes ou t'y passes,
après, il y a pas d'obligation là-dedans.
Mais si les autres ont réussi
à y passer,
il y a peu de chance que...
Enfin, que tu n'y arrêtes pas.
On peut rappeler quand même
que CUBE, c'est le premier
projet open source,
CUBE,
et celui qui drive...
Mais celui qui a la plus grosse communauté...
...le plus grosse communauté au entier.
...le premier projet open source.
Oui.
Sur GitHub.
Super.
Je pense qu'on a fait le tour.
Je pense que de toute façon,
ça reviendra.
On le voit là,
que c'est un projet qui prend l'importance.
Donc, on aura l'occasion
de reparler dans d'autres émissions.
Maintenant, on va passer
un sujet à SLA,
qui ressemble un peu,
au final,
un peu à ce que j'ai dit,
puisqu'il y a notion d'EPI, etc.
Mais on va laisser Victor en parler.
Et avant ça,
je vais te poser une petite question.
On a avec nous le trivial poursuite-édition DevOps.
Alors,
que signifie l'acronyme anglais
jit ?
J-I-T.
Ah merde,
à la question à la con.
Je pense...
Utilise tellement que j'avoue
que je m'en souviens pas.
C'est Justin Time ?
Justin Time,
exactement.
Je pensais à GIT.
Je pensais à GIT.
Ah putain.
Je pensais à Git.
Non, non, Git.
T'as dit J-I-T dans ma tête.
Je sais pas pourquoi.
C'était G-I-T.
Mais merde, ça me dit...
Je suis chiant,
on va avoir des accords.
J-I-T, c'est là pour Java, non ?
Voilà.
Tu en as un en Java script,
si tu l'as.
Bon, même pas un fail en aucun usage.
Bon, alors Victor,
on te laisse la parole
pour nous présenter un peu SLA,
et comme ça après on pourra
en débattre.
Ok, c'est parti.
Alors, ferme les yeux,
et souvenez-vous,
souvenez-vous de cette époque
où le monitoring était l'affaire
des 6 admins
et la dernière chose à laquelle
on pensait lors de la mise en place
d'un nouveau projet.
On se disait alors
qu'il suffisait, comme à chaque fois,
de mettre en place des checks
sur le CPU, la mémoire, le disque,
ou tout autre composant
dû ou des serveurs sur lesquels
tourne notre application
pour savoir quand il fallait agir.
En cas de dépassement d'un seuil fixé
à l'avance par un gros doigt
bien mouillé
sur ce bon vieux Nagios,
ou Nagios,
on alertait alors notre cher admin
d'Astrint
qui se ferait certainement une joie
de se connecter en ssdh
ou en remote console
à 2h du mat sur un serveur
pour lancer un Hatchtop
par ses délogues à base de grève
et tenter de trouver une réponse
à la question.
Mais pourquoi mon serveur
est-il monté à 80% de CPU
alors que d'habitude
il n'est qu'à 60% ?
Une fois le problème résolu
qui consiste en général
à faire un service restart,
notre ami préféré
pouvait alors se rendre dormir
et retourner à ses dourèves
de serveur
avec 10 000 cores
et 50 terra-drammes.
Mais pendant tout ce temps,
le service rendu
était-il réellement impacté ?
A ton vraiment perdu de l'argent
parce qu'une seule instance
s'est parti en vrille ?
Entra alors la renseigne
le concept de SLA
pour service level agreement
ou littéralement
contrat de niveau de service.
Ce contrat est un accord
formel ou informel
passé entre des fournisseurs
de service et un client
s'agissant d'équipe
dans la même entreprise
ou bien d'une relation commerciale.
Dans un SLA,
on ne se préoccupe
plus de la maîtrique individuelle
et obscure que peut représenter
par exemple un pourcentage
d'utilisation CPU
ou d'occupation drame
pour juger la qualité
du service rendu.
Non, au lieu de cela,
on va faire en sorte de refléter
le ressenti
côté client
et on va donc mesurer
l'expérience utilisateur.
Retenez bien,
expérience utilisateur.
Pour bien définir un SLA,
il faut essentiellement
des indicateurs
et des objectifs.
On parlera alors
de SLA et SLO
pour service level Indicators
et service level Objectives.
Commençons donc
par les indicateurs.
Ceux-ci dépendent
du type de service rendu
et peuvent lui être
entièrement spécifiques
tant que cela reste pertinent.
Pour bien les choisir,
demandez-vous
et mettez-vous d'accord
avec votre client,
encore une fois client interne
ou externe
au fonction du type de relation.
Sur ce qui est important pour eux,
car des indicateurs choisies
arbitrairement n'auraient
aucune valeur
s'ils ne peuvent être
compris ou transposés
au cas concret.
De façon générale,
il est préférable
de les mesurer au plus proche
du client,
en développant par exemple
une sonne qui génère
du trafic similaire
à celui-ci,
à celui que génère le client
et qui serait physiquement
installé
de préférence
à un endroit
où l'on sait que le chemin
emprunté jusqu'à la destination
serait le plus proche
possible de la réalité.
Encore une fois,
pour être capable de juger
de l'expérience utilisateur.
Prenons un qu'instimple
et supposons que votre équipe
fournit une API REST.
Des indicateurs typiques
seraient par exemple
le temps de réponse
et la disponibilité
que vous mesureriez
en permanence
au travers d'un bout de code
tournant sur un serveur
installé à côté du client.
En fonction des cas,
il est aussi possible
de construire l'application
rendant le service
afin qu'elle expose directement
un certain nombre de métriques
sur un chemin spécifique
et que l'on pourra utiliser
à des fins de mesure.
On parlera alors
de white box monitoring,
contrairement au black box monitoring
qui implique que l'on n'a pas
la possibilité
de modifier l'application
pour faire ça.
Une fois que les indicateurs
sont définis,
il faut maintenant
des objectifs.
Ces objectifs
doivent être impérativement
définis en accord
avec le client
encore une fois,
c'est un contrat
et sont théoriquement
propres à chacun d'entre eux
car un client X
n'aura pas nécessairement
les mêmes attentes
qu'un client Y
pour un même service rendu.
Toujours dans nos exemples
d'API REST,
on pourrait dire
que le client X
attend par exemple
une latence
au 99%
de 10 000 secondes
et une disponibilité
mensuelle de 95%
alors que le client Y
qui lui est plus exigeant
attend une latence
au 99%
de 5 000 secondes
et une disponibilité mensuelle
de 99,9%.
Au passage
de telles différences d'exigences
pourraient justifier
différentes infrastructures
pour y faire face.
Mais vous faites, c'est bien beau tout ça ?
Mais 4,6 à l'heure de nos check
sur la mémoire,
le disque, le CPU
que notre admis
n'affectionne tant
à 2h du mat'
rien n'empêche
de les conserver
mais il est plus nécessaire
de générer des alertes
basées sur ces métriques isolés
et bien trop suivant
des nuits de sens.
On alertera plutôt
alors sur le
dépassement des SLO
qui ont été définis
avec un peu de chance
euh, pardon
sur le dépassement des SLO
qui ont été définis
et avec un peu de chance
on révéra moins souvent
ces pauvres petites admis
qui ne demandent qu'à dormir
sur leurs deux oreilles.
Maintenant que les indicateurs
et les objectifs
sont été mis en place
compris et accepté
par toutes les parties
il faut les formaliser
dans un document
qui sera donc
notre SLE.
Ce document
peut prévoir des dispositions
en cas de dépassement
des objectifs définis
que l'on qualifie
de violation de contrats établis.
Il peut s'agir par exemple
de pénalité financière
si on est dans le cas
d'une relation commerciale
ou bien d'une obligation
de corriger, stabiliser
le service au détriment
de l'introduction
de nouvelles fonctionnalités
et ce tant que l'on n'a pas
l'assurance de la non-réoccurrence
du problème
du ou des problèmes.
En fait,
puisque c'est un contrat
établi et tant que
les parties en jeu sont d'accord
les dispositions à prendre
dans de tels cas
restent à leur entière liberté.
Tout ça c'est qu'une introduction
générale
au concept des SLA,
Seli et Selo
et plein d'acronyme.
Et nombre de bonnes pratiques
et d'autistes ont été aujourd'hui
disponibles pour répondre
à ce besoin de monitoring
orienté-business,
noté bien orienté-business
et qualité de service rendue.
Super, super bien.
Une présentation large.
Alors moi déjà j'ai une question,
enfin en fait
en ayant un peu recherché
le principe des SLA
on s'aperçoit que c'est
un principe fort de E-TIL
et moi on m'a toujours dit
que E-TIL c'était caca.
Alors je vous ne pas du tout
être famille avec l'E-TIL
n'ayant jamais travaillé
dans une boîte qui avait
en tout cas
qui intégrerait ses pratiques
là.
Alors je ne sais pas
si je suis capable de répondre
correctement à la question
mais peut-être quelqu'un
d'autre a une réponse.
Alors moi j'ai rien en particulier
sur E-TIL,
c'est-à-dire que j'ai jamais vu
une entreprise qui l'a
implementé de la même manière
qu'une autre.
Donc voilà c'est des bonnes pratiques
et au final ça ressemble assez
peu d'une entreprise à l'autre.
Mais la notion de SLA
en tout cas est super intéressante
et moi j'y suis très favorable
pour justement avoir été
ceci s'admine qui se fait
réveiller à 2-3 heures du matin
et qui comprenait pas pourquoi
la rame était éclatée
ou le CPU.
Mais c'est vrai que j'ai
justement plus un retour
d'expérience à offrir
plutôt que des questions
en l'occurrence.
J'ai commencé à implémenter
justement la notion de SLA
pour superviser des micro-services
qu'on avait mis en pratique
où je travaillais précédemment.
Et justement c'est quelque chose
qui a vraiment facilité
l'échange et la communication
entre l'équipe des développeurs
et des administrateurs systèmes,
des opérations
parce que justement
ça a responsabilisé
beaucoup plus les développeurs.
C'était eux qui
concevaient les indicateurs,
donc les fameux indicateurs.
C'était les ops
qui implémentaient les mesures,
donc vraiment la calcul des performances
et les remontées d'erreurs,
ce genre de choses.
Et au final les deux équipes
regardaient et analysaient
les résultats ensemble.
Et c'était vraiment
très très beau à voir.
En tout cas j'ai pas eu
l'occasion de l'implémenter
jusqu'au bout,
mais les débuts
étaient assez prometteurs.
Je suis assez d'accord avec ça.
Et comme tu dis,
comme tu dis,
d'ailleurs c'est pas mal
parce que ça s'inscrit
dans un peu ma définition
du DevOps.
Et je trouve que le SLS
marche très bien
dans la culture DevOps
et que ça
renforce
d'autant plus la collaboration
que ça
force entreguimer les équipes
à travailler ensemble
pour d'une part avoir
un service plus stable
et d'autre part
être capable d'analyser
d'analyser problèmes
en ayant des métriques
qui veulent dire quelque chose
et pas juste un CPU
qui dépasse un seuil fixe
ou un ARAM
qui dépasse
un omeil seuil fixe.
Moi pour revenir
à la compération
qu'on a faite
au niveau de l'itile,
je pense que
même si le SLA
il existe
depuis les années 90
niveau itile,
il y a une distinction
qui, enfin, il y a une répercussion
qui est faite
à notre niveau,
au niveau de l'ingénieur
au niveau de l'opérateur
qui n'existait pas avant
et avant,
le SLA était
un accord bien plus business
alors que maintenant
tel qu'on le conçoit
et tel qu'on le décrit
le SLA est un indicateur
bien plus technique
et voilà, je pense que la différence
elle est là.
Si je devais donner une différence
pour moi, ça serait plutôt celle-là.
Il y a même un troisième acteur
si je peux me permettre
qu'on n'a pas cité
dans ce sujet-là,
c'est la QA
qui peut être généralement
et en tout cas, c'était mon cas
peut être impliqué
justement dans le process
d'établir le SLA
ou du moins l'enforcer
et le faire appliquer.
C'est justement
en fait, c'est la notion de qualité
et donc de qualité de service
en l'occurrence
qui est un petit peu illustrée
dans ce genre de choses
et ça peut être pas mal
justement d'avoir une équipe
qui est un peu tierce
entre les devs et les ops
pour justement faire un peu arbitre
et pour pouvoir contribuer
soit en indicateur,
soit un petit peu en analyse de CSELE.
Je pense que là,
en fait, c'est vraiment
la notion de confiance
pour reprendre
peut-être deux interventions
c'est qu'au final,
vous avez créé une confiance
entre devs et ops
via un contrat
et souvent les contrats
il faut un tiers de confiance
dans la rédaction
c'est un notaire par exemple
ça va être des choses comme ça
quand on fait un contrat
pour un nouveau bien
et un premier par exemple
et en fait, il y a souvent besoin
d'un tiers de confiance
et oui, la QA peut donc être
certaine à me dire là
donc Thomas,
c'est tout à fait ça que tu confies
tu conseillerais en fait pour justement
enfin moi,
j'allais me faire un peu la vocation du gap
c'est
qu'est-ce qu'on fait quand la SLE
n'est pas respectée
qu'est-ce qu'on fait
quand on est dans une équipe interne
quand une autre équipe
n'en respecte pas
les préarroquies qu'on avait dit au début
j'imagine que ça doit être
justement stipulé
dans le fameux contrat
dans le fameux SLE
qu'est-ce qu'on fait
quand les termes du contrat
ne sont pas respectés
que le temps de réponse
est supérieur à ce qui a été établi
ou qu'il y a le seuil d'erreur
qui apparaît est trop élevé
qu'est-ce qu'on fait
et bien, là comme le disait Bartelémis
il parlait de passer
les SLE, ça avait vraiment
une connotation très business
où il y avait la notion de pénalité financière
on n'a pas tendance à se facturer
et à se lancer dans des guerres juridiques
entre services
du moins en tout cas dans les entreprises
dans lesquelles on travaille aujourd'hui
c'est là qu'on en approche
plus à la collaboration
et à faire en sorte de régler le problème
et ça pourrait en effet,
comme le disait Victor,
passer par le fait de ralentir
un petit peu l'acquadence
en termes d'implémentation de fonctionnalité
pour pouvoir stabiliser un service
qui commence à se dégrader
en termes de qualité de réponse
en qualité de service
pour arriver à stabiliser ce problème
Et Victor, qu'est-ce que tu ferais
parce qu'un contrat s'est évolué
et notamment une API
ou n'importe quoi
comment tu préconiserais
justement l'évolution
quels sont les bonnes pratiques
à ces niveaux-là
parce qu'on sait que rien n'est figé
dans le marbre
Oui, effectivement je parle de contrat
mais je crois que je l'ai dit
je sais plus si je l'ai dit
en tout cas ça peut être formel ou informel
à mon sens d'ailleurs
tant que c'est pas
je pense tant que c'est pas lié
tant que c'est pas directement lié au business
ou que c'est pas une relation commerciale
je pense que c'est préfère d'avoir un truc informel
histoire que ça soit un peu plus flexible
C'est pas qu'il y ait écrit mais...
Oui voilà, ça peut être écrit
mais c'est pas obligé que ce soit signé de son sang
C'est ça
à mon sens
si on parle
en tout cas j'ai parlé d'indicateurs
par exemple sur les indicateurs
il faut être capable
de pouvoir intérer dessus
de faire évoluer
aussi bien les indicateurs que les objectifs
pour répondre
aux besoins qui peuvent évoluer
de la part du client
ou au service rendu qui peut lui aussi évoluer
ça pourrait être versionné
comme on versionne une API par exemple
et c'est une façon de procéder
ou la version du service
à chaque fois en profiter
pour réviser les termes du SLE lié au service
C'est pas parce qu'on définit ce contrat
à un moment donné qu'on ne peut pas réviser
les termes quand il y a besoin
parce que les besoins ont évolué
ou parce qu'il faut le faire tout simplement
D'accord, super
Je pense que...
Oui on est bon
C'est très beau
Alors on va passer maintenant
à Doiton Tout Automatisé
donc c'est Marc qui va nous en parler
et avant ça je vais lui poser
une petite question encore
du trivial poursuite
édition DevOps
que nous a fournis automique
Alors dans quel langage de programmation
a été écrit Jane Kins ?
Jambe
Ouais on peut mettre quoi aussi dedans ?
Scala non ?
Du Groovy
Ah oui d'accord
Voilà des plugins qui ont pas mal de jeux d'opoil
Hmm Groovy
Bon ok on s'obsette de...
C'est un DSL sur...
En tout cas c'est un langage de scripting
au-dessus de Java
Donc voilà Marc
Doiton Tout Automatisé avec un point d'interrogation
C'est ça
Mon sujet aujourd'hui est une question
Doiton Tout Automatisé
Alors par le passé dans l'informatique
et on pourrait même d'ailleurs revenir au fond
au fond d'un mento
l'informatique c'est le principe
c'est l'automatisation
l'automatisation, l'algorithmique
le traitement automatisé de l'information
En partant de là
on a depuis quelques années
commencé à automatiser pas mal de choses dans l'informatique
à commencer par le déploiement de configuration
donc c'est un petit peu ce qui a entre guillemets
propulsé le mouvement DevOps
c'est parti en partie de là
donc ça aujourd'hui c'est quelque chose
qui je pense maîtriser
il y a des outils qui sont sortis
qui font un petit peu office de standard
donc on pense à ces fameux
Pepe, Chef, Antibole, Salt et Compagnie
donc on peut établir aujourd'hui que le déploiement
l'automatisation du déploiement de configuration
c'est réglé
il y a plus grand chose à révolutionner
ou à établir à ce niveau-là
pour le déploiement d'applications
donc du coup aujourd'hui les applications
qui sont écrites par les développeurs
il y a encore des choses à dire et à faire
mais globalement ça a à peu près en voie de stabilisation
donc on parle notamment de chaînes d'intégration
de déploiement continué avec CI CD
on parlait de Jenkins il y a quelques instants
il y a aujourd'hui des choses qui se dessinent
mais globalement on voit à peu près la direction
dans laquelle il faut aller
notamment aussi quand on parle de conteneurs
du coup on parle de développement aussi
je parlais dans ma précédente chronique
ou précédent numéro avec les méthodes de déploiement en blu-grine
l'automatisation de la mise à jour d'application
et on voit d'être à peu près établi et stabilisé aussi
un peu plus loin
on parle maintenant aujourd'hui d'automatisation
de déploiement d'infrastructures
donc ça c'est encore à peu près un terrain mouvant
il y a des outils qui sont en train d'établir un standard
tel que terraformes aujourd'hui
certains outils de gestion de configuration
comme Ansible et Chef sont capables aussi
de manipuler et d'automatiser la création d'infrastructures
c'est encore un peu moins sec
que pour le déploiement de configuration
mais ça va encore là une fois dans le bon sens
donc on pourrait se dire
on a tout automatisé dans la formatique
mais est-ce qu'on devrait vraiment
tout automatiser dans la formatique ?
est-ce que les bascules de base de données
dans le cas où on n'a pas affaire à des clusters de base de données
qui sont capables de gérer ce genre de choses
les bascules de trafic réseau
est-ce que tout est vraiment automatisable ?
je vous pose la question
très bonne introduction
je vais reprendre directement
on a un avis on a à peu près les mêmes exemples en tête
mais je vais te poser un est-ce que tu as un exemple
justement d'automatisation qui a bien foiré
mais c'était justement la question que je comptais vous poser un peu plus tard
alors moi j'ai eu à faire il y a quelques années
un système de bascule de base de données mais SQL
donc il y avait un master et un slave qui fonctionnaient par paire
et il y avait un systeme, un petit système embarqué
qui était capable de détecter si le master était KO
pour basculer automatiquement les écritures
en modifiant un enregistrement DNS
sur le secondaire, sur le slave
et il y a eu une fois un petit incident réseau
où le heartbeat entre les deux machines avait cessé de fonctionner
mais les deux machines fonctionnaient toujours bien
et ce problème fonctionnait apparaissait par intermittance
et donc on avait des bascules régulières entre le master et le slave
qui pour le coup avaient bien corrompu les données
les données, même si la réplication était master slave entre les deux
on avait observé des incohérences de données entre les deux serveurs
donc pour moi ça c'est typiquement le cas que je n'aurais tendance à ne pas automatiser
donc c'est vraiment un avis très personnel
tout ce qui a rapport aux bases de données
je suis assez frileux sur cette question là
parce que à cause de cette mauvaise expérience
c'est une expérience justifiée
puisqu'on se souvient l'expérience de GitHub qui avait eu exactement le même problème
c'est une bascule de base de données d'un master à un autre
qui a corrompu complètement
en fait, fait en sorte que les bases de données se sont splitées
et ont vécu leur vie
les fameuses splitbrains
on sait pas qui a raison et qui a tort
et c'est assez généralement assez douloureux
c'est vrai que normalement les technologies qui permettent de le gérer
mais qui sont aussi extrêmement compliquées
donc elles-mêmes étant compliquées, ayant été sensible à une faillite
c'est ça, il y a un autre, je ne sais pas si vous avez d'autres des expériences vécues
c'est marrant que tu parles de cet exemple de base de données
parce que justement je parlais de la même chose
il n'y a pas très longtemps avec quelqu'un que je connais bien
en DBA que je connais bien
et qui m'a justement parlé de ça
du fait que dans le monde des admins de base de données
donc les DBA, les bons vieux barbus de base de données
il y a cette peur effectivement de l'automatisation de ce genre d'opération
de bascule de base de données entre autres
et du coup les pratiques restent assez à l'ancienne
où on a plus tendance à avoir confiance
en l'opérateur manuel que quand la machine
il y a une procédure à suivre etc
et ça soulève la discussion au final
est-ce que le problème c'est le fait d'avoir ces procédures
manuels qui sont fastidieuses
et qui sont potentiellement source d'aira
parce que quand c'est un opérateur manuel
je pense qu'on est tous d'accord pour dire que
la procédure sera moins bien appliquée
que si c'était une machine qu'il a faisait
et un risque d'erreur humaine
est-ce que le problème finalement c'est...
le système de détection, de pas d'intention
qui dérange l'ordre d'automatiser de bascule
et d'une base sur une autre
Là en fait ça soulève même plusieurs pas
je pense que ça rejoint un peu la première discussion
qu'on a eue au début c'était comment on mettaient
des nouveaux logiciels sur cube
et je pense qu'en fait là c'est un peu la même chose
c'est-à-dire est-ce qu'on peut automatiser
quelque chose qui n'est pas automatisable
c'est plutôt ça à mon sens le sujet
qui est dans le cas des bases de données dite anciennes
la plupart des commandes sont pas immutables
elles sont pas idempotantes
c'est-à-dire que les commandes
il faut les jouer dans certains d'ores, dans certains de rôles
il y a une notion même de partage
des fois qu'il faut faire une commande doit être appliquée
sur un nœud et en fait le token généré
ou la ligne de configuration générée
doit être appliquée après sur d'autres
et ça par un outil d'automatisation c'est extrêmement compliqué
et je pense en fait c'est plutôt ça c'est qu'à l'heure actuelle
en fait les logiciels qu'on avait étaient très humaines
humaines centriques
dédiés à l'humain et faites pour un être humain
alors que maintenant on est obligé d'avoir des logiciels
qui soient faits pour un système d'automatisation
d'orchestration etc
et je pense c'est plutôt ça en fait
dans un tout automatisé c'est plutôt
est-ce que tout est automatisable
et c'est plutôt ça en fait je pense qu'il y a certaines choses
qui quand elles n'ont pas été conçues pour
de doivent avoir un certain niveau
et après deuxième point
disais-vous vous pourrez répondre après ces deux parties
deuxième point que tu disais pendant que je l'ai encore en tête
et en fait non
je dis à ce point
je vais juste remontre
on dit en fait ça rejoint la thématique
qu'on a eu l'émission précédente sur les outils
les outils qui étaient faits par l'homme pour l'homme
et ça d'autres outils qu'il fallait inventer
qui étaient faits pour la machine
destiné à la machine et les deux n'avaient pas le même usage
n'avaient pas le même objectif
et ne fonctionnaient justement
enfin juste pas de la même manière
et je pense que c'est un peu l'idée qui est derrière
derrière ton propos
deuxième point que moi aussi je pense que j'ai oublié dans la foulée
tu as que j'ai eu sur le bien
oui bah tu en vas aussi
en fait tu disais juste avant que les victors
que les êtres humains étaient sensibles à la faillite
en fait à ne pas respecter bien une procédure
en fait d'expérience j'ai l'impression que c'est plutôt l'inverse
c'est à dire que souvent les êtres humains sont
oui plus faillibles mais plus sensibles
à détecter leurs propres erreurs
alors que les outils automatiques
sont complètement incapables
les outils automatiques sont complètement incapables
c'est à dire qu'elles peuvent faire des choses
et quand elles le font mal elles le font
à des proportions mais des mesures restées
juste que tu leur dis te faire
oui mais non
enfin oui et non c'est à dire qu'en fait
après il y a un système qui est que c'est
le système en lui même qui a sa propre complexé
sa propre façon d'analyser les problèmes
c'est à dire que même au-delà de ce que tu lui dis te faire
il y a une corrélation des événements
qui se passe uniquement dans le logiciel
pour connaître un peu chef on a des systèmes
de notification interne entre les différents événements
avec des briques de if et que ça
oui tout ce code là a été écrit par un être humain
mais ce qui se passe en règle générale sur la machine
justement le but de l'automatisation
c'est que ça se passe sans intervention de l'être humain
avec une certaine logique parfaite
qui après s'appliquer et en fait
pas très souvent
enfin via des cas compliqués
et via des bases compliquées
ces choses là peuvent bien foirer
je vais retrouver ce que je voulais dire c'est
en fait
l'humain il est hyper maléable
il est hyper flexible
il peut s'adapter à toutes les situations
et il peut réagir au quart de tour
en utilisant son intelligence, son expérience
la machine ne peut pas le faire donc je pense que
se reposer sur cette maléabilité
d'une certaine manière
c'est pas mauvais
et on peut
enfin on peut et on doit
peut-être pas de manière hyper récurrente
mais on doit se reposer sur cette capacité humaine
qui est de s'adapter hyper efficacement
dans notre travail
ça serait idiot de pas le faire donc
peut-être que c'est pour moi la réponse
non il faut pas tout automatiser
et des fois faut juste faire travailler les hommes
alors certes
ça peut être épétitif, ça peut être chiant
il y a des opérations qui vont être pénibles
mais on a une capacité
qui n'a pas la machine
c'est qu'on est des hommes
C'est pour automatiser partiellement en fait
il y a une procédure à faire manuel
on doit pas être
pas être vocation, être forcément 100% manuel
on peut automatiser certaines parties
C'est peut-être de la récurrence
de l'intervention à faire en fait
tu sais t'alors des tâches récurrentes
et pénibles etc
je pense que ça c'est quelque chose qu'on peut automatiser
exactement
c'était une de mes sous-questions
à partir de quand on automatise
si il y a certaines tâches administratives
qui se produisent par exemple tous les 2-3 mois
qui sont réellement
très similaires
mais pas forcément automatisables facilement
est-ce que ça vaut le coup vraiment de se prendre la tête
à automatiser quelque chose qui est certes un peu pénible
à faire pendant quelques minutes
ou justement se lancer potentiellement
dans des jourhommes de développement
donc le bar t'as une expérience laitue avec des clés USB
clés USB, qu'est-ce que j'ai fait avec des clés USB
alors en fait t'avais reçu des clés USB qui étaient corrompus
et vous se demandiez
vous posiez la question de savoir
est-ce qu'il valait mieux renvoyer les clés
enfin ou avoir un tout un processus compliqué
d'iterration pour
enfin pas corrompu il manquait un fichier sur tes clés USB
qui étaient des clés USB
de commercial
et vous étiez posé la question de savoir est-ce que
vous rentriez dans un processus compliqué
d'automatisation
d'ajout des fichiers sur tous les clés USB
ou il valait pas mieux
brancher avec les USB, drag and drop le fichier
etc etc
peut-être, peut-être, je me suis marqué
et donc ton manager avait fait le calcul
simple, un calcul de
combien de temps ça va me coûter
entre guillemets à automatiser
combien de temps là, de manière ponctuelle, vous allez le faire
et le rapport est quasiment de 10
c'est ça mais il y a un vieil adage qui dit que
par exemple les 6 admins sont
euh...
pardon je cherche le mot
et en tendance à tout automatiser
à partir de la deuxième fois ils ont à faire quelque chose
qu'ils ont déjà fait une première fois, ils vont avoir tendance
à le automatiser mais personnellement
j'ai déjà été confronté à des cas où tu fais juste des choses
deux fois en fait et la deuxième fois le temps
que t'auras perdu a essayé d'automatiser quelque chose
il l'a vraiment perdu
2 fois ou 2 fois dans l'année du coup
il y a vraiment des cas où ça ne vaut pas le coup
humainement ou financièrement
d'automatiser certaines choses
sans parler d'erreurs et d'incidents
l'exemple typique c'est en ce moment
je suis en train de faire des
reportings sur de la capacité
tu le fais une fois dans l'année
est-ce qu'on l'automatise
est-ce qu'on l'automatise pas et j'ai pris le choix
de pas vraiment l'automatiser mais de l'assister
c'est de faire quelque chose et que je le copie-colle
de le parcellement automatiser
c'est ça, ça peut être une solution
oui c'est un truc que la automatisation enlève aussi
enfin obscurcie un peu la chose
c'est à dire que tu disais
enfin, deuxième fois
ou même la troisième fois combien si c'est dans un an
comment elle marche l'automatisation
est-ce que toi tu seras encore là pour la faire tourner
c'est une très bonne observation
c'est quelque chose qui marche tellement bien automatisé
que lorsque tu dois un jour le débugger
ou l'expliquer à quelqu'un qui arrive
des années plus tard, personne sait comment ça fonctionne
l'automagique
sinon rendez-vous
dans 10-15 ans et on verra si ça donne une bonne IA
oui voilà, il y a pour le coup
pourrais résoudre en partie
ce type de choses
si elle ne nous a pas tous tués d'ici là
elle aura automatisé la fin du monde
c'est encore un autre débat sur les IA
moi je me dis
alors, maintenant on va passer à la dernière partie
que va nous présenter
par Télémy
qui est donc sur le risque
mais avant ça, je vais d'abord te poser
une petite question
selon POPETLabs
en 2013
dans l'état du DevOps
quels sont les outils les plus importants
d'un projet DevOps ?
en 2013
à 84%
dans l'enquête
les gens disent que c'est ces outils-là
qui sont les plus importants
je ne sais pas, du bug tracking
POPETL
les outils de gestion de version
en 2013
peut-être aussi replacé un peu dans son contexte
en 2013, on est en pleine fin de guerre
où Geet commence à gagner allègrement
sur tous les autres
pour remettre un peu dans un contexte historique
c'était il y a longtemps
donc Bert, le risque ?
le risque du DevOps, le risque en général
voilà
donc c'est ma mission d'aujourd'hui, je vais vous présenter
ma vision du risque
ce bon vieux jeu de
1957 créé par un français
attention, instant cocorico
de par son sujet, il met en exergue
l'étendue et la complexité du monde
au travers d'un cessant conflit armé
la logistique est ici, prix mordéale
car elle...
Bert, je crois que tu t'es planté
c'est pas vraiment de ce risque là qu'on parle
ah mais non, non je me serais
planté de fiche, je vérifie
j'avais pourtant parlé de l'importance
de l'archipel indonésien, des faibles connexions
entre l'Amérique du Sud et la reste du monde
ainsi que de l'insularisme gagnant
de Madagascar, enfin quoi toutes
mes stratégies gagnantes
bon, je reprends
le risque, le risque, risque, ok
bon allez, un petit préambule
nécessaire, je voudrais dire à tous
que je ne suis absolument pas
un spécialiste du risque Haiti
je pense que si on analyse
à posteriori ce que je vais pouvoir dire
on trouvera certainement une infinité
d'effauts et d'écarts par rapport au texte
de référence dans le domaine
cela dit, j'ai aussi mon avis
Calhann et je compte bien vous en faire
profiter
donc, je vais pas vous faire
un cours sur la gestion du risque d'un projet
Haiti sur l'ISO 27005
ou 9000, le COBIT
le SMSIL, PDCA et toutes
les contraintes légales, type SOX
ça m'intéresse pas et puis il se trouve
qu'il y en a d'autres qui en parlent bien mieux que moi
s'il existe autant de textes
réagissant et encadrant la sécurité dans nos
métiers c'est parce que nous éritons
d'une technologie issue à la fois du
secteur militaire et de très grosses
industrielles stratégiques
dans ce type d'activité critique il est
compréhensible qu'il soit nécessaire
d'assurer et de garantir la préservation
de certains assets dans
acte
moi c'est plutôt l'échelle microscopique qui m'intéresse
celle qui nous concerne au quotidien
et qui n'est pas toujours dictée
par des règles de bouquins poussiéreux
en cela j'ai retenu quelques
4 figures intéressants que je vais balayer
rapidement avant de commencer un tour
de table avant que
tout le monde s'endorme
moi dévops, correspond sable
du cycle de vie et de la bonne
marche de mon service, quelles sont
les risques les plus fréquents auxquels je peux m'attendre
pour faire ce petit état des lieux
j'ai trouvé intéressant de projeter
en ces mêmes risques sur le modèle
cams, donc on rappelle cams
c'est culture automation, measure
and share qui sont
les piliers du devops et ça
va permettre de trouver une réponse
adéquate et compatible
devops voilà donc on va essayer
de balayer quelques exemples et on continuera
tous ensemble donc le fameux
on ne touche pas quand ça marche
pour moi c'est un problème de culture
qu'est ce qui est si bien
dans la sille de solution actuelle
pour que ça ne mérite pas d'être changé
réflexion
je pense que les paradigmes passés existent
pour être légitimement remis en question
à l'aune de nos pratiques et de nos
besoin modernes
autre dicton qu'on entend
régulièrement c'est la 10ème fois que notre service
est impacté par ce problème
on l'a tous su
on l'a encore
je regarde mon collègue
à droite
c'est un problème d'automatisation
quoi qu'il advienne quelle que soit la manière
vous devez impérativement vous empêcher
de refaire plusieurs fois la même chose
ça rejoint un petit peu notre débat précédent
vous devez
comment dire il faut le faire le maximum
humainement possible tout en se gardant
une certaine latitude d'action
si il faut on réunit tous les intervenants
du sujet autour d'une table et on règle ça
il faut pas rester dans des situations
où on a toujours les mêmes problèmes
autre phrase
tu bosses un peu trop avec une autre équipe
ça fait pas avancer le backlog
c'est un problème de sharing partage
mes compétences
mon expérience sont utiles ailleurs
et elles font gagner du temps à des personnes
c'est un bénéfice pour tout le monde
on silote déjà les produits on va pas
en plus siloter les gens
c'est trop compliqué on va commencer par plus petit
alors c'est discutable
mais pour moi c'est un problème de mesure
il faut donner de la confiance on en a parlé
et il faut donner de la visibilité
on va comparer les choses on va fixer un cap
et on va le faire sans compromis
mais avec de l'empathie
c'est à dire que des gens ils craignent le changement
pour eux ça représente un risque
on va essayer de le mitiger en donnant une visibilité
et en débroussaillant
le gros brouillard qui se trouve en face de nous
on le fait avec
de la mesure
il y a trop de dépendance avec d'autres équipes
c'est trop compliqué on arrête
on le fait pas on le fait autre chose
ou on se contente de ce qu'on fait déjà
alors ça c'est un problème qui est très complexe
pour moi j'ai pas réussi a le catégoriser
c'est un peu de tout
c'est illusoire pour moi de vouloir casser
l'intégralité des dépendances
qu'elles soient internes ou externes
car c'est aussi la force d'une entreprise
c'est ces personnes qui se travaillent ensemble
qui travaillent autour de différents produits
différents oeuvres, différents services
et il est possible d'aller voir les personnes
de discuter avec elles et de faire évoluer ces services
assez rapidement, plus rapidement que si on travaillait
avec Amazon ou avec d'autres services
ça va impacter nos performances
c'est aussi un problème de mesure
qu'est ce que c'est la performance pour nous
service provider
qu'est ce que c'est que la performance pour nous clients
il faut être conscient que c'est pas forcément
on parle pas forcément de la même chose
commence à voir à l'avance le résultat
et l'impact de business
sans l'avoir testé
donc il faut tester
avant dernier point
c'est comme ça qu'on fait ici
il faut s'adapter et il faut utiliser
l'outil officiel
c'est un problème aussi de culture et de partage
l'homogénité à tout prix est un fléau
il faut
et réduire les risques en forçant un outil
unique n'a jamais rendu cet outil de meilleure qualité
en revanche ça réduit dramatiquement sa
vélocité d'évolution et sa capacité
à convenir à tout le monde en même temps
faut donc briser ces dogmes
et ramener savoir faire et le bon sens
au centre de l'équation
et non c'est celui
je continue j'en avais quelques-uns
des points il faut prouver que c'est la
bonne solution à l'extérieur de l'équipe
il faut convaincre
alors pour moi et je pense que c'est
un problème de culture DevOps également
les équipes sont responsables de A à Z
de leur outil et de leur chaîne
de production de valeur
tant que les obligations de sécurité sont respectées
il paraît normal qu'une équipe unanime
sur un sujet ou sur une question
puisse choisir son propre destin
c'est un faux risque synthétique
créé de toute pièce pour ralentir les gêneurs
et c'est la différence entre
la confiance qu'on peut porter
à des gens et l'application
de bêtes d'instruction
c'est aussi la différence entre une communauté
et un bataillon de soldats
et dernier point
c'est le rôle de quelqu'un d'autre de faire ça
tu n'as pas à t'en préoccuper
tout le monde
a le droit de prendre des risques
on n'a pas besoin d'une étiquette ou d'un badge
je crois que j'ai dû dire quelque chose comme ça
la fois dernière également
et si on pense que notre idée peut apporter
de la valeur ou de la performance
c'est notre métier et notre devoir que de
tester et de valider cette hypothèse
je pense que vous avez maintenant compris le principe
on va pouvoir discuter ensemble d'autres risques
peut-être des risques un peu plus classiques
tout en tachant de les placer
dans le contexte DevOps
si vous êtes d'accord
alors je pense que
tu l'as un peu dit déjà au début en fait
c'est pour ça que je vais juste
enchaîner et approuver
c'est que dans certains contextes
sans doute que les risques sont forts
on peut le voir la aeronautique et encore
on en a parlé à fois d'avant
le militaire, on pourrait les centrales
tout ce qu'il y a d'énergie etc
et encore pas toutes les industries
encore
je pense là
une mauvaise vue
ou une vision biaisée peut-être de l'informatique
que l'on a maintenant
c'est que quand on est un site web
les risques sont quand même faibles
ceux qu'on va
impacter ou les choses qui vont se passer
sont quand même très très faibles
c'est peut-être pour ça le problème c'est la vision
même de nous et de ce qu'on va pouvoir y faire
c'est à dire que si jamais demain
des personnes veulent
innover et faire un nouveau projet
les risques inérents sont très faibles
en fait initialement
la société a peu de chance de s'écrouler
sauf si vraiment on est dans une start-up
qui n'a pas trouvé son business model
mais dans ces cas là ce n'est encore pas le problème
initial du risque
qu'on va faire à ce moment-là
et je pense en fait là dessus c'est vraiment
un problème de culture ou même de vision
des risques ou d'analyse des risques
entre les différents acteurs qui a un problème
je sais pas si vous êtes d'accord avec ça
ça se tient très bien
c'est pour ça que je...
j'ai avec toi
après pour répondre
à tes points aussi j'essaie de te faire des signes
très très grands donc tu vois
c'est très compliqué
dans le système de
que tu vas avoir d'interdépendance entre
des équipes en fait on y a déjà répondu tout à l'heure
en fait c'était notre deuxième point
qui était les SLAs et c'est peut-être ça
en fait le manque
quand tu parlais de confiance à faire les autres équipes
c'est peut-être le manque de SLAs
c'est ce point là qu'on a
c'est le mode de formalisme peut-être
de confiance en fait plus
on fait pas une confiance dans une SLAs on s'y tient
c'est contractuel
oui mais tu vas avoir une confiance justement dans l'autre équipe
si elle a fait une SLAs c'est qu'elle est
elle est capable de le filmer
ou en tout cas elle est capable de s'engager
et je pense que c'est en fait la notion de confiance
et d'engagement qui est un problème
et en fait tu isoles quand les gens ont perdu la confiance
et c'est quelque chose d'ailleurs
qu'on avait vu quand on était allé au DevOps Rex
ça permet de faire un petit placement produit
de l'Ostrex qui s'est passé la semaine dernière
et l'année dernière quand on y était
quelqu'un avait parlé justement
de la communication
et en fait du fait que les gens
refaisaient dans leur coin à partir du moment où ne faisaient plus
ou décidaient de faire
de ne plus avoir de communication le jour où il y avait perte de confiance
je pense que la confiance
se répétait plusieurs fois et ça a l'air de le centre du...
je pense
donc au final quand tu parles de risques dans le DevOps
c'est majoritairement des risques humains
si je comprends bien
j'ai voulu faire un listing et il se trouve que j'ai trouvé
assez peu de risques techniques
et même quand il y avait des risques techniques
au final c'était des risques humains
parce que justement il n'y avait pas de confiance
où il y avait des a priori, où il y avait des dogmes
et je pense que si
on était très factuel
il y a quand même relativement
peu de risques techniques
alors j'ai pas abordé les problématiques
de sécurité, type authentication
type auditing, type
obligation légale, je pense qu'il y a tout un
chapitre que je ne connais pas assez bien
pour creuser
avec vous
et qui a peut-être des réponses différentes
cela dit, moi
si on s'en tient au DevOps, à la culture
et à la mouvance DevOps
pour moi il y a relativement peu
de freins techniques
c'est peut-être aussi au fait que
tous les gens qui sont autour de la table
évoluent dans des milieux
où il y a relativement peu de contraintes
de sécurité
ou de risques
ce qu'a dit Gillem, juste avant
on travaille pas dans le nucléaire
ou si on le foire on risque de tout faire péter
ou dans le bancaire, ou chaque 10 secondes
ou alors tu peux divulguer des données bancaires
si jamais tu en profites
je suis dans deux projets
là dessus qui ont notamment un projet
PCI DSS
je vois
je suis pas exactement dedans avec ça
mais justement ça me permet de rebondir
ça me fait un peu penser à la Gillem
c'est à dire que certaines personnes vont penser
que la Gillem c'est bien
mais quand il faut réaliser vite
la méthode en V c'est mieux, d'avoir des plannings
d'avoir des projets, d'avoir des runemaps
c'est encore une question de confiance
au bout d'un moment, quand ils ont
c'est à dire la Gillem c'est bien
quand il n'y a pas de problème
mais en fait dès qu'on a quelque chose de bien précis
alors là non, on ressort la bonne vieille
bon vieux cyclanvé des familles
on le sort à toutes les sauces, un bon diagramme
de gantes et c'est parti et là on est sûr
que ça sorte au bon moment, en fait ça ne sort jamais au bon moment
et donc en fait cette question de confiance qu'on a
est-ce qu'elle est forte ou pas envers un élément
et c'est vers l'adversité qu'on a ça
je pense que pour la sécurité c'est un peu pareil, je suis persuadé
mais intimement persuadé
que justement le DevOps est une réponse au problème
de sécurité, c'est à dire de mettre
en place des liens forts entre développeurs
et opérationnels, c'est ça aussi qui fait
en sorte qu'il y ait une culture responsable
de tout point de vue qui se mette
en place. Avoir en faire en sorte par exemple
qu'on ait une CI-CD, ça fait en sorte que les développeurs
n'aient plus accès à la prod pour tout va
d'avoir des systèmes de log
généralisés, ça sert aussi bien à débugger
qu'à auditer. Et je pense en fait
vraiment que intrinsactement le DevOps est une réponse
à la sécurité et c'est pour ça que ça rejoint
un peu Falconix que j'ai pas voulu nommer
mais qu'on en a parlé à la fois d'avant
qui était que l'erreur même dans des cas
industrielles forts comme celui de la aeronautique
et les échecs en font partie
et je veux...
Il y a quand même
une composante
que tu ignores, enfin que tu je sais pas
c'est volontaire ou pas, c'est que
autant les développeurs et les opérations
sont présentes dans l'entreprise
autant la plupart du temps
la compétence sécurité
n'existe pas. Et c'est
des tiers, c'est des consultants
externes qui sont là
et qui sont pas là tout le temps. Donc comment
on travaille en DevOps avec des gens qui n'existent pas
avec la compétence qui n'existe pas.
Alors pour avoir vu
une roadmap par exemple PCI DSS
en fait on s'aperçoit que
j'ai des audits en amont que tu peux faire
et en fait justement il y a une notion vraiment
de rejeu et d'amélioration continue
même dans le process d'accréditation PCI DSS
c'est à dire qu'on va avoir
des premiers auditeurs qui vont venir à un moment
qui vont aller auditer
et donc en fait il y a la notion d'erreur
qui est incluse dans la certification PCI DSS
puisque on va avoir
un premier audit qui va être un audit purement
formel, c'est à dire qu'on va et déclaratif
on a déclaré ce qu'on faisait
et les auditeurs nous en donnent un avis
pour amélioration et on va évoluer
comme ça en fait très très progrésiment.
Donc je pense même que le cycle même
d'amélioration continue si jamais il est bien pris
peut aussi faire partie et aussi le faire
bien, enfin je pense que personne
aucun opérationnel
ne veut avoir une perfume complètement trouée
parce qu'il sait que c'est lui qui devra réparer après
donc la dimension même sécurité
si jamais il est bien pris, si jamais on lui laisse le temps
je pense qu'il a
il l'inclu, il l'inclu dans le process
avec des développeurs etc
c'est pour ça que même en fait, il y a
et c'est Jean-Jean en fait même ce que tu dis
c'est que je vais même encore plus loin, c'est qu'on parlait que
de risques humains et pas de risques techniques
mais même dans les risques techniques
en fait ça devient encore des risques humains et des risques de confiance etc
je pense que vraiment c'est...
On parlait de la peur du changement dans le premier
dans le premier numéro de dévobes
là justement, j'ai l'impression que ce qui
peut
supposer du risque, vous faire créer du risque
c'est vraiment le changement de paradigme
qui apporte le dévobes
et justement, les gens
avaient l'habitude de travailler d'une certaine manière
donc on vient de parler du cycle en V
dévobes et la méthode agile
chamboule un petit peu les repères de tout le monde
et donc du coup, on s'en remet vraiment à la confiance
donc on en revient encore au terme de confiance
on s'en remet vraiment à la confiance
et quand il y a des responsabilités en jeu
c'est plus difficile de faire confiance
et je pense que c'est là qu'il y a la notion de risque
et d'échec encore une fois
tous les sujets sont liés
c'est vraiment plus un sujet humain
que technique définitivement
je sais d'accord
je vais passer avec quelque chose de...
non je peux conclure
une petite conclusion sympathique
donc voilà, je voulais aborder un dernier point
c'est que nous ne
n'est pas avec une inclinaison
ou une aversion pour le risque
par exemple, les entrepreneurs
ne sont pas des céréales risqueurs
dotés d'une capacité innée
à jongler avec les risques
le risque n'est pas non plus un privilège
et il n'est pas déifié
car si on le fait c'est la plupart du temps
pour tenter de justifier la caparation
du risque par certains
des chercheurs de l'université de Californie
ont publié en 2013 une étude
montrant que la prise de risque est corrélée
à la fois à l'âge et à l'aisance
financière des individus
au final nous nous trouvons dans une situation
auto-entretenue où la capacité
à prendre des risques et récompenser
est saluée dans la société
est vue comme une vertu alors que cette
même aptitude est monopolisée par
une minorité privilégiée
faut donc démystifier la prise de risque
car c'est un très accessible à tous
dans tous les métiers
il semble alors pertinent de se demander
dans une gymnastique mentale quotidienne
qui risquait vraiment quelque chose
dans cette histoire
un petit conclusion
Super, merci beaucoup
je pense qu'on
peut s'arrêter là
on a bien abordé tous les sujets
je vais remercier
tous les participants
aujourd'hui
Victor, Bartelémy et Marc
dans cet ordre-là
N'oublie pas de te citer aussi
Oui, moi-même Guillaume
je ne vais même pas m'être cité au début
Tu t'es pas introduit je crois
je ne me suis pas s'introduit
je ne sais pas trop comment prendre cette phrase
mais c'est vrai, Guillaume
et voilà j'espère que ça vous a plu
c'était encore un peu différent
de la première fois
Et différent de la prochaine fois
Et sans doute différent de la prochaine fois
mais toujours mieux on l'espère
dans une logique d'amélioration continue
et de confiance dans l'avenir
Et de prise de risque
Je vous dis merci
et à une prochaine fois
on se tient au courant par tous les canaux disponibles
Twitter, SoundCloud
on va peut-être même aussi mettre sur YouTube
ce podcast
N'hésitez pas à commenter
on essaie d'être réactifs là-dessus
de voir un peu tous vos retours
et on espère s'améliorer
pour faire encore plus partager le DevOps
donc merci
à la prochaine
à bientôt
bien ça, au revoir