Well, that's job security, innit?

As I was idly paging through the comments thinking about how many of them were jumping to outlandish, unsubstantiated conclusions about why the poor submitter was being asked to come up with metrics, I also realized that pretty much nobody (in the finest tradition of Slashdot) has bothered to answer the actual question: "I'm wondering what people opinions are on what good metrics should be in regards to mttr mtbf etc." I think I misunderstood this at first as well... in light of what he does say about the goals ("...determining if we are performing above or below what is considered optimal") I don't think he's asking what metrics to measure or whether or not we think doing so is any good, but instead what reliable industry benchmarks are for those metrics, so he can tell his boss what is "optimal" or not about their operation.

Well, shibby, sorry, but I don't think there are such things, or at least none relevant enough to take back to your management team. The only way to get anything meaningful out of metrics (obviously a lot of other posters are arguing you'll get nothing meaningful out of them; I disagree, but it may not matter either way if those are your orders) is to establish baselines for your organization and track future performance against those. It will take a while and it will have to be viewed in context to be worthwhile... important points to make when you are presenting your findings to management.

I'm being optimistic and assuming genuine business goals and a desire to understand IT operations on the part of non-technical managers are the point of this request, not some haphazard effort to chop down a three-person department, but it is also worth passing along some of the critiques that are being posted here. On the other hand, if you don't already, you should understand that not all managers are buggers, and that many of the better ones have legitimate reasons for trying to understand what is going on in their IT department. We often forget how mysterious what we do looks to the un-initiated, and I have seen enough poorly run IT departments to sympathize with non-technical managers who are grasping for the tools to understand theirs. The point being, getting defensive and obstructive in the face of these requests isn't always the brightest idea; instead, you can look at it as an opportunity to present some of your perspectives and difficulties to managers who are finally prepared to hear about them (after all, they did ask!). They may not have the time or horsepower to learn everything you do in depth, but it is possible to analyze operations based on the right sort of shorthand.

The cynics may be right; only you will know. But I've seen companies run down by their IT departments as often as I've seen IT departments run down by the management team, so performance concerns on both sides are well-founded. Anyone who thinks their manager shouldn't ask for a suitably abstracted toolset for judging performance is asking for a stupid manager.

It's not unusual for management to be clueless about what exactly it is that their IT staff does on a daily basis, nor is it unnatural that they should take an interest. Often, it's a good sign when they actually ask the guys doing the work what the metrics should be... it indicates some degree of trust, and they haven't simply read an "IT Management for Dummies" book over the weekend laying out some arbitrary system that isn't going to fit your organization.

As a more cynical commenter points out, it also provides the opportunity to create a measurement system that you can game to make you look good. But I think it isn't a terrible sign that the bosses care what their employees are up to. It may represent an opportunity to explain what you think is important that perhaps they hadn't considered previously.

Bad metrics suck, good metrics are useful data.

As folks have already mentioned, time to answer and time to resolve are both important, and I think you have to watch for re-opened as well to curb "how fast can I shove this under the bed?" resolution games.

My favorite is average tickets per user, though. Particularly on a small team, what you really want to gear your measurements toward is preventing incidents in the first place. It is helpful to know what your overall ticket volume looks like, then, and to aim to decrease it over time in the same way you might try to decrease time to answer and time to resolve. That's important, because as the previous article suggests, if you will get what you measure... and your overall goal should not simply be to answer tickets faster and resolve them more quickly, but to not have as many in the first place*. Every issue represents a waste of somebody's time and therefore corporate resources that could be put to more productive uses. Steadily decreasing mtta and mttr are nothing to cheer about if your ticket count is increasing.

But you can keep it simple. You can drown yourself in metrics and lose sight of why you're tracking them and what you really want to accomplish. You may not really need any more than these few; better to start small and add what you need when you need it. I know there's always tension over getting a system in place that can capture what you need for historical purposes when you realize you need to know something new down the road, but resist the urge to over-collect. Half the time you won't need it all and are just wasting time getting it in the system.

* There is a caveat to this; in some organizations, I actually DO want to see an increasing ticket/user count, at least for a time. This is something I shoot for when relations between IT and users have broken down badly enough that users have stopped reporting problems to IT because they feel it's useless, and their issues are never resolved anyway. In those cases, a rising ticket count can represent an increasing trust level, which is good. You generally won't fix issues you don't know about.

Zittrain's been peddling this load of manure argument for a long time now, and as far as I am concerned he has been consistently disproven time after time. It's not that what he points out is not a factor, so much that he ignores the rest of the story, which is that the "generative spirit" continually finds ways to break down the walls, create alternatives, and generally keep innovating despite (and at times, because of) the controls the gardeners put in place.

He equally ignores the fact that the vast majority of users of open technologies never did, or ever would have, engaged in any truly generative behavior. And there's nothing wrong with that. What was a problem was that the price of keeping things open was often inhibiting the normal, consumptive uses of that larger group.

What we have now is by no means the perfect system but it's considerably more balanced than it was before, and there's no evidence whatsoever of the epic collapse of innovation Zittrain has been forecasting for years.

You might have thought that getting burned badly once already might have lead to a renewed emphasis on security and a commitment to best practices in securing important data. Huh. I guess the "can't happen here" clock must have reset already (as well it might have, since I only see one other comment here on Slashdot, of all places, indicating that anyone else remembered the kerfuffle over the Half-Life 2 source theft).

Because it's not a bad question. You're getting answers from a lot of people who are either so buried in the deeply technical side of things or locked into the past that they don't really understand it. Having shepherded a couple of dreamy startups through this phase, though, I don't think you are either crazy or necessarily under-qualified to make a successful site. To be honest, it no longer takes the hardcore technical skills that it once did, if in fact it ever did. Technical competency is over-rated by technical people; there are super-successful web businesses out there that started out (and sometimes even continued) with really shoddy coding and infrastructure setup. Craigslist and PlentyOfFish come to mind as examples. I know several others without such name recognition but which nonetheless did quite well for their owners, who slipped along with very basic programming skills and almost no hardware competency whatsoever.

