Чотири поверхи

Логістична компанія сиділа на Куренівці, у комплексі з трьох будівель: офіс (два поверхи), склад (один великий ангар), парковка вантажівок (просто двір з огорожею). На воротах — охоронник зі шлагбаумом, на стіні — табличка з логотипом, який я раніше бачив на бортах фур по місту.

Олександра я знайшов через знайому, яка працювала там бухгалтеркою. «Він раз на півроку дає інтерв'ю для якихось профільних видань про їхню ІТ-архітектуру. Запитай — погодиться».

Він погодився. Зустріч призначив на четвер після обіду. «Я тобі покажу все. У нас тут якраз цікаво: чотири типи клієнтів 1С одночасно, від товстого до мобільного. Подивишся, як це виглядає у реальному житті».

Я приїхав за чверть третя. Олександр зустрів у фойє — чоловік років сорока, синя сорочка з закатаними рукавами, окуляри, у руках горнятко з кавою. Виглядав як людина, у якій інженерія переважила менеджмент, але не до кінця.

— Підемо знизу вгору, — сказав він. — З підвалу. Там у нас серверна. А потім піднімемось до пілотів дронів. Жартую — у нас немає дронів. Поки що.

У підвалі було прохолодно, гуділи вентилятори, на стелажах — півтори стійки серверів за склом. Освітлення — синє, як завжди в серверних.

— Ось мозок. Дві ноди сервера 1С. Одна — продакшен, друга — тестова, ну і failover. DBMS під ними — Postgres Pro, збірка PostgreSQL під BAS. Ми перейшли на Postgres у дев'ятнадцятому. Раніше був SQL Server, але ліцензії стали кусатися. А після двадцять другого ми планово почали зменшувати залежність від західних комерційних вендорів узагалі — мало що завтра. У нас тепер усе, що можна тримати на opensource, тримається.

Він повернувся до однієї стійки, постукав по якомусь модулю.

— Тут — Apache Reverse Proxy. Через нього у нас іде тонкий клієнт через HTTPS. До дев'ятнадцятого року в нас всі сиділи на товстому клієнті через RDP — мали два термінальні сервери, ось тут вони ще стоять, як музей.

Я подивився на ще одну стійку: два сервери з вицвілими наліпками «TS01» і «TS02», явно не вмикалися рік.

— А чому RDP?
— А тому що інакше було не змасштабувати товстий клієнт. Уяви: вісімдесят бухгалтерів і менеджерів, кожен — на своєму ноутбуці. Кожен ноутбук — повноцінна копія 1С, яка постійно лізе в БД. Мережевий трафік — кошмар. Файлові операції, тимчасові кеші, кожен запит — туди-сюди. Через VPN з регіонального офісу — взагалі біда. У нас бухгалтери з Дніпра не могли працювати — пакети губилися.

— Рішення?
— RDP-ферма. Усі клієнти товстого 1С — на одному сервері в датацентрі. Користувачі — підключаються через термінал. По мережі ходить тільки картинка робочого столу. На клієнті — нуль навантаження. Це класична схема двохтисячних для масштабування товстого клієнта 1С. Велика частина України десь у п'ятнадцятому-двадцятому жила саме так.

— А коли перейшли на тонкий?

Олександр повів мене сходами нагору, на другий поверх — менеджерська зона. Опен-офіс, тридцять столів, на кожному — монітор. На моніторах — те, що я вже не міг не впізнати: вікно 1С:Підприємства, керовані форми, документи, накладні.

— У дев'ятнадцятому, — сказав він. — Великим проектом. Шість місяців. Чому: типова конфігурація, на якій ми сиділи, нарешті повністю перейшла на керовані форми. Що це значить?

Він зупинився перед монітором найближчого менеджера, який якраз заводив документ.

— Платформа 1С у вісімці-два розділила інтерфейс на два покоління: звичайні форми і керовані форми. Звичайні — це той інтерфейс, який бачили бухгалтери у двохтисячних. Жирні форми, на яких уся бізнес-логіка змішана з UI, виконуються лише у товстому клієнті. Керовані — це нове покоління, у якому форма явно розділена: серверна частина і клієнтська частина, з директивами &НаКлиенте, &НаСервере, &НаКлиентеНаСервере. Розробник пише код і явно каже, де він виконується.

— Це і є архітектурний поділ?
— Так. У товстому клієнті — клієнтський код виконується на ноутбуці бухгалтера, серверний — на сервері 1С. У тонкому — клієнтський код виконується на тонкому клієнті (це маленький .exe з мінімальним рантаймом), серверний — теж на сервері 1С. У веб-клієнті — клієнтський код виконується у браузері, переписаний у JavaScript автоматично платформою. У мобільному клієнті — клієнтський код виконується у мобільному додатку. Одна мова, чотири середовища виконання.

— Ого.
— Тільки є тонкощі. Не всі функції доступні в усіх клієнтах. У веб-клієнті немає COM-об'єктів, немає прямого доступу до файлової системи, є обмеження на роботу з диском. У мобільному — теж свої обмеження, плюс окрема компонента із власним набором об'єктів. Розробник, який пише на керованих формах, повинен тримати у голові, які функції є де. Інакше — серверний код, написаний для товстого, не запуститься у веб-клієнті.

— А переписувати типову зі звичайних форм на керовані — це наскільки боляче?

Олександр усміхнувся, як усміхається людина, яка згадує дуже неприємний досвід.

— Шість місяців. Команда — троє розробників плюс архітектор. Бюджет — двісті тисяч доларів. Це не вся типова — це наша доопрацьована типова з шестирічною історією модифікацій. Кожен наш кастомний звіт, кожна наша форма документа, кожна підписка — переписувалися. У типовій, яку постачальник давав, керовані форми вже були. У наших накатах — ні.

— А не можна було сидіти на старому?
— Можна. Але. Без тонкого клієнта нас би не пустили у віддалені офіси. Без веб-клієнта ми б не дали доступ нашим експедиторам, у яких корпоративний ноутбук від замовника-партнера. Без мобільного — водії б досі бігали з паперовими накладними. Перехід на керовані — це обов'язкова умова того, щоб платформа продовжувала рости разом з компанією. Не зробили б — застрягли б у двохтисячних і програли б ринок.

— Який був ROI?
— Я не міряв окремо. Але якщо взяти все разом — економію на термінальних серверах, можливість працювати з регіонів без VPN, мобільний для водіїв, веб-клієнт для зовнішніх — двісті тисяч окупилися десь за два роки. Зараз ми не уявляємо, як було б без цього.

Ми пройшли менеджерську зону, спустилися сходами вниз і вийшли через бічний вихід на парковку. Тут стояли вантажівки. Кілька — порожні, на стоянці. Одна — з відкритими дверима, біля кабіни — водій, років п'ятдесяти, з планшетом у руках.

— Це Володя, — сказав Олександр. — Володя, можна тебе на секунду? Я журналістові показую наш мобільний.

Володя простягнув мені планшет. Семидюймовий, з протиударним чохлом і ременем. На екрані — вже знайома мені інтерфейсна логіка 1С, тільки адаптована під дотик: великі кнопки, поля для заповнення, список накладних.

— Я з ним працюю з двадцять першого, — сказав Володя. — Перші пів року я звикав, лаявся. Тепер не можу без нього. Раніше ми мали папір — накладні, акти прийому, прибуткові. Підпис водія, підпис вантажника, печатка. Якщо втратив — переробляли. Раз на тиждень одна пачка зникала.

Він показав мені робочий процес. Натискає кнопку «Прийняти доставку», камера сканує QR-код на коробці, додаток підтверджує, що це той самий товар з накладної, водій ставить підпис прямо пальцем на екрані, тисне «Завершити», застосунок зберігає підписану накладну в локальній базі планшета. Коли він повертається на склад — синхронізація з сервером, документ автоматично проводиться в обліку.

— А офлайн?
— Більшу частину дня я в дорозі, — сказав Володя. — Десь у Київській області зв'язку немає. Працюю офлайн. Усе зберігається у планшеті. Коли потрапляю в зону покриття — синхронізується. Ні разу не загубив документ за чотири роки.

Я повернув планшет.

— Дякую, Володю, — сказав Олександр. — Не тримаємо тебе.

Володя пішов до своєї кабіни.

— Технічно це окрема історія, — сказав Олександр, поки ми йшли назад до офісу. — Мобільний клієнт у 1С — це не той самий додаток, що тонкий клієнт. Це окрема платформа, мобільна платформа, у якій є окрема компонента, своя локальна база, свій REST-обмін з сервером. Ти не береш типову Бухгалтерію і не запускаєш її на телефоні. Ти робиш окремий конфіг, у якому є тільки те, що потрібно водію: список накладних, прийом, доставка, підпис, фото. Це підмножина типової, переписана під мобільний.

— Хто це робив?
— Наш партнер. Окремий франчайзі, який спеціалізується саме на мобільних. У нас — стандартний BAS, тонкий клієнт. Мобільний — окремий проект. Інтеграція через REST: мобільний клієнт стукає у HTTP-сервіси, які ми написали в основній базі. Сервіси повертають JSON, мобільний показує. Підписані документи мобільний відсилає назад, основна база приймає і проводить.

— Це інакша архітектура.
— Так. Мобільний — це фактично окремий продукт, що тільки синхронізується з основним. У ньому свій рантайм, свій набір об'єктів, своя версійність. Платформа надає інструменти — але дисципліна архітектури лежить на тобі. Якщо не подумав про конфлікти при синхронізації — отримаєш у понеділок зранку чергу з тридцяти водіїв, у яких на планшеті — версія документа, яка вже не пройде, бо хтось у системі змінив прайс. Це нюанс, на який ми набили ґуль.

