
Эта история построена на ряде удачных совпадений, в которых нам, как нам кажется, удалось распознать правильную тенденцию и создать продукт, который может подойти многим похожим на нас. Потому, что… впрочем, обо всем по порядку.
Итак, мы – компания, оказывающая своим клиентам высокотехнологичные услуги – аутсорсинг ИТ-экспертизы, удаленное сопровождение, разработка ПО на заказ и т.д. и т.п. Как и для любой другой компании, для нас актуален вопрос соблюдения трудовой дисциплины и контроля присутствия наших высококвалифицированных сотрудников на рабочем месте. Задачи такого рода относительно успешно решаются в тех случаях, когда сотрудники а) работают по строгому графику в офисе и б) их отношением к тому, что за ними следят, можно пренебречь. То есть можно установить на входе в офис традиционные СКУД, поставить следящее ПО на офисные компьютеры и спокойно реализовывать функции Большого Брата. Но в случае работы с экспертной командой все эти меры сработают скорее в минус, и вот почему.
Во-первых, типичный сотрудник высокотехнологичной компании (далее назовем его «эксперт») – это человек, который работает не только на работе и не только в традиционное рабочее время. Это связано… это может быть много с чем связано – с фактической необходимостью осуществлять какие-то работы ночью, с разницей часовых поясов с клиентами, в конце концов с тем, что пик производительности нашего гениального разработчика приходится на интервал между 23-00 и 4-00, и в это время он творит чудеса. Соответственно, необходимо учитывать не пребывание в непосредственной близости от рабочего компьютера, а фактическую работу на нем (возможно, и удаленно из дома).
Во-вторых, эксперт – это свободолюбивое существо. Сама мысль, что какая-то программа занимается исключительно тем, что контролирует его деятельность, действует на него демотивирующе, подрывает дух инновационных команд и, соответственно, негативно влияет на производительность труда.
В-третьих, эксперт — это эксперт, со своими профессиональными амбициями. Существование софта, который ему (эксперту) противодействует, может направить таланты этого человека на борьбу с этим софтом. Таким образом, наш эксперт на своем рабочем месте в свое рабочее время будет тратить силы… на борьбу с системой учета рабочего времени! Согласитесь, что-то тут не так =).
Ну и, в-четвертых, к программам, собирающим данные пользователя, с подозрением относятся сами высокотехнологичные компании. Мало ли куда потом эти данные уплывают…
В общем, мы проблему для себя осознавали, но, как настоящий «сапожник без сапог», решать ее для себя не спешили. Пока с такой же проблемой к нам не обратился наш Клиент. Вот отсюда начинаются ранее анонсированные совпадения.
Так вот, наш клиент — компания, оказывающая своим клиентам высокотехнологичные услуги. А именно, стартап, специализирующийся на услуге Dedicated Developers Team (когда программистов сдают в аренду заказчику). Понемногу количество программистов у клиента разрослось, и встал вопрос о трудовой дисциплине и контроле рабочего времени. А традиционными средствами пользоваться клиент не хотел, по причинам, полностью совпадающим с описанными выше. Так что совпадение потребностей было стопроцентное. С предложением решить для него эту задачу клиент обратился к нам, и мы с энтузиазмом (предчувствуя как минимум двойную пользу =) ) принялись исследовать вопрос.
Оказалось, что наш клиент, как и мы, работает преимущественно под Windows. И приложения, с которыми он (как и мы!) работает, довольно тяжеловесные, типа SharePoint. На обычном домашнем ноутбуке, и уж тем более на IPad, не поработаешь. Поэтому сотрудники используют свою рабочую машину даже когда работают из дома – они подключаются к ней через службу удаленного рабочего стола RDG (Remote Desktop Gateway). Все, как у нас!
Далее выяснилось, что и мы, и заказчик используем в качестве и офисной АТС, и универсального средства коммуникаций Skype for Business (бывший MS Lync). Эта программа, кроме своих непосредственных обязанностей, выполняет еще одну – она в любой момент времени может сообщить статус присутствия пользователя в системе. Итак, сотрудник всегда для работы пользуется рабочим компьютером – на нем всегда стоит Skype for Business – Skype всегда знает статус присутствия пользователя… Небольшое умственное усилие – и идея сбора истории изменения статусов и получения на основе нее графика работы прочно обосновалась в нашем коллективном разуме. Осталось только ее реализовать, к чему мы и приступили.
Естественно, сбор статистики с клиента не имел большого смысла, т.к. не видно на каком устройстве в данный момент работает сотрудник. Следовательно, надо было смотреть на содержимое баз данных Skype серверов (речь, конечно же, о корпоративных серверах Skype4B). Соответствующая информация о структуре БД серверов Skype4B, хоть и не была документирована, но доступ к ней не потребовал каких-то операций по дешифрованию или декомпиляции. Под катом немного технических подробностей для заинтересованных.
Технические подробности
План:
Существует две базы данных, с которыми мы работаем при мониторинге изменения статусов:
[rtc] – содержит статические сведения, которые не меняются с течением времени. В данной базе находятся сведения о пользователях, контактных данных, фотографий профиля, статусных сообщений и т.п.
[rtcdyn] – содержит динамическую информацию, касательно изменения статусов клиентов(программ) которые подключены к серверу Skype For Business.
Как было сказано выше, данная база данных содержит динамическую информацию касательно изменения статусов клиентов(программ) которые подключены к серверу Skype For Business.
Прежде всего следует условится с понятием «клиент». Это прежде всего программа или веб браузер с которого происходит коннект к серверу Skype For Business. «Клиент» для соединения требует логин и пароль пользователя и предоставляет дополнительные сведения касательно устройства, часовой зоны. Важно понимать, что собираемая информация по «Клиенту» касается только «Клиента», а не реального пользователя. Т.е. сведения которые мы будем собирать зависят от того, где пользователь запустит «Клиент».
Рассмотрим пример:
Все сведения от «клиентов» независимы друг от друга.
После коннекта к базе rtcdyn мы видим несколько таблиц. Среди них можно найти таблицу RegistrarEndpoint. Попробуем извлечь некоторую информацию из данной таблицы.

