Menyerahkan Penjagaan Laman Web kepada Penyedia Baharu Tanpa Merosakkan Apa-apa

Minggu paling berisiko dalam hayat laman web selalunya bukan godaman

Ia adalah minggu ia bertukar tangan antara dua penyedia penjagaan. Pencerobohan atau gangguan cenderung mendapat perhatian penuh semua orang serta-merta. Serahan (handover) pula kelihatan tenang sehinggalah ia tidak lagi begitu — nameserver ditujukan ke arah salah selama enam jam, sistem e-mel yang senyap-senyap berhenti menerima mel kerana rekod MX tercicir semasa pertukaran, backup "akhir" yang didapati sudah berusia tiga bulan. Tiada satu pun daripada itu memerlukan sesiapa cuai. Ia memerlukan dua pihak yang masing-masing arif dengan bahagian proses masing-masing, tetapi tidak pernah perlu menyerahkan laman web live yang menjana hasil antara mereka sebelum ini.

Ini terpakai tidak kira arah mana pun anda bergerak. Turutan yang sama melindungi perniagaan yang meninggalkan satu penyedia untuk penyedia lain, dan ia terpakai sama banyaknya sama ada meninggalkan JagaWeb atau tiba di JagaWeb.

Sebelum memberi notis: apa yang perlu ada di tangan

Kesilapan yang perlu dielakkan ialah memberi notis kepada penyedia semasa sebelum mengesahkan anda benar-benar boleh mendapatkan apa yang anda perlukan daripada mereka. Minta, dan terima, perkara berikut semasa hubungan masih aktif dan bekerjasama: akses admin penuh kepada akaun hosting dan control panel, bukan sekadar CMS; log masuk pendaftar domain, atau pengesahan siapa pendaftar berdaftar jika domain berada di tempat lain; eksport semasa fail zon DNS, menunjukkan setiap rekod — bukan sekadar rekod yang jelas diperlukan oleh laman web semasa, kerana subdomain lama dan rekod MX atau TXT yang terlupa turut wujud di situ; salinan berfungsi codebase, termasuk apa-apa yang disesuaikan melebihi templat atau plugin siap pakai; eksport pangkalan data terkini; dan senarai setiap perkhidmatan pihak ketiga yang bersambung dengan laman web — analitik, tag manager, borang, payment gateway, penghantaran e-mel — beserta akaun mana yang memiliki setiap satu.

Mendapatkan semua ini sebelum notis diberikan, berbanding selepasnya, mengubah keseluruhan struktur insentif. Penyedia yang bekerjasama biasanya akan menyerahkan ini dalam apa jua keadaan, tetapi memintanya semasa kontrak masih aktif dan hubungan masih berjalan menghapuskan sebarang keraguan tentang sama ada mereka wajib membantu sebaik sahaja notis diberikan.

Menyusun pemindahan, bukan melakukan semuanya sekali gus

Susunan sama penting seperti senarai semak itu sendiri. Turutan praktikal kelihatan seperti ini: sahkan akses kepada pendaftar domain dan zon DNS dahulu, kerana itulah titik kawalan untuk segala-galanya di bawahnya; ambil dan simpan secara berasingan satu backup dan eksport kod/pangkalan data sebelum apa-apa perubahan lain berlaku; sediakan persekitaran penyedia baharu dan jalankan laman web di sana, tanpa menyentuh domain live lagi; uji sepenuhnya pada URL sementara atau melalui override fail hosts tempatan; dan hanya kemudian pindahkan DNS, sebaik-baiknya selepas menurunkan TTL (time-to-live) rekod DNS sehari dua lebih awal, supaya jika sesuatu perlu dikembalikan, perubahan itu tersebar semula dengan pantas berbanding mengambil masa TTL lalai penuh untuk dibatalkan.

Melakukan ini di luar susunan — contohnya, membatalkan akaun hosting lama sebelum mengesahkan yang baharu benar-benar berfungsi — adalah cara sesebuah perniagaan berakhir dengan laman web live menunjuk ke arah kosong sepanjang tengah hari.

Sahkan backup yang anda warisi, bukan sekadar yang anda tinggalkan

Sebarang serahan wajar merangkumi ujian restore sebenar, bukan sekadar fail bertanda "backup" duduk dalam folder. Itu topik yang cukup besar untuk layak proses tersendiri berbanding satu perenggan di sini — versi ringkasnya ialah backup yang tiada sesiapa pernah restore adalah andaian, bukan jaring keselamatan, dan andaian itu wajar diuji sebelum akses penyedia lama hilang dan tiada sesiapa lagi untuk ditanya jika ada sesuatu yang hilang daripadanya.

