Cette question revient de plus en plus lorsque l’on aborde la mise en place d’une approche DevOps dans une grande entreprise. Certaines personnes voient le DevOps comme le NoOps : « You build it, you run it! ». Est ce vraiment la réalité du terrain ?

« You build it, you ship it, you run it! »

Dans le monde du NoOps, l’équipe de développement agile est en charge des opérations. Les incréments produits par l’équipe sont revus, testés, validés par un maximum de processus automatisés afin de canaliser le déploiement jusqu’en production de manière sécurisée. Plus on déploie de petits incréments souvent, moins on a d’incidents de production. La mise en production devient donc un « non évènement ». Côté production, la supervision, la mise à l’échelle et la maintenance sont totalement automatisés par l’équipe de développement. Si un incident survient, n’importe quel membre de l’équipe de développement est à même d’intervenir pour resource le problème et prendre les actions nécessaires pour que celui ci ne se reproduise pas.

Est ce que cela fonctionne à tous les coups ?

De même que pour l’agilité, le niveau de maturité DevOps peut être très différent d’un contexte à l’autre. Le NoOps nécessite un très fort niveau de maturité. Google, Amazon, Netflix, Facebook, Microsoft travaillent sur leurs processus opérationnels dans un contexte cloud depuis des années pour en arriver là et ils continuent de s’améliorer. Est ce vraiment envisageable à court terme pour votre organisation ? Cela dépend de nombreux facteurs. Certaines personnes pense que le NoOps ne permet que de réduire les coûts en supprimant les Ops. C’est peut être le cas sur du très long terme mais cela n’est pas l’objectif premier du NoOps. Il s’agit de pouvoir délivrer de la valeur à un produit de manière beaucoup plus rapide. De réduire le « Lead Time » à son minimum et de pouvoir réagir rapidement dans un contexte changeant.

Le NoOps c’est bien mais est ce que cela correspond à la vision de mon organisation ?

Tout d’abord, lorsque l’on cherche à mettre en place une démarche DevOps, il faut se donner une vision. Quels sont les objectifs que je cherche à atteindre dans 1 an, 6 mois, 3 mois ? Ensuite, il faut trouver le ou les chemins pour y arriver.

Les grosses organisation ont cherché depuis de nombreuses années à diminuer leurs coûts opérationnels en mutualisant les infrastructure et en créant des pôles d’expertise technique. Cette approche a créé un silo naturel entre les entités métier et les entités opérationnels. Les développeurs se sont rapproché depuis quelques années du métier et travaillent en agile. Ils délivrent des incréments qui sont « prêts » à être déployer en production par les Ops. Ils envoient leur package par dessus le mur de la confusion aux équipes opérationnelles qui le déploient à leur tour.

Le NoOps est il pertinent dans mon contexte ?

Les opérations sont avant tout une histoire de rôles et de responsabilités. En cas d’incident, qui est responsable de trouver une solution ? Quel est l’engagement de service vis à vis du client (SLA)? C’est aussi une question de métier et de compétences. Certains développeurs sont extrêmement polyvalents mais sont ils en mesure d’opérer 24h sur 24 une plateforme de production ? Peuvent ils s’organiser pour le faire d’un point de vue logistique ? Ont ils assez de compétences opérationnels sur la supervision, le réseau et la sécurité ?

Ce sont les raisons pour lesquelles le NoOps complet n’est pas applicable dans beaucoup d’organisations.

Vers le NewOps…

La mise en œuvre d’une approche DevOps impacte fortement l’organisation et nécessite un accompagnement à la fois sur la mise en place des outils mais aussi sur le changement de culture. Cet accompagnement débouchera sur de nouveaux processus opérationnels, plus légers, plus agiles et adaptés aux enjeux du cloud. Le NewOps réinvente le métier de l’Ops et le recentre sur le métier par le biais de l’agilité. Le métier d’Ops n’est pas compromis, bien au contraire. Il évolue vers l’excellence opérationnelle au sein d’un écosystème agile.