These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

Général

 
  • Topic is locked indefinitely.
 

Dans les coulisses d'une longue maintenance d'EVE Online

First post
Author
Previous Topic Next Topic
CCP Tara
C C P
C C P Alliance
#1 - 2015-08-07 11:30:25 UTC  |  Edited by: CCP Tara
NB: Ceci est une traduction du blog de dév de CCP Goliath.

Ce blog de dév présente un résumé de ce qu'il s'est passé en coulisses, alors qu'EVE Online vivait l'une de ses plus longues maintenances, le 15 juillet 2015. Nous avons souhaité partager cela avec vous, car nous savons qu'un grand nombre d'entre vous travaillent dans le secteur informatique, et voudraient comprendre en détail ce qui s'est passé. Cela vous permettra ainsi d'avoir une idée de la façon dont fonctionne ce jeu unique. Si cela vous intéresse, continuez à lire ce rapport. Si vous n'avez pas particulièrement envie de connaître les détails de cette maintenance prolongée, nous vous conseillons de vous rendre sur le résumé que nous avons posté peu de temps après l'incident.

Contexte

Pour ceux qui nous suivent depuis longtemps, vous vous souvenez certainement de maintenances prolongées dont la durée se comptait en jours plutôt qu'en heures. Ces dernières années nous avons réussi, en grande partie, à éliminer ces longues périodes de maintenance. Le 15 juillet, EVE Online a été inaccessible aux joueurs pendant 699 minutes, soit légèrement plus longtemps que la maintenance prolongée entre le 2 et le 3 juin 2013, immédiatement après le déploiement d'Odyssey (version qui avait elle-même conduit à une maintenance prolongée qui avait duré environ 342 minutes, à cause de longs scripts de tiericide). Avant cela, Incarna, en 2011, avait provoqué une maintenance de 963 minutes. Il s'agissait du dernier long déploiement à notre rythme précédent (une nouvelle version tous les 6 mois). Actuellement, si nous devons redémarrer simplement et sans déployer quoi que ce soit, nous savons que cela ne prend que 7 minutes. Lors du déploiement d'une nouvelle version, nous pouvons nous attendre à une maintenance d'environ 30 minutes.

Démarrage

Le serveur TQ se compose d'environ 250 nœuds de serveur. Pour démarrer le serveur, tous ces nœuds doivent effectuer une série d'actions coordonnées. Ces actions comprennent l'attribution d'identifiants à chaque nœud, les connexions réseau entre chaque paire de nœuds, l'attribution de systèmes solaires à chacun d'entre eux et le chargement des données nécessaires pour permettre à chaque nœud d'effectuer les tâches qui lui incombent (un nœud peut servir à gérer la région d'un marché, ou un ensemble de corporations/alliances, ou encore l'entraînement d'une compétence pour un ensemble de personnages)

Lors de la séquence de démarrage, le serveur passe par différentes étapes. Il ne progressera à l'étape suivante qu'une fois que tous les nœuds ont rapporté avoir terminé les actions de l'étape actuelle. Cela commence à l'étape -4 et continue jusqu'à l'étape 0. Une fois que tous les nœuds sont à l'étape 0, on considère que le serveur est prêt. Un nœud principal est choisi pour orchestrer cette séquence. Il est surnommé Polaris. Le nœud Polaris est chargé de vérifier les étapes auxquelles se trouvent tous les autres nœuds, et leur donner l'instruction d'avancer à la prochaine étape, lorsque toutes les conditions appropriées sont réunies.

-4 : le nœud a commencé à être exécuté, et nous avons une connexion à la base de données.
-3 : le nœud a ouvert une connexion réseau avec succès une fois tous les deux nœuds.
-2 : l'adresse du cache est préparée. Elle contient une liste de ce que tous les nœuds sont censés faire, et envoie des informations à chaque nœud pour qu'il sache ce que l'autre nœud est en train de faire.
-1 : tous les services de démarrage ont terminé leur initialisation, et le pré-chargement de certaines données a commencé (marché, système solaire, etc.)
0 : le nœud est informé que le serveur est prêt, toutes les données de démarrage sont chargées et les services sont prêts à recevoir des requêtes.

