V 1C široce využíváme vlastní vývoj k organizaci práce společnosti. Zejména, . Kromě správy dokumentů (jak název napovídá) jde také o moderní -systém (Enterprise Content Management - správa firemního obsahu) se širokou škálou funkcí - pošta, pracovní kalendáře zaměstnanců, organizování sdíleného přístupu ke zdrojům (například rezervace zasedacích místností), sledování času, firemní fórum a mnoho dalšího.
Správa dokumentů ve společnosti 1C využívá více než tisíc zaměstnanců. Databáze se již stala působivou (11 miliard záznamů), což znamená, že vyžaduje pečlivější péči a výkonnější zařízení.
Jak náš systém funguje, s jakými potížemi se při údržbě databáze setkáváme a jak je řešíme (jako DBMS používáme MS SQL Server) - to vám povíme v článku.
Pro ty, kteří čtou o produktech 1C poprvé.
1C:Document Flow je aplikační řešení (konfigurace) implementované na bázi frameworku pro vývoj podnikových aplikací - platforma 1C:Enterprise.
„1C: Document Flow 8“ (zkráceně DO) umožňuje automatizovat práci s dokumenty v podniku. Jedním z hlavních nástrojů pro interakci zaměstnanců je e-mail. Kromě pošty řeší DO také další problémy:
- Sledování času
- Sledování nepřítomnosti zaměstnanců
- Aplikace pro kurýry/dopravu
- Pracovní kalendáře zaměstnanců
- Evidence korespondence
- Kontakty na zaměstnance (adresář)
- Firemní fórum
- Rezervace pokoje
- Plánování akce
- CRM
- Hromadná práce se soubory (s ukládáním verzí souborů)
- et al.
Vstupujeme do správy dokumentů (nativní spustitelná aplikace) z Windows, Linux, macOS, (z prohlížečů) a - podle situace.
A díky našemu dalšímu produktu připojenému k Document Flow - – přímo v Document Flow získáváme funkce messengeru – chaty, audio a video hovory (včetně skupinových hovorů, které se nyní stalo obzvláště důležité, včetně z mobilního klienta), rychlá výměna souborů plus možnost psát chatovací roboty, které zjednodušují práci se systémem. Další výhodou používání Interaction System (ve srovnání s jinými messengery) je možnost vést kontextové diskuse vázané na konkrétní objekty Document Flow – dokumenty, události atd. To znamená, že systém interakce je hluboce integrován s cílovou aplikací a nepůsobí jen jako „samostatné tlačítko“.
Počet písmen v našem DO již přesáhl 100 milionů a obecně je v DBMS více než 11 miliard záznamů. Celkem systém využívá téměř 30 TB úložiště: objem databáze je 7,5 TB, soubory pro hromadnou práci jsou uloženy samostatně a zabírají dalších 21 TB.
Pokud mluvíme o konkrétnějších číslech, zde je v tuto chvíli počet písmen a souborů:
- Odchozí e-maily – 14,7 milionů.
- Došlé dopisy – 85,4 milionů.
- Verze souborů – 70,8 milionů.
- Interní doklady – 30,6 tis.
DO má víc než jen poštu a soubory. Níže jsou uvedeny údaje pro další účetní objekty:
- Rezervace zasedacích místností – 52 126
- Týdenní zprávy – 153 940
- Denní hlášení – 628 153
- Schvalovací víza – 11 821
- Došlé doklady – 79 677
- Odchozí doklady – 28 357
- Záznamy o událostech v pracovních kalendářích uživatelů – 168 228
- Přihlášky pro kurýry – 21 883
- Protistrany – 81 029
- Evidence práce s protistranami – 45 632
- Kontaktní osoby protistran – 41 795
- Události – 10 243
- Projekty – 6 320
- Úkoly zaměstnanců – 245 980
- Příspěvky na fóru – 26 282
- Chatové zprávy – 891 095
- Obchodní procesy - 109 056. Interakce mezi zaměstnanci probíhá prostřednictvím procesů - schvalování, provádění, kontrola, registrace, podepisování atd. Měříme dobu trvání procesů, počet cyklů, počet účastníků, počet vratek, počet žádostí o změnu termínů. A tyto informace je velmi užitečné analyzovat, abychom pochopili, jaké procesy v podniku probíhají, a zvýšili efektivitu spolupráce zaměstnanců.
Na jakém zařízení to všechno zpracováváme?
Tato čísla ukazují na impozantní objem úkolů, takže jsme byli postaveni před nutnost alokovat poměrně produktivní zařízení pro potřeby interních dceřiných společností. Aktuálně jsou jeho charakteristiky následující: 38 jader, 240 GB RAM, 26 TB disků. Zde je tabulka serverů:
Do budoucna plánujeme navýšení kapacity zařízení.
Jak je to se zatížením serveru?
Síťová aktivita nebyla pro nás ani pro naše zákazníky nikdy problém. Slabým místem je zpravidla procesor a disky, protože s nedostatkem paměti už ví každý. Zde jsou screenshoty našich serverů z Resource Monitor, které ukazují, že nemáme žádnou hroznou zátěž, je velmi skromná.
Například na níže uvedeném snímku obrazovky vidíme SQL server, kde je zatížení CPU 23%. A to je velmi dobrý ukazatel (pro srovnání: pokud se zatížení blíží 70%, zaměstnanci s největší pravděpodobností zaznamenají poměrně výrazné zpomalení práce).
Druhý snímek obrazovky ukazuje aplikační server, na kterém běží platforma 1C:Enterprise – obsluhuje pouze uživatelské relace. Zde je zátěž procesoru o něco vyšší – 38 %, je plynulý a klidný. Dochází k určitému načítání disku, ale je přijatelné.
Třetí snímek obrazovky ukazuje další server 1C:Enterprise (je to druhý, máme dva z nich v clusteru). Pouze předchozí slouží uživatelům a na tomto pracují roboti. Například přijímají poštu, směrují dokumenty, vyměňují si data, počítají práva atd. Všechny tyto činnosti na pozadí provádějí přibližně 90–100 úloh na pozadí. A tento server je velmi vytížen - 88%. To se ale lidí nedotkne a implementuje přesně veškerou automatizaci, kterou by Správa dokumentů měla dělat.
Jaké jsou metriky pro měření výkonu?
V našich pobočkách máme zabudován seriózní subsystém pro měření výkonnostních ukazatelů a výpočet různých metrik. To je nezbytné, abychom pochopili jak v současné době, tak z historické perspektivy, co se v systému děje, co se zhoršuje, co se zlepšuje. Monitorovací nástroje – metriky a měření času – jsou součástí standardní dodávky „1C: Document Flow 8“. Metriky vyžadují přizpůsobení během implementace, ale samotný mechanismus je standardní.
Metriky jsou měření různých obchodních ukazatelů v určitých okamžicích (například průměrná doba doručení pošty je 10 minut).
Jedna z metrik ukazuje počet aktivních uživatelů v databázi. Průměrně jich je během dne 1000-1400. Graf ukazuje, že v době screenshotu bylo v databázi 2144 aktivních uživatelů.
Existuje více než 30 takových akcí, seznam je pod řezem.seznam
- Přihlaste se do systému
- Odhlásit se
- Načítání pošty
- Změna platnosti objektu
- Změna přístupových práv
- Změna předmětu procesu
- Změna pracovní skupiny objektu
- Změna složení stavebnice
- Změna souboru
- Import souboru
- Odeslání poštou
- Přesouvání souborů
- Přesměrování úkolu
- Podepsání elektronického podpisu
- Vyhledávejte podle podrobností
- Fulltextové vyhledávání
- Příjem souboru
- Přerušení procesu
- Zobrazit
- Dešifrování
- Registrace dokumentu
- Skenování
- Rušení označení smazání
- Vytvoření objektu
- Ukládání na disk
- Začátek procesu
- Mazání záznamů uživatelského protokolu
- Odstranění elektronického podpisu
- Nastavení značky pro smazání
- Šifrování
- Exportovat složku
Předminulý týden se nám průměrná aktivita uživatelů zvýšila jedenapůlkrát (v grafu znázorněno červeně) - je to způsobeno přechodem většiny zaměstnanců na práci na dálku (kvůli známým událostem). Počet aktivních uživatelů se také zvýšil 3krát (na snímku obrazovky zobrazeno modře), protože zaměstnanci začali aktivně používat mobilní telefony: každý mobilní klient vytváří připojení k serveru. Nyní má každý z našich zaměstnanců v průměru 2 připojení k serveru.
Pro nás, jako správce, je to signál, že musíme věnovat větší pozornost problémům s výkonem a sledovat, zda se situace nezhoršila. Na to se ale díváme na základě jiných parametrů. Například, jak se změní čas doručení pošty pro interní směrování (zobrazeno modře na snímku obrazovky níže). Vidíme, že do letošního roku to kolísalo, ale nyní je to stabilní - pro nás je to indikátor, že je se systémem vše v pořádku.
Další použitou metrikou je pro nás průměrná čekací doba na stahování dopisů z poštovního serveru (na snímku obrazovky je zobrazena červeně). Zhruba řečeno, jak dlouho bude dopis plout po internetu, než se dostane k našemu zaměstnanci. Screenshot ukazuje, že tato doba se v poslední době také nijak nezměnila. Existují izolované špičky - ale nejsou spojeny se zpožděním, ale se skutečností, že se na poštovních serverech ztrácí čas.
Nebo například další metrika (na snímku obrazovky zobrazená modře) – aktualizace písmen ve složce. Otevření poštovní složky je velmi běžná operace a je třeba ji provést rychle. Měříme, jak rychle se provádí. Tento ukazatel se měří u každého klienta. Vidíte jak celkový obraz za firmu, tak dynamiku např. u jednotlivého zaměstnance. Screenshot ukazuje, že do letošního roku byla metrika nevyvážená, poté jsme provedli řadu vylepšení a nyní se to nezhoršuje – graf je téměř plochý.
Metriky jsou v podstatě administrátorským nástrojem pro sledování systému, pro rychlou reakci na případné změny v chování systému. Snímek obrazovky ukazuje interní dceřiné metriky pro daný rok. Skok v grafech je způsoben tím, že jsme dostali úkoly na rozvoj interních dceřiných společností.
Zde je seznam některých dalších metrik (pod řezem).
Metriky
- Aktivita uživatele
- Aktivní uživatelé
- Aktivní procesy
- Počet souborů
- Velikost souboru (MB)
- Počet dokumentů
- Počet objektů, které mají být odeslány příjemcům
- Počet protistran
- Nedokončené úkoly
- Průměrná doba čekání na stahování e-mailů z poštovního serveru za posledních 10 minut
- Externí datová vyrovnávací paměť: počet souborů
- Zpožděná hranice od aktuálního data
- Dlouhá fronta
- Operační fronta
- Nezpracované stáří účtu externím směrováním
- Velikost fronty přijetí interního směrování (dlouhá fronta)
- Velikost fronty pro přijetí interního směrování (rychlá fronta)
- Doba doručení pošty prostřednictvím interního směrování (dlouhá fronta)
- Doba doručení pošty prostřednictvím interního směrování (rychlá fronta)
- Doba doručení pošty prostřednictvím externího směrování (průměr)
- Počet dokumentů Rezervace
- Počet dokumentů Absence
- Počet dokumentů „Záznam o práci s protistranou“
- Mail Aktualizace dopisů ve složce
- Mail Otevření dopisní karty
- Mail Přenos dopisu do složky
- Mail Procházení složek
Náš systém nepřetržitě měří více než 150 ukazatelů, ale ne všechny lze rychle sledovat. Mohou se hodit později, v nějaké historické perspektivě, a vy se můžete zaměřit na ty nejdůležitější pro podnikání.
V jedné z implementací bylo například vybráno pouze 5 indikátorů. Zákazník si stanovil za cíl vytvořit minimální sadu ukazatelů, ale zároveň takovou, aby pokryla hlavní pracovní scénáře. Bylo by neopodstatněné zahrnout do akceptačního certifikátu 150 ukazatelů, protože i v rámci podniku je obtížné shodnout se na tom, které ukazatele jsou považovány za přijatelné. A o těchto 5 indikátorech věděli a již před zahájením realizačního projektu je předložili do systému, včetně dokumentace soutěže: čas na otevření karty ne více než 3 sekundy, čas na dokončení úkolu se spisem č. více než 5 sekund atd. V našich pobočkách jsme měli metriky, které velmi jasně odrážely původní požadavek z technických specifikací zákazníka.
Máme také profilovou analýzu měření výkonu. Výkonnostní ukazatele jsou záznamem doby trvání každé probíhající operace (zápis dopisu do databáze, odeslání dopisu na poštovní server atd.). Toto používají výhradně technici. V našem programu shromažďujeme mnoho ukazatelů výkonu. Aktuálně měříme přibližně 1500 klíčových operací, které jsou rozděleny do profilů.
Jedním z nejdůležitějších profilů je pro nás „Seznam klíčových ukazatelů pošty z pohledu spotřebitele“. Tento profil zahrnuje například následující ukazatele:
- Provedení příkazu: Vybrat podle značky
- Otevření formuláře: List Form
- Provedení příkazu: Vybrat podle složky
- Zobrazení písmene v oblasti čtení
- Uložení dopisu do vaší oblíbené složky
- Hledejte písmena podle podrobností
- Vytvoření dopisu
Pokud vidíme, že metrika pro nějaký obchodní ukazatel je příliš velká (například dopisy od konkrétního uživatele začaly přicházet velmi dlouho), začneme to zjišťovat a přejdeme k měření doby technických operací. Máme technickou operaci „Archivace dopisů na poštovním serveru“ – vidíme, že čas této operace byl za poslední období překročen. Tato operace se zase rozloží na další operace - například navázání spojení s poštovním serverem. Vidíme, že se z nějakého důvodu najednou velmi rozrostla (máme všechna měření za měsíc – můžeme porovnat, že minulý týden to bylo 10 milisekund a nyní je to 1000 milisekund). A chápeme, že tady je něco rozbité – musíme to opravit.
Jak udržujeme tak velkou databázi?
Naše interní DO je příkladem skutečně fungujícího projektu s vysokým zatížením. Pojďme si promluvit o technických vlastnostech jeho databáze.
Jak dlouho trvá restrukturalizace velkých databázových tabulek?
SQL server vyžaduje pravidelnou údržbu, uspořádání tabulek. V dobrém slova smyslu by se to mělo provádět alespoň jednou denně, u stolů s vysokou poptávkou ještě častěji. Pokud je ale databáze velká (a náš počet záznamů již přesáhl 11 miliard), pak péče o ni není jednoduchá.
Před 6 lety jsme dělali restrukturalizaci tabulky, ale pak to začalo trvat tak dlouho, že jsme se už nevešli do nočních intervalů. A protože tyto operace silně zatěžují SQL server, nemůže efektivně sloužit ostatním uživatelům.
Proto nyní musíme používat různé triky. Nemůžeme například provádět tyto postupy na úplných souborech dat. Musíte se uchýlit k postupu aktualizace vzorku 500000 14 řádků – to trvá XNUMX minut. Neaktualizuje statistiky o všech datech v tabulce, ale vybere půl milionu řádků a použije je k výpočtu statistik, které použije pro celou tabulku. Je to určitá domněnka, ale jsme nuceni ji učinit, protože pro konkrétní tabulku bude sběr statistik celé miliardy záznamů trvat nepřijatelně dlouho.
Optimalizovali jsme také další operace údržby tím, že jsme je provedli dílčí.
Údržba DBMS je obecně obtížný úkol. V případě aktivní interakce mezi zaměstnanci databáze rychle roste a pro administrátory je stále obtížnější ji udržovat – aktualizovat statistiky, defragmentovat, indexovat. Zde je potřeba uplatnit různé strategie, dobře víme, jak na to, máme zkušenosti, můžeme je sdílet.
Jak je implementováno zálohování s takovými svazky?
Úplná záloha DBMS se provádí jednou denně v noci, přírůstková – každou hodinu. Každý den se také vytváří adresář souborů a je součástí přírůstkové zálohy úložiště souborů.
Jak dlouho trvá dokončení úplné zálohy?
Úplná záloha na pevný disk je dokončena za tři hodiny, částečná záloha za hodinu. Zápis na pásku (speciální zařízení, které vytvoří záložní kopii na speciální kazetu uloženou mimo kancelář, trvá déle, na pásku se vytvoří přenositelná kopie, která zůstane zachována, pokud například vyhoří serverovna). Záloha se provádí na přesně stejný server, jehož parametry byly vyšší - SQL server s 20% zátěží procesoru. V době zálohování se systém samozřejmě výrazně zhorší, ale stále je funkční.
Existuje deduplikace?
Existují soubory, vyzkoušíme to na sobě a brzy to bude zahrnuto do nové verze správy dokumentů. Testujeme také mechanismus deduplikace protistrany. Na úrovni DBMS nedochází k deduplikaci záznamů, protože to není nutné. Platforma 1C:Enterprise ukládá objekty do DBMS a pouze platforma může být zodpovědná za jejich konzistenci.
Existují uzly pouze pro čtení?
Neexistují žádné čtecí uzly (vyhrazené systémové uzly, které slouží těm, kteří potřebují přijímat data pro čtení). DO není účetní systém, který by se dal umístit na samostatný BI uzel, ale existuje samostatný uzel pro vývojové oddělení, se kterým se vyměňují zprávy ve formátu JSON a typická doba replikace je jednotek a desítek sekund. Uzel je stále malý, má asi 800 milionů záznamů, ale rychle se rozrůstá.
Nejsou e-maily označené ke smazání vůbec smazány?
Ještě ne. Nemáme za úkol základnu odlehčit. Vyskytlo se několik poměrně závažných případů, kdy bylo nutné odkázat na písmena označená ke smazání, včetně roku 2009. Proto jsme se rozhodli zatím vše ponechat. Ale když se náklady na to stanou neoprávněnými, budeme přemýšlet o odstranění. Pokud však potřebujete zcela odstranit samostatný dopis z databáze, aby nebyly žádné stopy, lze to provést na zvláštní žádost.
Proč to ukládat? Máte statistiky o přístupu ke starým dokumentům?
Neexistují žádné statistiky. Přesněji řečeno, má podobu uživatelského logu, ale neukládá se dlouho. Záznamy starší než rok jsou z protokolu vymazány.
Byly situace, kdy bylo potřeba získat starou korespondenci z doby před pěti nebo i deseti lety. A to se vždy nedělo z nečinné zvědavosti, ale kvůli přijímání složitých obchodních rozhodnutí. Vyskytl se případ, kdy by bez historie korespondence bylo učiněno nesprávné obchodní rozhodnutí.
Jak se posuzuje a ničí hodnota dokumentů podle doby uložení?
U papírových dokumentů se to provádí obvyklým tradičním způsobem, jako každý jiný. Neděláme to pro elektronické – ať si je nechají pro sebe. Sedačka je tady. Existují výhody. Všichni jsou v pořádku.
Jaké jsou vyhlídky rozvoje?
Nyní naše DO řeší asi 30 interních problémů, z nichž některé jsme uvedli na začátku článku. DL se také používá k přípravě konferencí, které pořádáme dvakrát ročně pro naše partnery: celý program, všechny zprávy, všechny paralelní sekce, sály - to vše se napíše do DL a pak se z něj stáhne a tištěný program je vyrobeno.
Na cestě k DO je několik dalších úkolů, kromě těch, které již řeší. Existují celofiremní úkoly a jsou jedinečné a vzácné, které potřebuje pouze konkrétní oddělení. Je nutné jim pomoci, což znamená rozšířit „geografii“ používání systému v rámci 1C - rozšířit rozsah aplikace, vyřešit problémy všech oddělení. To by byl nejlepší test výkonu a spolehlivosti. Přál bych si, aby systém fungoval na bilionech záznamů, petabajtech informací.
Zdroj: www.habr.com