Ketika kemampuan layanan cloud sudah menjadi langka, dan transisi ke versi kotak dipandang sebagai langkah logis berikutnya untuk pengembangan lebih lanjut dari portal perusahaan dan sistem CRM, maka timbul pertanyaan bagi perusahaan, bagaimana melakukannya, apa yang menanti mereka dan apakah semuanya akan tetap ada setelah transfer?
Tampaknya semuanya cukup sederhana:
- Perluas host dengan kotak;
- Kami sedang menulis dukungan teknis;
- Kami memesan cadangan;
- Kami berharap dapat menerimanya;
- Kami menyebarkan cadangan dan menikmati berbagai kemungkinan versi kotak.
Tetapi praktik menunjukkan bahwa transisi dari cloud ke versi kotak jauh dari sepele dan membutuhkan rencana tindakan yang jelas, analisis risiko yang mungkin dan kesiapan untuk fakta bahwa semuanya akan salah.
Kami didekati oleh pengembang besar dengan sistem CRM yang sangat banyak berdasarkan pada Bitrix24 cloud. Manajer penjualan dari beberapa cabang perusahaan bekerja secara aktif dalam CRM, portal terintegrasi dengan telepon IP Asterisk untuk secara otomatis membuat arahan, merekam percakapan dengan pelanggan dan mencatat fakta panggilan dalam kartu pelanggan dalam CRM. Lebih dari 100 lead dibuat per hari di CRM melalui berbagai saluran.
Jelas bahwa waktu yang sederhana selama transfer ke versi kotak mengancam pelanggan dengan kerugian besar. Setelah berbicara dengan Pelanggan tentang keseriusan transisi dan kemungkinan risiko, kami mulai bekerja.
Pertama-tama, kami menganalisis kasus dan publikasi yang ada tentang transfer cloud ke kotak, membuat daftar periksa kesalahan yang mungkin kami temui:
- Aplikasi yang berjalan di cloud tidak ada di dalam kotak;
- Biaya lisensi untuk aplikasi untuk versi cloud dan kotak dapat bervariasi;
- Risiko kehilangan beberapa data karena jeda waktu selama transfer;
- Beberapa pengguna dari cabang yang berbeda akan terus bekerja pada layanan cloud setelah transfer, dan akan perlu untuk mencari dan mentransfer tambahan entitas yang mereka buat dalam CRM;
- Pada portal tertutup, aplikasi seluler layanan tidak akan berfungsi;
- Setelah transfer, beberapa pengguna tidak akan bisa masuk dengan kata sandi lama mereka;
- Mungkin ada kegagalan fungsi dalam obrolan bot;
- Reset otorisasi yang sering saat bekerja di portal;
- Hanya sebagian dari komentar tugas yang dapat ditampilkan;
- Basis data akan tanpa indeks pencarian.
Selanjutnya, disusun algoritma tindakan yang jelas dengan uraian peran, yang harus dilakukan baik oleh Kontraktor maupun oleh Pelanggan:
1 fase (media urgensi)- Penyebaran lingkungan Produksi (Kontraktor);
- Menguji lingkungan yang digunakan (Kontraktor);
- Penyebaran versi kotak pada host (Kontraktor);
- Pembelian dan pemasangan sertifikat SSL untuk telepon (Pembelian pelanggan, pemasangan Kontraktor);
- Menguji versi kotak - kinerja, parameter, tes internal (Kontraktor).
- Penyebaran lingkungan Pra-Produksi - salinan lengkap dari Produksi (Kontraktor).
2 fase (urgensi tinggi)- Aplikasi untuk membongkar cadangan. Koordinasi dengan dukungan teknis dari layanan tanggal cadangan (Pelanggan);
- Memberi tahu pengguna tentang tanggal cadangan dan menyusun rencana untuk penyimpanan sementara informasi dari CRM (Pelanggan);
- Penempatan cadangan pada Produksi (Kontraktor);
- Menyiapkan portal setelah cadangan (Kontraktor);
- Menyiapkan server telepon untuk bekerja dengan portal (Pelanggan);
- Menyiapkan modul teleponi (Kontraktor);
- Pengujian teleponi awal (Pelanggan);
- Pengujian mendalam tentang proses bisnis CRM, telepon, CRM (departemen penjualan Pelanggan);
- Pernyataan Kesehatan. Penghapusan data uji (Pelanggan);
- Menghentikan manajer penjualan di layanan cloud (Pelanggan);
- Transfer transaksi, arahan, kontak dari saat membuat cadangan dari versi cloud ke kotak (Kontraktor);
- Mulai dari pekerjaan manajer penjualan pada versi kotak (Pelanggan).
3 fase (urgensi rendah)- Menguji versi kotak dalam 2-3 hari (Pelanggan);
- Persetujuan kinerja penuh (Pelanggan);
- Memperbarui Pra-Produksi - mentransfer salinan lengkap Produksi (Kontraktor).
Setelah menyusun rencana ini dan memiliki daftar periksa dengan kemungkinan kesalahan, kami menyadari bahwa kami memiliki terlalu banyak risiko karena banyaknya ketidakpastian:
- Seberapa cepat layanan akan menyediakan cadangan?
- Berapa lama untuk menggunakan cadangan, mengingat bahwa basis data CRM sangat besar?
- Seberapa cepat saya bisa mengkonfigurasi ulang modul dan server telepon agar berfungsi dengan benar dengan CRM?
- Bug spesifik apa yang dapat muncul di portal, seberapa kritis mereka bagi pengguna untuk bekerja, dan berapa lama untuk memperbaikinya?
Kami menyadari bahwa kami memiliki jeda waktu yang tidak terbatas, yang, seiring dengan bertambahnya waktu, akan membawa semakin banyak kerugian kepada klien. Untuk meminimalkan jeda waktu, perlu dipahami berapa banyak waktu yang kami habiskan untuk porting portal dan debuggingnya.
Jadi kami sampai pada kesimpulan bahwa satu cadangan dari cloud tidak akan cukup, dan untuk meminimalkan kerugian perlu untuk menggunakan satu cadangan - untuk mengidentifikasi semua risiko yang mungkin terjadi dan memperkirakan jeda waktu, dan kemudian cadangan kedua yang dapat kami rencanakan sedemikian rupa untuk meminimalkan kerugian. .
Bitrix hanya menyediakan satu cadangan dan hanya sekali, karena proses transfer dari cloud ke kotak secara teknis rumit. Beralih ke dukungan teknis dan menghubungkan Pelanggan ke masalah ini, kami masih memiliki lampu hijau untuk menyediakan dua cadangan dari cloud pada waktu yang berbeda. Waktu pencadangan pertama disepakati dan pekerjaan transfer dimulai.
Volume, kecepatan, dan bagian yang rusak
Untuk memahami berapa banyak dan berapa lama waktu yang kami butuhkan, kami mulai membuat jurnal di mana kami mencatat setiap langkah.
Jadi, portal mulai membuat cadangan layanan pada Kamis malam, yaitu, CRM memiliki data terbaru pada akhir Kamis, dan memberi kami tautan ke cadangan pada Jumat sore. Di sini kami menemui kesulitan pertama - cadangan berbobot sekitar 30 GB, dan kecepatan unduhan dari server Amazon.com yang meng-host cloud jauh dari ideal (rata-rata 800 Kb / dtk). Setelah menghitung kira-kira waktu di mana beberapa bagian cadangan dimuat, kami menyadari bahwa secara total akan memakan waktu sekitar 10 jam untuk mengunduh cadangan saja.
Masalah berikutnya adalah munculnya kesalahan selama memompa berbagai bagian cadangan, yang terdeteksi hanya ketika digunakan. Bagian-bagian ini, sebagai suatu peraturan, juga menyebabkan kesalahan ketidakcocokan hash, karena ini perlu untuk mengidentifikasi bagian yang rusak dari arsip dalam teks kesalahan dan secara manual mentransfernya melalui SSH, setelah itu pembongkaran dimulai kembali dari awal seluruh cadangan.
Setelah berhasil mengunduh dan menggunakan cadangan pada host kami, kami menerima salinan cloud yang berfungsi di dalam kotak dan melanjutkan ke langkah berikutnya - menguji dan men-debug portal.
Bug kecil dan dorongan & tarik berbahaya
Yang mengejutkan kami, pengujian kotak berjalan relatif lancar. Kami menguji CRM, memeriksa semua alat layanan, memeriksa fungsionalitas messenger, menjalankan tes internal dan hanya mengungkapkan 3 kesalahan:
- Ikon lampiran file di messenger menghilang dan mengirim file di messenger secara keseluruhan tidak berfungsi;
- Tautan dalam pemberitahuan memiliki alamat tanpa domain, misalnya: perusahaan / pribadi / pengguna / 1250 / tugas / tugas / tampilan , masing-masing, tidak berfungsi;
- Beberapa pengguna tidak dapat masuk ke portal dengan kesalahan login / kata sandi yang salah.
Kami tahu tentang ketidakmampuan untuk masuk setelah transfer sebelumnya, layanan segera memperingatkan tentang hal ini ketika menyediakan cadangan. Sayangnya, masalah ini hanya dapat diselesaikan dengan pengguna memulihkan kata sandi atau secara manual mengubah kata sandi untuk setiap pengguna oleh administrator, karena kata sandi dari Bitrix24.Network tidak disimpan di portal.
Kesalahan dengan tautan dalam pemberitahuan diselesaikan dengan cukup cepat - dengan mendaftarkan domain portal di pengaturan situs dan pengaturan modul utama.
Tetapi ikon lampiran file yang hilang di messenger menyampaikan beberapa kekhawatiran. Tugas ini membutuhkan beberapa jam lagi dari upaya yang gagal untuk memahami alasan ikon yang hilang. Sebagai hasilnya, kami menemukan bahwa alasannya jauh dari pada modul disk, seperti yang seharusnya. Alasannya terletak pada server push yang dinonaktifkan dalam pengaturan modul push & pull, yang secara otomatis mematikan transfer file di messenger.
Pengujian akhir
Setelah pengujian dan debugging portal yang sukses, laporan terperinci disiapkan untuk Pelanggan, dan langkah selanjutnya adalah pengujian mendalam oleh departemen penjualan Pelanggan CRM, serta menyiapkan server telepon untuk bekerja dengan kotak dan menguji panggilan.
Selama pengujian, masalah signifikan tidak teridentifikasi. Kami mengerahkan host uji dan menggulirkannya ke salinan lengkap portal tempur, seandainya kami memiliki versi portal yang berfungsi 100% dan sesuai dengan itu kami dapat membuat perbandingan dalam pengaturan jika terjadi kesalahan non-standar yang tidak terdeteksi ketika menguji cadangan pertama.
Setelah menyebarkan salinan portal, kami melanjutkan ke analisis jurnal, di mana kami memperbaiki kesalahan dan waktu untuk menyelesaikannya. Setelah menganalisis majalah secara terperinci, kami memperbarui rencana untuk mentransfer cadangan kedua, menyadari betapa kami bisa kehilangan banyak petunjuk selama transfer akhir, dan menyisihkan waktu tambahan untuk impor manual petunjuk hilang dari versi cloud. Semua perincian dan risiko juga didiskusikan dengan Pelanggan dan surat dikirim ke dukungan teknis layanan dengan permintaan untuk menyiapkan cadangan kedua.
Cadangan kedua dan mengapa semuanya bisa salah?
Setelah menyetujui waktu pembuatan cadangan juga pada hari Kamis, kami menyiapkan tim untuk tindakan operasional pada jam 12 siang pada hari Jumat. Di wilayah 12-13 jam, kami menerima tautan yang sudah lama ditunggu-tunggu dan mulai mengunduh. Beberapa jam kemudian jelas bahwa arsip tidak akan dipompa selama 10 jam, tetapi sekitar 14! Bandwidth saluran penyedia dan server Amazon.com kami pada hari ini meninggalkan banyak yang harus diinginkan. Kami sedang bersiap-siap untuk pekerjaan malam hari, ketika kontak terus turun, dan Pelanggan sedang menunggu laporan untuk mulai menyiapkan server telepon.
Seperti yang sering terjadi, tidak semuanya berjalan sesuai rencana. Langkah selanjutnya adalah mentransfer akumulasi akumulasi dari versi cloud ke kotak - prosesnya sederhana dan jelas, tetapi memiliki nuansa tersendiri. Jika dalam daftar prospek Anda memilih prospek yang perlu diekspor dan klik "Ekspor ke CSV", maka semua prospek yang ada di CRM akan dibongkar, bukan hanya yang dipilih. Adalah logis bahwa dengan database timbal yang besar, cloud jatuh ke dalam kesalahan. Solusinya adalah dengan menggunakan filter, hanya dalam hal ini lead dibongkar dengan benar.
Pengujian lebih lanjut berlalu tanpa kejutan, seperti yang telah kita ketahui: apa yang tidak akan berhasil, bagaimana cara memperbaikinya dan di mana. Setelah berhasil menghubungkan dan menguji telepon, pada hari Senin, manajer penjualan sudah sepenuhnya bekerja dengan CRM dalam versi kotak. Dan sudah dalam urutan kerja selama seminggu kami menyetel portal, didukung, membuat salinan akhir portal ke host tes.
Seluruh proses transfer memakan waktu sekitar satu minggu kerja dari saat perencanaan hingga pengaturan akhir.
Sebagai hasilnya, saya ingin mencatat pentingnya merencanakan proyek yang kompleks dan berisiko seperti itu, keterlibatan wajib dari Pelanggan dalam proses dan menyuarakan kemungkinan risiko, meskipun, seperti yang ditunjukkan oleh praktik, penyimpangan dari rencana tidak terkecuali.