We controleren zelf: hoe 1C wordt ingezet en hoe het wordt beheerd: Documentenstroom binnen het 1C-bedrijf

Bij 1C maken we veel gebruik van onze eigen ontwikkelingen om het werk van het bedrijf te organiseren. In het bijzonder, "1C: Documentstroom 8". Naast documentbeheer (zoals de naam al doet vermoeden) is het ook een modern programma ECM-systeem (Enterprise Content Management - corporate content management) met een breed scala aan functionaliteit - e-mail, werkagenda's van medewerkers, het organiseren van gedeelde toegang tot bronnen (bijvoorbeeld het boeken van vergaderruimtes), tijdregistratie, bedrijfsforum en nog veel meer.

Ruim duizend medewerkers maken bij 1C gebruik van documentbeheer. De database is al indrukwekkend geworden (11 miljard records), wat betekent dat er meer zorgvuldige zorg en krachtigere apparatuur voor nodig is.

Hoe ons systeem werkt, welke problemen we tegenkomen bij het onderhouden van de database en hoe we deze oplossen (we gebruiken MS SQL Server als DBMS) - we vertellen het u in het artikel.

Voor degenen die voor het eerst over 1C-producten lezen.
1C:Document Flow is een applicatieoplossing (configuratie) geïmplementeerd op basis van een raamwerk voor het ontwikkelen van bedrijfsapplicaties - het 1C:Enterprise-platform.

Met “1C: Document Flow 8” (afgekort als DO) kunt u het werk met documenten in een onderneming automatiseren. Een van de belangrijkste hulpmiddelen voor interactie met medewerkers is e-mail. Naast post lost DO ook andere problemen op:

• абочего емени
• Verzuimregistratie van medewerkers
• Aanvragen voor koeriers/transport
• Werkkalenders van medewerkers
• Registratie van correspondentie
• Contactpersonen van medewerkers (adresboek)
• Bedrijfsforum
• Kamer reservatie
• Evenement planning
• CRM
• Collectief werken met bestanden (met opslaan van bestandsversies)
• и др.

We komen in Documentbeheer dunne cliënt (native uitvoerbare applicatie) van Windows, Linux, macOS, web cliënt (van browsers) en mobiele klant - afhankelijk van de situatie.

En dankzij ons andere product dat is aangesloten op Document Flow - Interactie systeem – we ontvangen direct in Document Flow de functionaliteit van de messenger – chats, audio- en videogesprekken (inclusief groepsgesprekken, wat nu vooral belangrijk is geworden, ook vanaf een mobiele client), snelle bestandsuitwisseling plus de mogelijkheid om chatbots te schrijven die het vereenvoudigen werken met het systeem. Een ander voordeel van het gebruik van het interactiesysteem (vergeleken met andere boodschappers) is de mogelijkheid om contextuele discussies te voeren die verband houden met specifieke Document Flow-objecten - documenten, gebeurtenissen, enz. Dat wil zeggen dat het interactiesysteem diep geïntegreerd is met de doeltoepassing en niet slechts als een “afzonderlijke knop” fungeert.

Het aantal letters in onze DO heeft de 100 miljoen al overschreden, en over het algemeen zijn er meer dan 11 miljard records in het DBMS. In totaal gebruikt het systeem bijna 30 TB aan opslagruimte: het databasevolume is 7,5 TB, bestanden voor collectief werk worden afzonderlijk opgeslagen en nemen nog eens 21 TB in beslag.

Als we het over specifiekere cijfers hebben, is hier het aantal brieven en bestanden op dit moment:

• Uitgaande e-mails – 14,7 miljoen.
• Inkomende brieven – 85,4 miljoen.
• Bestandsversies – 70,8 miljoen.
• Interne documenten – 30,6 duizend.

DO heeft meer dan alleen mail en bestanden. Hieronder vindt u de cijfers voor andere boekhoudobjecten:

• Vergaderzalen boeken – 52
• Wekelijkse rapporten – 153
• Dagelijkse rapporten – 628
• Goedkeuring visa – 11
• Inkomende documenten – 79
• Uitgaande documenten – 28
• Vermeldingen over gebeurtenissen in de werkagenda's van gebruikers – 168
• Aanvragen voor koeriers – 21
• Tegenpartijen – 81
• Gegevens over werkzaamheden met tegenpartijen – 45
• Contactpersonen van tegenpartijen – 41
• Evenementen – 10
• Projecten – 6
• Werknemerstaken – 245
• Forumberichten – 26
• Chatberichten – 891 095
• Bedrijfsprocessen - 109 Interactie tussen werknemers vindt plaats via processen - goedkeuring, uitvoering, beoordeling, registratie, ondertekening, enz. We meten de duur van processen, het aantal cycli, het aantal deelnemers, het aantal retouren, het aantal verzoeken om deadlines te wijzigen. En deze informatie is erg handig om te analyseren om te begrijpen welke processen er in de onderneming plaatsvinden en om de efficiëntie van de samenwerking tussen medewerkers te vergroten.

Op welke apparatuur verwerken we dit allemaal?

Deze cijfers duiden op een indrukwekkend aantal taken, dus we werden geconfronteerd met de noodzaak om redelijk productieve apparatuur toe te wijzen voor de behoeften van interne dochterondernemingen. Momenteel zijn de kenmerken als volgt: 38 cores, 240 GB RAM, 26 TB aan schijven. Hier is een tabel met servers:


In de toekomst zijn we van plan de capaciteit van de apparatuur te vergroten.

Hoe gaat het met de serverbelasting?

Netwerkactiviteit is voor ons en onze klanten nooit een probleem geweest. Het zwakke punt is in de regel de processor en de schijven, omdat iedereen al weet hoe om te gaan met een gebrek aan geheugen. Hier zijn screenshots van onze servers van Resource Monitor, die laten zien dat we geen vreselijke belasting hebben, het is heel bescheiden.

In de onderstaande schermafbeelding zien we bijvoorbeeld een SQL-server waarbij de CPU-belasting 23% is. En dit is een zeer goede indicator (ter vergelijking: als de belasting 70% nadert, zullen werknemers hoogstwaarschijnlijk behoorlijk aanzienlijke vertragingen in het werk waarnemen).

De tweede schermafbeelding toont de applicatieserver waarop het 1C:Enterprise-platform draait - deze bedient alleen gebruikerssessies. Hier is de processorbelasting iets hoger - 38%, het is soepel en rustig. Er is enige schijfbelasting, maar dit is acceptabel.

De derde schermafbeelding toont nog een 1C:Enterprise-server (het is de tweede, we hebben er twee in de cluster). Alleen de vorige bedient gebruikers, en hier werken robots aan. Ze ontvangen bijvoorbeeld post, routeren documenten, wisselen gegevens uit, berekenen rechten, etc. Al deze achtergrondactiviteiten vervullen ongeveer 90-100 achtergrondbanen. En deze server is erg zwaar belast: 88%. Maar dit heeft geen gevolgen voor mensen, en het implementeert precies alle automatisering die Document Management zou moeten doen.

Wat zijn de statistieken om prestaties te meten?

We hebben een serieus subsysteem ingebouwd in onze dochterondernemingen voor het meten van prestatie-indicatoren en het berekenen van verschillende statistieken. Dit is nodig om zowel op het huidige moment als vanuit historisch perspectief te begrijpen wat er in het systeem gebeurt, wat erger wordt, wat beter wordt. Monitoringtools - statistieken en tijdmetingen - zijn inbegrepen in de standaardlevering van "1C: Document Flow 8". De statistieken vereisen maatwerk tijdens de implementatie, maar het mechanisme zelf is standaard.

