Our sysadmin environment
The simple way to describe it is that my group is traditional university sysadmins (well, for departmental computing). This means that our job is to provide an environment with various services, things like network connectivity, reasonably decent file storage, printing, email, some machines that people can log into to do various things (including run big computational jobs), and a reasonably flexible web server that people can put stuff on. But that's pretty much it.
(What's in this central environment is mostly set by the department's computing committee, mostly based on what's easy and cheap to do and of sufficiently broad use to the department.)
If a graduate student wants something that we don't already provide, it's usually up to them (and their Point of Contact) to set it up, and if they have a program or a web service or whatever that is falling over or not performing well enough, it's entirely up to them to troubleshoot it. If a graduate student wants something that requires root permissions or a new system daemon or whatever, something they cannot set up as an ordinary Unix user, the answer is generally 'no, we can't provide that'. The escape hatch from this limited functionality is that people can put their own machines on the network and obviously do more or less whatever they want on them.
(We're willing to install standard Ubuntu packages for people, but we won't run new system daemons. So we'll install the PostgreSQL packages but not run a system PostgreSQL instance.)
This means that we do only one part of the traditional 'ops' jobs, and we do it in a very hands-off way. We don't get handed software to deploy, we don't get asked to set up various packages (eg, 'this thing needs an Oracle database, set one up for us'), and we don't even get new machines to install for people. We do have some custom software and systems that are part of our environment, but they're all stuff we've written and have full control over; we own them from start to finish, plus they're only providing internal services.
Even in a university, not all systems are run this way. There are plenty of important public-facing systems and services around here that are run in a much more conventional industry-like 'ops' way, with code and site deployments, the sysadmins being responsible for the service staying up, and so on. (Some of them lead to very interesting war stories and challenges.)
(Points of Contact probably have a more industry-like 'ops' job, but even there my impression is that graduate students usually retain a lot of responsibility for deploying their own software and keeping it running.)