Suisse · Run cloud
Le contexte
Exploitation d'une plateforme hébergée chez un fournisseur public de cloud pour une société suisse de services financiers : supervision, mises à jour et correctifs, astreinte prévue par le contrat, runbooks écrits sur les alertes qui déclenchent réellement une action, et un cadrage mené au taux journalier avant le passage à un forfait de run. La société n'est pas nommée, comme sur l'ensemble de nos dossiers d'infrastructure. Ce dossier ne porte pas sur une migration mais sur ce qui vient après. La plateforme était déjà en place : ce qui manquait, c'était un exploitant, c'est-à-dire une équipe identifiée qui applique les correctifs, reçoit les alertes et répond la nuit. Dans les services financiers, cette absence se remarque vite, parce que les traitements ont des horaires et que l'indisponibilité d'un composant ne se rattrape pas en décalant la journée.
Ce que nous avons réalisé
- Supervision de la plateforme
- Mises à jour et correctifs
- Astreinte selon le contrat
- Runbooks sur les alertes utiles
- Passage TJM puis forfait de run
Une plateforme migrée que personne n'exploitait
La plateforme avait bien été migrée, mais le run n'était pas assuré : les mises à jour attendaient, les alertes arrivaient sans destinataire clairement désigné et aucune astreinte n'était organisée. C'est une situation classique de fin de projet, où l'attention se concentre sur la bascule et se retire au moment où la plateforme entre justement dans sa vie utile. Une infrastructure sans exploitant ne tombe pas le premier jour, elle se dégrade lentement, jusqu'à un incident que rien n'avait signalé.
La seconde difficulté était contractuelle. Un forfait d'exploitation signé trop tôt fige un périmètre encore mouvant : ni le volume d'incidents, ni la charge des mises à jour, ni la liste des alertes utiles n'étaient connus, et un engagement forfaitaire aurait été soit trop large pour le client, soit trop étroit pour nous. Aucune des deux parties n'a intérêt à un contrat bâti sur des suppositions, et nous préférons le dire avant de le signer. La question de savoir qui détient réellement les accès de la plateforme se pose au même moment, sujet que nous traitons dans notre article sur le compte racine cloud.
Cadrer le run au réel avant de le forfaitiser
Nous avons commencé au taux journalier, à 1000 HT la journée, le temps de stabiliser la supervision et le rythme des correctifs. La supervision a été construite sur un principe unique : une alerte doit correspondre à une action, sinon elle entretient un bruit de fond qui finit par masquer les vraies pannes. Nous expliquons ce que nous surveillons et à quels seuils dans notre article sur la supervision Zabbix, et l'offre correspondante est décrite sur notre page supervision.
Chaque alerte retenue a reçu un runbook, c'est-à-dire la marche à suivre écrite pour la personne qui la reçoit au milieu de la nuit, ce qui vaut mieux qu'une connaissance logée dans la tête d'un seul administrateur. Une fois le rythme connu, un forfait d'exploitation a pris le relais du taux journalier, sur le périmètre observé et non sur un périmètre estimé. L'ensemble relève de notre prestation de maintenance d'infrastructure : la Suisse fait partie de notre zone pour les missions cloud, qui se conduisent entièrement par accès distant, à la différence de nos interventions physiques réservées au Bassin Genevois.
Comment nous avons procédé
-
Cadrage du run
1 à 2 jours
-
Stabilisation
selon la plateforme
-
Forfait d'exploitation
une fois le rythme connu
Un exploitant identifié et des alertes qui ont une réponse
La plateforme a un exploitant nommé, des correctifs appliqués dans un cadre et une astreinte prévue par le contrat plutôt qu'improvisée au moment où une alerte tombe. Les alertes conservées ont chacune leur marche à suivre, ce qui rend l'exploitation transmissible entre plusieurs personnes au lieu de dépendre d'une mémoire individuelle. Le passage au forfait n'a été proposé qu'une fois le périmètre clair, ce qui donne à la société une dépense d'exploitation prévisible construite sur une réalité observée. Un projet de bascule se juge sur son plan de repli, une exploitation se juge sur la qualité de ses alertes et sur la possibilité de passer la main d'une personne à une autre. Une organisation dont la plateforme est en service sans exploitant identifié peut nous exposer sa situation pour cadrer un run.
Un projet, une panne, un rendez-vous.
Choisissez un créneau, ou décrivez votre besoin : nous répondons avec un périmètre clair, un prix hors taxes, et un interlocuteur nommé.