I'm not sure how email would help. I guess you mean the system would email you once a day saying that the monitoring system is working and if you don't see the email you know to check into it. The monitoring system I use has a higher SLA than 24 hours.
Usually folks divide the monitoring work among two servers and each server monitors the other. Or, you "meta monitor"... a monitoring system that just monitors the monitoring system. Then you get a third-party to monitor that. Then it is turtles all the way down.
"Sysadmins and devs shouldn't really care if they have five generations of hardware."
I wish it was true. sadly there are some services where scale and latency is so carefully measured that individual software releases are rejected if performance gets worse (or unacceptably worse, etc). In these situations you need to test on all hardware platforms. It is much better to have fewer platforms: Optimally: the one you are migrating off of, the one you are moving to.
For desktops... have you ever tried to maintain an Windows or Linux desktop environment with more than 4 "standard desktop configurations"? It becomes a nightmare. If you have a single "gold image" you blast to all machines it makes the task harder; if you stay with the vendor's OS and try to maintain it "forever" it is even worse.
One thing that makes virtualization a "win" is that the virtual box looks like a single hardware platform. It reduces testing, etc. However, then you still need to test the virtualization software on all hardware platforms... so you've made things easier for everyone but that team.
A more detailed reply:
3) really? the core of devops is to be data-driven in your decisions. how can you decide if you are maintaining the right uptime if you don't measure it?
8) I agree with you, as does the text. I think you may have reversed what I wrote.
9) The good ones write so that they "think before they do". On a larger team it is important to communicate what you are about to do, or what you have done. I prefer to write mini design docs. The team I'm on does this and I like it so much I want to spread the word.
11: Again, the team I'm on does this and it works so well I want to spread the word. I see I need to expand this out to explain why, not just how.
14: I'll clarify that the point is not to make big changes on your production system. Whether it is qa+live or a zillion steps including dev, qa, UAT, pre-prod, canary and prod. As long as it isn't zero steps.
22: refresh policy: This is for PCs (non-servers). I'll clarify.
23: The last part makes your point. I'll rewrite to make it more evident
28: "Anti-malware? Really? In 2011? I'm sure you have a whole blog post". Yes, I do: http://everythingsysadmin.com/2011/04/apt.html
Thanks for the reminder to add a link! (and if you are blown away that I had to list this, you can imagine my surprise about finding sites that violated this one!)
I read it this January after hearing it mentioned so many times. I was very impressed. My impressions were:
1. Ah, that's what it would have been like to attend a GOOD university!
2. Much of the systems knowledge I learned the hard way are clearly explained here. This would have jumpstarted my career by 10 years.
3. No current first-year student would sit through this. Though, it should be required reading for seniors.
OH MY GOD! THIS GUY WANTS ME TO CHANGE THE WAY I WORK!
I"VE BEEN WORKING THE SAME WAY FOR 20 YEARS
YOU CAN"T MAKE ME CHANGE!
CHANGE SCARES ME!
20 YEARS AGO MY TERMINAL DIDN"T HAVE LOWERCASE, COLOR, OR WINDOWS. WHY HE WANT ME TO CHANGE!!?!?
(Damn, I've never seen a group of people so change-adverse and closed minded about trying new things as the software developers that are in the business of making new stuff! Geeze! Download it and give it a try before you post a comment!)
As the co-author of TPoSaNA I am flattered but for the question at hand, I'd recommend a different book. Time Management for System Administrators from O'Reilly is more in line with what he's looking for. http://www.tomontime.com/ and http://www.amazon.com/o/ASIN/0596007833/tomontime-20 for more info. (Of course, since I wrote this other book, I don't mind recommending it :-)
I worked at AT&T / Bell Labs when those commercials were flooding every show on TV.
Bell Labs was upset because AT&T made those commercials without consulting us. A PR company thought up all the ideas. We had zero projects internally working on such products.
That's why those products came from EZPass, not AT&T; Skype, not AT&T; Apple iPad, not AT&T.
Even thought it wasn't AT&T that brought those things to market, nearly all of them do exist today. It is a beautiful thing. I feel lucky to be living in what my co-workers call 'The freakin Buck-Rogers-would-be-jealous future'.
Tom
PS. Oh, and the one where they guy has a Dick Tracy-style video-phone on his watch? Well, soon after AT&T bought McCaw Cellular my friends in the cellular phone communications research area were asked to work up an explanation of why such a thing can't exist and isn't likely to exist any time soon. It turns out that after AT&T bought McCaw they (McCaw) was very unhappy to learn that the wrist-phone was a figment of a marketing person's imagination and not something actually being developed at Bell Labs. Ooops. I hope they didn't let themselves get bought by AT&T just because they thought we had that product in the wings.
Usually folks divide the monitoring work among two servers and each server monitors the other. Or, you "meta monitor"... a monitoring system that just monitors the monitoring system. Then you get a third-party to monitor that. Then it is turtles all the way down.