Les usages typiques incluent le regroupement d'événements, la détection d'anomalies, l'inférence de dépendances, la prévision de capacité, les suggestions de cause probable, l'enrichissement de tickets et la remédiation recommandée ou automatisée. L'étiquette ne définit ni une architecture standard, ni une qualité de modèle, ni un niveau d'autonomie, ni une capacité de sécurité.
Un flux AIOps peut combiner métriques, journaux, traces, topologie, changements, incidents, enregistrements de service et données d'expérience utilisateur. Sa sortie doit entrer dans les processus établis de gestion de services et d'ingénierie avec des responsables nommés, une vérification, des contrôles d'accès, une gouvernance des changements et un retour des résultats, plutôt que de les contourner.
Points clés
Définir le but opérationnelRelier chaque cas d'usage à un résultat de service mesurable, des sources de données connues, un coût d'erreur acceptable, une autorité de réponse et une base de comparaison.
Ingénierer des entrées fiablesMaintenir la couverture de télémétrie, les horodatages, la propriété des services, les cartes de dépendances, le contexte de changement, la conservation, les protections de la vie privée et la protection contre les données manquantes ou manipulées.
Maîtriser l'actionSéparer observation, recommandation, approbation et exécution ; contraindre l'automatisation par la criticité du service ; préserver les journaux ; et tester le retour arrière, le fonctionnement dégradé et l'escalade.
Limite importanteUne corrélation ou une explication générée n'établit pas une cause profonde. La dérive, les trous de topologie, les défaillances partagées, un historique d'incidents biaisé, des entrées adverses ou des boucles de rétroaction peuvent produire des recommandations et une automatisation confiantes mais nuisibles.