Dezhurka : astreintes sur Telegram face à la fin d'Opsgenie

Fonctionnement

Dezhurka ne remplace pas la supervision. Il reçoit les alertes de Prometheus Alertmanager, Grafana Alerting ou Zabbix par webhook, chaque service disposant d'une clé d'intégration secrète. Il consulte le planning, prévient l'astreinte en cours par Telegram et par e-mail, et duplique l'incident dans le canal de l'équipe. Si personne n'appuie sur « Беру » (« Je prends ») en 5 minutes, il appelle la personne suivante, puis le responsable d'équipe ; après deux tours, la chronologie indique que l'escalade est épuisée.

Les alertes répétées portant la même clé forment un seul incident : l'empreinte des étiquettes pour Alertmanager, {EVENT.ID} pour Zabbix, ce qui apparie problème et résolution. Dès qu'un membre prend l'incident, tous les messages Telegram sont modifiés pour afficher qui s'en occupe.

Pensé pour les réseaux fermés

Le bot utilise le long polling via getUpdates plutôt qu'un webhook Telegram : seul un accès sortant vers api.telegram.org est requis, sans point HTTPS public. Seuls les comptes liés par un lien personnel signé par HMAC peuvent utiliser les boutons. Le panneau est protégé par authentification Basic et vérifie l'en-tête Origin sur les formulaires POST.

Le service repose sur Python 3.12, FastAPI et SQLAlchemy, avec SQLite ou Postgres, pour environ 2 000 lignes de code et 24 tests, dans un seul conteneur Docker. Tout tourne dans un processus unique avec un seul asyncio.Lock, choix délibéré pour éviter les doubles réveils ou les clics perdus. Personnes, plannings et politiques sont décrits en YAML, les secrets venant des variables d'environnement. Les remplacements se saisissent dans le panneau et priment sur la rotation.

Le code source est sur GitHub, avec un installateur de démonstration pour Ubuntu qui déploie en une commande Dezhurka, Prometheus, Alertmanager, Grafana et, en option, Zabbix. Les conditions d'utilisation figurent dans le fichier LICENSE du dépôt.