« Me rendre à la salle des opérations, je n’ai plus l’impression d’avoir besoin de le faire. »

À l'approche de notre Dernière mise à jour des fonctionnalités pour les développeurs , je me suis assis avec David Yang , un ingénieur senior ici chez PagerDuty qui a vu notre architecture interne évoluer d'une base de code monolithique unique à des dizaines de microservices Il est le responsable technique de notre équipe Gestion des incidents – Personnel, qui gère les services de notification d'alerte pour nos plus de 8 000 clients PagerDuty . Nous avons discuté de son expérience après son passage à… des équipes qui gèrent l'exploitation de leurs services. Voici quelques exemples : Voici quelques observations concernant les avantages et les inconvénients que nous avons constatés :

À propos de la vie maintenant que les équipes sont propriétaires de leurs services :

Depuis le passage à un modèle où les développeurs sont propriétaires de leurs services, leur autonomie s'est considérablement accrue. De ce fait, nous avons réduit au minimum les difficultés liées au provisionnement et à la gestion de l'infrastructure. L'équipe souhaite désormais optimiser le processus afin de minimiser les obstacles et les blocages. Les équipes d'infrastructure s'efforcent de fournir de meilleurs outils en libre-service pour réduire au maximum le besoin d'intervention humaine.

Le passage à avoir Les développeurs sont propriétaires de leur code. Cela réduit le délai entre le moment où quelqu'un signale un problème et celui où il peut réellement le résoudre, ce qui s'est avéré inestimable.

À propos du changement culturel :

En responsabilisant davantage les utilisateurs quant au code et à la gestion des systèmes, on favorise une culture axée sur la résolution des problèmes. Chaque équipe est ainsi davantage orientée vers la prévention des blocages, en se demandant : « Comment éviter d'être bloqué à nouveau ? » ou « Comment éviter les blocages futurs ? » Les blocages sont désormais beaucoup plus visibles. Auparavant, je devais solliciter l'équipe d'exploitation à chaque fois que nous voulions provisionner des hôtes, et je m'y résignais. Maintenant, mon équipe repère plus facilement ses propres blocages, car ils ne sont plus masqués par ceux des autres équipes.

Nous avons des équipes qui se concentrent beaucoup plus sur la maîtrise de l'ensemble du processus de création de valeur pour le client, de bout en bout, ce qui est inestimable.

Comment cela peut aider à processus de réponse aux incidents :

Les responsabilités des services sont mieux définies. Il est plus facile d'identifier les équipes impactées en cas de problème d'exploitation. Et le fait de connaître la procédure exacte à suivre – une procédure objective du type « voici la checklist » – est un atout majeur. Cela me permet de me concentrer pleinement sur la résolution du problème et non sur les détails. communication autour de l'incident.

Ce qui n'a pas si bien fonctionné :

Cela ne veut pas dire que la gestion d'un service est sans inconvénients. Elle exige du temps consacré à la maintenance opérationnelle de nos services. Cela accapare une part importante du temps de l'équipe, ce qui pose particulièrement problème avec les services existants, notamment en raison des lacunes de connaissances qu'ils peuvent engendrer. Au départ, nous n'avions pas mis en place de garde-fous suffisamment robustes pour protéger le travail d'exploitation lors de nos sprints. Nous améliorons actuellement la situation en tirant parti de… KPI [tels que des objectifs de mise à l'échelle spécifiques et des niveaux de charge opérationnelle] afin de nous permettre de prendre des décisions objectives.

Concernant l'avenir :

[Concernant l'équilibre entre le travail lié aux opérations et le travail de développement des fonctionnalités], les équipes se demandent : « Comment puis-je tirer parti de tout cela au quotidien ? Comment puis-je prendre des décisions encore plus objectives ? » — et s'orientent vers ces décisions objectives grâce à des indicateurs.

Tout dans notre développement produit est défini par la notion de « valeur client », de « critères de réussite », etc. Je pense qu'appliquer la même approche au travail opérationnel facilite la priorisation. Nous faisons tous partie de la même équipe et partageons le même objectif : apporter de la valeur à nos clients. Il faut donc, à un moment donné, concilier les priorités parfois contradictoires.

Mettre en œuvre des changements opérationnels au sein d'une organisation exige une forte collaboration. Il faut également identifier les indicateurs clés de performance (KPI) pertinents et en discuter.

^{Image: ' Loupe « » est protégé par le droit d’auteur © 2013 Todd Chandler}