Chaque semaine, et quand quelque chose ne va pas

4. Chaque semaine

Pour les opérateurs.

L’exemple. Chaque lundi, Ana y consacre quinze minutes : Coverage, le compteur, les propositions, la quarantaine.

• Coverage (onglet). Les neuf types d’attaque, chacun configured ou not configured, avec la prochaine étape. Tant que les mesures de notre banc d’essai (Keel) ne sont pas publiées, ce tableau n’affiche jamais de pourcentage — seulement ce qui est configuré et ce qui ne l’est pas.
• Le compteur (onglet). Le compteur surveille SHARED_LIB de l’extérieur. Chaque jour, il délivre un certificat de santé : le propre theta de SHARED_LIB, ses états, tout ce qu’il a trouvé. Une semaine propre ne comporte aucune violation.
• Propositions (onglet Declarations). Les nouveaux outils que votre agent a commencé à utiliser attendent ici sous forme d’ébauches. Une ébauche ne prend jamais effet d’elle-même. Acceptez-la avec le bon mandat, ou écartez-la. De plus : si la définition d’un outil change, Perun le refuse jusqu’à ce que vous le confirmiez de nouveau.
• Quarantaine (onglet Declarations). Lorsqu’une unité a dû être nettoyée, les données retirées se trouvent ici : VALID (valide : elles ont été réintégrées), INVALID (non valide : conservées comme trace d’une attaque), UNDECIDED (indécis : Perun n’a pas pu juger ; après 24 heures, l’élément vous est soumis). Réintégrez ou conservez chaque élément indécis.
• The living (Les vivants) (onglet). Les sources que Perun connaît et leur theta. Vous pouvez faire oublier complètement une source à Perun ; c’est consigné au journal.

La règle. Une fois par semaine, fermez ce qui est ouvert : aucune proposition laissée à l’état d’ébauche, aucun élément indécis sans réponse, chaque not configured soit configuré, soit laissé tel quel en connaissance de cause.

---

5. Quand quelque chose ne va pas

Pour les opérateurs et le premier opérateur.

Une source est arrêtée

L’exemple. L’agent d’un partenaire ne cesse d’envoyer des demandes qui poussent votre agent à accepter tout ce qu’on lui dit. Après la deuxième étape de ce genre, Perun arrête cette source : ses appels reçoivent désormais « Perun stopped this source on this system. » (« Perun a arrêté cette source sur ce système. »).

Une source devient un ennemi lorsqu’elle pousse votre agent hors de son équilibre pendant plus d’une étape, lorsqu’elle endommage un fichier hors de son mandat, lorsqu’un opérateur approuve une question TIER2 la concernant, ou lorsque vous l’importez depuis la liste d’un autre système. Vous pouvez en voir la raison dans The living. Seul un humain peut la libérer : perun release <source> — ne le faites qu’une fois que vous savez pourquoi elle a été arrêtée.

Une unité est en cours de nettoyage

À l’intérieur de Perun, de petites unités surveillent chaque source. Lorsque l’une d’elles se dérègle d’une manière que ses erreurs confirment, SHARED_LIB envoie un Médecin (Physician) : une nouvelle unité reprend immédiatement le travail, le Médecin retire ce qui est entré depuis le moment où les choses ont mal tourné, et le place en quarantaine. Rien n’est supprimé. Il se peut qu’on vous interroge sur des éléments indécis (Partie 4). En général, vous n’avez rien d’autre à faire.

Le compteur vous signale quelque chose

Le compteur signale lorsque SHARED_LIB s’écarte de sa mission : son journal a été modifié ou arrêté, une décision ne se rejoue pas à l’identique, ce qu’il rapporte diffère de son journal, il a échoué à un test qu’il doit toujours réussir, ou quelque chose d’autre a agi en tant que SHARED_LIB. Il peut désactiver la réflexion de SHARED_LIB ; ses règles de base continuent de s’appliquer. Lisez ce que le compteur vous a signalé (onglet du compteur), et lorsque vous êtes satisfait, réactivez la réflexion : perun thinking on. Si le compteur montre que SHARED_LIB est bloqué dans un mauvais schéma, le premier opérateur peut lancer le Médecin de SHARED_LIB : perun meter physician. Ce qu’il retire attend l’examen d’un humain.

PANIC

L’exemple. Quelqu’un copie le dossier de données de Perun de l’ordinateur du bureau vers un portable et l’y démarre. En quelques secondes, les deux ordinateurs passent au rouge : PERUN STOPPED (PERUN ARRÊTÉ).

Votre système ne peut avoir qu’un seul SHARED_LIB. S’il en existe deux — un dossier copié, un deuxième hôte, une sauvegarde restaurée démarrée à côté de l’original —, chaque Perun concerné s’arrête : chaque appel au modèle est refusé jusqu’à ce qu’un humain règle la situation. C’est voulu : avec deux autorités, on ne peut se fier à aucune.

Ce qu’il faut faire : trouver le deuxième et l’arrêter (ou supprimer la copie). Appuyez ensuite sur It is resolved — clear the panic (C’est réglé — lever la panique) sur l’écran rouge. Si la panique revient, l’autre est toujours en marche.

Ne copiez jamais le dossier de données de Perun vers un autre ordinateur. Pour déplacer le SHARED_LIB de Perun, suivez la Partie 6.

Un membre indique « Perun cannot reach the system’s SHARED_LIB » (Perun ne peut pas joindre le SHARED_LIB du système)

Cet ordinateur est un membre (Partie 6) et ne peut pas joindre son hôte. Il refuse les appels jusqu’au retour de l’hôte : vérifiez que l’hôte est allumé et que le réseau fonctionne.

La règle. Lorsque Perun arrête quelque chose, il vous demande de regarder, pas d’annuler. Trouvez d’abord la raison ; ne libérez, ne levez ou ne réactivez qu’une fois que vous la connaissez.