1C mes plačiai naudojame savo plėtrą įmonės darbui organizuoti. Visų pirma, . Be dokumentų valdymo (kaip rodo pavadinimas), tai dar ir šiuolaikiška -sistema (Enterprise Content Management – įmonės turinio valdymas) su plačiu funkcijų spektru – paštu, darbuotojų darbo kalendoriais, bendrinamos prieigos prie išteklių organizavimu (pavyzdžiui, susitikimų kambarių rezervacija), laiko sekimu, įmonių forumu ir dar daugiau.
1C dokumentų valdymu naudojasi daugiau nei tūkstantis darbuotojų. Duomenų bazė jau tapo įspūdinga (11 mlrd. įrašų), vadinasi, reikalauja kruopštesnės priežiūros ir galingesnės įrangos.
Kaip veikia mūsų sistema, su kokiais sunkumais susiduriame prižiūrėdami duomenų bazę ir kaip juos sprendžiame (kaip DBVS naudojame MS SQL Server) – papasakosime straipsnyje.
Tiems, kurie apie 1C produktus skaito pirmą kartą.
1C:Document Flow yra taikomųjų programų sprendimas (konfigūracija), įdiegtas remiantis verslo taikomųjų programų kūrimo sistema - 1C:Enterprise platforma.
„1C: Document Flow 8“ (sutrumpintai kaip DO) leidžia automatizuoti darbą su dokumentais įmonėje. Viena iš pagrindinių darbuotojų sąveikos įrankių yra el. Be pašto, DO taip pat išsprendžia kitas problemas:
- Laiko sekimas
- Darbuotojų nedarbo stebėjimas
- Paraiškos kurjeriams/transportui
- Darbuotojų darbo kalendoriai
- Korespondencijos registracija
- Darbuotojų kontaktai (adresų knyga)
- Įmonių forumas
- Kambario rezervacija
- Renginio planavimas
- CRM
- Kolektyvinis darbas su failais (su failų versijų išsaugojimu)
- ir kt.
Įeiname į dokumentų valdymą (savoji vykdomoji programa) iš „Windows“, „Linux“, „MacOS“, (iš naršyklių) ir - priklausomai nuo situacijos.
Ir dėka kito mūsų produkto, prijungto prie dokumentų srauto - – tiesiogiai „Document Flow“ gauname „Messenger“ funkcionalumą – pokalbius, garso ir vaizdo skambučius (įskaitant grupinius skambučius, kurie dabar tapo ypač svarbūs, taip pat ir iš mobiliojo kliento), greitą failų keitimąsi ir galimybę rašyti pokalbių robotus, kurie supaprastina darbas su sistema. Kitas sąveikos sistemos naudojimo pranašumas (lyginant su kitais pasiuntiniais) yra galimybė vesti kontekstines diskusijas, susietas su konkrečiais Dokumentų srauto objektais – dokumentais, įvykiais ir pan. Tai reiškia, kad sąveikos sistema yra giliai integruota su tiksline programa ir neveikia kaip tik „atskiras mygtukas“.
Mūsų DO raidžių skaičius jau viršijo 100 milijonų, o apskritai DBVS yra daugiau nei 11 milijardų įrašų. Iš viso sistema naudoja beveik 30 TB saugyklos vietos: duomenų bazės tūris yra 7,5 TB, rinkmenos kolektyviniam darbui saugomos atskirai ir užima dar 21 TB.
Jei kalbėsime apie konkretesnius skaičius, tai šiuo metu yra raidžių ir failų skaičius:
- Siunčiami elektroniniai laiškai – 14,7 mln.
- Gaunamų laiškų – 85,4 mln.
- Failų versijos – 70,8 mln.
- Vidaus dokumentai – 30,6 tūkst.
DO turi daugiau nei tik paštą ir failus. Toliau pateikiami kitų apskaitos objektų skaičiai:
- Užsakyti posėdžių sales – 52 126
- Savaitės ataskaitos – 153 940
- Dienos ataskaitos – 628 153
- Patvirtinimo vizos – 11 821
- Gaunamų dokumentų – 79 677
- Išsiunčiami dokumentai – 28 357
- Įrašai apie įvykius vartotojų darbo kalendoriuose – 168 228
- Prašymai kurjeriams – 21 883
- Sandorio šalys – 81 029
- Darbo su sandorio šalimis įrašai – 45 632
- Sandorio šalių kontaktiniai asmenys – 41 795
- Renginiai – 10 243
- Projektai – 6 320
- Darbuotojų užduotys – 245 980
- Forumo pranešimų – 26 282
- Pokalbių žinutės – 891 095
- Verslo procesai - 109 056. Sąveika tarp darbuotojų vyksta per procesus - patvirtinimą, vykdymą, peržiūrą, registraciją, pasirašymą ir kt. Matuojame procesų trukmę, ciklų skaičių, dalyvių skaičių, grąžinimų skaičių, prašymų pakeisti terminus skaičių. O šią informaciją labai naudinga išanalizuoti, norint suprasti, kokie procesai vyksta įmonėje ir padidinti darbuotojų bendradarbiavimo efektyvumą.
Kokia įranga visa tai apdorojame?
Šie skaičiai rodo įspūdingą užduočių apimtį, todėl susidūrėme su poreikiu skirti gana produktyvią įrangą vidaus dukterinių įmonių poreikiams. Šiuo metu jo charakteristikos yra tokios: 38 branduoliai, 240 GB RAM, 26 TB diskų. Čia yra serverių lentelė:
Ateityje planuojame padidinti įrangos pajėgumus.
Kaip sekasi su serverio apkrova?
Tinklo veikla niekada nebuvo problema nei mums, nei mūsų klientams. Paprastai silpnoji vieta yra procesorius ir diskai, nes visi jau žino, kaip susidoroti su atminties trūkumu. Čia yra mūsų serverių ekrano nuotraukos iš Resource Monitor, kurios rodo, kad mes neturime jokio baisaus krūvio, jis yra labai kuklus.
Pavyzdžiui, žemiau esančioje ekrano kopijoje matome SQL serverį, kuriame procesoriaus apkrova yra 23%. Ir tai yra labai geras rodiklis (palyginimui: jei apkrova artėja prie 70%, tada greičiausiai darbuotojai pastebės gana didelį darbo sulėtėjimą).
Antroje ekrano kopijoje parodytas programų serveris, kuriame veikia 1C:Enterprise platforma - ji aptarnauja tik vartotojo seansus. Čia procesoriaus apkrova kiek didesnė – 38%, sklandžiai ir ramiai. Diskas įkeliamas, bet tai priimtina.
Trečioje ekrano kopijoje rodomas kitas 1C: Enterprise serveris (tai antrasis, klasteryje turime du iš jų). Tik ankstesnis aptarnauja vartotojus, o prie šio dirba robotai. Pavyzdžiui, jie gauna paštą, maršruto dokumentus, keičiasi duomenimis, skaičiuoja teises ir pan. Visa ši foninė veikla atlieka maždaug 90–100 foninių darbų. Ir šis serveris yra labai stipriai apkrautas – 88%. Bet tai neturi įtakos žmonėms ir įgyvendina tiksliai visą automatizavimą, kurį turėtų atlikti Dokumentų valdymas.
Kokie yra našumo matavimo rodikliai?
Savo dukterinėse įmonėse turime rimtą posistemį veiklos rodikliams matuoti ir įvairiems rodikliams skaičiuoti. Tai būtina norint suprasti tiek dabartiniu laiko momentu, tiek iš istorinės perspektyvos, kas vyksta sistemoje, kas blogėja, kas gerėja. Stebėjimo įrankiai – metrika ir laiko matavimai – yra įtraukti į standartinį „1C: Document Flow 8“ pristatymą. Diegimo metu metriką reikia pritaikyti, tačiau pats mechanizmas yra standartinis.
Metrika – tai įvairių verslo rodiklių matavimai tam tikru momentu (pavyzdžiui, vidutinis pašto pristatymo laikas yra 10 minučių).
Viena iš metrikų rodo aktyvių vartotojų skaičių duomenų bazėje. Vidutiniškai per dieną jų būna 1000-1400. Diagrama rodo, kad ekrano kopijos metu duomenų bazėje buvo 2144 aktyvūs vartotojai.
Tokių veiksmų yra daugiau nei 30, sąrašas yra iškirptas.Sąrašas
- Prisijunkite prie sistemos
- Atsijungti
- Įkeliamas paštas
- Objekto galiojimo keitimas
- Prieigos teisių keitimas
- Proceso temos keitimas
- Objekto darbo grupės keitimas
- Rinkinio sudėties keitimas
- Failo keitimas
- Failų importas
- Siuntimas paštu
- Failų perkėlimas
- Užduoties peradresavimas
- Elektroninio parašo pasirašymas
- Ieškoti pagal detales
- Pilno teksto paieška
- Failo gavimas
- Proceso nutraukimas
- Peržiūra
- Iššifravimas
- Dokumento registracija
- Nuskaityti
- Panaikinama ištrynimo žyma
- Objekto kūrimas
- Išsaugomas diske
- Proceso pradžia
- Naudotojo žurnalo įrašų ištrynimas
- Elektroninio parašo pašalinimas
- Ištrynimo ženklo nustatymas
- Šifravimas
- Eksportuoti aplanką
Praėjusią savaitę mūsų vidutinis vartotojų aktyvumas išaugo pusantro karto (grafike rodomas raudonai) – taip yra dėl daugumos darbuotojų perėjimo prie nuotolinio darbo (dėl gerai žinomų įvykių). Taip pat 3 kartus išaugo aktyvių vartotojų skaičius (parodyta mėlynai ekrano kopijoje), nes darbuotojai pradėjo aktyviai naudotis mobiliaisiais telefonais: kiekvienas mobilusis klientas sukuria ryšį su serveriu. Dabar vidutiniškai kiekvienas mūsų darbuotojas turi 2 prisijungimus prie serverio.
Mums, administratoriams, tai signalas, kad turime būti dėmesingesni našumo problemoms ir žiūrėti, ar viskas nepablogėjo. Bet mes žiūrime į tai pagal kitus parametrus. Pavyzdžiui, kaip pasikeičia vidinio maršruto parinkimo pašto pristatymo laikas (parodyta mėlyna spalva toliau esančioje ekrano kopijoje). Matome, kad iki šių metų jis svyravo, bet dabar stabilus – mums tai yra rodiklis, kad su sistema viskas tvarkoje.
Kita mums taikoma metrika yra vidutinis laukimo laikas, kol atsisiunčiami laiškai iš pašto serverio (parodyta raudonai ekrano kopijoje). Grubiai tariant, kiek laiko laiškas sklandys internete, kol pasieks mūsų darbuotoją. Ekrano kopijoje matyti, kad šis laikas pastaruoju metu taip pat niekaip nepasikeitė. Yra pavienių spyglių – bet jie susiję ne su vėlavimais, o su tuo, kad pašto serveriuose prarandamas laikas.
Arba, pavyzdžiui, kita metrika (ekrano kopijoje rodoma mėlyna spalva) – aplanke esančių raidžių atnaujinimas. Pašto aplanko atidarymas yra labai įprasta operacija, kurią reikia atlikti greitai. Matuojame, kaip greitai tai atliekama. Šis rodiklis matuojamas kiekvienam klientui. Galite matyti ir bendrą vaizdą įmonei, ir dinamiką, pavyzdžiui, atskiram darbuotojui. Ekrano nuotraukoje matyti, kad iki šių metų metrika buvo nesubalansuota, vėliau atlikome nemažai patobulinimų, o dabar neblogėja – grafikas beveik plokščias.
Metrika iš esmės yra administratoriaus įrankis, skirtas stebėti sistemą, greitai reaguoti į bet kokius sistemos veikimo pokyčius. Ekrano kopijoje rodoma metų vidinė antrinė metrika. Grafikų šuolis atsirado dėl to, kad gavome užduotis plėtoti vidines antrines įmones.
Čia yra dar kelių metrikų sąrašas (po išpjova).
Metrika
- Vartotojo veikla
- Aktyvūs vartotojai
- Aktyvūs procesai
- Failų skaičius
- Failo dydis (MB)
- Dokumentų skaičius
- Objektų, kurie bus siunčiami gavėjams, skaičius
- Sandorio šalių skaičius
- Nebaigtos užduotys
- Vidutinis laukimo laikas atsisiunčiant el. laiškus iš pašto serverio per pastarąsias 10 minučių
- Išorinis duomenų buferis: failų skaičius
- Kraštinė vėluojama nuo dabartinės datos
- Ilga eilė
- Operatyvinė eilė
- Neapdorotas paskyros amžius pagal išorinį maršrutą
- Vidinio maršruto priėmimo eilės dydis (ilga eilė)
- Vidinio maršruto parinkimo priėmimo eilės dydis (greita eilė)
- Pašto pristatymo laikas naudojant vidinį maršrutą (ilga eilė)
- Pašto pristatymo laikas naudojant vidinį maršrutą (greita eilė)
- Pašto pristatymo laikas naudojant išorinį maršrutą (vidutinis)
- Dokumentų skaičius Rezervacija
- Dokumentų skaičius Nebuvimas
- Dokumentų „Darbo su kita šalimi įrašas“ skaičius
- Paštas Atnaujinti laiškus aplanke
- Paštas Laiško kortelės atidarymas
- Paštas Perkelkite laišką į aplanką
- Paštas Naršykite aplankuose
Mūsų sistema visą parą matuoja daugiau nei 150 rodiklių, tačiau ne visus juos galima greitai stebėti. Jie gali praversti vėliau, žvelgiant iš istorinės perspektyvos, ir galėsite sutelkti dėmesį į svarbiausius verslui.
Pavyzdžiui, viename iš įgyvendinimų buvo pasirinkti tik 5 rodikliai. Klientas užsibrėžė tikslą sukurti minimalų rodiklių rinkinį, bet tuo pačiu ir tokį, kuris apimtų pagrindinius darbo scenarijus. Į priėmimo aktą įtraukti 150 rodiklių būtų nepagrįsta, nes net įmonėje sunku susitarti, kurie rodikliai laikomi priimtinais. O apie šiuos 5 rodiklius jie žinojo ir jau buvo pateikę sistemai prieš įgyvendinimo projekto pradžią, įtraukdami į konkurso dokumentaciją: kortelės atplėšimo laikas ne daugiau kaip 3 sekundės, laikas atlikti užduotį su bylos Nr. daugiau nei 5 sekundes ir pan. Savo dukterinėse įmonėse turėjome metriką, kuri labai aiškiai atspindėjo pirminį kliento techninių specifikacijų prašymą.
Taip pat atliekame veiklos matavimų profilio analizę. Veiklos rodikliai – tai kiekvienos vykdomos operacijos trukmės fiksavimas (laiško rašymas į duomenų bazę, laiško siuntimas į pašto serverį ir pan.). Jį naudoja tik technikai. Savo programoje sukaupiame daug veiklos rodiklių. Šiuo metu matuojame maždaug 1500 pagrindinių operacijų, kurios yra suskirstytos į profilius.
Vienas iš svarbiausių mums profilių yra „Pagrindinių pašto rodiklių sąrašas vartotojų požiūriu“. Šis profilis apima, pavyzdžiui, šiuos rodiklius:
- Komandos vykdymas: Pasirinkite pagal žymą
- Formos atidarymas: Sąrašo forma
- Komandos vykdymas: Pasirinkite pagal aplanką
- Raidės rodymas skaitymo srityje
- Laiško išsaugojimas mėgstamame aplanke
- Ieškokite raidžių pagal detales
- Laiško kūrimas
Jei matome, kad kokio nors verslo rodiklio metrika tapo per didelė (pavyzdžiui, konkretaus vartotojo laiškai pradėjo gauti labai ilgai), pradedame tai išsiaiškinti ir pereiname prie techninių operacijų laiko matavimo. Atliekame techninę operaciją „Laiškų archyvavimas pašto serveryje“ – matome, kad šios operacijos laikas buvo viršytas paskutiniu laikotarpiu. Ši operacija, savo ruožtu, išskaidoma į kitas operacijas – pavyzdžiui, užmezgant ryšį su pašto serveriu. Matome, kad kažkodėl staiga pasidarė labai didelis (visus matavimus turime mėnesiui – galime palyginti, kad praeitą savaitę buvo 10 milisekundžių, o dabar – 1000 milisekundžių). Ir suprantame, kad čia kažkas sugedo – reikia taisyti.
Kaip išlaikyti tokią didelę duomenų bazę?
Mūsų vidinis DO yra tikrai veikiančio didelės apkrovos projekto pavyzdys. Pakalbėkime apie jo duomenų bazės technines savybes.
Kiek laiko užtrunka didelių duomenų bazių lentelių pertvarkymas?
SQL serveriui reikia periodinės priežiūros, sutvarkyti lenteles. Gerąja prasme tai turėtų būti daroma bent kartą per dieną, o didelės paklausos stalams – dar dažniau. Bet jei duomenų bazė didelė (o mūsų įrašų skaičius jau viršijo 11 mlrd.), tai rūpintis ja nėra lengva.
Prieš 6 metus atlikome stalo restruktūrizavimą, bet tada tai pradėjo užtrukti tiek daug laiko, kad nebetilpome į naktinius intervalus. Ir kadangi šios operacijos labai apkrauna SQL serverį, jis negali efektyviai aptarnauti kitų vartotojų.
Todėl dabar tenka pasitelkti įvairius triukus. Pavyzdžiui, negalime atlikti šių procedūrų su visais duomenų rinkiniais. Turite pasinaudoti 500000 14 eilučių pavyzdžio atnaujinimo procedūra – tai užtrunka XNUMX minučių. Ji neatnaujina visų lentelės duomenų statistikos, o atrenka pusę milijono eilučių ir naudoja jas visos lentelės statistikai apskaičiuoti. Tai tam tikra prielaida, bet esame priversti tai daryti, nes konkrečios lentelės statistikos rinkimas apie visą milijardą įrašų užtruks nepriimtinai ilgai.
Taip pat optimizavome kitas priežiūros operacijas, padarydami jas dalines.
DBVS priežiūra paprastai yra sudėtinga užduotis. Esant aktyviam darbuotojų sąveikai, duomenų bazė greitai auga, o administratoriams tampa vis sunkiau ją prižiūrėti – atnaujinti statistiką, defragmentuoti, indeksuoti. Čia reikia taikyti skirtingas strategijas, gerai žinome, kaip tai padaryti, turime patirties, galime ja pasidalinti.
Kaip tokiais kiekiais sukuriama atsarginė kopija?
Pilna DBVS atsarginė kopija atliekama kartą per dieną naktį, laipsniškas – kas valandą. Be to, kiekvieną dieną sukuriamas failų katalogas, kuris yra failų saugyklos atsarginės kopijos dalis.
Kiek laiko užtrunka sukurti visą atsarginę kopiją?
Visiška atsarginė kopija standžiajame diske sukuriama per tris valandas, dalinė – per valandą. Rašymas į juostą užtrunka ilgiau (specialus įrenginys, kuris daro atsarginę kopiją į specialią kasetę, saugomą ne biure; į juostą padaroma perkeliama kopija, kuri išsaugoma, jei, pavyzdžiui, sudegs serverio patalpa). Atsarginė kopija daroma lygiai tame pačiame serveryje, kurio parametrai buvo aukštesni – SQL serveris su 20% procesoriaus apkrova. Atsarginės kopijos kūrimo metu, žinoma, sistema tampa daug blogesnė, tačiau ji vis dar veikia.
Ar yra deduplikacijos?
Failų yra, išbandysime patys ir netrukus jie bus įtraukti į naują dokumentų valdymo versiją. Taip pat išbandome sandorio šalies dubliavimo panaikinimo mechanizmą. DBVS lygiu nėra įrašų dubliavimo panaikinimo, nes tai nėra būtina. 1C:Enterprise platforma saugo objektus DBVS ir tik platforma gali būti atsakinga už jų nuoseklumą.
Ar yra tik skaitomų mazgų?
Nėra skaitymo mazgų (skirtų sistemos mazgų, kurie aptarnauja tuos, kuriems reikia gauti kokius nors duomenis skaitymui). DO nėra apskaitos sistema, skirta atskiram BI mazgui, bet yra atskiras mazgas kūrimo skyriui, su kuriuo keičiamasi pranešimais JSON formatu, o tipinis replikacijos laikas yra vienetai ir dešimtys sekundžių. Mazgas vis dar mažas, jame yra apie 800 milijonų įrašų, tačiau jis sparčiai auga.
Ar ištrynimui pažymėti el. laiškai iš viso neištrinami?
Dar ne. Mes neturime užduoties padaryti pagrindo lengvesnį. Buvo keli gana rimti atvejai, kai reikėjo remtis išbraukti pažymėtomis raidėmis, tarp jų ir 2009 m. Todėl nusprendėme kol kas viską pasilikti. Bet kai to kaina taps nepagrįsta, pagalvosime apie pašalinimą. Bet jei jums reikia visiškai pašalinti atskirą laišką iš duomenų bazės, kad nebūtų pėdsakų, tai galima padaryti pagal specialų prašymą.
Kodėl jį saugoti? Ar turite statistiką apie prieigą prie senų dokumentų?
Statistikos nėra. Tiksliau, jis yra vartotojo žurnalo pavidalu, tačiau jis nėra saugomas ilgai. Senesni nei vienerių metų įrašai išbraukiami iš protokolo.
Būdavo situacijų, kai reikėdavo atgauti seną penkerių ar net dešimties metų senumo korespondenciją. Ir tai visada buvo daroma ne iš tuščio smalsumo, o siekiant priimti sudėtingus verslo sprendimus. Buvo atvejis, kai be susirašinėjimo istorijos būtų buvęs priimtas neteisingas verslo sprendimas.
Kaip įvertinama ir sunaikinama dokumentų vertė pagal saugojimo terminus?
Popieriniams dokumentams tai daroma įprastu tradiciniu būdu, kaip ir visiems kitiems. Mes to nedarome dėl elektroninių – tegul jie pasilieka juos sau. Sėdimas čia. Yra naudos. Visiems viskas gerai.
Kokios yra plėtros perspektyvos?
Dabar mūsų DO išsprendžia apie 30 vidinių problemų, kai kurias iš jų išvardinome straipsnio pradžioje. DL taip pat naudojamas ruošiant konferencijas, kurias rengiame du kartus per metus savo partneriams: visa programa, visos ataskaitos, visos lygiagrečios sekcijos, salės – visa tai surašoma į DL, tada iš jo atsisiunčiama ir atspausdinta programa. yra pagamintas.
Be tų, kurias jis jau sprendžia, DO laukia dar keletas užduočių. Yra visos įmonės užduočių, o yra unikalių ir retų, reikalingų tik konkrečiam skyriui. Būtina jiems padėti, o tai reiškia išplėsti sistemos naudojimo „geografiją“ 1C viduje - išplėsti taikymo sritį, išspręsti visų skyrių problemas. Tai būtų geriausias našumo ir patikimumo testas. Norėčiau, kad sistema veiktų su trilijonais įrašų, informacijos petabaitų.
Šaltinis: www.habr.com