Exploitation et DevOps

La mise en place du DevOps semble bien agréable, fluide, fini les blocages, méthode Agile .. Mais il est une question que l’on se pose à un moment ou à un autre  : Et côté exploitation ? Comment cela se passe ?

En effet, dans le monde idéal DevOps (le mien) il y a des services transverses comme l’administration de cloud privé ou public. La mise à disposition d’outils pré-packagés.
Ces services restent sur un schéma assez proche de ce que nous connaissons tous.

Par contre avec la mise en place du DevOps, on se retrouve avec des « SysOps » qui vont déployer des VM sur le cloud. Des Ops qui vont regarder les DEV lancer des déploiements automatisés et ce jusqu’à la prod alors que précédemment c’était le service production/exploitation qui s’occupait de cette partie.

Les services productions/exploitations ont des procédures qui sont censées garantir la fiabilité et la robustesses des plateformes (Est-ce toujours le cas ?). DevOps semble casser ce fonctionnement. Il est donc légitime que les services exploitations ne veulent pas laisser la mains aux Ops car ce ne sont pas eux qui supervisent et se réveillent la nuit en cas d’incident.

Le schéma idéal : l’exploitation des applications est gérée par les Ops dans les équipes DevOps.
C’est déjà le cas dans une startup ou une PME : l’Administrateur système gère l’ensemble des aspects lié à l’exploitation.
Par contre dans ce schéma, le service production, exploitation, garde la main sur les briques transverses (Cloud, SAN, Infrastructure).

Et les astreintes ?
Ils faut envisager un schéma où le projet est concerné par les astreintes. Si nous sommes 12 dans une équipe projet : ça fait une semaine d’astreinte toutes les 12 semaines ….. donc 4 dans l’année.
Dans une de mes précédentes missions nous avions mis en place un point « Astreinte » tous les 15 jours. A chaque point nous abordions un nouveau sujet permettant aux personnes de l’équipe de monter en compétence sur ce sujet. Les collaborateurs orientés Système présentaient des sujets systèmes, les collaborateurs orientés fonctionnalité présentaient des sujets fonctionnels. Et cela permettait de créer une certaines cohésions et aussi de découvrir le métier de l’autre au travers ces astreintes partagées. Cela permettait aussi de mettre en place des solutions simples pour que les actions à effectuer en astreintes soient le plus simple possible voir inexistantes ! : Supervision, scripting, Automatisation !

Supervision & DevOps

Un des sujets Majeurs : La Supervision

Prod, Poc, recette, lignes de développements, il y a tellement de types d’environnements qu’il est parfois difficile de s’y retrouver.  Que superviser, comment ? Là aussi chaque entreprise a sa façon de penser et je vous assure que chez bon nombre de clients il y a quelques « trous » dans la raquette.

Le schéma habituel :

L’infrastructure de supervision est gérée par les équipes infra/systèmes. Dans cette façon de travailler, les projets, les métiers et les développeurs n’ont aucune visu sur cet ensemble.

On se retrouve donc parfois avec des situations comme une alerte qui sonne pour un serveur d’intégration qui est « down ». Ce qui oblige l’ingénieur système en charge de la supervision à se demander si cette alerte est bien justifiée sur de l’intégration. Premier tour du service :

Mais à qui est ce serveur ?

Il faut que tu contactes telle équipe ..

D’accord, merci.

Deuxième tour du service :

Ils ne connaissent pas ce serveur …

Ah bon ? Ah, OK, demande donc à Mrs X …

Et ainsi de suite.

Finalement le serveur n’était plus utilisé depuis 1 an, nous sommes en droit de nous demander pourquoi il n’a pas été arrêté plus tôt. Finalement dans ce type de situation il y a une réelle perte de temps et d’argent ….

Le schéma hybride :

L’infrastructure de supervision est installée et mise à disposition par les équipes infra/systèmes et ce sont les projets, les métiers et les dev qui ont la possibilité de mettre en place différents « checks », ce sont aussi eux qui reçoivent les alertes et qui seront responsables de leurs environnements : ici on est déjà dans le DevOps, et c’est évident que si c’est une équipe DevOps qui reçoit les alertes, il faut que l’équipe ait les droits et les compétences pour résoudre l’incident (sauf incident lié à l’infrastructure sous-jacente).

Le schéma DevOps :

