Audit des workflows Dynatrace : automatisation en échec ou jamais déclenchée

Deux contrôles sur les workflows AutomationEngine — historique d’exécution et taux d’échec, et ceux dont le déclencheur ne correspond plus à rien.

Réserver un audit gratuit Les 71 contrôles

Ce que ces contrôles lisent

Historique d’exécution et d’échec

Chaque workflow, sa dernière exécution, et son taux de réussite récent.

Déclencheurs inatteignables

Les workflows dont le déclencheur référence une entité, un tag ou un profil qui n’existe plus.

Pourquoi c’est important

Une automatisation qui échoue bruyamment est corrigée. Une automatisation qui échoue en silence inspire confiance, ce qui est pire : l’étape du runbook qui dit « le workflow s’en charge » est toujours dans le runbook, et le workflow est en erreur depuis qu’un tag a été renommé en mars.

Les contrôles lisent l’historique d’exécution et la configuration des déclencheurs. Un workflow qui n’a jamais tourné depuis sa création, c’est généralement un déclencheur qui ne peut pas correspondre ; un workflow qui tourne et échoue, c’est généralement un identifiant d’intégration. Le constat dit lequel des deux vous avez, workflow par workflow, avec la dernière exécution réussie.

Ce domaine est petit — deux contrôles — et c’est fréquemment celui qui produit le constat le plus immédiatement exploitable, parce qu’un workflow cassé a un propriétaire et une correction qui se mesure en minutes.

Les questions qu’on nous pose sur ce domaine

L’audit exécute-t-il des workflows ?

Non. Il lit leur configuration et leurs enregistrements d’exécution. Déclencher un workflow pourrait alerter quelqu’un ou modifier quelque chose, c’est-à-dire exactement ce qu’un audit read-only ne doit pas faire.

Nous avons très peu d’automatisation — ce domaine est-il pertinent ?

Alors il prend deux contrôles et le rapporte, ce qui est utile à avoir par écrit. L’audit déclare honnêtement « non applicable » plutôt que de fabriquer des constats pour remplir une section.

Les autres domaines d’audit

Dix-neuf domaines, 71 contrôles, une exécution en read-only. Chaque domaine a sa page.

FinOps Où part l’argent, et ce qui est récupérable Kubernetes Couverture des clusters, versions, échecs récurrents Alerting Si un incident atteindrait réellement un humain Audit log Qui a changé quoi, quand, et hors heures ouvrées Coverage Ce qui est surveillé, et ce qui en a seulement l’air RUM Portée du monitoring des utilisateurs réels et réglages de confidentialité Grail Buckets, retention, coût de stockage annualisé Pipelines Traitement à l’ingestion, masquage, règles de rejet Synthetic Moniteurs Synthetic qui passent, échouent ou ne tournent jamais Topology Qualité de la détection d’entités et explosion du nombre d’entités OpenTelemetry Sources OTel et double instrumentation Security Portées des tokens, expiration, identifiants dormants Workflows Automatisations qui échouent ou ne se déclenchent jamais Bizevents Hygiène des fournisseurs d’événements métier Dashboards Inventaire des dashboards Davis Taux d’attribution de cause racine OpenPipeline Résolution des routes et des pipelines SLO Définitions de SLO qui cassent à la redétection Tagging Convention de tagging des environnements

Voyez ce que ce domaine trouve sur votre propre tenant.

Une exécution en read-only couvre les dix-neuf domaines. Vous gardez le rapport dans tous les cas.

Réserver un audit gratuit Voir comment fonctionne AudiTrace

Découvrez ce que votre Obervability fait réellement.

Un audit prend une exécution. Les constats prennent une réunion. Ce que vous en faites vous appartient.

Experts Dynatrace certifiés

Envoyer

Obervability

Implémentation, services managés et support Dynatrace. Chaque constat arrive avec la source qui le sous-tend.

Services

Services AudiTrace Étude de cas

Guides

Audit Dynatrace Optimisation des coûts Dynatrace Étude de cas Articles

Nous joindre

Contact hello@obzervability.com

Confidentialité Conditions d’utilisation Accessibilité