Успешный проект для крупного 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 |
