Tous les développeurs 1C, d'une manière ou d'une autre, interagissent étroitement avec les services informatiques et directement avec les administrateurs système. Mais pas toujours, cette interaction se passe bien. Je voudrais vous raconter quelques histoires drôles à ce sujet.
Canal de communication haut débit
La plupart de nos clients sont de grandes exploitations avec leurs grands services informatiques. Et pour les copies de sauvegarde des infobases, en règle générale, les spécialistes du client sont responsables. Mais il existe des organisations relativement petites. Surtout pour eux, nous avons un service selon lequel nous nous occupons de toutes les questions liées à la sauvegarde de tous les 1C. Une telle entreprise sera discutée dans cette histoire.
Un nouveau client est venu soutenir 1C et, entre autres choses, le contrat contenait une clause stipulant que nous étions responsables des sauvegardes, bien qu'ils aient leur propre administrateur système au sein du personnel. La base de données client-serveur, comme le SGBD - MS SQL. Une situation assez standard, mais il y avait encore une mise en garde: la base principale était assez grande, mais en même temps l'augmentation mensuelle était très faible. Autrement dit, la base de données contenait de nombreuses données historiques. Compte tenu de cette particularité, j'ai mis en place des plans de maintenance de sauvegarde comme suit: le premier samedi de chaque mois, une sauvegarde complète a été effectuée, elle était assez lourde, puis une copie différentielle a été effectuée chaque nuit - un volume relativement petit et toutes les heures une copie du journal des transactions. De plus, des copies complètes et différentielles, non seulement qu'elles ont été copiées sur une ressource réseau, ont également été téléchargées sur notre serveur FTP. Il s'agit d'une exigence obligatoire pour la fourniture de ce service.
Tout cela a été configuré avec succès, mis en service et a fonctionné en général sans échec.
Mais quelques mois plus tard, l'administrateur système a changé dans cette organisation. Le nouvel administrateur système a commencé à reconstruire progressivement l'infrastructure informatique de l'entreprise conformément aux tendances modernes. En particulier, la virtualisation est apparue, les étagères à disques, l'accès a été fermé partout et tout, etc., ce qui, dans le cas général, ne peut que se réjouir. Mais cela ne s'est pas toujours bien passé avec lui, souvent il y avait des problèmes avec les performances de 1C, ce qui a provoqué des désaccords et des malentendus avec notre soutien. Il convient également de noter que nos relations avec lui se sont généralement développées assez froides et quelque peu tendues, ce qui n'a fait qu'augmenter le degré de tension en cas de problème.
Mais un matin, il s'est avéré que le serveur de ce client n'était pas disponible. J'ai appelé l'administrateur système pour savoir ce qui s'est passé et j'ai reçu quelque chose comme "Notre serveur est tombé en panne, nous y travaillons, ce n'est pas à vous de décider." Eh bien, ça marche. La situation est donc sous contrôle. Après le déjeuner, je rappelle encore, de la voix de l'administrateur, au lieu d'irritation, je ressens déjà de la fatigue et de l'apathie. Essayer de clarifier ce qui s'est passé, et pouvons-nous en quelque sorte vous aider? La conversation a révélé ce qui suit:
Il a déplacé le serveur vers un nouveau système de stockage avec un raid qui vient d'être assemblé. Mais quelque chose s'est mal passé et après quelques jours, ce raid s'est effondré en toute sécurité. Soit le contrôleur a grillé, soit il est arrivé quelque chose aux disques, je ne me souviens pas exactement, mais toutes les informations ont été irrémédiablement perdues. Et l'essentiel était que la ressource réseau avec des sauvegardes également en cours de migration était sur la même baie de disques. C'est-à-dire que la base productive elle-même et toutes ses sauvegardes ont été perdues. Et que faire maintenant n'est pas clair.
Calmement, dis-je. Nous avons votre sauvegarde de nuit. La réponse est le silence, par lequel je comprends que je viens de sauver la vie d'une personne. Nous commençons à discuter de la façon de transférer cette copie vers un nouveau serveur récemment déployé. Mais ici, un problème s'est posé.
Rappelez-vous, j'ai dit que la sauvegarde complète était assez importante? Je l'ai fait pour une raison une fois par mois le samedi. Le fait est que l'entreprise était une petite usine, située bien au-delà de la ville et qu'Internet était très moyen. Lundi matin, c'est-à-dire au cours du week-end, cette copie avec peine de moitié a eu le temps de la télécharger sur notre serveur FTP. Mais il n'y avait aucun moyen d'attendre un jour ou deux jusqu'à ce qu'il se charge dans la direction opposée. Après plusieurs tentatives infructueuses pour faire glisser le fichier, l'administrateur a retiré le disque dur direct du nouveau serveur, a trouvé une voiture avec chauffeur quelque part et s'est précipité rapidement vers notre bureau, car nous sommes toujours dans la même ville.
Pendant que nous étions debout dans la salle des serveurs et que nous attendions que les fichiers soient copiés, nous nous sommes d'abord rencontrés, pour ainsi dire, «en direct», avons bu une tasse de café, avons parlé dans un cadre informel. J'ai sympathisé avec son chagrin et j'ai renvoyé avec une vis pleine de sauvegardes, pressé de rétablir le travail interrompu de l'entreprise.
Par la suite, toutes nos candidatures au service informatique ont été résolues très rapidement et il n'y a plus de désaccords.
Contactez votre administrateur système
Une fois, avec un seul client, pendant très longtemps, je ne pouvais pas publier 1C pour l'accès Web via IIS. Cela semble être une tâche ordinaire, mais ici, cela n'a pas été dérangé. Les administrateurs système locaux se sont connectés, ont essayé différents paramètres et fichiers de configuration. 1C sur le Web ne voulait normalement pas travailler dans aucun. Quelque chose n'allait pas avec les politiques de sécurité du domaine, ou avec un pare-feu sophistiqué local, ou quoi. À la Nème itération, l'administrateur me dépose un lien avec les mots:
- Réessayez avec cette instruction. Tout y est assez détaillé. Si cela ne fonctionne pas, écrivez à l'auteur de ce site, peut-être qu'il vous aidera.
«Non», dis-je, «cela n'aidera pas.»
- Pourquoi?
- Je suis l'auteur de ce site ... (
En conséquence, ils ont lancé Apache sans aucun problème. IIS n'a pas pu gagner.
Plus profond
Nous avions un client - une petite entreprise manufacturière. Ils avaient un serveur, un "classique" 3 en 1 si particulier: serveur terminal + serveur d'application + serveur de base de données. Ils travaillaient dans une configuration industrielle basée sur des démarreurs progressifs, il y avait environ 15 à 20 utilisateurs dans le système et les performances du système étaient en principe adaptées à tout le monde.
Le temps a passé, tout a fonctionné plus ou moins stable. Mais l'Europe a imposé des sanctions contre la Russie, à la suite de quoi les Russes ont commencé à acheter principalement des produits nationaux, et les choses dans cette entreprise se sont dégradées. Le nombre d'utilisateurs est passé à 50-60 personnes, une nouvelle succursale a ouvert, tout comme le workflow. Et maintenant, le serveur actuel a cessé de faire face à la charge fortement accrue, et 1C a commencé, comme on dit, à "ralentir". Aux heures de pointe, les documents ont été conservés pendant plusieurs minutes, des erreurs de blocage ont plu, des formulaires ouverts depuis longtemps, enfin, et tout le reste des services connexes. L'administrateur du système local a rejeté tous les problèmes en disant: «C'est votre 1C, vous devez le comprendre.» Nous avons suggéré à plusieurs reprises d'effectuer un audit du système pour vérifier les performances, mais cela n'a pas atteint l'audit lui-même. Le client a simplement demandé des recommandations sur le dépannage.
Eh bien, je me suis assis et j'ai écrit une lettre assez volumineuse déclarant qu'il est nécessaire de séparer les rôles du serveur terminal et du serveur d'applications du SGBD (ce que, en principe, nous avons déjà dit à plusieurs reprises auparavant). J'ai écrit sur DFSS sur les serveurs de terminaux, sur la mémoire partagée, jeté des liens vers des sources faisant autorité et même offert des options matérielles. Cette lettre a atteint les pouvoirs en place dans l'entreprise, est retournée au service informatique avec les résolutions «Exécuter», et la glace a généralement éclaté.
Après un certain temps, l'administrateur m'envoie l'adresse IP du nouveau serveur et les informations de connexion. Il dit que MS SQL et les composants du serveur 1C y sont déployés et que vous devez transférer les bases de données, mais jusqu'à présent uniquement vers le serveur SGBD, car il y a eu des problèmes avec les clés 1C.
En effet, tous les services sont entrés, le serveur n'est pas très puissant, d'accord, je pense que c'est mieux que rien. Je vais transférer les bases de données jusqu'à présent pour au moins soulager le serveur actuel. Dans le temps négocié, il a effectué tous les transferts, mais la situation n'a pas changé - tout de même des problèmes de performance. Étrange, bien sûr, eh bien, enregistrons les bases dans le cluster 1C, nous verrons.
Cela prend plusieurs jours, les clés n'ont pas été transférées. Je suis intéressé par le problème, tout semble être simple là-bas - je l'ai supprimé d'un serveur, l'ai collé dans un autre, installé le pilote et c'est prêt. L'administrateur répond, dit quelque chose sur la redirection de port, un serveur virtuel, etc.
Hmm ... un serveur virtuel? Il semble qu'il n'y ait jamais eu de virtualisation et ils ne l'étaient pas ... Je me souviens d'un problème assez connu avec l'incapacité de transmettre la clé du serveur 1C à la machine virtuelle sur Hyper-V dans Windows Server 2008. Et ici, certains soupçons commencent à se développer ...
J'ouvre le gestionnaire de serveur - Rôles - un nouveau rôle est apparu - Hyper-V. Je vais au gestionnaire Hyper-V, je vois une machine virtuelle, je me connecte ... Et vraiment ... Notre nouveau serveur de base de données ...
Eh bien quoi? Les instructions des autorités et mes recommandations sont remplies, les rôles sont séparés. La tâche peut être fermée.
Après un certain temps, la crise s'est produite, la nouvelle succursale a dû être fermée, la charge a diminué, les performances du système sont devenues plus ou moins tolérables.
Bien sûr, ils n'ont pas pu transmettre la clé du serveur à la machine virtuelle. En conséquence, tout était comme il était et est parti: le serveur Terminal Server + 1C cluster sur la machine physique, le serveur de base de données au même endroit dans le virtuel.
Et bien, serait-ce une sorte de bureau Sharashkin. Alors non. Une entreprise bien connue, dont vous connaissez et avez probablement vu les produits dans les départements correspondants de toutes sortes de rubans et Auchanov.
Horaire des vacances sur le disque dur
Une grande société holding avec des plans ambitieux
pour conquérir le monde a de nouveau acheté une petite entreprise dans le but de l'intégrer dans sa mégacorporation. Dans toutes les divisions de cette holding, les utilisateurs travaillent dans leurs bases de données, mais avec une configuration identique. Et donc nous avons commencé un petit projet pour inclure une nouvelle unité dans ce système.
Tout d'abord, il est nécessaire de déployer des bases de combat et de test. Le développeur a reçu les données de la connexion, se connecte au serveur, voit le MS SQL installé, le serveur 1C, voit 2 lecteurs logiques: un lecteur C de 250 gigaoctets et un lecteur D de 1 téraoctet. Eh bien, "C" est un système, "D" pour les données, le développeur décide logiquement et y déploie toutes les bases de données. J'ai même mis en place des plans de maintenance, y compris des sauvegardes, juste au cas où (bien que nous ne soyons pas responsables de cela). De vraies sauvegardes ont pris forme ici sur le "D". À l'avenir, il était prévu de reconfigurer déjà sur une ressource réseau distincte.
Le projet a été lancé, les consultants ont dispensé une formation sur la façon de travailler dans le nouveau système, les restes ont été transférés, quelques petites améliorations ponctuelles ont été apportées et les utilisateurs ont déjà commencé à travailler dans la nouvelle base d'informations.
Tout s'est bien passé jusqu'à ce qu'un lundi matin, on découvre que le lecteur de base de données a disparu. Il n'y a tout simplement pas de «D» sur le serveur et c'est tout.
Une enquête plus approfondie a révélé ceci: en fait, ce «serveur» était l'ordinateur de travail de l'administrateur système local. Certes, le système d'exploitation du serveur était toujours dessus. Un disque USB personnel de cet administrateur a été inséré dans le serveur. Et l'administrateur est parti en vacances en emportant avec lui sa propre vis, dans le but de pomper des films sur la route.
Dieu merci, il n'a pas réussi à supprimer les fichiers de la base de données et a réussi à restaurer la base de données de travail.
Il est à noter que tout le monde, en général, était satisfait des performances du système situé sur la clé USB. Personne ne s'est plaint de travaux insatisfaisants de 1C. C'est déjà plus tard que le mégaprojet a commencé dans l'exploitation pour transférer toutes les bases de données d'informations sur une seule plateforme centralisée avec des super serveurs, un stockage pour plus d'un million de roubles, des hyperviseurs sophistiqués et des freins 1C insupportables dans toutes les branches.
Mais c'est une histoire complètement différente ...
PS Voir aussi: