At first glance, these are two disjoint worlds. But in practice, this is not so.
The following is a short, local commentary on the good “Don't Sleep!” Article . How we learned to replicate releases at 12,000 box offices per night ” in terms of the system for monitoring the quality of software updates and the use of R in this task.
It is a continuation of previous publications .
Once again, a little about the specifics of the task.
- Software update takes place at a random selection of cash registers. There is just an update list.
- The window for updating is small. The update process begins at night and by ~ 6-7 a.m. local time, all cash desks should be already operational.
- The monitoring methodology is more similar to Netflix technology in terms of virtual machines on the farm. You need to quickly make sure that the cashier after the upgrade is ready for sales. If something went wrong, there’s no time to figure it out. It is necessary to quickly roll back to the previous working release at this box office, and already offline developers can prepare the code.
- The conclusion about the quality of the update is made according to the cash register logs. The conclusion is based not on a separate metric, but on a set of states of a finite state machine implemented by box office software. Cash desk launch is a process that is extended in time, passing through a mass of various statuses and conditions.
- It is necessary, in a mode close to the real one, to update the statuses of cash desks and prioritize problems not only from the point of view of a separate cash desk, but also from the point of view of the entire store. One problematic cash desk in a hypermarket is less problematic than one cashier at a “near the house” store.
No classic zabbix monitoring is suitable for such purposes. Therefore, the solution was built on the basis of the Business Monitoring System (BMS) referred to in the article. The System can be found in more detail in the materials of "# 5 Moscow R Meetup" . There in the comments are links to presentations and videos.
The entire analytical part, as well as the workstation, was assembled on the basis of R + Shiny, which are included in the BMS “count” block. As a result, the person responsible for the update receives on one screen a full summary of the statuses, “opening brackets” upon request, and tips for prioritizing actions.
This is not about “revolutionism” and “uniqueness”, but about the fact that such a task is elegantly and simply closed by R.
Examples of screenshots:
Previous post - “Reproducible Computing in R. How to separate code and data?” .