Incident

Lorsque nous avons désactivé le serveur le 15 juillet pour déployer le premier patch après la version Souveraineté d'Aegis, nous ne nous attendions pas à provoquer d'incident - les serveurs de test sur lesquels nous avions appliqué la mise à jour avaient démarré correctement et leur comportement était normal. Nous sommes donc partis du principe qu'il s'agirait d'un déploiement classique qui durerait de 15 à 20 minutes. Notre premier problème a été que notre outil de déploiement prenait très longtemps à déployer le paquet de serveur et commençait à émettre des erreurs, pour redémarrer un peu avant 11.30. Nous avons commencé à prévenir d'un possible ******, mais ne nous attendions à rien d'inhabituel - les outils peuvent parfois rencontrer des problèmes et les temps morts arrivent. Nous avons simplement déployé à nouveau, cette fois avec succès. Le premier redémarrage du serveur fut à 11.42. À 11.46, 12 nœuds (parmi 250) nous rapportaient être bloqués et empêchaient le serveur de redémarrer. Sans nous décourager, nous avons commencé par la base lors de tout problème informatique : tout éteindre, puis rallumer.

[img]http://content.eveonline.com/www/newssystem/media/67449/1/have-you-tried.jpg[/img]

Le redémarrage fut plus rapide, mais 41 nœuds étaient restés coincés à l'étape "-1". Nous avons décidé de mettre en place un accès VIP sur le serveur. Ainsi, seuls les comptes de développeur pouvaient accéder au serveur quand celui-ci était en ligne. Ils pouvaient ainsi recommencer l'ensemble du déploiement à partir de zéro, pour pouvoir exclure les blocages, les conflits ou erreurs humaines qui auraient pu se produire au début. Notre première hypothèse était que l'environnement était la cause du problème. Le code fonctionnait sur notre serveur de test, et aucune des données ne nous indiquaient de problèmes.

Malheureusement, après deux redémarrages, notre serveur était bien loin d'être en ligne. C'est là que notre croisade a commencé. Les programmeurs d'EVE ont rejoint le service Ops, qui s'occupe de l'exécution de serveur, afin d'enquêter plus en profondeur dans le...

CCP Tara | Project Management Specialist - Localization | @CCP_Tara
CCP Tara
C C P
C C P Alliance
#2 - 2015-08-07 11:32:41 UTC  |  Edited by: CCP Tara
-4
-3
-2
-1
...
0

Le serveur a redémarré !

C'était une très bonne nouvelle. Maintenant, il nous fallait comprendre pourquoi vider les données de renforcement et de vulnérabilité avait permis au serveur de démarrer correctement.

Nous ne pouvions pas démarrer le serveur dans cet état, étant donné que nous avions supprimé un jour entier de campagnes de souveraineté. Nous avons donc poursuivi l'enquête. À ce moment-là, environ 8 programmeurs d'EVE participaient à l'enquête,et plusieurs membres de l'équipe chargée de l'exécution du serveur faisaient leur propre enquête en parallèle. Chaque membre de l'équipe QA dans le bâtiment essayait de répliquer le problème sur Singularity. À 17.10, nous avons effectué le prochain changement – les données de fenêtre de vulnérabilité furent ajoutées à nouveau dans la base de données. Le prochain démarrage nous aiderait à indiquer si c'était cela ou les événements de renforcement qui bloquaient le démarrage. Nous avons déployé ce changement, avons réussi à démarrer et avions presque trouvé la cause du problème : la présence des campagnes. Les développeurs d'EVE ont donc poursuivi leur enquête avec ces nouveaux éléments. Les données de campagne restantes furent ajoutées à nouveau à la base de données.

[img]http://content.eveonline.com/www/newssystem/media/67449/1/Iqy3lnysmall.png[/img]

