vers une DSI++: Nommer les projets

Nommer vos projets informatiques peut avoir une conséquence sur sa notoriété dans l’entreprise. Il est vite fait de détourner un nom ou d’utiliser un second sens afin de descendre ledit projet… Tout projet a des partisans, et d’autres plus hostiles, qui ne manqueront pas une petite talonade en comité de pilotage ou autre!

Les méthodes « classiques »:

  • Prendre la première lettre de chaque mot du titre complet en essayant d’en faire quelque chose. Ma dernière « création »: Rolex (RéOrganisons LEXploitation). S’agissant d’un ordonnanceur entre autre, la relation avec l’horlogerie parait sympathique… Cependant une Rolex a un coût important, quolibet potentiel en réunion, surtout si le projet ne finit pas à l’heure…
  • Des noms Grecs, Latins, Mythologies…
  • Comme les tornades: http://www.atl.ec.gc.ca/weather/hurricane/hurricanes4_f.html

Mes recommandations:

  • Le nom doit rester le plus court possible
  • Il doit être facile à se rappeler (et à écrire)
  • Il doit exprimer autant ce peut l’objet/objectif du projet
  • Si le nom du projet est public, chercher le nom auquel vous pensez sur des moteurs de recherches. Moins il est répandu, mieux c’est.

Ma conclusion:

  • Il ne faut se compliquer l’esprit à vouloir justifier chaque lettre. Si en pensant à votre projet, un mot vous vient à l’esprit, et qu’il vous fait penser en retour à ce projet précisément, retenez-le. Une fois le nom répandu, la signification de chaque lettre n’intéresse plus personne!

CIO Online a publié récemment ces deux dessins:

mise à jour du blog

juste pour vous dire que je viens de changer quelques bricoles sur le site:

  • Passage d’une dedibox V2 sur une dedibox Pro (dans une VM)
  • le format des adresses du blog (mais les anciennes fonctionnent toujours)
  • j’ai ajouté le « Share This ». Si vous cliquez dessus, vous aurez un panel d’actions possible:
share this
share this

migration sur Google Apps: le bon, la brute et le truand…

Rien de tel qu’une migration sur Google Apps pour occuper le week-end!

En source:

  • un compte Gmail (2Go de mails ; agenda ; reader ; contacts)
  • un compte pop free.fr à ramasser
  • un domaine (lotp.fr) avec un renvoi gandi de l’adresse mail sur gmail

En destination… ben tout sur Google Apps en utilisant mon domaine lotp.fr 🙂

Activer Google Apps sur son propre domaine prends à peine 15mn…jusque là rock & roll !
Bon évidemment, ensuite, le rêve serait qu’il prenne le compte gmail et qu’il transfère tout ce qu’il contient dans le compte Google Apps…Si c’était le cas, en même temps, je ne bloggerai pas sur le sujet !

Le bon…

  • ca fonctionne immédiatement
  • pas de carte bleue demandée
  • on peut personnaliser l’url d’accès au webmail, par exemple webmail.mondomaine.com
  • Google Labs est là, on peut mettre les mêmes addons que pour gmail
  • Avoir les serveurs de mail google en frontal élimine beaucoup de spam dès la connexion smtp. J’y gagne beaucoup par rapport à passer par les relais gandi.

La brute…

  • Google ne fournit aucun moyen de migrer ses mails gmail sur google Apps. C’est un comble! Même GoogleEmailUploader fourni par Google exclut les compte gmail en source…Oui oui, c’est bien fait exprès. Je suis passé par une méthode expliquée notamment ici : synchro des deux boites via imapsync. Le tout est d’avoir une bonne connexion à internet et un linux sous la main (une dedibox par exemple :). 3h00 pour 2Go. Globalement c’est nickel, à part au moins une pièce jointe qui n’est plus lisible sur la boite de destination!! Comme il ne touche pas à la boite source,vous pouvez la garder sous le coude quelques temps.
  • Pour les contacts et l’agenda, il faut faire un ping-pong en synchronisant l’ancien compte avec un client de messagerie, et ce dernier avec le nouveau compte.

