Tous les développeurs 1C interagissent d'une manière ou d'une autre étroitement avec les services informatiques et directement avec les administrateurs système. Mais cette interaction ne se déroule pas toujours sans heurts. J'aimerais vous raconter quelques histoires amusantes à ce sujet.
Canal de communication à haut débit
La plupart de nos clients sont de grandes sociétés possédant leurs propres services informatiques. Et les spécialistes clients sont généralement responsables des copies de sauvegarde des bases de données d'informations. Mais il existe aussi des organisations relativement petites. Surtout pour eux, nous avons un service selon lequel nous prenons en charge toutes les questions liées à la sauvegarde de tout 1C. C'est de cette entreprise dont nous parlerons dans cette histoire.
Un nouveau client est venu prendre en charge 1C et, entre autres choses, le contrat comprenait une clause selon laquelle nous étions responsables des sauvegardes, bien qu'ils aient leur propre administrateur système parmi leur personnel. Base de données client-serveur, MS SQL comme SGBD. Une situation assez classique, mais il y avait quand même une nuance : la base principale était assez importante, mais l'augmentation mensuelle était très faible. Autrement dit, la base de données contenait de nombreuses données historiques. Compte tenu de cette fonctionnalité, j'ai mis en place des plans de maintenance des sauvegardes comme suit : le premier samedi de chaque mois une sauvegarde complète était faite, elle était assez lourde, puis une copie différentielle était faite chaque nuit - un volume relativement faible, et une copie du journal des transactions toutes les heures. De plus, les copies complètes et différentielles étaient non seulement copiées sur une ressource réseau, mais également téléchargées sur notre serveur FTP. Il s'agit d'une exigence obligatoire lors de la fourniture de ce service.
Tout cela a été configuré avec succès, mis en service et a généralement fonctionné sans échec.
Mais quelques mois plus tard, l'administrateur système de cette organisation a changé. 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 de disques, l'accès a été bloqué partout et tout, etc., ce qui dans le cas général, bien sûr, ne peut que se réjouir. Mais les choses ne se sont pas toujours bien déroulées pour lui : il y avait souvent des problèmes avec les performances de 1C, ce qui a provoqué des désaccords et des malentendus avec notre support. Il convient également de noter que nos relations avec lui étaient généralement assez froides et quelque peu tendues, ce qui ne faisait 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'était passé et j'ai reçu comme réponse quelque chose comme "Notre serveur est tombé en panne, nous y travaillons, ce n'est pas à vous de décider." Eh bien, c'est bien qu'ils fonctionnent. Cela signifie que la situation est sous contrôle. Après le déjeuner, je rappelle et au lieu d'irritation, je sens déjà de la fatigue et de l'apathie dans la voix de l'administrateur. J'essaie de comprendre ce qui s'est passé et pouvons-nous faire quelque chose pour vous aider ? À la suite de la conversation, les éléments suivants sont ressortis :
Il a déplacé le serveur vers un nouveau système de stockage avec un raid nouvellement assemblé. Mais quelque chose s’est mal passé et quelques jours plus tard, ce raid s’est effondré en toute sécurité. Que le contrôleur soit grillé ou que quelque chose soit arrivé 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 les sauvegardes se retrouvait également sur la même baie de disques lors de diverses migrations. Autrement dit, la base de données productive elle-même et toutes ses copies de sauvegarde ont été perdues. Et on ne sait pas quoi faire maintenant.
Calme-toi, dis-je. Nous avons votre sauvegarde nocturne. En réponse, il y a eu un silence, par lequel j'ai réalisé que je venais de sauver la vie d'un homme. Nous commençons par discuter de la manière de transférer cette copie vers un nouveau serveur nouvellement déployé. Mais là aussi, un problème s'est posé.
Vous vous souvenez quand j'ai dit que la sauvegarde complète était assez volumineuse ? Ce n'est pas pour rien que je le faisais une fois par mois le samedi. Le fait est que l’entreprise était une petite usine située loin de la ville et que leur Internet était très médiocre. Lundi matin, c'est-à-dire pendant le week-end, cette copie parvenait à peine à être téléchargée sur notre serveur FTP. Mais il n’était pas possible d’attendre un jour ou deux pour qu’il se charge dans la direction opposée. Après plusieurs tentatives infructueuses de transfert du fichier, l'administrateur a sorti le disque dur directement du nouveau serveur, a trouvé une voiture avec chauffeur quelque part et s'est rapidement précipité vers notre bureau, heureusement nous sommes toujours dans la même ville.
Alors qu'ils se trouvaient dans notre salle de serveurs et attendaient que les fichiers soient copiés, nous nous sommes rencontrés pour la première fois, pour ainsi dire, « en personne », avons bu une tasse de café et avons discuté dans un cadre informel. J'ai sympathisé avec son chagrin et je l'ai renvoyé avec un tas de sauvegardes, rétablissant à la hâte le travail arrêté de l'entreprise.
Par la suite, toutes nos demandes auprès du service informatique ont été résolues très rapidement et aucun désaccord n'est survenu.
Contactez votre administrateur système
Une fois, pendant très longtemps, je ne pouvais pas publier 1C pour un accès Web via IIS pour un client. Cela semblait être une tâche ordinaire, mais il n’y avait aucun moyen de tout faire fonctionner. Les administrateurs système locaux se sont impliqués et ont essayé différents paramètres et fichiers de configuration. 1C sur le Web ne voulait normalement en aucun cas fonctionner. Quelque chose n'allait pas, soit avec les politiques de sécurité du domaine, soit avec le pare-feu local sophistiqué, ou Dieu sait quoi d'autre. À la Nième itération, l'administrateur m'envoie un lien avec les mots :
- Réessayez en suivant ces instructions. Tout y est décrit de manière assez détaillée. Si cela ne fonctionne pas, écrivez à l'auteur de ce site, il pourra peut-être vous aider.
"Non," dis-je, "ça n'aidera pas."
- Pourquoi pas?
— Je suis l'auteur de ce site... (
Du coup, nous l'avons lancé sur Apache sans aucun problème. IIS n’a jamais été vaincu.
Un niveau plus profond
Nous avions un client – une petite entreprise manufacturière. Ils disposaient d'un serveur, une sorte de 3 en 1 « classique » : serveur de terminaux + serveur d'applications + serveur de base de données. Ils travaillaient dans une configuration spécifique à l'industrie basée sur UPP, il y avait environ 15 à 20 utilisateurs et les performances du système convenaient en principe à tout le monde.
Au fil du temps, tout fonctionnait de manière plus ou moins stable. Mais ensuite, l'Europe a imposé des sanctions à la Russie, à la suite desquelles les Russes ont commencé à acheter principalement des produits fabriqués dans le pays, et les affaires de cette entreprise ont fortement augmenté. Le nombre d'utilisateurs est passé à 50-60 personnes, une nouvelle succursale a été ouverte et le flux de documents a augmenté en conséquence. Et maintenant, le serveur actuel ne pouvait plus faire face à une charge fortement accrue, et 1C a commencé, comme on dit, à « ralentir ». Aux heures de pointe, les documents étaient traités pendant plusieurs minutes, des erreurs de blocage se produisaient, les formulaires mettaient beaucoup de temps à s'ouvrir, et tout le reste des services associés. L'administrateur système local a écarté tous les problèmes en disant : "C'est votre 1C, vous allez le découvrir." Nous avons proposé à plusieurs reprises de réaliser un audit de performance du système, mais nous n’avons jamais abordé l’audit lui-même. Le client a simplement demandé des recommandations sur la manière de résoudre les problèmes.
Eh bien, je me suis assis et j'ai écrit une lettre assez longue sur la nécessité de séparer les rôles du serveur de terminaux et du serveur d'applications avec le 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, fourni des liens vers des sources faisant autorité et même suggéré certaines options d'équipement. Cette lettre est parvenue aux dirigeants de l'entreprise, est revenue au service informatique avec les résolutions « Mettre en œuvre » et la glace a été généralement brisée.
Après un certain temps, l'administrateur m'envoie l'adresse IP du nouveau serveur et les informations de connexion. Il dit que les composants du serveur MS SQL et 1C y sont déployés et que les bases de données doivent être transférées, mais pour l'instant uniquement vers le serveur SGBD, car certains problèmes sont survenus avec les clés 1C.
Je suis arrivé, effectivement, tous les services fonctionnaient, le serveur n'était pas très puissant, mais bon, je pense que c'est mieux que rien. Je vais transférer les bases de données pour l'instant afin de soulager d'une manière ou d'une autre le serveur actuel. J'ai effectué tous les transferts à l'heure convenue, mais la situation n'a pas changé - toujours les mêmes problèmes de performances. C'est étrange, bien sûr, eh bien, enregistrons les bases de données dans le cluster 1C et nous verrons.
Plusieurs jours passent, les clés n'ont pas été transférées. Je me demande quel est le problème, tout semble simple : retirez-le d'un serveur, branchez-le sur un autre, installez le pilote et le tour est joué. L'administrateur répond en s'agitant et en disant quelque chose sur la redirection de port, un serveur virtuel, etc.
Hmm... Serveur virtuel ? Il semble qu'il n'y ait jamais eu de virtualisation et qu'il n'y en ait jamais eu... Je me souviens d'un problème assez connu avec l'impossibilité de transmettre une clé de serveur 1C vers une machine virtuelle sur Hyper-V dans Windows Server 2008. Et ici des soupçons commencent à se former en moi...
J'ouvre le gestionnaire de serveur - Rôles - un nouveau rôle est apparu - Hyper-V. Je vais dans le gestionnaire Hyper-V, vois une machine virtuelle, me connecte... Et en effet... Notre nouveau serveur de base de données...
Et alors? Les instructions des autorités et mes recommandations ont été exécutées, les rôles ont été séparés. La tâche peut être fermée.
Après un certain temps, la crise actuelle s'est produite, la nouvelle succursale a dû être fermée, la charge a diminué et les performances du système sont devenues plus ou moins tolérables.
Bien sûr, ils ne pouvaient pas transmettre la clé du serveur à la machine virtuelle. Du coup, tout est resté tel quel : serveur de terminaux + cluster 1C sur une machine physique, serveur de base de données là-bas dans une machine virtuelle.
Et ce serait bien si c'était une sorte de bureau de Sharashkin. Donc non. Une entreprise connue dont vous connaissez probablement les produits et avez vu dans les rayons concernés de tous les Lentas et Auchans.
Calendrier des vacances du disque dur
Une grande société holding avec des projets ambitieux pour conquérir le monde a une fois de plus racheté une petite entreprise dans le but de l'inclure dans sa méga-corporation. Dans toutes les divisions de cette holding, les utilisateurs travaillent dans leurs propres bases de données, mais avec une configuration identique. Nous avons donc lancé 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 données de production et de test. Le développeur a reçu les données de connexion, se connecte au serveur, voit MS SQL installé, le serveur 1C, voit 2 lecteurs logiques : le lecteur « C » d'une capacité de 250 gigaoctets et le lecteur « D » d'une capacité de 1 téraoctet. Eh bien, « C » est le système, « D » est pour les données, le développeur décide et y déploie logiquement toutes les bases de données. J'ai même mis en place des plans de maintenance, y compris des sauvegardes, au cas où (même si nous n'en sommes pas responsables). Certes, des sauvegardes ont été ajoutées ici à « D ». À l'avenir, il était prévu de le reconfigurer vers une ressource réseau distincte.
Le projet a démarré, 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 améliorations mineures ont été apportées et les utilisateurs ont commencé à travailler dans la nouvelle base d'informations.
Tout allait bien jusqu'à ce qu'un lundi matin, on découvre que le disque de la base de données manquait. 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 : ce « serveur » était en réalité l’ordinateur de travail d’un administrateur système local. Certes, il disposait toujours d’un système d’exploitation serveur. La clé USB personnelle de cet administrateur était branchée sur le serveur. L'administrateur est donc parti en vacances, emportant sa vis avec lui, dans le but d'y mettre des films pour le voyage.
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 productive.
Il est à noter que tout le monde était globalement satisfait des performances du système situé sur une clé USB. Personne ne s'est plaint des performances insatisfaisantes de 1C. Ce n'est que plus tard que la holding a lancé un méga-projet visant à transférer toutes les bases de données d'informations vers un seul site centralisé avec des super-serveurs, des systèmes de 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 ...
Source: habr.com