Statistieken zijn metingen van verschillende bedrijfsindicatoren op bepaalde tijdstippen (de gemiddelde bezorgtijd van post bedraagt ​​bijvoorbeeld 10 minuten).

Een van de statistieken toont het aantal actieve gebruikers in de database. Gemiddeld zijn het er overdag 1000-1400. Uit de grafiek blijkt dat er op het moment van de schermafbeelding 2144 actieve gebruikers in de database waren.

Er zijn meer dan 30 van dergelijke acties, de lijst staat onder de snede.Lijst

• Log in
• Afmelden
• E-mail laden
• De geldigheid van een object wijzigen
• Toegangsrechten wijzigen
• Het onderwerp van een proces veranderen
• De werkgroep van een object wijzigen
• De samenstelling van de kit wijzigen
• Een bestand wijzigen
• Bestand importeren
• Per post verzenden
• Bestanden verplaatsen
• Een taak omleiden
• Het ondertekenen van de elektronische handtekening
• Zoek op details
• Zoek volledige text
• Een bestand ontvangen
• Het onderbreken van een proces
• recensie
• Decryptie
• Documentregistratie
• scannen
• Markering van verwijdering ongedaan maken
• Een object maken
• Opslaan op schijf
• Begin van het proces
• Gebruikerslogboekvermeldingen verwijderen
• Een elektronische handtekening verwijderen
• Een verwijdermarkering instellen
• Encryptie
• Exporteer een map

Vorige week is onze gemiddelde gebruikersactiviteit anderhalf keer toegenomen (rood weergegeven in de grafiek) - dit komt door de overgang van de meeste medewerkers naar werken op afstand (als gevolg van bekende gebeurtenissen). Ook is het aantal actieve gebruikers drie keer zo groot geworden (in het blauw weergegeven op de schermafbeelding), omdat werknemers mobiele telefoons actief begonnen te gebruiken: elke mobiele client maakt een verbinding met de server. Nu heeft elk van onze medewerkers gemiddeld 3 verbindingen met de server.

Voor ons als beheerders is dit een signaal dat we meer aandacht moeten besteden aan prestatieproblemen en moeten kijken of de zaken nog erger zijn geworden. Maar we bekijken dit op basis van andere parameters. Bijvoorbeeld hoe de postbezorgtijd voor interne routing verandert (blauw weergegeven in onderstaande schermafbeelding). We zien dat het tot dit jaar fluctueerde, maar nu is het stabiel - voor ons is dit een indicator dat alles in orde is met het systeem.

Een andere toegepaste maatstaf voor ons is de gemiddelde wachttijd voor het downloaden van brieven van de mailserver (in rood weergegeven in de schermafbeelding). Hoe lang zal de brief grofweg op internet rondzwerven voordat deze onze medewerker bereikt? Uit de schermafbeelding blijkt dat deze tijd de laatste tijd ook op geen enkele manier is veranderd. Er zijn geïsoleerde pieken, maar deze houden geen verband met vertragingen, maar met het feit dat de tijd op de mailservers verloren gaat.

Of bijvoorbeeld een andere statistiek (blauw weergegeven in de schermafbeelding) – het bijwerken van letters in een map. Het openen van een e-mailmap is een veel voorkomende handeling en moet snel worden uitgevoerd. We meten hoe snel het wordt uitgevoerd. Deze indicator wordt per cliënt gemeten. Je ziet zowel het totaalbeeld van het bedrijf als de dynamiek van bijvoorbeeld een individuele medewerker. De schermafbeelding laat zien dat de metriek tot dit jaar uit balans was, daarna hebben we een aantal verbeteringen aangebracht en nu wordt het niet erger: de grafiek is bijna vlak.

Metrieken zijn in feite een hulpmiddel voor de beheerder om het systeem te monitoren en snel te reageren op eventuele veranderingen in het gedrag van het systeem. De schermafbeelding toont de interne dochterondernemingstatistieken voor het jaar. De sprong in de grafieken is te danken aan het feit dat we de opdracht kregen om interne dochterondernemingen te ontwikkelen.

