♋️ 🆔 ♦️ Kami memeriksa diri kami sendiri: cara menyebarkan dan cara mengelola 1C: Alur dokumen dalam perusahaan 1C 👟 👈🏾 🧗

Kami di 1C secara luas menggunakan perkembangan kami sendiri untuk mengatur pekerjaan perusahaan. Secara khusus, "1C: Manajemen Dokumen 8" . Selain manajemen dokumen (sesuai namanya), ini juga merupakan sistem ECM modern (Enterprise Content Management - manajemen konten perusahaan) dengan berbagai fungsi - surat, kalender kerja karyawan, organisasi akses bersama ke sumber daya (misalnya, pemesanan ruang konferensi), akuntansi jam kerja, forum perusahaan dan banyak lagi.

Di 1C, lebih dari seribu karyawan menggunakan dokumen. Basis data telah menjadi mengesankan (11 miliar catatan), yang berarti membutuhkan pemeliharaan yang lebih menyeluruh dan peralatan yang lebih kuat.

Bagaimana cara kerja sistem kita diatur, kesulitan apa yang kita hadapi dalam melayani database, dan bagaimana kita menyelesaikannya (kita menggunakan MS SQL Server sebagai DBMS), kita akan jelaskan di artikel.

Bagi mereka yang pertama kali membaca tentang produk 1C.
1C: Manajemen dokumen adalah solusi aplikasi (konfigurasi) yang diimplementasikan berdasarkan kerangka kerja untuk mengembangkan aplikasi bisnis - 1C: Platform perusahaan.

gambar

"1C: Document Management 8" (dalam bentuk disingkat - DO) memungkinkan Anda untuk mengotomatiskan pekerjaan dengan dokumen di perusahaan. Salah satu alat utama untuk interaksi karyawan adalah email. Selain mengirim surat, DO juga menyelesaikan tugas lain:

Pelacakan waktu
Akuntansi untuk absensi
Aplikasi untuk kurir / transportasi
Kalender Karyawan
Pendaftaran korespondensi
Kontak Karyawan (Buku Alamat)
Forum perusahaan
Pemesanan kamar
Perencanaan acara
CRM
Kerja kolektif dengan file (dengan mempertahankan versi file)
dan sebagainya.

Kami memasuki Manajemen Dokumen sebagai klien tipis (aplikasi yang dapat dieksekusi asli) dari Windows, Linux, macOS, klien web (dari browser) dan klien seluler - tergantung pada situasinya.

Dan terima kasih kepada produk kami yang terhubung dengan Manajemen Dokumen - Sistem Interaksi- kami langsung di Manajemen Dokumen menerima fungsionalitas messenger - obrolan, panggilan audio dan video (termasuk panggilan grup, yang kini menjadi sangat penting, termasuk dari klien seluler), berbagi file cepat plus kemampuan untuk menulis bot obrolan yang mempermudah kerja dengan sistem. Kelebihan lainnya dari menggunakan Sistem Interaksi (dibandingkan dengan rasul lain) adalah kemampuan untuk melakukan diskusi kontekstual terkait dengan objek tertentu dari Manajemen Dokumen - dokumen, acara, dll. Artinya, Sistem Interaksi terintegrasi secara mendalam dengan aplikasi target, dan tidak bertindak sebagai "tombol terpisah".

Jumlah surat dalam DL kami telah melebihi 100 juta, dan secara umum dalam DBMS - lebih dari 11 miliar catatan. Secara total, sistem ini menggunakan hampir 30 TB penyimpanan: basis datanya adalah 7,5 TB, file untuk pekerjaan kolektif terpisah dan menempati 21 TB lainnya.

Jika kita berbicara tentang angka yang lebih spesifik, maka di sini adalah jumlah huruf dan file saat ini:

Surat keluar - 14,7 juta.
Surat yang masuk - 85,4 juta
Versi File - 70,8 Juta
Dokumen internal - 30,6 ribu

Dalam DO tidak hanya ada surat dan file. Di bawah ini adalah sejumlah objek akuntansi lainnya:

