It's kind of impossible to have it any other way. Ops is a cost center; you'll only have as many ops staff as you need to ensure your hair isn't on fire. And so ops staff only have enough time to solve problems with the most direct shortcut (usually by adding more components into the mix), rather than doing good Engineering to pay down the technical debt responsible for the problem.
If you have an infinite budget, by all means, hire developers whose jobs are to be prophylactic for ops tickets, by paying down tech-debt. But you'll have to guard that department with your life, because it'll be the first thing to be cut the moment anyone's looking to grow margin by shaving costs.
That is, until your customers start demanding higher SLAs and offering money for them... Maybe only a thing for really big companies, but when that happens, improving reliability and ops becomes someone's job. If not multiple people.
That doesn't mean no duck tape like solutions get used, but that the ones that cause problems get removed.
A good File system maintainer is a precious resource. wasting them on running stuff is madness. (I say that as a Devop.) I know a fair amount about running/configuring/tinkering with filesystems. (hell I've bumped into at least 3 XFS bugs, ones that were new to Redhat.) But I would never presume to be able to make a meaningful patch.
Its the same way that I'd not expect the Ext4 maintainer to know how to instrument, metric and monitor a large company's infrastructure.
Almost certainly they would have flung a ticket over the fence, and it was up to politics to make it work.
It's kind of impossible to have it any other way. Ops is a cost center; you'll only have as many ops staff as you need to ensure your hair isn't on fire. And so ops staff only have enough time to solve problems with the most direct shortcut (usually by adding more components into the mix), rather than doing good Engineering to pay down the technical debt responsible for the problem.
If you have an infinite budget, by all means, hire developers whose jobs are to be prophylactic for ops tickets, by paying down tech-debt. But you'll have to guard that department with your life, because it'll be the first thing to be cut the moment anyone's looking to grow margin by shaving costs.
That is, until your customers start demanding higher SLAs and offering money for them... Maybe only a thing for really big companies, but when that happens, improving reliability and ops becomes someone's job. If not multiple people.
That doesn't mean no duck tape like solutions get used, but that the ones that cause problems get removed.
I don't think thats siloed.
A good File system maintainer is a precious resource. wasting them on running stuff is madness. (I say that as a Devop.) I know a fair amount about running/configuring/tinkering with filesystems. (hell I've bumped into at least 3 XFS bugs, ones that were new to Redhat.) But I would never presume to be able to make a meaningful patch.
Its the same way that I'd not expect the Ext4 maintainer to know how to instrument, metric and monitor a large company's infrastructure.
Almost certainly they would have flung a ticket over the fence, and it was up to politics to make it work.
Its the fence that I dislike. But I work in a small studio where I can easily work with (and do some) devops.