Fermer

juin 29, 2018

Mariage de DevOps et ITIL


DevOps est plus une philosophie ou une façon de travailler qu'un cadre formel ou une norme. Néanmoins, l'approche mérite le mérite, car elle est au cœur des tensions dans la plupart des organisations informatiques: le besoin d'être réactif aux changements métier tout en maintenant une infrastructure informatique stable et hautement disponible et en fournissant des services de qualité répondant aux besoins de l'entreprise.

Qu'est-ce que DevOps a à voir avec ITIL?

Commençons par ITIL. ITIL est un cadre global pour la fourniture et la gestion de la technologie en tant que service à l'entreprise. En tant que cadre de bonnes pratiques informatiques éprouvé et bien adopté, ITIL inclut la notion selon laquelle un service est un moyen de fournir de la valeur aux clients en facilitant les «résultats» qu'ils recherchent (obtenir des résultats commerciaux) sans avoir à supporter les coûts. ITIL maintient que les clients veulent des résultats – le résultat de l'exécution du service – et ils comprennent qu'un fournisseur de services est tenu de fournir tous les services informatiques nécessaires pour les aider à atteindre ces résultats, à travers le l'application des personnes, des processus et de la technologie. ITIL est neutre pour les fournisseurs (ne nécessite pas d'outils spécifiques à un fournisseur donné), non prescriptif (il doit s'adapter à l'organisation qui veut le pratiquer), et une meilleure pratique éprouvée pour l'informatique (cela fonctionne simplement. ITIL-In Conflict ou Complémentary

DevOps met l'accent sur la collaboration et la communication, tout comme ITIL: en fait, il n'y a pas de conflit inhérent entre le mouvement DevOps et l'ITIL, il devient évident que les deux sont très complémentaires. nous fournit une «nouvelle lumière» dans laquelle nous pouvons examiner le cadre ITIL dans plusieurs domaines clés, améliorant les processus, les fonctions et les principes de base au sein d'ITIL.

