Hos 1C bruker vi mye vår egen utvikling for å organisere selskapets arbeid. Spesielt, . I tillegg til dokumenthåndtering (som navnet tilsier), er det også en moderne -system (Enterprise Content Management - corporate content management) med et bredt spekter av funksjonalitet - post, arbeidskalendere for ansatte, organisering av delt tilgang til ressurser (for eksempel booking av møterom), tidsregistrering, bedriftsforum og mye mer.
Mer enn tusen ansatte bruker dokumenthåndtering ved 1C. Databasen har allerede blitt imponerende (11 milliarder poster), noe som betyr at den krever mer forsiktig pleie og kraftigere utstyr.
Hvordan systemet vårt fungerer, hvilke vanskeligheter vi møter når vi vedlikeholder databasen og hvordan vi løser dem (vi bruker MS SQL Server som DBMS) - vi vil fortelle deg i artikkelen.
For de som leser om 1C-produkter for første gang.
1C:Document Flow er en applikasjonsløsning (konfigurasjon) implementert på grunnlag av et rammeverk for utvikling av forretningsapplikasjoner - 1C:Enterprise-plattformen.
"1C: Document Flow 8" (forkortet DO) lar deg automatisere arbeid med dokumenter i en bedrift. Et av hovedverktøyene for medarbeidersamhandling er e-post. I tillegg til post, løser DO også andre problemer:
- Tidssporing
- Ansattes fraværssporing
- Søknader om bud/transport
- Arbeidskalendere for ansatte
- Registrering av korrespondanse
- Ansattkontakter (adressebok)
- Bedriftsforum
- Romreservasjon
- Arrangementsplanlegging
- CRM
- Kollektivt arbeid med filer (med lagring av filversjoner)
- etc.
Vi går inn i Dokumenthåndtering (innfødt kjørbar applikasjon) fra Windows, Linux, macOS, (fra nettlesere) og - avhengig av situasjonen.
Og takket være vårt andre produkt koblet til Document Flow - – vi direkte i Document Flow mottar funksjonaliteten til messengeren – chatter, lyd- og videosamtaler (inkludert gruppesamtaler, som nå har blitt spesielt viktig, blant annet fra en mobilklient), rask filutveksling pluss muligheten til å skrive chat-roboter som forenkler arbeider med systemet. En annen fordel med å bruke interaksjonssystemet (sammenlignet med andre budbringere) er muligheten til å gjennomføre kontekstuelle diskusjoner knyttet til spesifikke Document Flow-objekter - dokumenter, hendelser, etc. Det vil si at interaksjonssystemet er dypt integrert med målapplikasjonen, og fungerer ikke bare som en "separat knapp".
Antall brev i vår DO har allerede passert 100 millioner, og generelt 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 opptar ytterligere 21 TB.
Hvis vi snakker om mer spesifikke tall, her er antall bokstaver og filer for øyeblikket:
- Utgående e-poster – 14,7 millioner.
- Innkommende brev – 85,4 millioner.
- Filversjoner – 70,8 millioner.
- Interne dokumenter – 30,6 tusen.
DO har mer enn bare e-post og filer. Nedenfor er tallene for andre regnskapsobjekter:
- Booking av møterom – 52
- Ukentlige rapporter – 153
- Dagsrapporter – 628
- Godkjenningsvisum – 11 821
- Innkommende dokumenter – 79
- Utgående dokumenter – 28
- Oppføringer om hendelser i brukerarbeidskalendere – 168 228
- Søknader for bud – 21
- Motparter – 81
- Registrering av arbeid med motparter – 45
- Kontaktpersoner til motparter – 41
- Hendelser – 10 243
- Prosjekter – 6
- Arbeidstakeroppgaver – 245
- Foruminnlegg – 26
- Chatmeldinger – 891 095
- Forretningsprosesser - 109 056. Samhandling mellom ansatte skjer gjennom prosesser - godkjenning, utførelse, gjennomgang, registrering, signering m.m. Vi måler varigheten av prosesser, antall sykluser, antall deltakere, antall returer, antall forespørsler om å endre tidsfrister. Og denne informasjonen er veldig nyttig å analysere for å forstå hvilke prosesser som finner sted i bedriften og øke effektiviteten av medarbeidersamarbeid.
Hvilket utstyr behandler vi alt dette på?
Disse tallene indikerer et imponerende volum av oppgaver, så vi ble møtt med behovet for å allokere ganske produktivt utstyr for behovene til interne datterselskaper. For øyeblikket er dens egenskaper 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 våre kunder. Som regel er det svake punktet prosessoren og diskene, fordi alle allerede vet hvordan de 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 veldig beskjeden.
For eksempel, i skjermbildet nedenfor ser vi en SQL-server hvor CPU-belastningen er 23%. Og dette er en veldig god indikator (til sammenligning: hvis belastningen nærmer seg 70%, vil ansatte mest sannsynlig observere ganske betydelige nedganger i arbeidet).
Det andre skjermbildet viser applikasjonsserveren som 1C:Enterprise-plattformen kjører på - den betjener kun brukersesjoner. Her er prosessorbelastningen litt høyere - 38%, den er jevn og rolig. Det er noe disklasting, 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 roboter jobber med denne. De mottar for eksempel post, rutedokumenter, utveksler data, beregner rettigheter m.m. Alle disse bakgrunnsaktivitetene utfører omtrent 90-100 bakgrunnsjobber. Og denne serveren er veldig tungt lastet - 88%. Men dette påvirker ikke folk, og det implementerer akkurat all automatiseringen som Document Management skal gjøre.
Hva er beregningene for å måle ytelse?
Vi har et seriøst delsystem innebygd i datterselskapene våre for måling av ytelsesindikatorer og beregning av ulike beregninger. Dette er nødvendig for å forstå både i det aktuelle øyeblikket og fra et historisk perspektiv hva som skjer i systemet, hva som blir verre, hva som blir bedre. Overvåkingsverktøy - metrikk og tidsmålinger - er inkludert i standardleveransen av "1C: Document Flow 8". Beregningene krever tilpasning under implementering, men selve mekanismen er standard.
Beregninger er målinger av ulike forretningsindikatorer på bestemte tidspunkt (for eksempel er gjennomsnittlig postleveringstid 10 minutter).
En av beregningene viser antall aktive brukere i databasen. I gjennomsnitt er det 1000-1400 av dem i løpet av dagen. Grafen viser at på tidspunktet for skjermbildet var det 2144 aktive brukere i databasen.
Det er mer enn 30 slike handlinger, listen er under kuttet.Liste
- Logg Inn
- Logg ut
- Laster e-post
- Endre gyldigheten til et objekt
- Endring av tilgangsrettigheter
- Endre emnet for en prosess
- Endre et objekts arbeidsgruppe
- Endre sammensetningen av settet
- Endre en fil
- Filimport
- Sender med post
- Flytte filer
- Omdirigere en oppgave
- Signering av elektronisk signatur
- Søk etter detaljer
- Fulltekstsøk
- Mottar en fil
- Avbryte en prosess
- gjennomgang
- Dekryptering
- Dokumentregistrering
- skanning
- Fjerner merking av sletting
- Opprette et objekt
- Lagrer til disk
- Start av prosessen
- Sletting av brukerloggoppføringer
- Fjerne en elektronisk signatur
- Sette et slettemerke
- Kryptering
- Eksporter en mappe
Uken før sist økte vår gjennomsnittlige brukeraktivitet med en og en halv gang (vist i rødt på grafen) – dette skyldes overgangen til de fleste ansatte til fjernarbeid (på grunn av kjente hendelser). Antall aktive brukere økte også med 3 ganger (vist i blått på skjermbildet), da ansatte begynte å aktivt bruke mobiltelefoner: hver mobilklient oppretter en tilkobling til serveren. Nå har hver av våre ansatte i gjennomsnitt 2 tilkoblinger til serveren.
For oss som administratorer er dette et signal om at vi må være mer oppmerksomme på ytelsesproblemer og se om ting har blitt verre. Men vi ser på dette ut fra andre parametere. For eksempel hvordan postleveringstiden for intern ruting endres (vist i blått i skjermbildet nedenfor). Vi ser at det var svingende frem til i år, men nå er det stabilt – for oss er dette en indikator på at alt er i orden med systemet.
En annen anvendt beregning for oss er gjennomsnittlig ventetid for nedlasting av brev fra e-postserveren (vist i rødt på skjermbildet). Grovt sett, hvor lenge vil brevet flyte rundt på Internett før det når vår medarbeider. Skjermbildet viser at denne tiden heller ikke har endret seg på noen måte i det siste. Det er isolerte pigger – men de er ikke forbundet med forsinkelser, men med at tiden på mailserverne går tapt.
Eller for eksempel en annen beregning (vist i blått på skjermbildet) – oppdatering av bokstaver i en mappe. Å åpne en postmappe er en veldig vanlig operasjon og må gjøres raskt. Vi måler hvor raskt det utføres. Denne indikatoren måles for hver klient. Du kan se både helhetsbildet for bedriften og dynamikken, for eksempel for en enkelt ansatt. Skjermbildet viser at inntil i år var metrikken ubalansert, da gjorde vi en rekke forbedringer, og nå blir det ikke verre – grafen er nesten flat.
Beregninger er i utgangspunktet et administratorverktøy for å overvåke systemet, for raskt å svare på eventuelle endringer i systemets oppførsel. Skjermbildet viser interne datterselskapsberegninger for året. Hoppet i grafene skyldes at vi fikk oppgaver med å utvikle interne datterselskaper.
Her er en liste over noen flere beregninger (under snittet).
Beregninger
- Brukeraktivitet
- Aktive brukere
- Aktive prosesser
- Antall filer
- Filstørrelse (MB)
- Antall dokumenter
- Antall objekter som skal sendes til mottakere
- Antall motparter
- Uferdige oppgaver
- Gjennomsnittlig ventetid for nedlasting av e-post fra e-postserveren de siste 10 minuttene
- Ekstern databuffer: antall filer
- Lagrende kant fra gjeldende dato
- Lang kø
- Driftskø
- Rå kontoalder ved ekstern ruting
- Intern ruting aksept køstørrelse (lang kø)
- Intern ruting aksept køstørrelse (rask kø)
- Postleveringstid via intern ruting (lang kø)
- Postleveringstid via intern ruting (rask kø)
- Postleveringstid via ekstern ruting (gjennomsnittlig)
- Antall dokumenter Reservasjon
- Antall dokumenter Fravær
- Antall dokumenter "Protokoll over arbeid med motpart"
- Mail Oppdater bokstaver i en mappe
- Post Åpne et brevkort
- Mail Overfør 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 overvåkes raskt. De kan komme til nytte senere, i et eller annet historisk perspektiv, og du kan fokusere på de viktigste for virksomheten.
I en av implementeringene ble for eksempel kun 5 indikatorer valgt. Kunden satte et mål om å lage et minimumssett med indikatorer, men samtidig slik at det dekket de viktigste arbeidsscenarioene. Det vil være uberettiget å inkludere 150 indikatorer i akseptbeviset, fordi det selv innenfor virksomheten er vanskelig å bli enige om hvilke indikatorer som anses som akseptable. Og de visste om disse 5 indikatorene og hadde allerede presentert dem for systemet før starten av implementeringsprosjektet, inkludert dem i konkurransedokumentasjonen: tid for å åpne et kort ikke mer enn 3 sekunder, tid for å fullføre en oppgave med filnr. mer enn 5 sekunder osv. I våre datterselskaper hadde vi beregninger som veldig tydelig reflekterte den opprinnelige forespørselen fra kundens tekniske spesifikasjoner.
Vi har også en profilanalyse av resultatmålinger. Ytelsesindikatorer er en registrering av varigheten av hver pågående operasjon (skrive et brev til databasen, sende et brev til en e-postserver, etc.). Denne brukes utelukkende av teknikere. Vi samler mange ytelsesindikatorer i programmet vårt. Vi måler i dag cirka 1500 nøkkeloperasjoner, som er delt inn i profiler.
En av de viktigste profilene for oss er "Liste over nøkkelindikatorer for post fra et forbrukerperspektiv." Denne profilen inkluderer for eksempel følgende indikatorer:
- Utføre kommandoen: Velg etter tag
- Åpne et skjema: Listeskjema
- Utføre kommandoen: Velg etter mappe
- Viser en bokstav i leseområdet
- Lagre et brev i favorittmappen din
- Søk etter bokstaver etter detaljer
- Opprette et brev
Hvis vi ser at beregningen for en eller annen forretningsindikator har blitt for stor (for eksempel har brev fra en bestemt bruker begynt å ankomme i svært lang tid), begynner vi å finne ut av det og går over til å måle tidspunktet for tekniske operasjoner. Vi har en teknisk operasjon "Arkivere brev på en e-postserver" - vi ser at tiden for denne operasjonen er overskredet for den siste perioden. Denne operasjonen blir på sin side dekomponert i andre operasjoner - for eksempel å etablere en forbindelse med en e-postserver. Vi ser at den av en eller annen grunn plutselig har blitt veldig stor (vi har alle målene i en måned – vi kan sammenligne at forrige uke var den 10 millisekunder, og nå er den 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 virkelig fungerende høybelastningsprosjekt. La oss snakke om de tekniske funksjonene til databasen.
Hvor lang tid tar det å omstrukturere store databasetabeller?
SQL-serveren krever periodisk vedlikehold, og setter tabellene i orden. På en god måte bør dette gjøres minst en gang om dagen, og enda oftere for høye etterspørselsbord. Men hvis databasen er stor (og vårt antall poster har allerede passert 11 milliarder), så er det ikke lett å ta vare på den.
Vi gjorde en bordrestrukturering for 6 år siden, men så begynte det å ta så mye tid at vi ikke lenger passet inn i nattintervallene. Og siden disse operasjonene belaster SQL-serveren tungt, kan den ikke betjene andre brukere effektivt.
Derfor må vi nå bruke forskjellige triks. For eksempel kan vi ikke utføre disse prosedyrene på komplette datasett. Du må ty til prosedyren for Update Sample 500000 rader - dette tar 14 minutter. Den oppdaterer ikke statistikk på alle dataene i tabellen, men velger en halv million rader og bruker dem til å beregne statistikk som den bruker for hele tabellen. Dette er en antagelse, men vi er tvunget til å gjøre det, for for en bestemt tabell vil det ta uakseptabelt lang tid å samle statistikk på hele milliarden.
Vi optimaliserte også andre vedlikeholdsoperasjoner ved å gjøre dem delvise.
Å vedlikeholde et DBMS er generelt en vanskelig oppgave. Ved aktiv interaksjon mellom ansatte vokser databasen raskt, og det blir stadig vanskeligere for administratorer å vedlikeholde den – oppdatering av statistikk, defragmentering, indeksering. Her må vi bruke ulike strategier, vi vet godt hvordan vi gjør dette, vi har erfaring, vi kan dele den.
Hvordan implementeres backup med slike volumer?
En full DBMS-sikkerhetskopi utføres én gang om dagen om natten, en trinnvis én – hver time. Dessuten opprettes en filkatalog hver dag, og den er en del av den inkrementelle sikkerhetskopieringen av fillagringen.
Hvor lang tid tar det å fullføre en fullstendig sikkerhetskopi?
En fullstendig sikkerhetskopi til en harddisk er fullført på tre timer, en delvis sikkerhetskopiering på en time. Det tar lengre tid å skrive til bånd (en spesiell enhet som lager en sikkerhetskopi til en spesiell kassett som er lagret utenfor kontoret; det lages en overførbar kopi til båndet, som vil bli bevart hvis f.eks. serverrommet brenner ned). Sikkerhetskopieringen er laget på nøyaktig samme server, hvis parametere var høyere - en SQL-server med 20% prosessorbelastning. På tidspunktet for sikkerhetskopiering blir systemet selvfølgelig mye dårligere, men det er fortsatt funksjonelt.
Er det deduplisering?
Det er filer, vi tester det på oss selv, og snart vil det bli inkludert i den nye versjonen av Document Management. Vi tester også ut motpartsdedupliseringsmekanismen. Det er ingen deduplisering av poster på DBMS-nivå, siden dette ikke er nødvendig. 1C:Enterprise-plattformen lagrer objekter i DBMS, og bare plattformen kan være ansvarlig for deres konsistens.
Er det skrivebeskyttede noder?
Det er ingen lesenoder (dedikerte systemnoder som betjener de som trenger å motta data for lesing). DO er ikke et regnskapssystem for å sette på en egen BI-node, men det er 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.
Blir ikke e-poster merket for sletting slettet i det hele tatt?
Ikke ennå. Vi har ikke som oppgave å gjøre basen lettere. Det var flere ganske alvorlige tilfeller der det var nødvendig å vise til brev merket for sletting, inkludert 2009. Derfor bestemte vi oss for å beholde alt inntil videre. Men når kostnaden for dette blir uberettiget, vil vi tenke fjerning. Men hvis du trenger å fjerne et eget brev fra databasen helt slik at det ikke er spor, kan dette gjøres ved spesiell forespørsel.
Hvorfor lagre det? Har du statistikk over tilgang til gamle dokumenter?
Det finnes ingen statistikk. Mer presist er den i form av en brukerlogg, men den lagres ikke lenge. Oppføringer eldre enn ett år slettes fra protokollen.
Det var situasjoner da det var nødvendig å hente gammel korrespondanse fra fem eller ti år siden. Og dette ble alltid gjort, ikke av inaktiv nysgjerrighet, men for å ta komplekse forretningsbeslutninger. Det var et tilfelle der en feil forretningsavgjørelse ville blitt tatt uten korrespondansehistorikk.
Hvordan vurderes og destrueres verdien av dokumenter i henhold til oppbevaringsperioder?
For papirdokumenter gjøres dette på vanlig tradisjonell måte, som alle andre. Vi gjør det ikke for elektroniske - la dem beholde dem for seg selv. Sitten er her. Det er fordeler. Alle har det bra.
Hvilke utviklingsmuligheter er det?
Nå løser vår DO rundt 30 interne problemer, noen av dem har vi listet opp i begynnelsen av artikkelen. DL 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 skrives opp i DL, og lastes deretter ned fra det, og et trykt program er laget.
Det er flere oppgaver på vei for DO, i tillegg til de som den allerede løser. Det er virksomhetsomfattende oppgaver, og det er unike og sjeldne, som kun trengs av en bestemt avdeling. Det er nødvendig å hjelpe dem, noe som betyr å utvide "geografien" for å bruke systemet innen 1C - utvide anvendelsesområdet, løse problemene til alle avdelinger. Dette ville være den beste testen for ytelse og pålitelighet. Jeg vil gjerne se at systemet fungerer på billioner av poster, petabyte med informasjon.
Kilde: www.habr.com