Dans ma carrière, j'ai été à la fois développeur de logiciels et praticien ITIL dans un rôle opérationnel. Le DevOps a donc été une progression naturelle pour moi.
Cependant, j'ai toujours eu du mal à utiliser le langage hautement spécialisé qu'ITIL introduit et à le rendre suffisamment "convivial pour les développeurs" pour ne pas être complètement désactivé pour les développeurs.
ITIL est un cadre de gestion des services informatiques internationalement reconnu qui a été développé sur 30 ans comme un ensemble de pratiques qui ont fait leurs preuves pour la stabilité opérationnelle et la maturité d'une organisation.
Est-ce que DevOps est vraiment compatible avec ITIL, ou en substance devons-nous prendre l'esprit d'ITIL et le «traduire» dans un langage mieux compris par les équipes de développement:
- Gestion des incidents et des problèmes → Défauts de production, bogues ou problèmes
- Gestion des modifications et des versions → Livraison continue
- Gestion des événements → Journalisation, télémétrie, instrumentation et alertes
la source
Réponses:
À mon avis, la culture DevOps s'accompagne d'un changement de méthodologie vers la gestion des processus Agile .
ITIL vise fortement un formalisme clair du processus et des résultats et donc plus adapté à un modèle Waterfall .
Cela ne signifie pas que ITIL est incompatible avec Devops, mais généralement ce sera deux processus distincts avec des délais différents. Je veux dire que l'inclusion d'un nouveau produit dans le référentiel ITIL sera généralement retardée jusqu'à ce que le produit / l'application soit sorti en production pendant un certain temps, où les premiers pièges et la documentation nécessaire pour intégrer ITIL ont été faits et adaptés une fois le produit " vivre".
L'une des choses dans ITIL est la conception de service, qui est supposée être définie avant toute tâche de développement, un processus agile examinera / peut réviser la conception à chaque itération, brisant le formalisme nécessaire dans un processus ITIL.
Le principal objectif d'ITIL est, comme vous l'avez dit, de fournir un cadre pour garantir que rien n'est omis entre la phase de conception / conception et de maintenance (Build / Run). Dans une culture devops, toute l'équipe est responsable de toutes les phases sur le long terme, d'où la réduction du formalisme.
Cela ne signifie pas que nous devons oublier ITIL, les principes de base sont absolument bons et, à mon avis, devraient être utilisés comme liste de contrôle pour créer l'arriéré initial d'un produit. C'est juste que suivre le principe ITIL avec tout son formalisme va à l'encontre de l'objectif de réduction du temps de mise sur le marché d'un développement logiciel rapide et itératif et parfois même pas applicable car il y a moins de transmission d'informations nécessaires entre les équipes, car les tâches sont effectuées par la même équipe .
la source
Je suis certifié ITIL (même si cela fait longtemps). Je suis d'accord avec Tensibai: ITIL et DevOps ne sont pas incompatibles , mais cela ne fait pas nécessairement d'eux de grands amis.
L'argument peut être avancé que les processus dans ITIL doivent se produire d'une manière ou d'une autre, en particulier pour les grandes organisations. L'intégration réussie des pratiques DevOps, où ITIL est déjà pratiqué, nécessite une planification, une communication et une exécution minutieuses. Là encore, cela est vrai de toute transformation DevOps.
Pour une transformation "greenfield" où ni ITIL ni DevOps ne sont en place, je créerais une combinaison des deux en utilisant la terminologie "mappée" comme vous l'avez décrit. Tant que tout le monde dans l'organisation est sur la même page, en utilisant le même langage, ITIL et DevOps peuvent ajouter de la valeur lorsqu'ils sont combinés.
la source
J'ai aimé les réponses fournies par l' informatique sceptique sur un épisode de DevOpsCafe.org Si je me souviens bien, sa ligne de pensée est que si vous comprenez vraiment ITIL, il y a très peu de conflits. Que la plupart des directives ITIL sont très générales et que les conflits sont en grande partie entre certaines implémentations d'ITIL, pas derrière la spécification réelle.
la source