Gestion des incidents pour les charges de travail SaaS sur Azure
Les fournisseurs de logiciels indépendants (ISV) pour les solutions SaaS (Software as a Service) doivent exploiter la solution pour leurs clients. Cela nécessite une configuration et une culture organisationnelles qui gèrent des situations de production inattendues en douceur. En tant qu’architecte, vous devez concevoir des processus et des outils de gestion en conséquence.
Cet article vous guide dans l’alignement de la culture, des processus et des outils de votre organisation pour prendre en charge la gestion des incidents d’une solution SaaS de production.
Comprendre vos responsabilités en tant que fournisseur de services
L’exploitation d’une solution SaaS signifie que vous êtes le service informatique et opérationnel 24x7 de vos clients. Vous devez être préparé avec le personnel, la culture, les processus et les outils appropriés.
Considérations sur la conception
Prenez la responsabilité de la prise en charge de 24 x 7 x 365. L’exploitation d’une solution SaaS nécessite que votre organisation soit toujours préparée pour la réponse aux incidents. Cette préparation inclut toujours la disponibilité des membres de l’équipe, car les incidents peuvent se produire en dehors des heures d’ouverture.
La prise en charge des sites en direct implique une surveillance en temps réel et une réponse aux incidents qui affectent la disponibilité du système, la sécurité, les performances ou le déploiement. Vous ou vos clients pouvez détecter ces incidents. Pour gérer ces incidents, vous avez besoin de compétences spécifiques, notamment la possibilité d’analyser et de résoudre les problèmes sous pression.
Le support en direct peut être stressant et il est important de soutenir les membres de votre équipe. Si l’équipe est nouvelle à cette responsabilité, planifiez attentivement la transition. Résolvez les préoccupations relatives aux tâches, à la rémunération et à la gestion de l’indisponibilité pendant les incidents.
Risque : gestion des compétences et des attentes. Tous les ingénieurs ne sont pas adaptés à un rôle de prise en charge 24x7x365. Lors de la transition d’une équipe préexistante pour prendre en charge une solution SaaS, assurez-vous que les attentes appropriées sont définies et que les opportunités d’éducation sont fournies.
Institutez une culture de site en direct. Tenez compte de la façon dont vous gérez les cas de support et les incidents et la façon dont les escalades se produisent. L’objectif est de s’assurer que les membres de l’équipe comprennent leurs responsabilités et ont les compétences et les outils nécessaires pour gérer les incidents.
Les start-ups et les petites organisations peuvent avoir un plan léger pour les problèmes de site en direct. Les ingénieurs peuvent initialement servir de support de première ligne en répondant aux cas de support client. Les organisations matures ou les fournisseurs SaaS avec des clients d’entreprise ont besoin d’un support plus structuré et d’équipes dédiées.
Compromis : Excellence opérationnelle et coût. La gestion des événements en direct peut nuire au temps de développement pour les nouvelles fonctionnalités ou les correctifs de bogues. Si la vitesse de développement est une préoccupation, envisagez d’embaucher des ressources dédiées en direct.
Recommandations de conception
Recommandation | Avantage |
---|---|
Présenter une équipe de première ligne pour gérer les cas de support. Pour les cas complexes, cette équipe recueille les informations dont l’équipe d’ingénierie a besoin pour son examen. Un fournisseur peut servir d’équipe de support technique de première ligne et effectuer une analyse initiale des problèmes et résoudre des problèmes simples. |
Vous évitez de surcharger l’équipe d’ingénierie avec des responsabilités de gestion des incidents et de gérer les interruptions de leurs tâches régulières. |
Investissez dans une fonction d’appel pour que les ingénieurs gèrent des cas complexes, examinent et prennent des mesures. Si possible, faites pivoter les responsabilités d’appel entre les membres de l’équipe, chaque ingénieur étant en cours d’appel pendant quelques jours à la fois. |
Avec des responsabilités et des chemins d’escalade bien définis, vous pouvez rapidement identifier et résoudre les problèmes sans perturber votre workflow d’ingénierie. |
Procurez des outils spécialisés pour la gestion des incidents. Assurez-vous que tous les répondants ont accès à ces outils et comprennent comment utiliser ces outils efficacement. Sélectionnez des outils capables de surveiller l’état du système, de suivre les problèmes signalés par le client, d’identifier les problèmes, de passer aux ingénieurs à l’appel, de gérer les ingénieurs non répondants et d’apporter des modifications en production. |
Disposer des outils appropriés permet à votre équipe d’appel d’identifier et de résoudre rapidement les incidents tout en conservant la sécurité et le contrôle opérationnel. |
Améliorez vos opérations de supervision, de déploiements, de mises à jour et d’autres opérations de gestion régulières. | En investissant dans la maturité opérationnelle, vous réduisez la probabilité de problèmes de site en direct. Si des problèmes se produisent, le fait d’avoir des opérations bien définies en place raccourcit le temps de résolution. |
Définir votre plan de réponse
Reconnaissez que les incidents sont inévitables et préparez-les en définissant un plan de réponse aux incidents. Cette approche proactive vous empêche d’avoir à élaborer une stratégie de réponse lors de votre premier incident.
Planifiez les incidents majeurs, ce qui affecte généralement la capacité de vos clients à utiliser votre service. Cette préparation permet de réduire le stress et la complexité lorsque vous gérez les incidents au fur et à mesure qu’ils se produisent.
Considérations sur la conception
Définissez le chemin d’escalade. Assurez-vous que les équipes comprennent le processus d’escalade pour les tâches de support. Dans de nombreuses solutions SaaS, les clients contactent une équipe de support technique de première ligne, qui communique ensuite avec l’équipe d’ingénierie. Assurez-vous que les clients savent qui interagir avec et pourquoi ils ne doivent pas contourner ces processus. Assurez-vous également que votre équipe d’ingénierie sait quand et comment demander de l’aide auprès des fournisseurs, y compris les équipes de support technique chez Microsoft.
Définissez les niveaux de gravité. Les différents incidents varient en importance pour vous et vos clients. La façon dont vous gérez une panne de production majeure diffère de la façon dont vous résolvez un bogue mineur. Définissez les niveaux de gravité en fonction de l’impact du client et définissez les attentes et les chronologies appropriées pour chaque niveau.
Documentez les informations dont vous avez besoin pour le triage. La mise à jour de la documentation est essentielle pour une réponse efficace aux incidents. Cette documentation inclut la disposition architecturale du système, les détails au niveau des composants, les propriétaires et les contacts clés. Des informations inexactes ou obsolètes peuvent entraîner la perte de temps précieux de l’équipe de réponse aux incidents pour déterminer les opérations du système, les responsabilités et l’impact potentiel de l’incident.
Planifiez une communication efficace avec les clients. La fourniture de mises à jour d’état est essentielle dans la gestion des incidents. Les mises à jour d’état aident vos clients à comprendre la nature d’un incident et à réduire le volume de cas de support des clients qui rencontrent des problèmes similaires.
Recommandations de conception
Recommandation | Avantage |
---|---|
Fournissez un processus clair de création de rapports d’incidents, comme l’ouverture d’un cas de support auprès de votre équipe de support de première ligne, à vos clients. | Vous assurez la cohérence de la façon dont vous découvrez et répondez aux incidents, ce qui réduit le temps de résolution et empêche les informations d’être perdues ou ignorées. |
Documentez la disposition architecturale, les détails au niveau du composant, la confidentialité ou les classifications de sécurité, les propriétaires et les contacts clés. | L’équipe de triage dispose de l’information facilement disponible et peut se concentrer sur les enquêtes et l’évaluation de l’impact. |
Assurez-vous que votre équipe de réponse aux incidents peut accéder aux ressources et systèmes nécessaires, tels que les journaux. Ils doivent également être en mesure d’apporter des modifications de production par le biais d’un processus sécurisé et contrôlé. | Vous restaurez les opérations plus rapidement en vous assurant que votre équipe ne perd pas de temps. |
Utilisez une page d’état commercial au lieu de créer votre propre page. | Gagnez du temps à l’aide d’une page d’état commercial. Une page d’état hébergée par une autre organisation reste également accessible aux clients lors d’une panne sur votre système. |
Gérer les incidents de manière méthode
L’adhésion au plan défini est essentielle pour éviter l’improvisation pendant le temps de réponse. Cette approche permet de réduire le stress et la complexité de la gestion de ces situations.
Considérations sur la conception
Affectez la gravité de l’incident. Utilisez votre plan de réponse aux incidents pour déterminer la gravité de l’incident. Les clients sont souvent frustrés pendant les incidents. Il est important que vous compreniez l’impact qu’ils voient afin que vous puissiez hiérarchiser. Communiquez clairement la gravité de l’incident afin que les clients aient des attentes réalistes.
Restez calme et pensez clairement. Les incidents peuvent être stressants et ambigus, avec plusieurs parties prenantes exigeant l’attention. Avoir un processus clair pour qui prend la tête dans un incident. Les incidents de triage aussi bien que possible tout en reconnaissant que vous devrez peut-être utiliser des informations incorrectes. Essayez de rester en contrôle de la situation.
Les dirigeants de l’organisation peuvent aider en assurant la protection des membres de l’équipe qui examinent ou atténuent activement un incident.
Communiquez l’état à vos clients. Mettez à jour la page d’état pour publier suffisamment d’informations. Communiquez rapidement et fournissez les informations nécessaires, telles que les temps de résolution estimés. Donnez aux clients des mises à jour fréquentes pour maintenir leur confiance.
Recommandations de conception
Recommandation | Avantage |
---|---|
Pendant un incident, hiérarchiser la récupération par rapport à la découverte. Lorsqu’un incident se produit, hiérarchiser les opérations de restauration rapidement pour réduire les interruptions à vos clients. |
Vous pouvez peut-être récupérer en effectuant un routage autour d’un composant affecté ou en supprimant une mise à jour, même si vous ne comprenez pas encore ce qui a provoqué le problème. |
Fournissez des mises à jour rapides, claires et fréquentes pendant les pannes. | Vous pouvez inculquer la confiance des clients et réduire le fardeau de votre équipe de support de première ligne. |
Désignez un responsable des communications pendant un incident actif. Ce responsable peut être une seule personne, ou vous pouvez faire pivoter la responsabilité entre les membres de l’équipe entre les incidents. | En ayant une voix pour votre équipe d’ingénierie, vous centralisons les conversations et réduisez les distractions aux autres membres de l’équipe. Vous empêchez également les informations conflictuelles d’atteindre les clients ou les parties prenantes lors d’un incident chaotique. |
Vérifiez que vous disposez d’un plan de support stratégique pour les fournisseurs tels que Microsoft. | Si une panne se produit, vous avez besoin de communications réactives avec vos fournisseurs de plateforme comme Microsoft pour vous aider à déterminer où se trouve un problème et à raccourcir la durée de la panne. |
Effectuer des révisions post-incident
Après avoir récupéré un incident, passez en revue et analysez ce qui s’est passé pour en savoir plus. Implémentez des actions de correction, qui peuvent inclure des modifications techniques, des ajustements de processus ou une formation plus grande.
Considérations sur la conception
Découvrez les incidents. Les pannes offrent des opportunités d’apprentissage précieuses. Effectuez des examens approfondis après les incidents afin d’identifier les leçons et d’implémenter des améliorations. Les incidents majeurs ont souvent plusieurs causes. Déterminez si d’autres couches de votre solution, telles que les processus opérationnels, peuvent empêcher ou détecter le problème avant de remonter. En outre, recherchez des modèles similaires ailleurs dans votre solution qui peuvent également être à risque du même problème.
Communiquez avec vos clients. De nombreux éditeurs de logiciels indépendants fournissent des communications post-incident, en particulier pour les clients d’entreprise qui attendent des mises à jour de haute qualité. Soyez transparent et fournissez suffisamment d’informations aux clients pour comprendre les étapes de problème et d’atténuation. Toutefois, pour maintenir la sécurité et l’intégrité, évitez de partager des détails internes excessifs sur l’architecture ou les composants de votre solution.
Recommandations de conception
Recommandation | Avantage |
---|---|
Créez un processus pour effectuer des révisions post-incident internes. Concentrez-vous sur l’identification des raisons qui ont contribué au problème. Tenez compte des causes techniques, de la façon dont vos processus ont pu contribuer à la panne et de la façon dont vous avez répondu à l’incident. |
Les révisions post-incident internes vous aident à découvrir les pannes de production et à réduire le risque de problèmes similaires qui se produisent à nouveau. |
Créez un plan structuré pour traiter tous les éléments qui ont besoin de correction. Incluez une responsabilité claire et des chronologies. | La responsabilité claire vous permet de vous assurer que chaque rôle répond à ses attentes fonctionnelles, améliore la clarté et permet de créer des rapports transparents aux niveaux souhaités. |
Publiez des avis post-incidents côté client. Fournissez aux clients suffisamment de détails pour comprendre les étapes de problème et d’atténuation sans révéler les détails internes ou l’architecture système inutiles. Les communications post-incident doivent toujours être écrites et publiées par les humains. Les parties prenantes techniques et non techniques doivent examiner les communications à des fins d’exactitude et de clarté. |
Cette approche permet de maintenir la confiance des clients et de les assurer que vous avez appris de l’incident et de résoudre les problèmes identifiés. |
Étape suivante
Après avoir examiné les zones de conception, passez à l’outil d’évaluation pour évaluer votre conception.