Ingénierie de la fiabilité des sites
 |
Description
Introduction au livre
Un livre plein d'inspiration pour vous aider à passer au niveau supérieur !
Découvrez le principe de Google selon lequel le code qui fonctionne réellement est le plus important !
La durée de vie d'un système logiciel est généralement déterminée par la période pendant laquelle il est effectivement utilisé, et non par sa phase de conception ou de mise en œuvre.
Alors pourquoi les ingénieurs logiciels ont-ils considéré le processus de conception et de mise en œuvre des systèmes informatiques à grande échelle comme étant de la plus haute importance ?
Dans cet ouvrage, les principaux membres de l'équipe d'ingénierie de la fiabilité des sites de Google expliquent, à travers des essais et des éditoriaux, comment et pourquoi ils mettent en œuvre, déploient, surveillent et maintiennent le plus grand système logiciel au monde en se concentrant sur l'ensemble du cycle de vie du logiciel.
Cela vous permettra d'appliquer à votre propre organisation les principes et les pratiques qui ont permis aux ingénieurs de Google de concevoir des systèmes plus évolutifs, fiables et efficaces.
Contenu principal de ce livre
*Introduction : Présente ce qu’est l’ingénierie de la fiabilité des sites et en quoi elle diffère des pratiques informatiques traditionnelles.
*Principes : Présente les modèles, les comportements et les différents problèmes qui affectent le travail des ingénieurs en fiabilité des sites.
*Étude de cas : Découvrez la théorie et les études de cas relatives à la conception et à l’exploitation de systèmes informatiques distribués à grande échelle, ce qui fait partie du travail quotidien d’un ingénieur SRE.
*Gestion : Découvrez comment appliquer au sein de votre propre organisation les pratiques recommandées par Google en matière de formation des nouveaux employés, de communication et de gestion des réunions.
Découvrez le principe de Google selon lequel le code qui fonctionne réellement est le plus important !
La durée de vie d'un système logiciel est généralement déterminée par la période pendant laquelle il est effectivement utilisé, et non par sa phase de conception ou de mise en œuvre.
Alors pourquoi les ingénieurs logiciels ont-ils considéré le processus de conception et de mise en œuvre des systèmes informatiques à grande échelle comme étant de la plus haute importance ?
Dans cet ouvrage, les principaux membres de l'équipe d'ingénierie de la fiabilité des sites de Google expliquent, à travers des essais et des éditoriaux, comment et pourquoi ils mettent en œuvre, déploient, surveillent et maintiennent le plus grand système logiciel au monde en se concentrant sur l'ensemble du cycle de vie du logiciel.
Cela vous permettra d'appliquer à votre propre organisation les principes et les pratiques qui ont permis aux ingénieurs de Google de concevoir des systèmes plus évolutifs, fiables et efficaces.
Contenu principal de ce livre
*Introduction : Présente ce qu’est l’ingénierie de la fiabilité des sites et en quoi elle diffère des pratiques informatiques traditionnelles.
*Principes : Présente les modèles, les comportements et les différents problèmes qui affectent le travail des ingénieurs en fiabilité des sites.
*Étude de cas : Découvrez la théorie et les études de cas relatives à la conception et à l’exploitation de systèmes informatiques distribués à grande échelle, ce qui fait partie du travail quotidien d’un ingénieur SRE.
*Gestion : Découvrez comment appliquer au sein de votre propre organisation les pratiques recommandées par Google en matière de formation des nouveaux employés, de communication et de gestion des réunions.
- Vous pouvez consulter un aperçu du contenu du livre.
Aperçu
indice
PREMIÈRE PARTIE INTRODUCTION
CHAPITRE 01 Introduction _ 3
Comment utiliser les administrateurs système pour la gestion des services _ 3
La solution de Google pour la gestion des services : Ingénierie de la fiabilité des sites _ 5
Credo de SRE _ 8
En conclusion _ 14
CHAPITRE 02 L'environnement de production de Google du point de vue SRE 15
Matériel _ 15
Logiciel système qui « optimise » le matériel _ 17
Autres logiciels système _ 21
Infrastructure logicielle _ 22
Environnement de développement _ 23
Shakespeare : Exemple de service _ 24
PARTIE II PRINCIPES ET RÈGLES
CHAPITRE 03 Accepter les risques _ 30
Gestion des facteurs de risque _ 31
Mesure du risque de service _ 32
Acceptation des risques liés au service _ 34
Utilisation du budget d'erreur _ 40
CHAPITRE 04 Objectifs de niveau de service _ 44
Terminologie relative au niveau de service _ 45
Paramètres des indicateurs _ 48
Exercice de fixation d'objectifs _ 51
Exercice sur l'accord _ 56
CHAPITRE 05 Plus de fouilles ! _ 57
Définition du creusement _ 58
Raisons pour lesquelles moins creuser est une bonne chose _ 60
Quels types de travaux relèvent de l'ingénierie ? _ 61
Creuser est-il toujours une mauvaise chose ? _ 62
Conclusion _ 63
CHAPITRE 06 Surveillance des systèmes distribués _ 64
Définition _ 64
Pourquoi surveiller ? _ 66
Définir des attentes appropriées en matière de suivi _ 67
Symptômes et causes _ 68
Boîte noire et boîte blanche _ 69
Quatre indicateurs cruciaux _ 70
Considérations relatives à la dernière requête (ou à l'exécution et aux performances) _ 72
Choisir la bonne méthode de mesure _ 72
Pas plus simple, mais aussi simple que possible _ 73
En combinant les principes que nous avons abordés jusqu'à présent _ 74
Surveillance à long terme _ 76
Conclusion _ 78
CHAPITRE 07 L'automatisation avancée de Google _ 80
La valeur de l'automatisation _ 81
La valeur de Google SRE _ 83
Étude de cas sur l'automatisation _ 85
Faites-vous une faveur : automatisez tout ! _ 88
Un mouvement divin : Automatisation des mises en service de clusters _ 91
Vogue : La naissance d’un ordinateur de la taille d’un entrepôt _ 98
La fiabilité est une fonction fondamentale _ 101
Recommandations _ 101
CHAPITRE 08 Ingénierie des versions _ 103
Le rôle d'un ingénieur de mise en production _ 104
La philosophie de l'ingénierie des mises en production _ 104
Intégration et déploiement continus _ 106
Techniques de gestion de la configuration _ 111
Conclusion _ 112
CHAPITRE 09 Concision _ 114
Stabilité du système vs.
Rapidité _ 115
La vertu de l'ennui _ 115
Mon code n'abandonnera jamais ! _ 116
Indicateur de « code d'impact négatif » _ 116
API minimale _ 117
Modularisation _ 117
Simplification des versions _ 118
Conclusion concise _ 119
PARTIE III ÉTUDE DE CAS
CHAPITRE 10 Rappels pratiques pour les données de séries chronologiques _ 127
La Naissance de Borgmon _ 128
Manipulation de l'application _ 130
Collecte des données exportées _ 131
Stockage des données de séries temporelles _ 132
Évaluation des règles _ 135
Notification _ 140
Partitionnement dans les topologies de surveillance _ 141
Surveillance boîte noire _ 142
Gestion des paramètres _ 143
Au cours des 10 dernières années… _ 145
CHAPITRE 11 Dispositif de secours _ 146
Introduction _ 146
La vie d'un ingénieur en intervention d'urgence _ 147
Équilibrer le travail de veille d'urgence _ 148
Considérant la sécurité _ 150
Échappement aux charges de fonctionnement inappropriées _ 153
Conclusion _ 155
CHAPITRE 12 Basculement efficace _ 156
Théorie _ 157
Passons au monde réel _ 159
La magie des résultats négatifs _ 168
Étude de cas _ 171
Faciliter la prise en charge des personnes handicapées _ 175
Conclusion _ 176
CHAPITRE 13 INTERVENTION D'URGENCE _ 177
Que dois-je faire si quelque chose ne va pas avec mon système ? _ 178
Défaillances induites par les essais _ 178
Invalidité due au changement _ 180
Obstacles procéduraux _ 183
Tous les problèmes sont résolus _ 186
Tirez les leçons du passé.
Et ne répétez pas _ 186
Conclusion _ 188
CHAPITRE 14 GESTION DES HANDICAPS _ 189
Gestion inadéquate de l'invalidité _ 190
Analyse détaillée de la prise en charge inadéquate des personnes handicapées _ 191
Principes fondamentaux des procédures de gestion de l'invalidité _ 191
Basculement correctement géré _ 194
Quand faut-il déclarer un handicap ? _ 195
Résumé _ 196
CHAPITRE 15 Culture post-mortem : tirer des leçons de l’échec _ 197
La philosophie post-mortem de Google _ 198
Collaboration et partage des connaissances _ 200
Introduction à la culture post-mortem _ 201
Conclusion et amélioration continue _ 204
CHAPITRE 16 SUIVI DES PANNEAUX DE SYSTÈME _ 205
Escalier mécanique _ 206
Outerator _ 206
CHAPITRE 17 Tests de fiabilité _ 212
Types de tests logiciels _ 214
Configuration de l'environnement de test et de compilation _ 221
Tests en environnements à grande échelle _ 223
Conclusion _ 237
CHAPITRE 18 Ingénierie logicielle dans les organisations SRE _ 238
Pourquoi les compétences en génie logiciel sont importantes dans les organisations SRE _ 239
Étude de cas Auxon : Contexte du projet et origine des problèmes _ 240
Planification des capacités fondée sur l'intention _ 244
Comment promouvoir l'ingénierie logicielle au sein de votre organisation SRE _ 254
Conclusion _ 259
CHAPITRE 19 Équilibrage de la charge avant _ 260
Tout ne peut pas être résolu par la force seule _ 260
Équilibrage de charge via DNS _ 262
Équilibrage de charge à l'aide d'adresses IP virtuelles _ 265
CHAPITRE 20 Équilibrage de charge dans les centres de données _ 268
Cas idéal _ 269
Distinguer les tâches problématiques : contrôle des flux et tâches inefficaces _ 271
Limitation du pool de connexions à l'aide de sous-ensembles _ 273
Politique d'équilibrage de charge _ 280
CHAPITRE 21 Gestion des surcharges _ 287
Les pièges du « nombre de requêtes par seconde » _ 288
Limites par utilisateur _ 289
Limites d'utilisation côté client _ 290
Importance _ 292
Signaux d'utilisation _ 294
Gestion des erreurs de surcharge _ 295
Charge sur la connexion _ 299
Conclusion _ 300
CHAPITRE 22 Gestion des défaillances continues _ 302
Causes d'invalidité permanente et contre-mesures _ 303
Prévention de la surcharge du serveur _ 309
Démarrage lent et mise en cache à froid _ 320
Causes d'invalidité continue _ 323
Tests de défaillance continue _ 325
Réponse immédiate aux défaillances continues _ 328
En conclusion _ 331
CHAPITRE 23 Gestion des états critiques : Accord sur la fiabilité distribuée _ 332
Pourquoi le consensus est nécessaire : Échecs de la collaboration dans les systèmes distribués _ 335
Comment fonctionne le consensus sur la blockchain distribuée _ 337
Modèles d'architecture système pour le consensus distribué _ 339
Performance du consensus distribué _ 345
Déploiement d'un système distribué basé sur le consensus _ 354
Surveillance des systèmes de consensus distribués _ 364
Conclusion _ 365
CHAPITRE 24 Planification périodique distribuée avec Cron _ 366
Cron_367
Tâches Cron et idempotence _ 368
Cron dans les grands systèmes _ 369
Service Cron implémenté par Google _ 371
Résumé _ 379
CHAPITRE 25 PIPELINE DE TRAITEMENT DES DONNÉES _ 380
Les origines du modèle de conception Pipeline _ 380
Les effets fondamentaux du Big Data à l'aide d'un modèle de pipeline simple _ 381
Défis du modèle de pipeline régulier _ 381
Problèmes découlant d'une répartition inégale du travail _ 382
Inconvénients des pipelines classiques dans les environnements distribués _ 383
Présentation de Google Workflow _ 387
Étapes d'exécution du flux de travail _ 389
Assurer la pérennité de l'entreprise _ 391
Résumé _ 392
CHAPITRE 26 INTÉGRITÉ DES DONNÉES : JE DOIS ÊTRE PRÊT À LIRE CE QUE J’ÉCRIS _ 394
Conditions critiques pour l'intégrité des données _ 395
Objectifs de Google SRE pour le maintien de l'intégrité et de la disponibilité des données _ 401
Comment Google résout les problèmes d'intégrité des données _ 406
Étude de cas _ 419
Principes généraux de l'ingénierie de la fiabilité des systèmes (SRE) relatifs à l'intégrité des données _ 427
Conclusion _ 429
CHAPITRE 27 : Lancement de produits fiables dans des environnements à volume élevé _ 430
Ingénierie de coordination des mises en production _ 432
Établissement d'une procédure de lancement _ 434
Élaboration d'une liste de contrôle de lancement _ 438
Techniques pour un lâcher stable _ 443
Capacités de développement de LCE _ 448
Conclusion _ 452
PARTIE IV GESTION
CHAPITRE 28 : Favoriser la croissance de l’ingénierie de la fiabilité des systèmes (SRE) au-delà de la veille d’urgence _ 456
J'ai embauché un nouveau SRE.
Que dois-je faire maintenant ? _ 456
Première expérience d'apprentissage : une étude de cas sur la structure pour prévenir la confusion _ 459
Ingénieurs en rétro-ingénierie et penseurs improvisateurs – 463
Cinq principes pour les futurs ingénieurs en intervention d'urgence _ 467
Au-delà de la veille d'urgence : rites de passage et pratiques d'apprentissage continu _ 473
En conclusion _ 474
CHAPITRE 29 Gérer les distractions _ 475
Gestion des charges de travail opérationnelles _ 476
Facteurs déterminant la gestion des distractions _ 477
Machine imparfaite _ 478
CHAPITRE 30 : Se libérer du fardeau des tâches opérationnelles grâce à SRE _ 486
Étape 1 : Se renseigner sur le service et comprendre le contexte _ 487
Étape 2 : Partage du contexte _ 489
Étape 3 : Conduire le changement _ 491
Conclusion _ 494
CHAPITRE 31 Communication et collaboration en SRE _ 495
Communication : Réunion sur l'environnement opérationnel _ 497
Collaboration avec les SRE _ 501
Étude de cas sur la collaboration en SRE : Viceroy _ 503
Collaboration avec des organisations extérieures à SRE _ 509
Étude de cas : Migration de DFP vers F1 _ 510
Conclusion _ 512
CHAPITRE 32 Amélioration du modèle de participation SRE _ 513
Présentation de SRE : définition, fonctionnement et raisons d’être _ 513
Modèle PRR _ 514
Modèle d'introduction SRE _ 515
Évaluation de l'état de préparation de l'environnement opérationnel : un modèle PRR simple _ 517
Évolution d'un modèle PRR simple : Engagement précoce _ 521
Amélioration du développement de services : cadres et plateformes SRE _ 524
Conclusion _ 529
PARTIE V CONCLUSION
CHAPITRE 33 Leçons tirées d'autres secteurs d'activité _ 533
Présentation des experts du secteur _ 534
Préparation et essais en cas de catastrophe _ 536
Culture post-mortem _ 540
Éliminer les tâches répétitives et les frais généraux opérationnels grâce à l'automatisation _ 542
Prise de décision structurée et rationnelle _ 544
Conclusion _ 546
CHAPITRE 34 Conclusion _ 547
APPENDICE.
supplément
ANNEXE A Tableau de disponibilité _ 551
ANNEXE B Recueil de pratiques recommandées pour les services opérationnels _ 553
ANNEXE C Exemple de document d'état de défaillance _ 559
ANNEXE D Exemples post-mortem _ 561
ANNEXE E Liste de contrôle de coordination du lancement _ 566
ANNEXE F Exemple de réunion produit _ 569
Références _ 573
Recherche _ 584
CHAPITRE 01 Introduction _ 3
Comment utiliser les administrateurs système pour la gestion des services _ 3
La solution de Google pour la gestion des services : Ingénierie de la fiabilité des sites _ 5
Credo de SRE _ 8
En conclusion _ 14
CHAPITRE 02 L'environnement de production de Google du point de vue SRE 15
Matériel _ 15
Logiciel système qui « optimise » le matériel _ 17
Autres logiciels système _ 21
Infrastructure logicielle _ 22
Environnement de développement _ 23
Shakespeare : Exemple de service _ 24
PARTIE II PRINCIPES ET RÈGLES
CHAPITRE 03 Accepter les risques _ 30
Gestion des facteurs de risque _ 31
Mesure du risque de service _ 32
Acceptation des risques liés au service _ 34
Utilisation du budget d'erreur _ 40
CHAPITRE 04 Objectifs de niveau de service _ 44
Terminologie relative au niveau de service _ 45
Paramètres des indicateurs _ 48
Exercice de fixation d'objectifs _ 51
Exercice sur l'accord _ 56
CHAPITRE 05 Plus de fouilles ! _ 57
Définition du creusement _ 58
Raisons pour lesquelles moins creuser est une bonne chose _ 60
Quels types de travaux relèvent de l'ingénierie ? _ 61
Creuser est-il toujours une mauvaise chose ? _ 62
Conclusion _ 63
CHAPITRE 06 Surveillance des systèmes distribués _ 64
Définition _ 64
Pourquoi surveiller ? _ 66
Définir des attentes appropriées en matière de suivi _ 67
Symptômes et causes _ 68
Boîte noire et boîte blanche _ 69
Quatre indicateurs cruciaux _ 70
Considérations relatives à la dernière requête (ou à l'exécution et aux performances) _ 72
Choisir la bonne méthode de mesure _ 72
Pas plus simple, mais aussi simple que possible _ 73
En combinant les principes que nous avons abordés jusqu'à présent _ 74
Surveillance à long terme _ 76
Conclusion _ 78
CHAPITRE 07 L'automatisation avancée de Google _ 80
La valeur de l'automatisation _ 81
La valeur de Google SRE _ 83
Étude de cas sur l'automatisation _ 85
Faites-vous une faveur : automatisez tout ! _ 88
Un mouvement divin : Automatisation des mises en service de clusters _ 91
Vogue : La naissance d’un ordinateur de la taille d’un entrepôt _ 98
La fiabilité est une fonction fondamentale _ 101
Recommandations _ 101
CHAPITRE 08 Ingénierie des versions _ 103
Le rôle d'un ingénieur de mise en production _ 104
La philosophie de l'ingénierie des mises en production _ 104
Intégration et déploiement continus _ 106
Techniques de gestion de la configuration _ 111
Conclusion _ 112
CHAPITRE 09 Concision _ 114
Stabilité du système vs.
Rapidité _ 115
La vertu de l'ennui _ 115
Mon code n'abandonnera jamais ! _ 116
Indicateur de « code d'impact négatif » _ 116
API minimale _ 117
Modularisation _ 117
Simplification des versions _ 118
Conclusion concise _ 119
PARTIE III ÉTUDE DE CAS
CHAPITRE 10 Rappels pratiques pour les données de séries chronologiques _ 127
La Naissance de Borgmon _ 128
Manipulation de l'application _ 130
Collecte des données exportées _ 131
Stockage des données de séries temporelles _ 132
Évaluation des règles _ 135
Notification _ 140
Partitionnement dans les topologies de surveillance _ 141
Surveillance boîte noire _ 142
Gestion des paramètres _ 143
Au cours des 10 dernières années… _ 145
CHAPITRE 11 Dispositif de secours _ 146
Introduction _ 146
La vie d'un ingénieur en intervention d'urgence _ 147
Équilibrer le travail de veille d'urgence _ 148
Considérant la sécurité _ 150
Échappement aux charges de fonctionnement inappropriées _ 153
Conclusion _ 155
CHAPITRE 12 Basculement efficace _ 156
Théorie _ 157
Passons au monde réel _ 159
La magie des résultats négatifs _ 168
Étude de cas _ 171
Faciliter la prise en charge des personnes handicapées _ 175
Conclusion _ 176
CHAPITRE 13 INTERVENTION D'URGENCE _ 177
Que dois-je faire si quelque chose ne va pas avec mon système ? _ 178
Défaillances induites par les essais _ 178
Invalidité due au changement _ 180
Obstacles procéduraux _ 183
Tous les problèmes sont résolus _ 186
Tirez les leçons du passé.
Et ne répétez pas _ 186
Conclusion _ 188
CHAPITRE 14 GESTION DES HANDICAPS _ 189
Gestion inadéquate de l'invalidité _ 190
Analyse détaillée de la prise en charge inadéquate des personnes handicapées _ 191
Principes fondamentaux des procédures de gestion de l'invalidité _ 191
Basculement correctement géré _ 194
Quand faut-il déclarer un handicap ? _ 195
Résumé _ 196
CHAPITRE 15 Culture post-mortem : tirer des leçons de l’échec _ 197
La philosophie post-mortem de Google _ 198
Collaboration et partage des connaissances _ 200
Introduction à la culture post-mortem _ 201
Conclusion et amélioration continue _ 204
CHAPITRE 16 SUIVI DES PANNEAUX DE SYSTÈME _ 205
Escalier mécanique _ 206
Outerator _ 206
CHAPITRE 17 Tests de fiabilité _ 212
Types de tests logiciels _ 214
Configuration de l'environnement de test et de compilation _ 221
Tests en environnements à grande échelle _ 223
Conclusion _ 237
CHAPITRE 18 Ingénierie logicielle dans les organisations SRE _ 238
Pourquoi les compétences en génie logiciel sont importantes dans les organisations SRE _ 239
Étude de cas Auxon : Contexte du projet et origine des problèmes _ 240
Planification des capacités fondée sur l'intention _ 244
Comment promouvoir l'ingénierie logicielle au sein de votre organisation SRE _ 254
Conclusion _ 259
CHAPITRE 19 Équilibrage de la charge avant _ 260
Tout ne peut pas être résolu par la force seule _ 260
Équilibrage de charge via DNS _ 262
Équilibrage de charge à l'aide d'adresses IP virtuelles _ 265
CHAPITRE 20 Équilibrage de charge dans les centres de données _ 268
Cas idéal _ 269
Distinguer les tâches problématiques : contrôle des flux et tâches inefficaces _ 271
Limitation du pool de connexions à l'aide de sous-ensembles _ 273
Politique d'équilibrage de charge _ 280
CHAPITRE 21 Gestion des surcharges _ 287
Les pièges du « nombre de requêtes par seconde » _ 288
Limites par utilisateur _ 289
Limites d'utilisation côté client _ 290
Importance _ 292
Signaux d'utilisation _ 294
Gestion des erreurs de surcharge _ 295
Charge sur la connexion _ 299
Conclusion _ 300
CHAPITRE 22 Gestion des défaillances continues _ 302
Causes d'invalidité permanente et contre-mesures _ 303
Prévention de la surcharge du serveur _ 309
Démarrage lent et mise en cache à froid _ 320
Causes d'invalidité continue _ 323
Tests de défaillance continue _ 325
Réponse immédiate aux défaillances continues _ 328
En conclusion _ 331
CHAPITRE 23 Gestion des états critiques : Accord sur la fiabilité distribuée _ 332
Pourquoi le consensus est nécessaire : Échecs de la collaboration dans les systèmes distribués _ 335
Comment fonctionne le consensus sur la blockchain distribuée _ 337
Modèles d'architecture système pour le consensus distribué _ 339
Performance du consensus distribué _ 345
Déploiement d'un système distribué basé sur le consensus _ 354
Surveillance des systèmes de consensus distribués _ 364
Conclusion _ 365
CHAPITRE 24 Planification périodique distribuée avec Cron _ 366
Cron_367
Tâches Cron et idempotence _ 368
Cron dans les grands systèmes _ 369
Service Cron implémenté par Google _ 371
Résumé _ 379
CHAPITRE 25 PIPELINE DE TRAITEMENT DES DONNÉES _ 380
Les origines du modèle de conception Pipeline _ 380
Les effets fondamentaux du Big Data à l'aide d'un modèle de pipeline simple _ 381
Défis du modèle de pipeline régulier _ 381
Problèmes découlant d'une répartition inégale du travail _ 382
Inconvénients des pipelines classiques dans les environnements distribués _ 383
Présentation de Google Workflow _ 387
Étapes d'exécution du flux de travail _ 389
Assurer la pérennité de l'entreprise _ 391
Résumé _ 392
CHAPITRE 26 INTÉGRITÉ DES DONNÉES : JE DOIS ÊTRE PRÊT À LIRE CE QUE J’ÉCRIS _ 394
Conditions critiques pour l'intégrité des données _ 395
Objectifs de Google SRE pour le maintien de l'intégrité et de la disponibilité des données _ 401
Comment Google résout les problèmes d'intégrité des données _ 406
Étude de cas _ 419
Principes généraux de l'ingénierie de la fiabilité des systèmes (SRE) relatifs à l'intégrité des données _ 427
Conclusion _ 429
CHAPITRE 27 : Lancement de produits fiables dans des environnements à volume élevé _ 430
Ingénierie de coordination des mises en production _ 432
Établissement d'une procédure de lancement _ 434
Élaboration d'une liste de contrôle de lancement _ 438
Techniques pour un lâcher stable _ 443
Capacités de développement de LCE _ 448
Conclusion _ 452
PARTIE IV GESTION
CHAPITRE 28 : Favoriser la croissance de l’ingénierie de la fiabilité des systèmes (SRE) au-delà de la veille d’urgence _ 456
J'ai embauché un nouveau SRE.
Que dois-je faire maintenant ? _ 456
Première expérience d'apprentissage : une étude de cas sur la structure pour prévenir la confusion _ 459
Ingénieurs en rétro-ingénierie et penseurs improvisateurs – 463
Cinq principes pour les futurs ingénieurs en intervention d'urgence _ 467
Au-delà de la veille d'urgence : rites de passage et pratiques d'apprentissage continu _ 473
En conclusion _ 474
CHAPITRE 29 Gérer les distractions _ 475
Gestion des charges de travail opérationnelles _ 476
Facteurs déterminant la gestion des distractions _ 477
Machine imparfaite _ 478
CHAPITRE 30 : Se libérer du fardeau des tâches opérationnelles grâce à SRE _ 486
Étape 1 : Se renseigner sur le service et comprendre le contexte _ 487
Étape 2 : Partage du contexte _ 489
Étape 3 : Conduire le changement _ 491
Conclusion _ 494
CHAPITRE 31 Communication et collaboration en SRE _ 495
Communication : Réunion sur l'environnement opérationnel _ 497
Collaboration avec les SRE _ 501
Étude de cas sur la collaboration en SRE : Viceroy _ 503
Collaboration avec des organisations extérieures à SRE _ 509
Étude de cas : Migration de DFP vers F1 _ 510
Conclusion _ 512
CHAPITRE 32 Amélioration du modèle de participation SRE _ 513
Présentation de SRE : définition, fonctionnement et raisons d’être _ 513
Modèle PRR _ 514
Modèle d'introduction SRE _ 515
Évaluation de l'état de préparation de l'environnement opérationnel : un modèle PRR simple _ 517
Évolution d'un modèle PRR simple : Engagement précoce _ 521
Amélioration du développement de services : cadres et plateformes SRE _ 524
Conclusion _ 529
PARTIE V CONCLUSION
CHAPITRE 33 Leçons tirées d'autres secteurs d'activité _ 533
Présentation des experts du secteur _ 534
Préparation et essais en cas de catastrophe _ 536
Culture post-mortem _ 540
Éliminer les tâches répétitives et les frais généraux opérationnels grâce à l'automatisation _ 542
Prise de décision structurée et rationnelle _ 544
Conclusion _ 546
CHAPITRE 34 Conclusion _ 547
APPENDICE.
supplément
ANNEXE A Tableau de disponibilité _ 551
ANNEXE B Recueil de pratiques recommandées pour les services opérationnels _ 553
ANNEXE C Exemple de document d'état de défaillance _ 559
ANNEXE D Exemples post-mortem _ 561
ANNEXE E Liste de contrôle de coordination du lancement _ 566
ANNEXE F Exemple de réunion produit _ 569
Références _ 573
Recherche _ 584
Dans le livre
Par ailleurs, la capacité à résoudre des problèmes complexes par le développement de systèmes logiciels et le talent associé à cette tâche ont été cités comme des qualités essentielles pour les ingénieurs SRE. Au sein de l'équipe SRE, nous avons suivi de près l'évolution des compétences de ces deux groupes et, à ce jour, nous n'avons constaté aucune différence significative dans leurs performances.
En réalité, les différences de parcours au sein de l'équipe SRE ont souvent conduit à la création de systèmes uniques et de haute qualité intégrant de multiples technologies.
--- p.6
Comprendre dans quelle mesure votre système répond aux attentes vous aide à décider s'il convient d'investir pour le rendre plus rapide, plus disponible et plus résilient.
Par ailleurs, si le système fonctionne bien, le temps du personnel peut être consacré à des tâches plus prioritaires, telles que la réduction de la dette technique, l'ajout de nouvelles fonctionnalités ou le développement d'autres produits.
--- p.56
Le système possède une inertie.
Nous avons constaté qu'un système informatique fonctionnant correctement tend à continuer de fonctionner jusqu'à ce qu'un facteur externe, tel qu'un changement de configuration ou un changement du type de charge de service, survienne.
Le meilleur point de départ pour comprendre ce qui ne va pas est donc le changement le plus récent.
--- p.165
Une manière raisonnable de mettre en œuvre un algorithme de sélection de sous-ensemble consiste à faire en sorte que chaque client mélange aléatoirement la liste des serveurs d'arrière-plan, puis sélectionne les serveurs d'arrière-plan accessibles et en bon état pour constituer un sous-ensemble.
La méthode consistant à mélanger aléatoirement puis à sélectionner séquentiellement les serveurs d'arrière-plan nous permet de limiter explicitement le nombre de serveurs d'arrière-plan à prendre en compte, gérant ainsi les redémarrages et les pannes de manière fiable (par exemple, tout en maintenant un nombre relativement faible de connexions).
Cependant, nous avons constaté que cette stratégie ne fonctionne pas comme prévu dans la plupart des cas, car la charge n'est pas répartie uniformément.
--- p.275
Les entreprises en forte croissance et dont les produits et services évoluent rapidement peuvent tirer profit de la création d'un poste d'ingénieur en orchestration des mises en production.
Ces équipes sont particulièrement utiles lorsqu'une entreprise prévoit d'embaucher plus du double de développeurs de produits tous les ans ou tous les deux ans, lorsqu'un service doit s'adapter à des millions d'utilisateurs, ou lorsque la stabilité est plus importante pour les utilisateurs malgré un taux de changement élevé.
En réalité, les différences de parcours au sein de l'équipe SRE ont souvent conduit à la création de systèmes uniques et de haute qualité intégrant de multiples technologies.
--- p.6
Comprendre dans quelle mesure votre système répond aux attentes vous aide à décider s'il convient d'investir pour le rendre plus rapide, plus disponible et plus résilient.
Par ailleurs, si le système fonctionne bien, le temps du personnel peut être consacré à des tâches plus prioritaires, telles que la réduction de la dette technique, l'ajout de nouvelles fonctionnalités ou le développement d'autres produits.
--- p.56
Le système possède une inertie.
Nous avons constaté qu'un système informatique fonctionnant correctement tend à continuer de fonctionner jusqu'à ce qu'un facteur externe, tel qu'un changement de configuration ou un changement du type de charge de service, survienne.
Le meilleur point de départ pour comprendre ce qui ne va pas est donc le changement le plus récent.
--- p.165
Une manière raisonnable de mettre en œuvre un algorithme de sélection de sous-ensemble consiste à faire en sorte que chaque client mélange aléatoirement la liste des serveurs d'arrière-plan, puis sélectionne les serveurs d'arrière-plan accessibles et en bon état pour constituer un sous-ensemble.
La méthode consistant à mélanger aléatoirement puis à sélectionner séquentiellement les serveurs d'arrière-plan nous permet de limiter explicitement le nombre de serveurs d'arrière-plan à prendre en compte, gérant ainsi les redémarrages et les pannes de manière fiable (par exemple, tout en maintenant un nombre relativement faible de connexions).
Cependant, nous avons constaté que cette stratégie ne fonctionne pas comme prévu dans la plupart des cas, car la charge n'est pas répartie uniformément.
--- p.275
Les entreprises en forte croissance et dont les produits et services évoluent rapidement peuvent tirer profit de la création d'un poste d'ingénieur en orchestration des mises en production.
Ces équipes sont particulièrement utiles lorsqu'une entreprise prévoit d'embaucher plus du double de développeurs de produits tous les ans ou tous les deux ans, lorsqu'un service doit s'adapter à des millions d'utilisateurs, ou lorsque la stabilité est plus importante pour les utilisateurs malgré un taux de changement élevé.
--- p.452
SPÉCIFICATIONS DES PRODUITS
- Date de publication : 18 janvier 2018
- Nombre de pages, poids, dimensions : 624 pages | 188 × 245 × 29 mm
- ISBN13 : 9791188621088
- ISBN10 : 1188621084
Vous aimerez peut-être aussi
카테고리
Langue coréenne
Langue coréenne
![GQ KOREA Mark (Mensuel) : décembre [2025]](http://librairie.coreenne.fr/cdn/shop/files/8ef265dbbfbf186523ed75ba7319009d.jpg?v=1765340328&width=3840)