Je vois l’équipe DevOps comme une Startup, comme une TPE au sein même de l’entreprise. Si l’on veut atteindre le dynamisme de ces Startups, il faut donner aux équipes DevOps la même liberté que possède la Startup. Et la supervision est un point important. Laissons aux SysOps des équipes cross-fonctionnelles la possibilité de monter leur propre supervision dans leurs propres environnements.

C’est évident qu’un projet avec 50 machines à superviser saura quoi, quand et comment superviser leurs serveurs, avec leurs applicatifs. En ce qui concerne l’infrastructure de supervision, les besoins en ressources seront en fonction de la taille des projets et à la finale, la totalité des petits besoins ne feront pas plus qu’une énorme infrastructure groupe qui supervise 10000 serveurs.  Par contre il y aura une énorme différence en terme de qualité et de service rendu : et là on est vraiment dans le DevOps !
En plus des gains évidents, il y aura une véritable dynamique entre les différentes équipes ce qui fait gagner en motivation. (évidement la possibilité d’inclure ou d’exclure certains outils peut être envisagée afin d’avoir une certaine homogénéité et de pouvoir enrichir une base de connaissances qui puisse servir à tous).

Et vous ? Êtes vous prêts à laisser vos équipes projets recruter des SysOps qui mettront en place leur supervision dans leurs environnements ?

OpenVPN & AWS

Avant de migrer dans AWS, avant de créer des machines dans AWS, la question que tout le monde se pose : comment vais-je accéder à mes serveurs ?

En effet, pour le particulier ou la TPE/PME, la réponse est souvent rapide : les serveurs se verront dotés d’une adresse IP publique.

Pour les entreprises de taille plus conséquente, avec parfois plusieurs sites, des réseaux déjà complexes, des serveurs critiques qui se doivent de ne pas être exposés en direct sur internet, la réponse est : VPN.

Il y a plusieurs moyens de connecter son SI à un VPC AWS, et OpenVPN en fait partie. Il y a bien sur des limitations par rapport à un VPN connecté via AWS VPN mais dans certains cas cette solution correspond parfaitement au besoin.

OpenVPN sera simple à installer, simple à administrer et le seul coût sera celui d’une petite instance EC2.

Terraform

Terraform est un outil qui nous permettra bientôt de terraformer la planète Mars afin de pouvoir y vivre comme sur Terre.

?

Mais non ! Évidemment 🙂

Terraform est un outil permettant de construire des environnements dans un cloud (privé, public). Il permet bien-sûr d’effectuer des changements sur ces environnements et il automatise aussi un certain nombre de tâches lors de ces créations, changements et suppressions.

Il est de plus en plus utilisé pour AWS mais il prend en charge OpenStack et tout un tas d’autres « providers ».

Notre infrastructure est donc définie dans des fichiers textes, sous forme de code (code terraform ou Json). Nous introduisons ici la notion de IAC (Infrastructure As Code). Un fichier texte peut donc contenir la définition d’un réseau virtuel, de 2 serveurs de bases de données, ainsi que de 3 serveurs Web. Ce fichier nous permet de déployer rapidement cette infrastructure mais aussi de la reproduire encore plus facilement !

Pour aller plus loin : https://www.terraform.io/intro/index.html

Migration vers le cloud

Une nouvelle année et donc de nouveaux projets !

Les entreprises qui basculent une partie ou l’ensemble de leur système d’information vers un cloud public sont de plus en plus nombreuses et ces projets de migration vont continuer en 2018.

Mais pourquoi ?

Voici une petite liste qui pourrait vous inciter à basculer tout ou partie de votre SI vers un cloud public :

  • Rapidité pour déployer, ajouter, migrer, supprimer
  • Agilité dans les projets hébergés sur un cloud public
  • Réduction des coûts
  • Sécurité des données et des accès
  • Offre extrêmement complète chez certains fournisseurs et qui ne cesse de s’étoffer (infrastructure, calcul, stockage, bases de données, intégration continue, analyse de données et même intelligence artificielle …)
  • Consolidation simple grâce à la réplication sur différents Datacenter
  • Productivité augmentée pour les équipes informatiques

Et vous ? Qu’en pensez-vous ?

DevOps pour nous c’est quoi ?

Un client m’appelle et me dit, le DevOps, pour moi c’est l’installation d’outils permettant l’automatisation et l’intégration continue.

Je lui réponds, le DevOps pour moi c’est créer des équipes regroupant toutes les compétences nécessaires à un projet, un sous projet, afin de casser la distance entre les développeurs, les chefs de projets et les équipes systèmes et infrastructures.