Migrasi Pusat Data vs Decommissioning: Dimana Proyek Sebenarnya Gagal

Rencana migrasi pusat data Anda telah selesai dan semua orang puas dengan strukturnya. Lingkungan baru telah siap, dan jendela peralihan telah disetel. Lalu ada yang bertanya tentang rencana dekomisioning.

Satu orang mengira itu sudah diurus. Orang lain menyarankan Anda “mengalihdayakannya”, tanpa menjelaskan secara detail. Kemudian seseorang menyarankan Anda menunggu hingga migrasi selesai.

Di situlah masalahnya bisa dimulai.

Migrasi dan dekomisioning bukanlah proyek yang sama, namun keduanya berkaitan erat.

Ketika tim menggabungkannya ke dalam satu wadah mental, migrasi akan diperlakukan seperti peristiwa teknologi dan penonaktifan akan diperlakukan seperti sisa logistik.

Begitulah cara pemulihan aset menghilang, kesenjangan lacak balak terbuka, dan pekerjaan buruk baru diketahui ketika para pemimpin berpikir bahwa proyek tersebut pada dasarnya sudah selesai.

Migrasi dan Decommissioning Memecahkan Berbagai Masalah

Cara paling bersih untuk memahami tantangan yang mungkin Anda hadapi adalah dengan memisahkan pekerjaan.

Itu adalah kondisi keberhasilan yang berbeda.

Migrasi secara teknis dapat berhasil meskipun penonaktifan menyebabkan kekacauan finansial, kepatuhan, atau pembuktian. Penonaktifan dapat dijalankan dengan ketat sementara rencana migrasinya sendiri ceroboh. Tumpang tindih itu nyata, tetapi ini merupakan serah terima, bukan penggabungan.

Zona Handoff Menghadirkan Tantangan Logistik

Jika sebuah tim gagal, itu karena tidak ada yang memiliki kendali antara lingkungan hidup dan lingkungan pensiunan.

Zona serah terima adalah tempat dimana potensi terjadinya bencana paling besar. Jika Anda tidak dapat menjawab pertanyaan-pertanyaan ini, keadaan akan menjadi berbahaya:

Jika pertanyaan tersebut tidak menyebutkan nama pemiliknya sebelum jendela migrasi ditutup, proyek akan mulai berimprovisasi.

Improvisasi menciptakan masalah yang ingin Anda hindari: ambiguitas hak asuh, serialisasi yang hilang, penanganan pemulihan yang buruk, dan pekerjaan pembersihan yang tidak terduga. Sementara semua orang merayakan migrasi, penonaktifan tersebut berantakan.

Apa yang Dimiliki Migrasi dan Apa yang Dimiliki oleh Decommissioning

Ini adalah operasi yang harus dijabarkan secara eksplisit oleh tim sebelum dieksekusi:

Tabel ini sengaja dibuat sederhana.

Operator cenderung memperumit batas dalam diskusi dan kurang mendefinisikannya dalam pelaksanaan.

Lima Titik Kegagalan Yang Menyebabkan Proyek Hancur

Sebagian besar masalah terkait penonaktifan dan migrasi pusat data terjadi pada beberapa area tertentu.

1. Lingkungan Lama Diperlakukan Seperti Masalah Penyimpanan

Ini adalah kesalahan pascamigrasi yang paling umum. Migrasi selesai, tetapi lingkungan pensiunan masih berada di zona abu-abu. Tak seorang pun ingin menyentuhnya sampai semua orang yakin bahwa peralihannya stabil. Kehati-hatian tersebut dapat dimengerti, namun hal ini menimbulkan penyimpangan. Semakin lama lingkungan lama berada dalam ketidakpastian, semakin besar kemungkinan Anda kehilangan kondisi inventaris yang bersih, mencampurkan aset yang masih berfungsi dengan aset yang sudah mati, salah menangani media, atau membiarkan perangkat keras tingkat pemulihan menjadi semakin buruk di pasar. Itulah sebabnya dekomisioning bukanlah proyek yang dimulai setelah semua orang merasa santai. Hal ini memerlukan titik masuk yang ditentukan, bahkan jika eksekusi terjadi dalam fase terkendali setelah peralihan.

2. Tidak Ada yang Mendefinisikan Inventaris Tepercaya Terakhir