Hier is een lijst met nog meer statistieken (onder de snede).
statistieken

• Gebruikersactiviteit
• Actieve gebruikers
• Actieve processen
• Aantal bestanden
• Bestandsgrootte (MB)
• Aantal documenten
• Aantal objecten dat naar ontvangers moet worden verzonden
• Aantal tegenpartijen
• Onvoltooide taken
• Gemiddelde wachttijd voor het downloaden van e-mails van de mailserver gedurende de afgelopen 10 minuten
• Externe databuffer: aantal bestanden
• Achterblijvende grens vanaf de huidige datum
• Lange wachtrij
• Operationele wachtrij
• Ruwe accountleeftijd door externe routering
• Grootte van wachtrij voor acceptatie van interne routering (lange wachtrij)
• Grootte van wachtrij voor acceptatie van interne routering (snelle wachtrij)
• Postbezorgtijd via interne routing (lange wachtrij)
• Postbezorgtijd via interne routing (snelle wachtrij)
• Postbezorgtijd via externe routing (gemiddeld)
• Aantal documenten Reservering
• Aantal documenten Afwezigheid
• Aantal documenten “Record van werkzaamheden met wederpartij”
• Mail Update brieven in een map
• Post Een briefkaart openen
• E-mail Een brief overbrengen naar een map
• E-mail Navigeer door mappen

Ons systeem meet 150 uur per dag meer dan XNUMX indicatoren, maar ze kunnen niet allemaal snel worden gemonitord. Ze kunnen later, vanuit een historisch perspectief, van pas komen en u kunt zich concentreren op de belangrijkste voor het bedrijf.

In één van de implementaties zijn bijvoorbeeld slechts 5 indicatoren geselecteerd. De klant stelde zich ten doel een minimale set indicatoren te creëren, maar tegelijkertijd zodanig dat deze de belangrijkste werkscenario's besloeg. Het zou onterecht zijn om 150 indicatoren op te nemen in het acceptatiecertificaat, omdat het zelfs binnen de onderneming lastig is om het eens te worden over welke indicatoren als acceptabel worden beschouwd. En ze kenden deze 5 indicatoren en hadden ze al vóór de start van het implementatieproject aan het systeem gepresenteerd, inclusief ze in de wedstrijddocumentatie: de tijd om een ​​kaart te openen is niet meer dan 3 seconden, de tijd om een ​​taak te voltooien een bestand duurt niet langer dan 5 seconden, enz. In onze dochterondernemingen beschikten we over meetgegevens die heel duidelijk het oorspronkelijke verzoek uit de technische specificaties van de klant weerspiegelden.

Ook beschikken wij over een profielanalyse van prestatiemetingen. Prestatie-indicatoren zijn een registratie van de duur van elke lopende operatie (een brief schrijven naar de database, een brief sturen naar een mailserver, enz.). Dit wordt uitsluitend gebruikt door technici. We verzamelen veel prestatie-indicatoren in ons programma. Momenteel meten we ongeveer 1500 sleuteloperaties, onderverdeeld in profielen.

Een van de belangrijkste profielen voor ons is de ‘Lijst met sleutelindicatoren van post vanuit consumentenperspectief’. Dit profiel omvat bijvoorbeeld de volgende indicatoren:

• Het commando uitvoeren: Selecteer op tag
• Een formulier openen: Lijstformulier
• Het commando uitvoeren: Selecteer op map
• Een letter weergeven in het leesgedeelte
• Een brief opslaan in uw favoriete map
• Zoek naar letters op details
• Een brief maken

