On sait que la compétence du CTO n'est testée que la deuxième fois qu'il exerce ce rôle. Parce que c’est une chose de travailler dans une entreprise pendant plusieurs années, d’évoluer avec elle et, étant dans le même contexte culturel, de recevoir progressivement plus de responsabilités. Et c’en est une autre d’accéder directement au poste de directeur technique dans une entreprise avec un bagage historique et un tas de problèmes soigneusement balayés sous le tapis.

En ce sens, l'expérience de Leon Fire, qu'il a partagée sur Conférence DevOps, pas tout à fait unique, mais multiplié par son expérience et le nombre de rôles différents qu'il a réussi à essayer au cours de 20 ans, il est très utile. Sous la coupe se trouve une chronologie des événements sur 90 jours et de nombreuses histoires dont il est amusant de rire lorsqu'elles arrivent à quelqu'un d'autre, mais qui ne sont pas si amusantes à affronter en personne.

Léon parle un russe de manière très colorée, donc si vous disposez de 35 à 40 minutes, je vous recommande de regarder la vidéo. Version texte pour gagner du temps ci-dessous.

La première version du rapport était une description bien structurée du travail avec les personnes et les processus, contenant des recommandations utiles. Mais elle n'a pas fait part de toutes les surprises rencontrées en cours de route. Par conséquent, j'ai changé le format et présenté les problèmes qui se présentaient devant moi comme un diable dans la nouvelle entreprise, ainsi que les méthodes pour les résoudre par ordre chronologique.

Un mois avant

Comme beaucoup de bonnes histoires, celle-ci a commencé avec l’alcool. Nous étions assis avec des amis dans un bar et, comme on s'y attendait parmi les informaticiens, tout le monde pleurait à cause de ses problèmes. L'un d'eux venait de changer de travail et parlait de ses problèmes avec la technologie, avec les gens et avec l'équipe. Plus j'écoutais, plus je réalisais qu'il devrait simplement m'embaucher, car c'est le genre de problèmes que je résous depuis 15 ans. Je le lui ai dit et le lendemain, nous nous sommes rencontrés dans un environnement de travail. L’entreprise s’appelait Teaching Strategies.

Teaching Strategies est un leader du marché des programmes destinés aux très jeunes enfants, de la naissance à trois ans. L'entreprise « papier » traditionnelle a déjà 40 ans et la version numérique SaaS de la plateforme en a 10. Relativement récemment, le processus d'adaptation du numérique aux standards de l'entreprise a commencé. La « nouvelle » version lancée en 2017 était presque comme l’ancienne, sauf qu’elle fonctionnait moins bien.

La chose la plus intéressante est que le trafic de cette entreprise est très prévisible : de jour en jour, d'année en année, vous pouvez très clairement prédire combien de personnes viendront et quand. Par exemple, entre 13 heures et 15 heures, tous les enfants des écoles maternelles se couchent et les enseignants commencent à saisir les informations. Et cela se produit tous les jours, sauf le week-end, car presque personne ne travaille le week-end.

En regardant un peu plus loin, je constate que j’ai commencé mon travail pendant la période de plus fort trafic annuel, ce qui est intéressant pour diverses raisons.

La plateforme, qui semblait n'avoir que 2 ans, possédait une pile particulière : ColdFusion & SQL Server de 2008. ColdFusion, si vous ne le savez pas, et très probablement vous ne le savez pas, est un PHP d'entreprise sorti au milieu des années 90, et depuis lors, je n'en ai même plus entendu parler. Il y avait aussi : Ruby, MySQL, PostgreSQL, Java, Go, Python. Mais le monolithe principal fonctionnait sur ColdFusion et SQL Server.

Problèmes

Plus je discutais avec les employés de l'entreprise du travail et des problèmes rencontrés, plus je réalisais que les problèmes n'étaient pas seulement de nature technique. D'accord, la technologie est ancienne - et ils n'y ont pas travaillé, mais il y a eu des problèmes avec l'équipe et avec les processus, et l'entreprise a commencé à le comprendre.