DNS dan e-mel: dua perkara yang rosak secara senyap

Daripada segala-galanya dalam serahan, DNS dan e-mel adalah dua perkara paling berkemungkinan gagal tanpa mesej ralat yang jelas. Perubahan DNS yang tersalah satu rekod biasanya tidak memberi ralat — ia hanya senyap-senyap menghantar sebahagian trafik, atau sesuatu kategori permintaan, ke tempat yang salah, dan tanda pertama selalunya e-mel sokongan yang tiba berhari-hari kemudian bertanya mengapa borang hubungi tidak berfungsi. E-mel memerlukan perhatian khusus kerana mudah terlepas pandang: rekod MX menentukan ke mana mel sesuatu domain sebenarnya dihantar, dan ia sepenuhnya berasingan daripada di mana laman web itu sendiri dihoskan. Penyedia yang memindahkan hosting laman web boleh, tanpa berniat, menyerahkan fail zon DNS yang tertinggal rekod MX dan rekod sokongan SPF/DKIM yang bergantung kepadanya e-mel perniagaan, kerana daripada sudut pandang hosting laman web, rekod itu kelihatan tidak relevan. Menyemak silang keseluruhan zon DNS — bukan sekadar rekod yang diminta oleh wizard persediaan host baharu — berbanding apa yang sebenarnya digunakan sebelum ini adalah satu-satunya perlindungan yang boleh dipercayai terhadap ini.

Tempoh bertindih: menjalankan dua penyedia dengan sengaja

Serahan yang bersih biasanya tidak berlaku serta-merta. Menjalankan persekitaran lama dan baharu selari untuk tempoh bertindih yang pendek dan sengaja — laman web baharu live dan disahkan, laman web lama masih boleh dicapai dan tidak berubah sebagai fallback, DNS belum lagi dipindah — memberi ruang untuk mengesan rekod yang tercicir atau integrasi yang rosak sebelum pilihan fallback hilang. Tempoh bertindih itu tidak perlu panjang. Ia perlu cukup panjang supaya jika sesuatu tersasar, masih ada versi lama yang berfungsi untuk kembali kepadanya sementara ia dibetulkan, berbanding insiden live tanpa fallback.

Rupa serahan keluar yang profesional

Dari pihak yang meninggalkan, serahan yang baik kelihatan kurang dramatik berbanding yang buruk, itulah sebahagian sebab ia mudah dipandang rendah. Ia bermakna menjawab permintaan akses tanpa melengah-lengahkan, menyerahkan kelayakan admin sebenar berbanding paparan baca-sahaja, menyediakan apa-apa dokumentasi yang wujud tentang penyesuaian yang tidak jelas, dan tidak menganggap invois akhir sebagai leveraj untuk melepaskan akses yang klien sudah berhak dapat. Tiada satu pun daripada itu memerlukan hubungan panjang atau pasukan besar di belakangnya — ia memerlukan menganggap akses dan data sebagai perkara yang dimiliki klien, yang memang begitu, tidak kira siapa yang membina atau menyelenggara laman web itu.

Standard yang sama terpakai kedua-dua arah

Tiada satu pun daripada ini khusus kepada mana-mana penyedia. Perniagaan yang bertukar kepada JagaWeb sepatutnya mengharapkan untuk melalui turutan yang tepat ini dengan sesiapa yang mereka tinggalkan, dan perniagaan yang akhirnya bertukar daripada JagaWeb sepatutnya mengharapkan tahap kerjasama yang sama sebagai balasan — akses penuh, backup yang disahkan, serahan yang didokumenkan, tiada kelewatan buatan. Simetri itu sebenarnya keseluruhan intipatinya: proses serahan yang layak dipercayai ialah yang berfungsi sama tidak kira arah mana pun anda bergerak.

Jika penjagaan berterusan selepas serahan — pemantauan, kemas kini, tempat untuk menyalurkan pembetulan — adalah keperluan segera, JagaWeb Care (RM450/bulan) merangkumi penyelenggaraan rutin, dan Care + Changes (RM1,500/bulan) menambah bajet kerja untuk permintaan kandungan dan pembetulan sebaik sahaja persediaan baharu disahkan stabil. Satu pilihan untuk ditimbang sebaik sahaja pemindahan itu sendiri selesai, bukan sebelum itu.