Reservasi ruang konferensi - 52 126
Laporan mingguan - 153.940
Laporan harian - 628 153
Persetujuan visa - 11.821
Dokumen yang masuk - 79 677
Dokumen keluar - 28 357
Rekaman acara dalam kalender kerja pengguna - 168.228
Aplikasi untuk kurir - 21 883
Rekanan - 81 029
Catatan pekerjaan dengan kontraktor - 45 632
– 41 795
– 10 243
– 6 320
– 245 980
– 26 282
– 891 095
- – 109 056. – , , , , .. , , , , . , , .

?

Angka-angka ini menunjukkan jumlah tugas yang mengesankan, jadi kami menghadapi kebutuhan untuk mengalokasikan peralatan yang cukup produktif untuk kebutuhan anak perusahaan internal. Sampai saat ini, karakteristiknya adalah sebagai berikut: 38 core, 240 GB RAM, 26 TB drive. Kami
gambar

memberikan tabel server: Di masa depan kami berencana untuk meningkatkan kapasitas peralatan.

Bagaimana dengan pemuatan server?

Aktivitas jaringan tidak pernah menjadi masalah bagi kami atau pelanggan kami. Sebagai aturan, titik lemahnya adalah prosesor dan disk, karena semua orang sudah tahu cara menangani kekurangan memori. Berikut adalah screenshot dari server kami dari Resource Monitor, yang menunjukkan bahwa kami tidak memiliki beban yang buruk, ini sangat sederhana.

Misalnya, pada tangkapan layar di bawah ini, kita melihat server SQL tempat CPU dimuat 23%. Dan ini adalah indikator yang sangat baik (sebagai perbandingan: jika beban mendekati 70%, maka, kemungkinan besar, karyawan akan mengamati perlambatan yang cukup signifikan).

gambar

Tangkapan layar kedua menunjukkan server aplikasi tempat platform 1C: Enterprise berjalan - hanya melayani sesi pengguna. Di sini beban prosesor sedikit lebih tinggi - 38%, lancar dan tenang. Ada pemuatan disk, tapi itu bisa diterima.

gambar

Tangkapan layar ketiga menunjukkan 1C lain: Server perusahaan (ini adalah yang kedua, kami memiliki dua dari mereka di cluster). Hanya yang sebelumnya melayani pengguna, dan robot bekerja untuk ini. Misalnya, mereka menerima surat, merutekan dokumen, bertukar data, mempertimbangkan hak, dll. Semua kegiatan latar belakang ini melakukan sekitar 90-100 tugas latar belakang. Dan server ini sangat sibuk - pada 88%. Tetapi ini tidak memengaruhi orang, dan hanya menerapkan semua otomatisasi yang harus dilakukan Manajemen Dokumen.

gambar

Apa metrik untuk menentukan kinerja?

Kami telah membangun ke dalam BS suatu subsistem yang serius untuk mengukur indikator kinerja dan menghitung berbagai metrik. Ini diperlukan untuk memahami pada saat saat ini dan dalam perspektif sejarah apa yang terjadi dalam sistem, apa yang semakin buruk, apa yang semakin baik. Alat pemantauan - metrik dan pengukuran waktu - termasuk dalam paket standar "1C: Manajemen Dokumen 8". Metrik memerlukan penyesuaian pada implementasi, tetapi mekanismenya sendiri tipikal.

Metrik adalah pengukuran berbagai indikator bisnis pada titik waktu tertentu (misalnya, waktu pengiriman surat rata-rata pada saat 10 menit).

Salah satu metrik menunjukkan jumlah pengguna aktif dalam database. Rata-rata, ada 1000-1400 dari mereka per hari. Grafik menunjukkan bahwa pada saat tangkapan layar ada 2144 pengguna aktif dalam database.

gambar

Ada lebih dari 30 tindakan seperti itu, daftarnya ada di bawah potongan.

Daftar

Seminggu sebelum yang lalu, aktivitas pengguna rata-rata kami meningkat satu setengah kali (ditunjukkan dengan warna merah pada grafik) - ini disebabkan oleh transisi sebagian besar karyawan ke pekerjaan jarak jauh (sehubungan dengan acara yang diketahui). Juga, jumlah pengguna aktif meningkat 3 kali lipat (ditunjukkan dengan warna biru di layar), ketika karyawan mulai aktif menggunakan ponsel: setiap klien seluler membuat koneksi ke server. Sekarang, secara rata-rata, untuk setiap karyawan kami, ada 2 koneksi ke server.

