Проверяваме сами: как се внедрява 1C и как се администрира: Документопоток в компанията 1C

В 1C ние широко използваме нашите собствени разработки за организиране на работата на компанията. В частност, "1C: Документен поток 8". Освен за управление на документи (както подсказва името), той е и модерен ECM-система (Enterprise Content Management - управление на корпоративно съдържание) с широк набор от функционалности - поща, работни календари на служителите, организиране на споделен достъп до ресурси (например резервиране на зали за срещи), проследяване на времето, корпоративен форум и много други.

Повече от хиляда служители използват управление на документи в 1C. Базата данни вече е станала впечатляваща (11 милиарда записа), което означава, че изисква по-внимателна грижа и по-мощно оборудване.

Как работи нашата система, какви трудности срещаме при поддържането на базата данни и как ги решаваме (използваме MS SQL Server като СУБД) - ще ви разкажем в статията.

За тези, които четат за продуктите на 1C за първи път.
1C:Document Flow е приложно решение (конфигурация), реализирано на базата на рамка за разработване на бизнес приложения - платформата 1C:Enterprise.

„1C: Документен поток 8“ (съкратено DO) ви позволява да автоматизирате работата с документи в предприятието. Един от основните инструменти за взаимодействие на служителите е имейлът. В допълнение към пощата, DO решава и други проблеми:

• Проследяване на времето
• Проследяване на отсъствия на служители
• Приложения за куриери/транспорт
• Работни календари на служителите
• Регистрация на кореспонденция
• Контакти на служители (адресна книга)
• Корпоративен форум
• Резервация на стая
• Планиране на събитие
• CRM
• Колективна работа с файлове (със запазване на файлови версии)
• и др.

Влизаме в Управление на документи тънък клиент (родно изпълнимо приложение) от Windows, Linux, macOS, уеб клиент (от браузъри) и мобилен клиент - в зависимост от ситуацията.

И благодарение на другия ни продукт, свързан с потока на документи - Система за взаимодействие – ние директно в Document Flow получаваме функционалността на месинджъра – чатове, аудио и видео разговори (включително групови разговори, които сега станаха особено важни, включително от мобилен клиент), бърз обмен на файлове плюс възможност за писане на чат ботове, които опростяват работа със системата. Друго предимство на използването на Interaction System (в сравнение с други месинджъри) е възможността за провеждане на контекстуални дискусии, свързани с конкретни обекти на Document Flow - документи, събития и др. Това означава, че системата за взаимодействие е дълбоко интегрирана с целевото приложение и не действа просто като „отделен бутон“.

Броят на буквите в нашия DO вече надхвърли 100 милиона, а като цяло има повече от 11 милиарда записа в СУБД. Общо системата използва почти 30 TB място за съхранение: обемът на базата данни е 7,5 TB, файловете за колективна работа се съхраняват отделно и заемат още 21 TB.

Ако говорим за по-конкретни цифри, ето броя на писмата и файловете към момента:

• Изходящи имейли – 14,7 милиона.
• Входящи писма – 85,4 милиона.
• Версии на файлове – 70,8 милиона.
• Вътрешни документи – 30,6 хил. бр.

DO има повече от просто поща и файлове. По-долу са данните за други счетоводни обекти:

• Резервиране на заседателни зали – 52 126
• Седмични отчети – 153 940
• Ежедневни отчети – 628 153 бр
• Визи за одобрение – 11 821 бр
• Входящи документи – 79 677 бр
• Изходящи документи – 28 357 бр
• Записи за събития в работните календари на потребителите – 168 228
• Заявки за куриери – 21 883 бр
• Контрагенти – 81 029 бр
• Записи за работа с контрагенти – 45 632 бр
• Лица за контакт на контрагентите – 41 795 бр
• Събития – 10 243
• Проекти – 6 320 бр
• Задачи на служители – 245 980 бр
• Публикации във форума – 26 282
• Съобщения в чата – 891 095
• Бизнес процеси – 109 056. Взаимодействието между служителите се осъществява чрез процеси – одобрение, изпълнение, преглед, регистрация, подписване и др. Измерваме продължителността на процесите, броя на циклите, броя на участниците, броя на връщанията, броя на заявките за промяна на сроковете. И тази информация е много полезна за анализиране, за да се разбере какви процеси протичат в предприятието и да се повиши ефективността на сътрудничеството на служителите.

На какво оборудване обработваме всичко това?

Тези цифри показват впечатляващ обем от задачи, така че бяхме изправени пред необходимостта да разпределим доста продуктивно оборудване за нуждите на вътрешните дъщерни дружества. В момента характеристиките му са следните: 38 ядра, 240 GB RAM, 26 TB дискове. Ето таблица със сървъри:


В бъдеще планираме да увеличим капацитета на оборудването.

Как вървят нещата с натоварването на сървъра?

Мрежовата активност никога не е била проблем за нас или нашите клиенти. По правило слабото място е процесорът и дисковете, защото всеки вече знае как да се справи с липсата на памет. Ето екранни снимки на нашите сървъри от Resource Monitor, които показват, че нямаме ужасно натоварване, то е много скромно.

Например, на екранната снимка по-долу виждаме SQL сървър, където натоварването на процесора е 23%. И това е много добър показател (за сравнение: ако натоварването достигне 70%, тогава най-вероятно служителите ще наблюдават доста значително забавяне на работата).

Втората екранна снимка показва сървъра на приложения, на който работи платформата 1C:Enterprise - той обслужва само потребителски сесии. Тук натоварването на процесора е малко по-високо – 38%, върви плавно и спокойно. Има известно натоварване на диска, но е приемливо.

Третата екранна снимка показва друг 1C:Enterprise сървър (това е вторият, имаме два от тях в клъстера). Само предишният обслужва потребителите, а роботите работят върху този. Например, те получават поща, маршрутизират документи, обменят данни, изчисляват права и т.н. Всички тези фонови дейности изпълняват приблизително 90-100 фонови задания. И този сървър е много натоварен - 88%. Но това не засяга хората и прилага точно цялата автоматизация, която трябва да направи Управлението на документи.

Какви са показателите за измерване на ефективността?

Имаме вградена сериозна подсистема в нашите дъщерни дружества за измерване на показатели за ефективност и изчисляване на различни показатели. Това е необходимо, за да разберем както в настоящия момент, така и от историческа гледна точка какво се случва в системата, кое се влошава, кое се подобрява. Инструментите за наблюдение - метрики и времеви измервания - са включени в стандартната доставка на "1C: Документооборот 8". Метриките изискват персонализиране по време на внедряването, но самият механизъм е стандартен.

Метриките са измервания на различни бизнес показатели в определени моменти от време (например средното време за доставка на пощата е 10 минути).

Един от показателите показва броя на активните потребители в базата данни. Средно през деня има 1000-1400 от тях. Графиката показва, че към момента на екранната снимка в базата данни има 2144 активни потребители.

Има повече от 30 такива действия, списъкът е под разрез.Списък

• Вход
• Отписване
• Зареждане на пощата
• Промяна на валидността на обект
• Промяна на правата за достъп
• Смяна на предмета на процес
• Промяна на работната група на обект
• Промяна на състава на комплекта
• Смяна на файл
• Импортиране на файл
• Изпращане по пощата
• Преместване на файлове
• Пренасочване на задача
• Подписване на електронен подпис
• Търсене по детайли
• Пълнотекстово търсене
• Получаване на файл
• Прекъсване на процес
• Погледни вътре
• Декриптиране
• Регистрация на документ
• преглеждане
• Демаркиране на изтриване
• Създаване на обект
• Запазване на диск
• Начало на процеса
• Изтриване на потребителски регистрационни записи
• Премахване на електронен подпис
• Задаване на знак за изтриване
• Шифроване
• Експортиране на папка

Предишната седмица нашата средна потребителска активност се увеличи с един път и половина (показано в червено на графиката) - това се дължи на прехода на повечето служители към дистанционна работа (поради добре известни събития). Освен това броят на активните потребители се увеличи 3 пъти (показано в синьо на екранната снимка), тъй като служителите започнаха активно да използват мобилни телефони: всеки мобилен клиент създава връзка към сървъра. Сега средно всеки наш служител има 2 връзки към сървъра.

За нас, като администратори, това е сигнал, че трябва да сме по-внимателни към проблемите с производителността и да видим дали нещата са се влошили. Но ние разглеждаме това въз основа на други параметри. Например как се променя времето за доставка на пощата за вътрешно маршрутизиране (показано в синьо на екранната снимка по-долу). Виждаме, че до тази година имаше колебания, но сега е стабилен - за нас това е показател, че всичко в системата е наред.

Друг приложен показател за нас е средното време на изчакване за изтегляне на писма от пощенския сървър (показано в червено на екранната снимка). Грубо казано, колко време ще витае писмото в интернет, преди да стигне до нашия служител. Екранната снимка показва, че това време също не се е променило по никакъв начин напоследък. Има единични пикове - но те не са свързани със закъснения, а с факта, че времето на мейл сървърите се губи.

Или, например, друг показател (показан в синьо на екранната снимка) – актуализиране на букви в папка. Отварянето на пощенска папка е много обичайна операция и трябва да се извърши бързо. Ние измерваме колко бързо се изпълнява. Този показател се измерва за всеки клиент. Можете да видите както цялостната картина за компанията, така и динамиката, например за отделен служител. Екранната снимка показва, че до тази година показателят беше небалансиран, след това направихме редица подобрения и сега не се влошава – графиката е почти плоска.

