À Vitesse Santa Clara cette année, j'ai donné une conférence sur l'interaction entre les DevOps mouvement et gestion des produits. Je pense qu'il est important que les chefs de produit comprennent l'impact de leurs choix sur l'opérabilité des logiciels, et que les équipes d'ingénierie, qu'elles soient DevOps ou autres, comprennent comment leurs choix affectent le produit.

Je souhaite souligner trois pratiques que nous utilisons dans la création, l'expédition et l'exploitation de logiciels chez PagerDuty, et comment elles aident notre équipe produit à offrir plus de valeur aux clients.

Déploiements rapides, fréquents et stables

La plupart de nos dépôts Github disposent d'une configuration d'intégration continue ou de déploiement continu. Lorsque vous ouvrez une demande d'extraction, votre code est aspiré comme par magie vers le cloud, une batterie de tests est exécutée dessus et, s'ils réussissent tous, vous obtenez une grande coche verte « déploiement sûr ».

Nous avons également un déploiement ChatOps. Il y a un canal dans Mou où vous pouvez demander à un bot de lancer n'importe quelle branche de n'importe quel dépôt sur n'importe quel environnement, y compris la production. Cela facilite également l'investigation et l'annulation des mauvais déploiements, et contribue généralement à la visibilité sur ce qui se passe dans notre infrastructure.

Après avoir vécu cette expérience magique, je ne peux pas imaginer revenir à un monde où le développement et le déploiement nécessitent de mettre le site hors service pour maintenance ou de passer par une équipe distincte. Les chefs de produit vivent et meurent en fonction de la boucle de rétroaction : plus vous restez longtemps sans voir le produit en direct et sans en tirer des leçons, plus vous courez de risques.

Échec artificiel

Inspirés par Simian Army de Netflix, nous injectons régulièrement des substances contrôlées et échec supervisé dans les systèmes de PagerDuty pour garantir que nous sommes toujours prêts à faire face à l'inattendu.

Tous les vendredis à 11 heures du matin, heure du Pacifique, les équipes de développement, d'exploitation et toute autre personne qui le souhaite se réunissent dans une salle et nous démontons une partie de notre infrastructure. L'objectif est triple :

1. Définissez une attente selon laquelle lorsque vous démarrez un service chez PagerDuty, vous devez le créer avec échec en tête Vous devez vous attendre à ce qu'à tout moment, des choses folles puissent se produire et vous devez rester éveillé.
2. Identifiez les endroits où nos systèmes ne sont pas robustes dans un environnement contrôlé, afin que nous puissions résoudre ces problèmes bien avant que les clients ne soient impactés.
3. Pratiquez nos techniques de gestion des incidents afin que, lorsqu’un événement cygne noir se produit, notre réponse soit pratiquée et automatique.

J'adore être chef de produit dans une culture qui considère l'échec comme une opportunité d'apprentissage. La gestion de produit implique beaucoup de risques et d'échecs sur la voie du succès, et le fait que cela soit ancré dans notre culture facilite les conversations entre équipes sur ces sujets.

J'ai aussi beaucoup appris de la pratique de l'échec planifié, des autopsies sans reproche et de la pensée systémique. J'ai appris à considérer l'échec comme le succès non pas comme attribuables à une seule décision ou à une seule personne, mais comme des interactions entre de multiples croyances et circonstances. Cela m'a appris à constituer un backlog de travail qui ne nécessite pas une réaction en cascade de type domino pour réussir, mais qui reconnaît plutôt l'incertitude et met toutes les chances de notre côté.

Construisez-le, expédiez-le, possédez-le

Ce que je préfère dans DevOps chez PagerDuty, cependant, est la culture de la propriété des logiciels. Nos équipes déploient le code qu'elles écrivent et assument la responsabilité des logiciels qu'elles mettent au monde.

C'est parfois un peu frustrant pour un chef de produit, car cela signifie que votre feuille de route de nouvelles fonctionnalités peut être aléatoire en raison de la dette technique ou de problèmes opérationnels. Il faut surtout garder cela à l'esprit lors de la planification du travail et de la gestion d'une équipe.

Mais à long terme, la culture de propriété aide les produits à faire non seulement les bons choix pour le projet sur lequel ils travaillent actuellement, mais aussi les bons choix à long terme pour leur équipe et l'organisation dans son ensemble.

Avec DevOps, votre budget de développement et votre budget d'exploitation sont identiques. Vos collaborateurs sont les mêmes. Si vous livrez du code instable ou poussez votre équipe au-delà de ses limites, c'est votre propre vélocité future qui en pâtit. Selon les mots de Jez Humble « Les mauvais comportements surviennent lorsque les gens ne sont pas conscients des conséquences de leurs actes. » Je pense que la relation étroite que nous entretenons entre le produit et l’ingénierie favorise le bon comportement et les bons compromis.

Défis

Il n'est pas toujours facile de mettre les équipes produit et ingénierie sur la même longueur d'onde. Les gens doivent apprendre à parler le même langage, à créer un contexte et une compréhension communs et à réfléchir à la manière dont les différents flux de travail affectent un objectif commun. Cela peut être un peu mouvementé et à chaque version, nous regardons en arrière et voyons les points sur lesquels nous aurions pu faire mieux.

Mais je pense que cela en vaut la peine. Chaque fois que je constate que l'écart entre les choix et les conséquences se réduit, chaque fois que nous sommes en mesure de donner aux équipes davantage de contrôle sur leur code, nous livrons de meilleurs logiciels, plus fréquemment, et nous rendons nos clients plus heureux. Il peut y avoir beaucoup de choses auxquelles s'habituer au début, mais je ne peux pas imaginer un meilleur modèle que DevOps pour une gestion de produit de qualité.