Мы ў фірме 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
- Візы ўзгаднення - 11 821
- Уваходныя дакументы – 79 677
- Выходныя дакументы - 28 357
- Запісы аб падзеях у працоўных календарах карыстальнікаў – 168 228
- Заяўкі на кур'ераў - 21 883
- Кантрагенты - 81
- Запісы аб рабоце з контрагентамі - 45 632
- Кантактныя асобы контрагентаў - 41 795
- Мерапрыемствы - 10 243
- Праекты - 6 320
- Задачы супрацоўнікаў - 245 980
- Паведамленні на форуме – 26 282
- Паведамленні ў чаце - 891
- Бізнес-працэсы - 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 ключавых аперацый, якія разбіты па профілях.
Адзін з найбольш важных для нас профіляў - "Спіс ключавых паказчыкаў пошты з пункту гледжання спажыўцоў". Гэты профіль уключае ў сябе, напрыклад, наступныя паказчыкі:
- Выкананне каманды: Адбор па тэгу
- Адкрыццё формы: Форма спісу
- Выкананне каманды: Адбор па тэчцы
- Адлюстраванне ліста ў вобласці чытання
- Захаванне ліста ў каханую тэчку
- Пошук лістоў па рэквізітах
- Cтварэнне ліста
Калі мы бачым, што метрыка па нейкім бізнес-паказчыку стала занадта вялікай (напрыклад, лісты ад канкрэтнага карыстальніка сталі прыходзіць вельмі доўга), мы пачынаем разбірацца, звяртаемся да замераў часу тэхнічных аперацый. У нас ёсць тэхнічная аперацыя "Архівацыя лістоў на паштовым серверы" - бачым перавышэнне часу гэтай аперацыі за апошні перыяд. Гэтая аперацыя, у сваю чаргу, раскладваецца на іншыя аперацыі - напрыклад, усталёўка злучэння з паштовым серверам. Бачым, што яна чамусьці раптам стала вельмі вялікай (у нас усе замеры ёсць за месяц - можам параўнаць, што на мінулым тыдні 10 мілісекунд, а зараз 1000 мілісекунд). І разумеем, што нешта тут паламалася - трэба выпраўляць.
Як мы абслугоўваем такую вялікую базу дадзеных?
Наш унутраны ДА - прыклад рэальна працуе высоканагружанага праекта. Раскажам аб тэхнічных асаблівасцях яго базы даных.
Колькі часу ідзе рэструктурызацыя вялікіх табліц базы даных?
SQL-сервер патрабуе перыядычнага абслугоўвання, навядзенні парадку ў табліцах. Па-добраму гэта трэба рабіць мінімум раз у суткі, а для высоказапатрабаваных табліц - яшчэ часцей. Але калі база вялікая (а ў нас колькасць запісаў ужо пераваліла за 11 млрд.), то даглядаць яе няпроста.
Мы рабілі рэструктурызацыю табліц 6 гадоў таму, але потым яна стала займаць столькі часу, што мы ўжо не ўпісваліся ў начныя інтэрвалы. А бо гэтыя аперацыі моцна нагружаюць SQL-сервер, ён не можа якасна абслугоўваць іншых карыстачоў.
Таму зараз нам даводзіцца прымяняць розныя хітрыкі. Напрыклад, мы не можам выконваць гэтыя працэдуры на поўных наборах даных. Даводзіцца звяртацца да працэдуры Update Sample 500000 rows - гэта займае 14 хвілін. Яна выконвае абнаўленне статыстыкі не па ўсіх дадзеных табліцы, а адбірае паўмільёна радкоў, і па іх разлічвае статыстыку, якую выкарыстоўвае для ўсёй табліцы. Гэта некаторы дапушчэнне, але мы вымушаныя на яго ісці, таму што для канкрэтнай табліцы збор статыстыкі па ўсім мільярды запісаў будзе выконвацца непрымальна доўгі час.
Іншыя аперацыі абслугоўвання мы таксама аптымізавалі, зрабіўшы іх частковымі.
Абслугоўванне СКБД - гэта наогул складаная задача. У выпадку актыўнага ўзаемадзеяння супрацоўнікаў, база хутка разрастаецца, адміністратарам становіцца ўсё цяжэй абслугоўваць яе - рабіць абнаўленні статыстыкі, дэфрагментацыю, індэксацыю. Тут трэба прымяняць розныя стратэгіі, мы добра ведаем, як гэта рабіць, у нас ёсць вопыт, мы можам ім дзяліцца.
Як рэалізаваны бэкап пры такіх аб'ёмах?
Поўны бэкап СКБД вырабляецца раз у дзень уначы, інкрыментальны - кожную гадзіну. Таксама кожны дзень ствараецца каталог файлаў, і ён з'яўляецца порцыяй інкрыментальнага бэкапу файлавага сховішча.
Колькі часу выконваецца поўны бэкап?
На цвёрдую кружэлку поўны бэкап выконваецца за тры гадзіны, частковы – за гадзіну. На стужку пішацца даўжэй (спецпрылада, якое робіць рэзервовую копію на адмысловую касету, якая захоўваецца па-за офісам; на стужку робяць якая адчужаецца копію, якая захаваецца, калі, напрыклад, серверная згарыць). Бэкап робіцца роўна на тым жа серверы, параметры якога былі вышэй - SQL-сервер з 20% загрузкі працэсара. На момант бэкапу, вядома ж, сістэме становіцца значна горш, але яна ўсё роўна працаздольная.
Ці ёсць дэдуплікацыя?
файлаў ёсць, абкочваем яе на сабе, і хутка яна ўвойдзе ў новую версію Дакументазвароту. Таксама абкочваем на сабе механізм дэдуплікацыі контрагентаў. Дэдуплікацыі запісаў на ўзроўні СКБД няма, бо ў гэтым няма неабходнасці. Платформа 1С: Прадпрыемства захоўвае ў СКБД аб'екты, і толькі платформа можа адказваць за іх узгодненасць.
Ёсць ноды толькі для чытання?
Нод для чытання (вылучаныя вузлы сістэмы, якія абслугоўваюць тых, каму трэба атрымліваць якія-небудзь дадзеныя на чытанне) няма. ДА - не ўліковая сістэма, каб саджаць на асобную ноду BI, але ёсць асобная нода для аддзела распрацоўкі, абмен з якой ідзе паведамленнямі ў фармаце JSON, а тыповы час рэплікацыі - гэта адзінкі і дзясяткі секунд. Нода пакуль маленькая, у ёй каля 800 млн запісаў, але яна хутка расце.
А пазначаныя на выдаленне ліста зусім не выдаляюцца?
Пакуль няма. Задачы аблегчыць базу ў нас няма. Было некалькі даволі сур'ёзных выпадкаў, калі даводзілася звяртацца да пазначаных на выдаленне лістоў, у тым ліку і ў 2009 годзе. Таму пакуль вырашылі захоўваць усё. А вось калі кошт гэтага стане неапраўданым, будзем думаць пра выдаленне. Але, калі трэба нейкі асобны ліст выдаліць з базы з канцамі, каб не было ніякіх слядоў, то такі можна зрабіць па спецзапыце.
А навошта гэта захоўваць? Ёсць статыстыка зваротаў да старых дакументаў?
Менавіта статыстыкі няма. Дакладней, яна ёсць у выглядзе пратакола працы карыстачоў, але ён захоўваецца нядоўга. Запісы старэйшыя за год сціраюцца з пратакола.
Сітуацыі, калі трэба было падняць старую перапіску пяцігадовай і нават дзесяцігадовай даўніны, былі. І гэта заўсёды рабілася не з бяздзейнай цікаўнасці, а для прыняцця складаных бізнэс-рашэнняў. Быў выпадак, калі без гісторыі перапіскі было б прынятае няправільнае бізнес-рашэнне.
Як праводзіцца экспертыза каштоўнасці і знішчэнне дакументаў згодна з тэрмінамі захоўвання?
Для папяровых дакументаў гэта робіцца звычайным традыцыйным спосабам, як і ва ўсіх. Для электронных не робім - няхай сабе захоўваюцца. Месца ёсць. Карысць ёсць. Усім добра.
Якія перспектывы развіцця ёсць?
Цяпер наш ДА вырашае прыкладна 30 унутраных задач, частка якіх мы пералічвалі ў пачатку артыкула. Таксама ДА выкарыстоўваецца для падрыхтоўкі канферэнцый, якія мы двойчы ў год праводзім для нашых партнёраў: уся праграма, усе даклады, усе паралельныя секцыі, залы - усё гэта вярстаецца ў ДА, а потым выгружаецца з яго, і робіцца друкаваная праграма.
На падыходзе для ПЕРАД яшчэ некалькі задач, акрамя тых, што ён ужо вырашае. Ёсць агульнафірмовыя задачы, а ёсць унікальныя і рэдкія, патрэбныя толькі нейкаму канкрэтнаму падраздзяленню. Неабходна ім дапамагаць, а значыць, пашыраць "геаграфію" выкарыстання сістэмы ўнутры 1С - пашыраць вобласць ужывання, вырашаць задачы ўсіх падраздзяленняў. Гэта стала б найлепшым тэстам на прадукцыйнасць і надзейнасць. Хацелася б убачыць працу сістэмы на трыльёнах запісаў, петабайтах інфармацыі.
Крыніца: habr.com