Le truand…

  • Pas de Google Reader! Ca c’est vraiment un coup bas…Heureusement, il y a un workaround! Il faut créer un nouveau compte Google Reader en utilisant le compte mail Google Apps (même login/pass), et exporter/importer les flux. Reste que ca ne fait pas apparaitre le lien Reader en haut à gauche, et qu’il faudra s’authentifier sur Reader sans SSO.
  • Il semblerait qu’avant on avait plus d’espace mail en passant sur Google Apps. Là j’ai autant que mon compte Gmail…en fait j’ai même 1Mo de moins 😉 Sauf en déboursant un peu d’argent en édition Premier et donc 25Go

Je suis pour l’instant très satisfait du service, sans compter que le tout reste gratuit! Je serais prêt à payer pour avoir plus de stockage dans Google Documents (idem que gmail pour l’instant), Google Reader intégré…

UPDATE: j’ai finalement décidé d’utiliser Google Email Uploader sur mon pc fixe: en 64 bit, leur outil ne trouve aucune boite au lettre (outlook, thunderbird, même combat). Heureusement, quelqu’un a eu le courage de comprendre pourquoi, modifier le code source et relivrer une version qui fonctionne chez moi: http://blog.insanegenius.com/2009/01/google-email-uploader-on-vista-x64.html

Dedibox / VMware Server / VM / Ip publique

Cet article fait suite à un précédent sur Dedibox + Linux + VMware Server

Si vous voulez donner une adresse IP publique à vos VM:

  • Carte réseau sur « host only (vmnet1) » (on triche en activant le routage dans le linux hôte)
  • Configuration manuelle du réseau dans la VM
  • Adresse IP: l’ip publique louée chez dedibox (adresse ip supplémentaire)
  • Masque réseau: 255.255.255.255
  • Passerelle:
    • Linux: post-up /sbin/route add default dev eth0
    • Windows: l’ip de la dedibox. Acceptez l’avertissement
  • DNS : les mêmes que ceux de la dedibox

vers une DSI++: La sauvegarde, bilan de santé du SI ?

Après quelques péripéties sur la sauvegarde, voici quelques réflexions….

1/La sauvegarde permet de s’assurer de la cohérence des données. Si la sauvegarde complète du SI fonctionne, cela est déjà très positif! Car cela indique que toutes les données éparpillées partout sont lisibles.

2/L’évolution du temps de sauvegarde indique une tendance. S’il vous faut de plus en plus de temps pour sauvegarder un volume de données à peu près identique, cela indique une baisse de forme du SI. La sauvegarde peut être un exercice intense, car il s’agit de transférer un maximum de données en un minimum de temps. Cela test donc à la fois la capacité de lecture des différentes sources (SAN, AS/400…) et le backbone réseau.
On peut comparer la sauvegarde à une course de vitesse, où les dépôts de données sont les muscles et le réseau le sang circulant dans les veines. En cas de baisse de forme, il convient de diagnostiquer en détail ce qui ralentit. La fragmentation des disques durs est une raison fréquente, mais le service pack 2 de Windows 2003 a quelques effets sur les performances réseaux à ne pas négliger..

3/ L’expérience tend à montrer qu’une des premières briques du SI à se dégrader est la sauvegarde. Cela commence par une augmentation de la fenêtre de sauvegarde, puis des avertissements sur des fichiers non sauvegardés. Et là, alors que vous ne voulez toujours pas vous occuper de ces trop nombreux avertissements, une partition du serveur de fichiers principal lâche, d’un coup d’un seul… Enfin, c’est ce que l’on pense au début..Car on se rend compte que la sauvegarde se plaint depuis 15 jours de ne plus pouvoir sauvegarder des fichiers, de façon de plus en plus nombreux. Seulement voilà, il est trop tard, là où vous aviez un seul caillou dans la chaussure, vous avez d’un coup un menhir! Si je résume:

T0: tout va bien…
T1:tout va bien sauf quelques avertissements sur quelques fichiers, vous passez votre chemin..
T2:de plus en plus de fichiers non sauvegardés, mais bon « ce n’est qu’un avertissement » (laisser mariner 15 jours la situation…)
T3: Toute la partition est corrompue!

