« Je me dirige vers la salle des opérations. Je n'ai plus l'impression d'avoir besoin de faire ça. »

À l’approche de notre dernière version 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 seule base de code monolithique à des dizaines de microservices Il est le responsable technique de notre équipe de gestion des incidents – Personnel, qui possède les services qui envoient des notifications d'alerte à plus de 8 000 clients PagerDuty . Nous nous sommes assis et avons parlé de la vie après le passage à équipes propriétaires des opérations de leurs services. Voici quelques observations sur les avantages et les inconvénients que nous avons constatés :

Sur la vie maintenant que les équipes possèdent leurs services :

Depuis que nous sommes passés à un modèle dans lequel les développeurs sont propriétaires de leurs services, l'indépendance des développeurs est bien plus grande. L'un des effets secondaires est que nous avons minimisé les difficultés liées à la mise en service et à la gestion de l'infrastructure. Désormais, l'équipe souhaite optimiser le moins possible les obstacles et les blocages. Les équipes de soutien à l'infrastructure sont orientées vers la fourniture de meilleurs outils en libre-service pour minimiser le besoin d'intervention humaine.

Le passage à avoir les développeurs sont propriétaires de leur code réduit le temps de cycle entre le moment où quelqu’un dit « c’est un problème » et le moment où il peut réellement résoudre le problème, ce qui s’est avéré inestimable.

Sur le changement culturel :

En permettant aux gens de s'approprier davantage le code et d'avoir plus de responsabilités en général pour les systèmes qu'ils exploitent, vous favorisez essentiellement une culture qui est plus encline à éliminer les obstacles. Chaque équipe est ainsi mieux optimisée pour « comment puis-je m'assurer de ne plus jamais être bloqué » ou « ne pas être bloqué à l'avenir ». C'est beaucoup plus évident lorsque nous sommes bloqués. Avant, je devais demander aux opérateurs chaque fois que nous voulions provisionner des hôtes, et j'acceptais simplement. Maintenant, mon équipe peut mieux voir ses obstacles, car ils ne sont pas 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 fourniture de valeur client de bout en bout, ce qui est inestimable.

Sur la façon dont cela peut aider avec le processus de réponse aux incidents :

Les limites de la propriété des services sont plus claires. Il est plus facile de déterminer quelles équipes spécifiques sont affectées en cas de problème d'opérabilité. Et le fait que je connaisse la procédure exacte à suivre (qui est plus objective et consiste à se demander « voici la liste de contrôle ») est formidable. Cela me permet de me concentrer à 100 % sur la résolution du problème et non sur la communication autour de l'incident.

Sur ce qui n'a pas bien fonctionné :

Cela ne veut pas dire que posséder un service n'entraîne pas son lot de problèmes. Il faut consacrer du temps à la maintenance opérationnelle de nos services. Cela prend finalement plus de temps à l'équipe, ce qui est particulièrement problématique avec les services hérités où il peut y avoir des lacunes en matière de connaissances. Au début, nous n'avons pas mis en place de garde-fous suffisamment solides pour protéger le travail d'opérabilité dans nos sprints. Cela s'améliore en tirant parti de Indicateurs clés de performance [tels que des objectifs de mise à l’échelle spécifiques et des niveaux de charge opérationnelle] pour nous permettre de prendre des décisions objectives.

Dans le futur:

[En ce qui concerne l'équilibre entre les tâches opérationnelles et celles liées au développement de fonctionnalités], les équipes se demandent : « Comment tirer parti de tous ces éléments au quotidien ? Comment prendre des décisions encore plus objectives ? » — et elles s'appuient sur des indicateurs pour prendre ces décisions objectives.

Tout dans le développement de nos produits est défini par « qu'est-ce que la valeur client », « quels sont les critères de réussite », etc. Je pense qu'essayer de transmettre le travail opérationnel dans le même sens permet de mieux hiérarchiser les priorités. Nous sommes tous dans la même équipe et alignés sur le même objectif, à savoir offrir de la valeur à nos clients, et il faut résoudre les priorités concurrentes à un moment donné.

Essayer d'apporter des changements au sein d'une organisation autour des opérations nécessite beaucoup de collaboration. Il faut également déterminer quels sont les indicateurs appropriés et en discuter.

^{Image: ' Loupe ' est protégé par le droit d'auteur (c) 2013 Todd Chandler}