gambar

Bagi kami, seperti untuk administrator, ini adalah sinyal bahwa kami harus lebih memperhatikan masalah kecepatan, untuk melihat apakah itu menjadi lebih buruk. Dan kami melihatnya dengan cara lain. Misalnya, bagaimana waktu pengiriman email untuk perubahan rute internal (tangkapan layar di bawah ini menunjukkan warna biru). Kami melihat bahwa itu melonjak hingga tahun ini, dan sekarang stabil - bagi kami itu adalah indikator bahwa semuanya sesuai dengan sistem.

gambar

Metrik lain yang diterapkan bagi kami adalah waktu tunggu rata-rata untuk mengunduh surat dari server surat (ditunjukkan dengan warna merah di tangkapan layar). Secara kasar, berapa lama surat itu akan muncul di Internet sebelum sampai kepada karyawan kita. Tangkapan layar menunjukkan bahwa waktu ini juga tidak berubah dengan cara apa pun. Ada ledakan-ledakan terpisah - tetapi mereka tidak dikaitkan dengan penundaan, tetapi dengan fakta bahwa waktu hilang pada server mail.

gambar

Atau, misalnya, metrik lain (ditampilkan dengan warna biru di tangkapan layar) - memperbarui huruf dalam folder. Membuka folder surat adalah operasi yang sangat umum, dan perlu dilakukan dengan cepat. Kami mengukur seberapa cepat itu dilakukan. Indikator ini diukur untuk setiap klien. Anda dapat melihat gambaran keseluruhan perusahaan, dan dinamika, misalnya, dari seorang karyawan. Tangkapan layar menunjukkan bahwa hingga tahun ini metriknya tidak seimbang, maka kami melakukan sejumlah peningkatan, dan sekarang tidak bertambah buruk - jadwal yang hampir merata.

gambar

Metrik pada dasarnya adalah alat administrator untuk memantau sistem, untuk dengan cepat menanggapi setiap perubahan dalam perilaku sistem. Pada tangkapan layar - metrik DO internal selama satu tahun. Lompatan dalam grafik adalah karena fakta bahwa kami telah menetapkan tugas untuk mengembangkan anak perusahaan internal.

gambar

Berikut adalah daftar beberapa metrik lainnya (di bawah potongan).

Metrik

()
10
:
( )
( )
( )
( )
()
« »

Sistem kami melakukan pengukuran lebih dari 150 indikator setiap saat, tetapi tidak semuanya dapat dipantau dengan cepat. Mereka dapat berguna nanti, dalam beberapa perspektif sejarah, dan Anda dapat fokus pada yang paling penting untuk bisnis.

Di salah satu implementasi, misalnya, hanya 5 indikator yang dipilih. Pelanggan menentukan sendiri tujuan membuat serangkaian indikator minimum, tetapi pada saat yang sama ia mencakup skenario kerja utama. Tidak dapat dibenarkan untuk memasukkan 150 indikator dalam tindakan penerimaan, karena bahkan di dalam perusahaan sulit untuk menyepakati indikator mana yang dianggap dapat diterima. Dan mereka tahu tentang 5 indikator ini dan sudah mempresentasikannya ke sistem sebelum dimulainya proyek implementasi, termasuk dalam dokumentasi tender: waktu pembukaan kartu tidak lebih dari 3 detik, waktu pelaksanaan tugas dengan file tidak lebih dari 5 detik, dll. Di anak perusahaan kami, ada metrik yang sangat jelas mencerminkan permintaan awal dari persyaratan pelanggan.

Dan kami juga memiliki analisis profil pengukuran kinerja. Indikator kinerja adalah fiksasi dari durasi setiap operasi yang dilakukan (menulis surat ke basis data, mengirim surat ke server surat, dll.). Ini digunakan secara eksklusif oleh spesialis teknis. Kami memiliki banyak indikator kinerja dalam program kami. Kami sekarang mengukur sekitar 1.500 operasi utama, yang dikelompokkan berdasarkan profil.

