I disagree strongly, and I currently run an infrastructure team. Things break because of changes to the system. Assuming the entire infrastructure team wasn't fired, it should be dramatically easier to keep the service online assuming all development has stopped.

That depends entirely on the status of the stack when the code freeze happened.

If it was unstable, then I'd want several bottles of whisky on hand, because I'd have to work around the stinky pile of dung I'd been left with.

Given reports of debug and dev builds in production just before everything was frozen, I'd probably want to start stocking up on whisky.

Changes to a system can come in many ways, e.g. we had a noticeable increase in our db size because of a new customer data, what was ok. before wasn't after. Of course it's different for twitter. And what about security? Update to libraries, dependencies...?

Anyone remember the leap second?

Of course but this is also twitter, not a startup in its infancy. I'm not saying new stuff won't happen (etc), but they have a very mature infra org.

Do they? It's hard to tell where these cuts are happening and how much thought is going into them.

And almost no one left to manage it.

Not during the code freeze. Using the same container image that worked before for a while doesn’t need dev input.

I‘ve had stuff break because of required kernel updates, software that needed to be patched, hardware breaking and no exact substitute being available, database sizes crossing critical thresholds, … - it‘s definitely less risky to run something that is well understood and no longer getting substantial amounts of updates, but every complex system has known and unknown deficiencies that are just a butterfly’s wingbeat away from being triggered. As long as you‘re on the happy path, everything will look fine. But if something pushes slightly and moves you to the unhappy path, you can find yourself very quickly in a position where you need someone with a deep understanding of some obscure component of the system that is misbehaving - and that someone is unlikely to be the infrastructure team.