À 1C, usemu largamente i nostri sviluppi per urganizà u travagliu di a cumpagnia. In particulare, . In più di a gestione di documenti (cum'è u nome suggerisce), hè ancu un mudernu -system (Enterprise Content Management - gestione di cuntenutu corporativu) cù una larga gamma di funziunalità - mail, calendarii di travagliu di l'impiegati, urganizazione di l'accessu cumunu à e risorse (per esempiu, riservazione di sale di riunioni), seguimentu di u tempu, foru corporativu è assai di più.
Più di mille impiegati utilizanu a gestione di documenti in 1C. A basa di dati hè digià diventata impressiunanti (11 billion records), chì significa chì hè bisognu di più cura è un equipamentu più putente.
Cume u nostru sistema funziona, quale difficultà scontru quandu mantene a basa di dati è cumu risolvemu (usemu MS SQL Server cum'è DBMS) - vi diceremu in l'articulu.
Per quelli chì leghjenu nantu à i prudutti 1C per a prima volta.
1C: Document Flow hè una soluzione d'applicazione (configurazione) implementata nantu à a basa di un framework per u sviluppu di applicazioni cummerciale - a piattaforma 1C:Enterprise.
"1C: Document Flow 8" (abbreviatu cum'è DO) permette di automatizà u travagliu cù documenti in una impresa. Unu di i principali strumenti per l'interazzione di l'impiegati hè l'email. In più di mail, DO risolve ancu altri prublemi:
- U seguimentu di u tempu
- Tracciamentu di l'assenza di l'impiegati
- Applicazioni per i corrieri / trasportu
- Calendari di travagliu di l'impiegati
- Registrazione di a currispundenza
- Cuntatti di l'impiegati (Libre di indirizzu)
- Forum corporativu
- Riserva di stanza
- A pianificazione di l'avvenimenti
- CRM
- U travagliu cullettivu cù i fugliali (cù salvate versioni di i schedari)
- è altri.
Entremu in Gestione di Documenti (applicazione eseguibile nativa) da Windows, Linux, macOS, (da i navigatori) è - secondu a situazione.
È grazia à u nostru altru pruduttu cunnessu à Document Flow - - Ricevemu direttamente in Document Flow a funziunalità di u messenger - chats, audio è video chjamate (cumprese e chjama di gruppu, chì hè diventata soprattuttu impurtante, cumpresu da un cliente mobile), scambiu di fugliali veloce più a capacità di scrive chat bots chì simplificà travaglià cù u sistema. Un altru vantaghju di l'usu di u Sistema di Interazione (in paragone à l'altri messageri) hè a capacità di cunduce discussioni cuntestuali ligati à l'uggetti specifichi di Document Flow - documenti, avvenimenti, etc. Vale à dì, u Sistema di Interazzione hè assai integrata cù l'applicazione di destinazione, è ùn agisce micca solu cum'è un "buttone separatu".
U numaru di lettere in u nostru DO hà digià superatu 100 milioni, è in generale ci sò più di 11 miliardi di record in u DBMS. In totale, u sistema usa quasi 30 TB di almacenamiento: u voluminu di a basa di dati hè 7,5 TB, i schedarii per u travagliu cullettivu sò guardati separatamente è occupanu un altru 21 TB.
Se parlemu di numeri più specifichi, quì hè u numeru di lettere è schedari in u mumentu:
- E-mail in uscita - 14,7 milioni.
- Lettere entrate - 85,4 milioni.
- Versioni di u schedariu - 70,8 milioni.
- Documenti internu - 30,6 mila.
DO hà più cà solu mail è schedari. Quì sottu sò i figuri per altri oggetti cuntabili:
- Riservazione di sale di riunioni - 52
- Rapporti settimanali - 153
- Rapporti di ghjornu - 628
- Visa di appruvazioni - 11
- Documenti entranti - 79
- Documenti in uscita - 28
- Entrate nantu à l'avvenimenti in i calendarii di travagliu di l'utilizatori - 168
- Applicazioni per i corrieri - 21
- Contrapartiti - 81
- Records di travagliu cù contrapartiti - 45
- Contact persons of counterparts - 41
- Avvenimenti - 10
- Prughjetti - 6
- I travaglii di l'impiegati - 245
- Posti di u forum - 26
- Missaghju di chat - 891 095
- Prucessi cummerciale - 109 L'interazzione trà l'impiegati si faci à traversu i prucessi - appruvazioni, esecuzione, rivisione, registrazione, firma, etc. Misuremu a durata di i prucessi, u numeru di ciculi, u numeru di participanti, u numeru di ritorni, u numeru di richieste per cambià i termini. E sta infurmazione hè assai utile per analizà per capiscenu quali prucessi sò in l'impresa è cresce l'efficienza di a cullaburazione di l'impiegati.
In quale equipamentu processemu tuttu questu?
Queste figuri indicanu un voluminu impressiunanti di travaglii, cusì avemu statu affruntatu cù a necessità di assignà un equipamentu abbastanza produttivu per i bisogni di i filiali interni. Attualmente, e so caratteristiche sò i seguenti: 38 core, 240 GB di RAM, 26 TB di discu. Eccu una tabella di servitori:
In u futuru, pensemu à aumentà a capacità di l'equipaggiu.
Cumu andanu e cose cù a carica di u servitore?
L'attività di a rete ùn hè mai statu un prublema per noi o i nostri clienti. Comu regula, u puntu debule hè u processatore è i dischi, perchè ognunu sapi digià cumu trattà cù una mancanza di memoria. Eccu screenshots di i nostri servitori da Resource Monitor, chì mostranu chì ùn avemu micca una carica terribile, hè assai modesta.
Per esempiu, in a screenshot sottu vedemu un servitore SQL induve a carica di CPU hè 23%. È questu hè un indicatore assai bonu (per paragunà: se a carica si avvicina à u 70%, allora, assai prubabilmente, l'impiegati observeranu rallentamenti abbastanza significativi in u travagliu).
A seconda screenshot mostra u servitore di l'applicazioni nantu à quale a piattaforma 1C:Enterprise funziona - serve solu sessioni d'utilizatori. Quì a carica di u processatore hè un pocu più altu - 38%, hè liscia è calma. Ci hè una carica di discu, ma hè accettabile.
A terza screenshot mostra un altru 1C: Server Enterprise (hè u sicondu, avemu dui di elli in u cluster). Solu u precedente serve à l'utilizatori, è i robots travaglianu nantu à questu. Per esempiu, ricevenu mail, documenti di rotta, scambià dati, calculà diritti, etc. Tutte queste attività di fondo facenu circa 90-100 travaglii di fondo. È stu servitore hè assai pesante - 88%. Ma questu ùn affetta micca e persone, è implementa esattamente tutta l'automatizazione chì a Gestione Documentale deve fà.
Chì sò e metriche per misurà u rendiment?
Avemu un sottosistema seriu integratu in e nostre filiali per a misurazione di l'indicatori di rendiment è u calculu di diverse metriche. Questu hè necessariu per capiscenu sia in u mumentu attuale in u tempu sia da una perspettiva storica ciò chì succede in u sistema, ciò chì s'aggrava, ciò chì hè megliu. Strumenti di monitoraghju - metriche è misurazioni di u tempu - sò inclusi in a consegna standard di "1C: Document Flow 8". I metrici necessitanu persunalizazione durante l'implementazione, ma u mecanismu stessu hè standard.
I metrici sò misurazioni di diversi indicatori cummerciale in certi punti di u tempu (per esempiu, u tempu mediu di consegna di mail hè di 10 minuti).
Una di e metriche mostra u numeru di utilizatori attivi in a basa di dati. In media, ci sò 1000-1400 di elli durante u ghjornu. U graficu mostra chì à u mumentu di a screenshot ci eranu 2144 utilizatori attivi in a basa di dati.
Ci hè più di 30 tali azzioni, a lista hè sottu u cut.a lista
- Login
- Sorte
- Carica di mail
- Cambia a validità di un oggettu
- Cambia i diritti d'accessu
- Cambia u sughjettu di un prucessu
- Cambia u gruppu di travagliu di l'ughjettu
- Cambia a cumpusizioni di u kit
- Cambia un schedariu
- Importazione di u schedariu
- Mandatu per mail
- Sposta i schedari
- Redirecting un compitu
- Firmà a firma elettronica
- Ricerca per dettagli
- Ricerca di testu cumpletu
- Riceve un schedariu
- Interrupting un prucessu
- Vede
- Decryption
- Registrazione di u documentu
- Scansione
- Eliminazione di marcatura
- Crià un ughjettu
- Salvà à u discu
- U principiu di u prucessu
- Eliminazione di e voci di log di l'utilizatori
- Eliminazione di una firma elettronica
- Impostazione di una marca di eliminazione
- Encryption
- Esporta un cartulare
A settimana prima di l'ultima, a nostra attività media di l'utilizatori hà aumentatu da una volta è mezu (mostra in rossu nantu à u graficu) - questu hè duvuta à a transizione di a maiò parte di l'impiegati à u travagliu remoto (per via di avvenimenti ben cunnisciuti). Inoltre, u nùmeru di l'utilizatori attivi anu aumentatu da 3 volte (mostratu in blu nantu à a screenshot), cum'è l'impiegati cuminciaru à utilizà attivamente i telefunini mobili: ogni cliente mobile crea una cunnessione à u servitore. Avà, in media, ognunu di i nostri impiegati hà 2 cunnessione à u servitore.
Per noi, cum'è amministratori, questu hè un signalu chì avemu da esse più attenti à i prublemi di rendiment è vede s'ellu e cose sò peghju. Ma guardemu questu basatu annantu à altri parametri. Per esempiu, cumu cambia u tempu di spedizione di mail per u routing internu (mostratu in blu in a screenshot sottu). Avemu vistu chì finu à questu annu era fluttuante, ma avà hè stabile - per noi questu hè un indicatore chì tuttu hè in ordine cù u sistema.
Un'altra metrica applicata per noi hè u tempu d'attesa mediu per scaricà e lettere da u servitore di mail (mostratu in rossu in a screenshot). À pocu pressu, quantu tempu a lettera flottarà in Internet prima ch'ella ghjunghje à u nostru impiegatu. A screenshot mostra chì sta volta ùn hè micca cambiatu in ogni modu recentemente. Ci sò spikes isolati - ma ùn sò micca assuciati cù ritardi, ma cù u fattu chì u tempu nantu à i servitori di mail hè persu.
O, per esempiu, una altra metrica (mostra in blu in a screenshot) - aghjurnà lettere in un cartulare. Apertura di un cartulare di mail hè una operazione assai cumuna è deve esse fatta rapidamente. Misuremu quantu rapidamente hè realizatu. Stu indicatore hè misuratu per ogni cliente. Pudete vede sia a stampa generale per a cumpagnia è a dinamica, per esempiu, per un impiigatu individuale. A screenshot mostra chì finu à questu annu a metrica era sbilanciata, allora avemu fattu una quantità di migliure, è avà ùn hè micca peghju - u graficu hè quasi pianu.
A metrica sò basamente un strumentu di amministratore per u monitoraghju di u sistema, per risponde rapidamente à qualsiasi cambiamenti in u cumpurtamentu di u sistema. A screenshot mostra metrica subsidiaria interna per l'annu. U saltu in i gràfiche hè duvuta à u fattu chì ci sò stati dati compiti per sviluppà filiali internu.
Eccu una lista di qualchi metrica più (sottu u cut).
Metriche
- Attività di l'utilizatori
- Utenti attivi
- I prucessi attivi
- U numeru di schedari
- Taille du fichier (MB)
- Numero di documenti
- Numaru d'oggetti da esse mandati à i destinatari
- Numaru di contrapartiti
- I travaglii micca finiti
- Tempu mediu d'attesa per scaricà e-mail da u servitore di mail in l'ultimi 10 minuti
- Buffer di dati esterni: numeru di schedari
- Lagging frontiere da a data attuale
- Longa fila
- Fila operativa
- Raw account età per routing esternu
- Dimensione di a fila di accettazione di u routing internu (coda longa)
- Dimensione di a fila di accettazione di u routing internu (coda rapida)
- Tempu di consegna di mail via routing internu (longa fila)
- Tempu di consegna di mail via routing internu (coda rapida)
- Tempu di consegna di mail via routing esternu (media)
- Numero di ducumenti Riservazione
- Numero di ducumenti Assenza
- Numaru di documenti "Registru di u travagliu cù a contraparte"
- Mail Update lettere in un cartulare
- Mail Apertura di una carta di lettera
- Mail Trasferite una lettera à un cartulare
- Mail Navigate attraversu i cartulare
U nostru sistema misura più di 150 indicatori intornu à u clock, ma micca tutti ponu esse monitorati rapidamente. Puderanu esse utile dopu, in una perspettiva storica, è pudete fucalizza nantu à i più impurtanti per l'affari.
In una di l'implementazioni, per esempiu, solu 5 indicatori sò stati scelti. U cliente hà stabilitu un scopu di creà un settore minimu di indicatori, ma à u stessu tempu cusì chì copre i principali scenarii di travagliu. Saria micca ghjustificatu per include 150 indicatori in u certificatu di accettazione, perchè ancu in l'impresa hè difficiule d'accordu nantu à quale indicatori sò cunsiderati accettabili. E sapianu di sti indicatori 5 è avianu digià presentatu à u sistema prima di l'iniziu di u prugettu di implementazione, cumpresu in a documentazione di a cumpetizione: tempu per apre una carta micca più di 3 seconde, tempu per compie un compitu cù un schedariu micca. più di 5 seconde, etc. In i nostri filiali avemu avutu metriche chì riflettenu chjaramente a dumanda originale da e specificazioni tecniche di u cliente.
Avemu ancu un analisi di prufilu di e misurazioni di u rendiment. L'indicatori di rendiment sò una registrazione di a durata di ogni operazione in corso (scrittura una lettera à a basa di dati, mandà una lettera à un servitore di mail, etc.). Questu hè adupratu solu da i tecnichi. Accumulemu assai indicatori di rendiment in u nostru prugramma. Attualmente misuramu circa 1500 operazioni chjave, chì sò divisi in profili.
Unu di i profili più impurtanti per noi hè a "Lista d'Indicatori Chjave di Mail da una Perspettiva di u Consumatore". Stu prufilu include, per esempiu, i seguenti indicatori:
- Esecuzione di u cumandamentu: Selezziunate per tag
- Apertura di una forma: Forma di lista
- Esecuzione di u cumandamentu: Selezziunate per cartulare
- Mostra una lettera in l'area di lettura
- Salvà una lettera in u vostru cartulare preferitu
- Ricerca di lettere per dettagli
- Crià una lettera
Se vedemu chì a metrica per qualchì indicatore cummerciale hè diventatu troppu grande (per esempiu, e lettere da un utilizatore particulare anu cuminciatu à ghjunghje per un tempu assai longu), cuminciamu à calculà è vultà à a misurazione di u tempu di l'operazioni tecniche. Avemu una operazione tecnica "Archive lettere in un servitore di mail" - vedemu chì u tempu per sta operazione hè stata superata per l'ultimu periodu. Questa operazione, à u turnu, hè decomposta in altre operazioni - per esempiu, stabilisce una cunnessione cù un servitore di mail. Avemu vistu chì per una certa ragione hè diventatu subitu assai grande (avemu tutte e misurazioni per un mesi - pudemu paragunà chì a settimana passata era 10 millisecondi, è avà hè 1000 milliseconds). È capimu chì qualcosa hè rottu quì - avemu bisognu di riparà.
Cumu mantene una basa di dati cusì grande?
U nostru DO internu hè un esempiu di un prughjettu di alta carica veramente chì travaglia. Parlemu di e caratteristiche tecniche di a so basa di dati.
Quantu tempu ci vole à ristrutturare e grandi tabelle di basa di dati?
U servitore SQL hà bisognu di mantenimentu periodicu, mettendu e tavule in ordine. In una bona manera, questu deve esse fattu almenu una volta à ghjornu, è ancu più spessu per i tavulini d'alta dumanda. Ma s'è a basa di dati hè grande (è u nostru nùmeru di registri hà digià superatu 11 miliardi), allora a cura di questu ùn hè micca faciule.
Avemu fattu una ristrutturazione di a tavula 6 anni fà, ma poi hà cuminciatu à piglià tantu tempu chì ùn avemu micca più in l'intervalli di notte. E postu chì queste operazioni caricanu assai u servitore SQL, ùn pò micca serve in modu efficiente à l'altri utilizatori.
Dunque, avà avemu da aduprà diversi trucchi. Per esempiu, ùn pudemu micca fà queste prucedure nantu à setti di dati cumpleti. Avete da ricurdà à a prucedura Update Sample 500000 fila - questu dura 14 minuti. Ùn aghjurnà micca e statistiche nantu à tutte e dati in a tavula, ma selezziunate a mità di milione di fila è l'utilizanu per calculà statistiche chì usa per tutta a tavola. Questa hè una certa supposizione, ma simu furzati à fà, perchè per un tavulu specificu, a cullizzioni di statistiche nantu à l'interu billion records duverà un tempu inaccettabilmente longu.
Avemu ancu ottimizatu altre operazioni di mantenimentu rendenduli parziali.
Mantene un DBMS hè generalmente un compitu difficiule. In u casu di interazzione attiva trà l'impiegati, a basa di dati cresce rapidamente, è diventa sempre più difficiuli per l'amministratori di mantene - aghjurnà statistiche, defragmentazione, indexazione. Quì avemu bisognu di applicà diverse strategie, sapemu bè cumu fà questu, avemu sperienza, pudemu sparte.
Cumu hè implementatu a copia di salvezza cù tali volumi?
Una copia di salvezza completa di DBMS hè realizata una volta à ghjornu à a notte, una incrementale - ogni ora. Inoltre, un repertoriu di schedari hè creatu ogni ghjornu, è hè una parte di a copia di salvezza incrementale di l'almacenamiento di u schedariu.
Quantu tempu ci vole à compie una copia di salvezza completa?
Una copia di salvezza completa à un discu duru hè cumpletata in trè ore, una copia di salvezza parziale in una ora. Ci hè più tempu per scrive à a cinta (un dispositivu speciale chì face una copia di salvezza in un cassette speciale guardatu fora di l'uffiziu; una copia trasferibile hè fatta à a cinta, chì serà cunservata se, per esempiu, a sala di u servitore brusgia). A copia di salvezza hè fatta in u stessu servitore, i paràmetri di quale eranu più altu - un servitore SQL cù 20% di carica di processore. À u mumentu di a copia di salvezza, sicuru, u sistema diventa assai peggiu, ma hè sempre funziunale.
Ci hè a deduplicazione?
Ci sò schedari, avemu da pruvà nantu à noi stessi, è prestu sarà inclusu in a nova versione di Document Management. Testemu ancu u mecanismu di deduplicazione di a contraparte. Ùn ci hè micca deduplicazione di registri à u livellu DBMS, postu chì questu ùn hè micca necessariu. A piattaforma 1C:Enterprise guarda l'ogetti in u DBMS, è solu a piattaforma pò esse rispunsevuli di a so cunsistenza.
Ci sò nodi di sola lettura?
Ùn ci sò micca nodi di lettura (nodi di sistema dedicati chì serve à quelli chì anu bisognu di riceve dati per leghje). DO ùn hè micca un sistema di cuntabilità per mette in un node BI separatu, ma ci hè un node separatu per u dipartimentu di sviluppu, cù quale i missaghji sò scambiati in formatu JSON, è u tempu di replicazione tipica hè unità è decine di seconde. U node hè sempre chjucu, hà circa 800 milioni di dischi, ma cresce rapidamente.
E-mail marcati per a cancellazione ùn sò micca eliminati in tuttu?
Ancu micca. Ùn avemu micca u compitu di fà a basa più ligera. Ci era parechji casi serii quandu era necessariu di riferite à e lettere marcate per a cancellazione, cumpresu 2009. Hè per quessa chì avemu decisu di mantene tuttu per avà. Ma quandu u costu di questu diventa micca ghjustificatu, penseremu à a rimuzione. Ma, s'ellu ci vole à sguassà una lettera separata da a basa di dati cumplitamenti cusì chì ùn ci hè micca traccia, allura si pò esse fattu da dumanda spiciali.
Perchè guardà? Avete statistiche nantu à l'accessu à i vechji documenti ?
Ùn ci hè micca statistiche. Più precisamente, hè in forma di logu d'utilizatore, ma ùn hè micca guardatu per longu. L'entrata di più di un annu sò sguassate da u protocolu.
Ci era situazione quandu era necessariu di ricuperà a currispundenza antica da cinque o ancu deci anni fà. È questu hè sempre fattu micca per una curiosità inattiva, ma per piglià decisioni cummerciale cumplessu. Ci era un casu induve, senza storia di currispundenza, una decisione cummerciale sbagliata saria stata fatta.
Cumu hè u valore di i ducumenti valutatu è distruttu secondu i periodi di almacenamento?
Per i documenti di carta, questu hè fattu in u modu tradiziunale di solitu, cum'è tutti l'altri. Ùn facemu micca per l'elettronica - lasciate li tene per elli stessi. U postu hè quì. Ci sò benefici. Tutti sò bè.
Chì prospettive di sviluppu ci sò?
Avà u nostru DO risolve circa 30 prublemi internu, alcuni di i quali avemu listatu à u principiu di l'articulu. U DL hè ancu usatu per preparà cunferenze chì avemu tenutu duie volte à l'annu per i nostri partenarii: u prugramma tutale, tutti i rapporti, tutte e sezioni parallele, sale - tuttu questu hè scrittu in u DL, è dopu scaricatu da ellu, è un prugramma stampatu. hè fattu.
Ci sò parechje altre attività nantu à a strada per u DO, in più di quelli chì hè digià risolve. Ci sò compiti in tutta a cumpagnia, è ci sò unichi è rari, necessariu solu da un dipartimentu specificu. Hè necessariu aiutà, chì significa espansione a "geografia" di l'usu di u sistema in 1C - espansione u scopu di l'applicazione, risolve i prublemi di tutti i dipartimenti. Questu seria u megliu test per u rendiment è l'affidabilità. Mi piacerebbe vede u sistema travaglià nantu à trilioni di registri, petabytes d'infurmazioni.
Source: www.habr.com