Migrasi atau Decommissioning Pusat Data: Ketika Proyek Benar-benar Gagal

Rencana migrasi pusat data Anda telah selesai dan semua orang puas dengan strukturnya. Lingkungan baru telah siap dan jendela transisi telah diatur. Saat itulah ada yang menanyakan rencana dekomisioning.

Satu orang mengira mereka sudah diurus. Orang lain menyarankan “outsourcing”, tanpa menjelaskan secara rinci. Terakhir, ada yang menyarankan untuk menunggu hingga migrasi selesai.

Di sinilah masalah bisa dimulai.

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

Ketika tim mengelompokkannya dalam keranjang mental yang sama, migrasi dianggap sebagai peristiwa teknologi dan pembongkaran sebagai sisa logistik.

Ini adalah bagaimana pemulihan aset menghilang, kesenjangan dalam lacak balak muncul, dan pekerjaan paling remeh ditemukan ketika manajemen menganggap sebagian besar proyek sudah selesai.

Migrasi dan penurunan versi memecahkan masalah yang berbeda

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

Ini adalah kondisi yang berbeda untuk sukses.

Migrasi secara teknis bisa berhasil meskipun penurunan peringkat hanya membuang-buang uang, kepatuhan, atau pembuktian. Penurunan peringkat dapat dikelola dengan ketat sementara rencana migrasi itu sendiri diabaikan. Tumpang tindih itu nyata, tapi itu transfer dan bukan merger.

Zona transfer menghadirkan tantangan logistik

Jika sebuah tim gagal, itu karena tidak ada yang bertanggung jawab atas transisi dari lingkungan langsung ke lingkungan yang dihapus.

Di zona perpindahan inilah risiko bencana paling tinggi. Jika Anda tidak dapat menjawab pertanyaan-pertanyaan ini, keadaan akan menjadi berbahaya:

Jika masalah ini tidak memiliki petunjuk yang ditentukan sebelum akhir jendela migrasi, proyek akan mulai berimprovisasi.

Improvisasi menciptakan jenis masalah yang ingin Anda hindari: ambiguitas hak asuh, serialisasi yang hilang, penanganan pemulihan yang buruk, dan pekerjaan pembersihan yang tidak terduga. Meskipun semua orang merayakan migrasi, penurunan peringkat justru mengalami kegagalan.

Apa yang termasuk dalam migrasi dan apa yang termasuk dalam downgrade

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

Tabel ini sengaja dibuat sederhana.

Operator cenderung memperumit batasan dalam diskusi dan tidak mendefinisikannya secara memadai dalam pelaksanaannya.

Lima Titik Kegagalan yang Menyebabkan Proyek Gagal

Sebagian besar masalah yang berkaitan dengan penghentian dan migrasi pusat data bermuara pada beberapa bidang tertentu.

1. Lingkungan lama diperlakukan sebagai masalah penyimpanan

Ini adalah kesalahan pasca-migrasi yang paling umum. Migrasi selesai, namun lingkungan yang dihapus tetap berada di area abu-abu. Tidak ada yang mau menyentuhnya sampai semua orang yakin transisinya stabil. Semakin lama lingkungan lama berada dalam ketidakpastian, semakin besar kemungkinan Anda kehilangan status inventaris, mencampurkan aset yang berfungsi dengan aset yang sudah mati, salah mengelola media, atau membiarkan perangkat keras penyelamat memasuki pasar yang semakin sulit. Perlu ada titik masuk yang jelas, meskipun pelaksanaannya dilakukan secara bertahap setelah commissioning.

2. Tidak ada yang menetapkan inventaris kepercayaan terbaru

Tim migrasi biasanya fokus pada status layanan, bukan status sisa. Mereka tahu apa yang dipindahkan. Mereka umumnya kurang disiplin mengenai apa yang tersisa, apa yang dimatikan, apa yang masih berisi data, dan apa yang berubah keadaan selama proyek berlangsung. Di sinilah dekomisioning mulai kehilangan uang dan kendali. Jika Anda tidak mengunci inventaris akhir pada waktu yang tepat, setiap percakapan akan lebih lemah dibandingkan percakapan sebelumnya: apa yang dapat diselamatkan, apa yang perlu dimusnahkan, apa yang sebenarnya telah dihapus, dan apa yang masih hilang dari file. Semakin Anda mencoba menyusun daftar ini, semakin proyek Anda mulai bergantung pada spreadsheet yang tidak selaras.

