Formations

Certaines pannes n'apparaissent que quand on agit comme un utilisateur : un formulaire de connexion qui refuse des identifiants valides, un tableau de bord qui s'affiche vide, un paiement qui renvoie une erreur après le panier. Un simple contrôle HTTP ne les voit pas.

Dans cette vidéo, vous créez un contrôle JavaScript dans SolidPing. Le script tourne dans un moteur isolé, charge une page de connexion, se connecte avec un compte de test et vérifie ce qu'affiche le tableau de bord. Vous verrez comment stocker le mot de passe comme secret chiffré, comment essayer le script avec « Run now » et comment une étape en échec apparaît dans le résultat.

Les contrôles JavaScript tournent une fois par période dans chaque région, ouvrent des incidents comme n'importe quel contrôle et notifient vos canaux.

Décrivez ce que vous voulez surveiller en langage courant et laissez SolidPing écrire le contrôle.

Dans cette vidéo, vous utilisez le moteur IA : vous écrivez une description d'une phrase, vous relisez le contrat d'assertions qu'il propose, puis vous le regardez explorer la page et tester un script en direct. Vous enregistrez le résultat comme un contrôle JavaScript normal. Ensuite, le script tourne sur les workers comme n'importe quel contrôle, sans appel à l'IA à chaque exécution.

Quand la cible change ses pages et que le script casse, SolidPing peut le réparer. Une réparation ne démarre que si le script lui-même a cassé (il ne trouve plus un champ ou une page) sur 3 exécutions d'affilée alors que le site répond, donc une vraie panne n'en déclenche jamais. L'IA réécrit le script avec le même contrat, et la nouvelle version doit réussir une exécution de vérification, ne contacter aucun nouvel hôte et rester capable de signaler une panne. Vous choisissez le mode sous « Quand le script dérive » : « Proposer une réparation » (par défaut) attend votre accord sur la page Historique du contrôle, « Réparer automatiquement » l'applique, résout l'incident à l'exécution suivante et vous envoie le diff par e-mail.

La fonctionnalité demande un fournisseur d'IA configuré sur le serveur. Sans lui, le bouton est masqué.

Les workers cloud ne peuvent pas atteindre une base de données sur un réseau privé, un hôte accessible seulement par VPN ou un segment isolé. Les emplacements privés règlent ce problème : vous faites tourner un agent SolidPing dans votre réseau, et il exécute les contrôles pour vous.

Dans cette vidéo, vous créez un emplacement privé, générez un jeton d'enrôlement à usage unique, démarrez un agent et lancez un contrôle depuis celui-ci. L'agent ouvre lui-même une connexion WebSocket sortante, donc aucun port entrant n'est nécessaire. Il peut seulement prendre des tâches et envoyer des résultats, et les secrets des contrôles réservés aux emplacements privés sont chiffrés avec les clés des agents : le serveur ne peut pas les déchiffrer.

Un contrôle TCP sur le port 3389 prouve seulement qu'un port est ouvert. Le contrôle RDP effectue la poignée de main Remote Desktop qui précède l'authentification : une réponse valide prouve que le service a vraiment traité la requête.

Dans cette vidéo, vous créez un contrôle RDP, vous le lancez, vous lisez le protocole de sécurité négocié (TLS, NLA, etc.) et la date d'expiration du certificat du serveur, puis vous arrêtez le service pour voir le contrôle passer en panne et un incident s'ouvrir. Aucun identifiant n'est nécessaire et aucune session n'est ouverte, donc vos journaux d'événements Windows ne se remplissent pas d'échecs d'authentification.

Les hôtes RDP sont en général privés : lancez le contrôle depuis un worker ou un agent privé qui peut les atteindre.

Le contrôle VNC parle le vrai protocole RFB : il lit la bannière, négocie une version et liste les méthodes d'authentification proposées par le serveur. Un serveur qui ne demande aucune authentification est marqué en panne par défaut, car un bureau ouvert est presque toujours une erreur.

Dans cette vidéo, vous lancez un contrôle limité à la poignée de main, puis vous ajoutez un mot de passe pour que le contrôle se connecte et remonte le nom et la taille du bureau, et enfin vous activez l'option de capture d'écran pour joindre une image du bureau au résultat.

