Успішний проєкт для великого ENTERPRISE-клієнта — це не просто гарний кейс, золота медаль і слава на фініші. Це марафонська дистанція підвищеної складності, на якій чекає безліч сюрпризів. До фінішу добігають небагато команд. Ми добігли — і готові розповісти, як це було.
Що таке ENTERPRISE-марафон
Перш ніж перейти до самого проєкту, варто назвати речі своїми іменами. Ось із чим стикається команда на такій дистанції.
- Складні бізнес-процеси з нестандартною логікою — у найнесподіваніших місцях і в зовсім непристойній кількості.
- Нестандартна, можна навіть сказати — несподівана поведінка добре знайомого програмного забезпечення, яке ніколи так не поводилося в типових проєктах.
- Стрімке зростання додаткових вимог уже після затвердження технічного завдання.
- Інтеграції з найекзотичнішими інформаційними та обліковими системами.
- Випробування найсуворішим контролем з боку замовника за умовами інформаційної безпеки.
- Довгий перелік формальностей щодо погодження й документування змін.
І це ще далеко не повний список.
Про замовника
Публічне акціонерне товариство «Укртелеком» — одна з найбільших компаній України, що надає повний спектр телекомунікаційних послуг в усіх регіонах країни. Особливо сильні позиції товариство має на ринку послуг доступу до мережі Інтернет і фіксованої телефонії: «Укртелеком» є лідером ринку швидкісного фіксованого доступу до Інтернету та посідає провідні позиції на ринку фіксованої телефонії.
ПАТ «Укртелеком» створило найпотужнішу в Україні національну магістральну мережу передавання даних, побудовану на базі сучасної технології DWDM. Саме вона дозволяє надавати споживачам сучасні телекомунікаційні послуги майже в усіх населених пунктах України.
Сьогодні до складу ПАТ «Укртелеком» входить 33 філії, зокрема 27 регіональних. Компанія володіє первинною мережею, магістральними та зоновими лініями зв'язку й надає всі види основних і найсучасніших телекомунікаційних послуг — міжнародний, міжміський і місцевий телефонний зв'язок, дротове мовлення, радіозв'язок, радіомовлення й телебачення, документальний електрозв'язок, відеоконференцзв'язок, супутниковий зв'язок, надання в оренду цифрових каналів, ATM/Frame Relay, ISDN, доступ до Інтернету.
Завдання проєкту
У 2015 році команда ANIART розпочала роботи з упровадження внутрішнього корпоративного порталу для ПАТ «Укртелеком» — на базі корпоративної платформи для внутрішніх порталів, у редакції для холдингових структур.
Вимоги верхнього рівня замовник сформулював за шістьма напрямами.
Комунікації
Організація майданчика для ефективних внутрішньокорпоративних комунікацій.
Task management
Упровадження операційної системи обліку завдань середнього рівня: завдання, облік часу, виконавська дисципліна.
База знань
Можливість розміщення та зберігання корпоративно значущої інформації на єдиному інформаційному ресурсі. Реалізація процесів для контрольованого розміщення нових даних, ефективної систематизації матеріалів і пошуку інформації.
Навчання персоналу
Упровадження системи навчання та мотивації персоналу.
PR і корпоративна культура
Розвиток корпоративної культури та створення ефективного інструменту внутрішньокорпоративного PR.
Бізнес-процеси
Ефективне інформування про нові процеси та зміни в компанії.
Операційні вимоги
- Забезпечення одночасної роботи співробітників, які мають доступ до корпоративних інформаційних систем, — до 4000 осіб.
- Доступ до інформації для службового користування про співробітників компанії та можливість електронного погодження документів з кадрових питань: зарахування до штату, переведення, звільнення, оплата праці, пільги, мотивація, навчання, розвиток, адаптація, лікарняні, відрядження тощо.
- Інформація про проєкти, функціональні напрями та підрозділи компанії.
- Розробка дизайну порталу з використанням корпоративного стилю ПАТ «Укртелеком».
- Урахування територіальної та структурної належності користувача.
- Багатофункціональність сторінок порталу за призначенням і рівнями доступу: сторінки водночас мають виступати як сторінки загального призначення, сторінки підрозділів, сторінки служб і персональні сторінки.
- Забезпечення підтримки мобільних пристроїв.
- Спадковість лінкування ресурсів порталу: під час переміщення ресурсів посилання на документи мають залишатися працездатними.
Перший етап: мінімально достатній функціонал для старту
Щоб не повторити шаблон попереднього порталу, життєво важливо було максимально залучити співробітників до нового інформаційного простору. Спілкування має бути ефективним, а хорошу основу для цього забезпечує, за нашим досвідом, зрозуміле й упізнаване подання інформації про служби, підрозділи та співробітників.
Щоб запрацювала система допусків і дозволів, інформацію про співробітників потрібно було доповнити даними із системи безпеки. Завдання регулярної синхронізації кадрової системи підприємства плюс об'єднання даних про ролі та допуски стало для нас вирішально важливим.
Те, як зберігаються дані в кадровій системі, дуже сильно відрізняється від «гарної картинки» структури служб і відділів, яку бачить користувач у структурній схемі підприємства. Завдання суттєво ускладнювалося потребою багаторазової конвертації організаційної структури підприємства, щоб цю «гарну картинку» отримати.
Для ефективного управління кадрами ми розв'язували завдання перенесення на портал інформації про відвідуваність співробітників: планові та позапланові відсутності, відпустки, лікарняні. Ці дані потрібно було брати з облікової системи «Парус». А оскільки «Парус» не використовувався в невеликих регіональних підрозділах, дані про відсутність співробітників доводилося вводити безпосередньо на порталі. Це призвело до появи завдання двоспрямованої синхронізації.
Переміщення великих обсягів даних під час обміну та синхронізації потребувало впровадження журнального методу обміну: в обміні беруть участь лише змінені та нові записи, а записи з актуальністю понад два місяці переміщуються до архіву. Довелося внести зміни й до стандартного інтерфейсу системи — під час відображення «Графіка відсутностей» показуються записи лише вибраного підрозділу, без урахування дочірніх; «наскрізний режим» вимкнено.
Другий етап: системна архітектура та відмовостійкість
Основною складністю під час упровадження ENTERPRISE-системи, розрахованої на велику кількість користувачів (понад 24 000), було забезпечення належного рівня продуктивності та відмовостійкості. Оскільки портал планувався як основний засіб комунікації та взаємодії для компанії з великою кількістю співробітників, потрібне було серверне рішення з високим рівнем гарантованої відмовостійкості.
Архітектура кластерного рішення
Для розв'язання завдання швидкодії та відмовостійкості було створено серверний кластер. Кілька серверів мали статус «вебсервер» зі службами nginx, apache, memcached — вони об'єднувалися спільним сховищем сесій користувачів, реалізованим на redis. Кілька серверів мали статус «сервер БД» зі службою mysql. Сервери БД працювали в режимі master-master реплікації, а для підтримки реплікації використовувалася зв'язка percona + galera + проксувальний балансувальник HAProxy.
Користувачів порталу динамічно розподіляв між вебсерверами апаратний балансувальник. Кільком серверам було відведено роль «NAS» — мережевого сховища даних. Розроблена система контролю відстежувала стан кластера.
- Запит. Апаратний балансувальник динамічно спрямовує користувача на один із вебсерверів.
- Збій. Якщо внаслідок непередбачених обставин якийсь сервер не відповідає, запит повертається на балансувальник.
- Перемаршрутизація. Балансувальник вносить зміни до матриці доступності й передає запит на proxy/HAProxy.
- Відновлення. HAProxy знаходить працездатний екземпляр сервера й спрямовує запит на нього.
Для NAS застосували рішення на базі кластера з NFS-серверів за такою схемою. Два кластери NFS працюють за схемою master-slave. Збереження даних виконується на вузол master, slave синхронізується з інтервалом. Працездатність master перевіряється за допомогою служби NFS HeartBeat, а синхронізація даних здійснюється засобами lsyncd. Якщо настає непередбачена ситуація й master стає недоступним, slave автоматично переводиться в режим master.
Запас на зростання
В архітектуру закладався потенціал для подальшого зростання: «Укртелеком» — це компанія, що активно розвивається, з помітною тенденцією до щорічного збільшення кількості співробітників, а отже — і користувачів порталу. Ми розуміли, що зі збільшенням штату кількість кадрових подій зростає лінійно, а кількість операційних подій — лавиноподібно.
Реалізована архітектура дозволяла виконувати горизонтальне масштабування шляхом збільшення кількості серверів. Обмежень щодо кількості фізичних серверів не було.
На етапі відпрацювання системної архітектури та інтеграції із зовнішніми сервісами нам довелося розв'язати десятки завдань з підвищення продуктивності й пошуку вузьких місць на «стиках систем». Широко застосовувалися системи профілювання: відстежувалися скрипти з нестандартно великим часом виконання, і для них вмикалося профілювання. Загальний лог системи статистично аналізувався на частотність «повільних скриптів» — щоб виключити ситуації, коли оптимізують рідкісний повільний скрипт замість швидшого, але такого, що виконується часто.
Вимоги інформаційної безпеки та стандарти якості
Корпоративний портал — це система з персональними даними, комерційною та фінансовою інформацією. Коментарі щодо рівня безпеки тут зайві. Опрацьовувалося кілька сценаріїв можливого несанкціонованого проникнення; за кожним із них провели превентивні заходи та розписали регламенти дій у позаштатних ситуаціях.
- Вразливість системного оточення серверів.
- Отримання несанкціонованого доступу до консолі одного або одразу кількох серверів кластера.
- Вразливість на рівні прикладного ПЗ.
- Отримання несанкціонованого доступу до CMS.
Для автентифікації використовувався централізований сервіс LDAP. Застосовували також шифрування трафіку, фаєрволи та структуру роздільного зберігання персональних даних із денормалізацією — це потребувало зміни логіки роботи базових класів платформи, але всі вимоги було виконано.
Стандарти системи якості
Великі компанії завжди використовують стандарти системи забезпечення якості (ISO), один з яких описує вимоги до системи запису дій користувачів: там є чіткі вимоги до такої системи й перелік дій та подій, які мають журналюватися. Нам довелося розв'язувати завдання розширення наявної системи журналювання платформи до відповідності вимогам ISO — тобто завдання запису великого потоку подій, зберігання та пошуку у масивах даних. Протягом дня портал генерував до мільйона подій, і для їх запису використовувалася БД зі швидкою системою збереження.
У результаті ми отримали систему з можливостями пошуку подій за типами, джерелами, користувачами та часовими інтервалами.
Друга вимога, яку довелося врахувати, — необхідність отримання від користувачів дозволу на публікацію та обробку персональних даних. Було реалізовано спеціальний інтерфейс, який запитував згоду на обробку й публікацію персональних даних під час першого сеансу використання порталу, після чого зберігав усі часові мітки цієї події у спеціальному сховищі.
Третій етап: удосконалення користувацького інтерфейсу
ENTERPRISE-клієнт відрізняється підвищеними вимогами до якості. Історії використання типових сценаріїв у великих організаціях глибоко опрацьовані, тому замовник вимагає повної відповідності впроваджуваного рішення наявним бізнес-процесам. А користувацький інтерфейс у корпоративних замовників — на особливому рахунку: він має відповідати вигляду, до якого звикли користувачі. На цьому етапі багато стандартних системних інтерфейсних рішень довелося допрацьовувати під вимоги user cases — історій реального використання.
Фотографії співробітників
Для швидкої адаптації до нових інтерфейсів ми вирішили імпортувати з LDAP фотографії співробітників, давши при цьому кожному змогу змінити своє фото на порталі. Фотографії авторів з'являлися в повідомленнях і завданнях, а це дуже важливо у великій інформаційній системі підприємства: сприйняття текстової інформації (ім'я та прізвище) сильно відстає від сприйняття легковпізнаваних фотографій колег. Паралельно це розв'язувало проблему плутанини, коли люди мають однакову комбінацію імені та прізвища — по батькові колег, як правило, мало хто знає.
Підтвердження ознайомлення
Одним із завдань упровадження було інформування про нові процеси та зміни в компанії. Для цього знадобився механізм підтвердження ознайомлення співробітників з матеріалами, статистика ознайомлення та можливість отримання списків співробітників із часовими позначками. Механізм забезпечував публікацію персональних сповіщень і фіксував дату й час усіх дій співробітників з матеріалами, що потребують підтвердження ознайомлення.
Обмеження на публічні повідомлення
Щоб упровадження порталу не дало зворотного ефекту й портал не перетворився на велику «флудилку» з десятками публічних повідомлень, адресованих «усім», щохвилини, постало завдання розробити обмеження на створення таких повідомлень рядовими користувачами. Доступ на створення подібних публікацій обмежили спеціальними ролями для кожного підрозділу: на рівні підрозділу лише один співробітник міг мати права на створення публічних повідомлень. А щоб це правило не можна було обійти, ввели обмеження на кількість адресатів повідомлення.
Подяки та заохочення
Щоб портал став справді єдиним інформаційним простором, до нього перенесли багато функцій HR-відділу — зокрема публічне інформування про досягнення й успіхи співробітників: було реалізовано близько десятка видів подяк та індивідуальних заохочень. Це одразу позначилося на залученості співробітників до роботи з порталом і на розвитку командного духу — зростання активності негайно відобразилося в аналітиці.
Водночас ми допрацювали профіль користувача — реалізували відображення керівників і підлеглих на персональних сторінках співробітників.
Було реалізовано також потенціал внутрішнього кар'єрного зростання: на порталі почали публікуватися всі наявні в компанії вакансії, а в співробітників з'явилася можливість запропонувати свою кандидатуру. Оскільки інформація щодо кожного співробітника була інтегрована в портал, йому не потрібно було писати резюме — достатньо було запропонувати свою кандидатуру, а необхідною інформацією для аналізу відділ кадрів уже володів.
Документування проєкту
Документація життєво необхідна в проєктах класу ENTERPRISE. Вона дає загальне бачення системи під час планування змін, з нею легко занурити в проєкт нового розробника — одні й ті самі спеціалісти не займатимуться одним проєктом роками.
Природною вимогою замовника було надання користувацької документації, інструкцій з обслуговування системи та сценаріїв дій в особливих ситуаціях. У результаті ми виконали велику роботу: описали й передали замовнику технічний проєкт порталу та інструкції з його використання. Загальний обсяг виготовленої документації склав близько двохсот сторінок. До документації також увійшли матеріали щодо комплексу приймальних випробувань — понад 100 тестів.
Була виконана величезна робота, і тепер ми з упевненістю можемо сказати, що замовник підготовлений до дій у будь-яких ситуаціях — стандартних і нестандартних. Сценарії використання порталу та його обслуговування розроблені детально й неодноразово опрацьовані на практиці.Леонід Сидоренко, QA-інженер
Результати й висновки
Про що добре знати на старті
Не варто сліпо покладатися на стандартні підходи, описані в матеріалах постачальників прикладного ПЗ, і на типові варіанти розв'язання. На жаль, здебільшого вони доволі «теоретичні» й дуже далекі від реальних кейсів. Найважливіше джерело практичної інформації — реальні кейси схожих проєктів. Тут важливо контактувати з безпосередніми учасниками таких проєктів: вони можуть дати цінні деталі, здатні змінити всю картину.Артем Волков, розробник ANIART
Великі проєкти — це завжди складна архітектура, високе навантаження та велика фінансова відповідальність. Тому весь критичний функціонал обов'язково потрібно покривати тестами — це дозволяє запобігти потенційним проблемам у майбутньому.
Хочемо відзначити надзвичайно високий рівень технічної компетенції наших колег з «Укртелекому» — це професіонали з великим досвідом. Ми говорили з ними однією мовою: і щодо бізнес-завдань, і щодо технічних питань.Валентин Кертичак, керівник проєкту з боку ANIART
Нам вдалося розв'язати всі завдання, що стояли перед проєктом. Складнощі, які виникали, долалися невідкладно й оперативно. І ми з повною впевненістю запускаємо портал у планову експлуатацію.Юрій Гучек, керівник проєкту з боку «Укртелекому»
Команда проєкту
Команда ефективно працювала протягом восьми місяців і отримала відмінний результат.
| Учасник | Роль |
|---|---|
| Валентин Кертичак | Керівник проєкту |
| Олександр Купрін | Провідний розробник ANIART |
| Сергій Горлов | Провідний розробник ANIART |
| Артем Волков | PHP-розробник ANIART |
