Aller au contenu
Platform Docs

Entretien des Équipements

Un entretien approprié de votre infrastructure de gestion d’abonnements et de vos outils de développement est essentiel pour des performances optimales et une fiabilité. Ce guide couvre les meilleures pratiques pour maintenir votre intégration ToroSachi et les systèmes connexes.

Assurez-vous que votre infrastructure répond à ces exigences minimales :

  • CPU : 2+ cœurs pour les environnements de production
  • RAM : 4 Go minimum, 8 Go recommandés
  • Stockage : SSD recommandé pour les opérations de base de données
  • Réseau : Connexion Internet stable avec 99,9% de disponibilité
  • SSL : Certificat SSL valide pour tous les points de terminaison

Vérifications Quotidiennes :

  • Temps de réponse API < 500ms
  • Taux de succès de livraison webhook > 99%
  • Santé du pool de connexions base de données
  • Validité du certificat SSL
  • Tailles et rotation des fichiers journaux

Maintenance Hebdomadaire :

  • Installation des mises à jour de sécurité
  • Optimisation et nettoyage de la base de données
  • Analyse et archivage des journaux
  • Révision des métriques de performance
  • Vérification des sauvegardes

Révisions Mensuelles :

  • Évaluation de la planification de capacité
  • Audit de sécurité et scan de vulnérabilités
  • Tests de récupération après sinistre
  • Analyse des tendances de performance
  • Révision de l’optimisation des coûts

Pour les bases de données PostgreSQL stockant les données d’abonnement :

-- Requêtes de maintenance hebdomadaires
VACUUM ANALYZE subscriptions;
VACUUM ANALYZE payments;
VACUUM ANALYZE customers;
-- Maintenance mensuelle des index
REINDEX INDEX idx_subscriptions_status;
REINDEX INDEX idx_payments_created_at;
-- Vérifier la taille de la base de données
SELECT
schemaname,
tablename,
pg_size_pretty(pg_total_relation_size(tablename::text)) as size
FROM pg_tables
WHERE schemaname = 'public'
ORDER BY pg_total_relation_size(tablename::text) DESC;
#!/bin/bash
# Script de sauvegarde quotidienne
DB_NAME="torosachi_prod"
BACKUP_DIR="/backups/database"
DATE=$(date +%Y%m%d_%H%M%S)
# Créer une sauvegarde
pg_dump $DB_NAME > "$BACKUP_DIR/backup_$DATE.sql"
# Compresser la sauvegarde
gzip "$BACKUP_DIR/backup_$DATE.sql"
# Supprimer les sauvegardes de plus de 30 jours
find $BACKUP_DIR -name "backup_*.sql.gz" -mtime +30 -delete
# Vérifier l'intégrité de la sauvegarde
gunzip -t "$BACKUP_DIR/backup_$DATE.sql.gz"
if [ $? -eq 0 ]; then
echo "Sauvegarde réussie : backup_$DATE.sql.gz"
else
echo "Échec de la vérification de la sauvegarde !"
exit 1
fi
  • Implémentez un backoff exponentiel pour les tentatives
  • Mettez en cache les données fréquemment consultées
  • Utilisez les opérations en lot lorsque disponibles
  • Surveillez les en-têtes de limite de taux
// Client HTTP conscient des limites de taux
class ToroSachiClient {
constructor(apiKey) {
this.apiKey = apiKey;
this.rateLimitRemaining = 1000;
this.rateLimitReset = Date.now();
}
async makeRequest(endpoint, options = {}) {
// Vérifier la limite de taux
if (this.rateLimitRemaining <= 10 && Date.now() < this.rateLimitReset) {
const waitTime = this.rateLimitReset - Date.now();
await new Promise(resolve => setTimeout(resolve, waitTime));
}
const response = await fetch(`https://api.torosachi.com/v1${endpoint}`, {
...options,
headers: {
'Authorization': `Bearer ${this.apiKey}`,
'Content-Type': 'application/json',
...options.headers
}
});
// Mettre à jour les informations de limite de taux
this.rateLimitRemaining = parseInt(response.headers.get('X-RateLimit-Remaining'));
this.rateLimitReset = parseInt(response.headers.get('X-RateLimit-Reset')) * 1000;
return response;
}
}
Fenêtre de terminal
# Nettoyage régulier
git gc --aggressive --prune=now
git remote prune origin
# Supprimer les branches fusionnées
git branch --merged | grep -v "\*\|main\|master" | xargs -n 1 git branch -d
# Mettre à jour les sous-modules
git submodule update --remote --merge
# Vérifier l'intégrité du dépôt
git fsck --full
  • Supprimer rapidement les branches de fonctionnalités fusionnées
  • Utiliser des messages de commit conventionnels
  • Rebaser régulièrement les branches de longue durée
  • Écraser les commits avant de fusionner vers main