Tim migrasi biasanya berfokus pada negara layanan, bukan negara residu. Mereka tahu apa yang dipindahkan. Mereka biasanya kurang disiplin mengenai apa yang tertinggal, apa yang dimatikan, apa yang masih menyimpan data, dan kondisi apa yang berubah selama proyek berlangsung. Di sinilah penonaktifan mulai kehilangan uang dan kendali. Jika Anda tidak mengunci inventaris terakhir yang dihentikan pada saat yang tepat, setiap percakapan akan menjadi lebih lemah dibandingkan sebelumnya: apa yang dapat dipulihkan, apa yang harus dimusnahkan, apa yang sebenarnya dihapus, dan apa yang masih hilang dari catatan. Semakin lama Anda mencoba menyusun ulang daftar tersebut, semakin banyak proyek Anda dimulai bergantung pada spreadsheet yang tidak selaras.

3. Jalur Data Terlambat Didesain

Tim migrasi sering kali berasumsi bahwa lingkungan lama dapat disanitasi setelah perpindahan dilakukan. Itu adalah placeholder, bukan rencana. Pada saat placeholder berubah menjadi pekerjaan nyata, aset mungkin sudah tercampur dan kondisi hak asuh mungkin lebih lemah. Kemudian keputusan mengenai penggunaan kembali versus pemusnahan bergantung pada tekanan jadwal, bukan tekanan kebijakan.

NIST SP 800-88 Revisi 2 berguna di sini karena membingkai sanitasi sebagai sebuah program dengan kontrol yang terkait dengan jenis media dan sensitivitas informasi. Jalur data perlu diputuskan sebagai bagian dari desain penonaktifan. Anda tidak bisa begitu saja menyeberangi jembatan itu ketika Anda sampai di sana.

4. Rencana Pemulihan Adalah Fantasi atau Pengabaian

Tim biasanya berayun terlalu jauh ke satu arah. Entah mereka berasumsi bahwa lingkungan yang sudah tidak digunakan lagi adalah tambang emas yang tersembunyi, atau mereka memperlakukan segala sesuatu yang lama sebagai barang bekas dan secara tidak sengaja menghancurkan nilainya. Kedua kesalahan tersebut berasal dari masalah yang sama: Tidak ada yang melakukan pekerjaan memisahkan persediaan premium dari persediaan ekor.

Jika rencana penghentian tidak mengidentifikasi permintaan pasar sekunder yang sebenarnya, perangkat keras akan ditangani seperti pembersihan, bukan seperti kelas aset. Jika rencana mengasumsikan segala sesuatu masih memiliki nilai, pendanaan akan menjadi sebuah khayalan dan anggaran proyek akan terdistorsi bahkan sebelum pelaksanaan dimulai.

5. Batasan Vendor Tidak Jelas

Vendor migrasi, tim pemindahan, kontraktor fasilitas, dan operator ITAD semuanya dapat menangani proyek yang sama. Hal ini tidak berarti mereka berbagi insentif yang sama.

Salah satu pihak menginginkan peralihan yang stabil. Yang lain ingin ruangan itu dibersihkan. Yang lain menginginkan perangkat kerasnya diserialkan dan dilindungi. Ada pula yang ingin agar hasil pemulihan tetap dipertahankan. Jika batas-batas tersebut tidak ditentukan, proyek akan ditetapkan secara default kepada siapa pun yang paling keras dalam minggu terakhir. Pemilik penonaktifan memerlukan otoritas atas jalur aset yang dihentikan meskipun migrasilah yang memiliki pengalihan tersebut.

Model Operasi yang Lebih Baik

Jika Anda ingin proyek tetap bersih, jalankan migrasi dan dekomisioning sebagai alur kerja yang terhubung namun terpisah dengan serah terima formal.

Penyerahan itu harus menjelaskan:

Lima Pertanyaan untuk Memaksa Percakapan yang Benar

Sebelum migrasi ditutup, tanyakan:

1. Siapa yang memiliki persediaan yang dihentikan setelah peralihan selesai?
2. Apa daftar aset tepercaya terakhir, dan kapan dikunci?
3. Aset mana yang termasuk dalam tingkat pemulihan, tingkat kehancuran, atau masih dalam pengecualian?
4. Bagaimana jalur hak asuh dari masa pensiun hingga disposisi akhir?
5. Siapa yang menandatangani paket obralan akhir penonaktifan?

Jika jawabannya tidak jelas, Anda harus menyelesaikannya sebelum proses dimulai.

Langkah ini mungkin sudah siap. Beban kerja mungkin stabil. Lingkungan baru mungkin ramai. Itu tetap tidak berarti proyek tersebut terkendali.

Migrasi berakhir ketika bisnis sudah berjalan di sisi baru. Penonaktifan berakhir ketika Anda dapat membuktikan apa yang terjadi pada perangkat keras lama. Proyek gagal ketika tim mengacaukan kedua garis finis tersebut.