3. Jalur data dirancang terlambat

Tim migrasi sering kali berasumsi bahwa lingkungan lama dapat dibersihkan setelah transfer selesai. Ini adalah solusi sementara, bukan rencana. Pada saat solusi sementara menjadi pekerjaan nyata, aset mungkin sudah tercampur dan kondisi penyimpanan mungkin menjadi lebih buruk. Keputusan untuk menggunakan kembali atau memusnahkannya tergantung pada kendala jadwal, bukan kendala politik.

Dokumen NIST SP 800-88 Revisi 2 berguna di sini karena menyajikan remediasi sebagai program dengan kontrol terkait jenis media dan sensitivitas informasi. Jalur data harus diputuskan sebagai bagian dari desain dekomisioning. Kita tidak bisa begitu saja menyeberangi jembatan itu ketika kita sampai di sana.

4. Rencana pemulihan hanyalah khayalan atau kelalaian

Tim biasanya bertindak terlalu jauh dalam satu arah. Entah mereka berasumsi bahwa lingkungan pensiunan adalah tambang emas yang tersembunyi, atau mereka memperlakukan segala sesuatu yang lama sebagai sampah dan secara tidak sengaja merusak nilainya. Kedua kesalahan tersebut berasal dari masalah yang sama: belum ada yang melakukan pekerjaan memisahkan persediaan utama dan persediaan ekor.

Jika rencana dekomisioning tidak mengidentifikasi permintaan riil di pasar sekunder, peralatan tersebut diperlakukan sebagai pembersihan dan bukan kelas aset. Jika rencana tersebut mengasumsikan bahwa segala sesuatu masih memiliki nilai, pendanaan menjadi sia-sia dan anggaran proyek terdistorsi bahkan sebelum pelaksanaan dimulai.

5. Batasan pemasok menjadi kabur

Penyedia layanan migrasi, tim penggerak, kontraktor fasilitas, dan operator ITAD semuanya dapat terlibat dalam proyek yang sama. Ini tidak berarti bahwa mereka memiliki motivasi yang sama.

Ada pihak yang menginginkan transisi ini stabil. Yang lain ingin ruangannya dibersihkan. Yang lain ingin materinya diserialkan dan dilindungi, dan yang lain ingin hasil pemulihannya dipertahankan. Jika batasan ini tidak ditentukan, proyek diberikan kepada siapa pun yang paling vokal dalam seminggu terakhir. Pemilik yang melakukan dekomisioning harus memiliki wewenang atas lintasan aset yang dinonaktifkan, meskipun migrasi adalah penyebab dari dekomisioning tersebut.

Model operasi yang lebih baik

Jika Anda ingin proyek tetap bersih, lakukan migrasi dan penghentian alur kerja terkait namun terpisah, dengan serah terima formal.

Transfer ini harus didefinisikan:

Lima pertanyaan untuk memaksa percakapan

Sebelum migrasi selesai, tanyakan:

1. Siapa pemilik inventaris yang dihapus setelah transfer selesai?
2. Apa daftar kepercayaan terbaru dan kapan dikunci?
3. Aset manakah yang berada dalam kondisi dapat dipulihkan, dalam kondisi hancur, atau dalam kondisi pengecualian?
4. Bagaimana proses hak asuh dari pensiun hingga disposisi akhir?
5. Siapa yang menandatangani berkas penutupan dekomisioning?

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

Langkah ini mungkin sudah siap. Beban kerja mungkin stabil. Lingkungan baru mungkin sedang berjalan lancar. Namun hal ini tidak berarti bahwa proyek tersebut terkendali.

Migrasi selesai saat bisnis beroperasi di situs baru. Penonaktifan berakhir ketika Anda dapat membuktikan apa yang terjadi pada peralatan lama. Proyek gagal ketika tim mengacaukan kedua garis finis ini.