3 ms·
This might cause other problems, problems of the "if it's not broken, don't fix it" variety. Upgrading everything only to break something else, in a previously
by icedchai 2mo ago
This might cause other problems, problems of the "if it's not broken, don't fix it" variety. Upgrading everything only to break something else, in a previously stable configuration, isn't worth it.
- pixl97 2mo agoReally the days of "Lets run this stable configuration forever" are gone. Getting rid of as much stuff in your OS and software stack as possible should be the security teams ultimate goal, so you have less to upgrade in the end. But actual security updates just come out at a tremendous rate, and you need a QA system that checks as much as it can before prod is upgraded.
- icedchai 2mo agoI do agree with more frequent upgrades, but it has to be part of the culture. The longer you wait, the harder it gets. Unfortunately, I have worked in some heavily tech-debt-laden environments where upgrading anything required an act of god. I've logged on to production servers with 1500+ days of uptime at multiple companies. Nothing had been updated since well before that time. At one place, I recall encountering a 10+ year old dependency. On top of that, they were still using Python 2.7. This wasn't that long ago.
- vrighter 2mo agoin our case, updates were done on a staggered schedule, automatically, and rebooted at a particular agreed upon downtime window. dev, then test, then live machines. I had to explain multiple times to them, for example, that I have updated the system, but the reboot is scheduled for 3 days from now.