Hi Daniel, Tim pretty much nailed the answer to both your questions.
We see the approach as follows:
After the read-only maintenance, if any changes made to config and database/filesystem are lost, then what is the impact. In the case of page view analytics the result would be insignificant. Even for the config, we don’t block this as we feel that admins are owning the responsibility of read-only mode and may have a good case for changing the config whilst it is on.
If the same DB and filesystem are used post read-only mode then you get the benefit of having captured the analytics during read-only operation.
The same goes for scheduler jobs. Think about the impact of keeping or loosing that same database. If it was a nightly clean-up l, then likely it is irrelevant if you prevent the job or not, as the job will run the next day on the same or ‘new’ database with a similar nett result.
On the other hand, if the user changed a critical workflow, edited some content, changed a file, and those changes were lost post read-only mode then they would be both confused and annoyed.
Hope this helps.