**time to market**: période entre les premières idées concernant un produit et sa disponibilité éventuelle sur les marchés de consommation répondre au besoin marché
**time to value**: Mesure du temps nécessaire pour que l'entreprise recouvre
la valeur d'une fonctionnalité ou d'un service. crée u ne nouvelle valeur
**agile**: mise en prod par petite itération
**mur de la confution**: les devs et la prod n'on pas les même objectif changement/stabilité
### objectif
- version plus petite et plus fréquente
- limitation de l'impact (effet blast)
- communication inter équipe
- gain de temps -> automatisation
- Vision global et systémique
- casser les Silo
**CALMS**:
- Culture:Valeurs et comportements qui contribuent à instaurer l'environnement social et psychologique
L’ IT n’a plus besoin de s’aligner ou de s’intégrer au business, elle est le business
## principe fondamentaux
### les 3 voies
#### flux: dev vers Ops
comprendre le flux fluidifier ,
outils:lean automatisation
- ne pas transmettre de default
- une optimisation local ne doit pas dégrader de dégradation global
**Value Stream Mapping**:décrit le flux d’informations, de matériaux et de travail entre silos fonctionnels, en mettant l'accent sur DevOps la quantification et l'élimination du gaspillage,
théorie des contraintes
- au moins toujour une contrainte
- limiter au maillons le plus failble (like rando)
- l'amélioration passe par l'optimisation des contraintes
- identifier la contraintes
- exploiter
- subordonner et synchroniser
- élever la performance
- répéter le process
#### feedback: des ops vers les dev , ITSM
rapide
améliorer les pratiques
- monitoring
- automatisation des tests
- post mortem
- donnée de changement, incident
#### experimentation et amélioration coninue
- allouer du temps
- droit a l'erreur
neccessite:
- 3p: Protection, Permission, Puissance
- **assertivité**: voir la valeur de l'autre oposé de la domination
chaos Engineering
- généré des problématique sur une instance de production: permet d'évaluer
encourger une culture d'apprentisasge: voir chatops
**maitrise** répétition et entrainnement
## Principal pratiques de DevOps
### tests en continue
décalage a gauche: meilleure qualité lors de dev évute les proléme de mise en prod
test fonctionnelle: unitaire
test non fonctionelle: capacité, securité, performance
test-driven development: création des tests avant le dev
### intégration continue
commit régulier: lancement des test..
### continous delivery
s'assurer que le logiciel est toujour dans un étét livrable (s'arréte a la QA)
### continous deploiement
continue delivery jusqu'en Prod
### Site Reliability Engineering
mettre en place la resilience,
capacité du systéme a s'adapter
### ChatOps
partage entre les équipee
### KanBan
- notion importante de la capacité pour chaque "colonne"
- je vais cherché l'activité (Pul)
- lead time: entré de backlog et fin de process
- cycle time: entré dans le process et fin de process
- temps de backog= lead time - cycle time
- visualiser les contraintes
## Frameworks business et technologique
### Agile
valeur sur kes individu plutot que les pocesss
manifase agile
| valorisé | plutot que |
|---|---|
|individus|Processus et Outils|
|logiciel opé|doc exhaustive|
|collaboration avec les clients| Négociation contractuelle|
|adapatation au changement|suivre un plan|
- truc qui fonctionne plutot que la doc
#### SCRUM
- livrer pendant une période définie (sprint)
- itération fonctionnelle
- User stories: demandes rédigée du point de vue client
| responsabilité évitées | responsabilité sont compartimentalisées | les responsabilité sont partagées |
| les lien direct sont découagé | lien direct non encourager | lien direct sont récompensé |
| echec couvert | organisation juste est pardonne | echec entraine une investigation |
| originamité bridée | originaité crée des problémes | originalité mise en avant |
- les gens n'offrent pas de résistance a leur propres idées, **il ne peuvent que ce changer eux même**
- implication des partie prenante impérative
- une personne impliquer dans les décisions est plus suceptible d'acepter le changement
### étape de l'aceptation du changement: courbe de kubler ross
- choc
- denie
- frustration
- depression
- experiment
- decision
- Integration
communication rapide est effice neccessaire #ChatOps
### Encourager la collaboration
- volontaire
- partagé
- fournir des feedback
- partage des connaissances
- partage des responsabilité
- engagement réalilste
### s'attendre au conflit
inventaire des conflits de Thomas-Kilmann (erreur dans le tableau?)
### Eviter la fatigue aux changement
> Le degré de fatigue face aux changements ressentie par les personnes est directement liée à la façon dont le changement est géré.
- génére de l'**apathie**
- elle est normal
- expliquer les raisons
- montrer les interconnection
- avoir un feedback
- célébrer les succée
### Valorisé les nouveux changements
- expérience d'immerssion
- Team Building
- Hackaton
- communité (guilde)
## Automatisation
un outils par servce
avantage de l'Automatisation:
- indepotent
- environement maitrisé
- moins d'incidents
**artefact**: tout objet compris dans objet (documentation,plan de test , images, fichier de donnée...)
**API**: interface entre des module ou des applications
**Microservices**: logicielle composée de modules plus petits qui interagissent via des API
**Virtualisation**: VM ou conteneurs isolation de l'environnement
**Open Source** : logiciel distribué avec le code sources
**Machine Learning**: analyse de données utilisanr des données.
### Cloud, conteneurs et Microservices
IAS: délégation de la partie Infra
PAS: gestion de l'os, database déléger on ne gére uniquement l'applications
SAS: office 365
### IA & Machine Learning
Analyse de données qui utilise des algorithmes pour apprendre des données.
- analyse de log ...
### Infrastructure as code
un grand pouvoir implique de grande responsabilité
### Automatisation de la communication
- alarmes
- améliorer la réponse
- collaboration virtuelle
### premiére étapes de l'Automatisation
- définir l'architecture
- évaluer l'existant
- automatier le travail a haute valeur ajoutée, répétitif et sujet aux erreurs
- Optimiser les goulots d'étrangleemnt
- **pouvoir évoluer avec le temps**
- modéliser
- automaitiser les process de déploiement et de versions Build
- automatiser les test unitaire
- automatiser les tests d'acceptation (UAT)
- automatiser la mise en prod
### Toolchains
- chaque élément sert un objectif particulier
- les interfaces sont assuré par des API
- elle ne doivent pas tous être fournit par le même fournissuer
- neccessite une conception architectural
- **elle doit être évolutif**
example d'élément:
- Gestion des exigences
- Orchestration et visualisation
- Gestion des versions
- Intégration continue et versions
- Gestion des artefacts
- Virtualisation de conteneurs et de systèmes
- d'exploitation
- Automatisation des tests et de l'environnement
- Configuration et déploiement du serveur
- Gestion de la configuration du système
- Alertes et alarmes
- Monitoring
modéliser la chane de valueur -> automatiser les release -> automatiser les test unitaire et le coverage -> automatiser les test d'acceptation -> automatiser la mise en prod -> amélioration continue
## Mesures, indicateurs et reporting
si on ne peut pas mesurer on ne peu pas améliorer
- mesurer la vitesse: fréquence, vitesse de déploiement
- qualité: Taux d'echec des changement
- stabilité: MTTD délai moyen de detection des incident, MTTR délai de réparation, MTRS Délai moyen de rétablisement du service
- Culture: Engagement et moral, partage de connaissances.
1er voies: Les mesures nous permettent de trouver des contraintes
2 éme voies: Les preuves créent la confiance et permettent de faire plus
3 éme voies: Les hypothèses nécessitent des résultats quantifiables pour déterminer la prochaine expérience