De nos jours, l'administration de systèmes agiles et les devops sont parmi les sujets les plus courants concernant l'administration et les opérations des systèmes. Ces deux concepts visent principalement à combler le fossé entre les opérations / administrateurs système et les projets (développeurs, entreprises, etc.). Même si vous n'avez jamais entendu parler du concept des devops, je suis sûr que ce sujet vous préoccupe également.
Alors, quels outils et techniques utilisez-vous pour accomplir des devops dans vos entreprises? Je m'intéresse particulièrement à des sujets comme la gestion du changement, l'intégration continue et l'automatisation, mais pas seulement à ces sujets. Veuillez partager vos pensées. J'ai hâte de lire vos réponses / opinions :)
Réponses:
svn / git - contrôle de révision, évidemment.
trac / redmine / jira - billetterie.
cobbler - pour l'approvisionnement du serveur du système d'exploitation de base. Cobbler est un produit axé sur la famille des redhat, mais je suis sûr qu'il existe quelque chose de similaire pour debian / ubuntu. De même, la plupart des sociétés de «panneau de contrôle cloud» comme RightScale vous fourniront cela. Le mot d'ordre ici est "JEOS" ou "juste assez de système d'exploitation". Mon chemin est d'utiliser la ligne "% packages --nobase" dans mes kickstarts et de construire ensuite ma pile spécifique via ...
marionnette / chef - pour la gestion de la configuration et l'application de la cohérence. Il y a d'autres options ici aussi, il importe plus que vous en utilisiez une que laquelle. Une astuce que j'ai trouvée particulièrement importante est de stocker les configurations dans le même système de contrôle de version que les développeurs utilisent. Cela permet de rassembler le flux de travail des deux équipes et de le rendre visible l'une pour l'autre.
func (ou capistrano ou cluster-ssh) - pour exécuter le script de déploiement sur le cluster. L'astuce ici est de faire en sorte que les développeurs seniors puissent se lancer à la fois pour pousser de nouvelles choses en direct et pour repérer les correctifs inévitables.
C'est vraiment le cœur des devops, permettant aux développeurs de casser et de réparer l'environnement. Beaucoup d'administrateurs système sont trop gourmands en énergie pour se laisser aller comme ça, ou leur gestion fonctionne toujours sur l'idée erronée que les administrateurs système devraient contrôler les développeurs (comme si nous pouvions même lire la moitié de ce qu'ils faisaient).
cacti / ganglia / collectd / munin - les graphes sont tellement importants. C'est la valeur commerciale des métriques avec la valeur humaine des visuels simples. La corrélation de l'horodatage des poussées de code avec l'horodatage des modifications dans les graphiques est extrêmement utile pour résoudre les problèmes de régression des performances et voir des faits réels sur les décisions de performances. Il y a un point clé ici en ce que les graphiques doivent être faciles à voir et à utiliser par les développeurs et leur gestion doit en attendre d'eux.
nagios / zabbix / smokeping / etc - surveillance des éléments du serveur et des mesures de performance de type "page de base". Encore une fois, les graphiques sont essentiels. Ce sont plus pour le côté ops de l'équipe.
gomez / keynote / Browsermob - surveillance externe des performances complètes du navigateur, en tenant compte des services tiers, des CDN et des problèmes de temps de rendu. Ce sont plus pour le côté développeur de l'équipe.
C'est un mélange d'outils et de techniques, concentrez-vous sur les techniques. Plus précisément, le changement de mentalité du côté «sysadmin» des devops de «admin» à «operations». Il s'agit de permettre aux développeurs. Leur permettre de faire des choses, leur permettre de réparer les choses, leur permettant de voir de vrais faits / mesures / graphiques sur ce qu'ils ont fait. Inversement, les développeurs doivent comprendre qu'ils ont été activés et faire le travail de surveillance des tendances de performances, de débogage des problèmes et de penser non seulement aux fonctionnalités, mais comment les déployer et comment elles affecteront la santé de l'ensemble du système / environnement .
la source
Nous travaillons à faire exactement cela chez National Instruments. Vous pouvez en savoir plus sur ce que nous faisons à http://dev2ops.org/blog/2010/4/27/qa-ernest-mueller-on-bringing-agile-to-operations.html
Le mélange d'outils que cagenut mentionne ici va essentiellement dans la direction dans laquelle nous nous dirigeons ici.
la source
La meilleure approche consiste à comprendre l'environnement dans lequel vous travaillez. Commencez par parler aux développeurs et aux gestionnaires. Essayez de les intégrer et de faire rebondir leurs idées. Très probablement, ils auront une bonne idée de la façon dont les choses se déroulent et si vos idées pour introduire des devops causeront des problèmes.
À partir de là, commencez à regarder les applications et présentez-les une à la fois pour résoudre les problèmes.
la source
introduce them one at a time to solve problems.+1Bien que les outils et les techniques soient importants, le chemin critique est la collaboration à travers toute l'organisation. De nos jours, les opérations informatiques sont des opérations commerciales. Etsy affiche les changements de revenus sur leurs tableaux de bord, visibles pour tout le monde.
la source