On Thu, Dec 31, 2009 at 11:38 AM, Peter Tribble <peter.trib...@gmail.com> wrote: > Ben's recent post brought to mind a question I've been pondering for a while: > > How much Systems Administration do Systems Administrators actually do? > > I know that I spend the majority of my time working more on applications > rather than systems, and even when I'm working on the systems side of > the fence it's mostly storage or backups. > > Is this just me, or is it widespread?
I think it depends on the size of the environment. When I worked at a .edu (< 20 servers, 150 - 200 workstations, 5000 users) the unix admins were responsible for application installation and maintenance as well. As machines got big enough that we didn't have to do silly tricks with OS components on multiple disks or on a network file system (NFS or AFS) and administration practices improved (jumpstart, distributed management mechanisms) the balance of time shifted more toward application maintenance. It wasn't that there was more app work, there were fewer students helping out as admins. The last couple years there I found myself dealing more with security issues due to the openness of the university (firewalls and disabling telnet would stifle creativity). I had to do really stupid stuff like use the twist operation in tcpd to have a perl script connect to the source of the incoming telnet connection to see if it was a wingate telnet proxy and if so assume it was somebody that was just about to install bitchx. When I worked in the IT group that mostly serviced a large engineering community, I often found myself pulled into sysadmin related things to help product rather than strictly running IT operations. That is, I would get pulled into engineering labs to help engineers or testers figure out how to set up various systems for interoperability testing. For quite some time I was on loan to an engineering team to help them figure out how to handle security and system integration aspects of their first web-based network management tool. This branched out in a lot of other areas, including porting the app from Solaris to Linux and Windows (I talked them out of a Win98 port, thank God). Working in "the" IT department for a multi-billion dollar global enterprise has even a greater focus on pure system administration. At first, it was probably 80%+ reactive work. That is, the pager would go off and you would queue that problem to work on it as soon as you finished the problem from the previous page. It was this way for all sysadmins, but certainly worst for the person on call. Over a several year period organizational changes, grass-roots architectural changes, then top-down quality initiatives changed this quite a bit. The environment is large enough that sizable sysadmin teams still do primarily sysadmin work (with a healthy dose of regulation-induced paperwork) but it is much more orderly than it had been. I say "sysadmin teams" because different teams are focused in different areas. For instance, there is a team that is responsible for day-to-day operation, others that are aligned with specific parts of the business to do architecture and implementation work, and another than is responsible for defining and maintaining the tech stacks. The team responsible for the tech stacks ensures that we keep moving the tech stack forward and have mechanisms to ensure that the various other sysadmin teams are all on the same page. That is, with the multiple sysadmin teams, common leadership and feedback mechanisms are essential. In this larger IT environment, there are certainly plenty of times that sysadmins get pulled into application related issues. It is not to manage the apps, rather it is to help the application owners make architecture decisions or to help troubleshoot performance or reliability problems. Generally the sysadmins don't know enough about the applications (there's way too many of them) and the app admins don't have more than an end-user view of the OS. It's probably worth noting that unlike in smaller environments, there are other dedicated teams for storage, networking, etc. There's enough going on that all of the teams have areas of specialization within them. > (I don't see anything wrong with this - I've long thought that systems should > just work and the real complexity is in the application tier, although I'm > also > starting to think that it's about time that applications just worked.) I think that the systems and applications should just work *together*, but as separable units. I'm confused as to why I am worrying about the OS that is used under very common software like J2EE servers, databases, etc. I'm encouraged by the ideas behind JeOS and virtual appliances, but find very little uptake by the vendors that provide software to large enterprises. Exadata looks very promising, but I hear Oracle is setting the price. With the concepts from brandz, it should be possible to create a very thin zone that has absolutely no OS configuration inside it and has access to a minimal stable ABI. By establishing a firm barrier between the OS and app, it becomes much easier to pick up the app and move it from machine to machine and likely from OS to OS. The existence of a more fully-featured OS in the global zone allows things like analysis with DTrace and implementation of resource controls, firewalls, etc. Such a zone could be delivered by a vendor in a single file (e.g. a iso image or zpool in a file) and the management of it could be handled via the same management protocols that are used today. Data that changes within it could be stored in a ramdisk, NFS, or within the the file system included in the image file. If data within this image needs to change, backups and restores could be handled via NDMP or similar. -- Mike Gerdts http://mgerdts.blogspot.com/ _______________________________________________ sysadmin-discuss mailing list sysadmin-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/sysadmin-discuss
