By 1C gebruik ons wyd ons eie ontwikkelings om die maatskappy se werk te organiseer. In die besonder, . Benewens dokumentbestuur (soos die naam aandui), is dit ook 'n moderne -stelsel (Enterprise Content Management - korporatiewe inhoudbestuur) met 'n wye verskeidenheid van funksionaliteit - pos, werknemer werk kalenders, organisering van gedeelde toegang tot hulpbronne (byvoorbeeld, bespreking van vergaderlokale), tyd dop, korporatiewe forum en nog baie meer.
Meer as duisend werknemers gebruik dokumentbestuur by 1C. Die databasis het reeds indrukwekkend geword (11 miljard rekords), wat beteken dat dit noukeuriger sorg en kragtiger toerusting vereis.
Hoe ons stelsel werk, watter probleme ons ondervind wanneer ons die databasis in stand hou en hoe ons dit oplos (ons gebruik MS SQL Server as 'n DBMS) - ons sal jou in die artikel vertel.
Vir diegene wat vir die eerste keer oor 1C-produkte lees.
1C:Document Flow is 'n toepassingsoplossing (konfigurasie) wat geïmplementeer word op die basis van 'n raamwerk vir die ontwikkeling van besigheidstoepassings - die 1C:Enterprise-platform.
"1C: Document Flow 8" (afgekort as DO) laat jou toe om werk met dokumente in 'n onderneming te outomatiseer. Een van die belangrikste instrumente vir werknemerinteraksie is e-pos. Benewens pos, los DO ook ander probleme op:
- Tyd dop
- Werknemer afwesigheid dop
- Aansoeke vir koeriers/vervoer
- Werknemers werk kalenders
- Registrasie van korrespondensie
- Werknemerkontakte (adresboek)
- Korporatiewe forum
- Kamerbespreking
- Gebeurtenisbeplanning
- CRM
- Kollektiewe werk met lêers (met stoor lêer weergawes)
- ens.
Ons betree Dokumentbestuur (inheemse uitvoerbare toepassing) vanaf Windows, Linux, macOS, (van blaaiers) en - afhangende van die situasie.
En te danke aan ons ander produk wat aan Document Flow gekoppel is - – ons direk in Document Flow ontvang die funksionaliteit van die boodskapper – kletse, oudio- en video-oproepe (insluitend groepoproepe, wat nou veral belangrik geword het, insluitend vanaf 'n mobiele kliënt), vinnige lêeruitruiling plus die vermoë om kletsbots te skryf wat vereenvoudig werk met die stelsel. Nog 'n voordeel van die gebruik van die interaksiestelsel (in vergelyking met ander boodskappers) is die vermoë om kontekstuele besprekings te voer wat gekoppel is aan spesifieke Dokumentvloei-objekte - dokumente, gebeure, ens. Dit wil sê, die interaksiestelsel is diep geïntegreer met die teikentoepassing, en dien nie net as 'n "aparte knoppie" nie.
Die aantal briewe in ons DO het reeds 100 miljoen oorskry, en oor die algemeen is daar meer as 11 miljard rekords in die DBBS. In totaal gebruik die stelsel byna 30 TB berging: die databasisvolume is 7,5 TB, lêers vir kollektiewe werk word afsonderlik gestoor en beslaan nog 21 TB.
As ons oor meer spesifieke getalle praat, hier is die aantal letters en lêers op die oomblik:
- Uitgaande e-posse – 14,7 miljoen.
- Inkomende briewe – 85,4 miljoen.
- Lêerweergawes – 70,8 miljoen.
- Interne dokumente – 30,6 duisend.
DO het meer as net pos en lêers. Hieronder is die syfers vir ander rekeningkundige voorwerpe:
- Bespreking van vergaderlokale – 52 126
- Weeklikse verslae – 153 940
- Daaglikse verslae – 628 153
- Goedkeuringsvisums – 11 821
- Inkomende dokumente – 79 677
- Uitgaande dokumente – 28 357
- Inskrywings oor gebeure in gebruikerswerkkalenders – 168 228
- Aansoeke vir koeriers – 21 883
- Teenpartye – 81 029
- Rekords van werk met teenpartye – 45 632
- Kontakpersone van teenpartye – 41 795
- Gebeure – 10 243
- Projekte – 6 320
- Werknemertake – 245 980
- Forumplasings – 26 282
- Kletsboodskappe – 891 095
- Besigheidsprosesse - 109 056. Interaksie tussen werknemers vind plaas deur prosesse - goedkeuring, uitvoering, hersiening, registrasie, ondertekening, ens. Ons meet die duur van prosesse, die aantal siklusse, die aantal deelnemers, die aantal opgawes, die aantal versoeke om sperdatums te verander. En hierdie inligting is baie nuttig om te ontleed om te verstaan watter prosesse in die onderneming plaasvind en die doeltreffendheid van werknemersamewerking te verhoog.
Op watter toerusting verwerk ons dit alles?
Hierdie syfers dui op 'n indrukwekkende volume take, dus het ons gekonfronteer met die behoefte om redelik produktiewe toerusting vir die behoeftes van interne filiale toe te wys. Tans is sy kenmerke soos volg: 38 kerne, 240 GB RAM, 26 TB skywe. Hier is 'n tabel van bedieners:
In die toekoms beplan ons om die kapasiteit van die toerusting te verhoog.
Hoe gaan dit met die bedienerlading?
Netwerkaktiwiteit was nog nooit 'n probleem vir ons of ons kliënte nie. As 'n reël is die swak punt die verwerker en skywe, want almal weet reeds hoe om 'n gebrek aan geheue te hanteer. Hier is skermkiekies van ons bedieners van Resource Monitor, wat wys dat ons nie 'n vreeslike vrag het nie, dit is baie beskeie.
Byvoorbeeld, in die skermkiekie hieronder sien ons 'n SQL-bediener waar die SVE-lading 23% is. En dit is 'n baie goeie aanwyser (ter vergelyking: as die las 70% nader, sal werknemers heel waarskynlik aansienlike verlangsamings in werk waarneem).
Die tweede skermkiekie wys die toepassingsbediener waarop die 1C:Enterprise-platform loop - dit dien slegs gebruikersessies. Hier is die verwerkerlading effens hoër - 38%, dit is glad en kalm. Daar is 'n mate van skyflaai, maar dit is aanvaarbaar.
Die derde skermkiekie wys nog 'n 1C:Enterprise-bediener (dit is die tweede een, ons het twee van hulle in die groepie). Slegs die vorige een dien gebruikers, en robots werk op hierdie een. Hulle ontvang byvoorbeeld pos, roetedokumente, ruil data uit, bereken regte, ens. Al hierdie agtergrondaktiwiteite verrig ongeveer 90-100 agtergrondtake. En hierdie bediener is baie swaar gelaai - 88%. Maar dit raak nie mense nie, en dit implementeer presies al die outomatisering wat Dokumentbestuur moet doen.
Wat is die maatstawwe om prestasie te meet?
Ons het 'n ernstige substelsel wat in ons filiale ingebou is om prestasie-aanwysers te meet en verskeie maatstawwe te bereken. Dit is nodig om beide op die huidige oomblik in tyd en vanuit 'n historiese perspektief te verstaan wat in die sisteem gebeur, wat erger word, wat beter word. Moniteringsinstrumente - statistieke en tydmetings - is ingesluit in die standaard aflewering van "1C: Document Flow 8". Die maatstawwe vereis aanpassing tydens implementering, maar die meganisme self is standaard.
Metrieke is metings van verskeie besigheidsaanwysers op sekere tydstip (byvoorbeeld, die gemiddelde posafleweringstyd is 10 minute).
Een van die maatstawwe toon die aantal aktiewe gebruikers in die databasis. Gemiddeld is daar 1000-1400 van hulle gedurende die dag. Die grafiek toon dat daar ten tyde van die skermkiekie 2144 aktiewe gebruikers in die databasis was.
Daar is meer as 30 sulke aksies, die lys is onder die knie.Lys
- Teken in op die stelsel
- Teken uit
- Laai pos
- Verandering van die geldigheid van 'n voorwerp
- Verander toegangsregte
- Verander die onderwerp van 'n proses
- Verandering van 'n voorwerp se werkgroep
- Verander die samestelling van die kit
- Lêerverandering
- Lêer invoer
- Stuur per pos
- Skuif lêers
- Herlei 'n taak
- Ondertekening van die elektroniese handtekening
- Soek volgens besonderhede
- Volteks soektog
- Ontvang tans 'n lêer
- Onderbreek 'n proses
- hersiening
- Dekripsie
- Dokumentregistrasie
- skandering
- Ontmerk verwydering
- Die skep van 'n voorwerp
- Stoor tans op skyf
- Begin van die proses
- Vee gebruikersloginskrywings uit
- Die verwydering van 'n elektroniese handtekening
- Stel 'n skrapmerk op
- Enkripsie
- Voer 'n gids uit
Voorverlede week het ons gemiddelde gebruikersaktiwiteit met een en 'n half keer toegeneem (in rooi op die grafiek gewys) - dit is as gevolg van die oorgang van die meeste werknemers na afgeleë werk (as gevolg van bekende gebeurtenisse). Die aantal aktiewe gebruikers het ook met 3 keer toegeneem (getoon in blou op die skermkiekie), aangesien werknemers selfone aktief begin gebruik het: elke mobiele kliënt skep 'n verbinding met die bediener. Tans het elkeen van ons werknemers gemiddeld 2 verbindings met die bediener.
Vir ons, as administrateurs, is dit 'n teken dat ons meer aandag moet gee aan prestasiekwessies en kyk of dinge erger geword het. Maar ons kyk hierna op grond van ander parameters. Byvoorbeeld, hoe die posafleweringstyd vir interne roetes verander (in blou in die skermkiekie hieronder gewys). Ons sien dat dit tot vanjaar gewissel het, maar nou is dit stabiel - vir ons is dit 'n aanduiding dat alles in orde is met die stelsel.
Nog 'n toegepaste maatstaf vir ons is die gemiddelde wagtyd vir die aflaai van briewe vanaf die posbediener (in rooi in die skermkiekie gewys). Rofweg gesproke, hoe lank sal die brief op die internet ronddryf voordat dit ons werknemer bereik. Die kiekie wys dat hierdie tyd ook nie onlangs verander het nie. Daar is geïsoleerde spykers - maar dit word nie geassosieer met vertragings nie, maar met die feit dat die tyd op die posbedieners verlore gaan.
Of, byvoorbeeld, 'n ander maatstaf (getoon in blou in die skermkiekie) - opdatering van letters in 'n gids. Om 'n posvouer oop te maak is 'n baie algemene bewerking en moet vinnig gedoen word. Ons meet hoe vinnig dit uitgevoer word. Hierdie aanwyser word vir elke kliënt gemeet. Jy kan beide die algehele prentjie vir die maatskappy en die dinamika sien, byvoorbeeld vir 'n individuele werknemer. Die skermkiekie wys dat die metrieke tot vanjaar ongebalanseerd was, toe het ons 'n aantal verbeterings aangebring, en nou word dit nie erger nie - die grafiek is amper plat.
Metrieke is basies 'n administrateur se instrument om die stelsel te monitor, om vinnig te reageer op enige veranderinge in die gedrag van die stelsel. Die skermkiekie toon interne filiaalstatistieke vir die jaar. Die sprong in die grafieke is te wyte aan die feit dat ons take gegee is om interne filiale te ontwikkel.
Hier is 'n lys van nog 'n paar maatstawwe (onder die snit).
Metrieke
- Gebruikersaktiwiteit
- Aktiewe gebruikers
- Aktiewe prosesse
- Aantal lêers
- Lêergrootte (MB)
- Aantal dokumente
- Aantal voorwerpe wat aan ontvangers gestuur moet word
- Aantal teenpartye
- Onvoltooide take
- Gemiddelde wagtyd vir die aflaai van e-posse vanaf die posbediener oor die afgelope 10 minute
- Eksterne databuffer: aantal lêers
- Sloerende grens vanaf die huidige datum
- Lang tou
- Operasionele tou
- Rou rekening ouderdom deur eksterne roetering
- Interne roete-aanvaarding-waglysgrootte (lang tou)
- Interne roete-aanvaarding-waglysgrootte (vinnige tou)
- Pos afleweringstyd via interne roetering (lang tou)
- Pos afleweringstyd via interne roetering (vinnige tou)
- Pos afleweringstyd via eksterne roetering (gemiddeld)
- Aantal dokumente Bespreking
- Aantal dokumente Afwesigheid
- Aantal dokumente "Rekord van werk met teenparty"
- Pos Werk briewe in 'n gids op
- Pos Maak 'n briefkaart oop
- Pos Dra 'n brief oor na 'n gids
- Pos Navigeer deur dopgehou
Ons stelsel meet meer as 150 aanwysers rondom die klok, maar nie almal kan vinnig gemonitor word nie. Hulle kan later handig te pas kom, in een of ander historiese perspektief, en jy kan fokus op die belangrikstes vir die besigheid.
In een van die implementerings is byvoorbeeld slegs 5 aanwysers gekies. Die kliënt het 'n doelwit gestel om 'n minimum stel aanwysers te skep, maar terselfdertyd sodanig dat dit die hoofwerkscenario's dek. Dit sal ongeregverdig wees om 150 aanwysers by die aanvaardingsertifikaat in te sluit, want selfs binne die onderneming is dit moeilik om saam te stem oor watter aanwysers as aanvaarbaar beskou word. En hulle het geweet van hierdie 5 aanwysers en het dit reeds voor die aanvang van die implementeringsprojek aan die stelsel voorgelê, dit ingesluit in die kompetisiedokumentasie: tyd om 'n kaart oop te maak nie meer as 3 sekondes nie, tyd om 'n taak te voltooi met 'n lêer nr. meer as 5 sekondes, ens. In ons filiale het ons maatstawwe gehad wat die oorspronklike versoek van die kliënt se tegniese spesifikasies baie duidelik weerspieël.
Ons het ook 'n profielontleding van prestasiemetings. Prestasie-aanwysers is 'n opname van die duur van elke deurlopende operasie (skryf 'n brief aan die databasis, stuur 'n brief aan 'n posbediener, ens.). Dit word uitsluitlik deur tegnici gebruik. Ons versamel baie prestasie-aanwysers in ons program. Ons meet tans ongeveer 1500 XNUMX sleutelbedrywighede, wat in profiele verdeel is.
Een van die belangrikste profiele vir ons is die "Lys van sleutelaanwysers van pos vanuit 'n verbruikersperspektief." Hierdie profiel sluit byvoorbeeld die volgende aanwysers in:
- Voer die opdrag uit: Kies volgens merker
- Maak 'n vorm oop: Lysvorm
- Voer die opdrag uit: Kies volgens gids
- Vertoon 'n letter in die leesarea
- Stoor 'n brief in jou gunsteling vouer
- Soek briewe volgens besonderhede
- Die skep van 'n brief
As ons sien dat die maatstaf vir die een of ander besigheidsaanwyser te groot geword het (byvoorbeeld, briewe van 'n spesifieke gebruiker het vir 'n baie lang tyd begin aankom), begin ons dit uitvind en gaan ons oor om die tyd van tegniese bedrywighede te meet. Ons het 'n tegniese operasie "Argiveer briewe op 'n posbediener" - ons sien dat die tyd vir hierdie operasie oorskry is vir die laaste periode. Hierdie bewerking word op sy beurt in ander bewerkings ontbind - byvoorbeeld om 'n verbinding met 'n posbediener te vestig. Ons sien dat dit om een of ander rede skielik baie groot geword het (ons het al die afmetings vir 'n maand - ons kan vergelyk dat dit verlede week 10 millisekondes was, en nou is dit 1000 millisekondes). En ons verstaan dat hier iets stukkend is – ons moet dit regmaak.
Hoe hou ons so 'n groot databasis in stand?
Ons interne DO is 'n voorbeeld van 'n werklik werkende hoëladingsprojek. Kom ons praat oor die tegniese kenmerke van sy databasis.
Hoe lank neem dit om groot databasistabelle te herstruktureer?
Die SQL-bediener vereis periodieke instandhouding en plaas die tabelle in volgorde. Op 'n goeie manier moet dit ten minste een keer per dag gedoen word, en selfs meer dikwels vir hoë aanvraag tafels. Maar as die databasis groot is (en ons aantal rekords het reeds 11 miljard oorskry), dan is dit nie maklik om daarvoor te sorg nie.
Ons het 6 jaar gelede 'n tafelherstrukturering gedoen, maar toe begin dit soveel tyd neem dat ons nie meer in die nagtelike intervalle inpas nie. En aangesien hierdie bewerkings die SQL-bediener swaar laai, kan dit nie ander gebruikers doeltreffend bedien nie.
Daarom moet ons nou verskillende truuks gebruik. Ons kan byvoorbeeld nie hierdie prosedures op volledige datastelle uitvoer nie. Jy moet gebruik maak van die Update Sample 500000 rye-prosedure - dit neem 14 minute. Dit werk nie statistieke oor alle data in die tabel op nie, maar kies 'n halfmiljoen rye en gebruik dit om statistieke te bereken wat dit vir die hele tabel gebruik. Dit is 'n aanname, maar ons word gedwing om dit te maak, want vir 'n spesifieke tabel sal die insameling van statistieke oor die hele miljard rekords 'n onaanvaarbare lang tyd neem.
Ons het ook ander instandhoudingsbedrywighede geoptimaliseer deur dit gedeeltelik te maak.
Die instandhouding van 'n DBBS is oor die algemeen 'n moeilike taak. In die geval van aktiewe interaksie tussen werknemers, groei die databasis vinnig, en dit word al hoe moeiliker vir administrateurs om dit in stand te hou – opdatering van statistieke, defragmentering, indeksering. Hier moet ons verskillende strategieë toepas, ons weet goed hoe om dit te doen, ons het ondervinding, ons kan dit deel.
Hoe word rugsteun met sulke volumes geïmplementeer?
'n Volledige DBMS-rugsteun word een keer per dag in die nag uitgevoer, 'n inkrementele een - elke uur. Daar word ook elke dag 'n lêergids geskep, en dit is 'n deel van die inkrementele rugsteun van die lêerberging.
Hoe lank neem dit om 'n volledige rugsteun te voltooi?
'n Volledige rugsteun na 'n hardeskyf word in drie uur voltooi, 'n gedeeltelike rugsteun in 'n uur. Dit neem langer om op band te skryf ('n spesiale toestel wat 'n rugsteunkopie maak na 'n spesiale kasset wat buite die kantoor gestoor word; 'n oordraagbare kopie word na die band gemaak, wat behoue bly as die bedienerkamer byvoorbeeld afbrand). Die rugsteun word op presies dieselfde bediener gemaak, waarvan die parameters hoër was - 'n SQL-bediener met 20% verwerkerlading. Ten tyde van rugsteun word die stelsel natuurlik baie erger, maar dit is steeds funksioneel.
Is daar deduplisering?
Daar is lêers, ons sal dit op onsself toets, en binnekort sal dit by die nuwe weergawe van Dokumentbestuur ingesluit word. Ons toets ook die teenparty-dedupliseringsmeganisme uit. Daar is geen deduplisering van rekords op die DBBS-vlak nie, aangesien dit nie nodig is nie. Die 1C:Enterprise-platform stoor voorwerpe in die DBBS, en slegs die platform kan verantwoordelik wees vir hul konsekwentheid.
Is daar net-lees-nodes?
Daar is geen leesnodusse nie (toegewyde stelselnodusse wat diegene bedien wat enige data vir lees moet ontvang). DO is nie 'n rekeningkundige stelsel om op 'n aparte BI-nodus te plaas nie, maar daar is 'n aparte nodus vir die ontwikkelingsafdeling, waarmee boodskappe in JSON-formaat uitgeruil word, en die tipiese replikasietyd is eenhede en tientalle sekondes. Die nodus is nog klein, dit het ongeveer 800 miljoen rekords, maar dit groei vinnig.
Word e-posse gemerk vir uitvee glad nie uitgevee nie?
Nog nie. Ons het nie die taak om die basis ligter te maak nie. Daar was verskeie taamlik ernstige gevalle waar dit nodig was om te verwys na briewe wat vir skrap gemerk is, insluitend 2009. Daarom het ons besluit om alles vir eers te hou. Maar wanneer die koste hiervan ongeregverdig word, sal ons aan verwydering dink. Maar as u 'n aparte brief heeltemal uit die databasis moet verwyder sodat daar geen spore is nie, kan dit op spesiale versoek gedoen word.
Hoekom dit stoor? Het jy statistieke oor toegang tot ou dokumente?
Daar is geen statistieke nie. Meer presies, dit is in die vorm van 'n gebruikerslogboek, maar dit word nie lank gestoor nie. Inskrywings ouer as 'n jaar word uit die protokol uitgevee.
Daar was situasies toe dit nodig was om ou korrespondensie van vyf of selfs tien jaar gelede te herwin. En dit is altyd gedoen, nie uit ledige nuuskierigheid nie, maar om komplekse sakebesluite te neem. Daar was 'n geval waar, sonder korrespondensiegeskiedenis, 'n verkeerde sakebesluit geneem sou word.
Hoe word die waarde van dokumente beoordeel en vernietig volgens bergingstydperke?
Vir papierdokumente word dit op die gewone tradisionele manier gedoen, soos almal anders. Ons doen dit nie vir elektroniese mense nie - laat hulle dit vir hulself hou. Die sit is hier. Daar is voordele. Dit gaan goed met almal.
Watter ontwikkelingsvooruitsigte is daar?
Nou los ons DO ongeveer 30 interne probleme op, waarvan ons sommige aan die begin van die artikel gelys het. Die DL word ook gebruik om konferensies voor te berei wat ons twee keer per jaar vir ons vennote hou: die hele program, alle verslae, alle parallelle afdelings, sale - dit alles word in die DL getik, en dan daaruit afgelaai, en 'n gedrukte program is gemaak.
Daar is nog verskeie take op pad vir die DO, benewens dié wat dit reeds oplos. Daar is maatskappywye take, en daar is unieke en seldsame take wat slegs deur 'n spesifieke departement benodig word. Dit is nodig om hulle te help, wat beteken die uitbreiding van die "geografie" van die gebruik van die stelsel binne 1C - die uitbreiding van die toepassingsgebied, die oplossing van die probleme van alle departemente. Dit sal die beste toets vir werkverrigting en betroubaarheid wees. Ek sou graag wou sien dat die stelsel werk op triljoene rekords, petagrepe van inligting.
Bron: will.com