Cette vidéo présente une réflexion et un retour d'expérience de 2 ans de pratique du DevOps entre un infogérant/hébergeur et les équipes projet de ses clients. Comment ont dû évoluer les dispositifs humain, organisationnel, opérationnel, technologique, contractuel et commercial dans la relation entre l'infogérant fournisseur (plutôt Ops) et ses clients (plutôt Devs). Le speaker : Ludovic Piot a été le créateur et le responsable du pôle Conseil, Architecture et DevOps chez Oxalide pendant 2 ans et demi. Il revient sur les principes de cette mutation dans la relation client-fournisseur vers le DevOps, ses échecs et ses succès et surtout ses objectifs et ses résultats.

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 ?