Метриките са основно инструмент на администратора за наблюдение на системата, за бързо реагиране на всякакви промени в поведението на системата. Екранната снимка показва вътрешни показатели на дъщерното дружество за годината. Скокът в графиките се дължи на факта, че ни бяха поставени задачи за развитие на вътрешни дъщерни дружества.

Ето списък с още някои показатели (под разреза).
Метрика

• Потребителска активност
• Активни потребители
• Активни процеси
• Брой файлове
• Размер на файла (MB)
• Брой документи
• Брой обекти, които да бъдат изпратени до получателите
• Брой контрагенти
• Недовършени задачи
• Средно време на изчакване за изтегляне на имейли от пощенския сървър през последните 10 минути
• Външен буфер за данни: брой файлове
• Изоставаща граница от текущата дата
• Дълга опашка
• Оперативна опашка
• Необработена възраст на акаунта чрез външно маршрутизиране
• Размер на опашката за приемане на вътрешно маршрутизиране (дълга опашка)
• Размер на опашката за приемане на вътрешно маршрутизиране (бърза опашка)
• Време за доставка на пощата чрез вътрешно маршрутизиране (дълга опашка)
• Време за доставка на пощата чрез вътрешно маршрутизиране (бърза опашка)
• Време за доставка на пощата чрез външно маршрутизиране (средно)
• Брой документи Резервация
• Брой документи Отсъствие
• Брой документи „Работа с контрагент“
• Поща Актуализиране на писма в папка
• Поща Отваряне на карта с писмо
• Поща Прехвърлете писмо в папка
• Поща Придвижване през папки

Нашата система измерва повече от 150 показателя денонощно, но не всички от тях могат да бъдат бързо наблюдавани. Те могат да ви бъдат полезни по-късно, в някаква историческа перспектива и можете да се съсредоточите върху най-важните за бизнеса.

При една от реализациите например са избрани само 5 индикатора. Клиентът си постави за цел да създаде минимален набор от индикатори, но в същото време такъв, че да покрива основните сценарии на работа. Би било неоправдано да се включат 150 показателя в сертификата за приемане, тъй като дори в рамките на предприятието е трудно да се постигне съгласие кои показатели се считат за приемливи. И те знаеха за тези 5 индикатора и вече ги бяха представили на системата преди началото на проекта за внедряване, включвайки ги в конкурсната документация: време за отваряне на карта не повече от 3 секунди, време за изпълнение на задача с файл № повече от 5 секунди и т.н. В нашите дъщерни дружества имахме показатели, които много ясно отразяваха първоначалната заявка от техническите спецификации на клиента.

Имаме и профилен анализ на измерванията на ефективността. Индикаторите за ефективност са запис на продължителността на всяка текуща операция (писане на писмо в базата данни, изпращане на писмо до пощенски сървър и т.н.). Това се използва изключително от техници. Натрупваме много показатели за ефективност в нашата програма. В момента измерваме приблизително 1500 ключови операции, които са разделени на профили.

Един от най-важните профили за нас е „Списък с ключови индикатори на пощата от гледна точка на потребителя“. Този профил включва например следните показатели:

• Изпълнение на командата: Изберете по етикет
• Отваряне на формуляр: Формуляр за списък
• Изпълнение на командата: Избор по папка
• Показване на буква в областта за четене
• Запазване на писмо в любимата ви папка
• Търсене на букви по детайли
• Създаване на писмо

Ако видим, че показателят за някакъв бизнес показател е станал твърде голям (например писма от конкретен потребител са започнали да пристигат за много дълго време), ние започваме да го разбираме и се обръщаме към измерване на времето за технически операции. Имаме техническа операция „Архивиране на писма на пощенски сървър“ - виждаме, че времето за тази операция е надвишено за последния период. Тази операция от своя страна се декомпозира на други операции - например установяване на връзка с пощенски сървър. Виждаме, че по някаква причина изведнъж е станал много голям (имаме всички измервания за един месец - можем да сравним, че миналата седмица беше 10 милисекунди, а сега е 1000 милисекунди). И разбираме, че тук нещо е счупено - трябва да го поправим.

Как да поддържаме такава голяма база данни?

Нашият вътрешен DO е пример за наистина работещ проект с високо натоварване. Нека поговорим за техническите характеристики на неговата база данни.

Колко време отнема преструктурирането на големи таблици в база данни?

SQL сървърът изисква периодична поддръжка, подреждане на таблиците. В добрия смисъл това трябва да се прави поне веднъж на ден и дори по-често за маси с голямо търсене. Но ако базата данни е голяма (а броят на записите ни вече надхвърли 11 милиарда), тогава грижата за нея не е лесна.