Traditionnellement, leurs techniciens s'asseyaient dans un coin et effectuaient une sorte de travail. Mais de plus en plus d’affaires ont commencé à passer par la version numérique. Par conséquent, au cours de la dernière année avant que je commence à travailler, de nouveaux sont apparus dans l'entreprise : conseil d'administration, CTO, CPO et directeur QA. Autrement dit, l’entreprise a commencé à investir dans le secteur technologique.

Les traces d’un lourd héritage ne se trouvaient pas seulement dans les systèmes. L’entreprise avait des processus hérités, des personnes héritées, une culture héritée. Il fallait changer tout cela. J’ai pensé que ce ne serait certainement pas ennuyeux et j’ai décidé de l’essayer.

Deux jours avant

Deux jours avant de commencer un nouvel emploi, je suis arrivé au bureau, j'ai rempli les derniers documents, j'ai rencontré l'équipe et j'ai découvert que l'équipe était alors aux prises avec un problème. C'est que le temps de chargement moyen des pages est passé à 4 secondes, soit 2 fois.

À en juger par le graphique, quelque chose s’est clairement produit, et on ne sait pas exactement quoi. Il s'est avéré que le problème était la latence du réseau dans le centre de données : une latence de 5 ms dans le centre de données s'est transformée en 2 s pour les utilisateurs. Je ne savais pas pourquoi cela s’était produit, mais de toute façon, on a appris que le problème venait du centre de données.

Le premier jour

Deux jours se sont écoulés et dès mon premier jour de travail, j'ai découvert que le problème n'avait pas disparu.

Pendant deux jours, les pages des utilisateurs se chargeaient en moyenne en 4 secondes. Je demande s'ils ont trouvé quel est le problème.

- Oui, nous avons ouvert un ticket.
- et?
- Eh bien, ils ne nous ont pas encore répondu.

Puis j’ai réalisé que tout ce dont on m’avait parlé auparavant n’était qu’une petite partie de l’iceberg que je devais combattre.

Il y a une bonne citation qui correspond très bien à cela :

« Parfois, pour changer de technologie, il faut changer d’organisation. »

Mais comme j’ai commencé à travailler au moment le plus chargé de l’année, j’ai dû envisager les deux options pour résoudre le problème : à la fois rapide et à long terme. Et commencez par ce qui est critique en ce moment.

La troisième journée

Ainsi, le chargement dure 4 secondes, et de 13 à 15 les plus gros pics.

Le troisième jour de cette période, la vitesse de téléchargement ressemblait à ceci :

De mon point de vue, rien n’a fonctionné du tout. Du point de vue de tous, le rythme était un peu plus lent que d'habitude. Mais cela ne se produit pas comme ça : c’est un problème sérieux.

J'ai essayé de convaincre l'équipe, à laquelle ils ont répondu qu'ils avaient simplement besoin de plus de serveurs. Il s’agit bien sûr d’une solution au problème, mais ce n’est pas toujours la seule ni la plus efficace. J'ai demandé pourquoi il n'y avait pas assez de serveurs, quel était le volume de trafic. J'ai extrapolé les données et constaté que nous avons environ 150 requêtes par seconde, ce qui, en principe, se situe dans des limites raisonnables.

Mais il ne faut pas oublier qu’avant d’obtenir la bonne réponse, il faut poser la bonne question. Ma question suivante était : de combien de serveurs frontaux disposons-nous ? La réponse « m'a un peu dérouté » : nous avions 17 serveurs frontaux !

— Je suis gêné de demander, mais 150 divisé par 17 donne environ 8 ? Êtes-vous en train de dire que chaque serveur permet 8 requêtes par seconde, et si demain il y a 160 requêtes par seconde, nous aurons besoin de 2 serveurs supplémentaires ?

Bien entendu, nous n’avons pas eu besoin de serveurs supplémentaires. La solution était dans le code lui-même, et en apparence :

