I've seen a broad range of hardware decommissioning (decomm) processes in my years as a sysadmin. It can be as simple as an email with a dire warning about a soon-to-be decommissioned system all the way up to a multi-layered, multi-month, multi-approver process that makes government red tape seem like a pale pink by comparison.
The process in the last two companies I worked in, decommissioning was a 30-day process that started with notifications, a so-called "Scream" test, and a final shutdown, unracking, and palletizing for disposal. I love the term "Scream" test. This part of the process involves unplugging the system from the network for two weeks to see if anyone screams about a lost service. It's effective and I've had my share of opportunities to reverse a decomm for last-minute file recovery and then to restart the process again.
[ A free course for you: Virtualization and Infrastructure Migration Technical Overview. ]
Even small to medium-sized companies have some sort of governance surrounding server decommissioning. They might not call it decommissioning but the process usually goes something like the following:
- Send out a notification or multiple notifications of system end-of-life to stakeholders
- Make complete backups of the entire system and its data
- Unplug the system from the network but leave the system running (2-week Scream test)
- Shutdown and unplug from power but leave the system racked (2-week incubation period)
- Unracking and palletizing or in some cases recommissioning
I personally loved the decomm process. There's something fulfilling about it. I liked spending time in the data center, DBANning disks, unplugging systems, and filling out unracking requests. I know it's not for everyone but I liked it. I don't get to handle those tasks anymore either directly or indirectly, which is why I'm curious about your process.
关于作者
Ken has used Red Hat Linux since 1996 and has written ebooks, whitepapers, actual books, thousands of exam review questions, and hundreds of articles on open source and other topics. Ken also has 20+ years of experience as an enterprise sysadmin with Unix, Linux, Windows, and Virtualization.
Follow him on Twitter: @kenhess for a continuous feed of Sysadmin topics, film, and random rants.
In the evening after Ken replaces his red hat with his foil hat, he writes and makes films with varying degrees of success and acceptance. He is an award-winning filmmaker who constantly tries to convince everyone of his Renaissance Man status, also with varying degrees of success and acceptance.
