À première vue, ce sont deux mondes disjoints. Mais en pratique, ce n'est pas le cas.
Ce qui suit est un bref commentaire local sur le bon article, «Ne dors pas! Comment nous avons appris à reproduire les versions dans 12 000 guichets par nuit » en termes de système de surveillance de la qualité des mises à jour logicielles et d'utilisation de R dans cette tâche.
Il s'agit d'une continuation de publications antérieures .
Encore une fois, un peu sur les spécificités de la tâche.
- La mise à jour du logiciel a lieu dans une sélection aléatoire de caisses enregistreuses. Il y a juste une liste de mise à jour.
- La fenêtre de mise à jour est petite. Le processus de mise à jour commence la nuit et vers 6 h à 7 h, heure locale, tous les caisses devraient être déjà opérationnels.
- La méthodologie de surveillance est plus similaire à la technologie Netflix en termes de machines virtuelles sur la batterie de serveurs. Vous devez vous assurer rapidement que le caissier après la mise à niveau est prêt pour la vente. En cas de problème, nous n'avons pas le temps de le comprendre. Il est nécessaire de revenir rapidement à la version de travail précédente dans ce box-office, et les développeurs déjà hors ligne peuvent préparer le code.
- La conclusion sur la qualité de la mise à jour se fait selon les journaux de caisse. La conclusion n'est pas basée sur une métrique séparée, mais sur un ensemble d'états d'une machine à états finis implémentée par un logiciel de box-office. Le lancement d'une caisse est un processus qui se prolonge dans le temps, passant par une multitude de statuts et de conditions.
- Il est nécessaire, dans un mode proche du réel, de mettre à jour les statuts des caisses et de hiérarchiser les problèmes non seulement du point de vue d'une caisse séparée, mais aussi du point de vue de l'ensemble du magasin. Une caisse problématique dans un hypermarché est moins problématique qu'une caissière dans un magasin «près de la maison».
Aucune surveillance zabbix classique ne convient à de telles fins. Par conséquent, la solution a été construite sur la base du Business Monitoring System (BMS) mentionné dans l'article. Le système peut être trouvé plus en détail dans les documents du "# 5 Moscow R Meetup" . Dans les commentaires, vous trouverez des liens vers des présentations et des vidéos.
L'ensemble de la partie analytique, ainsi que le poste de travail, ont été assemblés sur la base de R + Shiny, qui sont inclus dans le bloc «count» BMS. En conséquence, la personne responsable de la mise à jour reçoit sur un écran un résumé complet des statuts, des «crochets ouvrants» sur demande et des invites pour hiérarchiser les actions.
Il ne s'agit pas de «révolutionnisme» et de «caractère unique», mais du fait qu'une telle tâche est élégamment et simplement clôturée par R.
Exemples de captures d'écran:
Article précédent - «Informatique reproductible en R. Comment séparer le code et les données?» .