Discussion :

[Olivier Famien]

DevOps contribue à réduire les coûts en entreprises
Selon une étude menée par IDC en collaboration avec AppDynamics

Une étude a été menée d’octobre à novembre 2014 par IDC en coopération avec AppDynamics afin de mesurer l’adoption et l’impact des pratiques devOps au sein de plus d’une vingtaine d’entreprises listées dans le classement de Fortune 1000.

Pour rappel, l’approche devOps est une méthode de travail ayant pour but de réduire les écarts de collaboration entre les équipes de développement et celles des opérations. Une bonne implémentation en entreprise permet de dégager des avantages énormes et réduire un certain nombre de dysfonctionnements.

Lors de cette étude Stephen Elliot, le vice-président d’IDC explique que « nous couvrons une gamme de sujets à travers le paysage des entreprises et des technologies d’informations, tout en portant le premier regard sur les instruments de mesure des pratiques devOps dans ces entreprises. Notre enquête indique que plus de 43 % de ces entreprises ont adopté une pratique devOps, et 40 % évaluent activement devOps ».

Au soir de cette étude, il ressort que lorsqu’il survient un dysfonctionnement des infrastructures, les coûts peuvent atteindre 100 000 $ par heure pour les grandes entreprises et même grimper pour atteindre un coût variant entre 500 000 et 1 million de dollars.

De même, peu importe que le dysfonctionnement soit structurel ou applicatif, 35 % des personnes interrogées estiment devoir dégager 1 à 12 heures de temps pour la réparation des anomalies. Cela représente un gap énorme à combler surtout pour certaines entreprises dont les transactions sont évaluées en seconde. Dans ce cas, vous pouvez imaginer le sort d'une telle entreprise pour laquelle les délais de réparation sont étendus à plusieurs jours. 17 % des arrêts des infrastructures et 13 % des échecs des applications sont concernés par ces réparations nécessitant un ou plusieurs jours.

En principe, l’adoption de la pratique devOps devrait favoriser une bonne organisation et permettre conséquemment de réduire les différents coûts liés à ces pannes. Pour y arriver, les personnes sondées comptent prendre des initiatives afin d'intégrer l'approche devOps dans leur environnement. Ainsi, 60 % des personnes ayant répondu comptent renforcer l’automatisation, 43 % prévoient d’assurer une intégration continue, 43 % entendent mettre en place une gestion et un suivi d’applications et le même pourcentage comptent faire des tests automatisés (43 %).

Toutefois, s'il est vrai que de nombreux avantages peuvent être tirés de cette pratique, il faut néanmoins noter que l’implémentation ne se fait sans heurts. En effet, plus de la moitié des personnes interrogées pointent du doigt des freins culturels comme le plus gros risque dans la mise en œuvre de cette pratique en entreprise. 40 % des personnes sondées soulèvent le problème de la fragmentation des processus, tandis qu’un peu plus du quart évoquent le manque de soutien de la part des ressources dirigeantes.

En dehors de ces aspects, cette étude a également permis de relever le lien étroit entre le bon fonctionnement des applications – infrastructures et le succès d’une entreprise. C’est pourquoi Jyoti Bansal, fondateur d’AppDynamics, « souligne que les performances des applications sont égales aux performances des entreprises ». L’étude va même plus loin en démontrant que les technologies de l'information sont en train de passer de devOps à BizDevOps. Dans ce modèle organisationnel, les travailleurs IT doivent se rapprocher des chefs d’entreprises afin de mieux comprendre comment les performances et les comportements des clients impactent les transactions financières.

Source : AppDynamics

Télécharger le rapport complet de l'étude


Et vous ?

Que pensez-vous des conclusions du rapport ?

Utilise-t-on une démarche devOps dans votre entreprise ?

[minirop]

on passe de "1 developpeur + 1 admin système" à "1 DevOps", donc forcément que ça coûte moins cher.

[Saverok]

on passe de "1 developpeur + 1 admin système" à "1 DevOps", donc forcément que ça coûte moins cher.

La "bonne pratique" de la mise en place du devOps, ce n'est pas une personnes à tous les postes (AMOA /conception / réa / recette / prod / admin / etc)
Mais plutôt de faire tourner les équipes
C'est à dire que le développeur ne fait pas que du dev, l'AMOA que de l'AMOA, etc mais tout le monde fait de tout à un moment donné et change de poste
Ainsi, à chaque fois que tu fais une tâche, tu n'es pas enfermé dans tes propres contraintes et spécificités de la tâche mais au contraire, tu prends du recules et tu tiens comptes des contraintes et spécificités des autres tâches en amont et en aval
Bien évidement, cela favborise la collaboration au sein de l'équipe car chacun à ses spécialités et qu'il aura besoin de l'assistance d'un autre membre de l'équipe pour les tâches pointues (le dev qui faire de l'admin aura sans doute besoin de sollicité l'admin qui fait de la recette, par exemple)

Ainsi, le développeur sera plus appliqué à écrire des logs pertinents car il sait (car à un moment donné, il sera ou a été à ce poste) que lors de la prod et de la maintenance, les logs sont essentiels à une analyse rapide et précise (alors que pour le dev, les logs n'apportent rien et son plus une contrainte qu'autre chose...).

