DevOps ou comment nous perdons des salaires et l'avenir de l'industrie informatique, deuxième partie

Le dernier article a déjà suscité beaucoup d'indignation, je pense que cet article ne sera plus aimé par beaucoup, je vais y décrire comment les clients voient un ingénieur DevOps.



Plus le temps passe, plus j'entends dire que «c'est le devoir des« devups », les demandes à la base de données veulent régler les devups, devinez comment et avec quelles dépendances le logiciel va au codeur - devups, evpn + bgp + ipsec + geo dns + autorisation réseau par certificats - devups, correction des erreurs d'architecture et proposition d'options sans effusion de sang - devups, transformer un pg_dump régulier en réplication synchrone - devups, être un psychanalyste pour les stations-service / PDG et équipe - devups.



Une autre tendance intéressante est l'équilibreur de charge k8s + pour tout éternuement. Il n'y a pas si longtemps, on m'a même proposé de mettre l'équilibreur de charge sur la base de données, peut-être que la charge moyenne diminuera et que les disques seront moins chargés .... K8s est généralement un sujet distinct, sur les mythes qui y sont associés, vous pouvez écrire 2-3 articles.



De plus en plus, les entreprises peuvent entendre dire que les développeurs et les ingénieurs se saoulent, que Sberbank a mis en place une bulle de savon et qu'un miracle est sur le point de se produire, et nous commencerons à travailler comme des gens ordinaires pour 60 à 80 000 personnes. Dans les régions, bien sûr, cela existe déjà, mais tout était triste là-bas, mais ici ils rêvent déjà pour toutes les villes sauf Moscou.



C'est encore plus amusant dans la même entreprise d'écouter à quel point tout est paresseux, des histoires sur l'inutilité des employés et que vous devez chercher des moyens de ne pas planifier le travail, l'architecture, penser à l'avenir, mais de donner une fessée à un code de mauvaise qualité à la vitesse de la lumière, car alors les devups «évoluent horizontalement ", Oui, nous avons 1 requête dans la base de données coûte 15% de la capacité du matériel, et 5 requêtes - un effondrement, et alors? La mise à l'échelle horizontale sans allocation de ressources nous sauvera !!! - la vérité n'est pas spécifiée comment. Surtout si la base de données est assez tordue en architecture, par exemple, PostgreSQL ou Elasticsearch par défaut.



Utiliser la technologie comme prévu? Non, c'est ennuyeux. Planification de l'architecture, des schémas de données et de leur traitement - pourquoi cela est coûteux et lent. Mais que faire? Il existe une solution - embauchez un développeur et blâmez-le pour tous les péchés mortels de votre projet, sans oublier d'ajouter - tout fonctionnait exactement avant votre arrivée. Et les journaux mentent, tout a fonctionné !!!



De plus en plus souvent, je vois des projets assez intéressants et prometteurs mourir, même au stade de leur création, simplement à cause de jeux politiques. Je communique avec RM, qui est déjà empêché depuis six mois de vendre un produit qui peut rapporter à l'entreprise des milliards de roubles par an, mais ils mettent constamment un rayon dans ses roues. Tout le monde cherche des moyens de faire du développement sans dépenser dessus, et la méthodologie DevOps est de plus en plus perçue comme un moyen de jeter un produit qui ne fonctionne pas dans la production et de couvrir les montants avec des conteneurs, des équilibreurs et des talons, même si cela conduit à des notes faibles et un grand nombre de négativité, l'essentiel est d'économiser développement.

Comme le montre l'enquête de l'article précédent, pour la majorité des visiteurs habr, les employeurs essaient de boucher plusieurs trous avec une seule personne. Naturellement, sans compenser ces obligations. Mais le problème est que l'entreprise elle-même en souffre. En raison des bas salaires et de la productivité élevée du travail par rapport au soutien financier et technique, l'entreprise survit, si, avec une direction comme dans la CEI, elle essayait de faire des affaires au Japon ou aux États-Unis, elle aurait fait faillite depuis longtemps.



De nombreuses méthodologies qui nous sont venues des pays développés étaient complètement déformées. Par exemple, Agile, Scrum, DevOps - les 3 méthodologies nécessitent des changements importants dans les processus métier pour fonctionner, mais la direction de la CEI n'est pas prête pour cela, il espère combiner vieilles habitudes et méthodologies modernes, nous sommes au sommet à l'ancienne et vous êtes de manière moderne et efficace en bas. Cela n'a aucun sens de mettre en œuvre les 3 méthodologies par le bas, la présence de cartes, de rapports quotidiens, de plans pour 2 semaines et de versions pour chaque ligne de code ne signifie pas que vous avez mis en œuvre ces méthodologies, cela signifie que vous avez introduit des processus de reporting supplémentaires qui aident simplement à trouver le coupable et l'excuse pour la haute direction. Il n'est que plus difficile pour le projet et les personnes qui commencent à travailler dans de telles conditions de mettre en œuvre leurs plans, car le nombre de rapports augmente beaucoup plus,que s'ils ne l'étaient pas.

Maintenant, il y a pas mal d'articles et de discours d'étranges responsables informatiques qui proposent déjà de payer pour les résultats, presque comme avant pour les lignes de code, en supprimant le temps de travail pour réfléchir à la mise en œuvre, considérant qu'il s'agit de 30 à 40 minutes, puis en écrivant uniquement du code. Dans le même temps, donnez-nous 2-3 semaines pour réfléchir et calculer les coûts et les risques liés aux décisions de gestion ... En conséquence, nous sommes de plus en plus confrontés au fait que la qualité des produits diminue inévitablement, bien sûr, ce n'est pas seulement un problème de l'industrie informatique, mais dans notre industrie c'est particulièrement aigu, car les échecs sont alors imputés aux programmeurs qui, comme «gaspillaient 180 millions de roubles», je J'ai déjà vu 4 projets qui, à la suite d'un tel processus, ne remplissent pas leurs tâches, mais ont dépensé 1 milliard de roubles ou plus,mais en conséquence, les informaticiens paresseux sont devenus coupables et ses procédures de signalement et de réglementation plus nombreuses commencent à corriger la situation. Pour assurer les fonctions de supervision, des managers supplémentaires sont embauchés et la masse salariale des informaticiens est réduite. Le nombre de décisions que nous prenons nous-mêmes diminue et la responsabilité et l'obligation de rendre compte augmentent, ce qui conduit à des problèmes encore plus graves.



Vous devez clairement tracer des lignes de responsabilité et les minimiser, sinon vous devenez simplement une victime dans n'importe quel jeu politique.



Dans le prochain article, j'écrirai davantage sur les raisons pour lesquelles DevOps et Agile, implémentés par le bas, ne seront jamais bénéfiques.