Ми зайшли назад в офіс. Олександр повів мене у переговорну на другому поверсі.

— Тепер про веб-клієнт. У нас він є, але для дуже вузької аудиторії. Експедитори наших партнерів — це люди, які працюють у замовника, в офісі замовника, на корпоративних ноутбуках замовника. На цих ноутбуках не можна ставити сторонній софт. Не можна навіть запустити .exe. Тому ми відкрили їм веб-клієнт.

— Як це виглядає?
— Вони відкривають Chrome, заходять на наш домен partners.{company}.com.ua, логіняться. Бачать ту ж саму 1С, що бачать наші менеджери, але через браузер. Інтерфейс — приблизно той самий. Швидкість — приблизно та сама. Платформа сама перетворює керовані форми у HTML+JavaScript і ганяє через WebSocket.

— А це працює нормально?
— Працює, але є нюанси. Веб-клієнт у 1С — це не зовсім веб-додаток у класичному сенсі. Це товста форма, упакована у браузер. Він не Single Page App, не реактивний UI, у ньому немає сучасних веб-патернів. За відчуттям — як SAP GUI for HTML. Працює, але виглядає по-старому. У Salesforce це справжній веб. У 1С — це сурогат. Для внутрішніх задач — ОК. Для клієнтського веб-додатку, який ти показуєш зовнішнім користувачам, — обмежено.

— Як це впливає на бізнес?
— Так і впливає. Наш веб-клієнт експедиторам — це внутрішній портал, не маркетинговий продукт. Якщо я завтра захочу зробити маркетингову веб-форму для замовлень — я не використаю 1С веб-клієнт. Я зроблю Laravel-вебсайт перед 1С, з нашим API, з нашим дизайном, з нашими швидкостями. 1С для цього не годиться. Платформа знає, що годиться, що ні.

— Підсумуй мені цю архітектуру, — попросив я. — Як ти її сам описуєш.

Олександр подумав.

— Чотири клієнти 1С — це одна метафора, чотири інкарнації. Усе те саме, що бачить бухгалтер у товстому, бачить менеджер у тонкому, бачить експедитор у браузері, бачить водій у мобільному. Але кожна інкарнація має свої сильні і слабкі сторони.

— Товстий — найшвидший, найповніший, найважчий. Потрібна локальна мережа або RDP. Для розробників і для бекофісу, де треба все.

— Тонкий — основний робочий клієнт сучасної 1С. Працює через інтернет, легкий, підтримує всі сценарії, окрім деяких низькорівневих. Для більшості користувачів.

— Веб — для тих, хто не може ставити софт. Дещо обмежений. Працює, але виглядає по-старому.

— Мобільний — окрема платформа з підмножиною функцій. Для виїзних, для офлайн, для тачскрін-сценаріїв. Окрема архітектура синхронізації.

— У цьому, — додав він, — і сила, і складність 1С. Сила — бо одна команда розробників пише код один раз, а доставка автоматично адаптується під чотири середовища. Складність — бо ти повинен це проектувати свідомо. Інакше — отримаєш товстий код, який не запуститься у браузері. Або серверний виклик у клієнтській процедурі, який підвішує веб. Або мобільний модуль, який не синхронізується.

Він допив каву.

— Дисципліна архітектури. Без неї платформа здається магічною, поки не лопне.

Я попрощався, вийшов з офісу, пройшов повз ворота зі шлагбаумом, вийшов на вулицю. Куренівка о шостій вечора — потоки фур, повз яких ішли пішоходи з покупками з найближчого «Сільпо».

Я думав про одне.

Усі попередні герої книги жили в одному з рівнів 1С. Антон на Лук'янівці — це переважно товстий клієнт або тонкий, на серверах франчайзі. Олег з автозапчастинами — товстий, на одному комп'ютері. Назар у коворкінгу — тонкий, у хмарі. Ірина у навчальному центрі — товстий, для розробки.

Олександр живе на всіх чотирьох одночасно. І це показує, що 1С — не одна технологія, а сімейство технологій, об'єднаних спільною мовою і метамоделлю. Це нетривіальне інженерне досягнення. Дуже мало хто з конкурентів — SAP, Oracle, Salesforce, Odoo — досяг такої гомогенності між десктопом, вебом і мобільним. Зазвичай це різні команди, різні мови, різні життєві цикли. У 1С — одна.

Це й робить платформу настільки інерційною. Якщо у тебе в роботі чотири клієнти від одного постачальника — мігрувати буде дуже важко. Бо мігрувати треба все одразу. Або частинами, які один в одного не дивляться. Або жити з гібридом, поки не лопне.

У наступному розділі я повернусь до самої моделі даних. До того, що Назар назвав «онтологією бізнесу, вшитою у виконуване середовище». До регістрів. До документів. До того, як це все думає про себе. У наступному розділі — «Чому це і ORM, і не ORM».