Support et maintenance applicatifs infogérés
Maintenir en état de marche des logiciels déjà en production, dans le cadre de votre SLA et de votre file de tickets : qualification, corrections à la source, versions correctives, montées de version des dépendances et des plateformes, réponse aux incidents de sécurité et gestion des incidents. Niveaux 2 et 3, par des ingénieurs qui développent aussi, de sorte qu’une panne récurrente est corrigée plutôt que redémarrée.
Pourquoi c’est un problème de partenaire
Le support est la partie d’un service managé qui est facile à vendre et difficile à staffer. Il arrive de façon irrégulière, il demande des personnes capables de lire du code inconnu sous pression, et dès que vous y affectez vos meilleurs ingénieurs, ils ne sont plus disponibles pour le travail qui rapporte davantage. La réponse habituelle est un niveau distinct, moins cher, qui ferme des tickets sans jamais rien corriger, et le client s’en aperçoit en un trimestre.
Notre réponse est que les personnes du support sont des ingénieurs. Elles peuvent modifier le système, pas seulement le décrire, ce qui est la seule façon pour qu’un incident récurrent cesse un jour de se répéter.
Ce que nous prenons en charge
Qualification et diagnostic
Prendre ce que le niveau 1 ne sait pas traiter, le reproduire et dire ce qui ne va réellement pas plutôt que de le clore comme « non reproductible ».
Des corrections qui tiennent
Défauts corrigés à la source, avec un test de non-régression écrit pour toute la classe de bug plutôt que pour le seul ticket, afin que le même incident ne revienne pas le trimestre suivant.
Versions et correctifs
Versions correctives livrées via votre pipeline et selon votre processus de changement, avec des dépendances, versions de framework et runtimes de plateforme tenus à jour au lieu de dériver vers une crise de mise à niveau.
Réponse aux incidents de sécurité
Un avis de sécurité publié sur un composant dont vous dépendez est une raison inconditionnelle de mettre à jour, pas un élément du backlog. Nous le suivons, le corrigeons et vous disons quelle était l’exposition.
Supervision et incidents
Surveillance des alertes existantes, ajout de celles qui devraient exister et gestion des incidents, avec ensuite un compte rendu écrit de ce qui s’est passé et de ce qui empêche que cela se reproduise.
Petites évolutions
Le flux régulier de petites améliorations qui maintient un client satisfait et ne justifie jamais un projet : traité dans la même capacité, aux mêmes conditions.
Votre SLA, évalué honnêtement
Nous ne publions pas d’objectifs de délai de réponse et de résolution, car un chiffre inventé avant que quiconque ait vu votre système ne vaut rien pour vous ni pour votre client. À la place, nous lisons le SLA que vous devez déjà, nous vous disons quelles parties nous pouvons réellement porter et quelle couverture cela exige, puis nous nous y engageons par écrit.
Il en va de même pour la couverture hors heures ouvrées. Lorsqu’une mission l’exige et que nous l’avons convenue dès le départ, elle est assurée par des personnes recrutées ou affectées pour ces horaires, et non en réveillant quelqu’un en espérant le meilleur. Nous travaillons déjà selon les horaires européens, australiens et de la côte Pacifique des États-Unis sur d’autres missions : la question est donc de savoir quelle plage vous faut, pas si c’est possible.
Reprendre un système que nous n’avons pas construit
C’est le cas normal. Neuf reprises à ce jour, la plus ancienne écrite en 2008.
D’abord une revue en lecture seule
Nous obtenons l’accès au code, à l’infrastructure et à l’historique des tickets avant d’être responsables de quoi que ce soit, et nous regardons au lieu de modifier.
Une liste écrite des risques
Ce qui est fragile, ce qui n’est pas corrigé, ce qui n’est pas documenté et ce qui réveillera quelqu’un la nuit, classé par impact en production. À vous, que nous allions plus loin ou non.
La discussion sur la couverture
Nous lisons le SLA que vous devez à votre client et vous disons honnêtement quelles parties nous pouvons porter, quelles heures cela exige et ce que cela coûte, avant que l’une ou l’autre partie ne signe quoi que ce soit.
Passation, puis mise en service
Une période de doublure définie avec celui qui détient aujourd’hui la connaissance, puis nous prenons la file. Si plus personne ne détient la connaissance, nous commençons plutôt par la revue des risques.
Sous votre nom, si tel est le dispositif
Le support est généralement la partie la plus visible d’un service managé, et c’est donc aussi là que la marque blanche compte le plus. Nos ingénieurs peuvent travailler depuis des boîtes mail et des comptes que vous émettez, répondre dans votre système de tickets et rédiger des rapports d’incident que vous transférez tels quels ; votre client traite avec vous tout au long. Le développement en marque blanche explique comment cela s’organise, et cela s’applique au support exactement de la même façon.
Comment le support est tarifé
Par personne, au mois, afin que votre propre coût soit prévisible et que vous puissiez tarifer un contrat de support à votre client en vous appuyant dessus. Chacun saisit son temps dans notre propre portail, vous voyez les heures tout au long du mois, et les mêmes chiffres produisent la facture : il existe ainsi une seule trace sur laquelle les deux parties se réconcilient.
Lorsque le support s’ajoute à du développement neuf, les deux forment en général un seul pod de delivery plutôt que deux contrats, de sorte que les semaines calmes d’un côté paient les semaines chargées de l’autre.
Questions sur les dispositifs de support
Que couvre le support applicatif géré ?
Maintenir en état de marche des logiciels déjà en production : trier ce qui arrive dans la file, reproduire et corriger les défauts, répondre aux questions techniques que le premier niveau ne peut pas traiter, livrer des correctifs, tenir à jour les dépendances et les versions de plateforme, surveiller les alertes et gérer les incidents quand quelque chose tombe en panne. C’est du travail de deuxième et de troisième niveau ; votre premier niveau reste où il est.
Travaillez-vous selon notre SLA ?
Oui. Nous ne publions pas d’objectifs de réponse et de résolution, car un chiffre inventé avant de connaître votre système ne vaut rien. Nous lisons le SLA que vous devez déjà à votre client, nous vous disons honnêtement quelles parties nous pouvons porter et quelle couverture cela demanderait, puis nous nous y engageons par écrit.
Pouvez-vous assurer une couverture hors heures ouvrées ou des astreintes ?
Oui. La couverture hors heures ouvrées et les astreintes sont convenues dès le départ, inscrites dans les conditions de support et assurées par des personnes dont les horaires y correspondent, de sorte qu’un incident de nuit atteint quelqu’un en poste et non quelqu’un qu’on réveille.
Pouvez-vous assurer le support d’un système que vous n’avez pas développé ?
C’est le cas normal. Neuf reprises à ce jour, dont la plus ancienne porte sur un code écrit en 2008. Le support d’un système hérité commence par une revue en lecture seule et une liste écrite de risques classés par impact sur la production, de sorte que les premières semaines servent à comprendre de quoi vous êtes réellement responsable plutôt qu’à deviner sous pression.
Les personnes qui assurent le support du système le feront-elles aussi évoluer ?
Oui, et c’est tout l’intérêt. Les ingénieurs du support sont des ingénieurs, pas un niveau distinct qui ne fait que clôturer des tickets : un incident récurrent peut donc être corrigé à sa cause au lieu d’être redémarré chaque lundi. Quand vous avez chez nous à la fois un flux de développement et un flux de support, les deux partagent les revues de code et les décisions d’architecture.
Comment le support est-il facturé ?
Par personne et par mois, afin que votre propre coût soit prévisible et que vous puissiez chiffrer un contrat de support auprès de votre client à partir de lui. Les heures sont enregistrées dans notre portail et visibles pour vous tout au long du mois, et les mêmes chiffres produisent la facture : il y a donc une seule source pour les deux parties.
Vous avez des systèmes à maintenir en fonctionnement ?
Indiquez-nous quels sont les systèmes, ce que promet votre SLA et où le support vous fait mal aujourd’hui. Nous le lirons et vous dirons quelles parties nous pouvons porter, y compris celles que nous ne pouvons pas.