Ce que nous faisons
Réparation matérielle Maintenance de serveurs Récupération de données Optimisation & upgradePar constructeur
Dell PowerEdge HPE ProLiant Lenovo ThinkSystem Fujitsu Primergy Supermicro IBM System x / Power Acer AltosIntervention & différenciateurs
Datacenter Lombardia Aruba Ponte San Pietro Au-delà du support constructeurStabilité OS : aligner pilotes, kernel et firmware sur un seul axe.
Plantages en apparence aléatoires, kernel panic intermittents, hyperviseurs qui tuent des VM sans cause apparente : le symptôme est souvent lié au matériel, mais la cause racine réside dans le décalage entre firmware constructeur, pilotes du système d'exploitation, configuration du power management et charge de travail réelle. Le diagnostic systémique est notre métier, avant tout remplacement de matériel.
Schémas d'instabilité récurrents.
- BSOD Windows récurrents avec un stop code stable (ex.
DPC_WATCHDOG_VIOLATION,SYSTEM_THREAD_EXCEPTION_NOT_HANDLED) — souvent un pilote réseau ou stockage non aligné avec le firmware. - Kernel panic Linux avec une stack trace qui pointe toujours vers le même pilote — nécessité de mettre à jour le pilote in-tree ou de passer au pilote constructeur.
- PSOD ESXi (Purple Screen of Death) faisant référence à un pilote réseau, stockage ou RAID — vérification de la matrice de compatibilité VMware-constructeur.
- VM killed by hypervisor sans défaillance du nœud : souvent un power management agressif qui place CPU/cache en deep sleep pendant la latence I/O.
Diagnostiquer avant de toucher au matériel.
- Alignement firmware ↔ pilotes : matrice de compatibilité du constructeur, contrôleur RAID, NIC, HBA, BMC.
- Configuration du power management : dans le BIOS (C-states, P-states, Turbo) et dans le système d'exploitation. Sur les serveurs transactionnels, une power policy « performance » s'impose ; sur les serveurs peu sollicités, l'inverse peut être préférable.
- Vérification des certifications : VMware HCL, Microsoft WHQL, Red Hat HCL pour les combinaisons effectivement utilisées par le client.
- Analyse des crash dumps (Windows) ou des kernel logs (Linux) pour identifier le composant exact qui défaille.
Les questions qu'on nous pose le plus souvent.
Sur un serveur avec des problèmes logiciels, intervenez-vous ou faut-il passer par AssistenzaServer.eu ?
Cela dépend de la cause racine. Si le diagnostic indique que le symptôme est lié au matériel (pilote constructeur non aligné, firmware à mettre à jour, power management BIOS), nous intervenons : c'est la zone frontière matériel/logiciel qui relève naturellement de notre compétence. Si la cause est purement système (configuration applicative, patchs OS, networking logiciel, sécurité), la référence est le site jumeau AssistenzaServer.eu.
Mettre à jour les pilotes résout-il toujours le problème ?
Non, dans certains cas les pilotes les plus récents comportent des bugs — surtout sur du matériel EOL, où la matrice constructeur cesse de tester les combinaisons les plus anciennes. Sur ces systèmes, la version stable certifiée est souvent une version N-1 ou N-2 par rapport à la dernière. Nous vérifions la matrice du constructeur au cas par cas.
Crash dump Windows ou kernel log Linux : les demandez-vous systématiquement ?
Oui, c'est le document le plus important pour le diagnostic. Sous Windows : minidump dans C:\Windows\Minidump (configuré par défaut). Sous Linux : /var/log/kern.log, journalctl -k, et les éventuels crash kdump dans /var/crash. Sous ESXi : vmkernel.log, bundle vm-support. Sans ces documents, le diagnostic est plus lent et moins précis.