Une de nos théories sur ce qui pourrait causer l'arrêt des nœuds : lors du démarrage, les nœuds qui exécutent les systèmes solaires avec une ou plusieurs campagnes de souveraineté communiquent avec les nœuds qui gèrent les alliances qui y sont liées. L'une de ces requêtes est de vérifier le système capital choisi par l'alliance. Selon le nouveau système de souveraineté, les changements apportés au système capital d'une alliance prennent plusieurs jours à prendre effet. Dans les jours qui ont suivi le développement de la version Aegis, nous voulions que les alliances puissent s'installer facilement avec nos nouvelles règles. Nous avions donc ajouté une option de configuration grâce à laquelle nous pouvions temporairement remplacer le décompte de 7 jours par un délai plus court.

Notre théorie était que si ces appels inter-nœuds, effectués pour consulter la capitale d'alliance, interagissaient avec le mécanisme de chargement des données de configuration (utilisés pour outrepasser le délai par défaut) d'une manière ou d'une autre, cela pouvait résulter en un blocage inter-nœuds. Le nœud de système solaire qui charge la campagne attend que le nœud d'alliance réponde avec les informations dont il a besoin. Pendant ce temps, le nœud d'alliance a chargé les paramètres de configuration de capitale, et envoie une mise à jour au système solaire de cette capitale en lui indiquant qu'il est le système capital et doit utiliser un modificateur de défense +2. Le nœud d'alliance ne répondra à aucune nouvelle requête jusqu'à ce que le nœud de système solaire ait pris en compte le statut de capitale mis à jour. Mais le nœud de système solaire ne répondra à aucune nouvelle requête jusqu'à ce que le nœud d'alliance réponde à la requête de campagne. Nous avons envoyé un changement de code pour supprimer le délai de capitale configurable, éliminant ainsi les blocages potentiels. Lors du démarrage suivant, à 18.12, 51 nœuds se trouvaient au statut "-1". Nous avons donc repris nos recherches (tout en redémarrant une nouvelle fois, au cas où).

Que savions-nous jusqu'ici ?


  • Le démarrage sans données de campagne dans la base de données a fonctionné sur TQ et tous nos serveurs de test.
  • Un démarrage avec 300 campagnes environ dans la base de données a fait échouer TQ, mais a fonctionné sur nos serveurs de test.
  • Éliminer des appels inter-nœuds aux capitales d'alliance n'a pas eu l'air de faire la différence.
  • Il nous fallait faire quelques tests des campagnes sur TQ pour isoler les endroits spécifiques qui posaient problème.


Nous avons décidé de supprimer complètement le chargement des campagnes au démarrage. Les nœuds de commande en arrière-plan n'apparaissaient donc plus, mais les structures de souveraineté pourraient se charger normalement. Bien sûr, nous n'avions pas l'intention de garder cet ajustement à l'avenir. Nous l'avons fait pour avoir une meilleure idée des conditions qui causent la réussite ou l'échec d'un démarrage. Ce changement expérimental (Hotfix #2) nous a effectivement aidé à faire démarrer le serveur à 19.15, et nous a permis d'essayer le Hotfix#3 : que se passerait-il si nous chargions les campagnes, mais seulement après un bref délai, pour permettre à tout le reste de finir de démarrer d'abord ?