var currentClass = classes.getCurrentClass();
return currentClass;

Il y avait une fonction getCurrentClass(), parce que tout sur le site fonctionne dans le contexte d'un cours - c'est vrai. Et pour cette fonction, sur chaque page, il y avait 200+ demandes.

La solution de cette façon était très simple, vous n’aviez même pas besoin de réécrire quoi que ce soit : il suffit de ne plus demander les mêmes informations.

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

J'étais très heureux parce que j'ai décidé que dès le troisième jour j'avais trouvé le problème principal. Aussi naïf que j’étais, ce n’était qu’un problème parmi tant d’autres.

Mais la résolution de ce premier problème a fait baisser le graphique beaucoup plus bas.

En parallèle, nous faisions d’autres optimisations. Il y avait beaucoup de choses en vue qui pourraient être réparées. Par exemple, le même troisième jour, j'ai découvert qu'il y avait quand même un cache dans le système (au début, je pensais que toutes les demandes provenaient directement de la base de données). Quand je pense à un cache, je pense à Redis standard ou à Memcached. Mais j'étais le seul à le penser, car ce système utilisait MongoDB et SQL Server pour la mise en cache - le même à partir duquel les données venaient d'être lues.

Jour dix

La première semaine, j'ai traité de problèmes qui devaient être résolus immédiatement. Au cours de la deuxième semaine, je suis venu au stand-up pour la première fois pour communiquer avec l'équipe, voir ce qui se passait et comment se déroulait tout le processus.

Quelque chose d’intéressant a encore été découvert. L'équipe était composée de : 18 développeurs ; 8 testeurs ; 3 gérants ; 2 architectes. Et ils ont tous participé à des rituels communs, c'est-à-dire que plus de 30 personnes sont venues au stand-up chaque matin et ont raconté ce qu'elles avaient fait. Force est de constater que la réunion n’a pas duré 5 ou 15 minutes. Personne n’a écouté personne car tout le monde travaille sur des systèmes différents. Sous cette forme, 2 à 3 tickets par heure pour une séance de toilettage constituaient déjà un bon résultat.

La première chose que nous avons faite a été de diviser l’équipe en plusieurs lignes de produits. Pour différentes sections et systèmes, nous avons affecté des équipes distinctes, comprenant des développeurs, des testeurs, des chefs de produit et des analystes commerciaux.

En conséquence, nous avons obtenu :

• Réduire les stand-ups et les rassemblements.
• Connaissance du sujet du produit.
• Un sentiment d'appartenance. Lorsque les gens bricolaient constamment les systèmes, ils savaient que quelqu'un d'autre devrait probablement travailler sur leurs bugs, mais pas eux-mêmes.
• Collaboration entre groupes. Inutile de dire que le contrôle qualité ne communiquait pas beaucoup avec les programmeurs auparavant, le produit faisait son propre travail, etc. Ils ont désormais un point de responsabilité commun.

Nous nous sommes principalement concentrés sur l'efficacité, la productivité et la qualité - ce sont les problèmes que nous avons essayé de résoudre avec la transformation de l'équipe.

Jour onze

En changeant la structure de l'équipe, j'ai découvert comment compter HistoirePoints. 1 SP équivalait à un jour et chaque ticket contenait des SP pour le développement et le contrôle qualité, soit au moins 2 SP.

Comment ai-je découvert cela ?

Nous avons trouvé un bug : dans l'un des rapports, où sont renseignées les dates de début et de fin de la période pour laquelle le rapport est nécessaire, le dernier jour n'est pas pris en compte. Autrement dit, quelque part dans la requête, il n'y avait pas <=, mais simplement <. On m'a dit qu'il s'agissait de trois Story Points, c'est-à-dire Jour 3.

Après cela, nous :

