Forgot your password?
typodupeerror
Businesses Operating Systems Software Unix Linux

System Admin's Unit of Production? 556

Posted by kdawson
from the counting-lines-of-shell-script dept.
RailGunSally writes "I am a (strictly technical) member of a large *nix systems admin team at a Fortune 150. Our new IT Management Overlord is a hardcore bean-counter from hell. We in the trenches have been tasked with providing 'metrics' on absolutely everything from system utilization to paper clip recycling. Of course, measuring productivity is right up there at the top of the list. We're stumped as to a definition of the basic unit of productivity for a *nix admin. There is a school of thought in our group that holds that if the PHBs are simple enough to want to operate purely from pie charts and spreadsheets, then we should just graph some output from /dev/random and have done with it. I personally love the idea, but I feel the need for due diligence, so I put the question to the Slashdot community: How does one reasonably quantify admin productivity?"
This discussion has been archived. No new comments can be posted.

System Admin's Unit of Production?

Comments Filter:
  • by Esion Modnar (632431) on Saturday August 25, 2007 @04:33PM (#20356015)
    of Jolt Cola consumed.
  • by haluness (219661) on Saturday August 25, 2007 @04:34PM (#20356023)
    How many tickets answered per day? Completed per day? /dev/random is probably the most elegant though
    • by metlin (258108) on Saturday August 25, 2007 @04:49PM (#20356199) Journal
      Trouble tickets are great, but I would recommend that you find ways to quantify all of the following in some way or the other -
      1. Stability calculated using the uptime of your systems. You could include such things as updates, patches etc to this to demonstrate that stability is not set in stone.
      2. Reliability is similar to stability, but how many production/pilot/training and other systems rely on you? How often and how well do you serve them?
      3. Response time is how fast you react to problems and how often do problems come up? (trouble tickets are a good way to quantify the latter)
      4. Network load is a good way to demonstrate how well your network is performing, if you are a *nix sysadmin handling networks.
      5. Security is how much time and effort do you spend on keeping your systems secure, both internally and externally?
      6. Efficiency would be a combination of all of the above and a way of measuring how well you achieved those things and how much time, resources and effort was expended to achieve those things.


        I am sure that others could find much better ways of quantifying performance, but this is something that jumped out at me. I was part of a consulting team that was asked to improve performance in a company several years back, and they came up with something similar.
      • The hammer priciple. (Score:5, Interesting)

        by infonography (566403) on Saturday August 25, 2007 @05:59PM (#20356823) Homepage
        I remember an old joke about a furnace repairman coming to a home and after looking at the furnace for about a minute and a half, listening to the rumbles and gurgles. He takes his hammer out and at once precise place he hits the furnace. The furnace starts up and runs fine as if it was brand new.

        The bill was $200.

        The homeowner asks why so much when all he did was hit it once with a hammer?

        The repairman takes back the bill, and itemizes the bill still totaling $200.

                              Cost of hammering, $1
                              Knowing where to Hammer $199

        Any idiot can muck about on a UNIX box, I worked at one Fortune 500 company where everybody in the dept had Double E's. Still their main Solaris server crashed ever 3-5 hours daily and had been for months.

        Took me a week to unscrew it and put everything back in order.

        Me, I am high school dropout with no GED and some non-technical college courses. Still most of what I was doing was letting them do their work and not have to bother about broken systems. My value was on par with theirs as it was time they didn't lose on their work.

        Nevertheless beancounters are stupid (also Beancounters are not accountants), they know the cost of everything and the value of nothing. If you really want to send their head swirling take the entire labor budget for each dept expressed as an hourly unit. Every time you work for a dept internally charge the company that much for each hour you work on a project or ticket for them or better still your company and tell them thats how much it costs. Without Sysadmins nobody does anything but fight technical fires and gets no work done.

        Likely this joker found out that Auto Mechanics have a book to calculate how much to charge for each service and repair with details on how long each job should take. This doesn't work because Sysadmins are closer to being chefs or doctors then low end auto mechanics.

        Even so, people who own Jaguars, Ferrari, and Maserati don't take them to Jiffy Lube.

        If they complain tell them the story about about that hammer. (or better yet use on on them)
        • by Firethorn (177587) on Saturday August 25, 2007 @07:12PM (#20357333) Homepage Journal
          To approach it from an entirely different angle, much of an system administrator's job(whether Unix or not) is to avoid things, much like a security guard.

          Just for one example: How do you measure avoided data leaks that would of cost millions?
          • by c6gunner (950153) on Saturday August 25, 2007 @07:24PM (#20357391)
            Of course the elephant repellent is working! You don't see any elephants around here, do you?

            Seriously though, that's a problem in many fields. People don't appreciate the value of a good military until they're under attack. They don't appreciate the value of a well funded police department until the crime rate starts increasing exponentially. And they don't appreciate the value of a good fire department until their whole block has gone up in flames. Sysadmins are no different.
        • by D-Cypell (446534) * on Saturday August 25, 2007 @07:20PM (#20357369)
          I worked at one Fortune 500 company where everybody in the dept had Double E's.

          Excellent. Tell me, how is Mr Hefner?
        • by budgenator (254554) on Saturday August 25, 2007 @07:44PM (#20357515) Journal
          I knew a guy who was a millright for GM at Hydromatic, he was paid $45.00 an hour and played Euchre all day, management was fine with this because when he went to work, the plant lost $45,000.00 an hour. When a sysadmin is working, really working at his/her real job, the shit done hit the fan.
          • by StupidKatz (467476) on Saturday August 25, 2007 @09:17PM (#20357993)
            ... in my opinion, is to be as bored as possible. Everything which is done on a regular basis should be as automated as possible, and as much effort and resources thrown at avoiding potential problems as the finances and customers will allow (data backups, spare or redundant equipment, etc.).

            Much of a "good" sysadmin's time should be spent doing regular, but occasional spot checks on the automation (which can also be greatly automated) to ensure everything is running as smoothly as possible.

            Obviously, not all problems can be avoided, especially hardware failures, but if everything else is in place, even recovering a dead, but critical server can be fairly painless.
            • by Anonymous Coward on Sunday August 26, 2007 @12:10AM (#20358971)
              I have never been a SysAdmin but I have done IMR. In IMR if you are really doing your job, then no one knows your there but the bean counters, unless of course someone wants to add something new to the mix or operator error. Of course it was more obvious when you regularly had to change the machine setups to run different products. Pretty much everywhere I did that there was a ticket system to make the bean counters happy and the better you did your job the more creative you had to be to account for your time. If you didn't make the bean counters happy they would start working to get your job eliminated and if you worked directly for production in this respect the departmental manager might try making you do production work when not doing maintenance or repairs.

              Fortunately the at the place I worked the longest in that field the plant manager was a former IMR technician and he would give a dressing down to any bean counter or ignorant lower management who messed with us, as he put it "this plant is running very smoothly because of this IMR crew and they all know that the smoother things are running the more time they have to relax and plan future required interventions to keep themselves relaxed with free time to think." Course we were not always thinking of such things while relaxing and he knew that, but he knew as long as we got rewarded with relaxing time at work, the smoother we would keep things running to preserve the relaxed atmosphere.

              Personally, I think the SysAdmin who contributed the question here should check the obviously clueless "new IT Management Overlord"'s computer to make sure they not violating copyright via downloading recordings; make sure they are no trojan infesting the system; and make sure they are not downloading large amounts of porn, it would be a shame if this "bean counter" had to account for anything like that.
              • by infonography (566403) on Sunday August 26, 2007 @02:35AM (#20359869) Homepage
                Hmm, thats true lets see now.

                clickityclickityclickityclickityclickityclickitycl ickityclickityclickityclickity

                su username

                clickityclickityclickityclickityclickityclickitycl ickityclickity

                not there.... hmmm

                clickityclickityclickityclickityclickityclickitycl ickityclickityclickityclickityclickityclickityclic kityclickityclickityclickityclickityclickityclicki tyclickityclickityclickity

                launch gimp, batch job import, crop

                clickityclickityclickityclickityclickityclickitycl ickityclickity

                copy rename alter datestamp chown

                clickityclickityclickityclickityclickityclickitycl ickityclickityclickityclickityclickityclickityclic kityclickityclickityclickityclickityclickityclicki tyclickityclickityclickity

                hmmm ok found it tsk tsk tsk, and he seems like such a nice young man. .......

                Cows???? oh good lord

                clickityclickityclickityclickityclickityclickitycl ickityclickityclickityclickity

                mail "my vacation photos" all

                / tip of the hat to the BOFH
        • Re: (Score:3, Informative)

          by servognome (738846)

          Nevertheless beancounters are stupid (also Beancounters are not accountants), they know the cost of everything and the value of nothing.

          Beancounters who try to impose their metrics are stupid, as they really don't understand what to measure. Any worker should understand their job enough to put together metrics that demonstrate their value. In the original post the beancounter went about things the right way, ask the admin how they would measure their job.

          Without metrics you leave yourself open to

          • The Barbrady Effect (Score:3, Interesting)

            by infonography (566403)

            Nevertheless beancounters are stupid (also Beancounters are not accountants), they know the cost of everything and the value of nothing.

            Beancounters who try to impose their metrics are stupid, as they really don't understand what to measure. Any worker should understand their job enough to put together metrics that demonstrate their value. In the original post the beancounter went about things the right way, ask the admin how they would measure their job.

            If you've ever watched South Park you may have seen the seemingly inept cop who somehow seems to keep order. As demonstrated in one episode when he was removed from office. Chaos ensued and was stabilized by his return.

            When a IT dept is feeling underfunded they merely threaten to quit. The reaction is akin to a three year old being told mommy is leaving. Good IT people are worth their cost, and most are not so greedy. They stay because they want to not because of the money. Beancounter bosses tend to pay f

            • Re: (Score:3, Funny)

              ...reading the latest management fad like Sigma 7 or some other such...

              The Sigma 7 was an excellent computer in it's day. It was the first computer to have a hardware priority interrupt, invented by Max Palevsky.

              I think you might mean "Six Sigma" which is slightly less old.

        • Re: (Score:3, Insightful)

          by jcgf (688310)

          Me, I am high school dropout with no GED and some non-technical college courses.

          Oh and you claim to know more than the EEs at your fortune 500 company? God, slashdot is full of you guys and frankly I think you're all full of shit.

          No offense to you personally, I just hate seeing people kicking on college degrees like they don't mean anything.

          • by TapeCutter (624760) on Sunday August 26, 2007 @01:27AM (#20359497) Journal
            "God, slashdot is full of you guys and frankly I think you're all full of shit. No offense to you personally, I just hate seeing people kicking on college degrees like they don't mean anything."

            Ditto, only financial success or inexperience permits the arrogance of thinking EE == Computer Science == Software developer == SysAdmin == Help Desk slave. It's total bullshit to infer dropping out of HS won't make a "difference" and that financially it is a detrimental step for all but a tiny minority of naturally gifted (or extremely lucky) entrepenuers and assorted geniuses.

            Me, I'm a high school dropout who then went on to be a member of the "working poor" and/or "time poor" until I obtained a degree in my early 30's. I quit the factory, got a lisence and invested $1K in a brand new Acer XT with a "paper white" 16 colour CGA monitor to replace my $80 second-hand IIE at the start of my course. It was not a small investment for us, but freeing up the family TV was a diplomatic coup over the wife/kids and it was also the best finacial one I ever made.

            My last year at uni the computer directly earned me $9K writing small "search and sort" examples for a text book the dept. head was writing. Indirectly, I am now quite comfortable in my late 40's and have a decent chance of being very comfortable in my 60's. Barring a lotto win, my alternate future would probably have seen me as a factory foreman (I was already a leading hand -death by rotating shiftwork- shudderrr). And when the factory job "disappeared", as so many did in the last couple of decades, I would probably have spent my severence pay on a franchise gardener/handyman/taxi-truck "bussiness", OTOH: I would probably be 10-15Kg lighter and have an endless supply of home grown pot... :)

            Today I live by the beach with a 15min drive (or a broadband connection) to the office, I like to take pictures of storms on the bay but the trick is finding a profitable passion to pay for the time and material needed for your other passions (that may also one day be profitable). Sure doing a degree and finding out just how smart others before you have been can dull the "passion" as one by one you find your "original insights" are not original and/or not instghtfull. For me it didn't completely kill the passion but it did open up the enormity of what I don't know and how hard it can be to "find out". If the "passion" were to die completely I have made enough profit to walk away and do something else besides mowing lawns for the middle class simply because a little passion for one's job and a decent "fuck-you" fund equates to power when dealing with PHB's.

            If someone doesn't think a degree will help with any of that then to them it isn't going to. They are either already "happy" or belive like I once did that the only reason for "working" is a paypack.
          • Re: (Score:3, Insightful)

            by retro128 (318602)

            Oh and you claim to know more than the EEs at your fortune 500 company? God, slashdot is full of you guys and frankly I think you're all full of shit.

            No offense to you personally, I just hate seeing people kicking on college degrees like they don't mean anything.

            He probably DOES know more than the EEs....about being a sysadmin. As he pointed out the EEs couldn't run their UNIX box, but likewise I wouldn't expect the grandparent poster knows how to design a circuit board. We all have our stations - People can't be expected to know everything about everything.

        • by Iron Condor (964856) on Sunday August 26, 2007 @01:58AM (#20359701)

          Please correct me where I have misread, but in all your verbosity you seem to have made two statements:

          - One cannot quantify the sysadmin job

          - You're better at it than some

          To my (non-MBA) eyes, these two appear in contradiction. If one cannot measure/quantify how well a sysadmin is doing his/her job, then one cannot claim that one is doing a better job than the other. Thus one might as well hire the cheapest guy. If, on the other hand it is supposed to be possible to say "you're doing a better job than joe" then there must be something measurable, observable, something that can be put into a number and that number differs for you and joe (in such a way as to make yours the better number).

          I admit I have no idea how to measure the quality of a sysadmin. If my stakeholders forced me to (I.e. my boss said "quantify what your IT dudes are doing") I would go to my sysadmins and say "please give me numbers that show how well you're doing". Because the alternative is pulling something out off my ass -- and neither my superiors nor the people who work for me would like that.

      • by dubl-u (51156) * <2523987012NO@SPAMpota.to> on Saturday August 25, 2007 @07:51PM (#20357579)
        That's a good list. I'd add a little more, though.

        Personally, I split sysadmin work up into two categories: doing something and making it so you don't have to do anything. The second is much more important, but much harder to quantify.

        For the first category, you can definitely count things for managers. E.g., X accounts created, Y support requests handled. Be very careful quantifying things like this, though, or you create perverse incentives. If I make a system that's hard to use, I can receive and satisfy a lot of support requests. Or if I concentrate power rather than distributing it, then I get to look busy and important.

        The other category is much trickier. Long ago I worked for a financial trading company. About 80% of the working day, the head clerk would just loiter on the trading floor, reading the paper and shooting the shit with clerks and traders. And that was exactly what his bosses wanted: they correctly saw that as a sign he kept things running smoothly. And then when problems popped up, he could give them his full attention while the rest of the operation kept running.

        So I'd add two items to your list: user satisfaction, measured through surveys, and crisis preparedness, measured by speed and quality of response during drills (and actual crises, of course, but you can't wait for those to find out how ready you are).
      • by Anonymous Coward on Saturday August 25, 2007 @10:41PM (#20358391)
        I am an SA who became a bean counter. One of my primary motivations was that I saw f*ck-ups getting rewarded with less work and raises while hard-working SAs suffered with more work and dead end jobs.

        I think management deserves to know what is good work and what isn't. If you leave it up to them, they are going to pick something like tickets resolved or customer satisfaction and you are going to see the a**-kissers move up while the hard-working straight-shooters get the shaft.

        I think the metrics described here are good ones, but I'd change #4 to the ratio of load to capacity -- which is a measure of efficiency and good planning. Overall, a good SA should be able to maximize delivery of services. I'd also change #5 to security risk measured as ELV (expected loss value). I know a lot of security professionals who hate this and think it is meaningless, but so far none has given me any better metric to show management that security risks are actually getting better managed over time.

        In short, think of what a good SA does for a company and propose metrics that reflect that. Do NOT leave it up to management like some have suggested. THey are asking for your opinion as an expert. Step up and show that you are the expert by giving them an expert answer. Show them that you know the difference between a good job and a bad job.
    • by Duhavid (677874) on Saturday August 25, 2007 @04:59PM (#20356309)
      No. How many tickets were not opened in the first place because things
      just work.

      Yeah, I know.
      • "How many tickets were not opened in the first place because things just work."

        "Functionally stable": A euphemisim meaning your project/system is going nowhere and getting nothing.
    • Isn't answering tickets the antithesis to productivity? Productivity would be designing your systems such that you don't get tickets. Routing everything to /dev/null doesn't count :)
    • Figure out how much downtime costs, and how much downtime you prevent due to increased numbers of people, or special skill sets. If your webserver goes down, will it potentially hurt your business or not? Are your internal servers more important? Do printers really need 99% uptime? Everything gets weighted.

      Overall, it seems like a pain in the ass to figure out, but might be quite useful in the future to justify spending for new equipment, software, or support, or even your own employment.

    • by Citizen of Earth (569446) on Saturday August 25, 2007 @05:17PM (#20356491)
      Hours of productivity per day lost to productivity measuring?
    • by beakerMeep (716990) on Saturday August 25, 2007 @05:19PM (#20356505)
      Simple answer is that you don't. Productivity in terms of IT and related fields has become a dirty little word but more than that it is a business term, not technical. If you aren't a director or higher in title, and your duties don't include justifying expenses and planning resources for solutions, then it isn't really your realm to measure something like productivity. If this guy has an MBA or similar qualifications, it is he who should know how to measure productivity. But alas the word productivity has become corrupted by half-assed business journalists trying to write articles about over all productivity and how your employees waste too much time on facebook. If this guy just wants a number and gives you no guidelines as to how to come up with the number, then my guess is that he just wants to kiss up to the CEO that "productivity" is up 40% or he wants a number to justify laying off people. Either way, if he cant tell you how he reached his number, I would suggest getting your resume ready.

      Also ideally, a CTO wouldn't be asking those in the trenches how to measure productivity, but rather how to improve it. As someone in the trenches, you probably know where the snags are in efficiency, or what software you would need to purchase to help smooth things along or even where people are over worked or over looked. This is the positive way to improve productivity. Basically he should be asking you what you need in order to get your job done, and he should get it for you (within reason of course)
      • Re: (Score:3, Insightful)

        If you aren't a director or higher in title, and your duties don't include justifying expenses and planning resources for solutions, then it isn't really your realm to measure something like productivity. If this guy has an MBA or similar qualifications, it is he who should know how to measure productivity.

        I am in an MBA program. Anyone in an organization can be involved in measurement. I was taught that it is arrogant and foolish for a manager to think they can sit in their office and make decisions re
    • Re: (Score:3, Insightful)

      by jcr (53032)
      Counting support tickets is almost as bad an idea as counting lines of code. There's all kinds of ways to generate and close a huge volume of support tickets.

      -jcr

    • Re: (Score:3, Insightful)

      by platypus (18156)
      Many people here commented that you can't measure productivity of a Sysadmin.
      This sort of misses the point. And to keep maintaining this stance of "what we
      are doing cannot be put in numbers" in a huge company will
      ultimately lead to job cuts in the IT Operations departments if times get tougher,
      money has to be saved, and heads will be counted. Because everybody else
      (Marketing, Finance etc.) *will* have numbers at hand to show how "productive"
      they are and how they cannot spare even one FTE.
      Add to that that co
  • Easy (Score:2, Funny)

    by Bloater (12932)
    Write a kernel module to log the number of keystrokes.
  • Unit of production (Score:5, Insightful)

    by phoenix.bam! (642635) on Saturday August 25, 2007 @04:35PM (#20356037)
    The best sys admins are the ones you never notice. If the productive workers in a company never see or need to talk to a sys admin it's been a productive day for the admins.
    • by thomas.galvin (551471) <slashdot@thomasA ... inus threevowels> on Saturday August 25, 2007 @04:50PM (#20356217) Homepage

      The best sys admins are the ones you never notice.

      If the productive workers in a company never see or need to talk to a sys admin it's been a productive day for the admins.
      Bingo. So here's what you do:

      Leave for a week.

      When you get back, after you've managed to suppress the fires and riots, fight your way to Mr. Bean's office, talk him down off of his desk, get him to put away the spear, and tell him "that's why you keep us around." If he wants it quantified, write it up as "Number of Cannibal Insurrections Suppressed Per Week (Estimated)."
    • Re: (Score:2, Insightful)

      by entgod (998805)
      Thus, productivity can effectively be measured 1/N where N is the number of times someone needs the sysadmin during a month. If the sysadmin is never needed this woud be 1 or 100% and someone with an effectiveness of 100% deserves a raise.
    • Re: (Score:3, Insightful)

      by drmerope (771119)
      Bingo. I remember very fondly joining companies and discovering that the IT stuff just works. This is the measure of a good sysadmin team.

      The common state-of-affairs is not that everything works; its impressive when it actually does.
    • Re: (Score:3, Insightful)

      Actually "hours without productivity lost to problems" could be a great metric in this case.
    • Re: (Score:3, Insightful)

      by gad_zuki! (70830)
      Yes, in other words: uptime.
  • Easy (Score:2, Offtopic)

    by metalhed77 (250273)
    Why worry? If you've got enough time to post stories to Slashdot you're clearly very efficient.
    • Re: (Score:3, Funny)

      by TubeSteak (669689)

      Why worry? If you've got enough time to post stories to Slashdot you're clearly very efficient.
      So what you're saying is that he should use /. posts per day as a measure of efficiency?

      I wonder how much he'd have to post to get a bigger Christmas bonus.
    • Re: (Score:3, Interesting)

      by Alsee (515537)
      productivity = (SystemUsers) * (TimeReadingSlashdot) / (SystemDowntimeRate)

      And while that is obviously a joke, it also happens to be pretty much correct.

      Obviously if you increase SystemUsers while keeping all else constant, productivity goes up. If you reduce SystemDowntimeRate while keeping all else constant, productivity goes up. If you spend less time on general maintenance and random panic fixes (increase TimeReadingSlashdot) while keeping all else constant, productivity goes up.

      -
  • Well... (Score:3, Insightful)

    by djupedal (584558) on Saturday August 25, 2007 @04:36PM (#20356045)
    "How does one reasonably quantify admin productivity?""

    If no one in the building but HR and your line report need to know your name, you're doing your job...

    Other than that, it would be like a trash collector counting how many cans he emptied during the day or a wildfire firefighter how many burning bushes he chopped. If there weren't any fires or trash these people wouldn't be needed, would they?

    You can't quantify SA productivity.
    • Re:Well... (Score:4, Interesting)

      by SplatMan_DK (1035528) on Saturday August 25, 2007 @05:05PM (#20356379) Homepage Journal

      You can't quantify SA productivity.
      I respectfully disagree.

      You can evaluate how many users the SA's systems serve, how many systems the SA maintains, and how much data throughput all these users/systems generate.

      A confused Microsoft-SA running in circles around an Exchange server all day in order to serve 200 users is not "efficient" compared to a Linux-SA running an MTA which services 25.000 users (with better response times).

      On the other hand, a non-skilled Linux-SA who is fiddling with a SAMBA server in order to maintain 200 users with Windows clients is not very "efficient" compared to a skilled Microsoft-SA with a well configured AD.

      Off course you can measure SA efficiency. And there is nothing bad about it. In most cases it is even a benefit for the *nix admins.

      :-)

      - Jesper
    • Re: (Score:3, Insightful)

      If no one in the building but HR and your line report need to know your name, you're doing your job...

      And that's easy to quantify. Number of outages per week, average downtime, etc. Then report this by service (the email server was up 100% of the time, but the server with lousy intranet app X crashed twice, they need to rewrite that).

      Of course, it's not productivity, but it's a measurement of the quality of service. Combine that with other indicators like users served, requests serviced, emails delivered, etc. and you can actually chart improvements in "productivity".

      Even something like average time to sol

  • impossible? (Score:2, Insightful)

    by ragahast (879945)
    It's easy to quantify /my/ productivity as a support tech (at the U of CA) in number of tickets resolved per shift. But sysadmins have a number of duties which they are performing /continuously/, so how can you quantify that?
  • by ZWithaPGGB (608529) on Saturday August 25, 2007 @04:36PM (#20356055)
    Since the real proof of actual productivity for network admins is negative: nothing goes wrong (no trouble tickets). Also, the PHB will get their wish: No one to pay is infinite productivity (measured as output per $ spent).
  • Unit of productivity (Score:5, Informative)

    by orionpi (318587) on Saturday August 25, 2007 @04:37PM (#20356059)
    Unit of Productivity = 1 / (hours of down time)

    They are paying you to keep bad things from happening.
    • (Out of mod points.)

      You are absolutely correct imho.
      Now, to explain this to a PHB... give them some downtime first ?

      Putting beancounters in IT mgmt can be a prelude to axing of IT jobs. Tread lightly!
    • by Tony (765)
      Unit of Productivity = 1 / (hours of down time)

      Bad choice. In a well run shop, you'd get a "division by zero" error.
  • hmmm (Score:2, Insightful)

    by nomadic (141991)
    Do uptime. Unless your team has serious problems, those numbers should always look good. If you do any sort of work in response to in-house or outside tech support requests, you can measure how long it takes to resolve issues.
    • Make sure you put the correct spin on the graphs. You would hate to be called on your low number of support requests completed just because you managed to keep 100% uptime on everything. Also, try and keep it all relative - for example 94% of all support requests were completed within 1 hour. It doesn't matter if you got 16 or 160 requests, it still looks like a good number. Maybe have a "fall back" category such as %age of support requests taking more than 6 hours to resolve - works great even if you d

  • A) Nagging emails
    B) Logging every OS update
    C) Supervising Patch Thursdays
    D) recording the percentage increase in spam email intercepted (This is your business metrics friend, since that number will never go down)
    E) Number of meetintgs with employees about improper email use.
    F) number of Company-wide software-license-compliance surveys, and number of improper installations detected.
    G) total number of top executive emails logged, with copies sent to several geographically distinct locations.

    If they want metr
    • Those are patch TUESDAYS.

      (Now, will I get flamebait for insulting myself?)
    • by tempest69 (572798)
      Nice list.. its nice to see a good counter for the quantifiers..

      I've found that the quantifiables are number of Servers, number of users, number of update requests, and number of unexpected downtimes..

      If the company is providing the right support the number of unexpected downtimes gets close to zero..

      The real crux is.. WHAT is uptime worth... it varies from company to company.. for google and microsoft the number is amazing.. for billsmitherspersonalwebpage downtime might be less noticed.

      Still Ha

  • Does he want to reduce the departments employee count? Or does he want to sustain it employee count?

    Mayeb he just needs to hire more and task to them, the metrics goals.

  • The sooner you find a job that doesn't suck so much, the more productive you probably were.
  • I suspect the closest model with math behind it is a futures contract.

    The things that a good sysadmin is supposed to do is make sure that all of the things that would threaten the relevant simple metrics -- capacity, uptime, etc -- are taken care of ahead of time.

    Clearly, it is more desirable to add servers a month or two before they are needed instead of after the server farm becomes unusable.

    So what you want, as your metric, is to track the future value of capacity and the future value of uptime.

    Got a tim
  • The basic unit of measure for any good admin is, of course, slack. You never notice when an admin is doing a good job. You only notice when they're not.
  • Units (Score:5, Funny)

    by ettlz (639203) on Saturday August 25, 2007 @04:41PM (#20356117) Journal

    How does one reasonably quantify admin productivity?
    In admons.
  • Base your (metric)work on how long things are NOT broken.

    i.e. Well I was 92% effective yesterday because I had to replace a switch.
  • by JosefAssad (1138611) on Saturday August 25, 2007 @04:44PM (#20356133) Homepage
    You aren't building automobiles or painting teapots. You are a support function and not a line function.

    You should have business plan objectives. These things are usually annual; there can be longer strategic objectives. If the person who set these things did it right, they should be measurable.

    What I'm trying to say is, if you're banging your head against the wall trying to figure out how your performance should be measured, your higher up didn't set your objectives correctly.

    This doesn't apply anywhere and everywhere. When the organization is in the business of IT itself, you might be measured differently since you'd then be contributing directly to the organization's core business. But from the description provided, it sounds like you're not.

    • by adrianmonk (890071) on Saturday August 25, 2007 @05:13PM (#20356455)

      You aren't building automobiles or painting teapots. You are a support function and not a line function.

      That is the best answer I've seen so far in this discussion. It mostly clearly illustrates that the question is framed wrong.

      There is nothing wrong with wanting to monitor and even quantify the value that an employee brings to the organization, but contrasting support function vs. line function perfectly illustrates the key point here: production is not the only kind of value that an employee can add to an organization.

      I wonder if a way of communicating this might be to make an analogy to something a financial person can relate to. You can use money to make several different types of purchases: you can buy durable goods, you can buy consumables, and you can buy more abstract things like insurance or legal advice. Don't take the analogy too literally, but system administration is like insurance or legal advice in that the value you provide is stuff like protection, security, planning, design, and order.

      I think if this were me, I would start by providing an outline of the responsibilities of the system administrator and the value that a system admin provides to the organization. This does include certain deliverables (like physical installation of hardware in machine rooms, installation of software, working and configured systems, documentation, answers to technical questions, training presentations, and code for scripts written to automate tasks), but it also includes a lot of work that doesn't have a deliverable (like diagnosing a problem and tracking down a patch from a vendor, or even convincing a vendor to supply a patch). It might be helpful to break the job down into types and subtypes of work being done and very rough estimates of the proportion of time being spent at each.

      So maybe the best plan is to educate the higher-ups about what the job really entails. It's quite possible they don't understand much about it, and some increased visibility into what is really going on could help with their understanding and thus their comfort level with paying the salaries of the people who do it.

      Also, there are deliverables that can be quantified. Creating user accounts, for example, has to be done repeatedly, and it takes about the same amount of time every time it happens. Auto mechanics deal with a similar situation and the industry has developed a list of tasks (such as replacing a fuel pump or brake pads) and standard times required to accomplish them. The computer world changes so quickly it might be hard to accomplish that, especially without industry support, but it seems possible to quantify some of what a system administrator does, because some of it is standard stuff.

  • The standard unit for quantifying productivity in IT is generally bottles/cans of Mountain Dew. This varies from "cups of coffee" the standard metric used in many other fields, but you can easily convert between the two, so it shouldn't be any trouble for your manager to share your productivity figures to his bosses in a manner they are more familiar with. To convert cans to cups of coffee, multiply by two fifths. To convert bottles to cups of coffee, multiply by two thirds.
  • To do system performance, just take pages/data/e-Mail/whatever served from a server, and divide it by the operational cost of the server.

    But how do you measure the value of the administrator?
    I guess I would take the value of what the system would do by itself, if it was just "left running", and divide it by that cost. (You would end up with less cost, but also less productivity, of course).
    And then, take it with say, a bare bones set up, with only a few, poorly trained administrators, and show what the cost
  • I suggest you take the task very seriously and try to find indexes on the internet from Gartner, Accenture, Cap Gemini, KMPG, or other major analyst/business consulting companies. Just using their names and logos in your reports/suggestions will get you a long way!

    After you have collected some reports, try to think of ways in which you can demonstrate your effectiveness. If you are in fact not very efficient, the boss is right in wanting that information - right? If you are in fact very efficient, you sho
  • Blind the bastards with science. Submit a load of white papers on things like function point analysis with a covering note explaining that this may be appropriate for measuring productivity in shell scripts. Ask for a really good job tracking and logging system that will cost a fortune to deploy, then estimate the resources required to implement it and feed back an estimate of the lost productivity while it is going in, plus the time to administer it. Find out what is the most expensive and complex server m
  • Systems Administration falls into several categories.
    Projects, Service requests, Patching, and user satisfaction are a few.

    Once you have an idea of what you do, define some SLAs with your customers and the metrics are easy from there.

    Now compare your defined SLAs to the following.

    Metrics:
    Time to ticket close?
    Were the requesters satisfied?
    Projects completed in the expected time?
    Resource allocation is at what percentage?
    Don't forget to measure your ongoing education and professional development. How much shou
  • You should view this as an opportunity to be able to rationalize extra help in the future! Let me give you an example: I'm an industrial engineer for a large 3PL. I put together labor models for warehousing opps on a day to day basis, and I do it by breaking down individual activities that the team will perform (stageing pallets, filling out purchase orders, etc.). I then assign hourly productivity rates to them (how many units I handle per hour), and assume that my employees will really only work about
  • "How does one reasonably quantify admin productivity?"

    Go see "Doctor Summeroff"

    High blood pressure from dealing with stupid people should do it. A couple of months might be enough.

    --
    BMO
  • Don't forget to make (honest) suggestions on how to improve efficiency. Even though the new boss might not go for your suggestions, it will prove to him that you are a valuable worker who is always seeking the most cost-efficient and optimum solution.

    Could you perhaps benefit from server virtualization which could potentially consolidate a number of servers - thereby reducing power and cooling costs? Or would it be possible to eliminate some niche systems which have high maintenance costs and which are re
  • by RazorJ_2000 (164431) on Saturday August 25, 2007 @04:55PM (#20356281)
    What you need to do is contact some other F150 companies and ask their senior IT admins/CTOs how they measure productivity. I work for a major investment firm and we have metrics for everything we do (even though we're private) because of two primary reasons:
    1. its how you improve, and
    2. its what our competitors do too.

    Its that simple.

  • by fishtop records (910593) on Saturday August 25, 2007 @04:56PM (#20356291)
    Assume for a second you had a perfect server farm. Its always up, backups are made, users are added and removed, etc. While we are at it, assume you have a staff of say two admins per shift, 24x7. That's at least 8 admins, probably more to cover holidays, vacation, etc. In this case, their productivity is zero, they have nothing to do. In reality, they are working their tails off, and deserve a nice bonus. So tell the PHB that productivity is not important, its problems. Its uptime, transactions delivered, average delay on transactions, etc. Get the Users to define what the 'requirements' are, and have the sysadmins deliver it. That is the measure of what is important.
  • Metrics (Score:4, Informative)

    by Codifex Maximus (639) on Saturday August 25, 2007 @04:57PM (#20356295) Homepage
    RailGunSally wrote:
    >We in the trenches have been tasked with providing 'metrics' on absolutely everything from system utilization to paper clip recycling.

    This pretty much says it all; your manager wants you to do HIS job. Shouldn't he develop his own metrics? He can ask you for ideas but he should do the work himself. As for metrics, I'd suggest downtime percentages for each machine. If the services are up and running and the machines are online providing service then that should be metrics enough.
    • Whoa, Nelly! (Score:4, Insightful)

      by TiggertheMad (556308) on Saturday August 25, 2007 @06:13PM (#20356945) Homepage Journal
      This pretty much says it all; your manager wants you to do HIS job. Shouldn't he develop his own metrics? He can ask you for ideas but he should do the work himself.

      You are right, but you are also skating on thin ice here. Asking someone who has no clue what is happening to set metrics is just asking for trouble....
  • They consider you only as good as your last mistake. The bosses don't want to know what goes on "under the hood". It just has to work. Anything less than 100% uptime is considered a failure in their eyes.
  • Uptime (Score:2, Interesting)

    by GuyverDH (232921)
    Keep track of uptime. Are the systems only down for scheduled maintenance? If they are down outside of scheduled maintenance windows, what is the percentage? Was it hardware or software or a mix (old firmware with updated driver requiring newer firmware), etc...

    Was the outage extended due to vendor timing? if so, maybe stock of typical spare components should be maintained to shorten the window.

    Typical maintenance like adding/deleting/unlocking user accounts, resetting passwords, printer maintenance,
  • and thats it.

    a sysadmin may rear a big belly and sit all day long for years, yet s/he can avert compromise of the system just one day and save even a fortune 50 company from total chop busting - like 100.000 entries of customer records being stolen.

    therefore forward your phbs here, and make them read these and learn that one cant direct an i.t. unit without being an i.t. person. its a totally different, magical world.
    1. Number of lusers not dead at end of shift, no matter how much they deserve it.

    There are no other metrics that matter.

  • Its a simple equation.

    productive_hours_per_period = ((number_of_hours_per_period * number of employees) - (number_of_hours_computers_are_down_or_unavailable * employees_affected)) / number_of_hours_per_period.

    10 employees, a full week, only one person looses computer access for 4 hours

    productive hours = (40*10) - (4*1) / 40 = 400-4 /400 = 396/400 = 99% productive

    perfectly reasonable

  • Here are some things you can track:

    - obsolete accounts archived/deleted
    - phone passwords changed
    - exit interviews logged

  • Simple.

    Use a ticket system. I help customers setup RT.
    (http://bestpractical.com/rt/)

    How does that help?

    Well, it allows coordination within a group, or shifted workgroups to identify and track changes in systems, and the status on certain things.

    For example, did you change the iptables entries on the router for the primary hub in the network?

    You then write a RT ticket entry on why, and what you changed.

    Then everyone in your group gets a copy.

    That way if something stoped working, or you made a typo people k
  • produce a metric that proves that when you're doing your best job everything's running smoothly and you're sitting on your hands doing nothing ... perhaps an inverse correlation to 'hours spent on /. or playing warcraft'
  • I have a formula (Score:4, Interesting)

    by KermodeBear (738243) on Saturday August 25, 2007 @05:16PM (#20356473) Homepage
    Hours Worked Fixing Problems divided by Hours Worked Doing Routine Work

    The lower the number, the more efficient the sys admin is. A good sys admin doesn't have to do anything, because everything is already set up and working. If the admin is constantly fixing servers, bringing them up, restoring data from backups, etc., etc., etc., then he isn't doing his job. If the majority of his day is spent sleeping in his chair and responding to the occasional email and things are running smoothly, then you can't ask for anything more.
  • Sounds simple to me (Score:5, Interesting)

    by mrami (664567) on Saturday August 25, 2007 @05:24PM (#20356547) Homepage
    1) Ask him what he wants to hear
    2) Tell him what he wants to hear.

    If you can't reasonably tell him what he wants to hear, tell him how much it will cost to produce what he wants to hear.

    This is not a technical consideration. This is a political consideration. He already has an idea of how to cover his ass. Give him the asbestos he wants.
  • by LargeWu (766266) on Saturday August 25, 2007 @05:26PM (#20356565)
    ...no matter what your boss says. Just don't do it. It is management's responsibility to come up with metrics. If they can't do that, they're not qualified to hold their position, and frankly, I would tell them to their face. It might get you fired. But I've taken the "this is not my responsibility" tack before with some success. The reason this stuff happens is because workers allow it to happen, and if you don't stand your ground once in a while they will just keep shoving this type of crap at you.
    • Re: (Score:3, Insightful)

      by argStyopa (232550)
      You know, that's a very noble thought. But the reality is, if you simply refuse, you allow the PHBs to define their OWN metrics, which can be orgasmically stupid:
      - 1 point for every spam mail that the PHBs get that they don't want.
      - 1 point for every time a website that they want to get to is blocked
      - 1 point for every time they see anyone in the company surfing a non-business website

      You let them define the measures, and you'll be looking for a job. It's a truism that they DON'T UNDERSTAND WHAT YOU'RE DOI
  • by crmartin (98227) on Sunday August 26, 2007 @12:07AM (#20358947)
    ... because a system administrator isn't producing anything, any more than a safety engineer is. They're there to preserve certain non-functional properties of the system. The appropriate measure is how much of the time the system meets or exceeds the service level agreed to, and what the cost is in staff hours to do that.

    Trying to turn it into a "productivity" measure will have the inevitable effect of maximizing whatever is being measured, whether it's LOC of scripts, service tickets closed per hour, or kumquats per fortnight.
  • by bokmann (323771) on Sunday August 26, 2007 @05:10AM (#20360625) Homepage
    The metric should be 'number of times the sysadmin has to be consulted', and it should be driven as close to zero as possible.

    I might get moded 'funny', or 'flamebait', but I'm serious.

    Think about it. When is a sysadmin needed? When there is some kind of crisis. "I can't get to the internet", "I can't check m email", "My computer thinks I might have won a million dollars", "I lost that important project file". A good sysadmin will prevent these things from ever happening, and when they do happen will have them resolved quickly, without a lot of technobabble or attitude (like the SNL skit guy), and will fade into the woodwork. Ironically, the middle-of-the-road IT guys are often thought of as heroes by the staff they support. They might be thought of as the firefighters, but unfortunately, they are also often the pyromaniacs.

    Other useful metrics:

    If you don't already have a ticket support system, get one. It will generate useful metrics for you. Some useful things out of it would be:

    - The AGE of the OLDEST OPEN SUPPORT TICKET. Proves you aren't dilly-dallying

    - Number of Priority 1 Tickets opened per quarter (see above - should be as low as possible)

    - Everything you do, you should open a ticket for. Upgrading that linux box? Ticket it. Updating anti-virus definitions? ticket it. From this you will get:

    - Nunber of tickets open per day

    - Nunber of proactive vs. reactive tickets (tickets you opened vs. someone else opened. You should get credit for fixing things before they become an issue someone notices.

    And if the bean counter needs some big numbers to justify things, just count up stuff that the logs on public boxes find. Seriously - have you ever looked at the stuff from logwatch? Just yesterday I had 2163 unique failed attempts to log in as root, not to mention all of the other assorted hackery it catches. "Number of successfully defended intrusion attempts" is a metric that will scare a bean counter enough that he won't take the liability of getting rid of you.

  • by koehn (575405) * on Sunday August 26, 2007 @02:10PM (#20363613)
    Part of the problem is that the sysadmin job is somewhat reactive (like the plumber who responds to problems), somewhat preventative (like the security guard keeping the bad guys out), and somewhat prescriptive (like the carpenter adding on another 20000 SF of building). Try to divide the general role into these different categories and come up with metrics for each. Coming up with a single metric will be nearly impossible because of the diversity of the responsibilities of the job.

    Find other jobs that have similar, "preventing the negative" jobs. How would you measure the security guard's efficacy?

It is much easier to suggest solutions when you know nothing about the problem.

Working...