Avantages / inconvénients de l'arrêt d'un workflow DevOps?

J'essaie d'évaluer si c'est une bonne idée de passer d'un flux de travail de style devops aux dev-then-ops traditionnels (je ne sais pas comment vous appelez cela).

Nous sommes un petit département de 5 personnes niché au sein d'une entreprise de médias traditionnels de 4000 employés (par exemple non-logiciel). Il y a deux ans, nous avons commencé à créer des logiciels pour permettre à notre département d'augmenter considérablement notre production. Nous avons assez bien réussi et la grande entreprise commence à en prendre note. À ce jour, nous avons été les seuls responsables de la conception, du développement et du déploiement de ce qui est devenu une plateforme de microservices AWS ~ 10 services. Notre équipe ne s'identifie pas comme DevOps, mais sans aucun doute, nous vivons la vie DevOps, chaque développeur étant intimement familiarisé avec le code et le système sur lequel il fonctionne.

L'une des questions auxquelles nous serons confrontés sous peu est de savoir quelles «économies» sont partagées entre nous et le service informatique de notre société mère. Notre maître d'ouvrage préfère généralement l'externalisation à l'apprentissage en interne, donc dans notre cas, ces gains d'efficacité signifient probablement que le plus possible de travail informatique "de notre assiette" est possible. Actuellement, je dirais que notre équipe a un partage de 70/30% entre l'expérience dans le codage et l'infrastructure. Le service informatique est solidement ancré dans le domaine informatique, sans transition visible dans le développement logiciel.