Éléments clés d'un DevOps

  • DevOps n'est pas un produit ou une technologie, mais plutôt une «méthodologie» émergente ou une façon de travailler entre deux groupes clés au sein d'une organisation de fournisseurs de services informatiques DevOps:
  • Devrait être holistique – impliquant les gens, les processus et la technologie
  • Peut être considéré comme une "extension"
  • Il s'agit de faire tomber les "barrières" entre les groupes de développement d'applications au sein des organisations, et leur fonction de service et de soutien
  • Est sur les moyens d'améliorer la collaboration entre l'équipe de développement et d'opérations. "DevOps" est apparu il y a quelques années comme un mouvement au sein des meilleures pratiques informatiques lorsque les responsables informatiques ont commencé à se rendre compte que quelque chose devait être fait pour combler le fossé de communication et de collaboration entre le personnel des opérations de soutien au développement, et accélérer la réactivité à l'entreprise.

    Avec la tendance vers les appareils mobiles, l'économie des applications est née. Le travail a commencé sa transition vers une main-d'œuvre mobile, et les applications – qui avaient une plus grande empreinte et avaient l'habitude de résider sur des ordinateurs de bureau – ont commencé à se transformer en «applications» plus petites et portables.

    une quantité sans cesse croissante de travail a commencé sur les tablettes, les smartphones et les ordinateurs portables. Parallèlement à la tendance vers le travail mobile, la concurrence pour les clients et les utilisateurs a continué à croître entre les entreprises.

    L'équilibre du commerce électronique s'est déplacé vers les appareils mobiles, et il est devenu impératif pour les entreprises de rester en avance sur leurs concurrents. applications "qui pourraient permettre à leur main-d'œuvre, attirer des clients, et peut-être équivalent à une différenciation concurrentielle. Les développeurs ont commencé à ressentir la pression d'être plus réactifs aux demandes des entreprises pour améliorer les fonctionnalités des applications.

    L'idée d'équipes de développement "Agiles" est née et les groupes de développement ont commencé à développer et déployer de nouvelles versions du code. base fréquente. Agile, qui est une philosophie de développement et de déploiement d'applications, est également supporté par des méthodologies telles que Scrum

    How DevOps, Agile, et ITIL Relate

    une méthodologie pour accélérer le développement et le déploiement d'applications (en utilisant des techniques et des processus tels que Scrum), DevOps est une philosophie ou une méthode de travail qui a le potentiel de réaliser de plus grands bénéfices et une livraison plus rapide. DevOps est une approche «à valeur ajoutée» du développement Agile, qui met l'accent sur:
    • Implication continue et implication des équipes opérationnelles avec les équipes de développement internes, tout au long du cycle de développement
    • Les équipes opérationnelles doivent être engagées le plus tôt possible. dès le début – pendant la formulation de la vision et de la charte pour la solution de service
    • Les équipes d'exploitation devraient également fournir des commentaires sur les exigences techniques et d'application du service et donner des conseils sur la faisabilité du • Amélioration de la fréquence de déploiement, accélérant la mise sur le marché des modifications de fonctionnalités nouvelles / améliorées
    • Taux de défaillance plus faible des nouvelles versions, mises à jour plus fréquentes des correctifs et temps de récupération plus rapide en cas de modification
    l'application de l'automatisation de service pour accélérer les «modèles de processus» communs tels qu'un changement standard ou une mise à jour de version de routine

    [1 9459017] Ces notions de collaboration, de communication optimisée et de réactivité métier ne sont pas étrangères à ITIL. En fait, le cadre ITIL souligne la nécessité d'impliquer rapidement les équipes fonctionnelles de gestion technique et de gestion des applications dans la stratégie de service, la conception des services et la transition des services. ITIL est très clair que les fonctions d'exploitation de service – en particulier, les équipes d'infrastructure technique – devraient fournir à l'équipe de conception et de développement un avis précoce sur la compatibilité et l'adéquation de l'application à l'environnement réel. Ils doivent également fournir des informations sur les architectures techniques de la «solution de service», notamment l'architecture de service, l'architecture des applications, l'architecture réseau, l'architecture de l'information, l'architecture de la base de données, etc

    ne sont pas étrangers à ITIL. En fait, le cadre ITIL souligne la nécessité d'impliquer rapidement les équipes fonctionnelles de gestion technique et de gestion des applications dans la stratégie de service, la conception des services et la transition des services. ITIL est très clair que les fonctions d'exploitation de service – en particulier, les équipes d'infrastructure technique – devraient fournir à l'équipe de conception et de développement un avis précoce sur la compatibilité et l'adéquation de l'application à l'environnement réel. Ils devraient également fournir des informations sur les architectures techniques pour la «solution de service», y compris l'architecture de service, l'architecture des applications, l'architecture réseau, l'architecture des informations, l'architecture des bases de données, etc

    toutes les applications, pas seulement celles qui sont développées en interne, devraient être engagées très tôt dans la vie d'un service. En fait, ils devraient travailler avec l'entreprise, la personne désignée comme gestionnaire des relations d'affaires (BRM) et le propriétaire du service pour identifier, définir et documenter les exigences de «solution de service» complètes et s'assurer qu'elles sont bien saisies. dans la charte de service pour le service nouveau ou modifié considéré. Selon ITIL, les équipes de gestion des applications doivent travailler en étroite collaboration avec les groupes de développement, qui restent concentrés sur la conception des services et la transition des services vers le développement rapide et le déploiement des applications faisant partie de la solution globale. Tandis que le développement se concentre sur les activités de développement et la transition de service, la gestion des applications gère l'application sur l'ensemble du cycle de vie du service, de la stratégie à la conception et la transition (en cours de développement). Cette approche garantit que la solution de service (qui contient l'application), non seulement se lance bien, mais continue de fonctionner pendant les opérations en direct, répondant aux besoins des clients et des utilisateurs professionnels.

    L'importance de définir et de mettre en œuvre des communications transversales efficaces est également souligné par ITIL. Toutes les parties prenantes, du personnel de service de première ligne aux spécialistes du support technique et applicatif, en passant par les développeurs et les clients, doivent être reliées par des canaux de communication bien planifiés et efficaces afin que les remontées puissent être traitées rapidement. Comme DevOps, ITIL est également très attaché à l'utilisation des «modèles» et à l'application de l'automatisation des services pour augmenter l'efficacité, accélérer l'exécution et réduire les coûts. Ce que souligne ITIL, cependant, c'est que pour réussir, un fournisseur de services informatiques doit d'abord être axé sur la stratégie et le processus, avant de pouvoir tirer le meilleur parti de l'automatisation. Le changement standard ou le «modèle» de version doit d'abord être documenté et analysé, les «lacunes» doivent être supprimées, et le processus et les interfaces doivent être rationalisés et automatisés. Ce n'est qu'alors que les avantages et le rendement seront atteints.

    Le personnel de gestion des applications (responsable du cycle de vie complet de toutes les applications, pas seulement celles développées en interne), devrait être engagé très tôt dans la vie d'un service. En fait, ils devraient travailler avec l'entreprise, la personne désignée comme gestionnaire des relations d'affaires (BRM) et le propriétaire du service pour identifier, définir et documenter les exigences de «solution de service» complètes et s'assurer qu'elles sont bien saisies. dans la charte de service pour le service nouveau ou modifié considéré. Selon ITIL, les équipes de gestion des applications doivent travailler en étroite collaboration avec les groupes de développement, qui restent concentrés sur la conception des services et la transition des services vers le développement rapide et le déploiement des applications faisant partie de la solution globale. Tandis que le développement se concentre sur les activités de développement et la transition de service, la gestion des applications gère l'application sur l'ensemble du cycle de vie du service, de la stratégie à la conception et la transition (en cours de développement). Cette approche garantit que la solution de service (qui contient l'application), non seulement se lance bien, mais continue de fonctionner pendant les opérations en direct, répondant aux besoins des clients et des utilisateurs professionnels.

    L'importance de définir et de mettre en œuvre des communications transversales efficaces est également souligné par ITIL. Toutes les parties prenantes, du personnel de service de première ligne aux spécialistes du support technique et applicatif, en passant par les développeurs et les clients, doivent être reliées par des canaux de communication bien planifiés et efficaces afin que les remontées puissent être traitées rapidement. Comme DevOps, ITIL est également très attaché à l'utilisation des «modèles» et à l'application de l'automatisation des services pour augmenter l'efficacité, accélérer l'exécution et réduire les coûts. Ce que souligne ITIL, cependant, c'est que pour réussir, un fournisseur de services informatiques doit d'abord être axé sur la stratégie et le processus, avant de pouvoir tirer le meilleur parti de l'automatisation. Le changement standard ou le «modèle» de version doit d'abord être documenté et analysé, les «lacunes» doivent être supprimées, et le processus et les interfaces doivent être rationalisés et automatisés. Ce n'est qu'alors que les avantages et le débit seront atteints.




Source link