Quantifier la valeur de DevOps

Selon mon expérience, lorsque vous travaillez dans l’informatique, l’équipe dirigeante s’intéresse rarement à votre staff jusqu’à ce que vous expérimentiez une défaillance catastrophique – une fois que cela arrive, vous êtes le centre de toute attention jusqu’au retour à la normale. Il est facile d’ignorer le travail de fond auquel les équipes informatiques consacrent la plupart de leur temps pour que tout fonctionne correctement. Dans cet article, je vais parler de la manière de quantifier la valeur des DevOps au sein des institutions. La notion de DevOps est simple : des développeurs travaillant ensemble avec des gestionnaires responsables de l’infrastructure pour rendre les choses plus rapides d’une manière automatique et répétitive. Si le processus fonctionne, le cycle ressemble à cela:

DevOps

DevOps consiste en des outils, des processus et un changement de culture à instaurer dans une institution. Selon mon expérience, dans les grandes entreprises cela est conduit du haut vers le bas, et dans les petites du bas vers le haut.

Quand j’ai débuté dans l’informatique, je travaillais en tant qu’ingénieur NOC sur un centre de données. La plupart des mes journées étaient consacrées à aider les clients dans l’installation ou l’upgrade de leur serveur. Si l’un de nos serveurs connaissait un problème, il était de ma responsabilité de réparer cela aussi rapidement que possible. D’autres journées étaient consacrées à des tâches de consultance pour aider des entreprises à gérer leurs applications. C’était l’époque où la plupart des applications web étaient simples avec deux serveurs – un centre de données et un serveur d’application:

monolithic_app

Ma carrière évoluant, je suis passé du côté de l’ingénierie et j’ai travaillé au développement d’applications web très larges. Les applications sur lesquels je travaillais étaient bien plus complexes que celles dont j’avais l’habitude avec le centre de données. Ce n’était pas seulement l’architecture et le codage qui étaient plus complexes, mais également les surplus opérationnels pour gérer ces grandes infrastructures appelaient à adopter d’autres attitudes et de meilleurs outils.

distributed_app

Quand j’ai construit et déployé des applications, nous avons dû construire nos serveurs depuis la base. A l’âge du cloud, vous devez choisir à quels problèmes vous souhaitez accorder du temps pour trouver une solution. Si vous choisissez une Infrastructure comme fournisseur de service, vous possédez non seulement votre application et vos données, mais également l’intergiciel et le système d’exploitation. Si vous choisissez une plateforme en tant que service, vous devez uniquement vous soucier de l’application et des données. La traditionnelle option sur site, si elle vous offre plus de liberté, porte également la responsabilité de gérer le hardware, le réseau et l’énergie. Choisissez sagement:

Screen Shot 2014-03-12 at 11.50.15 AM

En tant que responsable d’application dans une grande équipe, vous découvrez rapidement comment une équipe travaille bien ensemble. Durant l’époque pré-DevOps, le processus typique pour résoudre des problèmes opérationnels ressemblait à cela:

Screen Shot 2014-03-12 at 11.49.50 AM

  1. L’équipe support produit un ticket et choisit une priorité relative
  2. Les gestionnaires d’infrastructure commencent à enquêter et blâment les développeurs
  3. Les développeurs répondent que ce n’est pas possible car ils travaillent dans le développement et renvoient le ticket aux gestionnaires d’infrastructure
  4. L’équipe des gestionnaires d’infrastructures communique le problème au management jusqu’à ce qu’elle se retrouve à travailler avec les développeurs pour trouver la source du problème
  5. Tous discutent de la sévérité du problème, moins importante que jugée en premier lieu, et ils en changent la priorité
  6. Le management l’apprend et classe le problème en Sévère ou Priorité 1
  7. Les gestionnaires de l’infrastructure et les développeurs trouvent la cause du problème et le règle
  8. L’équipe support ferme le ticket

Nous avons à plusieurs reprises perdu beaucoup de temps en enquêtant sur des problèmes qui n’en étaient en fait pas. Nous faisions des recherches à leur sujet car nous ne pouvions pas faire confiance aux contrôles et aux outils de monitoring pour déterminer si un problème en était bien un. Soit le ticket ne pouvait pas être reproduit, soit les problèmes provenaient d’une tierce partie. Dans les deux cas, nous devions investir le temps requis pour le découvrir. Nous n’avons jamais calculé combien d’argent ces résultats faussement positifs ont coûté à l’entreprise en termes d’heures de travail.

Screen Shot 2014-03-12 at 11.50.35 AM

Avec de meilleurs outils de monitoring d’application, nous sommes en mesure de réduire le nombre de résultats faussement positifs et l’argent perdu par l’entreprise.

Combien d’argent le business a-t-il perdu? 

noidea

Je n’ai jamais été capable d’articuler le montant de l’argent que notre équipe a économisé en ajoutant des outils et en améliorant les processus. A l’âge de DevOps, il y a de nombreux outils dans la chaîne d’outil de DevOps.

En adoptant une automation d’infrastructure avec des outils comme Chef, Puppet et Ansible, vous pouvez traiter votre infrastructure comme un code, ainsi elle devient automatisée, en version, testable et, le plus important, répétable. La prochaine fois qu’un serveur s’arrêtera, il suffira de quelques secondes pour lancer une instance identique. Combien de temps avez-vous fait économiser à l’entreprise en ayant une manière cohérente de gérer les changements de configuration?

En adoptant une automation de déploiement avec des outils comme Jenkins, Fabric et Capistrano, vous pouvez déployer avec confiance et constance des applications à travers vos environnements. Combien de temps avez-vous fait économiser à l’entreprise en réduisant les problèmes de construction et de déploiement?

En adoptant une automation des registres avec des outils comme Logtash, Splunk, SumoLogic et Loggly, vous pouvez regrouper et indexer tous vos registres à travers chaque service. Combien de temps avez-vous fait économiser à l’entreprise en lui évitant de devoir trouver manuellement la machine à la source du problème et en retirant les registres associés en un seul click?

En adoptant des outils de gestion de performance d’application comme AppDynamics, vous pouvez facilement avoir une visibilité au niveau du code à l’intérieur des problèmes de production et comprendre exactement quels nœuds ont causé des problèmes. Combien de temps avez-vous fait économiser à votre entreprise en adoptant un APM pour réduire l’intervalle de temps jusqu’à la résolution?

En adoptant une automation de runbook grâce à des outils comme AppDynamics, vous pouvez automatiser les réponses apportées aux problèmes ordinaires d’application et les augmenter ou les diminuer dans le cloud. Combien de temps avez-vous fait économiser à votre entreprise en réglant automatiquement les défaillances d’application sans même cliquer sur un bouton?

Comprendre la valeur que ces outils et ces processus apportent à votre institution est simple:

devops_tasks

DevOps = Automation et Collaboration = Temps = Argent

Lorsque vous déployez le DevOps au sein de votre institution, le conseil plus précieux que je puisse vous donner est de tout automatiser et de toujours prévoir une défaillance. Une étude de RebelLabs/ZeroTurnaround démontre que:

  1. Les équipes DevOps passent plus de temps à améliorer les choses et moins de temps à les régler
  2. Les équipes DevOps se remettent plus facilement des défaillances
  3. Les équipes DevOps lancent des applications qui sont au moins deux fois plus rapides

Combien une panne coûte-t-elle à votre entreprise?

Cet article a été inspiré par une présentation tech que j’ai donnée par le passé: https://speakerdeck.com/dustinwhittle/devops-pay-raise-devnexus

Prenez cinq minutes pour accéder à une complète visibilité de la performance de vos applications de production aujourd’hui avec AppDynamics.