gambar

Salah satu profil paling penting bagi kami adalah "Daftar indikator utama surat dari sudut pandang konsumen". Profil ini mencakup, misalnya, indikator berikut:

Eksekusi Perintah: Saring dengan Tag
Membuka formulir: Formulir daftar
Eksekusi Perintah: Pilih dengan Folder
Tampilkan huruf-huruf di area bacaan
Menyimpan surat ke folder favorit Anda
Cari huruf dengan detail
Buat surat

Jika kita melihat bahwa metrik untuk beberapa indikator bisnis telah menjadi terlalu besar (misalnya, surat dari pengguna tertentu mulai berdatangan untuk waktu yang sangat lama), kita mulai memahami, kita beralih ke mengukur waktu operasi teknis. Kami memiliki operasi teknis "Pengarsipan surat di server surat" - kami melihat kelebihan waktu untuk operasi ini untuk periode terakhir. Operasi ini, pada gilirannya, terurai menjadi operasi lain - misalnya, membuat koneksi ke server email. Kami melihat bahwa karena alasan tertentu tiba-tiba menjadi sangat besar (kami memiliki semua pengukuran dalam sebulan - kami dapat membandingkan minggu lalu 10 milidetik, dan sekarang 1000 milidetik). Dan kami memahami bahwa ada sesuatu yang rusak di sini - kami harus memperbaikinya.

Bagaimana kita memelihara basis data yang begitu besar?

DO internal kami adalah contoh dari proyek yang sangat sarat kerja. Mari kita bicara tentang fitur teknis dari basis datanya.

Berapa lama restrukturisasi tabel database besar?

SQL server membutuhkan pemeliharaan berkala, membersihkan tabel. Dalam cara yang baik, ini harus dilakukan setidaknya sekali sehari, dan untuk meja yang sangat dituntut - bahkan lebih sering. Tetapi jika basisnya besar (dan jumlah catatan kami telah melebihi 11 miliar), maka tidak mudah untuk mengurusnya.

Kami melakukan restrukturisasi tabel 6 tahun yang lalu, tetapi kemudian mulai memakan banyak waktu sehingga kami tidak lagi cocok dengan interval malam. Dan karena operasi ini sangat memuat server SQL, itu tidak dapat memberikan layanan berkualitas kepada pengguna lain.

Karena itu, sekarang kita harus menerapkan berbagai trik. Misalnya, kami tidak dapat melakukan prosedur ini pada set data lengkap. Anda harus menggunakan prosedur Perbarui Sampel 500000 baris - ini membutuhkan waktu 14 menit. Itu tidak memperbarui statistik untuk semua data dalam tabel, tetapi memilih setengah juta baris, dan menghitung statistik dari mereka yang digunakan untuk seluruh tabel. Ini adalah beberapa asumsi, tetapi kami terpaksa melakukannya, karena untuk tabel tertentu koleksi statistik untuk seluruh miliar catatan akan sangat panjang.

gambar

Kami juga mengoptimalkan operasi pemeliharaan lainnya dengan membuatnya parsial.

Pemeliharaan DBMS umumnya merupakan tugas yang sulit. Dalam hal interaksi aktif antara karyawan, basis data tumbuh dengan cepat, semakin sulit bagi administrator untuk mempertahankannya - memperbarui statistik, mendefragmentasi, dan mengindeks. Di sini kita perlu menerapkan strategi yang berbeda, kita tahu bagaimana melakukan ini, kita memiliki pengalaman, kita dapat membagikannya.

Bagaimana cadangan diterapkan dengan volume seperti itu?

Cadangan penuh DBMS dilakukan sekali sehari di malam hari, secara bertahap - setiap jam. Juga, direktori file dibuat setiap hari, dan itu adalah bagian dari cadangan tambahan penyimpanan file.

Berapa lama pencadangan penuh?

Pada hard disk, pencadangan penuh dilakukan dalam tiga jam, sebagian - dalam satu jam. Butuh waktu lebih lama untuk menulis ke kaset (perangkat khusus yang membuat salinan cadangan ke kaset khusus yang disimpan di luar kantor; salinan yang dapat diasingkan dibuat ke kaset, yang akan disimpan jika, misalnya, server terbakar). Pencadangan dilakukan persis pada server yang sama, yang parameternya lebih tinggi - SQL server dengan beban prosesor 20%. Pada saat pencadangan, tentu saja, sistem menjadi jauh lebih buruk, tetapi masih operasional.

