Semua pengembang 1C dalam satu atau lain cara berinteraksi erat dengan layanan TI dan langsung dengan administrator sistem. Namun interaksi ini tidak selalu berjalan lancar. Saya ingin menceritakan beberapa kisah lucu tentang ini.
Saluran komunikasi berkecepatan tinggi
Sebagian besar pelanggan kami adalah perusahaan besar dengan departemen TI besar mereka. Dan untuk salinan cadangan dari infobases, sebagai aturan, spesialis klien bertanggung jawab. Tetapi ada organisasi yang relatif kecil. Khusus untuk mereka, kami memiliki layanan yang sesuai dengan itu kami mengurus semua masalah terkait dengan mencadangkan semua 1C. Tentang perusahaan seperti itu akan dibahas dalam cerita ini.
Klien baru datang untuk mendukung 1C, dan, antara lain, kontrak memiliki klausa bahwa kami bertanggung jawab atas cadangan, meskipun mereka memiliki administrator sistem mereka sendiri untuk staf. Database client-server, sebagai DBMS - MS SQL. Situasi yang cukup standar, tetapi masih ada satu peringatan: pangkalan utama cukup besar, tetapi pada saat yang sama kenaikan bulanan sangat kecil. Artinya, basis data berisi banyak data historis. Dengan kekhasan ini, saya menyiapkan rencana pemeliharaan cadangan sebagai berikut: pada hari Sabtu pertama setiap bulan dibuat cadangan penuh, itu cukup berat, kemudian salinan diferensial dibuat setiap malam - jumlah yang relatif kecil dan setiap jam salinan log transaksi. Selain itu, salinan lengkap dan diferensial, tidak hanya disalin ke sumber daya jaringan, juga diunggah ke server FTP kami. Ini adalah persyaratan wajib untuk penyediaan layanan ini.
Semua ini berhasil dikonfigurasi, dioperasikan dan bekerja secara umum tanpa gagal.
Tetapi beberapa bulan kemudian, administrator sistem berubah di organisasi ini. Administrator sistem baru mulai secara bertahap membangun kembali infrastruktur TI perusahaan sesuai dengan tren modern. Secara khusus, virtualisasi muncul, rak disk, akses ditutup di mana-mana dan semuanya, dll., Yang dalam kasus umum, tentu saja, tidak bisa tidak bersukacita. Tapi itu tidak selalu berjalan lancar dengannya, sering kali ada masalah dengan kinerja 1C, yang menyebabkan beberapa ketidaksepakatan dan kesalahpahaman dengan dukungan kami. Juga, harus dicatat bahwa hubungan kita dengannya umumnya berkembang cukup dingin dan agak tegang, yang hanya meningkatkan tingkat ketegangan jika ada masalah.
Tetapi suatu pagi ternyata server klien ini tidak tersedia. Saya menghubungi administrator sistem untuk mencari tahu apa yang terjadi dan menerima sesuatu seperti "Server kami rusak, kami sedang mengerjakannya, itu tidak terserah Anda." Ya, itu berhasil. Jadi situasinya terkendali. Setelah makan siang, saya menelepon kembali, dengan suara administrator, bukannya jengkel, saya sudah merasa lelah dan apatis. Mencoba menjelaskan apa yang terjadi, dan bisakah kami membantu? Percakapan mengungkapkan hal berikut:
Dia memindahkan server ke sistem penyimpanan baru dengan serangan yang baru saja dirakit. Tetapi ada yang tidak beres dan setelah beberapa hari serangan ini hancur dengan aman. Entah pengontrolnya habis, atau sesuatu terjadi pada disk, saya tidak ingat persis, tetapi semua informasi hilang. Dan hal utama adalah bahwa sumber daya jaringan dengan cadangan juga dalam proses migrasi apa pun berada pada array disk yang sama. Artinya, basis produktif itu sendiri dan semua cadangannya hilang. Dan apa yang harus dilakukan sekarang tidak jelas.
Dengan tenang, kataku. Kami memiliki cadangan malam Anda. Jawabannya adalah diam, yang dengannya saya mengerti bahwa saya baru saja menyelamatkan hidup seseorang. Kami mulai membahas cara mentransfer salinan ini ke server yang baru saja digunakan. Tapi di sini muncul masalah.
Ingat, saya katakan bahwa cadangan lengkapnya cukup besar? Saya melakukannya karena suatu alasan sebulan sekali pada hari Sabtu. Faktanya adalah bahwa perusahaan itu adalah pabrik kecil, yang terletak jauh di luar kota dan internet yang mereka miliki sangat-begitu-begitu. Pada Senin pagi, yaitu, selama akhir pekan, salinan dengan kesedihan ini setengahnya sempat diunggah ke server FTP kami. Tetapi tidak ada cara untuk menunggu satu atau dua hari sampai dimuat di arah yang berlawanan. Setelah beberapa upaya gagal untuk menyeret file, administrator menghapus hard drive langsung dari server baru, menemukan mobil dengan sopir di suatu tempat dan dengan cepat bergegas ke kantor kami, karena kami masih di kota yang sama.
Sementara kami berdiri di ruang server dan menunggu file akan disalin, kami pertama kali bertemu, sehingga untuk berbicara, "hidup", minum secangkir kopi, berbicara dalam suasana informal. Saya bersimpati dengan kesedihannya dan mengirim kembali dengan penuh cadangan, dengan tergesa-gesa untuk mengembalikan pekerjaan perusahaan yang terhenti.
Selanjutnya, semua aplikasi kami ke departemen TI diselesaikan dengan sangat cepat dan tidak ada lagi perselisihan.
Hubungi administrator sistem Anda
Sekali, dengan satu klien, untuk waktu yang sangat lama saya tidak dapat mempublikasikan 1C untuk akses web melalui IIS. Tampaknya menjadi tugas biasa, tetapi di sini tidak keluar dari jalan. Administrator sistem lokal terhubung, mencoba berbagai pengaturan dan file konfigurasi. 1C di web biasanya tidak ingin bekerja. Ada yang salah dengan kebijakan keamanan domain, atau dengan firewall canggih lokal, atau apa-apa. Pada iterasi ke-N, admin menjatuhkan tautan ke saya dengan kata-kata:
- Coba lagi dengan instruksi ini. Semuanya cukup detail di sana. Jika tidak berhasil, tulis ke penulis situs ini, mungkin dia akan membantu.
"Tidak," kataku, "itu tidak akan membantu."
- Kenapa?
- Saya penulis situs ini ... (
Hasilnya, mereka meluncurkan Apache tanpa masalah. IIS tidak bisa menang.
Lebih dalam
Kami memiliki klien - perusahaan manufaktur kecil. Mereka memiliki server, seperti "klasik" 3 in 1: server terminal + server aplikasi + server database. Mereka bekerja di beberapa konfigurasi industri berdasarkan soft starter, ada sekitar 15-20 pengguna dalam sistem, dan kinerja sistem pada prinsipnya cocok untuk semua orang.
Waktu berlalu, semuanya bekerja lebih atau kurang stabil. Tetapi Eropa memberlakukan sanksi terhadap Rusia, akibatnya Rusia mulai membeli terutama produk dalam negeri, dan hal-hal di perusahaan ini semakin menanjak. Jumlah pengguna telah bertambah menjadi 50-60 orang, cabang baru telah dibuka, dan demikian pula alur kerjanya. Dan sekarang server saat ini telah berhenti untuk mengatasi beban yang meningkat tajam, dan 1C mulai, seperti yang mereka katakan, "melambat". Pada jam-jam sibuk, dokumen ditahan selama beberapa menit, memblokir kesalahan yang dihujani, formulir dibuka untuk waktu yang lama, dan semua layanan terkait lainnya. Administrator sistem lokal menolak semua masalah, dengan mengatakan, "Ini 1C Anda, Anda harus mengetahuinya." Kami telah berulang kali menyarankan untuk melakukan audit sistem untuk kinerja, tetapi ini tidak mencapai audit itu sendiri. Klien hanya meminta rekomendasi tentang pemecahan masalah.
Yah, saya duduk dan menulis surat yang cukup banyak yang menyatakan bahwa perlu untuk memisahkan peran server terminal dan server aplikasi dari DBMS (yang, pada prinsipnya, kami telah mengatakan berulang kali sebelumnya). Saya menulis tentang DFSS pada server terminal, tentang Memori Bersama, melemparkan tautan ke sumber-sumber resmi dan bahkan menawarkan beberapa opsi perangkat keras. Surat ini mencapai kekuatan yang ada di perusahaan, kembali ke departemen TI dengan resolusi "Jalankan", dan es umumnya pecah.
Setelah beberapa waktu, admin mengirimi saya alamat IP server baru dan kredensial masuk. Dia mengatakan bahwa MS SQL dan komponen server 1C ditempatkan di sana, dan Anda perlu mentransfer database, tetapi sejauh ini hanya ke server DBMS, karena ada beberapa masalah dengan kunci 1C.
Memang, semua layanan masuk, server tidak terlalu kuat, oke, saya pikir itu lebih baik daripada tidak sama sekali. Saya akan mentransfer database sejauh ini untuk setidaknya meringankan server yang ada. Dalam waktu yang dinegosiasikan, ia melakukan semua transfer, tetapi situasinya tidak berubah - semua masalah kinerja yang sama. Aneh, tentu saja, yah, mari kita daftarkan pangkalan di cluster 1C, kita akan lihat.
Butuh beberapa hari, kunci belum ditransfer. Saya tertarik dengan masalahnya, semuanya tampak sederhana di sana - saya menghapusnya dari satu server, memasukkannya ke server lain, menginstal driver dan siap. Admin merespons, mengatakan sesuatu tentang penerusan porta, server virtual, dan banyak lagi.
Hmm ... server virtual? Tampaknya tidak pernah ada virtualisasi dan mereka tidak ... Saya ingat masalah yang cukup terkenal dengan ketidakmampuan untuk meneruskan kunci server 1C ke mesin virtual pada Hyper-V di Windows Server 2008. Dan di sini beberapa kecurigaan mulai menumpuk ...
Saya membuka manajer server - Peran - peran baru telah muncul - Hyper-V. Saya pergi ke manajer Hyper-V, saya melihat satu mesin virtual, saya terhubung ... Dan sungguh ... server database baru kami ...
Baiklah apa? Instruksi pihak berwenang dan rekomendasi saya terpenuhi, peran dipisahkan. Tugas bisa ditutup.
Setelah beberapa waktu, krisis sekarang terjadi, cabang baru harus ditutup, beban berkurang, kinerja sistem menjadi lebih atau kurang dapat ditoleransi.
Yah, tentu saja, mereka tidak dapat meneruskan kunci server ke mesin virtual. Akibatnya, semuanya seperti apa adanya dan pergi: server terminal + 1C cluster pada mesin fisik, server database di tempat yang sama di virtual.
Dan baiklah, apakah itu semacam kantor Sharashkin. Jadi tidak. Sebuah perusahaan terkenal, produk yang mungkin Anda ketahui dan lihat di departemen terkait semua jenis Pita dan Auchanov.
Jadwal Liburan Hard Drive
Satu perusahaan induk besar dengan rencana ambisius
untuk mengambil alih dunia sekali lagi membeli sebuah perusahaan kecil dengan tujuan untuk memasukkannya ke dalam perusahaan besar. Di semua divisi dari holding ini, pengguna bekerja di database mereka, tetapi dengan konfigurasi yang sama. Jadi kami memulai proyek kecil untuk memasukkan unit baru dalam sistem ini.
Pertama-tama, perlu untuk mengerahkan pangkalan tempur dan uji coba. Pengembang menerima data untuk koneksi, masuk ke server, melihat MS SQL yang diinstal, server 1C, melihat 2 drive logis: drive C 250 gigabyte dan drive D 1 terabyte. Nah, "C" adalah sistem, "D" untuk data, pengembang memutuskan dan menyebarkan semua basis data secara logis di sana. Saya bahkan mengatur rencana pemeliharaan, termasuk cadangan, untuk berjaga-jaga (meskipun kami tidak bertanggung jawab untuk ini). Cadangan sejati mulai terbentuk di sini di "D". Di masa depan, sudah direncanakan untuk mengkonfigurasi ulang sudah pada beberapa sumber daya jaringan yang terpisah.
Proyek ini diluncurkan, konsultan mengadakan pelatihan tentang cara bekerja dalam sistem baru, sisa makanan ditransfer, beberapa perbaikan kecil dilakukan dan pengguna mulai bekerja di basis informasi baru.
Semuanya berjalan dengan baik sampai suatu pagi pada hari Senin ditemukan bahwa drive basis data telah hilang. Tidak ada "D" di server dan hanya itu.
Penyelidikan lebih lanjut mengungkapkan ini: pada kenyataannya, "server" ini adalah komputer yang berfungsi dari administrator sistem lokal. Benar, OS server masih ada di sana. Disk USB pribadi admin ini dimasukkan ke server. Dan administrator pergi berlibur dengan membawa sekrupnya sendiri, dengan tujuan memompa film di atasnya di jalan.
Alhamdulillah, dia tidak berhasil menghapus file database dan berhasil mengembalikan database yang berfungsi.
Perlu dicatat bahwa semua orang, secara umum, puas dengan kinerja sistem yang terletak pada USB-drive. Tidak ada yang mengeluh tentang pekerjaan 1C yang tidak memuaskan. Sudah saatnya megaproyek mulai di holding untuk mentransfer semua database informasi ke platform terpusat tunggal dengan server super, penyimpanan jutaan + rubel, hypervisor canggih dan rem 1C yang tak tertahankan di semua cabang.
Tapi ini adalah kisah yang sangat berbeda ...
PS Lihat juga: