Rappel : Charte du Groupe Administration Système

De manière générale, les demandes énoncées ci-dessous visent à maximiser la continuité des services :

• par la minimisation du coût de maintenance ultérieure ;
• par la minimisation de l'impact de chaque élément sur l'ensemble de l'infra ;
• par la maximisation de la diffusion de la connaissance nécessaire à la maintenance du service.

• Documentée
• ipv6 déployé ;
• firewallée ;
• monitorée ;
• backupée.

• Documenté, avec un point d'entrée ici : https://admin.chapril.org/doku.php?id=admin#documentation_des_services_utilisateurs ;
• Monitoré ;
• Backupé (en particulier, écrire un hook si nécessaire) ;
• ML sympa pour le support dédié au projet
• projet sur agir.april.org dédié au projet :
  • sous projet de https://agir.april.org/projects/chapril ;
  • dont les membres héritent du projet parent ;
• ajout du service sur https://www.chapril.org/-services-.html ;
• Au moins deux admins savent intervenir dessus ;

Par ailleurs :

• Dans l'hypothèse ou le service est installable via apt, il faut motiver dans la doc le choix éventuel de ne pas passer par cette procédure.
• Dans l'hypothèse où le service est installé sur plusieurs machines, il faut motiver le choix de ne pas passer par un paquet déployé par apt depuis l'infrastructure chapril.

Dans l'idéal, une panne est réparée lorsqu'elle est :

• diagnostiquée
• associée a un ticket dans redmine
• assignée a quelqu'un
• un correctif est décrit dans le ticket
• une alerte de monitoring (nouvelle si besoin) correspond au problème
• le correctif est appliqué
• l'alerte de monitoring valide que le problème est corrigé

Lorsque c'est pertinent, il faut encourager la remontée upstream du correctif.