Personally, I have NEVER seen an e-mail system that has had DR or Failover.
I certainly have. I've even managed one that's gone through a catastrophic failure. It was a Lotus Notes/Domino-based system, and while god knows that platform is far from perfect, one thing it does pretty well is replicating users' mailboxes over a WAN with very little extra effort required on the sysadmin's part.
Beyond DR, ask an even more important question: In the event of disaster, how quickly does e-mail come back up on-line? Is it the first system recovered?
In my current organization it's the 3rd application to come back on-line in event of a disaster. Administration wants it available for communication during disaster recovery since it provides a good audit trail (phone calls don't).
Payroll, on the other hand, is not on the criticality list at all. Our DR strategy is to write paycheques by hand based on people's last pay stub (that info can be recovered quickly from backup tape) and square up discrepancies a month or two later.
This is the first time I've noticed your sig line, so please excuse me if someone has already answered your question.
Who the f*** decided that sentences on the Internet shall no longer be formatted with two spaces after a period?!
Actually, the two-space convention was an invention of the fixed-pitch typewriter age. Proportional typefaces (which preceed the typewriter by centuries) generally include a bit of extra space after the period. When typewriters became common, this was simulated by hitting the space bar twice. Now that we have computers, fixed-pitch fonts are on the decline and the original practice of hitting the space bar just once is returning. Nothing to do with the Internet.
In that regard, the new version of DB2 looks kind of interesting. (I'm not an IBM-er, nor do I currently use DB2). Here's a marketing pdf: ftp://ftp.software.ibm.com/software/data/pubs/broc hures/db2_9_overview.pdf. It's still the DB2 rdb, but it stores the XML hierarchically and cross-indexes it. It'll be interesting to see if it works in the real world.
As a database guy in a large corporation, I think it's great that employees can create small things in Access.
That's all well and good until, a few years later, you end up with critical business data scattered over dozens of Access databases all over your enterprise. Some of them live on C: drives and don't get backed up - guess what's gonna happen when that drive crashes? Some of them have a password on them, known only to the guy who created them - guess what's going to happen when he gets hit by a bus? And of course these accidents will happen the day before the auditors come for their annual visit. Been there, done that. My users don't get Access. If Excel won't do the job for them, they can put their request into the Project queue. If they don't like how long the Project queue is, they can tell their C-level to lobby for a budget increase for my C-level.
Linux was the absolute exemplar of slowly developed high quality low cost code....
Ummm... you're agreeing with the parent, then. Linux is high quality and low cost, but definitely not developed quickly. You have your two out of three.
We're talking about the United States, where this total-control-of-the-weapons scenario is impossible to achieve if for no other reason than the sheer size of the place.
Um, Canada is a lot bigger than the US, and it works OK there. It would work even better if there weren't so many hand guns in the US that they migrate to the border cities almost by osmosis. I don't think it's a matter of size. It's more a matter of historical, cultural, and legal development.
Yah, it's not a very professional looking site. That's just how it works when you have a limited budget. I think your expectations and standards are a bit to high for an organization that just started. If they still have the same problems in 6 months, I'd be a little worried.
I respectfully disagree. IMO that's no excuse for publishing anything with blatant mistakes. Quality is cheapest when it's built in at an early stage. Retrofitting is always more expensive. In this case, it's expensive at least in part because you'll never sell the idea to the PHBs of the world if the presentation has too many errors; it suffers a credibility gap right up front. You've lost part of your potential market right away, simply through haste and carelessness. Two rules for success (or, at least, to give you a better chance at avoiding failure): Always dress better than you need to, and always write better than you need to.
But how do kids get their interest sparked in the first place? Nothing beats booting up a computer and having a BASIC prompt staring you in the face, daring you to type in your first "10 PRINT 'I AM COOL' / 20 GOTO 10"-type program.
If you're running any recent version of Windows, paste the following into Notepad and save it as "test.vbs" (use quote marks to ensure it doesn't append ".txt" to the end). Then double-click it.
I tried too with similar results. There's also a briefer on-line description here for those who don't want to look at the paper-based article in Discover - though it really is worth reading. It's worth stressing: The Thermal Depolymerization process can convert anything with a carbon atom into petroleum, safely. Even dioxins. This story should blow the heard-it-all-before "Greasel" story right out of the water. There's no justice on/.
Oh come on. "-1 Flamebait"??? You know there are going to be sick jokes coming out of this event. It's part of the human reaction, functioning psychologically to distance oneself from tragedy. Happens all the time. I'm just attempting to point us to some of the more clever ones from last time around. If you're old enough to remember, there were a lot of sick ones that were not clever at all. Let's aspire to cleverness, at the very least.
It is important to bear in mind that the UFO phenomenon kicks off in 1947, in the form we now recognize, as a result of observations made by Kenneth Arnold over Mount Rainier. Paradoxically, Arnold didn't see "flying saucers," rather, he witnessed a formation of nine boomerang-like devices, or "D"-shaped with the straight section aimed backward (the reader will recall the comments made by Justo Miranda regarding this most aerodynamic shape). It was a journalistic error that assigned Arnold the term "flying saucer." What really matters is that the saucer myth spread quickly across the U.S., and then throughout the rest of the world.
Essentially, in ISO9000-speak, Processes are higher level descriptions that often cross organizational boundaries (more than one team, or workers and management). Processes may be implemented via one or more procedures, the step-by-step recipes that pertain to the McDonalds example you site. I agree that an experienced sysadmin doesn't need procedures on how to change a tape. But you do need an agreed-upon process that tapes will be changed periodically and data will be retained/destroyed according to a schedule negotiated with users, stating which team is responsible for doing what part of the job, and how we are going to know that it is in fact being done.
Processes are the way policies are implemented and controlled. Procedures are the way processes are implemented and controlled. In a small shop, or in trivial cases, these may overlap quite a bit. But in the context of an article about how serious it is to be a Sysadmin, I think it should be mentioned that there's a great deal of literature and structure out there, so there's no need to go reinventing the last 20 years' worth of wheels.
By the way, does anyone know why this was posted in the Developers section? From a Sysadmin's point of view, developers are just another kind of user, and sometimes rather whiny ones at that.
Maybe you shouldn't work in IT then. Leave it to those of us who enjoy tinkering, and playing with new technologies.
You're lucky then. Most SysAdmins in big shops don't get to play with new technologies, since most companies don't adopt new technologies. They wait until they become established technologies. Lots of Microsoft-oriented shops, for example, are still running Windows NT 4 servers, and some still have Windows NT 3.51. There are still Linux boxen running pre-2.0 kernels in production. It's a matter of Total Cost of Ownership and Return On Investment. If someone's paying you to "tinker" and "play" then you are indeed blessed. But not at all typical.
I would have liked to see the article talk more about the processes SysAdmins should be following. If he's really working for a major service provider then where are his hooks into:
Change control?
Incident management?
Problem management?
Change window?
Service level negotiations?
Capacity management?
Security management?
As long as all the SysAdmins seem to be making it up as they go along, we will continue to be marginalized and geek-ified by management. Try on for size:
Heck, even Microsoft is trying to get into the picture with its Microsoft Operational Framework, a kind of embrace-and-extend on ITIL, though I don't know of many places that are actually using it.
It's not that the SysAdmin necessarily has to manage these processes - though in a small shop no one else will - but he/she/it needs at least to be able to talk the language and understand the processes that the IT Manager has set up. And if you are managing the shop, then this is your job. You must know this stuff as a matter of professional responsibility and "keeping up" in your field.
A 20 min. presentation to the other managers on Best Practices and Processes in IT Management will gain you a lot of credibility and help lift you out of the geek gutter. There are decades worth of lessons that have been learned the hard way and documented into these processes. When you can demonstrate to management that you are drawing on a substantial body of knowledge that is geared towards improving service and reducing total cost of ownership, you will gain their respect (assuming that you care about their respect).
Beyond this, I want to emphasize an excellent point that Sanders makes in the article. The SysAdmin job is one that is invisible if you're doing it right. A good day at work is a boring day. Excitement is a sign that something has gone wrong. You should structure your environment to be as boring and reliable as possible.
Too many SysAdmins live off the adrenaline rush of fixing a broken server while everyone else in the organization sits on their thumbs waiting. That's costly for the organization, but ironically is the easy way out for the SysAdmin - you don't need to be disciplined or structure your time or do any planning or thinking, just jump from crisis to crisis. It's much more challenging to turn it into a boring desk job where most of your work is pushing paper and the machines pretty much take care of themselves. But guess which option is better for the organization's mission?
Once you do get to that Nirvana state of boring life, you can strategize how to produce some measurables so you can blow your department's horn at the monthly managers meeting. Because if you do your job well, with the result that your work is invisible, they'll cut your funding unless you keep in their face on a regular basis.
once had a physics professor who told us routinely that if we were not able to explain a concept to an average person using normal language (no math, physics jargon, etc) then we did not understand that concept ourselves.
That might work for the simpler disciplines like physics, but it doesn't work for the more complex disciplines like the social sciences. And if you don't know that sociology is more complex than physics then you haven't been keeping up with the literature on the difference between "hard" and "soft" (i.e. complex) sciences - so don't bother replying, let alone moderating. Informed discussion only, please.
Slashdot Mirror
Payroll, on the other hand, is not on the criticality list at all. Our DR strategy is to write paycheques by hand based on people's last pay stub (that info can be recovered quickly from backup tape) and square up discrepancies a month or two later.
--
.nosig
--
.nosig
--
.nosig
--
.nosig
--
.nosig
Integration with SharePoint might be one. I think this promises to clean up team authorship/editing & version control quite a bit.
--
.nosig
That's all well and good until, a few years later, you end up with critical business data scattered over dozens of Access databases all over your enterprise. Some of them live on C: drives and don't get backed up - guess what's gonna happen when that drive crashes? Some of them have a password on them, known only to the guy who created them - guess what's going to happen when he gets hit by a bus? And of course these accidents will happen the day before the auditors come for their annual visit. Been there, done that. My users don't get Access. If Excel won't do the job for them, they can put their request into the Project queue. If they don't like how long the Project queue is, they can tell their C-level to lobby for a budget increase for my C-level.
--
.nosig
See Lotus Notes/Domino for this. Still my favourite.
--
.nosig
Ummm... you're agreeing with the parent, then. Linux is high quality and low cost, but definitely not developed quickly. You have your two out of three.
--
.nosig
Um, Canada is a lot bigger than the US, and it works OK there. It would work even better if there weren't so many hand guns in the US that they migrate to the border cities almost by osmosis. I don't think it's a matter of size. It's more a matter of historical, cultural, and legal development.
--
.nosig
I respectfully disagree. IMO that's no excuse for publishing anything with blatant mistakes. Quality is cheapest when it's built in at an early stage. Retrofitting is always more expensive. In this case, it's expensive at least in part because you'll never sell the idea to the PHBs of the world if the presentation has too many errors; it suffers a credibility gap right up front. You've lost part of your potential market right away, simply through haste and carelessness. Two rules for success (or, at least, to give you a better chance at avoiding failure): Always dress better than you need to, and always write better than you need to.
--
.nosig
So here's one advantage of being a programmer at Microsoft: At least you get dates, even if they are bad ones.
--
I can misspell words in 9 languages.
.nosig
--
do while TRUE
msgbox "I am cool"
loop
Have fun!
Our TWO main weapons are fear and surprise. And a fanatical devotion to the Pope. Our THREE main weapons...
.nosig
.nosig
.nosig
.nosig
http://www.netfunny.com/rhf/jokes/88q3/16840.12.ht ml
.nosig
Essentially, in ISO9000-speak, Processes are higher level descriptions that often cross organizational boundaries (more than one team, or workers and management). Processes may be implemented via one or more procedures, the step-by-step recipes that pertain to the McDonalds example you site. I agree that an experienced sysadmin doesn't need procedures on how to change a tape. But you do need an agreed-upon process that tapes will be changed periodically and data will be retained/destroyed according to a schedule negotiated with users, stating which team is responsible for doing what part of the job, and how we are going to know that it is in fact being done.
Processes are the way policies are implemented and controlled. Procedures are the way processes are implemented and controlled. In a small shop, or in trivial cases, these may overlap quite a bit. But in the context of an article about how serious it is to be a Sysadmin, I think it should be mentioned that there's a great deal of literature and structure out there, so there's no need to go reinventing the last 20 years' worth of wheels.
By the way, does anyone know why this was posted in the Developers section? From a Sysadmin's point of view, developers are just another kind of user, and sometimes rather whiny ones at that.
.nosig
As long as all the SysAdmins seem to be making it up as they go along, we will continue to be marginalized and geek-ified by management. Try on for size:
- ITIL (IT Infrastructure Library)
- More ITIL
- IT Service Management Forum (the U.K. headquarters)
- CMM (Capability Maturity Model) Technical Engineering Practices
- The Open Group's Technical Architecture Framework.
Heck, even Microsoft is trying to get into the picture with its Microsoft Operational Framework, a kind of embrace-and-extend on ITIL, though I don't know of many places that are actually using it.It's not that the SysAdmin necessarily has to manage these processes - though in a small shop no one else will - but he/she/it needs at least to be able to talk the language and understand the processes that the IT Manager has set up. And if you are managing the shop, then this is your job. You must know this stuff as a matter of professional responsibility and "keeping up" in your field.
A 20 min. presentation to the other managers on Best Practices and Processes in IT Management will gain you a lot of credibility and help lift you out of the geek gutter. There are decades worth of lessons that have been learned the hard way and documented into these processes. When you can demonstrate to management that you are drawing on a substantial body of knowledge that is geared towards improving service and reducing total cost of ownership, you will gain their respect (assuming that you care about their respect).
Beyond this, I want to emphasize an excellent point that Sanders makes in the article. The SysAdmin job is one that is invisible if you're doing it right. A good day at work is a boring day. Excitement is a sign that something has gone wrong. You should structure your environment to be as boring and reliable as possible.
Too many SysAdmins live off the adrenaline rush of fixing a broken server while everyone else in the organization sits on their thumbs waiting. That's costly for the organization, but ironically is the easy way out for the SysAdmin - you don't need to be disciplined or structure your time or do any planning or thinking, just jump from crisis to crisis. It's much more challenging to turn it into a boring desk job where most of your work is pushing paper and the machines pretty much take care of themselves. But guess which option is better for the organization's mission?
Once you do get to that Nirvana state of boring life, you can strategize how to produce some measurables so you can blow your department's horn at the monthly managers meeting. Because if you do your job well, with the result that your work is invisible, they'll cut your funding unless you keep in their face on a regular basis.
.nosig
That might work for the simpler disciplines like physics, but it doesn't work for the more complex disciplines like the social sciences. And if you don't know that sociology is more complex than physics then you haven't been keeping up with the literature on the difference between "hard" and "soft" (i.e. complex) sciences - so don't bother replying, let alone moderating. Informed discussion only, please.
.nosig