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 ?