Als we zien dat de maatstaf voor een bepaalde bedrijfsindicator te groot is geworden (brieven van een bepaalde gebruiker komen bijvoorbeeld al heel lang binnen), beginnen we dit uit te zoeken en gaan we over tot het meten van de tijd van technische handelingen. We hebben een technische operatie "Brieven archiveren op een mailserver" - we zien dat de tijd voor deze operatie de afgelopen periode is overschreden. Deze bewerking wordt op zijn beurt ontleed in andere bewerkingen, bijvoorbeeld het tot stand brengen van een verbinding met een mailserver. We zien dat het om de een of andere reden plotseling erg groot is geworden (we hebben alle metingen voor een maand - we kunnen vergelijken dat het vorige week 10 milliseconden was, en nu is het 1000 milliseconden). En we begrijpen dat er hier iets kapot is - we moeten het repareren.

Hoe onderhouden we zo’n grote database?

Onze interne DO is een voorbeeld van een echt werkend high-load project. Laten we het hebben over de technische kenmerken van de database.

Hoe lang duurt het om grote databasetabellen te herstructureren?

De SQL-server heeft periodiek onderhoud nodig, waardoor de tabellen op orde komen. Op een goede manier zou dit minstens één keer per dag moeten worden gedaan, en zelfs vaker voor tafels waar veel vraag naar is. Maar als de database groot is (en ons aantal records al de 11 miljard heeft overschreden), dan is het niet eenvoudig om er voor te zorgen.

We hebben zes jaar geleden een tafelherstructurering uitgevoerd, maar toen begon het zoveel tijd te kosten dat we niet langer in de nachtelijke intervallen pasten. En omdat deze handelingen de SQL-server zwaar belasten, kan deze andere gebruikers niet efficiënt bedienen.

Daarom moeten we nu verschillende trucs gebruiken. We kunnen deze procedures bijvoorbeeld niet uitvoeren op volledige datasets. U moet uw toevlucht nemen tot de procedure Voorbeeld 500000 rijen bijwerken - dit duurt 14 minuten. Het werkt de statistieken niet bij over alle gegevens in de tabel, maar selecteert een half miljoen rijen en gebruikt deze om statistieken te berekenen die voor de hele tabel worden gebruikt. Dit is een aanname, maar we zijn genoodzaakt deze te maken, omdat het verzamelen van statistieken over het hele miljard records voor een specifieke tabel onaanvaardbaar lang zal duren.

Ook andere onderhoudswerkzaamheden hebben we geoptimaliseerd door deze gedeeltelijk te maken.

Het onderhouden van een DBMS is over het algemeen een complexe taak. In het geval van actieve interactie tussen werknemers groeit de database snel en wordt het voor beheerders steeds moeilijker om deze te onderhouden - statistieken bijwerken, defragmentatie, indexering. Hier moeten we verschillende strategieën toepassen, we weten goed hoe we dit moeten doen, we hebben ervaring, we kunnen die delen.

Hoe wordt back-up geïmplementeerd met dergelijke volumes?

Er wordt één keer per dag en 's nachts een volledige DBMS-back-up uitgevoerd, een incrementele back-up elk uur. Bovendien wordt er elke dag een bestandsmap gemaakt, die deel uitmaakt van de incrementele back-up van de bestandsopslag.

Hoe lang duurt het om een ​​volledige back-up te maken?

Een volledige back-up op een harde schijf is in drie uur voltooid, een gedeeltelijke back-up in een uur. Het duurt langer om naar tape te schrijven (een speciaal apparaat dat een reservekopie maakt naar een speciale cassette die buiten het kantoor is opgeslagen; er wordt een overdraagbare kopie naar de tape gemaakt, die bewaard blijft als bijvoorbeeld de serverruimte afbrandt). De back-up wordt gemaakt op exact dezelfde server, waarvan de parameters hoger waren: een SQL-server met een processorbelasting van 20%. Op het moment dat er een back-up wordt gemaakt, wordt het systeem natuurlijk veel slechter, maar het is nog steeds functioneel.

Is er sprake van deduplicatie?

