1.
Cloud Expo Europe 2017 – 15-nov
Faire du DevOps
dans une relation client/fournisseur

2.
Le speaker
Ludovic Piot
@lpiot
Responsable du pôle
Conseil, Architecture & DevOps

3.
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

4.
Devops
Tentative de définition

5.
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.

6.
Devops – le mur de la confusion
Depuis toujours, DEV et OPS s’opposent à cause
d’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 objectifs
intermédiaires et non exclusifs !

7.
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
Source:StateofDevOpsreport2016
(Puppet+DevopsResearch&Assessment)

8.
Devops – une tentative de définition
L’approche DevOps
Source:StateofDevOpsreport2016
(Puppet+DevopsResearch&Assessment)
La démarche DevOps
ulture
utomation
easurement
haring
Coût Temps
Qualité Satisfaction
the Beal-Hedemark
golden square

9.
l’Infogérance
Modèle 2015

10.
Transformation digitale

11.
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
 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

12.
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/Metrology/Backups
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
PAP
P
AP
P

13.
l’Infogérance
DevOps

14.
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 »

15.
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

16.
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

17.
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
e
Network
Logs / Metrology /
Backups
Data
On-premise Iaas Paas
Responsabilité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.

18.
Infogérance DevOps – tirer parti de l’héritage des images Docker
Dev team
Ops team
Container
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

19.
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

20.
What’s next?

21.
Questions ?