Nous aimons tous parler de nos succès et n'aimons pas vraiment parler d'échecs. Mais l'expérience des erreurs a souvent plus de valeur que le profit d'une entreprise réussie. Par conséquent, je voudrais simplement parler de tels cas aujourd'hui. Alors allons-y ...
Pot, ne cuisine pas!
Cette histoire s'est produite il y a quelques années, au tout début de ma carrière de développeur 1C.
Un projet est apparu dans notre entreprise pour optimiser le fonctionnement d'une base très chargée d'un client très important et respecté. Le client était avec un tel service de sécurité paranoïaque qu'il n'y avait pas et ne pouvait pas y avoir d'accès à distance aux serveurs de l'extérieur. Pour se connecter aux bases directement à notre bureau, un réseau local séparé avec VPN matériel a été installé et des postes de travail avec un logiciel strictement négocié ont été installés. Bien sûr, sans les droits d'un administrateur local.
Comme tout autre projet de ce type, il a commencé par la collecte de données. On a supposé que nous collecterions d'abord divers indicateurs dans un délai d'un mois, puis nous nous efforcerions d'optimiser la base d'informations elle-même. Combien et combien de temps dans cet environnement bureaucratique a pris pour mettre en place le MCC, c'est un sujet pour une histoire distincte. Mais maintenant, à un moment donné, c'est arrivé, le MCC a été configuré et démarré. Après cela, l'expert qui a mené ce projet (Dima, salut!), Est monté dans sa voiture de luxe et est allé voyager dans notre vaste pays, puis plus dans les pays voisins. Mais en fait, je savais encore peu et savais comment, mais j'étais déjà considéré comme un développeur assez responsable. Par conséquent, avant de partir, Dmitry m'a confié une tâche très importante et sérieuse: 2 fois par jour, au moment de la pointe de charge, je devais me rendre sur cet ordinateur très secret et commencer les mesures dans le MCC, puis les éteindre après une heure. Les instructions étaient extrêmement simples et claires:
- Regardez, vous appuyez sur ce petit bouton vert "play", différentes cartes fonctionnent, attendez une heure, puis vous appuyez sur ce bouton - "stop". C’est tout.
Quoi de plus simple, non? En vain ai-je étudié pendant 5 ans à la faculté de mathématiques?
Toute la semaine, j'ai strictement observé ce rituel le matin et le soir. Et tout allait bien jusqu'au dernier jour. Après le déjeuner, vendredi, comme d'habitude, j'ai commencé à collecter des données, puis ... Eh bien, vous savez comment cela se passe ... Vendredi soir, nous devons terminer certaines choses urgentes, terminer certaines tâches, après le travail, emmener ma femme chez ma belle-mère, en cours de route passer dans un magasin, un deuxième, etc. En général, j'ai quitté le travail, oubliant complètement ce malheureux MCC.
Le samedi matin a commencé par un appel. Nous avons obtenu TOUS les 1C-ème base chez le client. Achtung et catastrophe! Notre expert se situe quelque part entre Dzheyrakh et Pasanauri, en dehors de la zone d'accès au réseau. L'administrateur principal du client est également dans une maison de campagne et inaccessible. En essayant de savoir par téléphone, quelle est la raison? D'une manière ou d'une autre, il s'avère que l'espace disque est épuisé, donc le service d'agent 1C s'est levé. Ici, j'ai déjà commencé à soupçonner quelque chose ...
Comme vous vous en souvenez, il n'y a pas d'uddalenka. L'ordinateur n'est pas seulement isolé d'Internet, mais également en dehors de notre réseau local. Rien à faire - aller travailler. Lors de la préparation et de la conduite, les administrateurs se sont rendu compte que la place entière était prise par les journaux du MCC et ont fait ce qu'ils pensaient être le plus raisonnable - ils l'ont coupé via le gestionnaire de tâches. Allez-y. Vous ne pouvez pas simplement supprimer les journaux du disque - nous perdrons les données de mesure. D'une manière ou d'une autre, ils ont trouvé suffisamment d'espace sur le partage réseau et y ont copié les fichiers. Le travail semble avoir repris.
Le dimanche matin a commencé par un appel. Nous avons obtenu TOUS les 1C-ème base chez le client. Achtung et la catastrophe en prennent deux! Toute la panique est terminée - l'endroit est fini. Mais comment ça? MCC désactivé? En toute hâte, je vais retravailler, jeter les bûches pour libérer de l'espace. Et ils grandissent tous et grandissent, bon sang! Sous la crainte des exécutions les plus perverses, les administrateurs m'ont interdit de démarrer quoi que ce soit ou de configurer quoi que ce soit. Pour le reste du dimanche, j'étais assis devant l'ordinateur et je copiais les journaux sur le ballon pour que les bases ne se relèvent plus.
Ce n'est que tard dans la nuit que Dima est entré en contact et a déclaré qu'il vous suffit de supprimer un petit fichier sur le serveur 1C. Plus tard, quelques semaines plus tard, j'ai lu à son sujet dans un livre de "bureau" bien connu, mais ce jour-là , épuisé, le torturé est rentré chez lui pour dormir.
Lundi matin, notre compte a été bloqué jusqu'à ce que Dmitry revienne de vacances, et il a été dit très clairement sur mon compte: "Pour que nous ne le revoyions pas!"
C'est ainsi que mon premier projet d'optimisation s'est terminé pour moi.
Deux fois dans un entonnoir
Grande tenue. 18 bases d'informations de configuration identique, réparties dans tout le pays. La mise à jour a lieu une fois par semaine et est le même rituel: le fichier de livraison doit être préparé à l'avance, téléchargé sur le cloud, assurez-vous qu'il a été téléchargé dans toutes les succursales (même en 2018, dans certaines régions, Internet est plus lent que le 1C: ERP typique), vérifiez que les sauvegardes ont été créées partout (nous ne semblons pas être responsables de cela, mais l'expérience amère nous a appris à être sûr), puis à chaque branche exécutez le script de mise à jour manuellement et assurez-vous qu'il fonctionne sans erreur. Souvent, au dernier moment, on découvre qu'une tâche supplémentaire doit être incluse dans la livraison et il s'agit d'une correction mineure, car la prochaine mise à jour n'est que dans une semaine.
C'était donc cette fois. Un développeur expérimenté avec de nombreuses années d'expérience pressé a fait une erreur sur une ligne lors du transfert d'une tâche vers un circuit de combat. L'erreur s'est avérée critique, elle a été découverte après la mise à jour de toutes les bases de données.
Que faire? Le développeur corrige rapidement le code. Ne laisse personne tester:
- Oui, il y a des ordures ... Je ne peux pas me tromper deux fois sur une mĂŞme ligne?
Une heure plus tard, 18 succursales ont été mises à jour pour la troisième fois.
DĂ©veloppeur qui pourrait
L'histoire racontée par un collègue sur Skype.
[Collègue]: Il était une fois un «développeur qui pouvait!» Il avait une tenue de développement. Il voulait ouvrir un test, mais a raté, et a ouvert une productive ...
[Collègue]: Mais cela pourrait-il arrêter le «développeur qui pourrait»? Non!
[I]: Et lors de la mise Ă jour, il n'a pas compris qu'il y avait des gens assis lĂ , pour ainsi dire? )))
[Collègue]: De plus, il voit que le konf est sur support ... Mais pensez-vous que cela pourrait arrêter le "Développeur qui pourrait"? Non!
[Collègue]: Il supprime la configuration du support (!) Et voit son mod contourner tous les référentiels ...
[I]: Ce n'est pas ça! Terminer l'histoire, mise à jour dynamique)))
[Collègue]: Mises à jour ... Le système dit: "Il y a 18 sessions actives dans la base de données!". Mais comment cela pourrait-il arrêter le «développeur qui pourrait»? Non et non encore!
[Collègue]: Il met à jour la base de données et passe la tâche au test ...
[Collègue]: Le consultant ne trouve pas la tenue ... et alors seulement, après un long moment, il se rend compte qu'il a raté.
[Collègue]: J'ai dû le réprimander ...
[Collègue]: Je l'appelle ... et je ris au téléphone ...
[Collègue]: Je ne comprends tout simplement pas ... COMMENT ???
Effondrement des transports
L'histoire racontée par un collègue et enregistrée à partir de ses paroles.
C'est arrivé dans une grande entreprise de logistique. La plupart des processus métier sont concentrés dans une seule base d'informations. Utilisateurs compétitifs pour 2012 - environ 3 000 personnes de toutes les régions du pays.
Définissez une tâche simple. Selon lui, il a créé son propre registre d'informations, dans lequel des données sont écrites lorsque certains documents sont publiés. Bien qu'il n'y ait pas beaucoup de types de documents, le nombre de ces documents par jour est énorme. En théorie, l'opération d'écriture que j'ai ajoutée au registre ne devrait pas charger lourdement le système. Mais il y avait une nuance dans l'implémentation de la tâche - lors de l'enregistrement d'un ensemble, la propriété Overwrite était définie sur False. Autrement dit, chaque document contenant des entrées ajoutées au registre. Cela était nécessaire selon les conditions du problème, mais n'a pratiquement pas affecté les performances, car selon les conditions de sélection, il y avait toujours 1 à 10 entrées.
Les tests fonctionnels ont réussi. Nous avons effectué plusieurs dizaines de documents, vérifié que les entrées dans le registre étaient correctes, n'avons rien remarqué de suspect et les avons envoyés au producteur.
En ce malheureux vendredi matin, nous avons mis à jour la base de combat et les utilisateurs ont commencé à travailler. 3000 personnes ont rempli joyeusement des documents et le registre a commencé à être rempli de données. Après avoir vérifié que tout se passait bien, quelques heures plus tard nous sommes rentrés à la maison avec une âme calme (nous travaillons dans différents fuseaux horaires avec les principaux utilisateurs de la base d'informations).
Il convient de noter que les serveurs sur lesquels le SI fonctionnait sont presque l'un des plus puissants de Russie utilisés sous 1C. Mais après quelques heures, «quelque chose s'est mal passé» (c).
Les utilisateurs ont commencé à remarquer une baisse des performances du système. Toutes les opérations ont commencé à ralentir. Les réponses à toute action se sont allongées. La charge sur le matériel a régulièrement augmenté. Pendant que le service informatique comprenait ce qui se passait, le travail dans le système a presque cessé. L'équipement ne pouvait pas faire face, les files d'attente sur les disques étaient plus longues que dans les bureaux de poste de la Russie. Si l'équipement était plus faible, le problème serait détecté presque immédiatement. Mais les serveurs les plus puissants ont résisté héroïquement à mes mains tordues pendant une demi-journée.
«D'après les mots» de MSSQL, la demande la plus sévère est soudainement devenue une demande de lecture dans mon registre. Bien que je n'aie fait aucune lecture. Un problème a été rapidement découvert dans le code 1C. J'ai oublié de définir des sélections sur un ensemble d'enregistrements. Si la propriété "Overwrite" était définie sur "True", je trouverais immédiatement une erreur, car chaque entrée effacerait tout le registre. Mais dans notre cas, cela ne s'est pas produit. Sur l'exemple d'une dizaine de documents, bien entendu, nous n'avons constaté aucune perte de performance. Mais lorsque le registre a commencé à se remplir de dizaines et de centaines de milliers de lignes - le système a dû à chaque fois vérifier l'intégralité du registre pour rechercher les enregistrements correspondants.
À ce moment-là , selon certains utilisateurs, un effondrement du transport s'était déjà produit, car les voitures n'ont pas reçu de documents de 1C et n'ont pas pu quitter les points de déchargement.
Donc, oubliant «juste» de mettre une sélection dans le jeu d'enregistrements, j'ai mis l'une des plus grandes bases de données 1C en Russie.
PS Voir aussi: