Embauchez un ingénieur DevOps quand vous avez assez de travail d’infrastructure régulier pour occuper un poste à temps plein, ou quand l’infrastructure est le produit que vous vendez. Impartissez les opérations quand le vrai besoin est la couverture, c’est-à-dire une personne responsable de la production la nuit, la fin de semaine et pendant les vacances. Une seule embauche ne peut pas offrir cette couverture à elle seule, et un fournisseur est rarement le bon responsable de votre code applicatif. Le modèle hybride est une voie mitoyenne courante pour les PME : l’application reste à l’interne et un fournisseur opère la couche infrastructure.
DevOps est la contraction de développement et d’opérations. Un ingénieur DevOps construit et opère les systèmes sur lesquels le logiciel est déployé et hébergé. Il s’agit des serveurs, des comptes cloud, des pipelines de déploiement, de la surveillance et des sauvegardes. Impartir les opérations signifie qu’un fournisseur opère cette couche pour vous, selon un périmètre écrit et un accord de niveau de service (SLA). Le SLA est le contrat qui énonce ce à quoi le fournisseur s’engage. Des offres semblables se vendent sous les noms d’opérations infogérées, de DevOps en tant que service ou de gestion de serveurs impartie.
Que vous apporte une seule embauche DevOps, et que ne vous apporte-t-elle pas ?
Un ingénieur DevOps à l’interne vous apporte la connaissance du produit et une présence de jour, mais ni la couverture jour et nuit ni la continuité. L’ingénieur participe à vos réunions de planification et apprend l’application. Il peut modifier à la fois l’infrastructure et la façon dont vos développeurs livrent le code. Un fournisseur externe connaît rarement votre produit aussi bien qu’un collègue.
Une seule embauche ne vous donne pas de couverture jour et nuit. Une personne dort, prend des vacances, tombe malade et finit un jour par changer d’emploi.
Une seule embauche concentre aussi le savoir. Si le fonctionnement de la production n’existe que dans la tête d’une personne, l’entreprise s’expose au risque lié à une personne clé : un seul départ peut lui enlever la capacité d’opérer le système.
Combien d’ingénieurs faut-il pour une couverture de production 24/7 à l’interne ?
Assurer une couverture de production 24/7 à l’interne demande une rotation de plusieurs ingénieurs. Être de garde signifie être joignable et capable d’agir sur les alertes de production en dehors des heures de travail. Une rotation de garde partage cette charge entre plusieurs personnes.
La page de cadrage de Stack Harbor donne sa propre estimation : « une rotation interne 24/7, c’est six équivalents temps plein et plus une fois les vacances, la maladie et l’épuisement couverts ». Sa page de surveillance parle de cinq ou six ingénieurs. Ce sont les estimations d’un seul fournisseur. Faites donc le calcul pour votre propre équipe :
- Comptez les heures de la semaine qui tombent hors de vos heures de travail.
- Décidez combien de nuits et de fins de semaine par mois une personne peut prendre les alertes sans s’épuiser.
- Ajoutez les vacances, la maladie, les congés parentaux et le délai entre une démission et un remplacement.
- Comptez combien de vos ingénieurs peuvent rétablir la production seuls à 3 h du matin.
Le résultat est la taille de la rotation que vous auriez à financer. La base de connaissances explique comment mettre en place une rotation de garde pour une équipe qui n’en a jamais eu. Elle explique aussi comment structurer les chemins d’escalade pour que les seniors ne soient pas réveillés par des alertes de routine.
Toutes les entreprises n’ont pas besoin d’une couverture 24/7. Si vos clients dorment quand vous dormez, une couverture en heures ouvrables ou étendue est peut-être le choix le plus juste, que vous la bâtissiez à l’interne ou que vous l’achetiez.
Que couvre l’impartition des opérations ?
L’impartition des opérations couvre normalement la couche infrastructure, et non l’application. Une proposition d’opérations infogérées peut contenir trois couches différentes, et il est utile de savoir laquelle on vous vend.
- Facturation et administration du compte. Le fournisseur revend ou administre le compte cloud. Cette couche ajoute peu de valeur d’exploitation à elle seule, et on la confond souvent avec de la gestion.
- Exploitation de l’infrastructure. Durcissement, correctifs, sauvegardes, surveillance, garde et réponse aux incidents. C’est la couche qu’achète un mandat d’exploitation continu.
- Exploitation applicative. Déployer votre code et faire tourner son pipeline. Il s’agit habituellement d’un mandat distinct, avec des exigences d’accès distinctes.
Une application qui tombe à cause de ses propres défauts relève du travail d’ingénierie, et ni l’embauche ni l’impartition ne la réparent. Si la plupart de vos incidents remontent à des bogues applicatifs, corrigez d’abord l’application, puis décidez qui opère les serveurs.
Embauche, impartition ou modèle hybride : comment les options se comparent-elles ?
Les options diffèrent surtout par la couverture hors des heures de travail, par la continuité et par la forme du coût. Le tableau les compare selon des critères que vous pouvez vérifier.
| Critère | Une embauche à l’interne | Rotation interne 24/7 | Opérations imparties | Hybride |
|---|---|---|---|---|
| Couverture hors des heures ouvrables | Au mieux, par une seule personne | Complète, si la rotation est bien dotée | Définie par la fenêtre de couverture du contrat | Le fournisseur couvre la fenêtre, votre équipe traite les escalades applicatives |
| Connaissance de votre application | Approfondie | Approfondie | Limitée à ce que permettent les runbooks et les accès | Approfondie à l’interne, documentée pour le fournisseur |
| Continuité quand quelqu’un part | Faible, à moins que tout soit écrit | Plus solide, le savoir est partagé | Dépend de la documentation du fournisseur et des conditions de sortie | Solide quand les runbooks sont partagés |
| Forme du coût | Salaire, avantages sociaux, outillage, temps de gestion | Plusieurs salaires et des primes de garde | Frais fixes pour un périmètre écrit | Un ou plusieurs salaires et des frais fixes |
| Charge de gestion pour vous | Vous dirigez le travail | Vous gérez une équipe | Vous gérez un contrat et un périmètre | Les deux, avec un partage clair |
| Risque principal | Dépendance à une personne clé | Un coût difficile à justifier sous une certaine taille | Un périmètre qui s’arrête avant ce que vous aviez supposé | Une responsabilité floue entre les deux parties |
Un runbook est une procédure écrite pour une défaillance connue ou une tâche de routine. C’est ce qui permet à une deuxième personne d’agir.
Qu’advient-il de la continuité quand une personne ou un fournisseur part ?
La continuité des opérations dépend de ce qui est écrit, que vous embauchiez ou que vous impartissiez.
Pour une embauche à l’interne, faites de la documentation une partie du poste. Exigez des runbooks pour les défaillances courantes et un diagramme d’architecture à jour. Exigez aussi qu’une deuxième personne détienne un accès fonctionnel à la production.
Pour un fournisseur, demandez ce qui vous suit à la fin du contrat. Demandez qui fait le travail quand vous ouvrez un billet, si la même équipe reste affectée à votre environnement, et comment les accès sont retirés à la sortie. L’article sur quoi rechercher chez un fournisseur d’hébergement infogéré énumère des critères que vous pouvez vérifier avant de signer.
Quels facteurs déterminent le coût de l’embauche et celui de l’impartition ?
L’embauche et l’impartition n’ont pas les mêmes facteurs de coût. Il faut donc comparer des choses comparables. La comparaison juste met en regard le devis d’un fournisseur pour une fenêtre de couverture et le coût complet des personnes que cette fenêtre exige.
Le coût d’une embauche dépasse le salaire :
- Les avantages sociaux, les cotisations de l’employeur et l’équipement.
- L’effort de recrutement et la période d’intégration avant que l’ingénieur soit efficace.
- L’outillage de surveillance, d’alerte et de sauvegarde dont l’ingénieur aura besoin.
- Le temps de gestion, et des primes de garde si des nuits sont à prévoir.
- Le coût d’un poste vacant quand la personne part.
Le coût des opérations imparties dépend habituellement de l’environnement et de la couverture :
- Le nombre et la classe des environnements, par exemple la production et le staging.
- La complexité de l’architecture et la redondance.
- La fenêtre de couverture : heures ouvrables, heures étendues ou 24/7.
- Les cibles de réponse du SLA et le nombre d’actifs surveillés.
- Les heures de projet mensuelles et, pour les agences, le nombre de sites clients.
Comparez un devis de couverture 24/7 à une rotation, et un devis de couverture en heures ouvrables à un seul ingénieur.
Demandez à tout fournisseur comment son prix est structuré. Des frais établis en pourcentage de votre facture cloud montent quand votre facture monte, ce qui affaiblit l’incitation à la réduire. Des frais fixes pour un périmètre écrit se budgètent plus facilement, à condition de lire où le périmètre s’arrête. L’article sur la façon dont l’hébergement cloud infogéré est tarifé explique les structures de prix courantes.
Quand faut-il embaucher un ingénieur DevOps plutôt qu’impartir ?
Embauchez un ingénieur DevOps quand le travail est régulier, à temps plein et proche de votre produit.
- Le travail d’infrastructure régulier suffit à occuper un poste à temps plein, mois après mois.
- Votre produit est l’infrastructure, par exemple une plateforme d’hébergement.
- Le travail se situe surtout dans votre application et son pipeline de livraison, là où la connaissance du produit compte plus que la couverture.
- Deux ingénieurs ou plus sont déjà responsables de l’exploitation et la font bien. Ajouter un fournisseur crée un problème de double commande, à moins que le partage du périmètre soit explicite.
- Vos clients travaillent aux mêmes heures que vous, de sorte qu’une panne de nuit peut attendre au matin.
Quand faut-il impartir les opérations ?
Impartissez les opérations quand le manque se situe dans la couverture, la continuité ou la routine d’exploitation plutôt que dans le travail sur le produit.
- Un seul ingénieur débordé tient la production à lui seul, et personne ne couvre ses nuits, ses fins de semaine ni ses vacances.
- Vous avez besoin d’une réponse confirmée hors des heures de travail et vous ne pouvez pas financer une rotation.
- La routine d’exploitation est sans cesse reportée : les correctifs ont des mois de retard, les restaurations ne sont pas testées, les alertes génèrent du bruit et rien n’est documenté.
- Vos développeurs seniors consacrent à des billets d’hébergement du temps facturable ou du temps destiné au produit.
Dans quels cas ni l’embauche ni l’impartition ne sont la bonne réponse ?
Ni l’embauche d’un ingénieur DevOps ni l’impartition des opérations ne conviennent dans trois situations.
- L’empreinte est minuscule. Si tout ce que vous opérez tient dans un serveur et un compartiment de stockage, un contrat d’opérations infogérées représente une charge excessive, tout comme une embauche dédiée.
- L’équipe compte deux développeurs. La lourdeur d’un mandat formel peut dépasser le travail répétitif qu’il enlève. Un pipeline construit une fois et documenté est peut-être la solution à la bonne échelle.
- L’application est le problème. Les alertes causées par des défauts applicatifs demandent du temps d’ingénierie, pas un nouvel opérateur.
La même décision vaut-elle pour les parcs WordPress, les agences et les serveurs cPanel ?
La décision est la même pour les parcs WordPress, les agences et les serveurs cPanel, et le scénario y est souvent plus marqué. Dans bien des agences, un développeur senior est devenu dans les faits l’administrateur système de tous les sites clients. Le travail d’hébergement est réel, mais il est trop fragmenté pour justifier une embauche à temps plein en exploitation.
Une agence dans cette situation peut acheter les opérations en marque blanche ou en cogestion et conserver la relation avec le client. Dans le cadre d’un mandat, une agence de 22 personnes a consolidé 14 sites clients, et ses deux développeurs seniors ont récupéré à eux deux environ quarante heures par mois. Le même scénario type note que l’hébergeur est rarement le vrai problème, et que la pièce manquante est un modèle de soutien.
L’article sur l’hébergement pour les agences qui gèrent plusieurs sites WordPress compare les modèles d’exploitation. Les petites équipes qui opèrent des serveurs cPanel peuvent lire le guide de la base de connaissances sur la conception d’une rotation de garde pour une petite équipe d’opérations cPanel. Les équipes sur Amazon Web Services (AWS) trouveront la version de cette décision propre à AWS dans l’impartition de la gestion AWS comparée à l’embauche d’un ingénieur DevOps.
À quoi répondre avant d’embaucher ou d’impartir ? Une liste de vérification
Répondez par écrit à ces huit questions avant d’afficher un poste ou d’appeler un fournisseur.
- Combien d’alertes de production se sont déclenchées hors des heures de travail au cours des 90 derniers jours, et qui y a répondu ?
- À quels moments vos clients sont-ils actifs, et que vous coûte une heure de panne à 3 h du matin ?
- Combien d’heures par semaine votre équipe consacre-t-elle aux correctifs, aux sauvegardes, à la surveillance et aux billets d’hébergement ?
- Ce travail est-il assez régulier pour remplir un poste à temps plein chaque mois ?
- Combien de personnes peuvent restaurer la production aujourd’hui sans aide ?
- Parmi les incidents de la dernière année, lesquels étaient des défaillances d’infrastructure et lesquels étaient des défauts applicatifs ?
- Des runbooks et un diagramme d’architecture existent-ils, et à quand remonte leur dernière mise à jour ?
- Si vous impartissez, quelle couche achetez-vous, et que conservez-vous à la fin du contrat ?
Un travail régulier à temps plein et des clients actifs le jour orientent vers une embauche. Une couverture mince, des restaurations non testées et un seul ingénieur fatigué orientent vers l’impartition de la couche infrastructure ou vers un modèle hybride. Si la plupart des incidents sont des défauts applicatifs, corrigez-les d’abord.
La place de Stack Harbor
Stack Harbor est un fournisseur d’exploitation infonuagique gérée (MSP) canadien pour les environnements de production, dont le siège est à Montréal. L’entreprise sert des PME et des agences d’environ 5 à 200 personnes qui opèrent des systèmes de production sans avoir leur propre équipe d’opérations 24/7. Sa clientèle comprend des entreprises de logiciel-service (SaaS), des agences et des éditeurs.
Son offre d’exploitation continue s’appelle Opérations Cloud. L’offre couvre l’exploitation de l’infrastructure : surveillance, correctifs, sauvegardes, réponse aux incidents, escalade aux fournisseurs et une feuille de route d’amélioration écrite. Les défauts applicatifs restent à vos ingénieurs. Les équipes à qui il manque seulement une réponse hors des heures de travail peuvent considérer la surveillance infogérée avec intervention de garde. Les agences peuvent utiliser le modèle d’infrastructure en marque blanche pour les agences.
Stack Harbor opère des environnements sur AWS, Azure, Google Cloud, OVH, DigitalOcean, des serveurs dédiés et cPanel/WHM. L’entreprise opère aussi sa propre infrastructure canadienne, dans deux centres de données à Montréal. Aucune migration n’est requise pour utiliser le service. Stack Harbor travaille aux côtés d’une équipe existante, ou tient lieu de fonction d’exploitation quand il n’y en a pas.
Une rotation de garde formée exécute des runbooks conçus par des ingénieurs seniors, et les ingénieurs seniors sont responsables des incidents de gravité 1 (Sev-1), c’est-à-dire une production en panne. Dans les plans qui comprennent la couverture des incidents, un incident de gravité 1 reçoit une réponse confirmée en moins de 15 minutes, et un incident de gravité 2 en moins de 60 minutes, jour et nuit. La résolution est une cible, pas un engagement. Ces délais sont publiés dans l’accord de niveau de service. La couverture en heures ouvrables et la couverture étendue sont aussi offertes. Les demandes techniques passent par le bureau de soutien, et le téléphone sert à joindre votre gestionnaire de compte.
La couverture peut être mise en place par étapes. Dans le cadre d’un mandat, une entreprise SaaS d’environ 35 personnes est restée sur AWS et a gardé ses propres ingénieurs. La couverture y est passée d’un sprint de runbooks le premier mois à une couverture 24/7 complète au troisième mois.
Chaque mandat livre un runbook écrit et un diagramme d’architecture, que vous conservez si vous partez. Stack Harbor ne publie pas de prix. L’entreprise remet un périmètre et un devis fixes après une évaluation écrite, comme le décrit la page Comment nous cadrons les mandats. Cette page énumère aussi les cas où un mandat est le mauvais achat.