Notre maître d'ouvrage (une personne non technique) espère qu'en transférant autant de travail que possible à l'équipe informatique, nous verrons une augmentation de la productivité d'environ 1: 1 pour chaque heure de travail que nous perdrons. Je suis cependant sceptique à ce sujet. Notre produit est encore pré-bêta (bien qu'il soit déjà un atout commercial important) et dans notre expérience limitée avec le service informatique, il y a généralement des retards importants pour des choses aussi simples que les changements de permission du système de fichiers.

À l'heure actuelle, ma solution idéale serait que le service informatique nous «adopte» et nous permette de continuer à déployer notre propre travail, tout en nous assurant de répondre aux normes et aux exigences du bureau informatique. Je ne sais pas dans quelle mesure c'est réaliste. De plus, c'est presque l'approche opposée que notre maître d'ouvrage préconise, car cela ajouterait des travaux d'exploitation supplémentaires à court terme.

Dans notre situation, quels sont les avantages / inconvénients probables de rester avec l'approche DevOps par rapport au transfert de l'informatique?

Ce n'est pas une bonne idée.

D'après mon expérience, vous gagnerez les inconvénients des deux alors que les avantages projetés ne se matérialiseront pas.

Détaillé:

1. Vous perdrez de la vitesse.
   Les TI se conformeront à leur propre norme. La nouvelle tâche (pour eux) suivra le même modèle «lent» que tout leur travail a maintenant. Soyez prêt, ils trouveront cela difficile - donc encore moins de vitesse que les actions simples standard.
2. Vous ne pourrez pas décharger.
   IL s'appuiera sur vous pour chaque anomalie. Vous vous efforcerez de mettre un gars au courant - et la prochaine chose que vous allez maintenant vous répéter parce que la tâche / problème / jour suivant, il y aura un nouveau gars, encore une fois.
3. La documentation sera requise, mais elle n'aidera pas.
   Encore une fois, le comportement du modèle sera que les manuels courts ne parviendront pas à détecter chaque anomalie et que les textes complets ne seront pas lus car trop longs. Donc, tout investissement ici sera une perte, tout comme l'énorme effort nécessaire pour mettre en œuvre des améliorations pour que vos outils soient de qualité «rétractable».

Enfin et surtout, aucun problème ne se répercutera sur vous. Tar, principe de tarbrush.

Si ce qui précède semble cynique, eh bien, j'ai bien peur d'y être allé. À plusieurs reprises.

Que faire à la place?

Allez faire du shopping dans le service informatique, trouvez-vous un candidat utile et gardez ce type en prêt pour vous soulager de la charge de travail.

Vous pouvez trouver de nombreuses réponses dans le résultat de l'enquête DevOps que vous devriez demander au propriétaire du produit de lire. Il s'agit d'un document écrit spécifiquement pour les hommes d'affaires ayant peu de connaissances techniques parlant dans les termes qu'il doit comprendre.

En moyenne, vous aurez besoin d'un développeur supplémentaire pour 4 personnes pour conserver le même niveau de développement des fonctionnalités (38% contre 49% de temps consacré aux nouveaux travaux). Votre temps moyen pour vous remettre d'un échec diminuera jusqu'à 25 fois. Votre travail sera 20% moins agréable et vous aurez 40% de chances de recommander votre travail à un ami. Ces trois faits devraient suffire.

Ce que vous perdrez en vous inscrivant dans l'organisation informatique, c'est la partie "Dev" de votre petite équipe DevOps. Lorsque les équipes sont segmentées en rôles artificiels de NetOps, SysOps et Dev, vous introduisez les problèmes suivants:

1. Tracasseries administratives et isolement inutiles - Pour faire quoi que ce soit, les développeurs devront soumettre un ticket au service informatique et attendre qu'ils le mettent en œuvre. Ils ne pourront plus l'implémenter et interagir avec eux-mêmes - jusqu'à et y compris leurs instances de développement et d'assurance qualité, ce qui limitera l'infrastructure à coder. Ils sont bloqués sur la barrière VM au lieu de pouvoir coder sur la pile complète. Si ce qu'ils soumettent au service informatique ressemble à du code DevOps, ils seront mal équipés pour le gérer et pourraient revenir à des déploiements manuels.
2. Négligence - Alternativement, ils peuvent simplement le déployer tel quel, puis négliger la bête parce qu'ils ne savent pas comment interagir avec elle - et ils ne sont pas des développeurs, donc le code n'est pas leur problème.
3. Pannes - L'un des avantages souvent négligés de DevOps est sa nature programmatique. Bien sûr, le déploiement de ce serveur peut prendre plus de temps en le traitant comme du code, mais cela automatise les erreurs humaines. La façon dont il est entré dans le développement est la façon dont il ira en AQ / Test est la façon dont il ira en prod, réduisant ainsi les pannes. Lorsque les développeurs perdent l'accès à l'équipement réseau dont ils ont besoin pour déployer leur service ou que l'infrastructure de calcul prend non seulement plus de temps, mais elle introduit davantage d'humains faillibles, ce qui entraînera plus de pannes.
4. Documentation - Dans certains sens, le code DevOps est auto-documenté. Vous savez comment le serveur a été construit et déployé car le code vous le dit. Dans 5 ans, lorsqu'il sera temps de passer à CentOS 8 ou autre, personne ne saura plus comment déployer votre application, y compris au niveau du réseau, du stockage, de la surveillance et des couches de sauvegarde.

En bref, vous devriez suggérer à votre propriétaire de projet de prendre le temps de lire The Mythical Man-Month pour le désabuser de l'idée que vous verrez une relation 1: 1 dans la productivité et The Phoenix Project qui est un bon roman (et divertissant) illustration de ce qui est gagné et perdu en utilisant DevOps dans un langage non technique pour des personnes non techniques. Si le propriétaire du projet a une sorte de trajet, un livre audio Audible de The Phoenix Project est disponible.

Je vous suggère d'adopter une partie de l'équipe informatique et de leur donner une formation approfondie sur le nouveau système.

Une fois qu'ils comprennent parfaitement le système, il est logique de le leur décharger.

Sinon, vous deviendrez un centre de support informatique - et passerez beaucoup de temps à combattre les incendies pendant qu'ils apprendront les subtilités du nouveau système.