После преобразования полученной информации, мы можем увидеть сведения об источнике подключения к серверу Skype For Business.
Например:
Из данной строки можно извлечь IP адрес устройства с которого идет подключение «клиента».
Аналогично можно извлечь сведения из колонки ClientApp. В данной колонке находится информация про приложение из которого происходит сам коннект к серверу Skype For Business.
Примеры значений которые могут содержаться в ClientApp приведены ниже:
UCCAPI/15.0.4753.1000 OC/15.0.4753.1000 (Skype for Business)
RTCC/5.0.0.0 OWA/15.00.1076.009
На основании ClientApp можно определить название, тип клиента и его версию.
Таблица PublishedInstance заполняется автоматически при поступлении информации об изменении статуса (Activity) «Клиента». Среди всех столбцов особенно интересны:
PublisherId – идентификатор аккаунта пользователя который подключается к Skype For Business;
LastPubTime – дата и время при котором произошло изменение статуса «Клиента»;
Data – основная часть сведений по измененному статусу. Позволяет понять что именно произошло со статусом в конкретный промежуток времени. Более подробное описание сведений которые могут находиться в столбце можно найти в Chapter 6 книги Enhanced Presence Lync 2010.
Мы же извлекаем из Data только информацию про Availability, TimeZoneBias, Device и PublisherId.
Отдельно следует сказать про BoundEndpointId. Этот столбец указывает на идентификатор сессии, которая устанавливается при каждом подключении «клиента» к серверу Skype For Business. По данному идентификатору мы можем определить дополнительные сведения по устройству, с которого подключается «клиент». Это позволяет вести изменения статусов индивидуально для каждого устройства.
В итоге, после применения выборки из столбца Data, группировки и сортировки мы получаем вот такой результат:

Все статусы в базе пишутся только номерами, и Microsoft не дает информации, какой статус что означает. Есть только общие сведения по диапазонам, которые зарезервированы под различные Activity.
Например 15500 – away, mobile. Или 6700 – busy, presenting.
Пришлось потратить время на исследование и сбор статистики для составления таблицы-справочника диапазонов Activity:

