Ми у фірмі 1С широко використовуємо власні розробки для організації роботи компанії. Зокрема, . Крім управління документами (як випливає з назви) це ще й сучасна -система (Enterprise Content Management - управління корпоративним контентом) з широким набором функціональних можливостей - пошта, робочі календарі співробітників, організація спільного доступу до ресурсів (наприклад, бронювання переговорних), облік робочого часу, корпоративний форум та багато іншого.
У фірмі 1С документообіг користується понад тисячу співробітників. База даних стала вже великою (11 млрд. записів), а це означає, що вона вимагає ретельного догляду та потужнішого обладнання.
Як улаштована робота нашої системи, з якими складнощами при обслуговуванні бази ми стикаємося і як їх вирішуємо (як СУБД ми використовуємо MS SQL Server) – розповімо у статті.
Для тих, хто вперше читає про продукти 1С.
1С: Документообіг – це прикладне рішення (конфігурація), реалізоване на базі фреймворку для розробки бізнес-додатків – платформі 1С: Підприємство.
«1С:Документообіг 8» (скорочено – ДО) дозволяє автоматизувати роботу з документами на підприємстві. Один із основних інструментів взаємодії співробітників – електронна пошта. Крім пошти ДО вирішує й інші завдання:
- Облік робочого часу
- Облік відсутності співробітників
- Заявки на кур'єрів/транспорт
- Робочі календарі співробітників
- Реєстрація кореспонденції
- Контакти співробітників (Адресна книга)
- Корпоративний форум
- Бронювання приміщень
- Планування заходів
- CRM
- Колективна робота з файлами (зі збереженням версій файлів)
- та ін.
У Документообіг ми заходимо (нативний виконуваний додаток) з Windows, Linux, macOS, (з браузерів) та - в залежності від ситуації.
А ще завдяки підключеному до Документообігу іншому нашому продукту – – ми безпосередньо в Документообігу отримуємо функціональність месенджера – чати, аудіо та відеодзвінки (включаючи групові, що зараз стало особливо актуальним, у тому числі з мобільного клієнта), швидкий обмін файлами плюс можливість написання чат-ботів, що спрощують роботу з системою. Ще один плюс від використання Системи Взаємодії (проти інших месенджерів) – можливість вести контекстні обговорення, прив'язані до конкретних об'єктів Документообігу – документів, заходів тощо. Тобто Система взаємодії глибоко інтегрується з цільовим додатком, а не є просто «окремою кнопкою».
Число листів у нашому ДО вже перевалило за 100 млн., а загалом у СУБД – понад 11 млрд. записів. Сумарно система використовує майже 30 Тб сховища: обсяг бази – 7,5 Тб, файли для колективної роботи лежать окремо та займають ще 21 Тб.
Якщо говорити про більш конкретні цифри, то кількість листів і файлів на даний момент:
- Вихідні листи – 14,7 млн.
- Вхідні листи – 85,4 млн.
- Версій файлів – 70,8 млн.
- Внутрішні документи – 30,6 тис.
У ДО є не лише пошта та файли. Нижче наведемо цифри інших облікових об'єктів:
- Бронювання переговорних – 52 126
- Щотижневі звіти – 153 940
- Щоденні звіти – 628 153
- Візи погодження – 11 821
- Вхідні документи – 79
- Вихідні документи – 28 357
- Записи про події у робочих календарях користувачів – 168 228
- Заявки на кур'єрів – 21 883
- Контрагенти – 81
- Записи про роботу з контрагентами – 45 632
- Контактні особи контрагентів – 41 795
- Заходи – 10 243
- Проекти – 6
- Завдання співробітників – 245 980
- Повідомлення на форумі – 26 282
- Повідомлення в чаті – 891 095
- Бізнес-процеси - 109. Взаємодія між співробітниками відбувається через процеси - узгодження, виконання, розгляду, реєстрації, підписання і т.д. У нас вимірюється тривалість процесів, кількість циклів, кількість учасників, кількість повернень, кількість запитів на зміну термінів. І цю інформацію дуже корисно аналізувати, щоб розуміти, які процеси на підприємстві відбуваються та підвищувати ефективність спільної роботи працівників.
На якому обладнанні ми це обробляємо?
Ці цифри говорять про значний обсяг завдань, так що перед нами постала необхідність виділити під потреби внутрішнього ДО досить продуктивне обладнання. На поточний його характеристики такі: 38 ядер, 240 Гб ОЗУ, 26 Тб дисків. Наводимо таблицю серверів:
Надалі ми плануємо нарощувати потужність обладнання.
Як справи із завантаженням серверів?
Мережева активність ніколи не була проблемою ні в нас, ні в наших замовників. Як правило, слабке місце – це процесор та диски, тому що з нестачею пам'яті все вже боротися вміють. Наведемо скріншоти наших серверів із Resource Monitor, на яких видно, що у нас ніякого страшного навантаження немає, воно дуже скромне.
Наприклад, на скріншоті нижче ми бачимо SQL-сервер, де ЦПУ завантажено на 23%. І це дуже добрий показник (для порівняння: якщо завантаження наближатиметься до 70%, то, швидше за все, співробітники спостерігатимуть досить суттєві уповільнення роботи).
На другому скріншоті показаний сервер додатків, на якому працює платформа 1С:Підприємство - він обслуговує тільки сеанси користувача. Тут навантаження процесора дещо більше – 38%, воно рівне і спокійне. Завантаження диска є, але воно прийнятне.
Третій скріншот показує ще один сервер 1С:Підприємства (він другий, у нас їх два в кластері). Лише попередній обслуговує користувачів, а на цьому працюють роботи. Наприклад, приймають пошту, маршрутизують документи, виконують обмін даними, вважають права тощо. Усі ці фонові активності виконують приблизно 90-100 фонових завдань. І цей сервер завантажений дуже сильно – на 88%. Але на людях це не позначається, і він реалізує якраз усю ту автоматику, яку має робити документообіг.
Які є метрики визначення ефективності роботи?
У нас в ДО вбудована серйозна підсистема вимірювання показників продуктивності та обчислень різних метрик. Це потрібно для того, щоб і зараз, і в історичній перспективі розуміти, що в системі відбувається, що стає гірше, що стає краще. Засоби моніторингу – метрики та виміри часу – входять до типового постачання «1С:Документообіг 8». Метрики вимагають налаштування на впровадженні, але сам типовий механізм.
Метрики – це вимірювання різних бізнес-показників у ті чи інші моменти часу (наприклад, середній час доставки пошти у моменті 10 хвилин).
Одна з метриків показує кількість активних користувачів у базі. У середньому їх 1000–1400 протягом дня. На графіку видно, що на момент скріншоту в базі було 2144 активних користувача.
Таких дій більше ніж 30, список під катом.перелік
- Вхід в систему
- Вихід із системи
- Завантаження пошти
- Зміна дійсності об'єкта
- Зміна прав доступу
- Зміна предмета процесу
- Зміна робочої групи об'єкта
- Зміна складу комплекту
- Зміна файлу
- Імпорт файлу
- Відправлення поштою
- Переміщення файлів
- Перенаправлення завдання
- Підписання ЕП
- Пошук за реквізитами
- Повнотекстовий пошук
- Отримання файлу
- Переривання процесу
- Перегляд
- Розшифрування
- Реєстрація документа
- сканування
- Зняття позначки видалення
- Створення об'єкту
- Збереження на диск
- Старт процесу
- Видалення записів протоколу роботи користувачів
- Видалення підпису ЕП
- Встановлення позначки видалення
- Зашифрування
- Експорт папки
Позаминулого тижня у нас середня активність користувачів збільшилася у півтора рази (на графіку показана червоним) – це пов'язано з переходом більшості співробітників на віддалену роботу (у зв'язку з відомими подіями). Також кількість активних користувачів збільшилася в 3 рази (на скрині показані синім), оскільки співробітники почали активно користуватися мобільними: кожен мобільний клієнт створює підключення до сервера. Зараз у середньому кожного нашого співробітника припадає 2 підключення до серверу.
Для нас, як для адміністраторів, це сигнал, що потрібно уважніше ставитись до питань швидкодії, дивитися, чи не стало гірше. А ми дивимося це за іншими параметрами. Наприклад, як змінюється час доставки пошти з внутрішньої маршрутизації (на скріншоті нижче показано синім). Ми бачимо, що воно до цього року стрибало, а зараз стабільне – для нас це показник, що із системою все гаразд.
Ще одна прикладна метрика для нас – середній час очікування завантаження листів із поштового сервера (на скріншоті показано червоним). Грубо кажучи, скільки лист буде гуляти по Інтернету, перш ніж він виявиться у нашого співробітника. На скріншоті видно, що цей час теж не змінився останнім часом. Є окремі сплески - але вони пов'язані не із затримками, а з тим, що час збивається на поштових серверах.
Або, наприклад, ще метрика (на скріншоті показано синім) – оновлення листів у папці. Відкриття папки листів – дуже часта операція, і потрібно, щоб вона виконувалася швидко. Ми вимірюємо, з якою швидкістю вона виконується. Цей показник вимірюється кожному за клієнта. Можна подивитися як загальну картину по фірмі, так і динаміку, наприклад, окремого співробітника. По скріншоту видно, що до цього року метрика була неврівноважена, потім ми зробили низку покращень, і зараз вона не стає гіршою – практично рівний графік.
Метрики – це в основному інструмент адміністратора для моніторингу системи, для швидкого реагування на якісь зміни у поведінці системи. На скріншоті – метрики внутрішнього ДО протягом року. Стрибок на графіках обумовлений тим, що перед нами поставили завдання щодо розвитку внутрішнього ДО.
Ось перелік ще деяких метриків (під катом).
Метрики
- Активність користувачів
- Активні користувачі
- Активні процеси
- Кількість файлів
- Розмір файлів (Мб)
- Кількість документів
- Кількість об'єктів для надсилання адресатам
- Кількість контрагентів
- Невиконані завдання
- Середній час очікування завантаження листів із поштового сервера за останні 10 хвилин
- Зовнішній буфер даних: кількість файлів
- Відставання кордону від поточної дати
- Довга черга
- Оперативна черга
- Вік необробленого облікового запису із зовнішньої маршрутизації
- Розмір черги приймання з внутрішньої маршрутизації (довга черга)
- Розмір черги приймання з внутрішньої маршрутизації (швидка черга)
- Час доставки пошти з внутрішньої маршрутизації (довга черга)
- Час доставки пошти з внутрішньої маршрутизації (швидка черга)
- Час доставки пошти із зовнішньої маршрутизації (середня)
- Кількість документів Бронювання
- Кількість документів Відсутність
- Число документів «Запис про роботу з контрагентом»
- Пошта Оновлення листів у папці
- Пошта Відкриття картки листа
- Пошта Перенесення листа до папки
- Пошта Перехід по папкам
Наша система цілодобово вимірює понад 150 показників, але не всі з них можна оперативно відстежувати. Вони можуть стати в нагоді потім, в якійсь історичній перспективі, а зосередитися можна на найважливіших для бізнесу.
На одному із впроваджень було обрано, наприклад, лише 5 показників. Замовник поставив собі за мету зробити мінімальний набір показників, але в той же час такий, щоб він покривав основні сценарії роботи. Включати до акту прийому 150 показників було б невиправдано, тому що навіть усередині підприємства складно узгодити, які показники вважати прийнятними. А про ці 5 показників вони знали та вже пред'являли їх до системи до початку проекту впровадження, включивши до конкурсної документації: час відкриття картки не більше 3 секунд, час виконання завдання з файлом не більше 5 секунд тощо. У нас в ДО були метрики, які дуже чітко відображали вихідний запит із ТЗ замовника.
А ще маємо профільний аналіз вимірів продуктивності. Показники продуктивності – це фіксація тривалості кожної операції, що виконується (запис листа в базу, відправка листа на поштовий сервер і т.д.). Це використовується виключно технічними фахівцями. Показників продуктивності у нас у програмі накопичується дуже багато. Зараз ми вимірюємо приблизно 1500 ключових операцій, які розбиті за профілями.
Один із найважливіших для нас профілів – «Список ключових показників пошти з погляду споживачів». Цей профіль включає, наприклад, такі показники:
- Виконання команди: Відбір за тегом
- Відкриття форми: Форма списку
- Виконання команди: Відбір за папкою
- Відображення листа з читання
- Збереження листа до улюбленої папки
- Пошук листів з реквізитів
- Створення листа
Якщо ми бачимо, що метрика за якимось бізнес-показником стала надто великою (наприклад, листи від конкретного користувача почали надходити дуже довго), ми починаємо розбиратися, звертаємось до замірів часу технічних операцій. Ми маємо технічну операцію «Архівація листів на поштовому сервері» – бачимо перевищення часу цієї операції за останній період. Ця операція, своєю чергою, розкладається інші операції – наприклад, встановлення з'єднання з поштовим сервером. Бачимо, що вона чомусь раптом стала дуже великою (у нас усі виміри є за місяць – можемо порівняти, що минулого тижня 10 мілісекунд, а зараз 1000 мілісекунд). І розуміємо, що щось тут зламалося – треба виправляти.
Як ми обслуговуємо таку велику базу даних?
Наш внутрішній ДО – приклад високонавантаженого проекту, що реально працює. Розповімо про технічні особливості його бази даних.
Скільки часу триває реструктуризація великих таблиць бази даних?
SQL-сервер вимагає періодичного обслуговування, наведення порядку у таблицях. По-хорошому це потрібно робити щонайменше раз на добу, а для високозатребуваних таблиць - ще частіше. Але якщо база велика (а в нас кількість записів уже перевищила 11 млрд.), то доглядати її непросто.
Ми робили реструктуризацію таблиць 6 років тому, але потім вона почала займати стільки часу, що ми вже не вписувалися в нічні інтервали. Оскільки ці операції сильно навантажують SQL-сервер, він може якісно обслуговувати інших користувачів.
Тому зараз нам доводиться застосовувати різноманітні хитрощі. Наприклад, ми не можемо виконувати ці процедури на повному наборі даних. Доводиться вдаватися до процедури Update Sample 500000 14 rows - це займає XNUMX хвилин. Вона виконує оновлення статистики за всіма даними таблиці, а відбирає півмільйона рядків, і з них розраховує статистику, яку використовує для таблиці. Це деяке припущення, але ми змушені на нього йти, тому що для конкретної таблиці збір статистики по всьому мільярду записів буде неприйнятно тривалий час.
Інші операції обслуговування ми також оптимізували, зробивши їх частковими.
Обслуговування СУБД – це складне завдання. У разі активної взаємодії співробітників база швидко розростається, адміністраторам стає все важче обслуговувати її - робити оновлення статистики, дефрагментацію, індексацію. Тут треба застосовувати різні стратегії, ми добре знаємо, як це робити, ми маємо досвід, ми можемо їм ділитися.
Як реалізований бекап за таких обсягів?
Повний бекап СУБД проводиться щодня вночі, інкрементальний – щогодини. Також кожен день створюється каталог файлів і він є порцією інкрементального бекапа файлового сховища.
Скільки часу виконується повний бекап?
На жорсткий диск повний бекап виконується за три години, частковий за годину. На стрічку пишеться довше (спецпристрій, який робить резервну копію на спеціальну касету, що зберігається поза офісом; на стрічку роблять копію, що відчужується, яка збережеться, якщо, наприклад, серверна згорить). Бекап робиться рівно на тому ж сервері, параметри якого були вищими - SQL-сервер з 20% завантаження процесора. На момент бекапу, звичайно, системі стає значно гірше, але вона все одно працездатна.
Чи є дедуплікація?
файлів є, обкатуємо її на собі, і незабаром вона увійде до нової версії Документообігу. Також обгортаємо на собі механізм дедуплікації контрагентів. Дедуплікації записів лише на рівні СУБД немає, оскільки у цьому немає потреби. Платформа 1С:Підприємство зберігає в СУБД об'єкти, і тільки платформа може відповідати за їхню узгодженість.
Чи є ноди тільки для читання?
Нід для читання (виділені вузли системи, які обслуговують тих, кому треба отримувати будь-які дані на читання) немає. ДО – не облікова система, щоб садити на окрему ноду BI, але є окрема нода для відділу розробки, обмін з якою йде повідомленнями у форматі JSON, а типовий час реплікації – це одиниці та десятки секунд. Нода поки маленька, в ній близько 800 млн. записів, але вона швидко росте.
А помічені видалення листи зовсім не видаляються?
Поки немає. Завдання полегшити базу ми не маємо. Було кілька досить серйозних випадків, коли доводилося звертатися до позначених видалення листів, у тому числі і 2009 року. Тому поки що вирішили зберігати все. А ось коли вартість цього стане невиправданою, думатимемо про видалення. Але, якщо потрібно якийсь окремий лист видалити з бази з кінцями, щоб не було жодних слідів, то це можна зробити за спецзапитом.
А навіщо це зберігати? Чи є статистика звернень до старих документів?
Саме статистики немає. Точніше вона є у вигляді протоколу роботи користувачів, але він зберігається недовго. Записи старіші за рік стираються з протоколу.
Ситуації, коли треба було підняти старе листування п'ятирічної та навіть десятирічної давності, були. І це завжди робилося не з марної цікавості, а для прийняття складних бізнес-рішень. Був випадок, коли без історії листування було прийнято неправильне бізнес-рішення.
Як проводиться експертиза цінності та знищення документів згідно з термінами зберігання?
Для паперових документів це робиться традиційним методом, як і в усіх. Для електронних не робимо – хай собі зберігаються. Місце є. Користь є. Усім добре.
Які є перспективи розвитку?
Наразі наш ДО вирішує приблизно 30 внутрішніх завдань, частину яких ми перераховували на початку статті. Також ДН використовується для підготовки конференцій, які ми двічі на рік проводимо для наших партнерів: вся програма, усі доповіді, усі паралельні секції, зали – все це верстається до ДН, а потім вивантажується з нього, і робиться друкована програма.
На підході для ДО ще кілька завдань, крім тих, що він вирішує. Є загальнофірмові завдання, а є унікальні та рідкісні, потрібні лише якомусь конкретному підрозділу. Необхідно їм допомагати, отже, розширювати «географію» використання системи всередині 1С – розширювати сферу застосування, вирішувати завдання всіх підрозділів. Це стало б найкращим тестом на продуктивність та надійність. Хотілося б побачити роботу системи на трильйонах записів, петабайтах інформації.
Джерело: habr.com