Направихме преструктуриране на масата преди 6 години, но след това започна да отнема толкова много време, че вече не се вписваме в нощните интервали. И тъй като тези операции натоварват силно SQL сървъра, той не може да обслужва ефективно други потребители.

Затова сега трябва да използваме различни трикове. Например не можем да изпълним тези процедури върху пълни набори от данни. Трябва да прибегнете до процедурата Update Sample 500000 rows - това отнема 14 минути. Той не актуализира статистически данни за всички данни в таблицата, но избира половин милион реда и ги използва за изчисляване на статистически данни, които използва за цялата таблица. Това е някакво предположение, но сме принудени да го направим, защото за конкретна таблица събирането на статистика за целия милиард записи ще отнеме неприемливо дълго време.

Оптимизирахме и други операции по поддръжката, като ги направихме частични.

Поддържането на СУБД обикновено е сложна задача. В случай на активно взаимодействие между служителите, базата данни расте бързо и за администраторите става все по-трудно да я поддържат - актуализиране на статистика, дефрагментиране, индексиране. Тук трябва да прилагаме различни стратегии, знаем добре как да го направим, имаме опит, можем да го споделим.

Как се осъществява архивирането при такива обеми?

Пълно архивиране на СУБД се извършва веднъж на ден през нощта, инкрементално – на всеки час. Освен това всеки ден се създава файлова директория и тя е част от инкременталното архивиране на файловото хранилище.

Колко време отнема пълното архивиране?

Пълно архивиране на твърд диск се извършва за три часа, частично архивиране за един час. Отнема повече време за запис на лента (специално устройство, което прави резервно копие на специална касета, съхранявана извън офиса; на лентата се прави прехвърляемо копие, което ще бъде запазено, ако например сървърната стая изгори). Архивирането се прави на абсолютно същия сървър, чиито параметри бяха по-високи - SQL сървър с 20% натоварване на процесора. По време на архивирането, разбира се, системата става много по-лоша, но все още функционира.

Има ли дедупликация?

Дедупликация Има файлове, ще го тестваме върху себе си и скоро ще бъде включен в новата версия на Управление на документи. Ние също така тестваме механизма за дедупликация на контрагента. Няма дедупликация на записи на ниво СУБД, тъй като това не е необходимо. Платформата 1C:Enterprise съхранява обекти в СУБД и само платформата може да отговаря за тяхната последователност.

Има ли възли само за четене?

Няма възли за четене (специализирани системни възли, които обслужват онези, които трябва да получат каквито и да било данни за четене). DO не е счетоводна система, която да се постави на отделен BI възел, но има отделен възел за отдела за разработка, с който се обменят съобщения в JSON формат, а типичното време за репликация е единици и десетки секунди. Възелът все още е малък, има около 800 милиона записа, но расте бързо.

Изобщо ли не се изтриват имейлите, маркирани за изтриване?

Все още не. Ние нямаме задачата да направим основата по-лека. Имаше няколко доста сериозни случая, когато беше необходимо да се препраща към писма, маркирани за изтриване, включително 2009 г. Затова решихме да запазим всичко засега. Но когато разходите за това станат неоправдани, ще помислим за премахване. Но ако трябва напълно да премахнете отделно писмо от базата данни, така че да няма следи, тогава това може да стане със специална заявка.

Защо да го съхранявате? Имате ли статистика за достъп до стари документи?

Няма статистика. По-точно, той е под формата на потребителски дневник, но не се съхранява дълго. Вписвания, по-стари от една година, се заличават от протокола.

Имаше ситуации, когато беше необходимо да се извлече стара кореспонденция от преди пет или дори десет години. И това винаги се правеше не от празно любопитство, а за вземане на сложни бизнес решения. Имаше случай, при който без история на кореспонденцията би било взето грешно бизнес решение.

Как се оценява стойността на документите и как се унищожават според сроковете на съхранение?

За хартиените документи това се прави по обичайния традиционен начин, както всички останали. За електронните не го правим - нека си ги запазят. Мястото е тук. Има ползи. Всички са добре.

Какви перспективи за развитие има?

Сега нашият DO решава около 30 вътрешни проблема, някои от които изброихме в началото на статията. DL се използва и за подготовка на конференции, които провеждаме два пъти годишно за нашите партньори: цялата програма, всички доклади, всички паралелни секции, зали - всичко това се набира в DL, след което се изтегля от него и се разпечатва програма е направен.

Има още няколко задачи на път за DO, в допълнение към тези, които вече решава. Има задачи за цялата компания, а има и уникални и редки, необходими само на конкретен отдел. Необходимо е да им се помогне, което означава разширяване на „географията“ на използване на системата в рамките на 1C - разширяване на обхвата на приложение, решаване на проблемите на всички отдели. Това би бил най-добрият тест за производителност и надеждност. Бих искал да видя системата да работи върху трилиони записи, петабайти информация.

Източник: www.habr.com