Nous avons aussi essayé de réactiver le chargement de campagne (que nous avions désactivé dans le Hotfix #2), mais avec un bref délai, et l'avons laissé s'exécuter en différé. À ce moment-là, nous devions gérer plusieurs complications : la synchronisation de Perforce s'était arrêtée, ce qui causait des retards dans notre système de build, et nous avions aussi des problèmes de stockage de données sans rapport avec le serveur. À mesure des hotfix, nous nous rapprochions de plus de en plus des...

[img]http://content.eveonline.com/www/newssystem/media/67449/1/CJ-vErKWsAARyU8small.jpg[/img]

pizzas, qui sont arrivées avec bonheur à 19.48, tandis que notre 3ème hotfix était déployé. TQ n'a pas pu redémarrer avec ce changement. C'était intéressant, puisque dans le Hotfix #3, nous avions chargé les campagnes indépendamment du reste des tâches de démarrage – rien que le fait de les charger leur faisait rompre quelques nœuds.

Revigorés grâce à une table de ping-pong remplie de pizza, nous redéployâmes le Hotfix #2 pour plus de tests, et des expériences en direct sur la console !

[img]http://content.eveonline.com/www/newssystem/media/67449/1/pics_026small.jpg[/img]

CCP Tara | Project Management Specialist - Localization | @CCP_Tara
CCP Tara
C C P
C C P Alliance
#3 - 2015-08-07 11:38:29 UTC  |  Edited by: CCP Tara
Une fois que tous les nœuds étaient prêts et que nous avions vérifié que les systèmes solaires s'étaient chargés correctement, nous avons ouvert une console python sur le serveur, pour nous permettre d'émettre des commandes et d'observer les résultats en temps réel. Nous avons effectué plusieurs vérifications pour nous assurer qu'aucune campagne n'était chargée sur un nœud. Comme prévu, les nœuds ont tous rapporté que leurs campagnes étaient vides. Nous avons ensuite envoyé une requête à tous les nœuds afin qu'ils chargent les campagnes desquelles ils étaient responsables. Immédiatement après, le cluster a commencé à ralentir et ne réagissait plus. Après quelques minutes, nous avons commencé à voir plusieurs nœuds mourir et quitter le cluster. Tous les systèmes solaires qui se trouvaient sur ces nœuds morts étaient réorientés vers les nœuds actifs restants. Il ne nous restait donc plus que 200 nœuds sur 250. Nous avons ensuite demandé au cluster d'exécuter la séquence de chargement de campagne une fois de plus. Nous nous attendions à ce que chaque nœud se déconnecte des campagnes qu'il connaissait, et rapporte qu'aucune autre campagne n'avait besoin de chargement (étant donné qu'elles étaient toutes en mémoire). Dans les faits, le cluster a cessé de répondre pendant quelques minutes, et lorsque tout s'est mis en place, encore plus de nœuds étaient morts. Cela nous a semblé très étrange, puisque les nœuds devaient simplement se déconnecter et n'avaient plus rien à charger. Une pensée nous est venue : et si ce n'était pas les campagnes elles-mêmes qui causaient le problème, mais l'enregistrement des donnée autour des campagnes ? Comme le cluster était en mauvais état à cause des nœuds morts, nous avont fait redémarrer le serveur (tout en restant sur le Hotfix#2) pour plus de tests.

Avec la console, nous avons modifié les fonctions de chargement de campagne pour qu'elles exécutent normalement le chargement à partir d'opérations de base de données, et avons désactivé toutes les opérations d'enregistrement. Nous avons ensuite répété le même test – et demandé à tous les nœuds de charger leur campagne. Cette commande s'est terminée quasiment instantanément, et le cluster était intact. Comment était-ce possible ? D'autres vérifications indiquaient que toutes les campagnes s'était effectivement chargées avec succès. Nous avons répété le test de chargement une deuxième fois, en utilisant encore les fonctions de chargement et en désactivant l'enregistrement. Cela s'est terminé instantanément, en rapportant qu'aucune nouvelle campagne ne nécessitait de chargement.

Comme test final, nous avons réactivé la fonction d'enregistrement, et envoyé davantage d'instructions de chargement de campagne. Le cluster est ensuite retourné à comportement précédent : ralentissement excessif et désactivation progressive des nœuds.

Il semble que nous avions trouvé le coupable (même si nous ne savions pas vraiment comment/pourquoi !) Pour une raison inconnue, le canal d'enregistrement utilisé par le système de campagne de TQ semblait affecter la performance des nœuds, jusqu'à les faire quitter le cluster.

Remarque : ces canaux se réfèrent aux enregistrements utilisés par les développeurs pour les opérations de test de fonctionnalité et la recherche de bugs. Ils sont indépendants des journaux d'activité que vous pourriez avoir dans le portefeuille de votre personnage, par exemple, ou celui que les GM utilisent dans leur travail de support client.

Le Hotfix#5 a été requis à 21.48, et il contenait ce que nous pensions être la réponse au problème. Nous avions supprimé tout l'enregistrement au sein du système de campagne, mais avions laissé le code intact. Si ce changement fonctionnait et faisait redémarrer le serveur, nous pourrions ouvrir TQ à nouveau. Le Hotfix#5 a été déployé sur TQ à 22.07. Nous avons réussi à démarrer TQ à 22.22 et avons commencé la vérification VIP pour nous assurer qu'aucune donnée de souveraineté n'avait été endommagée par notre essai. Nous avons trouvé un souci lié à une campagne en double, mais avons pu rectifier cela facilement. Nous avons réussi à remettre CREST en ligne à 22.38 et avons enlevé la connexion VIP afin d'ouvrir TQ à tous les joueurs à 22.41.

CCP Tara | Project Management Specialist - Localization | @CCP_Tara
CCP Tara
C C P
C C P Alliance
#4 - 2015-08-07 11:40:58 UTC
Suite – lundi, 20 juillet

Suite à nos aventures d'échec au démarrage du cluster, nous voulions comprendre pourquoi un canal d'enregistrement spécifique (celui utilisé pour les campagnes de souveraineté) sur un serveur particulier (Tranquillity) avait pu causer des problèmes de stabilité aussi extrêmes. Ainsi, nous avons planifié une connexion VIP sur TQ où nous pouvions effectuer quelques tests. Notre but était de trouver le code le plus simple possible à exécuter qui nous permettrait de reproduire les symptômes afin d'aider les enquêtes futures. Nous nous sommes connectés à une console python sur un nœud TQ - avec la console, nous pouvions un peu toucher à tout, pour voir ce que nous pouvions casser. (Avant cela, nous avions effectué les mêmes étapes sur les serveurs de test Singularity et Duality, et tous les tests s'étaient terminés sans déclencher d'erreur).

Nous avions préparé une série d'étapes de résolution que nous voulions suivre. Chacune des étapes ajouterait de nouveaux facteurs progressivement, jusqu'à ce que le problème puisse être, nous l'espérions, reproduit. Il se trouve que nous n'avons pas eu à chercher très loin ! Voici ce qu'il s'est passé :

Tout d'abord, nous avions deux canaux d'enregistrement – un canal général, puis un canal spécifique, utilisé au sein du système de souveraineté pour les activités d'enregistrement de campagne. Nous avons ensuite confirmé que les deux canaux fonctionnaient, en exécutant le code suivant sur un nœud unique.

1 # generic_logger se réfère à un canal d'enregistrement générique
2 # campaign_logger se réfère au canal d'enregistrement utilisé par les campagnes de souveraineté
3
4 # Étape 1a : s'assurer que la réponse vers le canal d'enregistrement générique fonctionne correctement
5 generic_logger.warn('The quick brown fox jumps over the lazy dog')
6
7 # Étape 1b: s'assurer que la réponse vers le canal d'enregistrement de campagne fonctionne correctement
8 campaign_logger.warn('The quick brown fox jumps over the lazy dog')

Lors de l'exécution, nous observions le résultat de l'enregistrement en temps réel via Splunk. Chaque ligne apparaissait en effet une fois.

Ensuite, nous avons exécuté l'étape 1a sur l'ensemble des 250 nœuds en parallèle, au même moment. Nous avons immédiatement vu 250 entrées apparaître sur l'affichage Splunk. Ensuite, nous avons fait la même chose avec l'étape 1b, et avons constaté le même résultat – chaque nœud enregistre une instance de la ligne, et chaque ligne affiche qu'elle provient du canal de campagne.

Pour l'instant, ça fonctionne bien. Maintenant, on va enregistrer un peu plus de données, mais rien qui ne puisse causer de problème, n'est-ce pas ? Pas vrai ? Mmm.

1. # Étape 2a : Enregistrer la même ligne 500 fois par nœud, sur le canal d'enregistrement générique
2. [generic_logger.warn('The quick brown fox jumps over the lazy dog') for i in range(500)]
3. # Étape 2b : Enregistrer la même ligne 500 fois par nœud, sur le canal d'enregistrement de campagne
4.
5. [campaign_logger.warn('The quick brown fox jumps over the lazy dog') for i in range(500)]


Pour ceux qui ne sont pas familiers avec Python : la ligne 2 sera lue 500 fois, et affichera un message d'avertissement une fois par boucle depuis le canal d'enregistrement générique. La ligne 5 fait la même chose, mais pour le canal d'enregistrement de campagne.

Nous avons d'abord effectué l'étape 2a sur tous les nœuds en parallèle. La commande s'est terminée instantanément, et nous avons constaté un pic de 125 000 lignes (250*500) sur le graphique Splunk. Cela représente beaucoup de données, mais c'est tout à fait gérable par le système, surtout sur de petites instances comme celle-ci. Nous avons ensuit exécuté l'étape 2b de la même manière. C'est là que quelque chose de curieux s'est produit. Le nombre correct de lignes d'enregistrement s'est affiché dans Splunk (les enregistrement montrent donc quelque chose !), mais la commande ne semblait pas revenir aussi rapidement que pour l'étape 2a. En fait, il a fallu quelques minutes avant que la console puisse être à nouveau réactive, et les données renvoyées indiquaient que plusieurs nœuds n'avaient pas répondu à temps. En regardant l'état du cluster, ces nœuds apparaissaient comme morts. Cette ligne d'enregistrement innocente avait réussi à causer l'arrêt de ces nœuds et leur déconnexion du cluster.

La solution était donc bien plus simple que ce que nous pensions. Nous n'avions même pas à commencer à faire quoi que ce soit avec les campagnes ou la base de données pour reproduire le cluster arrêté. Si un développeur ne peut pas être sûr que les enregistrements ne vont pas exploser le serveur de production, il risque de passer une mauvaise journée. Comme nous, le mercredi 15 juillet. Comme nous avions isolé le problème, nous avons redémarré Tranquillity, avons autorisé l'arrêt de la connexion VIP, et avons ouvert TQ comme d'habitude.

Comme nous l'avons mentionné plusieurs fois dans ce blog, c'est la première fois que nous avons constaté ce problème, et il ne s'était jamais produit d'autres serveurs de test avant cela, ni même depuis. Le serveur Tranquillity a une manière unique de fonctionner (et sa configuration elle-même est assez unique). Nous continuons d'enquêter sur les raisons du comportement de cet enregistrement (qui ne se produit que sur TQ), et sur pourquoi l'erreur ne s'est produite que sur des canaux d'enregistrement spécifiques. Nous savons que TQ opère sur une échelle différente en termes de logiciel, mais jusqu'ici nos tests suggèrent qu'il ne s'agit pas juste d'un problème de nombre de nœuds.

L'enquête se poursuit...

[img]http://content.eveonline.com/www/newssystem/media/67449/1/RaidersWarehouse.jpg[/img]

CCP Tara | Project Management Specialist - Localization | @CCP_Tara
Laufey Sif Tetseldottir
Blue Lagoon Appreciation Society
#5 - 2015-08-07 15:02:18 UTC
tl;dr
Lorgan Greuhzeth
The Scope
Gallente Federation
#6 - 2015-08-07 15:38:45 UTC  |  Edited by: Lorgan Greuhzeth
intéressant.

Pour ceux qui ont la flemme de lire en entier : Ça explique comment une recherche de panne peut être longue, et comment un simple routine d'enregistrement via un canal spécifique peux foutre tout le système en branle.

@CCP_Tara sinon : "Le Hotfix#5 a été requis à 21.48, et il connait ce que nous pensions être la réponse au problème."
il contenait plutôt, non ? car des hotfix qui connaissent des choses ça parait bizarroïde P

Mighty/SpaceFamous CEO of GREUH SACERDOTIUM !!!

twitter: LorganGreuhzeth

Organiser of Eve Paris
CCP Tara
C C P
C C P Alliance
#7 - 2015-08-07 15:45:41 UTC
Lorgan Greuhzeth wrote:
intéressant.

Pour ceux qui ont la flemme de lire en entier : Ça explique comment une recherche de panne peut être longue, et comment un simple routine d'enregistrement via un canal spécifique peux foutre tout le système en branle.

@CCP_Tara sinon : "Le Hotfix#5 a été requis à 21.48, et il connait ce que nous pensions être la réponse au problème."
il contenait plutôt, non ? car des hotfix qui connaissent des choses ça parait bizarroïde P


Hotfixes are people, too!

Merci d'avoir spotté, c'est corrigé :)

CCP Tara | Project Management Specialist - Localization | @CCP_Tara
Lorgan Greuhzeth
The Scope
Gallente Federation
#8 - 2015-08-07 16:14:24 UTC  |  Edited by: Lorgan Greuhzeth
C'est une belle version officielle en tout cas...

Mais on sait de source sûr que la vraie version c'est l'escapade des hamsters dans la nature car vous les nourrissiez pas assez et que c'est l'odeur de pizza qui les as ramenés.... Big smileBig smileBig smile

Mighty/SpaceFamous CEO of GREUH SACERDOTIUM !!!

twitter: LorganGreuhzeth

Organiser of Eve Paris
Gismork
French Wing
#9 - 2015-08-07 18:52:59 UTC
CCP Tara wrote:

Nous ne pouvions pas le serveur dans cet état, étant donné que nous avions supprimé un jour entier de campagnes de souveraineté. Nous avons donc poursuivi l'enquête. [...]


Je crois qu'il doit manquer un mot entre "Nous ne pouvions pas" et le "le serveur dans dans cet état" :).

On comprends mieux maintenant pourquoi cela mis autant de temps, pas facile à trouver comme bug.
Il y a de quoi s'arracher les cheveux !

Merci pour la traduction !
gastonn 2timesix
Moonshine Industrial Inc.
#10 - 2015-08-08 11:11:26 UTC
hé CCP Tara , t'as des nouvelles de ray donavan ?
mya karrde
Viziam
Amarr Empire
#11 - 2015-08-19 21:57:10 UTC
Merci Tara pour ce long post instructif pour les non informaticiens :)
Jdestars
Stars Research systems Incorporation
#12 - 2015-09-11 13:36:27 UTC  |  Edited by: Jdestars
très bon rapport en effet j'ai adorè l'expression les script "tiericide"
bat cher sur une large cible de serveur à partir d'une seul script et serveur peut bouffer la ram du serveur si les script ne sont pas rapide et que l'on n'attend pas les retour code ;) et ça peut prendre des heures ( du vécu )