Ontdubbeling Er zijn bestanden, we gaan het op onszelf testen en binnenkort wordt het opgenomen in de nieuwe versie van Document Management. We testen ook het deduplicatiemechanisme van de tegenpartij. Er vindt geen ontdubbeling van records op DBMS-niveau plaats, aangezien dit niet nodig is. Het 1C:Enterprise-platform slaat objecten op in het DBMS en alleen het platform kan verantwoordelijk zijn voor de consistentie ervan.

Zijn er alleen-lezen knooppunten?

Er zijn geen leesknooppunten (specifieke systeemknooppunten die degenen bedienen die gegevens moeten ontvangen om te kunnen lezen). DO is geen boekhoudsysteem om op een apart BI-knooppunt te zetten, maar er is een apart knooppunt voor de ontwikkelafdeling, waarmee berichten in JSON-formaat worden uitgewisseld, en de typische replicatietijd bedraagt ​​eenheden en tientallen seconden. Het knooppunt is nog steeds klein, het heeft ongeveer 800 miljoen records, maar groeit snel.

Worden e-mails die zijn gemarkeerd voor verwijdering helemaal niet verwijderd?

Nog niet. Het is niet onze taak om de basis lichter te maken. Er waren verschillende tamelijk ernstige gevallen waarin het nodig was om te verwijzen naar brieven die waren gemarkeerd voor verwijdering, waaronder 2009. Daarom hebben we besloten om alles voorlopig te behouden. Maar als de kosten hiervan ongerechtvaardigd worden, zullen we nadenken over verwijdering. Maar als u een afzonderlijke brief volledig uit de database wilt verwijderen zodat er geen sporen meer zijn, dan kan dit op speciaal verzoek worden gedaan.

Waarom opslaan? Heeft u statistieken over de toegang tot oude documenten?

Er zijn geen statistieken. Om precies te zijn, het heeft de vorm van een gebruikerslogboek, maar het wordt niet lang bewaard. Inzendingen ouder dan een jaar worden uit het protocol verwijderd.

Er waren situaties waarin het nodig was om oude correspondentie van vijf of zelfs tien jaar geleden op te halen. En dit gebeurde altijd niet uit ijdele nieuwsgierigheid, maar om complexe zakelijke beslissingen te nemen. Er was een geval waarin zonder correspondentiegeschiedenis een verkeerde zakelijke beslissing zou zijn genomen.

Hoe wordt de waarde van documenten beoordeeld en vernietigd op basis van de bewaartermijnen?

Voor papieren documenten gebeurt dit, net als iedereen, op de gebruikelijke traditionele manier. We doen het niet voor elektronische apparaten - laat ze ze voor zichzelf houden. De zit is hier. Er zijn voordelen. Iedereen maakt het goed.

Welke ontwikkelingsperspectieven zijn er?

Nu lost onze DO ongeveer 30 interne problemen op, waarvan we er enkele aan het begin van het artikel hebben genoemd. De DL wordt ook gebruikt om conferenties voor te bereiden die we twee keer per jaar houden voor onze partners: het hele programma, alle rapporten, alle parallelle secties, zalen - dit alles wordt in de DL getypt en vervolgens daaruit gedownload, en een afgedrukt programma is gemaakt.

Er staan ​​nog een aantal taken op stapel voor de DO, naast de taken die al worden opgelost. Er zijn bedrijfsbrede taken, en er zijn unieke en zeldzame taken, die alleen nodig zijn voor een specifieke afdeling. Het is noodzakelijk om hen te helpen, wat betekent dat de "geografie" van het gebruik van het systeem binnen 1C wordt uitgebreid - het toepassingsgebied wordt uitgebreid en de problemen van alle afdelingen worden opgelost. Dit zou de beste test zijn voor prestaties en betrouwbaarheid. Ik zou graag zien dat het systeem werkt met biljoenen records, petabytes aan informatie.

Bron: www.habr.com