Ĉe 1C, ni vaste uzas niajn proprajn evoluojn por organizi la laboron de la kompanio. Precipe, . Krom dokumenta administrado (kiel la nomo sugestas), ĝi ankaŭ estas moderna -sistemo (Enterprise Content Management - kompania enhavadministrado) kun ampleksa gamo de funkcioj - poŝto, dungitaj laborkalendaroj, organizado de komuna aliro al rimedoj (ekzemple, rezervado de kunvenejoj), tempospurado, kompania forumo kaj multe pli.
Pli ol mil dungitoj uzas dokumentan administradon ĉe 1C. La datumbazo jam fariĝis impona (11 miliardoj da rekordoj), kio signifas, ke ĝi postulas pli zorgan prizorgon kaj pli potencajn ekipaĵojn.
Kiel nia sistemo funkcias, kiajn malfacilaĵojn ni renkontas dum konservado de la datumbazo kaj kiel ni solvas ilin (ni uzas MS SQL Server kiel DBMS) - ni rakontos al vi en la artikolo.
Por tiuj, kiuj legas pri 1C-produktoj unuafoje.
1C:Document Flow estas aplika solvo (agordo) efektivigita surbaze de kadro por disvolvi komercajn aplikaĵojn - la platformo 1C:Enterprise.
"1C: Document Flow 8" (mallongigita kiel DO) permesas vin aŭtomatigi laboron kun dokumentoj en entrepreno. Unu el la ĉefaj iloj por dungita interago estas retpoŝto. Krom poŝto, DO ankaŭ solvas aliajn problemojn:
- Tempo spurado
- Spurado de foresto de dungitoj
- Aplikoj por kurieroj/transporto
- Laborkalendaroj de dungitoj
- Registrado de korespondado
- Kontaktoj de dungitoj (Adreslibro)
- Korporacia forumo
- Rezervado de ĉambro
- Eventplanado
- CRM
- Kolektiva laboro kun dosieroj (kun konservado de dosierversioj)
- kaj aliaj.
Ni eniras Dokumentan Administradon (denaska rulebla aplikaĵo) de Vindozo, Linukso, macOS, (de retumiloj) kaj - depende de la situacio.
Kaj danke al nia alia produkto ligita al Document Flow - - ni rekte en Document Flow ricevas la funkciecon de la mesaĝisto - babiloj, aŭdaj kaj videovokoj (inkluzive de grupvokoj, kiuj nun fariĝis speciale grava, inkluzive de poŝtelefona kliento), rapida dosierŝanĝo plus la kapablo skribi babilajn robotojn kiuj simpligas laborante kun la sistemo. Alia avantaĝo de uzado de la Interaga Sistemo (kompare kun aliaj mesaĝistoj) estas la kapablo fari kontekstajn diskutojn ligitajn al specifaj Document Flow-objektoj - dokumentoj, okazaĵoj, ktp. Tio estas, la Interaga Sistemo estas profunde integrita kun la cela aplikaĵo, kaj ne funkcias kiel nur "aparta butono".
La nombro da literoj en nia DO jam superis 100 milionojn, kaj ĝenerale estas pli ol 11 miliardoj da registroj en la DBMS. Entute, la sistemo uzas preskaŭ 30 TB da stokado: la datumbaza volumo estas 7,5 TB, dosieroj por kolektiva laboro estas konservitaj aparte kaj okupas pliajn 21 TB.
Se ni parolas pri pli specifaj nombroj, jen la nombro da literoj kaj dosieroj nuntempe:
- Elirantaj retpoŝtoj - 14,7 milionoj.
- Alvenantaj leteroj - 85,4 milionoj.
- Dosierversioj - 70,8 milionoj.
- Internaj dokumentoj - 30,6 mil.
DO havas pli ol nur poŝton kaj dosierojn. Malsupre estas la ciferoj por aliaj kontadaj objektoj:
- Rezervaj kunvenejoj – 52
- Semajnaj raportoj - 153
- Ĉiutagaj raportoj - 628
- Aprobaj vizoj - 11
- Alvenantaj dokumentoj - 79
- Elirantaj dokumentoj – 28
- Enskriboj pri eventoj en uzantlaboraj kalendaroj - 168
- Aplikoj por kurieroj - 21
- Kontraŭpartioj – 81
- Registroj de laboro kun kontraŭpartioj - 45
- Kontaktpersonoj de kontraŭpartioj - 41
- Okazaĵoj – 10
- Projektoj - 6
- Taskoj de dungitoj - 245
- Forumaj afiŝoj - 26
- Babilmesaĝoj - 891 095
- Komercaj procezoj - 109 056. Interago inter dungitoj okazas per procezoj - aprobo, ekzekuto, revizio, registrado, subskribo ktp. Ni mezuras la daŭron de procezoj, la nombron da cikloj, la nombron da partoprenantoj, la nombron da revenoj, la nombron da petoj por ŝanĝi limdatojn. Kaj ĉi tiu informo estas tre utila analizi por kompreni, kiaj procezoj okazas en la entrepreno kaj pliigi la efikecon de kunlaborado de dungitoj.
Sur kiu ekipaĵo ni prilaboras ĉion ĉi?
Ĉi tiuj ciferoj indikas imponan volumon de taskoj, do ni alfrontis la bezonon asigni sufiĉe produktivan ekipaĵon por la bezonoj de internaj filioj. Nuntempe, ĝiaj karakterizaĵoj estas kiel sekvas: 38 kernoj, 240 GB da RAM, 26 TB da diskoj. Jen tabelo de serviloj:
En la estonteco, ni planas pliigi la kapablon de la ekipaĵo.
Kiel iras aferoj kun la servila ŝarĝo?
Reta agado neniam estis problemo por ni aŭ niaj klientoj. Ĝenerale, la malforta punkto estas la procesoro kaj diskoj, ĉar ĉiuj jam scias kiel trakti mankon de memoro. Jen ekrankopioj de niaj serviloj de Resource Monitor, kiuj montras, ke ni ne havas teruran ŝarĝon, ĝi estas tre modesta.
Ekzemple, en la ekrankopio malsupre ni vidas SQL-servilon kie la CPU-ŝarĝo estas 23%. Kaj ĉi tio estas tre bona indikilo (por komparo: se la ŝarĝo alproksimiĝas al 70%, tiam, plej verŝajne, dungitoj observos sufiĉe gravajn malrapidiĝojn en laboro).
La dua ekrankopio montras la aplikaĵservilon sur kiu funkcias la platformo 1C:Enterprise - ĝi nur servas uzantajn sesiojn. Ĉi tie la procesoro-ŝarĝo estas iomete pli alta - 38%, ĝi estas glata kaj trankvila. Estas iom da disko-ŝarĝado, sed ĝi estas akceptebla.
La tria ekrankopio montras alian 1C:Enterprise-servilon (ĝi estas la dua, ni havas du el ili en la areto). Nur la antaŭa servas uzantojn, kaj robotoj laboras sur ĉi tiu. Ekzemple, ili ricevas poŝton, vojdokumentojn, interŝanĝas datumojn, kalkulas rajtojn ktp. Ĉiuj ĉi tiuj fonaj agadoj plenumas proksimume 90-100 fonajn laborojn. Kaj ĉi tiu servilo estas tre forte ŝarĝita - 88%. Sed ĉi tio ne influas homojn, kaj ĝi efektivigas ĝuste la tutan aŭtomatigon, kiun Dokumenta Administrado devus fari.
Kio estas la metrikoj por mezuri rendimenton?
Ni havas seriozan subsistemon konstruitan en niajn filiojn por mezuri rendimentajn indikilojn kaj kalkuli diversajn metrikojn. Tio estas necesa por kompreni kaj en la nuna momento kaj el historia perspektivo, kio okazas en la sistemo, kio plimalboniĝas, kio pliboniĝas. Monitoraj iloj - metrikoj kaj tempomezuradoj - estas inkluditaj en la norma livero de "1C: Document Flow 8". La metrikoj postulas personigon dum efektivigo, sed la mekanismo mem estas norma.
Metrikoj estas mezuradoj de diversaj komercaj indikiloj en certaj punktoj en tempo (ekzemple, la meza poŝta livertempo estas 10 minutoj).
Unu el la metrikoj montras la nombron da aktivaj uzantoj en la datumbazo. Averaĝe estas 1000-1400 da ili dumtage. La grafikaĵo montras, ke en la momento de la ekrankopio estis 2144 aktivaj uzantoj en la datumbazo.
Estas pli ol 30 tiaj agoj, la listo estas sub la tranĉo.Listo de
- Ensaluti al la sistemo
- Elsaluti
- Ŝarĝante poŝton
- Ŝanĝi la validecon de objekto
- Ŝanĝante alirrajtojn
- Ŝanĝi la temon de procezo
- Ŝanĝi la laborgrupon de objekto
- Ŝanĝi la komponadon de la ilaro
- Ŝanĝante dosieron
- Dosiera importo
- Sendado per poŝto
- Movante dosierojn
- Redirekti taskon
- Subskribante la elektronikan subskribon
- Serĉu laŭ detaloj
- Plenteksta serĉo
- Ricevante dosieron
- Interrompante procezon
- revizio
- Malĉifrado
- Dokumenta registrado
- Skani
- Malmarka forigo
- Kreante Objekton
- Konservado al disko
- Komenco de la procezo
- Forigante uzantregistrajn enskribojn
- Forigo de elektronika subskribo
- Agordi forigmarkon
- Ĉifrado
- Eksportu dosierujon
La antaŭan semajnon, nia averaĝa uzant-agado pliiĝis unufoje kaj duono (montrita ruĝe sur la grafikaĵo) - tio estas pro la transiro de la plej multaj dungitoj al fora laboro (pro konataj eventoj). Ankaŭ, la nombro de aktivaj uzantoj pliiĝis je 3 fojojn (montrita blue sur la ekrankopio), ĉar dungitoj komencis aktive uzi poŝtelefonojn: ĉiu movebla kliento kreas konekton al la servilo. Nun, averaĝe, ĉiu el niaj dungitoj havas 2 konektojn al la servilo.
Por ni, kiel administrantoj, ĉi tio estas signalo, ke ni devas esti pli atentaj pri rendimentaj problemoj kaj vidi ĉu aferoj plimalboniĝis. Sed ni rigardas ĉi tion surbaze de aliaj parametroj. Ekzemple, kiel ŝanĝiĝas la poŝta livertempo por interna vojigo (montrita blue en la ekrankopio malsupre). Ni vidas, ke ĝi fluktis ĝis ĉi tiu jaro, sed nun ĝi estas stabila - por ni ĉi tio estas indikilo, ke ĉio estas en ordo kun la sistemo.
Alia aplikata metriko por ni estas la averaĝa atenda tempo por elŝuti leterojn de la poŝtservilo (montrita ruĝe en la ekrankopio). Proksimume, kiom longe la letero flosiĝos ĉirkaŭ la Interreto antaŭ ol ĝi atingos nian dungiton. La ekrankopio montras, ke ĉi tiu tempo ankaŭ ne ŝanĝiĝis lastatempe. Estas izolitaj pikiloj - sed ili ne rilatas al prokrastoj, sed al tio, ke la tempo perdiĝas ĉe la poŝtserviloj.
Aŭ, ekzemple, alia metriko (montrita blue en la ekrankopio) - ĝisdatigi literojn en dosierujo. Malfermi poŝtan dosierujon estas tre ofta operacio kaj devas esti farita rapide. Ni mezuras kiom rapide ĝi estas farita. Ĉi tiu indikilo estas mezurita por ĉiu kliento. Vi povas vidi kaj la ĝeneralan bildon por la firmao kaj la dinamikon, ekzemple, por individua dungito. La ekrankopio montras, ke ĝis ĉi tiu jaro la metriko estis malekvilibra, tiam ni faris kelkajn plibonigojn, kaj nun ĝi ne plimalboniĝas - la grafikaĵo estas preskaŭ plata.
Metriko estas esence ilo de administranto por monitori la sistemon, por rapide respondi al ajnaj ŝanĝoj en la konduto de la sistemo. La ekrankopio montras internajn filajn metrikojn por la jaro. La salto en la grafikaĵoj estas pro tio, ke ni ricevis taskojn por disvolvi internajn filiojn.
Jen listo de kelkaj pliaj metrikoj (sub la tranĉo).
Metriko
- Uzantagado
- Aktivaj Uzantoj
- Aktivaj procezoj
- Nombro de dosieroj
- Dosiera grandeco (MB)
- Nombro de dokumentoj
- Nombro de objektoj sendotaj al ricevantoj
- Nombro de kontraŭpartioj
- Nefinitaj taskoj
- Meza atenda tempo por elŝuti retpoŝtojn de la poŝtservilo dum la lastaj 10 minutoj
- Ekstera datuma bufro: nombro da dosieroj
- Malfrua limo de la nuna dato
- Longa vico
- Funkcia atendovico
- Kruda konta aĝo per ekstera vojigo
- Interna envojiga akcepta atendovicgrando (longa atendovico)
- Interna envojiga akcepta atendovicgrando (rapida atendovico)
- Poŝtlivera tempo per interna vojigo (longa vico)
- Poŝtlivera tempo per interna vojigo (rapida atendovico)
- Poŝta livertempo per ekstera vojigo (mezumo)
- Nombro de dokumentoj Rezervado
- Nombro de dokumentoj Foresto
- Nombro de dokumentoj "Registro de laboro kun kontraŭpartio"
- Poŝto Ĝisdatigu leterojn en dosierujo
- Poŝto Malfermante leterkarton
- Poŝto Transdonu leteron al dosierujo
- Poŝto Movu tra dosierujoj
Nia sistemo mezuras pli ol 150 indikilojn ĉirkaŭ la horloĝo, sed ne ĉiuj povas esti rapide monitoritaj. Ili povas esti utilaj poste, en iu historia perspektivo, kaj vi povas koncentriĝi sur la plej gravaj por la komerco.
En unu el la efektivigoj, ekzemple, nur 5 indikiloj estis elektitaj. La kliento starigis celon krei minimuman aron da indikiloj, sed samtempe tia ke ĝi kovris la ĉefajn laborscenarojn. Estus nepravigite inkluzivi 150 indikilojn en la akceptatestilo, ĉar eĉ ene de la entrepreno estas malfacile konsenti pri kiuj indikiloj estas konsiderataj akcepteblaj. Kaj ili sciis pri ĉi tiuj 5 indikiloj kaj jam prezentis ilin al la sistemo antaŭ la komenco de la efektiviga projekto, inkluzive de ili en la dokumentado de la konkuro: tempo por malfermi karton ne pli ol 3 sekundojn, tempo por plenumi taskon kun dosiero ne. pli ol 5 sekundoj, ktp. En niaj filioj ni havis metrikojn, kiuj tre klare reflektis la originan peton de la teknikaj specifoj de la kliento.
Ni ankaŭ havas profilan analizon de agado-mezuradoj. Efikecindikiloj estas registrado de la daŭro de ĉiu daŭra operacio (skribi leteron al la datumbazo, sendi leteron al poŝtservilo, ktp.). Ĉi tio estas uzata ekskluzive de teknikistoj. Ni amasigas multajn rendimentajn indikilojn en nia programo. Nuntempe ni mezuras proksimume 1500 XNUMX ŝlosilajn operaciojn, kiuj estas dividitaj en profilojn.
Unu el la plej gravaj profiloj por ni estas la "Listo de Ŝlosilaj Indikiloj de Poŝto laŭ Konsumanto-Perspektivo." Ĉi tiu profilo inkluzivas, ekzemple, la jenajn indikilojn:
- Plenumante la komandon: Elektu per etikedo
- Malfermo de formularo: Listo Formo
- Plenumante la komandon: Elektu per dosierujo
- Montrante leteron en la legado
- Konservante leteron en via plej ŝatata dosierujo
- Serĉu literojn laŭ detaloj
- Kreante leteron
Se ni vidas, ke la metriko por iu komerca indikilo fariĝis tro granda (ekzemple, leteroj de aparta uzanto komencis alveni de tre longa tempo), ni komencas eltrovi ĝin kaj turni sin al mezuri la tempon de teknikaj operacioj. Ni havas teknikan operacion "Arkivado de leteroj sur poŝtservilo" - ni vidas, ke la tempo por ĉi tiu operacio estis superita por la lasta periodo. Ĉi tiu operacio, siavice, estas malkomponita en aliajn operaciojn - ekzemple, establi konekton kun poŝtservilo. Ni vidas, ke ial ĝi subite fariĝis tre granda (ni havas ĉiujn mezurojn por monato - ni povas kompari tion pasintsemajne ĝi estis 10 milisekundoj, kaj nun ĝi estas 1000 milisekundoj). Kaj ni komprenas, ke io estas rompita ĉi tie - ni devas ripari ĝin.
Kiel ni konservas tian grandan datumbazon?
Nia interna DO estas ekzemplo de vere funkcianta altŝarĝa projekto. Ni parolu pri la teknikaj trajtoj de ĝia datumbazo.
Kiom da tempo necesas por restrukturi grandajn datumbazajn tabelojn?
La SQL-servilo postulas periodan prizorgadon, ordigante la tabelojn. En bona maniero, ĉi tio devus esti farita almenaŭ unufoje tage, kaj eĉ pli ofte por altpostulaj tabloj. Sed se la datumbazo estas granda (kaj nia nombro da registroj jam superis 11 miliardojn), tiam prizorgi ĝin ne estas facila.
Ni faris tablorestrukturadon antaŭ 6 jaroj, sed tiam ĝi komencis daŭri tiom da tempo, ke ni ne plu taŭgas en la noktajn intervalojn. Kaj ĉar ĉi tiuj operacioj peze ŝarĝas la SQL-servilon, ĝi ne povas efike servi aliajn uzantojn.
Tial, nun ni devas uzi diversajn lertaĵojn. Ekzemple, ni ne povas plenumi ĉi tiujn procedurojn sur kompletaj datenoj. Vi devas recurri al la proceduro de Ĝisdatiga Specimeno 500000 vicoj - ĉi tio daŭras 14 minutojn. Ĝi ne ĝisdatigas statistikojn pri ĉiuj datumoj en la tabelo, sed elektas duonmilionon da vicoj kaj uzas ilin por kalkuli statistikojn, kiujn ĝi uzas por la tuta tabelo. Ĉi tio estas ia supozo, sed ni estas devigitaj fari ĝin, ĉar por specifa tabelo, kolekti statistikojn pri la tuta miliardo da registroj daŭros neakcepteble longan tempon.
Ni ankaŭ optimumigis aliajn prizorgajn operaciojn farante ilin partaj.
Prizorgi DBMS estas ĝenerale kompleksa tasko. En la kazo de aktiva interago inter dungitoj, la datumbazo kreskas rapide, kaj fariĝas ĉiam pli malfacile por administrantoj konservi ĝin - ĝisdatigi statistikojn, malfragmentadon, indeksadon. Ĉi tie ni devas apliki malsamajn strategiojn, ni bone scias kiel fari tion, ni havas sperton, ni povas dividi ĝin.
Kiel estas efektivigita sekurkopio kun tiaj volumoj?
Plena DBMS-rezervo estas farita unufoje tage nokte, pliiga - ĉiun horon. Ankaŭ, dosiero dosierujo estas kreita ĉiutage, kaj ĝi estas parto de la pliiga sekurkopio de la dosierstokado.
Kiom da tempo necesas por kompletigi plenan sekurkopion?
Plena sekurkopio al malmola disko finiĝas en tri horoj, parta sekurkopio en horo. Daŭras pli longe por skribi al sonbendo (speciala aparato kiu faras kopion de sekureco al speciala kasedo stokita ekster la oficejo; transdonebla kopio estas farita al la bendo, kiu estos konservita se, ekzemple, la servilĉambro forbrulos). La sekurkopio estas farita sur ĝuste la sama servilo, kies parametroj estis pli altaj - SQL-servilo kun 20%-procesora ŝarĝo. En la momento de sekurkopio, kompreneble, la sistemo fariĝas multe pli malbona, sed ĝi ankoraŭ funkcias.
Ĉu estas dedupliko?
Estas dosieroj, ni testos ĝin sur ni mem, kaj baldaŭ ĝi estos inkluzivita en la nova versio de Dokumentadministrado. Ni ankaŭ provas la kontraŭpartian deduplikadan mekanismon. Ne estas deduplikado de rekordoj ĉe la DBMS-nivelo, ĉar tio ne estas necesa. La platformo 1C:Enterprise stokas objektojn en la DBMS, kaj nur la platformo povas respondeci pri ilia konsistenco.
Ĉu ekzistas nurlegeblaj nodoj?
Ne ekzistas legaj nodoj (diligentaj sistemaj nodoj, kiuj servas tiujn, kiuj bezonas ricevi ajnajn datumojn por legado). DO ne estas kontada sistemo por surmeti apartan BI-nodon, sed ekzistas aparta nodo por la evolufako, kun kiu mesaĝoj estas interŝanĝitaj en JSON-formato, kaj la tipa replika tempo estas unuoj kaj dekoj da sekundoj. La nodo estas ankoraŭ malgranda, ĝi havas ĉirkaŭ 800 milionojn da registroj, sed ĝi kreskas rapide.
Ĉu retpoŝtoj markitaj por forigo tute ne estas forigitaj?
Ankoraŭ ne. Ni ne havas la taskon fari la bazon pli malpeza. Ekzistis pluraj sufiĉe gravaj kazoj kiam estis necese rilati al literoj markitaj por forigo, inkluzive de 2009. Tial ni decidis konservi ĉion por nun. Sed kiam la kosto de ĉi tio fariĝos nepravigebla, ni pensos pri forigo. Sed, se vi bezonas tute forigi apartan leteron el la datumbazo por ke ne estu spuroj, tiam ĉi tio povas esti farita per speciala peto.
Kial konservi ĝin? Ĉu vi havas statistikojn pri aliro al malnovaj dokumentoj?
Ne estas statistikoj. Pli precize, ĝi estas en formo de uzantprotokolo, sed ĝi ne estas konservita longe. Enskriboj pli aĝaj ol jaro estas forigitaj de la protokolo.
Estis situacioj, kiam necesis retrovi malnovan korespondadon de antaŭ kvin aŭ eĉ dek jaroj. Kaj ĉi tio ĉiam estis farita ne pro senutila scivolemo, sed por fari kompleksajn komercajn decidojn. Estis kazo kie, sen koresponda historio, malĝusta komerca decido estus farita.
Kiel la valoro de dokumentoj estas taksita kaj detruita laŭ konservaj periodoj?
Por paperaj dokumentoj tio estas farita laŭ la kutima tradicia maniero, kiel ĉiuj aliaj. Ni ne faras ĝin por elektronikaj - lasu ilin konservi ilin por si. La sidado estas ĉi tie. Estas avantaĝoj. Ĉiuj fartas bone.
Kiaj evoluperspektivoj estas?
Nun nia DO solvas ĉirkaŭ 30 internajn problemojn, kelkajn el kiuj ni listigis komence de la artikolo. La DL ankaŭ estas uzata por prepari konferencojn, kiujn ni okazigas dufoje jare por niaj partneroj: la tuta programo, ĉiuj raportoj, ĉiuj paralelaj sekcioj, salonoj - ĉio ĉi estas tajpita en la DL, kaj poste elŝutita de ĝi, kaj presita programo. estas farita.
Estas pluraj pliaj taskoj survoje por la DO, krom tiuj, kiujn ĝi jam solvas. Estas tutkompaniaj taskoj, kaj ekzistas unikaj kaj maloftaj, bezonataj nur de specifa fako. Necesas helpi ilin, kio signifas vastigi la "geografion" uzi la sistemon ene de 1C - vastigi la amplekson de apliko, solvante la problemojn de ĉiuj fakoj. Ĉi tio estus la plej bona testo por rendimento kaj fidindeco. Mi ŝatus vidi la sistemon funkcii sur bilionoj da rekordoj, petabajtoj da informoj.
fonto: www.habr.com