Reprise du message précédent :

Le bouton est trop sensible ?

 
Ce qui est marrant c'est d'écrire un soft qui gère à l'heure actuelle environ 115 000 VMs sur plus de 9000 serveurs

Wrong topic

Ça fait pas de grosses conso ça

 
Qu'est-ce que tu veux dire par là ?

 
Non, ce qui est moins marrant c'est le support, quand ya 2/3 des demandes qui sont à côté de la plaque c'est pas mal (enfin disons 1/3 concernant un problème de l'hyperviseur et 1/3 entre la chaise et la clavier). Là il y a quoi de devenir un peu aigri parfois

conso = consolidation j'imagine, 115k VMs pour 9k hôtes ça fait pas un très grand nombre de VMs par hôtes Mais bon ça dépend de tellement de choses.

C'est sûr que si c'est que des applications java (ou de l'oracle), ça réduit le nombre de vm possibles par serveur

Oracle de toutes façons si tu les écoutes quand t'utilises autre chose que leur hardware pour faire de la virtu il faut licensier absolument tous les cores de CPU existant, ayant existé ou qui existeront un jour sur terre

Ils t'ont pas dit ils ouvrent un datacenter sur la lune la semaine prochaine  

 
Oui enfin là tu fais une moyenne, qui peut être loin de la vérité
 
C'est les stats globales de toutes nos XOA, donc tu peux avoir des gens avec 2 VMs sur 2 hôtes ou alors des mecs avec 500 VMs sur une seule machine

 
Tellement
Votre truc est visible sur le net? Donc potentiellement tous les CPU de toutes les machines ayant un accès au net. Y compris les CPU des routeurs et autres équipements réseau. TOUT

Je nettoie le pc d'une amie, disque quasi plein, ok, un coup de windirstat :

290go (sur 320) pour le dossiers de logs de McAffee.

Comment que c'est possible.

   
Je deviens fou aussi
 
Y a un mec qui m'a tapé un scandale car je voulais pas faire remonter en interne que leur firmware de carte réseau était pas disponible sur le site du constructeur du serveur. Constructeur chez qui je ne travaille pas

 
Dans ma COGIP on en est arrivé à "rephysicaliser" toutes les instances Oracle pour économiser des €.

Je suis persuadé que le service licensing oracle y pensera un jour

En 2017 pourquoi ne pas dégager tout ça pour AWS RDS ou similaire ?

 
Je suis à la recherche de bouquin pour mieux piger comment fonctionne Oracle avec SAP. (Tout ce qui est PSAPUNDO, SAPTEMP etc...)
Est-ce que quelqu'un a croisé des bouquins la dessus? witjet ça te dit quelque chose?

Parce qu'en 2017 tu as toujours des tas de raisons techniques, légales, fonctionnelles et même financières pour qu'une solution saas/cloud ne soit pas forcément adaptée ?

 
Et que aussi on préfère faire bosser des gens chez nous pour maintenir hard soft et réseau.
On se paie même le luxe d'avoir des salles serveur en plein centre de Paris.

 
On parle d'Oracle quand même

Il va bientôt il y a avoir un audit chez nous pour refondre notre organisation coté exploitation/support users
 
aujourd'hui, 3 services (périmètre métier différent) font de l'exploitation/support users sans spécialisation interne.
Chaque services de support à des équipe de DEV dédiés.
 
 
L'objectif de l'audit est de refondre ce système et de créer:
- une équipe unifier sur le support utilisateurs
- garder les équipe de DEV, telle quel.
- crée une entité intermédiaire  "en mode DEVOPS".
 
Vu qu'on ma indiqué que je pourrais bascule sur cette céllule devips, je me pose des questions
Certain d'entre vous on deja vécue cette transition, quelle sont les compétence qui vous semble indispensable.
 
J'ai encore pas mal de temps (6mois mini) avant la bascule et j'aimerais bien être capable de saisir l’opportunité en m'auto formant au maximum.
 
Merci

Alors si t'as une entité dédiée au devops, c'est pas vraiment du devops.
Après c'est comme ça dans la plupart des boîtes, et à vrai dire tant mieux.
 
Mais tu viens de quel côté toi?
Chez nous pour des gens qui avant s'appelaient sysops ou system engineers ça veut dire:

• Déploiement avec Puppet/Chef/Ansible/Salt... donc faut savoir te démerder en Ruby/Python
• Toute l'infra automatisée, avec de l'IaaS, des containers, des trucs comme Kubernetes/Marathon/Mesos/Consul, de nouveau faut savoir scripter pour appeler des APIs.
• Fournir tout un pipeline de CI/CD, ils nous ont monté un truc qui provisionne des instances Jenkins à la demande, orchestration avec go.cd
• Aider à mettre en place le monitoring (Splunk, Catchpoint, Grafana, New Relic, ...)

J'ai fait un topic avec mes vieux PCBs sinon pour ceux qui auraient besoin de nanards (sait-on jamais ...)

oui, c'est assez marrant comme le rôle de "devops" n'est finalement qu'un sysadmin "nouvelle sauce".
Le dev lui, évolue peu.
 
Avant ils cherchaient des admins, maintenant, ils cherchent des devops.
Et ils comprennent toujours pas ce qu'il faut faire et c'est toujours à eux (admin/devops) de compenser les conneries des devs.

 
    c'est sûr, ça arrive tellement souvent  .
Surtout quand 90% du temps le dev est sur son poste en local.

 
C'est ne pas avoir compris ce qu'est la mouvance DevOps... Si c'était un sysadmin 2.0, on aurait appelé ça Sysloper.

 
De mon expérience c'est parfois un problème plus global, c'est l'organisation dans son ensemble qui n'a pas prévu de canal de communication pour ce genre de chose. Du coup en temps qu'admin on n'a pas vraiment de point de contact, on envoie un ou deux mails groupés un peu au pif mais c'est pas efficace.

 
DevOps c'est l'adminSys ultra Expert et en plus qui peut développeur tout seul des applications entières comme un Dev Expert quoi.
 
Sauf que le salaire il fait pas x2  . Non c'est juste qu'ils cherchent le mouton à 5 pattes, en prenant un seul Gus au lieux d'un Dev et d'un SysAdmin  

 
J'aimerais bien qu'on m'apprenne vraiment ce qu'est la mouvance DevOps. Ce que je vois moi c'est un AdminSys qui est capable de faire lui même du Dev d'un niveau correct pour scipter/automatiser tout un tas de choses.
 
Fin ce qu'un sysAdmin doit savoir faire de toute façon  

En théorie le devops c'est précisément pour améliorer les situations que vous décrivez, en intégrant beaucoup plus et en bon intelligence les aspects dev, sys, infra et exploit  pour s'adapter aux nouveaux rythmes, méthodes et exigences de delivery Et c'est pas un poste ou un métier devops, c'est une façon de travailler et d'organiser la collaboration entre dev, sys, IT, etc.
 
Dans la pratique c'est malheureusement trop souvent vu/vécu comme des mecs embauchés comme "devops" qui vont être des devs à qui on va demander de gérer tout de l'archi de l'infra, à l'admin au dev et à la QA, comme les devs qui prennent le contrôle de tout sans que le côté sys/infra des choses sans impliqué ou qu'on leur donne les moyens d'évoluer, ou comme des "admins" balancés au milieu des équipes de devs sans rien changer aux process et équipes côté sys/infra, ou très souvent comme un nouveau buzzword à balancer sans rien changer que ce soit côté dev ou infra mais en s'en servant pour justifier qu'il faut toujours faire plus et plus vite avec moins

C'est ça.
 
Une des rares boîtes qui pousse vraiment le concept à l'extrême c'est Amazon.
Chaque équipe de dév est 100% responsable de faire tourner son produit, en production, selon le SLA, gérant ses propres astreintes.
Chaque commit est déployé en production dans les minutes qui suivent.
Alors bien sûr derrière y a des équipes qui fournissent les outils internes nécessaires à ça (l'idée derrière AWS vient de là).
 
Même Google par exemple, ils engagent des devs à qui ils collent le titre Site Reliability Engineer, mais quand un produit doit être mis en production la première fois, c'est pas fait par l'équipe qui l'a développé.

bien résumé.
 
Faut dire déjà que "devops", c'est une tendance, pas un poste.
Alors voir des postes de devops, c'est un fail direct.
 
pour commencer à en faire dans mon taf actuel, on me contacte sur linkedin pour des postes ... ridicules.
Mais je parle à des RH donc ils comprennent pas que c'est dans l'organisation globale qu'il y a un fail.

De ce que je comprend qui va etre fait c'est:
 
C'est positionner des personnes (groupe à part ou dans les équipe dev) venant de l'exploitation pour amélioré les process de délivery(jenkins, etc, ) et le lien avec le support opérationnel (qui continueras d'exister mais plus petit)
 
 
On m'a parlé un peu du truc car je suis déjà très proche des cellule de DEV au jour de le jour et passe presque plus de temps a bosser avec eux qu'avec les gars de l'exploitation.
De plus je m'occupe déjà de pas mal d'outil / flux de données.
 
 
je vous lache des infos plus précise quand j'en ai.    
 
 
 

 
 
pareil mais c'est juste la première étape avant de les dégager  

Bas moi en réalité ce que je comprends c'est que la mouvance Devops c'est pour améliorer la chaine de validation/preproduction/passage en prod avec des personnes d'experiences qui peuvent avoir un certain recul.
 
 

 
je dois avoir ça en stock je regarde ce soir mais de toutes façons  c'est bientôt la fin de sap sous oracle