- Do the test at a time that causes least disruption to users of the product. Based on your system's known use pattern, you schedule the operation for a quiet time -like a Sunday morning. If the test works, few people notice. If things go wrong, well, damage is minimal and you have the rest of the day to roll back. The main inconvenience here is to the development team, who get phone calls from the operations team once -not if- the system fails.
- Do it during working hours when it is most convenient to the development team. This is best for the developers, but generally worse for end users, more of whom discover the system is down
(photo taken in central Bristol on Friday afternoon, 2:04pm)