Les NetOps ont besoin de défenseurs et non d'adversaires
Vous êtes prêt à savourer un repas que vous attendez avec impatience toute la journée lorsque vous remarquez qu'il n'est pas assez cuit. Frustré, vous parlez durement au serveur et réduisez peut-être même son pourboire. Ils le prennent avec le sourire même si ce n'est pas de leur faute. Après tout, ce n’est pas eux qui ont préparé votre repas. Mais ils sont votre interface avec la cuisine, et en fin de compte, ce sont eux qui paient le prix des échecs qui se produisent hors de vue.
Qu'il s'agisse du serveur dans un restaurant ou d'un représentant du service client de <insérer le service ici>, c'est généralement la personne qui interagit avec vous qui finit par supporter le poids de votre angoisse/frustration/colère lorsque quelque chose ne va pas.
C’est également vrai dans le centre de données.
Alors que l'informatique se transforme numériquement dans le but d'atteindre une optimisation et une vitesse supérieures, ce sont les équipes NetOps qui sont les plus susceptibles d'interagir avec les « clients » internes et donc de supporter le poids des utilisateurs mécontents lorsque les processus n'évoluent pas aussi rapidement que souhaité.
Il est important de reconnaître que ce n’est pas toujours « NetOps » qui fait obstacle au déploiement de la dernière nouveauté/application/service. Les obstacles à la rapidité sont souvent dus à l’incapacité des organisations à adopter tous les principes de DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Faites-vous du DevOps ou automatisez-vous simplement ?
CAMS est le moyen le plus couramment utilisé pour diffuser les principes fondamentaux de DevOps. CAMS signifie : culture , automatisation , mesure et partage .
Parmi ces quatre solutions, l’automatisation est celle qui sera probablement adoptée avec enthousiasme. Ce sont les trois autres qui ont tendance à être laissés de côté ou complètement ignorés dans la quête d’amélioration de la vitesse de service au sein de l’informatique.
Il est particulièrement intéressant de noter que les trois concepts généralement ignorés sont étroitement liés. Il est difficile de changer la culture lorsque les équipes sont encore isolées par fonction et concentrées sur des mesures qui n’ont pas d’importance pour les autres équipes. Nous travaillons pour atteindre ce sur quoi nous sommes mesurés. Si nous sommes évalués sur la disponibilité du réseau, c'est sur cela que nous allons nous concentrer - même si nos homologues des opérations tentent d'améliorer la disponibilité des application .
À savoir, vous vous souvenez peut-être de l’ étude sur l’état de l’automatisation des réseaux dans laquelle nous avons uni nos forces avec Red Hat pour plonger dans le monde trouble de DevOps, NetOps et de l’automatisation. Nous avons constaté une grande disparité entre les mesures recherchées par NetOps et celles impliquées dans le développement et les opérations.
Près des trois quarts (73 %) des NetOps ont cité le « temps de disponibilité du réseau » comme leur principale mesure. De l’autre côté de la barrière, 59 % des développeurs et des opérations nous ont déclaré que « le temps de disponibilité des application » était leur principale mesure. À l’inverse, près de deux fois plus de développeurs et d’opérations (30 %) sont évalués sur la fréquence des déploiements que NetOps (16 %) et Sécurité (17 %).
Pourquoi cette disparité est-elle importante ? Si mon objectif principal est de maintenir le réseau disponible, je vais consacrer mon temps à me concentrer sur le réseau. L'instrumentation et la surveillance - cette dernière étant essentielle au composant de partage de DevOps - se concentreront d'abord sur le réseau, puis peut-être sur l' application. S'il y a du temps. Personne n’a le temps de s’occuper de la sécurité et de toute façon personne n’est évalué sur ce point. En fait, la mesure numéro un citée pour la sécurité était « le temps de disponibilité du réseau » chez 59 % des professionnels de la sécurité mesurés sur cette mesure.
Les humains, qui sont toujours au cœur de l’informatique et composent les équipes qui doivent mettre en œuvre l’automatisation et l’orchestration, ne sont pas nécessairement alignés sur les mêmes objectifs. L’un des facteurs de ce décalage est l’isolement continu des domaines opérationnels. Les groupes NetOps et Sécurité sont plus susceptibles de travailler dans le cadre d'une équipe « à fonction unique ». NetOps s'inquiète du réseau. Sécurité? Sécurité. Des opérations ? Opérations système.
Mais cela va encore plus loin que cela . Parce qu’à l’intérieur des GRANDS silos se trouvent des silos encore plus petits. Comme la matriochka (une poupée russe), il existe de nombreuses équipes différentes au sein de NetOps sur lesquelles cette demande apparemment simple de « nouveau site » doit s'appuyer avant d'être complète. De nombreux services d’infrastructure et application doivent être provisionnés et intégrés avant qu’une telle demande puisse être satisfaite. Un nouveau site nécessite non seulement des ressources de calcul et de réseau pour l’héberger, mais également une multitude d’autres exigences. Un serveur Web et son stockage. Contrôle d'accès. Certificats et gestion des clés. Équilibrage de charge. Règles du pare-feu. La liste des silos intra-informatiques à travers lesquels cette « simple » demande doit transiter est longue.
Et si l’un de ces silos au sein du silo NetOps n’est pas automatisé, le processus s’arrête brutalement. Des jours, voire des semaines, peuvent s’ajouter au délai nécessaire pour répondre à une telle demande.
De l'extérieur, du point de vue du demandeur, il semble que NetOps ne soit tout simplement pas en mesure de faire son travail. C'est le « homologue », l'« agent de liaison », le « partenaire informatique » qui porte l'angoisse de ceux qui demandent pourquoi il faut autant de temps pour répondre à ce qui semble être une demande simple. Nous blâmons NetOps de la même manière que les néophytes techniques blâment le fournisseur local pour les problèmes d'Internet alors que le problème vient en réalité d'un routeur situé au plus profond du réseau fédérateur et géré par un autre fournisseur.
Soyez un défenseur, pas un adversaire
La transition vers une informatique plus collaborative et transparente n’est encore qu’une étape à l’horizon pour de nombreuses organisations. Même si certains groupes informatiques voient la nécessité et adoptent les changements nécessaires, ce n’est pas le cas de tous. Au cours des cinq années de recherche sur les services application , nous n'avons pas vu « DevOps » atteindre le niveau d'importance stratégique requis pour réellement initier les changements culturels et organisationnels nécessaires pour atteindre le type de vitesse que l'entreprise souhaite - et dont elle a besoin. Au lieu de cela, les organisations ont adopté l’automatisation – et oublié les trois autres composants essentiels à DevOps.
Cette incapacité à reconnaître le mouvement DevOps dans l’informatique comme étant bien plus qu’une simple automatisation est troublante. C'est une erreur de reconnaître que si vous voulez gagner en vitesse, vous devez automatiser le pipeline, et que ce pipeline traverse pratiquement tous les domaines opérationnels et silos au sein de l'informatique. Cela signifie que toutes les personnes concernées doivent évoluer vers l'automatisation, sinon vous ne parviendrez pas à atteindre la vitesse et la fréquence des déploiements que vous recherchez. Vous ne pouvez pas simplement adopter l’automatisation et espérer réussir. Lorsque l’automatisation doit franchir les frontières entre des groupes cloisonnés, vous échouerez sans changement culturel significatif.
Le changement nécessaire doit venir d’en haut. En particulier le changement organisationnel. On ne peut pas vraiment se réorganiser, n’est-ce pas ? Nous ne pouvons pas redéfinir nos objectifs et utiliser un ensemble de mesures entièrement différent, n’est-ce pas ?
Nous ne pouvons pas, et à moins d’éduquer et de convaincre ceux qui peuvent apporter les changements nécessaires, nous nous retrouverons coincés avec des processus manuels au milieu d’un pipeline par ailleurs automatisé.
Alors arrêtons d’utiliser NetOps comme bouc émissaire et reconnaissons qu’ils peuvent eux aussi être frustrés. Rappelez plutôt aux décideurs la nécessité de réévaluer les structures organisationnelles et de reprioriser les mesures pour mieux les aligner sur l'entreprise et le reste du pipeline continu.
Crier sur les gens du NetOps en première ligne peut être satisfaisant, mais cela ne change pas réellement la situation qui a donné lieu à la colère en premier lieu. Et sans changement, le pipeline ne va pas s’accélérer.
Soyez votre défenseur NetOps plutôt que son adversaire. Ils ont besoin de toute l’aide possible.