• Le système de notation Story Points a été révisé. Désormais, les correctifs pour les bugs mineurs qui peuvent être rapidement transmis via le système parviennent plus rapidement à l'utilisateur.
• Nous avons commencé à fusionner les tickets associés pour le développement et les tests. Auparavant, chaque ticket, chaque bug constituait un écosystème fermé, non lié à quoi que ce soit d'autre. La modification de trois boutons sur une page aurait pu donner lieu à trois tickets différents avec trois processus d'assurance qualité différents au lieu d'un test automatisé par page.
• Nous avons commencé à travailler avec des développeurs sur une approche d'estimation des coûts de main-d'œuvre. Trois jours pour changer un bouton, ce n'est pas drôle.

Vingtième jour

Au milieu du premier mois, la situation s'est un peu stabilisée, j'ai compris ce qui se passait essentiellement et j'ai déjà commencé à regarder vers l'avenir et à réfléchir à des solutions à long terme.

Objectifs à long terme:

• Plateforme gérée. Des centaines de demandes sur chaque page ne sont pas sérieuses.
• Tendances prévisibles. Il y avait des pics de trafic périodiques qui, à première vue, ne correspondaient pas à d'autres mesures - nous devions comprendre pourquoi cela se produisait et apprendre à prédire.
• Extension de la plateforme. L'activité est en constante croissance, de plus en plus d'utilisateurs viennent et le trafic augmente.

Autrefois, on disait souvent : « Réécrivons tout en [langage/framework], tout fonctionnera mieux ! »

Dans la plupart des cas, cela ne fonctionne pas, c'est bien si la réécriture fonctionne. Par conséquent, nous devions créer une feuille de route - une stratégie spécifique illustrant étape par étape comment les objectifs commerciaux seront atteints (ce que nous ferons et pourquoi), qui :

• reflète la mission et les objectifs du projet ;
• priorise les objectifs principaux ;
• contient un calendrier pour les réaliser.

Avant cela, personne n’avait parlé à l’équipe du but des changements apportés. Cela nécessite les bonnes mesures de réussite. Pour la première fois dans l'histoire de l'entreprise, nous avons défini des KPI pour le groupe technique, et ces indicateurs étaient liés aux indicateurs organisationnels.

Autrement dit, les KPI organisationnels sont pris en charge par les équipes et les KPI des équipes sont pris en charge par les KPI individuels. Sinon, si les KPI technologiques ne coïncident pas avec ceux organisationnels, alors chacun tire la couverture sur lui-même.

Par exemple, l’un des KPI de l’organisation consiste à augmenter la part de marché grâce à de nouveaux produits.

Comment pouvez-vous soutenir l’objectif d’avoir plus de nouveaux produits ?

• Premièrement, nous souhaitons consacrer plus de temps au développement de nouveaux produits plutôt qu’à la correction des défauts. Il s’agit d’une solution logique et facile à mesurer.
• Deuxièmement, nous souhaitons soutenir une augmentation du volume des transactions, car plus la part de marché est grande, plus il y a d'utilisateurs et, par conséquent, plus de trafic.

Ainsi, les KPI individuels pouvant être exécutés au sein du groupe seront, par exemple, là où proviennent les principaux défauts. Si vous vous concentrez spécifiquement sur cette section, vous pouvez vous assurer qu'il y a beaucoup moins de défauts, puis le temps nécessaire au développement de nouveaux produits et encore une fois à la prise en charge des KPI organisationnels augmentera.

Ainsi, chaque décision, y compris la réécriture du code, doit soutenir les objectifs spécifiques que l'entreprise nous a fixés (croissance organisationnelle, nouvelles fonctionnalités, recrutement).

Au cours de ce processus, une chose intéressante est apparue, qui est devenue une nouveauté non seulement pour les techniciens, mais en général dans l'entreprise : tous les tickets doivent être axés sur au moins un KPI. Autrement dit, si un produit déclare vouloir créer une nouvelle fonctionnalité, la première question doit être posée : « Quel KPI cette fonctionnalité prend-elle en charge ? » Si ce n’est pas le cas, désolé – cela semble être une fonctionnalité inutile.