Ensuite, cet esprit, auquel j'adhère totalement, est perverti pour faire de la réduction de personnel par le raccourci : "puisque le collaborateur est compétent/formé à tous les postes, on peut réduire la taille de l'équipe..."

[Glutinus]

Ainsi, le développeur sera plus appliqué à écrire des logs pertinents car il sait (car à un moment donné, il sera ou a été à ce poste) que lors de la prod et de la maintenance, les logs sont essentiels à une analyse rapide et précise (alors que pour le dev, les logs n'apportent rien et son plus une contrainte qu'autre chose...).

Oui. Enfin je dirai bien qu'il l'a toujours su, en théorie et par expérience, que de bonnes logs sont toujours utiles. Mais encore une fois quand les délais sont réduits, c'est du "on verra plus tard" et pour la conscience du développeur "c'est pas moi qui vais me le taper" (ou pas)...

[RyzenOC]

Oui. Enfin je dirai bien qu'il l'a toujours su, en théorie et par expérience, que de bonnes logs sont toujours utiles. Mais encore une fois quand les délais sont réduits, c'est du "on verra plus tard" et pour la conscience du développeur "c'est pas moi qui vais me le taper" (ou pas)...

Il est la le problème, avec des délai toujours plus serré, on peut pas faire de la qualité, on vas a l'essentiel et on zap les finissions malheureusement.
Dans mon ancien projet, j'ai du abandonnée la création de log et et zappé la partie optimisation, car pas le temps, c'est triste car on nous empêche de bien travaillé.

[pmithrandir]

Devops, c'est surtout une réponse marketing a un problème de process et de manque de qualification des équipes sur des domaines variés pour moi.

Quand on voit le cout d'un opérationnel, sa formation, on arrive a quelqu'un avec un bac +2 et une compétence qui peut etre faible. En résumé, 90% de son travail peut consister à recopier des lignes de code, et a redemarrer un serveur. Ce qui sur une équipe de 100 personnes vetut dire avoir 90 personnes non qualifiées et 10 un peu plus haut niveau.

A coté de ca, on a des services developés et mis en prod par des developpeurs, qui vont être bine plus doués, mais c'est assez normal, on les forme a bzc +5 et ils connaissent le produit sur le bout des ongles. Même si c'est pas propre, ils peuvent réparer vite, parfois au risque de casser autre chose, mais on l'oublie vite.

Au final, devops, c'est faire par des gens cher le travail que des gens pas cher peuvent faire aussi bien avec les bon outils et la bonne doc.
C'est une jolies méthode pour contrer le fait que les dev et les opérations ne discutent pas(et je ne parle pas seulement de définir des règles d'opérations, mais de faire des retours d'expérience). Il suffit souvent de les mettrent dans une salle ensemble 2 heures par mois pour avoir le même résultat.

Un des problèmes du devops par contre, c'est le mélange des genres. Par définition, on a deux métiers assez différents avec des contraintes totalement opposées :
- les opérations qui fonctionnent en mode 24/24, qui opnt des astreintes, mais qui en échange ont des niveaux de difficultés simples. Quand ca devient compliqué, on escalade après avoir mis un patch rapide(qui souvent consiste à faire un reboot)
- les developpeurs qui sont dans une démarche créative, démarche qui ne fonctionne à plein qu'avec des personnes non stressées, reposées et non interrompue tout le temps.

En plus, d'un point de vue business, on preferera parfois redemarrer le serveur tous les jours pour un cout de 20€ que d'utiliser un dev pour 2 mois pour résoudre le problème. les priorités sont différentes et le cout peut être bien inférieur.

Bref, après l'agilité produit à la mode, on a devops... et comme d'hab dans 5 ans quand on nous demandera si on fait du devops en entretien, on répondra :
J'en fait, mais on s'adapte aux contraintes des projets... ce qui voudra dire : on travaille comme avant, mais on a changer le nom sur l'étiquette.

[Bousk]

Et dans quelques mois/années, on révolutionnera encore les termes en créant un "DevOps fullstack".
Où comment nos cravateux veulent créer des termes tendances pour limiter les frais, aux frais des petits nouveaux.

on passe de "1 developpeur + 1 admin système" à "1 DevOps", donc forcément que ça coûte moins cher.

Ils ont compris qu'on ne pouvait pas payer les gens moins cher, alors ils prennent le problème dans l'autre sens. Au lieu de 2 personnes, 2 charges, 2 salaires, il n'y a plus que 1 personne, qui fait 2 boulots pour 1 salaire (ne nous leurrons pas, le salaire ne bougera pas lui ) mais avec un titre de poste sexy.

[el_slapper]

Et dans quelques mois/années, on révolutionnera encore les termes en créant un "DevOps fullstack".
Où comment nos cravateux veulent créer des termes tendances pour limiter les frais, aux frais des petits nouveaux.


Ils ont compris qu'on ne pouvait pas payer les gens moins cher, alors ils prennent le problème dans l'autre sens. Au lieu de 2 personnes, 2 charges, 2 salaires, il n'y a plus que 1 personne, qui fait 2 boulots pour 1 salaire (ne nous leurrons pas, le salaire ne bougera pas lui ) mais avec un titre de poste sexy.

et ça n'avancera pas plus, mais bon, comme entretemps ils seront partis ailleurs en doublant leur salaire, ils s'en foutent éperdument...