Semua pembangun 1C dalam satu cara atau yang lain berinteraksi rapat dengan perkhidmatan IT dan secara langsung dengan pentadbir sistem. Tetapi interaksi ini tidak selalu berjalan lancar. Saya ingin memberitahu anda beberapa cerita lucu tentang ini.
Saluran komunikasi berkelajuan tinggi
Kebanyakan pelanggan kami adalah pegangan besar dengan jabatan IT besar mereka sendiri. Dan pakar pelanggan biasanya bertanggungjawab untuk salinan sandaran pangkalan data maklumat. Tetapi terdapat juga organisasi yang agak kecil. Terutama bagi mereka, kami mempunyai perkhidmatan yang mengikutnya kami mengambil alih semua isu yang berkaitan dengan sandaran semua 1C. Inilah syarikat yang akan kita bincangkan dalam cerita ini.
Pelanggan baharu datang untuk menyokong 1C dan, antara lain, kontrak itu termasuk klausa bahawa kami bertanggungjawab untuk membuat sandaran, walaupun mereka mempunyai pentadbir sistem mereka sendiri pada kakitangan. Pangkalan data pelayan pelanggan, MS SQL sebagai DBMS. Situasi yang agak standard, tetapi masih terdapat satu nuansa: asas utama agak besar, tetapi kenaikan bulanan adalah sangat kecil. Iaitu, pangkalan data mengandungi banyak data sejarah. Dengan mengambil kira ciri ini, saya menyediakan pelan penyelenggaraan sandaran seperti berikut: pada hari Sabtu pertama setiap bulan sandaran penuh dibuat, ia agak berat, kemudian salinan pembezaan dibuat setiap malam - volum yang agak kecil, dan salinan daripada log transaksi setiap jam. Selain itu, salinan penuh dan berbeza bukan sahaja disalin ke sumber rangkaian, tetapi juga dimuat naik tambahan ke pelayan FTP kami. Ini adalah keperluan wajib semasa menyediakan perkhidmatan ini.
Semua ini telah berjaya dikonfigurasikan, dimasukkan ke dalam operasi dan secara amnya berfungsi tanpa kegagalan.
Tetapi beberapa bulan kemudian, pentadbir sistem dalam organisasi ini berubah. Pentadbir sistem baharu mula membina semula infrastruktur IT syarikat secara beransur-ansur mengikut trend moden. Khususnya, virtualisasi muncul, rak cakera, akses telah disekat di mana-mana dan segala-galanya, dan lain-lain, yang dalam kes umum, sudah tentu, tidak boleh tidak bergembira. Tetapi perkara tidak selalu berjalan lancar untuknya; sering terdapat masalah dengan prestasi 1C, yang menyebabkan beberapa perselisihan faham dan perselisihan faham dengan sokongan kami. Juga, perlu diingatkan bahawa hubungan kami dengannya secara amnya agak dingin dan agak tegang, yang hanya meningkatkan tahap ketegangan sekiranya berlaku sebarang masalah.
Tetapi pada suatu pagi ternyata pelayan pelanggan ini tidak tersedia. Saya menghubungi pentadbir sistem untuk mengetahui perkara yang berlaku dan menerima jawapan seperti "Pelayan kami telah ranap, kami sedang mengusahakannya, bukan bergantung kepada anda." Baiklah mereka bekerja. Ini bermakna keadaan terkawal. Selepas makan tengah hari, saya menelefon semula, dan bukannya kerengsaan, saya sudah boleh merasakan keletihan dan sikap tidak peduli dalam suara pentadbir. Saya cuba memikirkan apa yang berlaku dan adakah apa-apa yang boleh kami lakukan untuk membantu? Hasil daripada perbualan, perkara berikut muncul:
Dia memindahkan pelayan ke sistem storan baharu dengan serbuan yang baru dipasang. Tetapi sesuatu yang tidak kena dan beberapa hari kemudian serbuan ini selamat runtuh. Sama ada pengawal terbakar atau sesuatu berlaku pada cakera, saya tidak ingat dengan tepat, tetapi semua maklumat telah hilang tanpa dapat dikembalikan. Dan perkara utama ialah sumber rangkaian dengan sandaran juga berakhir pada tatasusunan cakera yang sama semasa pelbagai migrasi. Iaitu, kedua-dua pangkalan data produktif itu sendiri dan semua salinan sandarannya telah hilang. Dan tidak jelas apa yang perlu dilakukan sekarang.
Tenang, kataku. Kami mempunyai sandaran malam anda. Sebagai tindak balas, terdapat kesunyian, yang mana saya menyedari bahawa saya baru sahaja menyelamatkan nyawa seorang lelaki. Kami mula membincangkan cara memindahkan salinan ini ke pelayan baharu yang baru digunakan. Tetapi di sini juga timbul masalah.
Ingat apabila saya mengatakan bahawa sandaran penuh agak besar? Bukan sia-sia saya melakukannya sebulan sekali pada hari Sabtu. Hakikatnya ialah syarikat itu adalah sebuah kilang kecil, yang terletak jauh di luar bandar dan Internet mereka sangat-sangat-sangat. Menjelang pagi Isnin, iaitu pada hujung minggu, salinan ini hampir tidak dapat dimuat naik ke pelayan FTP kami. Tetapi tidak ada cara untuk menunggu satu atau dua hari untuk ia dimuatkan ke arah yang bertentangan. Selepas beberapa percubaan yang tidak berjaya untuk memindahkan fail, pentadbir mengeluarkan cakera keras terus dari pelayan baru, menemui sebuah kereta dengan pemandu di suatu tempat dan dengan cepat bergegas ke pejabat kami, mujur kami masih di bandar yang sama.
Semasa mereka berdiri di bilik pelayan kami dan menunggu fail disalin, kami bertemu buat pertama kali, boleh dikatakan, "secara peribadi," minum secawan kopi, dan bercakap dalam suasana tidak formal. Saya bersimpati dengan kesedihannya dan menghantarnya kembali dengan sandaran penuh, tergesa-gesa memulihkan kerja syarikat yang terhenti.
Selepas itu, semua permintaan kami kepada jabatan IT telah diselesaikan dengan cepat dan tiada lagi perselisihan faham yang timbul.
Hubungi pentadbir sistem anda
Sekali, untuk masa yang sangat lama, saya tidak dapat menerbitkan 1C untuk akses web melalui IIS untuk satu pelanggan. Ia kelihatan seperti tugas biasa, tetapi tidak ada cara untuk menjalankan semuanya. Pentadbir sistem tempatan terlibat dan mencuba tetapan dan fail konfigurasi yang berbeza. 1C di web biasanya tidak mahu berfungsi dalam apa jua cara. Sesuatu yang tidak kena, sama ada dengan dasar keselamatan domain, atau dengan tembok api canggih tempatan, atau Tuhan tahu apa lagi. Pada lelaran ke-N, pentadbir menghantar saya pautan dengan perkataan:
- Cuba lagi menggunakan arahan ini. Segala-galanya diterangkan di sana dengan agak terperinci. Jika ia tidak berfungsi, tulis kepada pengarang laman web ini, mungkin dia boleh membantu.
"Tidak," saya berkata, "ia tidak akan membantu."
- Mengapa?
β Saya adalah pengarang laman web ini... (
Akibatnya, kami melancarkannya pada Apache tanpa sebarang masalah. IIS tidak pernah dikalahkan.
Satu tahap lebih dalam
Kami mempunyai pelanggan - perusahaan pembuatan kecil. Mereka mempunyai pelayan, sejenis "klasik" 3 dalam 1: pelayan terminal + pelayan aplikasi + pelayan pangkalan data. Mereka bekerja dalam beberapa konfigurasi khusus industri berdasarkan UPP, terdapat kira-kira 15-20 pengguna, dan prestasi sistem, pada dasarnya, sesuai untuk semua orang.
Apabila masa berlalu, semuanya berfungsi dengan lebih kurang stabil. Tetapi kemudian Eropah mengenakan sekatan terhadap Rusia, akibatnya orang Rusia mula membeli terutamanya produk keluaran tempatan, dan perniagaan untuk syarikat ini meningkat dengan mendadak. Bilangan pengguna meningkat kepada 50-60 orang, cawangan baharu dibuka, dan aliran dokumen meningkat dengan sewajarnya. Dan kini pelayan semasa tidak lagi dapat menampung beban yang meningkat secara mendadak, dan 1C mula, seperti yang mereka katakan, untuk "melambatkan". Semasa waktu puncak, dokumen diproses selama beberapa minit, ralat menyekat berlaku, borang mengambil masa yang lama untuk dibuka, dan keseluruhan rangkaian perkhidmatan berkaitan yang lain. Pentadbir sistem tempatan menepis semua masalah, berkata, "Ini adalah 1C anda, anda akan memikirkannya." Kami telah berulang kali mencadangkan untuk menjalankan audit prestasi sistem, tetapi ia tidak pernah sampai kepada audit itu sendiri. Pelanggan hanya meminta cadangan tentang cara menyelesaikan masalah.
Baiklah, saya duduk dan menulis surat yang agak panjang tentang keperluan untuk memisahkan peranan pelayan terminal dan pelayan aplikasi dengan DBMS (yang, pada dasarnya, telah kami katakan berkali-kali sebelum ini). Saya menulis tentang DFSS pada pelayan terminal, tentang Memori Dikongsi, menyediakan pautan ke sumber berwibawa, dan juga mencadangkan beberapa pilihan untuk peralatan. Surat ini sampai kepada mereka yang berkuasa dalam syarikat itu, kembali ke jabatan IT dengan resolusi "Melaksanakan" dan pada umumnya ia telah dipecahkan.
Selepas beberapa lama, pentadbir menghantar saya alamat IP pelayan baharu dan kelayakan log masuk. Dia mengatakan bahawa komponen pelayan MS SQL dan 1C digunakan di sana, dan pangkalan data perlu dipindahkan, tetapi buat masa ini hanya kepada pelayan DBMS, kerana beberapa masalah telah timbul dengan kekunci 1C.
Saya masuk, memang, semua perkhidmatan sedang berjalan, pelayan tidak begitu berkuasa, tetapi ok, saya fikir ia lebih baik daripada tiada. Saya akan memindahkan pangkalan data buat masa ini untuk entah bagaimana melegakan pelayan semasa. Saya menyelesaikan semua pemindahan pada masa yang dipersetujui, tetapi keadaan tidak berubah - masih masalah prestasi yang sama. Memang pelik, sudah tentu, mari kita daftarkan pangkalan data dalam kelompok 1C dan kita akan lihat.
Beberapa hari berlalu, kunci belum dipindahkan. Saya tertanya-tanya apa masalahnya, segala-galanya nampaknya mudah - keluarkannya dari satu pelayan, pasangkannya ke yang lain, pasang pemacu dan anda selesai. Pentadbir bertindak balas dengan kecoh dan mengatakan sesuatu tentang pemajuan port, pelayan maya dan sebagainya.
Hmm... Pelayan maya? Nampaknya tidak pernah ada virtualisasi dan tidak pernah ada... Saya masih ingat masalah yang agak terkenal dengan kemustahilan untuk memajukan kunci pelayan 1C ke mesin maya pada Hyper-V dalam Windows Server 2008. Dan di sini beberapa syak wasangka mula terbentuk dalam diri saya...
Saya membuka pengurus pelayan - Peranan - peranan baru telah muncul - Hyper-V. Saya pergi ke pengurus Hyper-V, lihat satu mesin maya, sambung... Dan sesungguhnya... Pelayan pangkalan data baharu kami...
Jadi apa? Arahan pihak berkuasa dan cadangan saya telah dilaksanakan, peranan telah diasingkan. Tugas boleh ditutup.
Selepas beberapa lama, krisis sekarang berlaku, cawangan baru terpaksa ditutup, beban berkurangan, dan prestasi sistem menjadi lebih kurang boleh diterima.
Sudah tentu, mereka tidak dapat memajukan kunci pelayan ke mesin maya. Akibatnya, segala-galanya dibiarkan begitu sahaja: pelayan terminal + gugusan 1C pada mesin fizikal, pelayan pangkalan data di sana dalam satu maya.
Dan alangkah baiknya jika ini adalah sejenis pejabat sharashkin. Jadi tidak. Sebuah syarikat terkenal yang produknya mungkin anda kenali dan pernah lihat di jabatan yang berkaitan di semua Lentas dan Auchan.
Jadual percutian cakera keras
Sebuah syarikat induk besar dengan rancangan bercita-cita tinggi untuk mengambil alih dunia sekali lagi telah membeli sebuah syarikat kecil dengan matlamat untuk memasukkannya ke dalam syarikat meganya. Dalam semua bahagian pegangan ini, pengguna bekerja dalam pangkalan data mereka sendiri, tetapi dengan konfigurasi yang sama. Maka kami memulakan projek kecil untuk memasukkan unit baharu dalam sistem ini.
Pertama sekali, adalah perlu untuk menggunakan pangkalan data pengeluaran dan ujian. Pemaju menerima data sambungan, log masuk ke pelayan, melihat MS SQL dipasang, pelayan 1C, melihat 2 pemacu logik: pemacu "C" dengan kapasiti 250 gigabait dan pemacu "D" dengan kapasiti 1 terabait. Nah, "C" ialah sistem, "D" adalah untuk data, pembangun secara logik memutuskan dan menggunakan semua pangkalan data di sana. Saya juga menyediakan pelan penyelenggaraan, termasuk sandaran, untuk berjaga-jaga (walaupun kami tidak bertanggungjawab untuk ini). Benar, sandaran telah ditambahkan di sini pada "D". Pada masa hadapan, ia telah dirancang untuk mengkonfigurasi semula ia kepada beberapa sumber rangkaian yang berasingan.
Projek dimulakan, perunding menyediakan latihan tentang cara bekerja dalam sistem baharu, sisa makanan dipindahkan, beberapa penambahbaikan kecil kecil dibuat, dan pengguna mula bekerja di pangkalan maklumat baharu.
Semuanya berjalan lancar sehingga satu pagi Isnin apabila didapati bahawa cakera pangkalan data hilang. Tiada "D" pada pelayan dan itu sahaja.
Siasatan lanjut mendedahkan ini: "pelayan" ini sebenarnya adalah komputer kerja pentadbir sistem tempatan. Benar, ia masih mempunyai OS pelayan. Pemacu USB peribadi pentadbir ini telah dipalamkan ke pelayan. Oleh itu, pentadbir pergi bercuti, membawa skru bersamanya, dengan matlamat untuk mengepam filem ke dalamnya untuk perjalanan itu.
Alhamdulillah, dia tidak berjaya memadam fail pangkalan data dan berjaya memulihkan pangkalan data yang produktif.
Perlu diperhatikan bahawa semua orang secara amnya berpuas hati dengan prestasi sistem yang terletak pada pemacu USB. Tiada siapa yang mengadu tentang prestasi 1C yang tidak memuaskan. Hanya kemudiannya pegangan itu memulakan projek mega untuk memindahkan semua pangkalan data maklumat ke tapak terpusat tunggal dengan pelayan super, sistem storan untuk sejuta+ rubel, hipervisor canggih dan brek 1C yang tidak tertanggung di semua cawangan.
Tetapi itu cerita yang sama sekali berbeza...
Sumber: www.habr.com