В данном случае на основе справочника и колонки isav определяется – засчитывается ли время в активное или нет.
Новая поступающая информация по статусам сохраняется в отдельную базу, которая никак не связана с базами rtc и rtcdyn. Параллельно мы обсчитываем общие сведения за прошедшие дни для ускорения вывода отчетов активного и неактивного времени «клиента». Сохранение логов производится с помощью TimerJob, либо в случае использования SQL Express с помощью Windows расписания.
- Базы данных Skype For Business сервера.
- База rtcdyn:
- Понятие клиент в rtcdyn.
- Извлекаем клиентов. Таблица [RegistrarEndpoint].
- Работаем с изменениями статусов клиентов. Таблица [PublishedInstance].
- Статусы клиентов. Колонка Availability.
- Журнал логов присутствия.
Базы данных Skype For Business сервера
Существует две базы данных, с которыми мы работаем при мониторинге изменения статусов:
[rtc] – содержит статические сведения, которые не меняются с течением времени. В данной базе находятся сведения о пользователях, контактных данных, фотографий профиля, статусных сообщений и т.п.
[rtcdyn] – содержит динамическую информацию, касательно изменения статусов клиентов(программ) которые подключены к серверу Skype For Business.
База rtcdyn
Как было сказано выше, данная база данных содержит динамическую информацию касательно изменения статусов клиентов(программ) которые подключены к серверу Skype For Business.
Понятие клиент в rtcdyn
Прежде всего следует условится с понятием «клиент». Это прежде всего программа или веб браузер с которого происходит коннект к серверу Skype For Business. «Клиент» для соединения требует логин и пароль пользователя и предоставляет дополнительные сведения касательно устройства, часовой зоны. Важно понимать, что собираемая информация по «Клиенту» касается только «Клиента», а не реального пользователя. Т.е. сведения которые мы будем собирать зависят от того, где пользователь запустит «Клиент».
Рассмотрим пример:
- Пользователь А может запустить клиент внутри Remote Desktop сессии, и следовательно его клиент будет передавать серверу Skype For Business сведения о компьютере внутри Remote Desktop сессии.
- Пользователь А может запустить клиент на мобильном телефоне, и следовательно аналогично будут передаваться данные касательно мобильного телефона.
Все сведения от «клиентов» независимы друг от друга.
Извлекаем клиентов. Таблица [RegistrarEndpoint]
После коннекта к базе rtcdyn мы видим несколько таблиц. Среди них можно найти таблицу RegistrarEndpoint. Попробуем извлечь некоторую информацию из данной таблицы.
select top 5 ContactInfo
from [rtcdyn].[dbo].[RegistrarEndpoint];

После преобразования полученной информации, мы можем увидеть сведения об источнике подключения к серверу Skype For Business.
Например:
P;sip:212.3.112.68:51024;transport=tls;ms-opaque=b68b30d990;ms-received-cid=608500;] ;;sip:lyncedge1-uk.point.local:5061;transport=tls;opaque=state:Ee.ag8rxSddCvwU5-K8q7K742RAAA;lrbwbyztosJ7NpwKGhwBHTHlngAA70f2c5f712 <sip:lyncedge1-uk.point.local:5061;transport=tls;opaque=state:Ee.ag8rxSddCvwU5-K8q7K742RAAA;lrbwbyztosJ7NpwKGhwBHTHlngAA70f2c5f712>
Из данной строки можно извлечь IP адрес устройства с которого идет подключение «клиента».
Аналогично можно извлечь сведения из колонки ClientApp. В данной колонке находится информация про приложение из которого происходит сам коннект к серверу Skype For Business.
Примеры значений которые могут содержаться в ClientApp приведены ниже:
UCCAPI/15.0.4753.1000 OC/15.0.4753.1000 (Skype for Business)
RTCC/5.0.0.0 OWA/15.00.1076.009
На основании ClientApp можно определить название, тип клиента и его версию.
Работаем с изменениями статусов клиентов. Таблица [PublishedInstance]
Таблица PublishedInstance заполняется автоматически при поступлении информации об изменении статуса (Activity) «Клиента». Среди всех столбцов особенно интересны:
PublisherId – идентификатор аккаунта пользователя который подключается к Skype For Business;
LastPubTime – дата и время при котором произошло изменение статуса «Клиента»;
Data – основная часть сведений по измененному статусу. Позволяет понять что именно произошло со статусом в конкретный промежуток времени. Более подробное описание сведений которые могут находиться в столбце можно найти в Chapter 6 книги Enhanced Presence Lync 2010.
Мы же извлекаем из Data только информацию про Availability, TimeZoneBias, Device и PublisherId.
Отдельно следует сказать про BoundEndpointId. Этот столбец указывает на идентификатор сессии, которая устанавливается при каждом подключении «клиента» к серверу Skype For Business. По данному идентификатору мы можем определить дополнительные сведения по устройству, с которого подключается «клиент». Это позволяет вести изменения статусов индивидуально для каждого устройства.
В итоге, после применения выборки из столбца Data, группировки и сортировки мы получаем вот такой результат:

Статусы клиентов. Колонка Availability
Все статусы в базе пишутся только номерами, и Microsoft не дает информации, какой статус что означает. Есть только общие сведения по диапазонам, которые зарезервированы под различные Activity.
Например 15500 – away, mobile. Или 6700 – busy, presenting.
Пришлось потратить время на исследование и сбор статистики для составления таблицы-справочника диапазонов Activity:

В данном случае на основе справочника и колонки isav определяется – засчитывается ли время в активное или нет.
Журнал логов присутствия
Новая поступающая информация по статусам сохраняется в отдельную базу, которая никак не связана с базами rtc и rtcdyn. Параллельно мы обсчитываем общие сведения за прошедшие дни для ускорения вывода отчетов активного и неактивного времени «клиента». Сохранение логов производится с помощью TimerJob, либо в случае использования SQL Express с помощью Windows расписания.
В результате мы имеем полную информацию о том, когда и как менялся статус пользователя, и об устройстве с которого был получен этот статус (нас в нашем конкретном случае интересовали только офисные компьютеры, но включать фантазию еще никто никому не мешал).
Используя эту информацию, можно получать сведения о графике работы. В данный момент с большой достоверностью мы получаем:
- Время прихода в офис.
- Время начала и окончания обеденного перерыва.
- Время ухода.
- Сколько всего часов было отработано.
- Работал ли сотрудник вечером из дома.
Фактуры достаточно, чтобы построить полноценную систему контроля рабочего времени, но с привязкой к реальному рабочему месту труженика интеллектуального фронта – программиста или саппорт-инженера. Собственно, такую систему мы и реализовали, чем спешим похвастаться.
Можно получать, например, такие отчеты:
- Среднее и максимальное опоздание за период.
- Всю историю отсутствий с указанием на наличие согласия руководителя.
- Время внеурочной работ.
- Работа из дома — система получает информацию со шлюзов RDG и можно видеть, зашел ли сотрудник на компьютер локально или из дома.
Как и во всех подобных системах, есть график отпусков, больничные, разрешения менеджеров на работу из дома и прочие плюшки.
Еще одной особенностью является личный кабинет сотрудника, и рассылка отчетов на почту. То есть система позиционирует себя не как «шпион» (будем тайно собирать о тебе информацию, а потом вычтем из зарплаты), а как «помощник» (покажем тебе, что статистика ведется, и дадим возможность проанализировать эту статистику и сделать для себя выводы). Эта функция оказалась очень полезной — даже несмотря на то, что все наши сотрудники и сотрудники заказчика довольно ответственные люди, после начала рассылки отчетов среднее время присутствия сотрудника на рабочем месте повысилось.
Реализация со скринами системы:
SkypeTime
Можем констатировать – с задачей мы справились. Наш заказчик доволен, мы (пользуясь сами этой системой) довольны, сотрудники, деятельность которых контролируется… ну, как минимум, не недовольны, а некоторые, как уже сказано выше, и благодарны системе за структурированные отчеты о графике работы и другие сотрудник-ориентированные фичи. Пожалуй, систему не стоит использовать для ведения табеля или начисления зарплат, но в качестве инструмента, предоставляющего менеджеру оценочную информацию о работе сотрудника, она очень эффективна. Еще она является неоценимым подспорьем сотруднику-администратору, ведущему информацию об отгулах и отпусках. Такая ситуация, как — сотрудник в отпуске, начальник попросил его полдня поработать из дома, а потом взять это время в отгул — теперь легко отслеживается. А возможности настройки гибких условий типа «если в 9:15 не на работе значит прогул» или даже «можно опаздывать не чаще двух раз в неделю и если ночью работал с заказчиком, то можно поспать до обеда, а после поработать из дома» сделали возможным использовать систему для ИТ-компаний, где обычные СКУД практически не применимы. Ну и факт отсутствия «шпионского» ПО на компьютерах сотрудников благоприятно отражается на атмосфере в коллективе. А хорошая рабочая атмосфера – это, «по данным британских ученых», до 80% успеха работы =)
P.S. Да, конечно, было бы неплохо и смотреть статистику работы в интернет, и собирать список установленных программ, но это совсем другой уровень шпионажа, чреватый потерей лояльности коллектива. Кроме того, в нашей практике такие изощренные обманщики встречаются крайне редко, и они все же довольно быстро выявляют себя низкой производительностью или низким качеством работы – так что награда все равно находит героев.
C уважением коллектив компании Servilon.ru Servilon.com