Jour trente

À la fin du mois, j'ai découvert une autre nuance : personne dans mon équipe Ops n'a jamais vu les contrats que nous concluons avec les clients. Vous pouvez demander pourquoi vous avez besoin de voir les contacts.

• Premièrement, parce que les SLA sont spécifiés dans les contrats.
• Deuxièmement, les SLA sont tous différents. Chaque client venait avec ses propres exigences et le service commercial signait sans regarder.

Une autre nuance intéressante est que le contrat avec l'un des plus gros clients stipule que toutes les versions logicielles prises en charge par la plateforme doivent être n-1, c'est-à-dire non pas la dernière version, mais l'avant-dernière.

Il est clair à quel point nous étions loin du n-1 si la plateforme était basée sur ColdFusion et SQL Server 2008, qui n'était plus du tout supporté en juillet.

Jour quarante-cinq

Vers le milieu du deuxième mois, j'ai eu suffisamment de temps pour m'asseoir et faire Plus-valuecourantcartographie complètement pour l'ensemble du processus. Ce sont les étapes nécessaires qui doivent être suivies, depuis la création d'un produit jusqu'à sa livraison au consommateur, et elles doivent être décrites de manière aussi détaillée que possible.

Vous divisez le processus en petits morceaux et voyez ce qui prend trop de temps, ce qui peut être optimisé, amélioré, etc. Par exemple, combien de temps faut-il pour qu'une demande de produit passe par le toilettage, quand atteint-elle un ticket qu'un développeur peut prendre, le contrôle qualité, etc. Vous examinez donc chaque étape en détail et réfléchissez à ce qui peut être optimisé.

Lorsque j’ai fait cela, deux choses ont attiré mon attention :

• pourcentage élevé de tickets renvoyés par le contrôle qualité aux développeurs ;
• les examens des demandes de tirage ont pris trop de temps.

Le problème était que ces conclusions étaient du type : Cela semble prendre beaucoup de temps, mais nous ne savons pas combien de temps.

"On ne peut pas améliorer ce qu'on ne peut pas mesurer."

Comment justifier la gravité du problème ? Est-ce que cela fait perdre des jours ou des heures ?

Pour mesurer cela, nous avons ajouté quelques étapes au processus Jira : « prêt pour le développement » et « prêt pour le contrôle qualité » pour mesurer combien de temps chaque ticket attend et combien de fois il revient à une certaine étape.

Nous avons également ajouté « en révision » pour savoir combien de billets sont en moyenne à réviser, et à partir de là, vous pouvez commencer à danser. Nous avions des métriques système, maintenant nous avons ajouté de nouvelles métriques et commencé à mesurer :

• Efficacité des processus : performance et planifié/livré.
• Qualité du processus : nombre de défauts, défauts de QA.

Cela aide vraiment à comprendre ce qui va bien et ce qui ne va pas.

Jour cinquantième

Bien sûr, tout cela est bon et intéressant, mais vers la fin du deuxième mois, il s'est produit quelque chose qui, en principe, était prévisible, même si je ne m'attendais pas à une telle ampleur. Les gens ont commencé à partir parce que la direction avait changé. De nouvelles personnes sont arrivées à la direction et ont commencé à tout changer, et les anciennes ont démissionné. Et généralement dans une entreprise qui existe depuis plusieurs années, tout le monde est ami et tout le monde se connaît.

C'était prévu, mais l'ampleur des licenciements était inattendue. Par exemple, en une semaine, deux chefs d’équipe ont présenté simultanément leur démission de leur plein gré. Par conséquent, j'ai dû non seulement oublier d'autres problèmes, mais me concentrer sur créer une équipe. C’est un problème long et difficile à résoudre, mais il fallait le résoudre car je voulais sauver les gens qui restaient (ou la plupart d’entre eux). Il fallait d'une manière ou d'une autre réagir au fait que les gens partaient afin de maintenir le moral de l'équipe.