#!/bin/bash
# Script de rotation mensuelle des clés API
# Générer une nouvelle clé API
NEW_KEY=$(curl -X POST https://api.torosachi.com/v1/keys \
-H "Authorization: Bearer $CURRENT_KEY" \
-H "Content-Type: application/json" \
-d '{"name": "Production Key '$(date +%Y%m)'"}')
# Mettre à jour les variables d'environnement
echo "TOROSACHI_API_KEY=$NEW_KEY" > .env.new
# Tester la nouvelle clé
if curl -f https://api.torosachi.com/v1/account \
-H "Authorization: Bearer $NEW_KEY" > /dev/null 2>&1; then
mv .env.new .env
echo "Clé API rotée avec succès"
# Révoquer l'ancienne clé après une période de grâce
sleep 300
curl -X DELETE https://api.torosachi.com/v1/keys/$OLD_KEY_ID \
-H "Authorization: Bearer $NEW_KEY"
else
echo "Test de la nouvelle clé API échoué"
rm .env.new
exit 1
fi
-- Identifier les requêtes lentes
SELECT
query,
mean_time,
calls,
total_time
FROM pg_stat_statements
ORDER BY mean_time DESC
LIMIT 10;
-- Créer les index nécessaires
CREATE INDEX CONCURRENTLY idx_subscriptions_customer_status
ON subscriptions(customer_id, status)
WHERE status IN ('active', 'trialing');
Fenêtre de terminal
# Commandes de maintenance Redis
redis-cli INFO memory
redis-cli INFO stats
# Effacer les clés expirées
redis-cli SCAN 0 MATCH "expired:*" | xargs redis-cli DEL
# Surveiller l'expiration des clés
redis-cli --latency-history -i 1
# Optimiser l'utilisation de la mémoire
redis-cli CONFIG SET maxmemory-policy allkeys-lru
app.get('/health', async (req, res) => {
const health = {
status: 'healthy',
timestamp: new Date().toISOString(),
checks: {}
};
try {
// Connectivité de la base de données
const dbResult = await db.query('SELECT 1');
health.checks.database = { status: 'healthy', responseTime: dbResult.duration };
// Connectivité API externe
const apiStart = Date.now();
await fetch('https://api.torosachi.com/v1/health');
health.checks.externalAPI = { status: 'healthy', responseTime: Date.now() - apiStart };
res.status(200).json(health);
} catch (error) {
health.status = 'unhealthy';
health.error = error.message;
res.status(503).json(health);
}
});
#!/bin/bash
# Test mensuel de restauration de sauvegarde
TEST_DB="torosachi_test_restore"
BACKUP_FILE="/backups/database/latest.sql.gz"
# Créer une base de données de test
createdb $TEST_DB
# Restaurer à partir de la sauvegarde
gunzip -c $BACKUP_FILE | psql $TEST_DB
# Vérifier l'intégrité des données
RECORD_COUNT=$(psql $TEST_DB -t -c "SELECT COUNT(*) FROM subscriptions")
EXPECTED_COUNT=1000 # Ajuster selon vos données
if [ $RECORD_COUNT -ge $EXPECTED_COUNT ]; then
echo "Test de restauration de sauvegarde réussi : $RECORD_COUNT enregistrements trouvés"
else
echo "Test de restauration de sauvegarde échoué : seulement $RECORD_COUNT enregistrements trouvés"
exit 1
fi
# Nettoyage
dropdb $TEST_DB

Une maintenance régulière est la clé de systèmes de gestion d’abonnements fiables. Révisez ce guide mensuellement et mettez à jour les procédures à mesure que votre infrastructure évolue.