CloudExpo Europe 2017 - DevOps entre client et fournisseur
-
Upload
ludovic-piot -
Category
Technology
-
view
65 -
download
1
Transcript of CloudExpo Europe 2017 - DevOps entre client et fournisseur
Cloud Expo Europe 2017 – 15-nov
Faire du DevOps
dans une relation client/fournisseur
Le speaker
Ludovic Piot
@lpiot
Responsable du pôle
Conseil, Architecture & DevOps
Agenda
DevOps
disclaimer
le mur de la confusion
une tentative de définition
Infogérance
modèle d’activité en 2015
état des lieux en 2015
infogérance DevOps
modèle renversé
mode projet continu
everything as code
tirer parti du modèle du Cloud
tirer parti de l’héritage des images Docker
convention de service opérationnel
Devops
Tentative de définition
DevOps – disclaimer
“It’s not about the destination,
it’s about the journey” – Gene Kim
DevOps n’est pas une méthodologie.
Il s’agit de créer une culture
dans laquelle Dev et Ops collaborent étroitement et en confiance.
Devops – le mur de la confusion
Depuis toujours, DEV et OPS s’opposent à caused’objectifs antagonistes…
Les DEV recherchent :
la rapidité de mise à disposition des nouvelles
fonctionnalités aux utilisateurs finaux
culture du produit
Les Ops recherchent :
la stabilité, la robustesse
la maîtrise, la performance
la sécurité
l’industrialisation
l’efficience économique
culture du service
Mais il y a confusion : ces objectifs sont des objectifsintermédiaires et non exclusifs !
Devops – une tentative de définition
L’approche DevOps a un objectif unique :
aligner l'ensemble des acteurs et des compétences
du système d’information…
… sur la seule qualité du produit fourni à l'utilisateur
final
Pour cela, la démarche DevOps passe par…
l'engagement de l'ensemble des acteurs sur la chaîne
de production de valeur,
- dans une collaboration libre et sans contrainte
- et le souci d’une amélioration continue
- par le partage d'informations et de responsabilité
- et des outils et méthodes communes
- en vue d'automatiser les actions
- et ainsi d’étendre au maximum l’autonomie des
différents acteurs en dehors de leur périmètre propre
So
urc
e:
Sta
te o
f D
evO
ps
rep
ort
20
16
(Pu
pp
et+
Devo
ps
Rese
arc
h&
Asse
ssm
en
t)
Devops – une tentative de définition
L’approche DevOps
So
urc
e:
Sta
te o
f D
evO
ps
rep
ort
20
16
(Pu
pp
et+
Devo
ps
Rese
arc
h&
Asse
ssm
en
t)
La démarche DevOps
ulture
utomation
easurement
haring
Coût Temps
Qualité Satisfaction
the Beal-Hedemark
golden square
l’Infogérance
Modèle 2015
Transformation digitale
Infogérance – modèle d’activité en 2015
Activité Dispositif
organisationnel
Fonction ITIL Eléments facilitant La promesse La réalité
MCO –
Maintien en
condition
opérationnell
e de
l’application
Horaire :
24/7
équipe élargie
intervenant sur
les plateformes
de tous les
clients (100+)
traitement sur
procédure
ou analyse et
work-around
(rollback)
traitement des
événements et
incidents
augmentation de la
maîtrise par :
standardisat° des
plateformes
(rebuild ou audit)
automatisation
des procédures
GTI – Temps
garanti
d’intervention
(30’ – 1h)
GTR – Temps
garanti de
rétablissement (1
– 3h)
peu de maîtrise
du contexte client
pertinence des
procédures
maîtrise relative
context-switching
implication faible
GCC –
Gestion
continue des
changement
s liés au
projet client
Horaire : 8/5
équipe restreinte
et dédiée aux
plateformes de
quelques clients
mode micro-
projet
déclenchement
par ticket ou lors
des
CoPil/ComOp
résolution des
problèmes
application des
changements
augmentation de la
productivité par :
standardisat° des
plateformes
expertise des
équipes
automatisation
des actions
accompagnemen
t du projet dans
le design et
l’implémentation
de son
architecture
technique
KPIs ?
priorisation et
allocation de
ressource au
coup par coup
(délai)
intervention fire-
and-forget
participation
épisodique au
projet
Infogérance – état des lieux en 2015
Serve
r
Hypervisor
VM
OS
Libs
Middlewar
e
conf.
Apps
Kernel
HDW
conf.
conf.
Storag
e
Network
Logs / M
etr
olo
gy
/ B
ackups
Data
Responsabilité
contractuelle
Réalité
opérationnelle
Contraintes techniques choix d’infrastructure restreint
choix d’architecture technique contraint
partage des outils de déploiement
partage des secrets
Contraintes Organisationnelles concurrence pour la disponibilité des ressources
intégrer des équipes tierces dans le design
d’architecture
interlocuteurs multiples sur la gestion des incidents
organisation à 2 vitesses entre le build et le run
Incompréhension du modèle zones de responsabilité et de forfait flous
Build
build
Run
GC C GC C GC C GC C
buil
d
GC
C?
AP P AP P AP P
AP P AP P AP P AP P
l’Infogérance
DevOps
Infogérance DevOps – modèle renversé
Objectifs
ré-aligner les promesses et la réalité opérationnelle
augmenter la souplesse d’une prestation de service
rétablir la confiance et la collaboration
Eléments du modèles
communication et proximité renforcées
ouverture à des technologies hors-catalogue
partage des outils, et des assets technologiques
propriété du client renforcée
collaboration sur du matériau commun
automatisation maximale
responsabilité partagée
notion de forfait « agile »
Infogérance DevOps – mode projet continu
Inscription dans le projet client
aoption de la méthodologie scrum du client
conception de la backlog partagée avec le client en
tenant compte des sprints
participation aux rituels agiles : stand-up meetings,
sprint planning, démo, rétrospective
partage des outils de gestion de projet du client
(kanban, Jira agile, Pivotal Tracker, Redmine)
plus de GCC, mais du forfait sous forme de sprints avec
le fonctionnement des projets agile : « stop ou encore »
tout nouveau sujet alimente la backlog et est priorisé à
chaque sprint planning
gouvernance technologique (design d’architecture
technique) partagée et assumée par l’ensemble de
l’équipe projet
déplacement chez le client en temps partiel
Infogérance DevOps – everything as code
Partage des assets technologiques
build et maintien de la plateforme en Infra as Code
codebase partagée en lecture/écriture sur les dépôts du
client
validation croisée des contributions Dev et Ops :
tout le monde est
Responsible/Consulted/Informed
les personnes Accountable restent à la
validation
chaîne de delivery portée sur la software factory
partagée avec le client
cohérence du workflow projet
vélocité de chacun immédiatement visible
secrets centralisés dans un Vault partagé (ACL
différenciées)
communication instantanée via outil de chat partagé
(celui du client)
versionning et traçabilité assurés par Git
Infogérance DevOps – tirer parti du modèle du Cloud
Hypervisor
VM
OS
Libs
conf.
Kernel
HDW
Middlewar
e conf.
Apps
conf.
Serve
r
Storag
eNetwork
Logs / Metrology /
Backups
Data
On-premise Iaas PaasResponsabilités
Repréciser la zone de
responsabilité de chaque
acteur… quitte à avoir des
zones de responsabilité
partagées.
Cloud provider
Infogérant
Client
Propriété
Les plateformes Cloud sont
en propriété du client.
Potentielle délégation de
gouvernance.
Caas
Runtime
conf.
Container
conf.
Infogérance DevOps – tirer parti de l’héritage des images Docker
Dev team
Ops teamContainer
Apps
Middl
eware
s
Libs
OS
conf
.
conf
.conf
.
conf
.
Container
Libs
OS
conf
.
conf
.
Image
Container
Middl
eware
s
conf
.
Container
Apps
conf
.
ImageImage
☹️ Not
prod-
ready
Container
Apps
conf
.
😀
prod-ready
😀
prod-
ready Image
😀
prod-
ready
Infogérance DevOps – convention de service opérationnel
objectifs
les éléments contractuels doivent refléter au plus près la
réalité opérationnelle
Démarche
document essentiellement opérationnel connexe au
PAQ, PAS
évolue dans le temps
identifie la réalité du moment (SLAs, KPIs, dispositif
opérationnel)
identifie une cible à atteindre et la backlog pour y aller
est révisée de proche en proche (au ComOp) à chaque
évolution majeure de la plateforme
- architecture
- fréquentation du site
- criticité du business
responsabilité partagée
What’s next?
Questions ?