Pendant une panne, le pire endroit pour chercher du contexte, c'est cinq messages éparpillés dans un canal. SolidPing garde un seul fil Slack par incident.

Dans cette vidéo, vous connectez Slack, rattachez un canal à un contrôle et voyez un incident s'ouvrir sous forme de message avec un bouton Acknowledge. Vous en prenez la charge depuis Slack, ajoutez un commentaire avec la commande slash de commentaire et voyez le retour à la normale publié dans le même fil. Les commentaires écrits dans le tableau de bord sont aussi publiés en réponse dans le fil.

Un planning d'astreinte répond à une question simple : qui est responsable en ce moment ?

Dans cette vidéo, vous créez une rotation hebdomadaire avec une heure de relève dans votre propre fuseau horaire, ajoutez trois personnes, voyez qui est d'astreinte maintenant et ensuite, ajoutez un remplacement pour couvrir un créneau et publiez le planning sous forme de flux iCal pour votre agenda. Les relèves suivent l'heure locale, donc le passage à l'heure d'été ne décale pas vos créneaux.

Alerter quelqu'un est facile. S'assurer que quelqu'un répond, c'est la partie difficile. Une politique d'escalade est une liste ordonnée d'étapes avec des délais, et chaque étape peut notifier plusieurs cibles en même temps : un utilisateur, un planning d'astreinte ou un canal.

Dans cette vidéo, vous construisez une politique en trois étapes (la personne d'astreinte, puis une personne nommée après dix minutes, puis le canal d'une équipe après vingt), vous la rattachez à un contrôle, déclenchez un incident et lisez la chronologie. Prendre l'incident en charge depuis le tableau de bord, Slack ou Telegram annule les étapes restantes.

Une page de statut dit à vos clients ce qui se passe, pour qu'ils arrêtent de vous le demander.

Dans cette vidéo, vous créez une page de statut, l'organisez en sections, ajoutez des composants et passez une section en ajout automatique (tous les contrôles, par label ou par groupe) pour que les nouveaux contrôles apparaissent sans intervention. Vous ouvrez ensuite la page publique, la voyez réagir quand un contrôle échoue et publiez une mise à jour d'incident.

L'ajout automatique sur une page publique est un choix de ce que vous rendez public : ne l'activez que pour les sections que vous acceptez de publier.

Une panne de base de données ne devrait pas réveiller quelqu'un quatre fois en pleine nuit.

Dans cette vidéo, vous déclarez des liens de dépendance entre contrôles. Un lien fort indique que la panne d'un parent provoque celle de ses enfants : les incidents des enfants apparaissent toujours dans la chronologie, mais n'alertent personne. Un lien faible enregistre seulement une corrélation, et l'incident alerte quand même. Vous verrez l'effet quand une base de données tombe, comment le regroupement fonctionne même quand le parent confirme sa panne en dernier, et ce qui se passe quand le parent revient.

Être disponible ne suffit pas. L'est-on assez ? Un SLO fixe un objectif, par exemple 99,9 % par mois, et SolidPing suit le budget d'erreur : combien d'échecs vous pouvez encore vous permettre, à quelle vitesse vous le consommez et quand il sera épuisé.

Dans cette vidéo, vous créez un objectif pour un contrôle, lisez la carte de statut (atteinte de l'objectif, budget consommé, restant, pastille d'état), comprenez le burn rate et la date d'épuisement prévue, et lisez le graphique de consommation. Les maintenances planifiées sont exclues par défaut, et vous pouvez recevoir ces chiffres par e-mail à intervalle régulier sous forme de rapport de disponibilité.

L'e-mail est le canal que tout le monde a déjà.

Dans cette vidéo, vous ajoutez un canal e-mail et vous le rattachez à un contrôle. Vous voyez l'e-mail d'incident quand un contrôle échoue, puis l'e-mail de résolution quand il redevient disponible : deux messages par incident, pas un par sonde en échec. Un incident supprimé à cause d'une dépendance en panne n'envoie rien. Enfin, vous planifiez un rapport hebdomadaire de disponibilité et vous lisez le résumé : disponibilité comparée à la période précédente, incidents et état de vos budgets d'erreur.