Vi i 1C bruker i stor grad vĂ„r egen utvikling for Ă„ organisere selskapets arbeid. Spesielt, I tillegg til dokumenthĂ„ndtering (som navnet antyder), er det ogsĂ„ et moderne - et system (Enterprise Content Management) med et bredt spekter av funksjonelle muligheter â e-post, ansattes arbeidskalendere, organisering av delt tilgang til ressurser (for eksempel bestilling av mĂžterom), tidssporing, bedriftsforum og mye mer.
Mer enn tusen ansatte bruker 1C dokumenthÄndtering. Databasen har allerede blitt imponerende (11 milliarder poster), noe som betyr at den krever mer nÞye vedlikehold og kraftigere utstyr.
Hvordan systemet vĂ„rt fungerer, hvilke vanskeligheter vi stĂžter pĂ„ nĂ„r vi vedlikeholder databasen og hvordan vi lĂžser dem (vi bruker MS SQL Server som DBMS) â det vil vi fortelle deg i artikkelen.
For de som leser om 1C-produkter for fĂžrste gang.
1C:DokumenthÄndtering er en applikasjonslÞsning (konfigurasjon) implementert pÄ grunnlag av et rammeverk for utvikling av forretningsapplikasjoner - 1C:Enterprise-plattformen.
"1C:DokumenthÄndtering 8" (forkortet DO) lar deg automatisere arbeidet med dokumenter i bedriften. Et av hovedverktÞyene for medarbeiderinteraksjon er e-post. I tillegg til post lÞser DO ogsÄ andre problemer:
- Tidtaking
- RegnskapsfĂžring av ansattes fravĂŠr
- ForespĂžrsler om budtjenester/transport
- Arbeidskalendere for ansatte
- Registrering av korrespondanse
- Ansattkontakter (adressebok)
- Bedriftsforum
- Reservasjon av lokaler
- Arrangementsplanlegging
- CRM
- Samarbeid med filer (med lagring av filversjoner)
- etc.
Vi gĂ„r til dokumenthĂ„ndtering (innebygd kjĂžrbar applikasjon) fra Windows, Linux, macOS, (fra nettlesere) og â avhengig av situasjonen.
Og ogsĂ„ takket vĂŠre vĂ„rt andre produkt knyttet til dokumenthĂ„ndtering â â vi direkte i DokumenthĂ„ndtering fĂ„r funksjonaliteten til en messenger â chatter, lyd- og videosamtaler (inkludert gruppesamtaler, noe som har blitt spesielt relevant nĂ„, inkludert fra en mobilklient), rask filutveksling pluss muligheten til Ă„ skrive chatboter som forenkler arbeidet med systemet. En annen fordel med Ă„ bruke interaksjonssystemet (sammenlignet med andre messengers) er muligheten til Ă„ gjennomfĂžre kontekstuelle diskusjoner knyttet til spesifikke dokumenthĂ„ndteringsobjekter â dokumenter, hendelser osv. Det vil si at interaksjonssystemet er dypt integrert med mĂ„lapplikasjonen, og fungerer ikke bare som en «separat knapp».
Antall bokstaver i vÄrt DO har allerede oversteget 100 millioner, og totalt sett er det mer enn 11 milliarder poster i DBMS. Totalt bruker systemet nesten 30 TB lagringsplass: databasevolumet er 7,5 TB, filer for kollektivt arbeid lagres separat og tar opp ytterligere 21 TB.
Hvis vi snakker om mer spesifikke tall, er dette antallet bokstaver og filer for Ăžyeblikket:
- UtgĂ„ende brev â 14,7 millioner.
- Innkommende e-poster â 85,4 millioner.
- Filversjoner â 70,8 millioner.
- Interne dokumenter â 30,6 tusen.
DO har mer enn bare post og filer. Nedenfor er tallene for andre regnskapsobjekter:
- Bestilling av mĂžterom â 52 126
- Ukentlige rapporter â 153 940
- Daglige rapporter â 628 153
- Visumgodkjenninger â 11 821
- Innkommende dokumenter â 79 677
- UtgĂ„ende dokumenter â 28 357
- OppfĂžringer om hendelser i brukernes arbeidskalendere â 168 228
- SĂžknader om budtjenester â 21 883
- Motparter â 81 029
- Motpartsarbeidsjournaler â 45 632
- Kontaktpersoner for motparter â 41 795
- Hendelser â 10 243
- Prosjekter â 6 320
- Ansattoppgaver â 245 980
- Foruminnlegg â 26 282
- Chatmeldinger â 891 095
- Forretningsprosesser â 109 056. Samhandling mellom ansatte skjer gjennom prosesser â godkjenning, utfĂžrelse, vurdering, registrering, signering osv. Vi mĂ„ler varigheten av prosesser, antall sykluser, antall deltakere, antall returer, antall forespĂžrsler om endring av frister. Og denne informasjonen er svĂŠrt nyttig Ă„ analysere for Ă„ forstĂ„ hvilke prosesser som foregĂ„r i bedriften og for Ă„ forbedre effektiviteten i de ansattes felles arbeid.
Hvilket utstyr bruker vi for Ă„ behandle alt dette?
Disse tallene indikerer et imponerende volum av oppgaver, sÄ vi sto overfor behovet for Ä allokere ganske produktivt utstyr til behovene til det interne DO. Per i dag er egenskapene som fÞlger: 38 kjerner, 240 GB RAM, 26 TB disker. Her er en tabell over servere:
I fremtiden planlegger vi Ä Þke kapasiteten pÄ utstyret.
Hvordan gÄr det med serverbelastningen?
Nettverksaktivitet har aldri vÊrt et problem for oss eller kundene vÄre. Som regel er det svake punktet prosessoren og diskene, fordi alle allerede vet hvordan man skal hÄndtere mangel pÄ minne. Her er skjermbilder av serverne vÄre fra Resource Monitor, som viser at vi ikke har noen forferdelig belastning, den er svÊrt beskjeden.
For eksempel, i skjermbildet nedenfor ser vi en SQL-server der CPU-en er lastet med 23 %. Og dette er en veldig god indikator (til sammenligning: hvis belastningen nĂŠrmer seg 70 %, vil ansatte mest sannsynlig oppleve ganske betydelige nedganger i arbeidet).
Det andre skjermbildet viser applikasjonsserveren som kjĂžrer 1C:Enterprise-plattformen â den betjener bare brukerĂžkter. Prosessorbelastningen er litt hĂžyere her â 38 %, den er jevn og stillegĂ„ende. Det er diskbelastning, men det er akseptabelt.
Det tredje skjermbildet viser en annen 1C:Enterprise-server (det er den andre, vi har to av dem i klyngen). Bare den forrige betjener brukere, og det er her roboter jobber. For eksempel mottar de e-post, ruter dokumenter, utfĂžrer datautveksling, beregner rettigheter osv. Alle disse bakgrunnsaktivitetene utfĂžres av omtrent 90â100 bakgrunnsoppgaver. Og denne serveren er veldig tungt belastet â med 88 %. Men dette pĂ„virker ikke folk, og den implementerer akkurat all automatiseringen som DokumenthĂ„ndtering skal gjĂžre.
Hva er mÄlepunktene for Ä bestemme ytelse?
Vi har et seriĂžst delsystem for mĂ„ling av ytelsesindikatorer og beregning av ulike mĂ„linger innebygd i vĂ„rt DO. Dette er nĂždvendig for Ă„ forstĂ„ bĂ„de i Ăžyeblikket og i et historisk perspektiv hva som skjer i systemet, hva som blir verre, hva som blir bedre. OvervĂ„kingsverktĂžy â mĂ„linger og tidsmĂ„linger â er inkludert i standardleveransen av «1C:DokumenthĂ„ndtering 8». MĂ„linger krever justering under implementeringen, men selve mekanismen er standard.
MÄlinger er mÄlinger av ulike forretningsindikatorer pÄ bestemte tidspunkter (for eksempel gjennomsnittlig postleveringstid pÄ 10 minutter).
En av mĂ„lingene viser antall aktive brukere i databasen. I gjennomsnitt er det 1000â1400 av dem i lĂžpet av dagen. Grafen viser at det var 2144 aktive brukere i databasen pĂ„ tidspunktet for skjermbildet.
Det finnes mer enn 30 slike handlinger, listen er under kuttet.Liste
- Logg Inn
- Logg ut
- Laster inn e-post
- Endring av et objekts virkelighet
- Endre tilgangsrettigheter
- Endring av emne for prosessen
- Endre objektets arbeidsgruppe
- Endring i settets sammensetning
- Endre fil
- Importer fil
- Sender via post
- Flytte filer
- Omdirigere en oppgave
- Signering av en EP
- SĂžk etter detaljer
- FulltekstsĂžk
- Motta en fil
- Prosessavbrudd
- gjennomgang
- Dekoding
- Dokumentregistrering
- skanning
- Fjerner slettemerket
- Opprette et objekt
- Lagre pÄ disk
- Starten av prosessen
- Slette brukerloggoppfĂžringer
- Fjerne en EP-signatur
- Sette et slettemerke
- Kryptering
- Eksporter mappe
Forrige uke Ăžkte den gjennomsnittlige brukeraktiviteten vĂ„r med halvannen gang (vist i rĂždt pĂ„ grafen) â dette skyldes overgangen til fjernarbeid for de fleste ansatte (i forbindelse med kjente hendelser). I tillegg Ăžkte antallet aktive brukere med tre ganger sĂ„ mye (vist i blĂ„tt pĂ„ skjermbildet), ettersom ansatte begynte Ă„ aktivt bruke mobil: hver mobilklient oppretter en forbindelse til serveren. NĂ„ har i gjennomsnitt hver av vĂ„re ansatte to forbindelser til serveren.
For oss, som administratorer, er dette et signal om at vi mĂ„ vĂŠre mer oppmerksomme pĂ„ ytelsesproblemer, for Ă„ se om ting har blitt verre. Og vi ser pĂ„ dette etter andre parametere. For eksempel hvordan leveringstiden for post endres via intern ruting (vist i blĂ„tt pĂ„ skjermbildet nedenfor). Vi ser at den hoppet opp og ned frem til i Ă„r, men nĂ„ er stabil â for oss er dette en indikator pĂ„ at alt er i orden med systemet.
En annen praktisk mĂ„lestokk for oss er gjennomsnittlig ventetid for nedlasting av brev fra e-postserveren (vist i rĂždt pĂ„ skjermbildet). Grovt sett, hvor lenge vil et brev vandre rundt pĂ„ Internett fĂžr det havner hos vĂ„r ansatte. Skjermbildet viser at denne tiden ikke har endret seg pĂ„ noen mĂ„te i det siste. Det er noen topper â men de er ikke relatert til forsinkelser, men til det faktum at tiden gĂ„r tapt pĂ„ e-postserverne.
Eller for eksempel en annen mĂ„leenhet (vist i blĂ„tt pĂ„ skjermbildet) â oppdatering av brev i en mappe. Ă
Ă„pne en brevmappe er en veldig hyppig operasjon, og det mĂ„ gjĂžres raskt. Vi mĂ„ler hvor raskt det gjĂžres. Denne indikatoren mĂ„les for hver klient. Du kan se bĂ„de helhetsbildet for selskapet og dynamikken, for eksempel, for en enkelt ansatt. Fra skjermbildet kan du se at mĂ„leenheten var ubalansert frem til i Ă„r, deretter gjorde vi en rekke forbedringer, og nĂ„ blir det ikke verre â nesten en flat graf.
MÄlinger er hovedsakelig et administratorverktÞy for Ä overvÄke systemet, for rask respons pÄ eventuelle endringer i systemets oppfÞrsel. Skjermbildet viser de interne DO-mÄlingene for Äret. Hoppet i grafene skyldes at vi fikk oppgaver med Ä utvikle den interne DO-en.
Her er en liste over noen flere mÄlinger (under snittet).
Beregninger
- Brukeraktivitet
- Aktive brukere
- Aktive prosesser
- Antall filer
- FilstĂžrrelse (MB)
- Antall dokumenter
- Antall objekter som skal sendes til mottakere
- Antall motparter
- Uoppfylte oppgaver
- Gjennomsnittlig ventetid for nedlasting av e-poster fra e-postserveren de siste 10 minuttene
- Ekstern databuffer: antall filer
- Grenseforsinkelse fra nÄvÊrende dato
- Lang kĂž
- DriftskĂž
- Alder pÄ rÄ konto etter ekstern ruting
- StÞrrelse pÄ intern rutegodkjenningskÞ (lang kÞ)
- StÞrrelse pÄ intern rutingsgodkjenningskÞ (rask kÞ)
- Leveringstid for post via intern ruting (lang kĂž)
- Leveringstid for post for intern ruting (rask kĂž)
- Leveringstid for post via ekstern ruting (gjennomsnitt)
- Antall dokumenter Bestilling
- Antall dokumenter FravĂŠr
- Antall dokumenter «Arbeidslogg med motpart»
- Post Oppdatering av brev i mappe
- Post Ă pne et brevkort
- Post Flytte et brev til en mappe
- E-post Naviger gjennom mapper
Systemet vÄrt mÄler mer enn 150 indikatorer dÞgnet rundt, men ikke alle kan spores raskt. De kan vÊre nyttige senere, i et historisk perspektiv, men du kan fokusere pÄ de viktigste for virksomheten.
For eksempel ble bare 5 indikatorer valgt for én av implementeringene. Kunden satte seg et mÄl om Ä lage et minimumssett med indikatorer, men samtidig slik at det dekket de viktigste arbeidsscenarioene. Det ville vÊre uberettiget Ä inkludere 150 indikatorer i akseptbeviset, fordi selv innad i bedriften er det vanskelig Ä bli enige om hvilke indikatorer som er akseptable. Men de kjente til disse 5 indikatorene og hadde allerede presentert dem for systemet fÞr starten av implementeringsprosjektet, inkludert dem i anbudsdokumentasjonen: kortÄpningstid ikke mer enn 3 sekunder, oppgaveutfÞrelsestid med en fil ikke mer enn 5 sekunder, osv. I vÄr DO hadde vi akkurat de beregningene som veldig tydelig gjenspeilet den opprinnelige forespÞrselen fra kundens tekniske spesifikasjoner.
Vi har ogsÄ en profilanalyse av ytelsesmÄlinger. Ytelsesindikatorer er registrering av varigheten av hver utfÞrte operasjon (skrive et brev til databasen, sende et brev til e-postserveren osv.). Dette brukes utelukkende av tekniske spesialister. Vi samler mange ytelsesindikatorer i programmet. For tiden mÄler vi omtrent 1500 nÞkkeloperasjoner, som er delt inn i profiler.
En av de viktigste profilene for oss er «Liste over viktige e-postmÄlinger fra et forbrukerperspektiv». Denne profilen inkluderer for eksempel fÞlgende mÄlinger:
- UtfĂžrer kommando: Velg etter tagg
- Ă pne skjemaet: Listeskjema
- UtfĂžrer kommando: Velg etter mappe
- Vise en bokstav i lesepanelet
- Lagre et brev i favorittmappen din
- SĂžk etter bokstaver etter detaljer
- Opprette et brev
Hvis vi ser at metrikken for en forretningsindikator har blitt for stor (for eksempel at brev fra en bestemt bruker har begynt Ä komme veldig sakte), begynner vi Ä finne ut av det, vi vender oss til mÄlingene av tiden for tekniske operasjoner. Vi har en teknisk operasjon "Arkivering av brev pÄ e-postserveren" - vi ser at tiden for denne operasjonen har blitt overskredet for den siste perioden. Denne operasjonen er igjen delt opp i andre operasjoner - for eksempel etablering av en forbindelse med e-postserveren. Vi ser at den av en eller annen grunn plutselig har blitt veldig stor (vi har alle mÄlingene for en mÄned - vi kan sammenligne at forrige uke var det 10 millisekunder, og nÄ er det 1000 millisekunder). Og vi forstÄr at noe er Þdelagt her - vi mÄ fikse det.
Hvordan vedlikeholder vi en sÄ stor database?
VÄr interne DO er et eksempel pÄ et reelt, fungerende hÞybelastningsprosjekt. Vi vil fortelle deg om de tekniske funksjonene i databasen.
Hvor lang tid tar det Ă„ omstrukturere store databasetabeller?
SQL-serveren krever periodisk vedlikehold, og det mĂ„ ryddes opp i tabellene. Ideelt sett bĂžr dette gjĂžres minst Ă©n gang om dagen, og for tabeller med hĂžy etterspĂžrsel â enda oftere. Men hvis databasen er stor (og antallet poster allerede har oversteget 11 milliarder), er det ikke lett Ă„ ta vare pĂ„ den.
Vi omstrukturerte tabeller for seks Är siden, men sÄ begynte det Ä ta sÄ mye tid at vi ikke fikk plass til nattintervallene. Og siden disse operasjonene belaster SQL-serveren tungt, kan den ikke betjene andre brukere godt.
SĂ„ nĂ„ mĂ„ vi bruke diverse triks. For eksempel kan vi ikke utfĂžre disse prosedyrene pĂ„ fullstendige datasett. Vi mĂ„ ty til prosedyren «Oppdater eksempel pĂ„ 500000 14 rader» â dette tar XNUMX minutter. Den oppdaterer ikke statistikk for alle dataene i tabellen, men velger en halv million rader og beregner statistikk for dem, som den bruker for hele tabellen. Dette er litt av en antagelse, men vi mĂ„ gjĂžre det, fordi for en spesifikk tabell vil det ta uakseptabelt lang tid Ă„ samle statistikk for alle Ă©n milliard poster.
Vi har ogsÄ optimalisert andre vedlikeholdsoperasjoner ved Ä gjÞre dem delvise.
Vedlikehold av DBMS er generelt sett en kompleks oppgave. Ved aktiv samhandling mellom ansatte vokser databasen raskt, og det blir vanskeligere og vanskeligere for administratorer Ă„ vedlikeholde den â Ă„ oppdatere statistikk, defragmentere, indeksere. Her er det nĂždvendig Ă„ bruke forskjellige strategier. Vi vet godt hvordan vi gjĂžr det, vi har erfaring, og vi kan dele den.
Hvordan implementeres sikkerhetskopiering for slike volumer?
En full sikkerhetskopi av DBMS-systemet tas én gang om dagen eller natten, og en trinnvis sikkerhetskopi tas hver time. En filkatalog opprettes ogsÄ hver dag, og den er en del av den trinnvise sikkerhetskopien av fillagringen.
Hvor lang tid tar en full sikkerhetskopiering?
En full sikkerhetskopiering til en harddisk tar tre timer, en delvis sikkerhetskopiering tar en time. Det tar lengre tid Ä skrive til tape (en spesiell enhet som lager en sikkerhetskopi til en spesiell kassett som er lagret utenfor kontoret; en avhendbar kopi lages pÄ tape, som vil bli lagret hvis for eksempel serveren brenner ned). Sikkerhetskopien lages nÞyaktig pÄ den samme serveren, hvis parametere var hÞyere - en SQL-server med 20 % prosessorbelastning. PÄ sikkerhetskopieringstidspunktet blir systemet selvfÞlgelig betydelig dÄrligere, men det er fortsatt operativt.
Finnes det deduplisering?
filer, vi tester det pÄ oss selv, og snart vil det bli inkludert i den nye versjonen av DokumenthÄndtering. Vi tester ogsÄ mekanismen for motpartsdeduplisering pÄ oss selv. Det er ingen deduplisering av poster pÄ DBMS-nivÄ, siden det ikke er behov for det. 1C:Enterprise-plattformen lagrer objekter i DBMS, og bare plattformen kan vÊre ansvarlig for deres konsistens.
Finnes det skrivebeskyttede noder?
Det finnes ingen lesende noder (dedikerte systemnoder som betjener de som trenger Ä motta data for lesing). DO er ikke et regnskapssystem som skal plasseres pÄ en egen BI-node, men det finnes en egen node for utviklingsavdelingen, som meldinger utveksles med i JSON-format, og den typiske replikeringstiden er enheter og titalls sekunder. Noden er fortsatt liten, den har omtrent 800 millioner poster, men den vokser raskt.
Og bokstavene som er merket for sletting, blir ikke slettet i det hele tatt?
Ikke ennÄ. Vi har ikke noe mÄl om Ä gjÞre databasen enklere. Det var flere alvorlige tilfeller der vi mÄtte fÄ tilgang til brev merket for sletting, inkludert de fra 2009. SÄ forelÞpig bestemte vi oss for Ä lagre alt. Men nÄr kostnadene ved dette blir uberettigede, vil vi vurdere Ä slette det. Men hvis vi trenger Ä slette et bestemt brev fra databasen for godt, slik at det ikke er spor, kan dette gjÞres ved spesiell forespÞrsel.
Hvorfor lagre dette? Finnes det statistikk over hvor mange ganger gamle dokumenter blir Ă„pnet?
Det finnes ingen statistikk. Mer presist, den finnes i form av en protokoll over brukerarbeid, men den lagres ikke lenge. OppfĂžringer eldre enn ett Ă„r slettes fra protokollen.
Det var situasjoner der det var nĂždvendig Ă„ hente frem gammel korrespondanse fra fem eller til og med ti Ă„r siden. Og dette ble alltid gjort, ikke av nysgjerrighet, men for Ă„ ta komplekse forretningsavgjĂžrelser. Det var tilfeller der feil forretningsavgjĂžrelse ville blitt tatt uten korrespondansehistorikken.
Hvordan utfĂžres verdivurdering og destruksjon av dokumenter i henhold til lagringsperioder?
For papirdokumenter gjĂžres dette pĂ„ vanlig tradisjonell mĂ„te, som alle andre. For elektroniske dokumenter gjĂžr vi det ikke â la dem bli lagret. Det er plass. Det er fordeler. Det er bra for alle.
Hva er utviklingsutsiktene?
For tiden lĂžser DO-en vĂ„r omtrent 30 interne oppgaver, noen av dem listet vi opp i begynnelsen av artikkelen. DO brukes ogsĂ„ til Ă„ forberede konferanser, som vi holder to ganger i Ă„ret for vĂ„re partnere: hele programmet, alle rapporter, alle parallelle seksjoner, haller â alt dette legges ut i DO, og lastes deretter ned fra den, og et trykt program lages.
Det er flere oppgaver som kommer for DO, i tillegg til de det allerede lÞser. Det finnes generelle bedriftsoppgaver, og det finnes unike og sjeldne, som bare trengs av en bestemt avdeling. Det er nÞdvendig Ä hjelpe dem, og derfor Ä utvide "geografien" for bruk av systemet innenfor 1C - Ä utvide bruksomrÄdet, Ä lÞse problemene til alle avdelinger. Dette ville vÊre den beste testen pÄ ytelse og pÄlitelighet. Jeg skulle gjerne sett at systemet fungerer pÄ billioner av poster, petabyte med informasjon.
Kilde: www.habr.com