gambar

Apakah ada deduplikasi?

Ada deduplikasi file, kami menjalankannya sendiri, dan segera akan dimasukkan dalam versi baru Manajemen Dokumen. Kami juga menjalankan mekanisme deduplikasi pihak lawan. Tidak ada deduplikasi catatan di tingkat DBMS, karena ini tidak perlu. 1C: Platform perusahaan menyimpan objek dalam DBMS, dan hanya platform yang dapat bertanggung jawab atas konsistensi mereka.

Apakah ada node baca-saja?

Tidak ada node untuk membaca (node sistem khusus yang melayani mereka yang perlu menerima data bacaan). DO bukan sistem akuntansi untuk memakai BI node terpisah, tetapi ada node terpisah untuk departemen pengembangan, yang dipertukarkan dengan pesan dalam format JSON, dan waktu replikasi yang khas adalah unit dan puluhan detik. Node ini masih kecil, memiliki sekitar 800 juta entri, tetapi ia tumbuh dengan cepat.

Dan pesan yang ditandai untuk dihapus sama sekali tidak dihapus?

Belum. Kami tidak memiliki tugas untuk memfasilitasi pangkalan. Ada beberapa kasus yang agak serius ketika saya harus beralih ke huruf yang ditandai untuk dihapus, termasuk 2009. Karena itu, untuk saat ini, kami memutuskan untuk menyimpan semuanya. Tetapi ketika biaya ini menjadi tidak dapat dibenarkan, kami akan berpikir tentang penghapusan. Tetapi, jika Anda perlu menghapus surat terpisah dari database dengan ujungnya sehingga tidak ada jejak, maka ini dapat dilakukan dengan permintaan khusus.

Kenapa menyimpannya? Apakah ada statistik tentang akses ke dokumen lama?

Tidak ada statistik. Lebih tepatnya, itu dalam bentuk log pengguna, tetapi tidak disimpan lama. Catatan yang lebih tua dari satu tahun dihapus dari protokol.

Ada situasi di mana perlu untuk meningkatkan korespondensi lama lima tahun atau bahkan sepuluh tahun yang lalu. Dan ini selalu dilakukan bukan karena keingintahuan, tetapi untuk membuat keputusan bisnis yang kompleks. Ada kasus ketika tanpa sejarah korespondensi keputusan bisnis yang salah akan dibuat.

Bagaimana pemeriksaan nilai dan perusakan dokumen sesuai dengan periode penyimpanan?

Untuk dokumen kertas, ini dilakukan dengan cara tradisional yang biasa, seperti orang lain. Untuk elektronik, kami tidak melakukannya - biarkan disimpan. Duduk di sini. Ada manfaatnya. Semuanya baik-baik saja.

Bagaimana prospek pengembangannya?

Sekarang DO kami memecahkan sekitar 30 masalah internal, beberapa di antaranya kami cantumkan di awal artikel. DO juga digunakan untuk menyiapkan konferensi yang kami adakan dua kali setahun untuk mitra kami: seluruh program, semua laporan, semua bagian paralel, aula - semua ini dibuat dalam DO, dan kemudian diunduh dari situ, dan program cetak dibuat.

Di jalan untuk DO ada beberapa tugas lagi, selain yang sudah dia selesaikan. Ada tugas di seluruh perusahaan, tetapi ada tugas unik dan langka yang hanya dibutuhkan oleh unit tertentu. Penting untuk membantu mereka, dan karena itu, untuk memperluas "geografi" menggunakan sistem di dalam 1C - untuk memperluas ruang lingkup, menyelesaikan tugas-tugas semua departemen. Ini akan menjadi tes terbaik untuk kinerja dan keandalan. Saya ingin melihat sistem bekerja pada triliunan catatan, petabyte informasi.

Kami memeriksa diri kami sendiri: cara menyebarkan dan cara mengelola 1C: Alur dokumen dalam perusahaan 1C

?