Kisah pengembang 1C: milik admin

Semua pengembang 1C dalam satu atau lain cara berinteraksi erat dengan layanan TI dan langsung dengan administrator sistem. Namun interaksi ini tidak selalu berjalan mulus. Saya ingin menceritakan beberapa cerita lucu tentang ini.

Saluran komunikasi berkecepatan tinggi

Sebagian besar klien kami adalah perusahaan besar yang memiliki departemen TI mereka sendiri yang besar. Dan spesialis klien biasanya bertanggung jawab atas salinan cadangan database informasi. Namun ada juga organisasi yang relatif kecil. Khusus untuk mereka, kami memiliki layanan yang dapat menangani sendiri semua masalah yang terkait dengan pencadangan semua 1C. Ini adalah perusahaan yang akan kita bicarakan dalam cerita ini.

Klien baru datang untuk mendukung 1C dan, antara lain, kontrak tersebut menyertakan klausul bahwa kami bertanggung jawab atas pencadangan, meskipun mereka memiliki staf administrator sistem sendiri. Basis data klien-server, MS SQL sebagai DBMS. Situasi yang cukup standar, namun masih ada satu peringatan: basis utama cukup besar, namun peningkatan bulanannya sangat kecil. Artinya, database berisi banyak data historis. Dengan mempertimbangkan fitur ini, saya menyiapkan rencana pemeliharaan pencadangan sebagai berikut: pada hari Sabtu pertama setiap bulan pencadangan penuh dilakukan, cukup berat, kemudian salinan diferensial dibuat setiap malam - volume yang relatif kecil, dan salinan dari log transaksi setiap jam. Selain itu, salinan lengkap dan diferensial tidak hanya disalin ke sumber daya jaringan, tetapi juga diunggah ke server FTP kami. Ini merupakan persyaratan wajib saat menyediakan layanan ini.

Semua ini berhasil dikonfigurasi, dioperasikan, dan secara umum berfungsi tanpa kegagalan.

Namun beberapa bulan kemudian, administrator sistem di organisasi ini berubah. Administrator sistem baru mulai secara bertahap membangun kembali infrastruktur TI perusahaan sesuai dengan tren modern. Secara khusus, virtualisasi muncul, rak disk, akses diblokir di mana-mana dan segalanya, dll., yang secara umum, tentu saja, merupakan kabar baik. Namun hal-hal tidak selalu berjalan mulus baginya; sering kali ada masalah dengan kinerja 1C, yang menyebabkan beberapa perbedaan pendapat dan kesalahpahaman dengan dukungan kami. Perlu juga dicatat bahwa hubungan kami dengannya secara umum cukup dingin dan agak tegang, yang hanya meningkatkan tingkat ketegangan jika ada masalah yang timbul.

Namun suatu pagi ternyata server klien ini tidak tersedia. Saya menelepon administrator sistem untuk mencari tahu apa yang terjadi dan menerima jawaban seperti "Server kami mogok, kami sedang mengerjakannya, bukan terserah Anda." Yah, baguslah mereka berhasil. Artinya situasi terkendali. Setelah makan siang, saya menelepon kembali, dan bukannya kesal, saya sudah merasakan kelelahan dan apatis dalam suara admin. Saya mencoba mencari tahu apa yang terjadi dan adakah yang bisa kami lakukan untuk membantu? Dari hasil perbincangan tersebut, muncullah hal-hal sebagai berikut:

Dia memindahkan server ke sistem penyimpanan baru dengan serangan yang baru dirakit. Tapi ada yang tidak beres dan beberapa hari kemudian serangan ini gagal dengan aman. Apakah pengontrolnya terbakar atau terjadi sesuatu pada disk, saya tidak ingat persisnya, tetapi semua informasi hilang dan tidak dapat diambil kembali. Dan yang terpenting adalah sumber daya jaringan dengan cadangan juga berakhir di susunan disk yang sama selama berbagai migrasi. Artinya, database produktif itu sendiri dan semua salinan cadangannya hilang. Dan tidak jelas apa yang harus dilakukan sekarang.

Tenang, kataku. Kami memiliki cadangan malam Anda. Sebagai tanggapan, terjadilah keheningan, saat itulah saya menyadari bahwa saya baru saja menyelamatkan nyawa seorang pria. Kami mulai membahas cara mentransfer salinan ini ke server baru yang baru dikerahkan. Namun di sini juga muncul masalah.

