ЗаказчикПАО «Укртелеком» предоставляет полный спектр телекоммуникационных услуг во всех регионах страны. В состав компании входит 33 филиала, в том числе 27 региональных. ЗадачаЗадача — создать единый корпоративный портал для всех сотрудников Укртелеком, который бы выдерживал нагрузку в 400 пользователей, имел высокие показатели быстродействия и отказоустойчивости.
Успешный проект для крупного ENTERPRISE-клиента — это не просто красивый кейс, золотая медаль, почет на финише и слава после него — это марафонская дистанция повышенной сложности, где поджидает множество сюрпризов. Это и сложные бизнес-процессы с нестандартной логикой — в самых неожиданных местах и в совершенно неприличных количествах. И нестандартное, можно даже сказать — неожиданное поведение хорошо знакомого программного обеспечения, которое никогда не вело себя так в типовых проектах. И взрывной рост дополнительных требований после утверждения ТЗ. И интеграции с самыми экзотическими информационными и учетными системами. И испытание строжайшим контролем со стороны заказчика по условиям информационной безопасности. И длинный список формальностей по согласованию и документированию изменений. И еще много чего… Так что до финиша добегают немногие. Мы добежали. И готовы написать об этом.
Публичное акционерное общество «Укртелеком»
Одна из крупнейших компаний Украины, предоставляющая полный спектр телекоммуникационных услуг во всех регионах страны.
Особенно сильные позиции общество имеет на рынке услуг доступа к сети Интернет и фиксированной телефонии. ПАО «Укртелеком» является лидером рынка скоростного фиксированного доступа к сети Интернет и занимает ведущие позиции на рынке фиксированной телефонии.
ПАО «Укртелеком» создало самую мощную в Украине национальную магистральную сеть передачи данных, построенную на базе современной технологии DWDM, которая позволяет предоставлять потребителям современные телекоммуникационные услуги почти во всех населенных пунктах Украины.
Сегодня в состав ПАО «Укртелеком» входит 33 филиала, в том числе 27 региональных филиалов.
Владеет первичной сетью, магистральными и зоновыми линиями связи, предоставляет все виды основных и наиболее современных телекоммуникационных услуг — международная, междугородняя и местная телефонная связь, проводное вещание, радиосвязь, радиовещание и телевидение, документальная электросвязь, видеоконференцсвязь, спутниковая связь, предоставление в аренду цифровых каналов, ATM/Frame Relay, ІSDN, доступ к Интернету.
Задачи проекта
- Коммуникации — организация площадки для эффективных внутрикорпоративных коммуникаций.
- Task managment — внедрение операционной системы учета задач среднего уровня: задачи, учет времени, исполнительская дисциплина.
- База знаний — возможность размещения и хранения корпоративно значимой информации на едином информационном ресурсе. Реализация процессов для контролируемого размещения новых данных, эффективной систематизации материалов, поиска информации.
- Обучение персонала — внедрение системы обучения и мотивации персонала.
- PR и корпоративная культура — развитие корпоративной культуры и создание эффективного инструмента внутрикорпоративного PR.
- Бизнес процессы — эффективное информирование о новых процессах и изменениях в Компании.
Операционные задачи
- Обеспечение одновременной работы сотрудников, имеющих доступ к корпоративным информационным системам (до 4000 человек).
- Доступ к информации для служебного пользования о сотрудниках Компании и возможность электронного согласования документов по кадровым вопросам: зачисление в штат, перевод, увольнение, оплата труда, льготы, мотивация, обучение, развитие, адаптация, больничные, командировки и пр.
- Информация о проектах, функциональных направлениях и подразделениях Компании.
- Разработка дизайна Портала с использованием корпоративного стиля ПАО «Укртелеком».
- Учет территориальной и структурной принадлежности пользователя.
- Многофункциональность страниц Портала по своему предназначению и уровням доступа: страницы одновременно должны выступать как страницы общего назначения, страницы подразделений, страницы служб, персональные страницы.
- Обеспечение поддержки мобильных устройств.
- Преемственность линкования ресурсов Портала (при перемещении ресурсов ссылки на документы должны оставаться работоспособными).
В 2015 году команда «Aniart» начала работы по внедрению внутреннего корпоративного портала для ПАО «Укртелеком» на базе системы Битрикс24, редакция «Холдинг».
Первый этап
Минимально достаточный функционал для старта
Чтобы избежать повторения шаблона предшествующего портала, жизненно важно максимально вовлечь сотрудников в новое информационное пространство. Общение должно быть эффективным, а хорошую основу для этого обеспечивает, по нашему опыту, понятное и узнаваемое представление информации о службах, подразделениях и сотрудниках. Чтобы заработала система допусков и разрешений, информацию о сотрудниках необходимо было дополнить данными из системы безопасности. Задача регулярной синхронизации кадровой системы предприятия плюс объединение данных о ролях и допусках стала для нас решающе важной.
То, как хранятся данные в кадровой системе, очень сильно отличается от «красивой картинки» структуры служб и отделов для пользователей в структурной схеме предприятия. Задача сильно усложнялась необходимостью многократной конвертации организационной структуры предприятия для получения «красивой картинки».
Для эффективного управления кадрами решалась задача переноса на портал информации о посещаемости сотрудников: плановые и внеплановые отсутствия, отпуска, больничные. Эти данные необходимо было брать из учетной системы «Парус», а так как «Парус» не использовался в небольших региональных подразделениях, данные об отсутствии сотрудников пришлось вводить непосредственно на портале. Это привело к появлению задачи двунаправленной синхронизации.
Перемещение больших объемов данных при обмене и синхронизации потребовало внедрения «журнального метода обмена» — в обмене участвуют только измененные и новые записи, а записи с актуальностью более двух месяцев перемещаются в архив. Пришлось внести изменения в стандартный интерфейс системы — при отображении «Графика отсутствий» отображаются записи только выбранного подразделения без учета дочерних подразделений, отключен «сквозной режим».
Неожиданная проблема
Решение работало, но оказалось очень ресурсоемким, что впоследствии сыграло с нами злую шутку. Когда в момент запуска первых посетителей (около 4000 одновременных пользователей) сервис синхронизации периодически включался, потребляя много ресурсов — вся система значительно увеличивала время ответа. Сервис требовал рефакторинга и был переписан на минимизацию потребления ресурсов.
Второй этап
Системная архитектура и безопасность
Основной сложностью при внедрении ENTERPRISE-системы, рассчитанной на большое число пользователей (>24 000), было обеспечение должного уровня производительности и отказоустойчивости. Так как портал планировался как основное средство коммуникации и взаимодействия для компании с большим количеством сотрудников, необходимо было серверное решение, имеющее высокий уровень гарантированной отказоустойчивости.
Архитектура кластерного решения
Для решения задачи быстродействия и отказоустойчивости был создан серверный кластер. Несколько серверов имело статус «web-сервер» со службами nginx, apache, memcach — они объединялись совместным хранилищем сессий пользователей, реализованным на redis. Несколько серверов имело статус«сервер БД» со службой mysql. Сервера БД работали в режиме master-master репликации. Для поддержки репликации использовалась связка percona + galera + проксирующий балансировщик HAProxy.
В результате мы получили систему, обеспечивающую полноценную работу портала в режиме чтения/записи при наличии минимум 2-х серверов.
Пользователи портала динамически распределялись между веб-серверами с помощью аппаратного балансировщика. Нескольким серверам была отведена роль «NAS» — сетевого хранилища данных. Разработанная система контроля отслеживала состояние кластера: если в результате непредвиденных обстоятельств какой-либо сервер не отвечал, то запрос возвращался на балансировщик, который вносил изменения в матрицу доступности, перенаправлял запрос на proxy/HAProxy, который, в свою очередь, находил работающий экземпляр сервера и направлял запрос на него. В результате мы получили систему, обеспечивающую полноценную работу портала в режиме чтения/записи при наличии, как минимум, 2-х серверов.
Для NAS было применено решение на базе кластера из NFS-серверов по следующей схеме. Два кластера NFS работают по схеме «master-slave». Сохранение данных производится на «master»-узел, «slave» синхронизируется с интервалом. Работоспособность «master» проверяется с помощью службы NFS HeartBeat. Синхронизация данных осуществляется с помощью «lcyncd». При наступлении непредвиденных ситуаций, в которых «master» выходит из строя, «slave» автоматически переводится в режим «master».
В архитектуру закладывался потенциал для дальнейшего роста: «Укртелеком» — это активно развивающаяся компания с заметной тенденцией ежегодного увеличения числа сотрудников, а значит — и пользователей портала. Мы понимали, что при увеличении штата сотрудников количество кадровых событий растет линейно, а количество операционных событий — взрывообразно.
Реализованная архитектура позволяла выполнять горизонтальное масштабирование путем увеличения количества серверов. Ограничения по количеству физических серверов отсутствовали.
На этапе отработки системной архитектуры и интеграции с внешними сервисами нам пришлось решать десятки задач по повышению производительности и поиску узких мест на «стыках систем». Широко применялись системы профилирования: отслеживались скрипты с нестандартно большим временем выполнения, и для них включалось профилирование. Общий лог системы статистически анализировался на частотность «медленных скриптов», чтобы исключить ситуации с оптимизацией медленного скрипта, на практике выполняющегося редко, вместо оптимизации более быстрого скрипта, выполняющегося часто.
Выполнение требований службы безопасности
Корпоративный портал — это система с персональными данными, коммерческой и финансовой информацией. Комментарии касательно уровня безопасности здесь излишни. Прорабатывалось несколько сценариев возможного вторжения. По каждому из них были проведены мероприятия превентивного характера и расписаны регламенты действий в нештатных ситуациях.
Прорабатывались следующие сценарии:
- Уязвимость системного окружения серверов.
- Получение несанкционированного доступа к консоли одного или сразу нескольких серверов кластера.
- Уязвимость на уровне прикладного ПО.
- Получение несанкционированного доступа к CMS.
Для аутентификации использовался централизованный сервис LDAP. Применялось также шифрование трафика, файерволы, структура раздельного хранения персональных данных с денормализацией, что потребовало изменения логики работы базовых классов Биррикс24 —, но все требования были выполнены.
Cтандарты системы качества
Крупные компании всегда используют стандарты системы обеспечения качества (ISO), один из которых описывает требования к системе записи действий пользователей: описаны четкие требования к такой системе, перечислены действия и события, которые должны журналироваться. Нам пришлось решать задачу расширения имеющейся в Битрикс24 системы журналирования до соответствия требованиям ISO — решались задачи записи большого потока событий, хранения и поиска в массивах данных. В течение дня портал генерировал до миллиона событий — для их записи использовалась БД с быстрой системой сохранения.
В результате мы получили систему с возможностями поиска событий по типам, источникам, пользователям и временным интервалам.
Второе требование, которое пришлось учитывать — это необходимость получения от пользователей разрешения на публикацию и обработку персональных данных.
Был реализован специальный интерфейс, который запрашивал согласие на обработку и публикацию персональных данных при первом сеансе использования портала, после чего сохранял все временные метки этого события в специальном хранилище.
Третий этап
Совершенствование пользовательского интерфейса
ENTERPRISE-клиент отличается повышенными требованиями к качеству. Истории использования типовых сценариев в крупных организация глубоко проработаны, поэтому заказчик требует полного соответствия внедряемого решения имеющимся бизнес-процессам. И пользовательский интерфейс у корпоративных заказчиков — на особом счету. Интерфейс должен соответствовать виду, к которому привыкли пользователи.
На этом этапе много стандартных системных интерфейсных решений пришлось дорабатывать под требования user cases — историй реального использования.
Для быстрой адаптации к новым интерфейсам было принято решение импортировать из LDAP фотографии сотрудников, дав при этом возможность каждому сотруднику изменить свою фотографию на портале. Фотографии авторов появлялись в сообщениях и задачах, а это очень важно в большой информационной системе предприятия, потому что восприятие текстовой информации (имя и фамилия) сильно отстает от восприятия легкоузнаваемых фотографий коллег. Параллельно это решало проблему путаницы в случаях, когда люди имеют одинаковую комбинацию имени и фамилии (отчества коллег, как правило, мало кто знает).
Одной из задач внедрения было информирование о новых процессах и изменениях в Компании. Для этого потребовался механизм подтверждения ознакомления сотрудников с материалами, статистика об ознакомлении, возможность получения списков сотрудников с временными отметками об ознакомлении. Механизм подтверждения ознакомления сотрудников с новыми информационными материалами обеспечивал публикацию персональных уведомлений и фиксировал дату/время всех действий сотрудников с материалами, требующими подтверждения ознакомления.
Чтобы внедрение портала не дало обратный эффект и портал не превратился бы в большую «флудилку» с десятками публичных (адресованных «всем») сообщений ежеминутно, возникла задача разработки ограничений на возможность создания рядовыми пользователями портала сообщений, адресованных «всем». Доступ на создание таких публикаций ограничили специальными ролями для каждого подразделения. На уровне подразделения только один сотрудник мог иметь права для создания публичных сообщений. А для предотвращения возможности обхода данного правила было введено ограничение на количество адресатов для сообщения.
Чтобы портал стал по-настоящему единым информационным пространством, в него были перенесены многие функции HR-отдела, в частности — публичное информирование о достижениях и успехах сотрудников: было реализовано около десятка видов благодарностей и индивидуальных поощрений. Это тут же отразилось на вовлеченности сотрудников в работу портала, развитии командного духа — рост активности немедленно отразился в аналитике.
В то же время мы доработали профиль пользователя — реализовали отображение руководителей и подчинённых на персональных страницах сотрудников.
Был реализован также потенциал внутреннего карьерного роста — на портале стали публиковаться все существующие в Компании вакансии плюс у сотрудников появилась возможность предложения своей кандидатуры. Так как информация по каждому сотруднику была интегрирована в портал, ему не требовалось писать резюме — достаточно было предложить свою кандидатуру, а необходимой информацией для анализа отдел кадров уже располагал.
Документирование проекта
Документация жизненно необходима в проектах класса ENTERPRISE. Она дает общее видение системы при планировании изменений, с ней легко погрузить в проект нового разработчика — одни и те же специалисты не будут заниматься одним проектом годами.
Естественным требованием заказчика было предоставление пользовательской документации, инструкций по обслуживанию системы, сценариев действий в особых ситуациях. В результате нами была проделана большая работа — описан и предоставлен заказчику технический проект портала, инструкции по его использованию. Общий объём изготовленной документации составил около двухсот страниц.
В документацию также вошли материалы по комплексу приёмочных испытаний общим количеством более 100 тестов.
Была проделана огромная работа, и теперь мы с уверенностью можем сказать, что заказчик подготовлен к действиям в любых ситуациях, стандартных и нестандартных. Сценарии использования портала и его обслуживания разработаны детально и неоднократно проработаны на практике.
Леонид Сидоренко, QA инженер
Когда проект запущен
О чем хорошо знать на старте
Не стоит слепо полагаться на стандартные подходы, описанные в материалах поставщиков прикладного ПО, и на типовые варианты решения. К сожалению, в большинстве своем они довольно «теоретические» и весьма далеки от реальных кейсов. Важнейший источник практической информации — реальные кейсы похожих проектов. Здесь важно контактировать с непосредственными участниками таких проектов — они могут дать ценные детали, способные изменить всю картину. Крупные проекты — это всегда сложная архитектура, высокая нагрузка и большая финансовая ответственность. Поэтому весь критичный функционал обязательно нужно покрывать тестами — это позволяет предотвратить потенциальные проблемы в будущем.
Артем Волоков, разработчик «Aniart»
Хотим отметить необыкновенно высокий уровень технической компетенции наших коллег из «Укртелеком» — это профессионалы с большим опытом. Мы говорили с ними на одном языке — как по бизнес-задачам, так и по техническим вопросам.
Валентин Кертычак, руководитель проекта со стороны «ANIART»
Нам удалось решить все стоящие перед проектом задачи. Возникавшие сложности преодолевались безотлагательно и оперативно. И мы с полной уверенностью запускаем портал в плановую эксплуатацию.
Юрий Гучек, Руководитель проекта со стороны «Укртелеком»
Перейти на сайт
Полный текст статьи читайте на CMS Magazine