En théorie, c’est bien : arrive une nouvelle personne qui a carte blanche, qui peut évaluer les compétences de l’équipe et remplacer le personnel. En fait, vous ne pouvez pas simplement recruter de nouvelles personnes pour de nombreuses raisons. L'équilibre est toujours nécessaire.

• Vieux et nouveau. Nous devons garder les personnes âgées qui peuvent changer et soutenir la mission. Mais en même temps, il faut apporter du sang neuf, nous en reparlerons un peu plus tard.
• Expérience. J'ai beaucoup discuté avec de bons juniors qui étaient impatients et voulaient travailler avec nous. Mais je ne pouvais pas les embaucher car il n’y avait pas assez de seniors pour soutenir les juniors et leur servir de mentors. Il fallait d'abord recruter les meilleurs et ensuite seulement les jeunes.
• Carotte et bâton.

Je n'ai pas de bonne réponse à la question de savoir quel est le bon équilibre, comment le maintenir, combien de personnes garder et jusqu'où pousser. Il s'agit d'un processus purement individuel.

Jour cinquante et un

J'ai commencé à regarder de près l'équipe pour comprendre qui j'avais, et encore une fois je me suis souvenu :

« La plupart des problèmes sont des problèmes de personnes. »

J'ai découvert que l'équipe en tant que telle - à la fois Dev et Ops - a trois gros problèmes :

• Satisfaction face à la situation actuelle.
• Manque de responsabilité - parce que personne n'a jamais utilisé les résultats du travail des artistes pour influencer l'entreprise.
• Peur du changement.

Le changement vous fait toujours sortir de votre zone de confort, et plus les gens sont jeunes, plus ils n’aiment pas le changement parce qu’ils ne comprennent pas pourquoi ni comment. La réponse la plus courante que j’ai entendue est : « Nous n’avons jamais fait cela ». De plus, cela atteignait le point de l'absurdité totale : le moindre changement ne pouvait avoir lieu sans que quelqu'un ne s'indigne. Et peu importe à quel point les changements affectaient leur travail, les gens disaient : « Non, pourquoi ? Cela ne marchera pas. »

Mais on ne peut pas s'améliorer sans rien changer.

J'ai eu une conversation absolument absurde avec un employé, je lui ai fait part de mes idées d'optimisation, à quoi il m'a répondu :
- Oh, tu n'as pas vu ce qu'on avait l'année dernière !
- Alors quoi?
"Maintenant, c'est bien mieux qu'avant."
- Alors, ça ne peut pas aller mieux ?
- pourquoi

Bonne question : pourquoi ? C’est comme si tout allait mieux maintenant qu’avant, alors tout va bien. Cela conduit à un manque de responsabilité, ce qui est en principe tout à fait normal. Comme je l'ai dit, le groupe technique était un peu à l'écart. L'entreprise pensait qu'ils devraient exister, mais personne n'a jamais établi de normes. Le support technique n’a jamais vu le SLA, donc c’était tout à fait « acceptable » pour le groupe (et c’est ce qui m’a le plus frappé) :

• 12 secondes de chargement ;
• Temps d'arrêt de 5 à 10 minutes à chaque version ;
• Le dépannage des problèmes critiques prend des jours et des semaines ;
• manque de personnel de garde 24h/7 et XNUMXj/XNUMX / de garde.

Personne n'a jamais essayé de se demander pourquoi ne pas faire mieux, et personne n'a jamais réalisé qu'il n'était pas nécessaire que cela se passe ainsi.

En prime, il y avait un autre problème : manque d'expérience. Les seniors sont partis et les jeunes équipes restantes ont grandi sous le régime précédent et en ont été empoisonnées.

En plus de tout cela, les gens avaient aussi peur d’échouer et de paraître incompétents. Cela s'exprime dans le fait que, premièrement, ils en aucun cas demandé de l'aide. Combien de fois avons-nous parlé en groupe et individuellement, et j’ai dit : « Posez une question si vous ne savez pas comment faire quelque chose ». J'ai confiance en moi et je sais que je peux résoudre n'importe quel problème, mais cela prendra du temps. Par conséquent, si je peux demander à quelqu’un qui sait comment résoudre le problème en 10 minutes, je le demanderai. Moins vous avez d’expérience, plus vous avez peur de poser la question parce que vous pensez que vous serez considéré comme incompétent.

Cette peur de poser des questions se manifeste de manière intéressante. Par exemple, vous demandez : « Comment allez-vous avec cette tâche ? » - "Il reste quelques heures, je termine déjà." Le lendemain, vous redemandez, vous obtenez la réponse que tout va bien, mais il y a eu un problème, ce sera certainement prêt d'ici la fin de la journée. Un autre jour passe, et jusqu'à ce que vous soyez cloué au mur et obligé de parler à quelqu'un, cela continue. Une personne veut résoudre un problème elle-même ; elle croit que si elle ne le résout pas elle-même, ce sera un grand échec.

C'est pourquoi les développeurs ont gonflé les estimations. C'était cette même anecdote, alors qu'ils discutaient d'une certaine tâche, ils m'ont donné un tel chiffre que j'ai été très surpris. Ce à quoi on m'a dit que dans les estimations du développeur, le développeur inclut le temps pendant lequel le ticket sera renvoyé par le contrôle qualité, car il y trouvera des erreurs, et le temps que prendra le PR, et le temps que les personnes qui devraient examiner ce sera occupé - c'est-à-dire tout, tout ce qui est possible.

Deuxièmement, les gens qui ont peur de paraître incompétents suranalyser. Quand vous dites ce qui doit être fait exactement, cela commence : « Non, et si on y réfléchissait ici ? En ce sens, notre entreprise n’est pas unique : c’est un problème courant pour les jeunes.

En réponse, j'ai introduit les pratiques suivantes :

• Règle 30 minutes. Si vous ne parvenez pas à résoudre le problème en une demi-heure, demandez de l’aide à quelqu’un. Cela fonctionne avec plus ou moins de succès, car les gens ne le demandent toujours pas, mais au moins le processus a commencé.
• Éliminez tout sauf l'essence, pour estimer le délai d'exécution d'une tâche, c'est-à-dire considérer uniquement le temps qu'il faudra pour écrire le code.
• Apprentissage tout au long de la vie pour ceux qui suranalysent. C'est juste un travail constant avec les gens.

Jour soixantième

Pendant que je faisais tout cela, il était temps de déterminer le budget. Bien sûr, j’ai trouvé beaucoup de choses intéressantes sur la façon dont nous dépensions notre argent. Par exemple, nous avions un rack entier dans un centre de données séparé avec un serveur FTP, utilisé par un client. Il s'est avéré que "... nous avons déménagé, mais il est resté comme ça, nous ne l'avons pas changé". C'était il y a 2 ans.

La facture des services cloud était particulièrement intéressante. Je pense que la principale raison de la facture élevée du cloud réside dans le fait que les développeurs ont un accès illimité aux serveurs pour la première fois de leur vie. Ils n’ont pas besoin de demander : « S’il vous plaît, donnez-moi un serveur de test », ils peuvent le faire eux-mêmes. De plus, les développeurs veulent toujours créer un système tellement cool que Facebook et Netflix en seront jaloux.

Mais les développeurs n'ont pas d'expérience dans l'achat de serveurs ni la capacité de déterminer la taille requise des serveurs, car ils n'en avaient pas besoin auparavant. Et ils ne comprennent généralement pas bien la différence entre évolutivité et performances.

Résultats de l'inventaire :

• Nous avons quitté le même centre de données.
• Nous avons résilié le contrat avec 3 services de journalisation. Parce que nous en avions 5 - chaque développeur qui commençait à jouer avec quelque chose en prenait un nouveau.
• 7 systèmes AWS ont été arrêtés. Encore une fois, personne n'a arrêté les projets morts, ils ont tous continué à travailler.
• Coûts logiciels réduits de 6 fois.