Ingat ketika saya mengatakan bahwa full backup cukup besar? Bukan tanpa alasan saya melakukannya sebulan sekali pada hari Sabtu. Faktanya adalah perusahaan itu adalah pabrik kecil, yang terletak jauh di luar kota dan internetnya biasa-biasa saja. Pada Senin pagi, yaitu pada akhir pekan, salinan ini hampir tidak dapat diunggah ke server FTP kami. Namun tidak ada cara untuk menunggu satu atau dua hari hingga memuat ke arah yang berlawanan. Setelah beberapa kali gagal mentransfer file, administrator mengeluarkan hard drive langsung dari server baru, menemukan mobil dengan sopir di suatu tempat dan segera bergegas ke kantor kami, untungnya kami masih berada di kota yang sama.

Saat mereka berdiri di ruang server kami dan menunggu file disalin, kami bertemu untuk pertama kalinya, bisa dikatakan, “secara langsung”, minum secangkir kopi, dan berbicara dalam suasana informal. Saya bersimpati dengan kesedihannya dan mengirimnya kembali dengan cadangan penuh, segera memulihkan pekerjaan perusahaan yang terhenti.

Selanjutnya, semua permintaan kami ke departemen TI diselesaikan dengan sangat cepat dan tidak ada lagi perselisihan yang muncul.

Hubungi administrator sistem Anda

Suatu kali, untuk waktu yang sangat lama, saya tidak dapat mempublikasikan 1C untuk akses web melalui IIS untuk satu klien. Tampaknya seperti tugas biasa, namun tidak ada cara untuk membuat semuanya berjalan. Administrator sistem lokal terlibat dan mencoba berbagai pengaturan dan file konfigurasi. 1C di web biasanya tidak mau bekerja dengan cara apa pun. Ada yang salah, baik dengan kebijakan keamanan domain, atau dengan firewall lokal yang canggih, atau entah apa lagi. Pada iterasi ke-N, admin mengirimi saya link dengan tulisan:

- Coba lagi menggunakan petunjuk ini. Semuanya dijelaskan di sana dengan cukup detail. Jika tidak berhasil, tulislah ke penulis situs ini, mungkin dia bisa membantu.
“Tidak,” kataku, “itu tidak akan membantu.”
- Mengapa tidak?
— Saya adalah penulis situs ini... (

Hasilnya, kami meluncurkannya di Apache tanpa masalah. IIS tidak pernah dikalahkan.

Satu tingkat lebih dalam

Kami memiliki klien - sebuah perusahaan manufaktur kecil. Mereka memiliki server, semacam “klasik” 3 in 1: server terminal + server aplikasi + server database. Mereka bekerja dalam konfigurasi khusus industri berdasarkan UPP, ada sekitar 15-20 pengguna, dan kinerja sistem, pada prinsipnya, cocok untuk semua orang.

Seiring berjalannya waktu, semuanya berjalan kurang lebih stabil. Namun kemudian Eropa menjatuhkan sanksi terhadap Rusia, akibatnya orang Rusia mulai membeli sebagian besar produk produksi dalam negeri, dan bisnis perusahaan ini meningkat tajam. Jumlah pengguna meningkat menjadi 50-60 orang, cabang baru dibuka, dan aliran dokumen pun meningkat. Dan sekarang server saat ini tidak dapat lagi mengatasi beban yang meningkat tajam, dan 1C mulai, seperti yang mereka katakan, “melambat”. Pada jam sibuk, dokumen diproses selama beberapa menit, terjadi kesalahan pemblokiran, formulir membutuhkan waktu lama untuk dibuka, dan berbagai layanan terkait lainnya. Administrator sistem lokal menepis semua masalah tersebut, dengan mengatakan, "Ini adalah 1C Anda, Anda akan mengetahuinya." Kami telah berulang kali mengusulkan untuk melakukan audit kinerja terhadap sistem, namun tidak pernah sampai pada audit itu sendiri. Klien hanya meminta rekomendasi tentang cara memperbaiki masalah.

Baiklah, saya duduk dan menulis surat yang agak panjang tentang perlunya memisahkan peran server terminal dan server aplikasi dengan DBMS (yang, pada prinsipnya, telah kami katakan berkali-kali sebelumnya). Saya menulis tentang DFSS di server terminal, tentang Memori Bersama, memberikan tautan ke sumber resmi, dan bahkan menyarankan beberapa opsi untuk peralatan. Surat ini sampai kepada mereka yang berkuasa di perusahaan, kembali ke departemen TI dengan resolusi “Terapkan” dan suasana secara umum terpecahkan.

Setelah beberapa waktu, admin mengirimi saya alamat IP server baru dan kredensial login. Dia mengatakan bahwa komponen server MS SQL dan 1C dikerahkan di sana, dan database perlu ditransfer, tetapi untuk saat ini hanya ke server DBMS, karena beberapa masalah telah muncul dengan kunci 1C.

Saya masuk, memang semua layanan berjalan, servernya tidak terlalu kuat, tapi oke, menurut saya itu lebih baik daripada tidak sama sekali. Saya akan mentransfer database untuk saat ini untuk meringankan server saat ini. Saya menyelesaikan semua transfer pada waktu yang disepakati, tetapi situasinya tidak berubah - masalah kinerja masih sama. Aneh tentu saja, mari kita daftarkan database di cluster 1C dan kita lihat saja nanti.

Beberapa hari berlalu, kuncinya belum juga ditransfer. Saya bertanya-tanya apa masalahnya, semuanya tampak sederhana - keluarkan dari satu server, sambungkan ke server lain, instal driver dan selesai. Admin merespons dengan meributkan dan mengatakan sesuatu tentang penerusan porta, server virtual, dan sebagainya.

Hmm... Server virtual? Sepertinya tidak pernah ada virtualisasi dan tidak pernah ada... Saya ingat masalah yang cukup terkenal dengan ketidakmungkinan meneruskan kunci server 1C ke mesin virtual pada Hyper-V di Windows Server 2008. Dan di sini beberapa kecurigaan mulai terbentuk dalam diriku...

Saya membuka manajer server - Peran - peran baru telah muncul - Hyper-V. Saya pergi ke manajer Hyper-V, melihat satu mesin virtual, menghubungkan... Dan memang... Server database baru kami...

Terus? Instruksi penguasa dan rekomendasi saya sudah dijalankan, peran sudah dipisahkan. Tugas dapat ditutup.

Setelah beberapa waktu, krisis terjadi, cabang baru harus ditutup, beban menurun, dan kinerja sistem menjadi kurang lebih dapat ditoleransi.

Tentu saja, mereka tidak dapat meneruskan kunci server ke mesin virtual. Akibatnya, semuanya dibiarkan apa adanya: server terminal + cluster 1C di mesin fisik, server database di sana di mesin virtual.

Dan alangkah baiknya jika ini menjadi semacam kantor sharashkin. Jadi tidak. Perusahaan terkenal yang produknya mungkin Anda ketahui dan pernah lihat di departemen terkait di semua Lentas dan Auchan.

Jadwal liburan hard drive

Sebuah perusahaan induk besar dengan rencana ambisius untuk mengambil alih dunia sekali lagi membeli sebuah perusahaan kecil dengan tujuan memasukkannya ke dalam perusahaan besarnya. Di semua divisi holding ini, pengguna bekerja di database mereka sendiri, tetapi dengan konfigurasi yang sama. Jadi kami memulai proyek kecil untuk memasukkan unit baru ke dalam sistem ini.

Pertama-tama, perlu untuk menyebarkan database produksi dan pengujian. Pengembang menerima data koneksi, masuk ke server, melihat MS SQL terinstal, server 1C, melihat 2 drive logis: drive "C" dengan kapasitas 250 gigabyte dan drive "D" dengan kapasitas 1 terabyte. Nah, “C” adalah sistemnya, “D” adalah untuk data, pengembang secara logis memutuskan dan menyebarkan semua database di sana. Saya bahkan menyiapkan rencana pemeliharaan, termasuk cadangan, untuk berjaga-jaga (walaupun kami tidak bertanggung jawab atas hal ini). Benar, cadangan ditambahkan di sini ke "D". Di masa depan, direncanakan untuk mengkonfigurasi ulang ke beberapa sumber daya jaringan yang terpisah.

Proyek dimulai, konsultan memberikan pelatihan tentang cara bekerja dalam sistem baru, sisa-sisa dipindahkan, beberapa perbaikan kecil dilakukan, dan pengguna mulai bekerja di basis informasi baru.

Semuanya berjalan baik sampai suatu Senin pagi ketika ditemukan bahwa disk database hilang. Tidak ada “D” di server dan hanya itu.

Penyelidikan lebih lanjut mengungkap hal ini: “server” ini sebenarnya adalah komputer kerja administrator sistem lokal. Benar, ia masih memiliki OS server. Drive USB pribadi admin ini telah dicolokkan ke server. Maka sang administrator pergi berlibur, membawa sekrupnya, dengan tujuan memasukkan film ke dalamnya untuk perjalanan tersebut.

Alhamdulillah, dia tidak berhasil menghapus file database dan berhasil memulihkan database produktif.

Patut dicatat bahwa setiap orang pada umumnya puas dengan kinerja sistem yang terletak pada drive USB. Tidak ada yang mengeluh tentang kinerja 1C yang tidak memuaskan. Baru kemudian holding memulai mega-proyek untuk mentransfer semua database informasi ke satu situs terpusat dengan server super, sistem penyimpanan lebih dari satu juta rubel, hypervisor canggih, dan rem 1C yang tak tertahankan di semua cabang.

Tapi itu cerita yang sama sekali berbeda...

Sumber: www.habr.com