Sauf que maintenant, vous avez 15 jours de sauvegardes aussi complets qu’un emmental. Alors qu’il suffirait normalement de restaurer les données de la veille, ces données ne valent rien. Expliquer à son DSI et plus haut qu’une panne fait perdre une journée de travail, c’est déjà dur, mais lui expliquer que c’est 15 jours qui sont perdus…Pas la même histoire.

On peut alors se poser la question « pourquoi ne pas avoir traité ces avertissements? »
Sur un SI un peu évolué, avec une centaine de serveurs, il est très difficile d’avoir toutes les sauvegardes de tous les serveurs sans aucun avertissement. Il y a toujours un serveur pour faire parler de lui le matin au rapport d’exploitation. D’une part, les personnes en charge prenne l’habitude de voir quelques avertissements qui vont et viennent. Ils ne se formalisent plus en dessous du mot « échec ». Je pense que le terme « avertissement » n’est pas approprié est amène les administrateurs à penser que cela va suffisamment bien pour ne pas s’inquiéter.
La sauvegarde est un sujet ingrat, comme un vaccin. Il n’intéresse personne jusqu’à ce qu’il y en ait besoin. Et là personne ne comprends que la sauvegarde de la veille n’ait pas fonctionné, sans chercher plus en détail les causes profondes du maux.

Quelques conseils pour une DSI++:

  • Ne rien lâcher, traiter les avertissements comme un échec. Ne rien laisser entraver le bon déroulement de la sauvegarde. Arrêter cette ancienne application tous les soirs s’il le faut.
  • Historier tous les temps de sauvegardes (et volumétrie). Générer un rapport mensuel sur les performances des 6 derniers mois.
  • Faire un test de restauration au moins tous les mois, toujours sur un élément différent.

La sauvegarde est la dernière chose à fonctionner, et la première à tomber.

System Center Operation Manager 2007: collation de l’instance SQL Server 2005

Que fût ma déception, de découvrir que SCOM 2007 impose que l’instance SQL soit en SQL_Latin1_General_CP1_CS_AS.
Oui, vous avez bien lu, l’instance elle même doit avoir cette collation précisément, et non juste les bases SCOM…
Le setup que nous souhaitions:
Instance SQL Server (collation: French_CI_AS)
TempDB (collation: French_CI_AS)
OP DB (collation: SQL_Latin1_General_CP1_CS_AS)
DWH DB (collation: SQL_Latin1_General_CP1_CS_AS)
(Ce setup sur notre maquette n’a pas posé de problème pour l’instant)

Pourquoi ? SCOM utilise la base tempDB, qui a la collation de l’instance. Cela peut donc engendrer des effets de bords.
Cette information est rare, je dirais même que l’information n’existe pas de façon explicite, voilà qui est chose faite!

——————————————————————–
Bonjour M. Chateau,
Suite aux diverses conversations avec le groupe produit, il en ressort lefait d’avoir des collations différentes
entre la TEMPDB et la base SCOM génère des effets de bord tant au niveau du traitement qu’au niveau des performances.
De plus la collation SQL_Latin1_General_CP1_CS_AS est la seule a avoir été testée et approuvée donc que nous supportons.

Complément de l’équipe produit SCOM US:
——————————
SCOM is a very complicated product, and you want to stay with what’s tested in 100% of all cases.
A dedicated SQL server should also generally be used for SCOM, so I do not see any reason not to use the default collation,
unless this is for a proof of concept, or a very small (shared sql) installation.
If OpsMgr and TempDB differ in collation, your management group will be unusable.
As long as TempDB and OperationsManager, and OperationManagerDW are all SQL_Latin1_General_CP1_CS_AS, there should not be a problem.
I don’t think changing the collations is supported, There are known issues if the tempdb has a different collation than the Ops DB.
If both DB’s had the same collation, I am not aware of any known issues, but this is an untested scenario.

——————————
Dans le cadre d’une infrastructure telle que vous nous me l’avez décrite (50 agents), en général  la base SCOM n’a pas besoin installé sur un serveur dédié.
Ainsi le serveur SCOM peut être installé sur la même machine que sa base.
Si vous avez besoin d’autres éclaircissement n’hésitez pas à me contacter.