1C-s kasutame ettevõtte töö korraldamiseks laialdaselt enda arendusi. Eriti, . Lisaks dokumendihaldusele (nagu nimigi ütleb) on see ka kaasaegne -süsteem (Enterprise Content Management – ettevõtte sisuhaldus) laia funktsionaalsusega – post, töötajate töökalendrid, ressurssidele jagatud juurdepääsu korraldamine (näiteks koosolekuruumide broneerimine), aja jälgimine, ettevõtte foorum ja palju muud.
Rohkem kui tuhat töötajat kasutab 1C-s dokumendihaldust. Andmebaas on muutunud juba muljetavaldavaks (11 miljardit kirjet), mis tähendab, et see nõuab hoolikamat hooldust ja võimsamat varustust.
Kuidas meie süsteem töötab, milliste raskustega me andmebaasi hooldamisel kokku puutume ja kuidas neid lahendame (DBMS-ina kasutame MS SQL Serverit) - sellest räägime teile artiklis.
Neile, kes loevad 1C toodete kohta esimest korda.
1C:Document Flow on rakenduslahendus (konfiguratsioon), mida rakendatakse ärirakenduste arendamise raamistiku - 1C:Enterprise platvormi - alusel.
“1C: Document Flow 8” (lühendatult DO) võimaldab teil ettevõttes dokumentidega tööd automatiseerida. Üks peamisi tööriistu töötajate suhtlemiseks on e-post. Lisaks postile lahendab DO ka muid probleeme:
- Aja jälgimine
- Töötajate puudumise jälgimine
- Taotlused kulleritele/transpordile
- Töötajate töökalendrid
- Kirjavahetuse registreerimine
- Töötajate kontaktid (aadressiraamat)
- Ettevõtete foorum
- Ruumi broneerimine
- Ürituste planeerimine
- CRM
- Kollektiivne töö failidega (koos failiversioonide salvestamisega)
- jne
Siseneme dokumendihaldusse (natiivne käivitatav rakendus) Windowsist, Linuxist, macOS-ist, (brauseritest) ja - olenevalt olukorrast.
Ja tänu meie teisele tootele, mis on ühendatud Document Flow'ga - – otse Document Flow’s saame messengeri funktsionaalsuse – vestlused, heli- ja videokõned (sh nüüd eriti oluliseks muutunud grupikõned, sh mobiilikliendilt), kiire failivahetus pluss võimalus kirjutada vestlusroboteid, mis lihtsustavad süsteemiga töötamine. Teine interaktsioonisüsteemi kasutamise eelis (võrreldes teiste sõnumitoojatega) on võimalus pidada kontekstuaalseid arutelusid, mis on seotud konkreetsete Dokumendivoo objektidega – dokumendid, sündmused jne. See tähendab, et interaktsioonisüsteem on sihtrakendusega sügavalt integreeritud ega toimi lihtsalt "eraldi nupuna".
Meie DO tähtede arv on juba ületanud 100 miljoni piiri ja üldiselt on DBMS-is üle 11 miljardi kirje. Kokku kasutab süsteem ligi 30 TB salvestusruumi: andmebaasi maht on 7,5 TB, kollektiivse töö faile hoitakse eraldi ja need võtavad enda alla veel 21 TB.
Kui rääkida konkreetsematest numbritest, siis siin on hetkel kirjade ja failide arv:
- Väljuvad meilid – 14,7 miljonit.
- Saabunud kirjad – 85,4 miljonit.
- Failiversioonid – 70,8 miljonit.
- Sisedokumendid – 30,6 tuh.
DO-l on rohkem kui lihtsalt kirjad ja failid. Allpool on toodud arvud muude raamatupidamisobjektide kohta:
- Koosolekuruumide broneerimine – 52 126
- Nädalaaruanded – 153 940
- Päevaaruanded – 628 153
- Kinnitusviisad – 11 821
- Saabuvad dokumendid – 79 677
- Väljaminevad dokumendid – 28 357
- Kirjed sündmuste kohta kasutajate töökalendrites – 168 228
- Avaldused kulleritele – 21 883
- Vastaspooled – 81 029
- Osapooltega töötamise arvestus – 45 632
- Osapoolte kontaktisikud – 41 795
- Sündmusi – 10 243
- Projektid – 6 320
- Töötaja ülesanded – 245 980
- Foorumi postitusi – 26 282
- Vestlussõnumid – 891 095
- Äriprotsessid - 109 056. Töötajate omavaheline suhtlus toimub protsesside kaudu - kinnitamine, täitmine, ülevaatamine, registreerimine, allkirjastamine jne. Mõõdame protsesside kestust, tsüklite arvu, osalejate arvu, tagastamiste arvu, tähtaegade muutmise taotluste arvu. Ja seda teavet on väga kasulik analüüsida, et mõista ettevõttes toimuvaid protsesse ja tõsta töötajate koostöö efektiivsust.
Millistel seadmetel me seda kõike töötleme?
Need arvud näitavad muljetavaldavat ülesannete mahtu, mistõttu seisime silmitsi vajadusega eraldada sisemiste tütarettevõtete vajadusteks üsna tootlikud seadmed. Praegu on selle omadused järgmised: 38 tuuma, 240 GB muutmälu, 26 TB kettaid. Siin on serverite tabel:
Tulevikus plaanime seadmete võimsust suurendada.
Kuidas serveri koormusega lood on?
Võrgutegevus pole meile ega meie klientidele kunagi probleemiks olnud. Reeglina on nõrgaks kohaks protsessor ja kettad, sest kõik teavad juba, kuidas mälupuudusega toime tulla. Siin on ekraanipildid meie serveritest Resource Monitorist, mis näitavad, et meil pole kohutavat koormust, see on väga tagasihoidlik.
Näiteks alloleval ekraanipildil näeme SQL-serverit, kus protsessori koormus on 23%. Ja see on väga hea näitaja (võrdluseks: kui koormus läheneb 70%, siis tõenäoliselt täheldavad töötajad töö üsna märkimisväärset aeglustumist).
Teisel ekraanipildil on näha rakendusserver, millel töötab platvorm 1C: Enterprise - see teenindab ainult kasutajaseansse. Siin on protsessori koormus veidi suurem - 38%, see on sujuv ja rahulik. Ketast laaditakse veidi, kuid see on vastuvõetav.
Kolmas ekraanipilt näitab teist 1C: Enterprise serverit (see on teine, meil on klastris kaks neist). Ainult eelmine teenindab kasutajaid ja selle kallal töötavad robotid. Näiteks saavad nad posti, marsruudi dokumente, vahetavad andmeid, arvutavad õigusi jne. Kõik need taustategevused täidavad ligikaudu 90-100 taustatööd. Ja see server on väga koormatud – 88%. Kuid see ei mõjuta inimesi ja see rakendab täpselt kogu automatiseerimise, mida dokumendihaldus peaks tegema.
Millised on toimivuse mõõtmise mõõdikud?
Meil on tütarettevõtetesse sisse ehitatud tõsine alamsüsteem tulemusnäitajate mõõtmiseks ja erinevate mõõdikute arvutamiseks. See on vajalik selleks, et mõista nii praegusel ajahetkel kui ka ajaloolisest vaatenurgast, mis süsteemis toimub, mis läheb hullemaks, mis läheb paremaks. Seirevahendid – mõõdikud ja ajamõõtmised – sisalduvad "1C: Document Flow 8" standardtarnes. Mõõdikud nõuavad rakendamise ajal kohandamist, kuid mehhanism ise on standardne.
Mõõdikud on erinevate ärinäitajate mõõtmised teatud ajahetkedel (näiteks keskmine posti kohaletoimetamise aeg on 10 minutit).
Üks mõõdikutest näitab aktiivsete kasutajate arvu andmebaasis. Keskmiselt on neid ööpäeva jooksul 1000-1400. Graafik näitab, et ekraanipildi tegemise hetkel oli andmebaasis 2144 aktiivset kasutajat.
Selliseid toiminguid on rohkem kui 30, nimekiri on lõike all.nimekiri
- Sisselogimine süsteemi
- Logi välja
- Kirja laadimine
- Objekti kehtivuse muutmine
- Juurdepääsuõiguste muutmine
- Protsessi teema muutmine
- Objekti töörühma muutmine
- Komplekti koostise muutmine
- Faili muutmine
- Failide import
- Postiga saatmine
- Failide teisaldamine
- Ülesande ümbersuunamine
- Elektroonilise allkirja allkirjastamine
- Otsige üksikasjade järgi
- Täisteksti otsing
- Faili vastuvõtmine
- Protsessi katkestamine
- Vaade
- Dekrüpteerimine
- Dokumendi registreerimine
- Skaneerimine
- Kustutamise märgistuse tühistamine
- Objekti loomine
- Salvestamine kettale
- Protsessi algus
- Kasutaja logikirjete kustutamine
- Elektroonilise allkirja eemaldamine
- Kustutusmärgi määramine
- Krüpteerimine
- Kausta eksportimine
Üle-eelmisel nädalal kasvas meie keskmine kasutajate aktiivsus poolteist korda (graafikul punaselt näidatud) - see on tingitud enamiku töötajate üleminekust kaugtööle (tuntud sündmuste tõttu). Samuti kasvas aktiivsete kasutajate arv 3 korda (näidatud ekraanipildil sinisega), kuna töötajad hakkasid aktiivselt mobiiltelefone kasutama: iga mobiiliklient loob ühenduse serveriga. Nüüd on igal meie töötajal serveriga keskmiselt 2 ühendust.
Meie kui administraatorite jaoks on see signaal, et peame olema jõudlusprobleemide suhtes tähelepanelikumad ja vaatama, kas asjad on hullemaks läinud. Kuid me vaatame seda muude parameetrite põhjal. Näiteks kuidas muutub sisemise marsruutimise posti kohaletoimetamise aeg (alloleval ekraanipildil sinisena). Näeme, et see oli kuni selle aastani kõikuv, kuid nüüd on see stabiilne - meie jaoks on see näitaja, et süsteemiga on kõik korras.
Teine meie jaoks rakendatav mõõdik on keskmine ooteaeg kirjade allalaadimisel meiliserverist (kuvatakse ekraanipildil punaselt). Jämedalt öeldes kui kaua kiri internetis vedeleb, enne kui see meie töötajani jõuab. Ekraanipilt näitab, et ka see aeg pole viimasel ajal kuidagi muutunud. On üksikuid naelu - kuid need ei ole seotud viivitustega, vaid sellega, et meiliserverites läheb aeg kaotsi.
Või näiteks mõni muu mõõdik (ekraanipildil sinisena) – tähtede värskendamine kaustas. Kirjakausta avamine on väga levinud toiming ja seda tuleb teha kiiresti. Mõõdame, kui kiiresti see täidetakse. Seda indikaatorit mõõdetakse iga kliendi kohta. Näha saab nii ettevõtte üldpilti kui ka dünaamikat näiteks üksiku töötaja puhul. Ekraanipilt näitab, et kuni selle aastani oli mõõdik tasakaalust väljas, siis tegime mitmeid täiustusi ja nüüd enam hullemaks ei lähe – graafik on peaaegu lame.
Mõõdikud on põhimõtteliselt administraatori tööriist süsteemi jälgimiseks, kiireks reageerimiseks süsteemi käitumise muutustele. Ekraanitõmmis näitab aasta sisemisi tütarettevõtte mõõdikuid. Hüpe graafikutes on tingitud sellest, et meile anti ülesanded sisemiste tütarettevõtete arendamiseks.
Siin on veel mõned mõõdikud (lõike all).
Mõõdikud
- Kasutaja tegevus
- Aktiivsed kasutajad
- Aktiivsed protsessid
- Failide arv
- Faili suurus (MB)
- Dokumentide arv
- Saajatele saadetavate objektide arv
- Osapoolte arv
- Lõpetamata ülesanded
- Keskmine ooteaeg meiliserverist allalaadimisel viimase 10 minuti jooksul
- Väline andmepuhver: failide arv
- Hilinenud piir praegusest kuupäevast
- Pikk järjekord
- Operatiivne järjekord
- Konto töötlemata vanus välise marsruutimise järgi
- Sisemise marsruudi aktsepteerimise järjekorra suurus (pikk järjekord)
- Sisemise marsruudi aktsepteerimise järjekorra suurus (kiire järjekord)
- Posti kohaletoimetamise aeg sisemise marsruudi kaudu (pikk järjekord)
- Posti kohaletoimetamise aeg sisemise marsruudi kaudu (kiire järjekord)
- Posti kohaletoimetamise aeg välise marsruudi kaudu (keskmine)
- Dokumentide arv Broneering
- Dokumentide arv Puudumine
- Dokumentide arv “Osupoolega töötamise dokument”
- Mail Uuenda kaustas olevaid kirju
- Post Kirjakaardi avamine
- Post Kirjade kausta ülekandmine
- Mail Liikuge kaustades
Meie süsteem mõõdab ööpäevaringselt üle 150 näitaja, kuid kõiki neid ei ole võimalik kiiresti jälgida. Need võivad hiljem mõnes ajaloolises perspektiivis kasuks tulla ja saate keskenduda ettevõtte jaoks kõige olulisematele.
Näiteks ühes teostuses valiti ainult 5 näitajat. Klient seadis eesmärgiks luua minimaalne näitajate kogum, kuid samas sellised, mis kataks peamised tööstsenaariumid. 150 näitaja lisamine vastuvõtuaktile oleks põhjendamatu, sest isegi ettevõtte sees on raske kokku leppida, milliseid näitajaid peetakse vastuvõetavaks. Ja nad teadsid nendest 5 näitajast ja olid need juba enne rakendusprojekti algust süsteemile esitanud, lisades need konkursi dokumentatsiooni: kaardi avamise aeg mitte rohkem kui 3 sekundit, aeg ülesande täitmiseks failiga nr. rohkem kui 5 sekundit jne. Meie tütarettevõtetes olid meil mõõdikud, mis peegeldasid väga selgelt kliendi tehnilistes kirjeldustes esitatud algset taotlust.
Meil on ka jõudlusmõõtmiste profiilianalüüs. Jõudlusnäitajad on iga käimasoleva toimingu (kirja kirjutamine andmebaasi, kirja saatmine meiliserverisse jne) kestuse salvestamine. Seda kasutavad ainult tehnikud. Kogume oma programmi palju tulemusnäitajaid. Praegu mõõdame ligikaudu 1500 võtmetoimingut, mis on jagatud profiilideks.
Üks meie jaoks kõige olulisemaid profiile on "Posti põhinäitajate loend tarbija vaatenurgast". See profiil sisaldab näiteks järgmisi näitajaid:
- Käsu täitmine: valige sildi järgi
- Vormi avamine: Loendivorm
- Käsu täitmine: valige kausta järgi
- Tähe kuvamine lugemisalal
- Kirja salvestamine lemmikkausta
- Otsige tähti üksikasjade järgi
- Kirja koostamine
Kui näeme, et mõne ärinäitaja mõõdik on muutunud liiga suureks (näiteks konkreetse kasutaja kirjad on hakanud saabuma väga pikka aega), hakkame seda välja mõtlema ja asume mõõtma tehniliste toimingute aega. Meil on tehniline toiming “Kirjade arhiveerimine meiliserveris” - näeme, et selle toimingu aeg on viimase perioodi jooksul ületatud. See toiming jaotatakse omakorda muudeks toiminguteks – näiteks meiliserveriga ühenduse loomiseks. Näeme, et see on millegipärast järsku väga suureks läinud (meil on kuu aega kõik mõõtmised olemas – saame võrrelda, et eelmisel nädalal oli see 10 millisekundit ja nüüd on see 1000 millisekundit). Ja me mõistame, et siin on midagi katki – me peame selle parandama.
Kuidas hoida nii suurt andmebaasi?
Meie sisemine DO on näide tõeliselt toimivast suure koormusega projektist. Räägime selle andmebaasi tehnilistest omadustest.
Kui kaua võtab aega suurte andmebaasitabelite ümberstruktureerimine?
SQL-server vajab perioodilist hooldust, tabelite korrastamist. Heas mõttes tuleks seda teha vähemalt kord päevas ja suure nõudlusega laudade puhul veelgi sagedamini. Aga kui andmebaas on suur (ja meie kirjete arv on juba ületanud 11 miljardi piiri), siis pole selle eest hoolitsemine lihtne.
Tegime 6 aastat tagasi tabeli ümberkorraldamise, kuid siis hakkas see nii palju aega võtma, et me ei mahtunud enam öistesse vahedesse. Ja kuna need toimingud koormavad SQL-serverit tugevalt, ei saa see teisi kasutajaid tõhusalt teenindada.
Seetõttu peame nüüd kasutama erinevaid nippe. Näiteks ei saa me neid protseduure läbi viia täielike andmekogumitega. Peate kasutama 500000 14 rea proovi värskendamise protseduuri – selleks kulub XNUMX minutit. See ei värskenda statistikat kõigi tabeli andmete kohta, vaid valib pool miljonit rida ja kasutab neid kogu tabeli jaoks kasutatava statistika arvutamiseks. See on mõningane oletus, kuid oleme sunnitud seda tegema, sest konkreetse tabeli puhul võtab statistika kogumine kogu miljardi kirje kohta lubamatult kaua aega.
Samuti optimeerisime teisi hooldustoiminguid, muutes need osaliseks.
DBMS-i hooldamine on üldiselt keeruline ülesanne. Töötajate vahelise aktiivse suhtluse korral kasvab andmebaas kiiresti ning administraatoritel muutub selle pidamine – statistika uuendamine, defragmentimine, indekseerimine – järjest keerulisemaks. Siin tuleb rakendada erinevaid strateegiaid, me teame hästi, kuidas seda teha, meil on kogemusi, saame seda jagada.
Kuidas selliste mahtude puhul varundamist teostatakse?
DBMS-i täielik varukoopia tehakse üks kord päevas öösel, järkjärguline - iga tund. Samuti luuakse iga päev failikataloog ja see on osa failimälu varunduskoopiast.
Kui kaua kulub täieliku varukoopia tegemiseks?
Täielik varundamine kõvakettale valmib kolme tunniga, osaline varukoopia tunniga. Lindile kirjutamine võtab kauem aega (spetsiaalne seade, mis teeb varukoopia väljaspool kontorit hoiustatavale spetsiaalsele kassetile; lindile tehakse teisaldatav koopia, mis säilib näiteks serveriruumi põlemisel). Varukoopia tehakse täpselt samas serveris, mille parameetrid olid kõrgemad - 20% protsessori koormusega SQL server. Varundamise ajal muutub süsteem muidugi palju hullemaks, kuid see on endiselt funktsionaalne.
Kas on olemas deduplikatsioon?
Faile on olemas, me testime seda ise ja peagi lisatakse see dokumendihalduse uude versiooni. Testime ka vastaspoole dubleerimise mehhanismi. DBMS-i tasemel kirjete dubleerimist ei toimu, kuna see pole vajalik. 1C:Enterprise platvorm salvestab objektid DBMS-i ja ainult platvorm saab vastutada nende järjepidevuse eest.
Kas on olemas kirjutuskaitstud sõlmed?
Puuduvad lugemissõlmed (spetsiaalsed süsteemisõlmed, mis teenindavad neid, kes peavad lugemiseks andmeid vastu võtma). DO ei ole raamatupidamissüsteem, mida eraldi BI-sõlme peale panna, vaid arendusosakonna jaoks on eraldi sõlm, millega JSON-vormingus sõnumeid vahetatakse ning tüüpiline replikatsiooniaeg on ühikud ja kümned sekundid. Sõlm on endiselt väike, sellel on umbes 800 miljonit kirjet, kuid see kasvab kiiresti.
Kas kustutamiseks märgitud e-kirju ei kustutata üldse?
Mitte veel. Meil ei ole ülesannet alust kergemaks muuta. Oli mitmeid üsna tõsiseid juhtumeid, kus oli vaja viidata kustutamisele märgitud kirjadele, sealhulgas 2009. a. Seetõttu otsustasimegi, et jätame praegu kõik alles. Aga kui selle maksumus muutub põhjendamatuks, siis mõtleme eemaldamisele. Aga kui teil on vaja eraldi kirja andmebaasist täielikult eemaldada, et jälgi ei oleks, saate seda teha erisoovi korral.
Miks seda säilitada? Kas teil on statistikat juurdepääsu kohta vanadele dokumentidele?
Statistika puudub. Täpsemalt on see kasutajalogi kujul, kuid seda ei säilitata kaua. Üle aasta vanemad kanded kustutatakse protokollist.
Oli olukordi, kus tuli välja otsida vana viie või isegi kümne aasta tagune kirjavahetus. Ja seda tehti alati mitte tühisest uudishimust, vaid keeruliste äriotsuste tegemiseks. Oli juhus, kus ilma kirjavahetuse ajaloota oleks tehtud vale äriotsus.
Kuidas dokumentide väärtust hinnatakse ja hävitatakse hoiutähtaegade järgi?
Paberdokumentide puhul tehakse seda tavapärasel traditsioonilisel viisil, nagu kõik teisedki. Me ei tee seda elektrooniliste jaoks – las nad jätavad need endale. Istumiskoht on siin. Kasu on. Kõik on hästi.
Millised on arenguväljavaated?
Nüüd lahendab meie DO umbes 30 sisemist probleemi, millest mõned loetlesime artikli alguses. DL-i kasutatakse ka konverentside ettevalmistamiseks, mida korraldame oma partneritele kaks korda aastas: kogu programm, kõik aruanded, kõik paralleelsed sektsioonid, saalid - kõik see sisestatakse DL-i ja seejärel laaditakse sealt alla ning trükitakse programm. on tehtud.
DO jaoks on teel veel mitu ülesannet, lisaks neile, mida see juba lahendab. On ettevõtteüleseid ülesandeid ning unikaalseid ja haruldasi, mida vajab ainult konkreetne osakond. Neid on vaja aidata, mis tähendab 1C-s süsteemi kasutamise “geograafia” laiendamist - rakendusala laiendamist, kõigi osakondade probleemide lahendamist. See oleks parim jõudluse ja töökindluse test. Tahaksin näha, et süsteem töötaks triljonite kirjete, petabaitide teabe peal.
Allikas: www.habr.com