By 1C brûke wy ús eigen ûntjouwings in protte om it wurk fan it bedriuw te organisearjen. Yn't bysonder, . Neist dokumintbehear (lykas de namme al fermoeden docht), is it ek in moderne -systeem (Enterprise Content Management - Corporate Content Management) mei in breed oanbod fan funksjonaliteit - post, wurkkalinders fan wurknimmers, organisearje dielde tagong ta boarnen (bygelyks boeking fan gearkomsteromten), tiidsregistraasje, bedriuwsforum en folle mear.
Mear dan tûzen meiwurkers brûke dokumintbehear by 1C. De databank is al yndrukwekkend wurden (11 miljard records), wat betsjut dat it mear soarchfâldige soarch en krêftiger apparatuer fereasket.
Hoe't ús systeem wurket, hokker swierrichheden wy tsjinkomme by it behâld fan de database en hoe't wy se oplosse (wy brûke MS SQL Server as DBMS) - wy sille jo fertelle yn it artikel.
Foar dyjingen dy't foar it earst lêze oer 1C-produkten.
1C:Document Flow is in applikaasje-oplossing (konfiguraasje) ymplementearre op basis fan in ramt foar it ûntwikkeljen fan saaklike applikaasjes - it 1C: Enterprise-platfoarm.
"1C: Document Flow 8" (ôfkoarte as DO) lit jo wurkje mei dokuminten yn in bedriuw automatisearje. Ien fan 'e wichtichste ark foar ynteraksje mei meiwurkers is e-post. Neist post lost DO ek oare problemen op:
- Tiid tracking
- Tracking fan ôfwêzigens fan wurknimmers
- Applikaasjes foar koeriers / ferfier
- Meiwurkers wurk kalinders
- Registraasje fan korrespondinsje
- Meiwurkerskontakten (adresboek)
- Corporate foarum
- Keamer reservearring
- Event Planning
- CRM
- Kollektive wurk mei bestannen (mei opslaan fan triemferzjes)
- en oaren.
Wy ynfiere Document Management (native útfierbere applikaasje) fan Windows, Linux, macOS, (fan browsers) en - ôfhinklik fan 'e situaasje.
En tank oan ús oare produkt ferbûn mei Document Flow - - wy direkt yn Document Flow ûntfange de funksjonaliteit fan 'e boadskipper - petearen, audio- en fideoproppen (ynklusyf groepoproppen, dy't no foaral wichtich is wurden, ynklusyf fan in mobile kliïnt), rappe triemútwikseling plus de mooglikheid om petearbots te skriuwen dy't ferienfâldigje wurkje mei it systeem. In oar foardiel fan it brûken fan it ynteraksjesysteem (yn ferliking mei oare boaden) is de mooglikheid om kontekstuele diskusjes te fieren ferbûn oan spesifike Document Flow-objekten - dokuminten, eveneminten, ensfh. Dat is, it ynteraksjesysteem is djip yntegreare mei de doelapplikaasje, en fungearret net as gewoan in "apart knop".
It oantal letters yn ús DO is al mear as 100 miljoen, en yn 't algemien binne d'r mear as 11 miljard records yn' e DBMS. Yn totaal brûkt it systeem hast 30 TB oan opslach: it databankvolume is 7,5 TB, bestannen foar kollektyf wurk wurde apart opslein en besette nochris 21 TB.
As wy prate oer mear spesifike sifers, hjir is it oantal letters en bestannen op it stuit:
- Utgeande e-mails - 14,7 miljoen.
- Ynkommende brieven - 85,4 miljoen.
- Bestânsferzjes - 70,8 miljoen.
- Ynterne dokuminten - 30,6 tûzen.
DO hat mear dan allinich post en bestannen. Hjirûnder binne de sifers foar oare boekhâldkundige objekten:
- Booking gearkomsteromten - 52
- Wyklikse rapporten - 153
- Deistige rapporten - 628
- Goedkarring visa - 11
- Ynkommende dokuminten - 79
- Utgeande dokuminten - 28
- Ynstjoerings oer eveneminten yn wurkkalinders fan brûkers - 168
- Oanfragen foar koeriers - 21
- Tsjinpartijen - 81
- Records fan wurk mei tsjinpartijen - 45
- Kontaktpersoanen fan tsjinpartijen - 41
- Eveneminten - 10
- Projekten - 6
- Meiwurker taken - 245
- Foarum berjochten - 26
- Petearberjochten - 891 095
- Saaklike prosessen - 109 056. Ynteraksje tusken meiwurkers komt troch prosessen - goedkarring, útfiering, resinsje, registraasje, ûndertekening, ensfh. Wy mjitte de doer fan prosessen, it oantal syklusen, it oantal dielnimmers, it oantal rendeminten, it oantal oanfragen om deadlines te feroarjen. En dizze ynformaasje is heul nuttich om te analysearjen om te begripen hokker prosessen yn 'e ûndernimming plakfine en de effisjinsje fan gearwurking mei meiwurkers ferheegje.
Op hokker apparatuer ferwurkje wy dit alles?
Dizze sifers jouwe oan in yndrukwekkend folume fan taken, dus wy waarden konfrontearre mei de needsaak om frij produktive apparatuer te allocearjen foar de behoeften fan ynterne dochterûndernimmingen. Op it stuit binne har skaaimerken as folget: 38 kearnen, 240 GB RAM, 26 TB fan skiven. Hjir is in tabel mei servers:
Yn 'e takomst planje wy de kapasiteit fan' e apparatuer te fergrutsjen.
Hoe giet it mei de serverlading?
Netwurkaktiviteit hat nea in probleem west foar ús of ús klanten. As regel is it swakke punt de prosessor en de skiven, om't elkenien al wit hoe't jo moatte omgean mei in gebrek oan ûnthâld. Hjir binne skermôfbyldings fan ús servers fan Resource Monitor, dy't sjen litte dat wy gjin skriklike lading hawwe, it is heul beskieden.
Bygelyks, yn 'e skermôfbylding hjirûnder sjogge wy in SQL-tsjinner wêr't de CPU-lading 23% is. En dit is in tige goede yndikator (foar fergeliking: as de lading 70% komt, dan, nei alle gedachten, meiwurkers sille observearje hiel wichtige fertraging yn wurk).
De twadde skermôfbylding lit de applikaasje-tsjinner sjen wêrop it 1C: Enterprise-platfoarm rint - it tsjinnet allinich brûkerssesjes. Hjir de prosessor lading is wat heger - 38%, it is glêd en kalm. Der is wat skiif laden, mar it is akseptabel.
De tredde skermprint toant in oare 1C: Enterprise-tsjinner (it is de twadde, wy hawwe twa fan har yn it kluster). Allinnich de foarige tsjinnet brûkers, en robots wurkje oan dizze. Se ûntfange bygelyks post, rûtedokuminten, wikselje gegevens út, berekkenje rjochten, ensfh. Al dizze eftergrûnaktiviteiten útfiere sawat 90-100 eftergrûnbanen. En dizze tsjinner is tige swier laden - 88%. Mar dit hat gjin ynfloed op minsken, en it ymplementearret krekt alle automatisearring dy't Document Management moat dwaan.
Wat binne de metriken om prestaasjes te mjitten?
Wy hawwe in serieus subsysteem ynboud yn ús dochterûndernimmingen foar it mjitten fan prestaasjesyndikatoaren en it berekkenjen fan ferskate metriken. Dat is nedich om sawol op it aktuele momint as út in histoarysk perspektyf te begripen wat der yn it systeem bart, wat minder wurdt, wat better wurdt. Monitoring-ark - metriken en tiidmjittingen - binne opnommen yn 'e standert levering fan "1C: Document Flow 8". De metriken fereaskje maatwurk by ymplemintaasje, mar it meganisme sels is standert.
Metriken binne mjittingen fan ferskate saaklike yndikatoaren op bepaalde punten yn 'e tiid (bygelyks is de gemiddelde postlevertiid 10 minuten).
Ien fan 'e metriken toant it oantal aktive brûkers yn' e databank. Gemiddeld binne der oerdei 1000-1400 fan. De grafyk lit sjen dat op it momint fan it skermôfbylding d'r 2144 aktive brûkers yn 'e database wiene.
Der binne mear as 30 sokke aksjes, de list is ûnder de besuniging.List fan
- Oanmelde
- Út logge
- Post laden
- It feroarjen fan de jildichheid fan in objekt
- Feroarje tagongsrjochten
- It feroarjen fan it ûnderwerp fan in proses
- It feroarjen fan de wurkgroep fan in objekt
- It feroarjen fan de gearstalling fan de kit
- It feroarjen fan in triem
- Triem ymportearje
- Ferstjoere per post
- Ferpleatse triemmen
- It omlieden fan in taak
- Undertekenjen fan de elektroanyske hantekening
- Sykje op details
- Folsleine tekst sykjen
- Untfange in triem
- In proses ûnderbrekke
- Fisy
- Dekodearring
- Dokumint registraasje
- Scan
- Demarkearje wiskjen
- It meitsjen fan in objekt
- Opslaan op skiif
- Begjin fan it proses
- It wiskjen fan brûker log yngongen
- It fuortsmiten fan in elektroanyske hantekening
- It ynstellen fan in wiskje mark
- Fersifering
- Eksportearje in map
De foarige wike is ús gemiddelde brûkersaktiviteit mei ien en in heale kear ferhege (yn 'e grafyk werjûn yn read) - dit komt troch de oergong fan de measte meiwurkers nei wurk op ôfstân (fanwege bekende eveneminten). Ek, it oantal aktive brûkers tanommen mei 3 kear (oanjûn yn blau op 'e skermprint), as meiwurkers begûn aktyf te brûken mobile telefoans: elke mobile client makket in ferbining mei de tsjinner. Op it stuit hat elk fan ús meiwurkers gemiddeld 2 ferbiningen mei de tsjinner.
Foar ús, as behearders, is dit in sinjaal dat wy oandachtiger moatte wêze foar prestaasjesproblemen en sjen oft dingen slimmer binne wurden. Mar wy sjogge dit op basis fan oare parameters. Bygelyks hoe't de e-postlevertiid foar ynterne routing feroaret (yn blau werjûn yn 'e skermôfbylding hjirûnder). Wy sjogge dat it oant dit jier fluktuearret, mar no is it stabyl - foar ús is dit in yndikator dat alles yn oarder is mei it systeem.
In oare tapaste metrik foar ús is de gemiddelde wachttiid foar it downloaden fan brieven fan 'e e-posttsjinner (yn read yn' e skermôfbylding werjûn). Rûchwei, hoe lang sil de brief op it ynternet sweve foardat it ús meiwurker berikt. It skermôfbylding lit sjen dat dizze tiid de lêste tiid ek net feroare is. D'r binne isolearre spikes - mar se wurde net ferbûn mei fertragingen, mar mei it feit dat de tiid op 'e e-posttsjinners ferlern is.
Of, bygelyks, in oare metryske (yn blau werjûn yn 'e skermôfbylding) - it bywurkjen fan letters yn in map. It iepenjen fan in postmap is in heul gewoane operaasje en moat fluch dien wurde. Wy mjitte hoe fluch it wurdt útfierd. Dizze yndikator wurdt mjitten foar elke klant. Jo kinne sawol it algemiene byld foar it bedriuw as de dynamyk sjen, bygelyks foar in yndividuele meiwurker. It skermôfbylding lit sjen dat oant dit jier de metryske unbalansearre wie, doe hawwe wy in oantal ferbetterings makke, en no wurdt it net slimmer - de grafyk is hast flak.
Metriken binne yn prinsipe in behearder syn ark foar tafersjoch op it systeem, foar fluch reagearje op alle feroarings yn it gedrach fan it systeem. De skermprint toant ynterne dochterûndernimmingsmetriken foar it jier. De sprong yn 'e grafiken komt troch it feit dat wy taken krigen hawwe om ynterne dochterûndernimmingen te ûntwikkeljen.
Hjir is in list mei wat mear metriken (ûnder de besuniging).
Metrics
- Brûker aktiviteit
- Aktive brûkers
- Aktive prosessen
- Oantal triemmen
- Bestânsgrutte (MB)
- Oantal dokuminten
- Oantal objekten dy't stjoerd wurde nei ûntfangers
- Oantal tsjinpartijen
- Unfoltôge taken
- Gemiddelde wachttiid foar it downloaden fan e-mails fan 'e e-posttsjinner oer de lêste 10 minuten
- Eksterne gegevensbuffer: oantal bestannen
- Lagging grins fan de hjoeddeiske datum
- Lange wachtrige
- Operasjonele wachtrige
- Raw account leeftyd troch eksterne routing
- Ynterne routing akseptaasjewachtrige grutte (lange wachtrige)
- Ynterne routing akseptaasjewachtrige grutte (snelle wachtrige)
- Postlevertiid fia ynterne routing (lange wachtrige)
- Postlevertiid fia ynterne routing (snelle wachtrige)
- Postlevertiid fia eksterne routing (gemiddelde)
- Oantal dokuminten Reservearring
- Oantal dokuminten Absence
- Oantal dokuminten "Rekord fan wurk mei tsjinpartij"
- Mail Update brieven yn in map
- Mail It iepenjen fan in briefkaart
- Mail In brief oerbringe nei in map
- Post Navigearje troch mappen
Us systeem mjit mear dan 150 yndikatoaren rûn de klok, mar net allegear kinne fluch wurde kontrolearre. Se kinne letter fan pas komme, yn guon histoaryske perspektyf, en jo kinne rjochtsje op de wichtichste foar it bedriuw.
Yn ien fan 'e ymplemintaasjes waarden bygelyks mar 5 yndikatoaren selektearre. De klant stelde in doel om in minimale set fan yndikatoaren te meitsjen, mar tagelyk sa dat it de wichtichste wurkscenario's behannele. It soe ûnrjochtfeardich wêze om 150 yndikatoaren op te nimmen yn it akseptaasjesertifikaat, om't sels binnen it bedriuw it lestich is om te iens oer hokker yndikatoaren as akseptabel wurde beskôge. En se wisten oer dizze 5 yndikatoaren en hienen se al foar it begjin fan it ymplemintaasjeprojekt oan it systeem presintearre, ynklusyf se yn 'e kompetysjedokumintaasje: tiid om in kaart te iepenjen net mear as 3 sekonden, tiid om in taak te foltôgjen mei in bestân nr. mear as 5 sekonden, ensfh. Yn ús dochterûndernimmingen hiene wy metriken dy't it orizjinele fersyk fan 'e technyske spesifikaasjes fan 'e klant heul dúdlik wjerspegele.
Wy hawwe ek in profylanalyse fan prestaasjesmjittingen. Prestaasje-yndikatoaren binne in opname fan 'e doer fan elke oanhâldende operaasje (in brief skriuwe nei de databank, in brief stjoere nei in e-posttsjinner, ensfh.). Dit wurdt allinich brûkt troch technici. Wy sammelje in protte prestaasje-yndikatoaren yn ús programma. Wy mjitte op it stuit likernôch 1500 kaai operaasjes, dy't binne ferdield yn profilen.
Ien fan 'e wichtichste profilen foar ús is de "List fan wichtige yndikatoaren fan e-post út in konsumintperspektyf." Dit profyl omfettet bygelyks de folgjende yndikatoaren:
- It kommando útfiere: Selektearje troch tag
- Iepenje in formulier: List Form
- It kommando útfiere: Selektearje op map
- It werjaan fan in brief yn it lêsgebiet
- In brief opslaan yn jo favorite map
- Sykje nei letters op details
- It meitsjen fan in brief
As wy sjogge dat de metryske foar guon saaklike yndikator te grut wurden is (bygelyks binne brieven fan in bepaalde brûker foar in heul lange tiid begon te kommen), begjinne wy it út te finen en omgean nei it mjitten fan 'e tiid fan technyske operaasjes. Wy hawwe in technyske operaasje "Argivearjen fan brieven op in e-posttsjinner" - wy sjogge dat de tiid foar dizze operaasje foar de lêste perioade is oerskreaun. Dizze operaasje wurdt op syn beurt ferdield yn oare operaasjes - bygelyks it meitsjen fan in ferbining mei in e-posttsjinner. Wy sjogge dat it om ien of oare reden ynienen heul grut is wurden (wy hawwe alle mjittingen foar in moanne - wy kinne fergelykje dat it ferline wike 10 millisekonden wie, en no is it 1000 millisekonden). En wy begripe dat hjir wat brutsen is - wy moatte it reparearje.
Hoe hâlde wy sa'n grutte databank by?
Us ynterne DO is in foarbyld fan in echt wurkjend projekt mei hege lading. Litte wy prate oer de technyske skaaimerken fan syn databank.
Hoe lang duorret it om grutte databanktabellen te werstrukturearjen?
De SQL-tsjinner fereasket periodyk ûnderhâld, en set de tabellen yn oarder. Op in goede manier moat dit op syn minst ien kear deis dien wurde, en noch faker foar tabellen mei hege fraach. Mar as de databank grut is (en ús oantal records is al mear as 11 miljard), dan is it soargjen foar it net maklik.
Wy diene 6 jier lyn in tafel werstrukturearring, mar doe begûn it safolle tiid te duorjen dat wy net mear yn 'e nachtlike yntervallen passe. En om't dizze operaasjes de SQL-tsjinner swier laden, kin it oare brûkers net effisjint tsjinje.
Dêrom moatte wy no ferskate trúkjes brûke. Wy kinne bygelyks dizze prosedueres net útfiere op folsleine datasets. Jo moatte taflecht ta de Update Sample 500000 rigen proseduere - dit duorret 14 minuten. It net bywurkje statistiken op alle gegevens yn 'e tabel, mar selekteart in heal miljoen rigen en brûkt se foar in berekkenjen statistyk dat it brûkt foar de hiele tabel. Dit is wat oanname, mar wy binne twongen om it te meitsjen, want foar in spesifike tabel sil it sammeljen fan statistiken oer de hiele miljard records in ûnakseptabel lange tiid nimme.
Wy hawwe ek oare ûnderhâldsoperaasjes optimalisearre troch se foar in part te meitsjen.
It behâld fan in DBMS is oer it algemien in komplekse taak. Yn it gefal fan aktive ynteraksje tusken meiwurkers groeit de databank fluch, en it wurdt hieltyd dreger foar behearders om it te behâlden - statistyk bywurkje, defragmentaasje, yndeksearring. Hjir moatte wy ferskate strategyen tapasse, wy witte goed hoe dit te dwaan, wy hawwe ûnderfining, wy kinne it diele.
Hoe wurdt backup ymplementearre mei sokke folumes?
In folsleine DBMS-backup wurdt ien kear deis nachts útfierd, in inkrementele ien - elk oere. Ek wurdt elke dei in triemtafel makke, en it is in diel fan 'e inkrementele reservekopy fan' e triem opslach.
Hoe lang duorret it om in folsleine reservekopy te foltôgjen?
In folsleine reservekopy nei in hurde skiif wurdt foltôge yn trije oeren, in part reservekopy yn in oere. It duorret langer om nei de tape te skriuwen (in spesjaal apparaat dat in reservekopy makket nei in spesjale kassette dy't bûten it kantoar bewarre wurdt; der wurdt in oerdraachbere kopy makke nei de tape, dy't bewarre bliuwt as bygelyks de serverkeamer ôfbaarnde). De reservekopy wurdt makke op krekt deselde tsjinner, wêrfan de parameters heger wiene - in SQL-tsjinner mei 20% prosessorlading. Op it stuit fan reservekopy, fansels, it systeem wurdt folle slimmer, mar it is noch funksjoneel.
Is der deduplikaasje?
D'r binne bestannen, wy sille it op ússels testen, en ynkoarten sil it opnommen wurde yn 'e nije ferzje fan Document Management. Wy testen ek it deduplikaasjemeganisme fan tsjinpartij. D'r is gjin deduplikaasje fan records op it DBMS-nivo, om't dit net nedich is. It 1C: Enterprise-platfoarm bewarret objekten yn 'e DBMS, en allinich it platfoarm kin ferantwurdlik wêze foar har konsistinsje.
Binne d'r allinich-read-knooppunten?
D'r binne gjin lêsknooppunten (tawiisde systeemknooppunten dy't dejingen tsjinje dy't gegevens moatte ûntfange foar it lêzen). DO is gjin boekhâlding systeem te setten op in aparte BI node, mar der is in aparte node foar de ûntwikkeling ôfdieling, wêrmei berjochten wurde útwiksele yn JSON opmaak, en de typyske replikaasje tiid is ienheden en tsientallen sekonden. It knooppunt is noch lyts, it hat sawat 800 miljoen records, mar it groeit fluch.
Binne e-mails markearre foar wiskjen hielendal net wiske?
Noch net. Wy hawwe net de taak om de basis lichter te meitsjen. D'r wiene ferskate nochal serieuze gefallen as it nedich wie om te ferwizen nei brieven dy't markearre binne foar wiskjen, ynklusyf 2009. Dêrom hawwe wy besletten alles foar no te hâlden. Mar as de kosten hjirfan ûnrjochtfeardich wurde, sille wy tinke oer ferwidering. Mar, as jo in aparte brief fan 'e databank folslein moatte fuortsmite, sadat der gjin spoaren binne, dan kin dit dien wurde op spesjaal fersyk.
Wêrom bewarje it? Hawwe jo statistiken oer tagong ta âlde dokuminten?
Der binne gjin statistiken. Mear krekter, it is yn 'e foarm fan in brûkerslog, mar it wurdt net lang opslein. Ynstjoerings âlder dan in jier wurde wiske út it protokol.
Der wiene situaasjes dat it nedich wie om âlde korrespondinsje fan fiif of sels tsien jier lyn op te heljen. En dit waard altyd dien net út idle nijsgjirrigens, mar om komplekse saaklike besluten. D'r wie in gefal wêr't sûnder korrespondinsjeskiednis in ferkeard saaklik beslút naam wêze soe.
Hoe wurdt de wearde fan dokuminten beoardiele en ferneatige neffens opslachperioaden?
Foar papieren dokuminten wurdt dat dien op de gewoane tradisjonele wize, lykas alle oaren. Wy dogge it net foar elektroanyske - lit se se foar harsels hâlde. De sit is hjir. Der binne foardielen. Elkenien is goed.
Hokker ûntwikkelingsperspektyf binne d'r?
No lost ús DO sa'n 30 ynterne problemen op, wêrfan guon wy oan it begjin fan it artikel neamden. De DL wurdt ek brûkt foar it tarieden fan konferinsjes dy't wy twa kear yn 't jier foar ús partners hâlde: it hiele programma, alle ferslaggen, alle parallelle seksjes, sealen - dit alles wurdt yn 'e DL optypt, en dêrnei ynladen, en in printe programma is makke.
Der binne noch ferskate taken foar de DO ûnderweis, neist dyjingen dy't it al oplost. D'r binne bedriuwsbrede taken, en d'r binne unike en seldsume, allinich nedich troch in spesifike ôfdieling. It is nedich om har te helpen, wat betsjut dat de "geografy" fan it brûken fan it systeem binnen 1C útwreidzje - it tapassingsgebiet útwreidzje, de problemen fan alle ôfdielingen oplosse. Dit soe de bêste test wêze foar prestaasjes en betrouberens. Ik soe graach sjen dat it systeem wurket op trillions fan records, petabytes oan ynformaasje.
Boarne: www.habr.com