Pourquoi bloquer par défaut les déploiements le vendredi ? S’interdire de déployer le vendredi, c’est se priver de 20% de temps où l’on peut apporter cette valeur à nos clients. Parfois on s’interdit également le jeudi après-midi, les veilles de jours fériés, on dépasse ainsi les 30%… Pourquoi on bloque ? Pour éviter l'incident de prod à la veille du week-end ... On associe donc déploiement et incident, cela en dit beaucoup sur notre maturité DevOps (Observabilité, CI/CD, Management, ...). Et si on faisait confiance aux équipes pour décider ce qui est pertinent et développer leur maturité pour prendre les bonnes décisions ?

1. ET SI ON DÉPLOYAIT AUSSI LE VENDREDI ?
Christophe Rochefolle, CTO SNCF Connect
17 Novembre 2022
1
@crochefolle @crochefolle@fosstodon.org

2. 2

3. 3

4. 4

5. 5
Mais pourquoi ?

6. 6
RAISON #1 : La MEP qui se passe mal et qui vous fait
rester tard le vendredi soir, voire le samedi matin.

7. 7
RAISON #1 : La MEP qui se passe mal et qui vous fait
rester tard le vendredi soir, voire le samedi matin.
Principes DevOps : une MEP doit être un
non événement technique par la mise en place
:
• d’une pipeline industrialisée,
• des tests automatisés qui génèrent un niveau
de confiance élevée pour envoyer en prod,
• de l’observabilité qui permet de détecter les
incidents,
• voire aussi du "blue green" qui permet de
revenir en arrière instantanément,
• Etc.

8. 8
RAISON #1 : La MEP qui se passe mal et qui vous fait
rester tard le vendredi soir, voire le samedi matin.
Principes DevOps : il faut déployer le plus
fréquemment possible pour réduire la taille
de l’incrément.
Moins on déploie souvent, plus le contenu à
déployer est important donc plus le risque est
élevé.
QUALITÉ

9. 9
RAISON #1 : La MEP qui se passe mal et qui vous fait
rester tard le vendredi soir, voire le samedi matin.
Principes DevOps : You Build it, You Run it
Les équipes – personnes – qui conçoivent les
applications ou services sont ceux qui les
opèrent.
Cela implique notamment que les membres de
l’équipe qui font un changement soient
d’astreintes, gèrent et assument le problème
qu’elles pourraient éventuellement générer.
Ainsi elles mettront tout en œuvre, notamment
les pratiques de sûreté de fonctionnement
pour éviter de perdre ses nuits et week-ends.

10. 10
RAISON #2 : Les incidents se produisent souvent
quelques temps après la MEP et que les équipes soient
parties.

11. 11
RAISON #2 : Les incidents se produisent souvent
quelques temps après la MEP et que les équipes soient
parties.
Pratique DevOps : Observabilité
Les incidents ne se produisent pas quelques temps
après (sauf cas vraiment particuliers), c’est surtout
qu’avec le temps ils prennent une ampleur qui les rend
visibles.
L’instrumentation de la plateforme pour la rendre
observable favorise la sûreté de fonctionnement des
services.

12. 12
RAISON #2 : Les incidents se produisent souvent
quelques temps après la MEP et que les équipes soient
parties.
Principes DevOps : You Build it, You Run it
Cela implique notamment que l’équipe ne
déploie pas le vendredi à 17h et parte en week-
end ou prendre un verre à peine après avoir
appuyé sur le bouton.
Responsabiliser une équipe, lui faire confiance,
c’est lui définir un cadre où elle peut prendre
les décisions de déployer quand elle veut plutôt
que quand elle peut.

13. 13
RAISON #3 : il y a toujours un risque inconnu dans un
changement.
Charity Majors : Chaos Engineering et Observabilité

14. 14
RAISON #3 : il y a toujours un risque inconnu dans un
changement.
Pratiques DevOps : Chaos Engineering
Par définition, on ne peut prévoir l’inconnu, par
contre on peut entraîner notre système
sociotechnique à réagir efficacement face à
l’inconnu, notamment par des pratiques de
Chaos Engineering.

15. 15
RAISON #1 : La MEP qui se passe mal et qui vous
fait rester tard le vendredi soir, voire le samedi
matin.
Interdire le vendredi, c’est mettre l’emphase
sur la peur du déploiement,
augmenter le risque en augmentant le
contenu de ce que l’on déploie et
déresponsabiliser les équipes.
C’est un antipattern de déploiement d’une
démarche DevOps.
RAISON #2 : Les incidents se produisent souvent
quelques temps après la MEP et que les équipes
soient parties.
RAISON #3 : il y a toujours un risque inconnu dans
un changement.

16. 16
PASSER DE LA CULTURE DE LA PEUR
À CELLE DE LA CONFIANCE

17. EN RÉSUMÉ
17
Nous sommes au
service d’une
société durable et
solidaire, et favorisons
des comportements, des
mobilités et des usages
responsables.
CITOYENNETÉ
Oser déployer même
le vendredi… nous
sommes persuadés que c’est
en se basant sur la
responsabilisation de nos
équipes que nous pouvons
garder un temps d’avance.
AUDACE
Pourvoir déployer
quand on veut plutôt
que quand on peut nous
permet d’être plus réactif et de
répondre aux attentes de nos
utilisateurs finaux plus
rapidement.
PERFORMANCE
Nos yeux sont grands
ouverts sur notre production à
l’aide d’une démarche
d’observabilité qui s’améliore
à chaque évènement, tout en
nous ouvrant sur de nouvelles
pratiques comme les Chaos
Engineering pour mieux nous
préparer.
OUVERTURE
Nous croyons en une
culture de la confiance
comme un incontournable de
la réussite d’une démarche
DevOps.
CONFIANCE
https://jobs.connect-tech.sncf/
REJOIGNEZ-NOUS
Une démarche qui s’incarne dans nos valeurs