To the original poster: It is entirely possible, but you're going to need to learn a lot about modern automation and configuration management tools appropriate to the types of maintenance you're looking to automate. You also need solid vision and alignment on how you're going to achieve this level of automation across multiple parts of your business -- Development, IT, the Business, everyone. They all have to buy in and commit, because all of those folks have the ability to fuck it all up if everyone isn't on the same page. You can't do it alone on the admin side. As a start, I would suggest learning about Continuos Integration/Continuous Delivery and Agile and Devops methodologies to get started on the road to where you want to be.

To the rest of you:

The original comment ("Learn and use Puppet") is grossly oversimplified -- there is a lot more to it -- but with proper implementation of configuration management software (Chef, Puppet, Salt, etc), proper automated testing (think Jenkins, Teamcity, etc) and a real commitment in your organization to Continuous Integration and Delivery practices, you can easily do regular automated maintenance. Yes -- sometimes it will break and you'll have to clean it up. But properly and thoughtfully implemented in policy and practice, those times when it breaks will be the exception that proves the rule.

Forgive the argument from authority, but at our firm (International, thousands of primarily linux servers across 14 countries and 40+ datacenters, mostly bare-iron, some virtualization) we have regular daily and weekly automated maintenance. We handle all sorts of significant change -- driver updates, software upgrades, network switch configuration, even forklift OS upgrades involving the full re-imaging of a bare iron system combined with re-deployment of software (including things like databases and hadoop clusters) -- automatically and without human intervention on a regular basis. And by regular I mean daily.

The attitude that "Murphy always wins" or "something will fail and you will have failed by not being there to fix it immediately" is a relic of a time when the tools available to manage large scale infrastructure were inadequate or unavailable. Again, there are failures that will require manual intervention, but if you are doing your jobs well as developers, network admins, systems admins, 'devops' [NOTE: I strongly object to that term being used as a job title, but that's how folks have started using it] then you should be able to conduct automated hands-free production change at 2am on a Saturday and sleep like a baby knowing that when you check your upgrade report in the morning 99% of the time everything will have gone off without a hitch.

Frankly if you approach complex infrastructure management with that defeatist viewpoint of "things will always fail", you are doing yourself and your employer a disservice, and you are severely restricting your career prospects. My company is not in any way unique in our ability to automate and manage our infrastructure, and maintaining that type of outdated attitude is going to cause lots of doors to be slammed in your face. Do you really believe the Googles, Facebooks and Amazons of the world rely on having a human being white-knuckling every change in their infrastructure?

One additional note: If your infrastructure is designed such that you cannot push change without guaranteed downtime or the risk of downtime then you have failed to design your infrastructure properly.

I'd mainly argue that the punishment is grossly inflated compared to the "crime". The individuals in question submitted properly formatted GET requests to a public website AT&T provided, collecting two pieces of information: The unique identifier for an iPad and the email address of the user who registered the iPad. They didn't get real names, phone numbers, addresses, social security numbers, etc. They didn't spam the users' inboxes. They didn't attempt to spoof the ICC-ID's to get unregistered iPads onto ATT's network. There's about a bazillion harmful things they did not do.

But they were sentenced to 41 months in prison? That seems disproportionate.

And from a technical specification, they didn't do anything unusual at all. I'm curious how much of their sentencing depends on the difference between sitting in front of a browser and typing in 100,000 URL's by hand to get the data v. writing some script to loop through and do it automatically.

Anyway, to your point: 'Stealing private information and releasing in [sic] publicly isn't just obviously illegal, it caused grief for 114,000 people". My responses would be:
a) email addresses are arguably not private, and to the extent that email addresses are private information, AT&T provided them on a public website.
b) I wasn't aware my iPad had an ICC-ID, but even if that's private information (and useless to anyone not in possession of my iPad, since it's solely used for validating my device when connecting to AT&T's 3G network): again, AT&T provided the information on a public website.
c) releasing the information publicly is certainly rude, but I'm not sure why it should be _obviously_ illegal.
d) what grief was caused to those 114,000 people?

The only part of the sentence that makes some sense to me is the fine. AT&T does have an argument the release of this information harms their corporate reputation (as it should. Shame on them for leaving this out where anyone could grab it), but I would think that harm would better be remedied in civil court, rather than a criminal proceeding.

Just to correct one thing:

CTA (chicago transit authority) platforms do have displays which show when the next train will arrive. On newly renovated platforms, it's on an LCD display, on older platforms it's displayed on a simple digital text bar. However, in both cases, the displays rotate through the next arrival and other information (including ads on the LCD's), so it's easy to miss the info you're looking for.

Sorry, I realized I skipped over the statement "a lot of people have never heard of SAP or Oracle".

Really? Then why are they working in your IT department? Would you hire a pilot who'd never heard of a 747? Or a programmer who'd never heard of Fortran?

Your arguments reflect a lack of understanding of current technology. In order, the simple rebuttals are:

1) OpenOffice -- supports most (if not all) Excel formulas, and imports all Excel 2K document formats.
2) LDAP
3) Cobbler/Puppet -- You don't know what they are, but that's ok, because you think that the retail install of windows provided by your vendor is acceptable on the corporate desktop, so your opinion on this issue really doesn't count.
4) RedHat offers paid support for Linux. Also, no business succeeds by having "the same issues that your competitors have". If that's your attitude, then your company has already lost.

For the record: I don't use Linux as my primary desktop OS. Securing Windows desktops is an annoying task, but it is doable. Ignorance like yours annoys me more, but correcting that ignorance is also doable.