The ads are not "relevant" to you, they are what advertisers want you to see.

Those things aren't mutually exclusive.

The advertisers don't have enough information to to give you really relevant ads.

Then isn't the solution, if you want what the GP professes to want, less privacy?

Best thing to do is block ads and just google when you want something.

Ironic that you're citing one of the biggest data-aggregating advertisers out there today as a relevant source, when you appear to be arguing against exactly what they are doing to present you with those results.

I'm not much interested in Hollywood versions of classic books, ever since Peter Jackson took a book that is much shorter than any of the books in the Lord of the Rings trilogy and stretched it out to what promises to be a trilogy in it's own right.

I'm not saying it's right for The Hobbit, particularly, but there's nothing inherently wrong with taking a short book and making a long movie, or series of movies, out of it... books are dense, most are given little chance to have all their themes, sub-plots, and characters portrayed on the big screen. It's not always wise to do so, but such a common objection to adaptations is "Aw, they cut my favorite part from the book!" that I think most fans would prefer stretching their favorites out if it meant fitting in more of the source.

Again, not exactly what Jackson is up to, but nothing at all wrong with taking a short book loaded with story and making a movie long enough to do it justice.

...regularly sweeping money into a bank account will also get your account frozen.

I'm not saying I trust PayPal all that much, but this is simply untrue. I have businesses that use a couple of different PayPal accounts, and regular sweeps are de rigeur for us, and we've never had any account frozen by them.

Part of the reason we sweep them is to guard against just that possibility, however.

It's also important to sweep the account you are sweeping into... usually, the wire transfer capability works both ways. So they can, without additional authorization, suck funds back out of your bank account. (if anyone happens to know a bank that will let you prevent this sort of outgoing transaction, I am all ears)

If the funds aren't in that account, you could get hit with an NSF charge from your institution, but you'll have an easier time arguing with them about it than with PayPal, and a $30 bounce charge is a lot less than $50,000 or whatever amount PayPal might decide to sit on instead.

You know, I agree with your sentiment entirely, which is why I feel bad calling this out:

A serious firewall would be a good start.

It's really not. In fact, the firewall is the last thing you should think about.

That's not just because there are so many exploits right now that are for all practical purposes indistinguishable from normal traffic, although that's a good reason, too. It's because the best defenses are always layered defenses, and those start from the inside out.

Far too often I see people begin and end at the firewall. Even if they intended it only be the start, they're thinking rarely progresses much further into the network... why should it? They think about all the stuff the firewall is going to catch, and it seems to take care of so many problems it's hard for them to imagine what else they need to do internally to lock things down. They've succumbed to the "enumerating badness" fallacy, classically described by Marcus Ranum in his must-read Six Dumbest Ideas in Computer Security.

That's exactly backward, though. Where you want to start is at your core data, with the assumption that everything else has already failed, and what can you do to mitigate the disaster of penetration at that last possible level.

Then you work your way out, doing the same thing at each level.

Because almost no one does this, firewalls today are the thin, crunchy shell over the juicy taste explosion of vulnerable systems that crackers crave.

Yeah, but the only "problems" with plastic bags were also with the users. So why try to pin the blame there now? Just regulate cloth bags, too!

I'm waiting for this whole exercise in un-scientific nanny-stateism to run full circle. My only problem is that I no long have a state-approved bag in which to put the popcorn.

Hansel and Gretel shove a little old lady into on oven and broil her, and that's been broadly accepted as children's fare for two hundred years. A little justifiable homicide shouldn't be a big issue all of a sudden.

As others have said, it's perfectly possible to get a job in IT without the corresponding degree. But if that's what you're interested in, and you're looking at CS programs, why not do both? Apply or start in on the CS degree and simultaneously look for a job in the industry. The fact that you are at least starting down that path educationally might assuage some potential employers who might otherwise look at your move as one tinged with desperation ("Couldn't get into grad school, now hopes we're going to pay him for his tech hobby while he re-groups and looks for another psych program... no thanks!").

I wish I could tell you more about the job environment and the relative merits of comp-sci degrees these days but I suspect they've changed since the late nineties when I got into it. That was the wild west, and employers cared far more about what you could do than what your degree was in. I was already working in IT by the time I started college, and I consciously decided against a CS degree... at the time, the degree programs I was looking at were hopelessly outdated compared to the technologies I was already working with.

I got my degree in English instead, and I've never regretted it. In fact, communications skills have been some of my most valuable assets when competing for jobs. If you have practical knowledge and the ability to articulate it, you're far more valuable in most IT organizations than a geek who may know more, but can't communicate it. So your psych degree might actually prove more useful than you think.

But if you have the resources to go on and get a CS degree also, and you really want to work in the IT industry, then you should go ahead and get started on it.

"Considering how much talk there is of an enterprise false flag operation, if it was ever intended it probably won't happen because of all the talk about it."

That's just what they want you to think!

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).