DevOps ou comment nous perdons des salaires et l'avenir de l'industrie informatique

Le plus triste dans la situation actuelle est que l'informatique devient progressivement une industrie où il n'y a pas du tout le mot «arrêt» dans le nombre de tâches par personne.



Lors de la lecture des offres d'emploi, parfois vous ne voyez même pas 2-3 personnes, mais toute une entreprise en une seule personne, tout le monde est pressé, la dette technique augmente, l'ancien héritage semble parfait dans le contexte des nouveaux produits, car il contient au moins des documents et des commentaires dans le code, nouveau Les produits sont écrits à la vitesse de la lumière, mais par conséquent, ils ne peuvent pas être utilisés pendant une autre année après leur écriture, et souvent cette année ne rapporte pas de profit, de plus, les coûts du «cloud» sont plus élevés que les ventes du service. L'argent des investisseurs va à la maintenance d'un service qui ne fonctionne pas encore, mais qui a déjà été remis au réseau en tant que travailleur.

À titre d'exemple: une entreprise bien connue dont le remasterisation d'un ancien jeu a reçu les notes les plus basses de l'histoire de l'industrie. J'étais l'un de ceux qui ont acheté ce produit, mais même maintenant, ce produit fonctionne terriblement, et en théorie, il n'aurait pas dû être mis en vente sous cette forme. Les remboursements, la baisse des notes, un grand nombre d'interdictions d'utilisateurs sur les forums pour les plaintes concernant les services. Le nombre de correctifs n'est pas incroyable, mais terrifiant, mais tout de même - le produit n'est pas utilisable. Si cette approche conduit à de tels résultats pour une entreprise qui se développe depuis 91, alors pour les entreprises qui débutent, la situation est encore pire.



Mais nous avons regardé les résultats de cette approche du côté de l'utilisateur du service, et regardons maintenant les problèmes que rencontrent les employés.



J'entends souvent dire que les équipes DevOps ne devraient pas exister, qu'il s'agit d'une méthodologie, etc., mais le problème est que, pour une raison quelconque, les entreprises ont cessé de chercher des nœuds, des dba, des ingénieurs d'infrastructure et des ingénieurs de construction - maintenant, c'est tout un ingénieur DevOps en une seule personne. Bien sûr, il y a encore de tels postes vacants dans les entreprises individuelles, mais il y en a de moins en moins. Beaucoup ont appelé ce développement, je vois personnellement une dégradation en cela, il est impossible de maintenir un bon niveau de connaissances dans tous les domaines, et en même temps, parviennent à ne pas travailler plus de 8 heures. Naturellement, ce sont des fantasmes. En réalité, de nombreux informaticiens sont obligés de travailler 12 ou 14 heures, dont 8 sont rémunérées. Et souvent sept jours sur sept, car «on m'a confié une tâche, il n'y a ni quais ni courbes, et même le service coûte de l'argent», et pour 1 une erreur dans le cloud peut, en principe, ne pas obtenir de salaire dans quelques mois, surtout si vous travaillez sur une IP.En fait, nous perdons notre parole en affaires, parallèlement à la séparation des tâches, je constate de plus en plus que les gestionnaires se lancent dans les processus de développement, ne comprenant généralement rien à leur sujet, ils confondent les données commerciales et le fonctionnement de l'application, ce qui entraîne le chaos.



Lorsque le chaos commence, l'entreprise veut trouver le coupable, et ici vous avez besoin d'un coupable universel, il est difficile d'accrocher la culpabilité à plus de 10 personnes, donc les gestionnaires combinent les positions, car plus un spécialiste a de responsabilités, plus il est facile de prouver sa négligence. Et dans les conditions d'Agile, trouver le "coupable" et fouetter est la base de cette méthodologie de faire des affaires en management. Agile a quitté l'informatique pendant longtemps, et son concept principal est devenu - l'exigence de résultats quotidiens. Le problème est qu'un spécialiste hautement spécialisé n'aura pas toujours un résultat quotidien, ce qui signifie qu'il sera plus difficile de signaler, et c'est une autre raison pour laquelle l'entreprise veut des «experts en tout». Mais la raison principale, bien sûr, est la masse salariale - c'est la raison principale de tous les changements, dans l'intérêt d'un bonus, les gens ont accepté de travailler pour eux-mêmes et ce type. Mais au final, comme dans d'autres domaines,il est simplement devenu maintenant un devoir, pour moins de paiement pour plus de services fournis.



Maintenant, vous pouvez souvent voir même des articles sur ce que les développeurs devraient être capables de déployer, devraient traiter de l'infrastructure aux côtés d'un ingénieur DevOps, mais à quoi cela mène-t-il? C'est vrai - à une baisse de la qualité des services, à une baisse de la qualité des développeurs. Il y a seulement 2 jours, j'ai expliqué au développeur que vous pouvez écrire et lire à partir de différents hôtes, et ils m'ont prouvé avec de la mousse à la bouche qu'ils n'avaient jamais vu cela, les voici dans les paramètres orm host, port, db, user, password et c'est tout .... Mais le développeur sait exécuter des déploiements, écrire des yamls ... Mais il oublie déjà les tests unitaires et les commentaires dans le code.



En conséquence, nous voyons ce qui suit - un surmenage constant, la recherche de solutions aux problèmes en dehors des heures de travail, une formation constante le week-end, et non pas pour augmenter les revenus, mais pour nous maintenir à flot. Les développeurs sont obligés d'aider l'ingénieur DevOps avec CI / CD, et si le développeur n'a pas le temps, il commence à coudre, et les gestionnaires commencent à se frapper la cervelle, et si cela n'aide pas à augmenter le désir de faire des heures supplémentaires, puis appliquer des pénalités et des amendes, une personne est à la recherche d'un nouvel emploi. laissant derrière lui une dette technique de la taille de l'Everest, par conséquent, la dette commence à croître parmi les développeurs, car ils sont obligés d'écrire du code avec moins de refactoring afin d'avoir le temps d'aider soit l'ancien ou le nouvel ingénieur DevOps, et les managers sont plutôt satisfaits de tout, car il y a un coupable et il est immédiatement visible, ce qui signifie que la règle principale de la gestion Agile est respectée, le coupable est trouvé,les résultats de son fouet sont visibles.



Une fois à l'ITGM, j'ai donné une conférence «quand allons-nous apprendre à dire non» - ses résultats ont été très révélateurs. Un très grand nombre de personnes croient que ce mot est tabou, et tant que nous n’arrêterons pas de penser ainsi, les problèmes ne feront qu’augmenter.



Une partie de cet article a été inspirée par cet article , mais je l'écrirai probablement plus tard en termes moins suaves.