Jour soixante-quinze

Le temps a passé et au bout de deux mois et demi, j'ai dû rencontrer le conseil d'administration. Notre conseil d’administration n’est ni meilleur ni pire que les autres ; comme tous les conseils d’administration, il veut tout savoir. Les gens investissent de l’argent et veulent comprendre dans quelle mesure ce que nous faisons correspond aux KPI définis.

Le conseil d'administration reçoit chaque mois de nombreuses informations : le nombre d'utilisateurs, leur croissance, quels services ils utilisent et comment, les performances et la productivité, et enfin, la vitesse moyenne de chargement des pages.

Le seul problème est que je crois que la moyenne est un pur mal. Mais il est très difficile d'expliquer cela au conseil d'administration. Ils sont habitués à fonctionner avec des chiffres agrégés, et non, par exemple, avec l'étalement des temps de chargement par seconde.

Il y avait quelques points intéressants à cet égard. Par exemple, j'ai dit que nous devions répartir le trafic entre des serveurs Web distincts en fonction du type de contenu.

Autrement dit, ColdFusion passe par Jetty et nginx et lance les pages. Et les images, JS et CSS passent par un nginx distinct avec leurs propres configurations. C'est une pratique assez courante dont je parle écrit Il y a quelques années. En conséquence, les images se chargent beaucoup plus rapidement et... la vitesse de chargement moyenne a augmenté de 200 ms.

Cela est dû au fait que le graphique est construit sur la base des données fournies avec Jetty. Autrement dit, le contenu rapide n'est pas inclus dans le calcul - la valeur moyenne a bondi. C'était clair pour nous, nous avons ri, mais comment expliquer au conseil d'administration pourquoi nous avons fait quelque chose et que les choses ont empiré de 12 % ?

Jour quatre vingt cinq

À la fin du troisième mois, j’ai réalisé qu’il y avait une chose sur laquelle je n’avais pas du tout compté : le temps. Tout ce dont j'ai parlé prend du temps.

C'est mon vrai calendrier hebdomadaire – juste une semaine de travail, pas très chargée. Il n'y a pas assez de temps pour tout. Par conséquent, encore une fois, vous devez recruter des personnes qui vous aideront à faire face aux problèmes.

Conclusion

Ce n'est pas tout. Dans cette histoire, je n’ai même pas expliqué comment nous avons travaillé avec le produit et essayé de nous adapter à la vague générale, ni comment nous avons intégré le support technique, ni comment nous avons résolu d’autres problèmes techniques. Par exemple, j'ai appris tout à fait par hasard que sur les plus grandes tables de la base de données, nous n'utilisons pas SEQUENCE. Nous avons une fonction auto-écrite nextID, et il n'est pas utilisé dans une transaction.

Il y avait un million d’autres choses similaires dont nous pourrions parler pendant longtemps. Mais ce qu’il y a de plus important à dire, c’est la culture.

C'est la culture, ou son absence, qui conduit à tous les autres problèmes. Nous essayons de construire une culture où les gens :

• n'ont pas peur des échecs ;
• apprendre de ses erreurs;
• collaborer avec d'autres équipes;
• prendre l'initiative;
• prendre la responsabilité;
• accueillir le résultat comme un objectif ;
• célébrer le succès.

Avec cela, tout le reste viendra.

Léon Feu sur twitter, sur Facebook et moyenne.

Il existe deux stratégies concernant l’héritage : éviter à tout prix de travailler avec lui ou surmonter courageusement les difficultés qui y sont associées. Nous c Conférence DevOps Nous empruntons la deuxième voie, en modifiant les processus et les approches. Rejoignez-nous sur Youtube, liste de diffusion и télégramme, et ensemble nous mettrons en œuvre une culture DevOps.

Source: habr.com