nota sur les systèmes de déploiement de patch : un certain produit de Microsoft ('SCSM ) ne permet pas de maitriser le temps de déploiement et de faire un push urgent sur l'ensemble des cible les agent récupère les paquets quand ça leur chante... v.

ah les joie de l'ingénierie de production Blink

le redémarrage d'une infrastructure et ses service technique n'est jamais une chose simple fusse t-elle documenté que rien ne se passe comme prévu
on peut lire que les dev se sont poser la question : ce qui a changer entre la dernière mise à jours ... la bonne question n'est pas de ce dire : qu'est qui a changer depuis le dernières arrêt/redémarrage de l'infrastructure c'est a dire de la dernière grande maintenance ?

j'ose espérer que cet incident aura permis de mettre en place des contrôle addoc concernant la surveillance des compteurs de lock des serveurs de BDD
mais si l'est facile de détecter les lock de page dans un serveur l'est difficile de le voir entre serveur interagissant .. les labo de recherche de Polalis ont du boulot sur la planche
cet exemple nous montre la limite des plan d'architecture logique de l'infrastructure .


note pour CCP Tara .. la pizza nourris pas son homme , leur faillais des plats plus consistant faut leur faire découvrir les joie de la cuisine française .. la bière /requin au petit dej ça embrume l'esprit ;)
CCP Tara
C C P
C C P Alliance
#13 - 2015-09-14 13:20:00 UTC
Jdestars wrote:

note pour CCP Tara .. la pizza nourris pas son homme , leur faillais des plats plus consistant faut leur faire découvrir les joie de la cuisine française .. la bière /requin au petit dej ça embrume l'esprit ;)


Vu la pizza qu'il y avait, ils ont bien réussi à se nourrir ! Il en restait même le lendemain :)

CCP Tara | Project Management Specialist - Localization | @CCP_Tara