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.
チャンネル別に見る
自動化
テクノロジー、チームおよび環境に関する IT 自動化の最新情報
AI (人工知能)
お客様が AI ワークロードをどこでも自由に実行することを可能にするプラットフォームについてのアップデート
オープン・ハイブリッドクラウド
ハイブリッドクラウドで柔軟に未来を築く方法をご確認ください。
セキュリティ
環境やテクノロジー全体に及ぶリスクを軽減する方法に関する最新情報
エッジコンピューティング
エッジでの運用を単純化するプラットフォームのアップデート
インフラストラクチャ
世界有数のエンタープライズ向け Linux プラットフォームの最新情報
アプリケーション
アプリケーションの最も困難な課題に対する Red Hat ソリューションの詳細
仮想化
オンプレミスまたは複数クラウドでのワークロードに対応するエンタープライズ仮想化の将来についてご覧ください