That’s true. You can’t completely prevent this from ever happening again, but you can try to make it harder to happen again.
A group of people at Funcom has the ability to deploy new settings to the whole official server fleet. Adding a bit of judicious friction there would make it harder to have another disaster like this.
“Judicious” is the key word, though. If you add a new confirmation stage that pops up every time you do a deployment, people will get used to it after a while and it will have no effect. However, if it pops up only under certain conditions – for example, when deploying to the whole fleet and/or when something about the deployment seems anomalous (like a setting configured outside “reasonable” range) – then it should help. It’s especially helpful when the confirmation isn’t just a “yes/no” choice, but asks you to confirm a value.
For example, if you’re deploying to the whole fleet, the confirmation pop up could say:
WARNING!!!
You are deploying the following settings to 780 servers:
<summary of settings changes>
Please enter the number of servers in the box below to confirm the deployment:
And all you would have to do is enter the same number you see on the screen, but hopefully it would make you stop and look at the settings you’re deploying before doing it.
Again, nothing is foolproof, but there are measures that have been proven to help.
2 Likes