Having the ability to outsource your infrastructure makes it even easier to do this today. I'm going to stay away from the "C" word because it's so shot through with marketing dross and misunderstanding now. But it's entirely possible to effectively do away with almost all the Windows admin if that's not your strength by going with hosted services. You are probably a long, long way from having to worry about Windows/LAMP stack comparisons even at your stated traffic goals, and using a hosted service will abstract that to the point where you aren't going to need to worry about it anyway. I wish you the best, but the reality is also that few sites make it big anyway, so while scalability is certainly something to consider at this stage, you shouldn't allow it to hobble your choices excessively. If you actually get there, it's almost certain you are going to have both the resources and the need to rip everything up and re-do the entire site from scratch once or twice along the way anyhow. You can re-tool then if you must.

Abstracting hardware doesn't absolve you from making other design choices that will afford scalability, and you should have some understanding of what's going on under the hood so you can make those appropriately. But you don't need all that to get started. I don't know anyone, at any skill level, who actually correctly made all the right choices on their first pass. You'll be learning along the way. That's actually an advantage; tech is filled with people who found their comfort levels and can't adjust to newer models.

It sounds like you are asking as much about your dev environment as production. I would say "yes," move it all to a hosted environment. At this stage, you don't need to be worrying about the underlying nuts and bolts. Get up and running quickly and easily. Be flexible and make adjustments along the way. You probably don't even need to go with a full-on PaaS provider right now, either; get a cheap hosting plan with a company that will help you scale when you need to. Depending on your service requirements, you can go with best of breed hosting to find the most efficient solutions for your various problems... use a SaaS vendor for version control, use a CDN for content hosting, and so on. It's cheap, it's fast, and it reduces the time and cost of failure. Failure is undoubtedly something you will run into a few times along the way. That's going to happen whether you are a technical genius or just some schmoe with a good idea. Build it in to your plans; don't over-invest (whether in time or money) in things until you can see better how things are working out.

If you have a good idea, don't be too afraid if you don't know what you are doing. A lot of the best people don't. One of the most valuable lessons you can learn is what not to spend time on, and a lot of things that certain folks here on Slashdot hold dear are things that you don't necessarily need to spend a lot of time on right now. Prove your concepts first. If you turn into the next Facebook, you can worry about infrastructure then. Until then, don't let the idea that you need a Facebook-worthy infrastructure before getting started to hold you back. Re-format that VM server into a games machine and go rent time elsewhere.

Real nerds who spend their days up to their elbows in Internet plumbing knew exactly what it was about at first glance.

IANAL either, but I know that passing the bar is a state-by-state test; you don't just take one test that covers the laws of all the states, you take a test for the state you are going to be licensed in (or the federal version, but that only covers federal law). So it's entirely reasonable he wouldn't know about the precise details of the law in "most states" even if he picked up a general knowledge in law school.

It's a mystery to me what "satisfactorily stable" consists of for people who point out availability as a problem with cloud solutions. As a rule, enterprises don't publish their internal downtime statistics, but I can tell you that for a large chunk of them, it's far worse than the occasional Gmail outages. And no one who makes that argument ever seems to look at the necessary companion to stability, which is cost. What does it cost you to be satisfactorily stable running internally? For most businesses, again, it's a lot more than an Apps subscription, for a lot less stability.

As for off-line access, Gears is already available to allow offline access to Gmail, but if you don't like that, you can just as easily configure the same sort of standard POP3 or IMAP client-side application that you would use with any other mail service, with the same capabilities should your connection be severed.

It also seems to me that people over-estimate what actually gets done in many offices when network access goes out, regardless of the off-line capabilities of clients, but that's another arguement.

Ironically, I think you have illustrated exactly why the desktop/laptop will be dead.

Similar arguments have been made for every outmoded technology by people who can't quite grasp that the world constantly changes around them. The only objection you are really leveling is already being attacked from both angles (areas with little or not Internet connectivity have been shrinking rapidly for a decade now, and many SaaS companies are providing basic caching and local operation of their services via browser plugins). We'll always still use something with some local processing capacity and storage to access cloud-based services, and in that sense, of course the "computer" is not dead... but it won't be the same processor/storage behemoth that we currently think of as a desktop or laptop. In fact, that's why they are calling those things you mention "netbooks"... because they aren't really a laptop or a desktop, no more than a horse and buggy is a car.

There are a load of fine suggestions in this thread which are well-constructed for logical minds, but I can't help but feel this tactic is best answered in kind: a gut-level fear-check. And so the best response isn't to sit down and try to explain the perils of security through obscurity, nor to try to sell additional security services, or to discuss patch cycles and the like, but instead to simply ask the client this: "When's the last time you heard on the evening news anything about a new virus, exploit, or vulnerability discovered in your Linux software? Now, how about Microsoft software?"

Overly simplistic? Absolutely. Sure to make them reconsider what the Microsoft vendors are trying to sell them on its supposed security? Definitely.

I think what it really shows the perils of is piling additional "features" on top of a perfectly good product until you've ruined what made it good in the first place and turned it into worthless crap. Search should be simple: give the user what they are looking for. All the other extraneous stuff they are loading it up with is bound to interfere with that basic requirement at some point.

I see this in mature development projects all the time. At some point, people get a pretty good product working, but they can't repress the urge to continue "improving" it... it can be boredom, wow factor for marketing, or just plain stupidity, but few people or organizations seem to know when to quit messing with a product that already works well.