Сбой ещё не заметили сотрудники — SmartOffice уже о нём знает

01 Интеграции — самое хрупкое место любой платформы

Программный код мы можем протестировать. Проверить, отладить, убедиться, что всё работает. А интеграции — нет. Потому что они живут не у нас, а у заказчика. В его инфраструктуре, которая меняется без нашего ведома.

Вчера всё работало. А сегодня сломалось. Потому что кто-то обновил контроллер домена. Или поменял настройки на почтовом сервере. Или сетевой инженер закрыл порт и забыл сказать. Или подрядчик перепрошил шлагбаум на парковке.

И всё. Сценарий, который работал сутками, просто перестаёт работать.

И знаете, в чём самая большая разница между сбоем интеграции и обычной ошибкой в интерфейсе?

Ошибка в интерфейсе — это неудобно. Кнопка не нажалась — перезагрузил страницу, пошёл дальше.

А сбой в интеграции — это когда человек реально не может попасть в офис. Не может открыть шкафчик и забрать вещи. Не может забронировать переговорную к приезду клиента. Не может заехать на парковку, потому что система не видит свободных мест.

Это уже не «неудобство». Это остановленный рабочий день. И арендатор воспринимает это именно так — как проблему, которая мешает ему работать. А вслед за ним и управляющая компания, которая слышит от него: «У вас ничего не работает».

Причём пользователю всё равно, кто виноват. Он не разбирается, где наш код, а где чужая инфраструктура. Для него это единая система. И если она не работает — значит, «у вас всё сломалось».

Поэтому мы решили: отвечать за интеграции мы будем так же, как за свой собственный код. Если мы выпускаем продукт, в котором есть интеграции с другими системами, мы не можем сказать: «Это не наша проблема, это у вас там что-то сломалось».

Мы должны это видеть. Мы должны это контролировать. И мы должны чинить это до того, как пользователь заметит.

02 Что показала статистика поддержки

Мы сели и посчитали. И цифры нас не обрадовали.

До 70% обращений в поддержку — это не ошибки в нашей платформе. Это сбои на стыках с другими системами.

Вот с чем мы сталкиваемся чаще всего:

• синхронизация сотрудников с Active Directory — люди не видят свои рабочие места и переговорные;
• календари и бронирование переговорных через MS Exchange — встречи не создаются, гости не получают приглашения;
• бронирование парковок — арендатор приезжает, а места нет, хотя он бронировал;
• бронирование рабочих мест — гибридный график превращается в хаос;
• СКУД — человек не может пройти в офис или на этаж;
• шкафчики хранения — не открываются, вещи заблокированы.

И самое обидное: мы узнавали об этом только после того, как пользователь уже пожаловался.

Между моментом сбоя и началом работ проходили часы. Иногда сутки. Всё это время проблема висела в воздухе, но никто о ней не знал. Поддержка работала как на американских горках: тишина — потом шквал звонков — снова тишина.

Это не масштабируется. И, что важнее, это нечестно по отношению к клиенту. Получалось, что о состоянии своей собственной инфраструктуры он узнавал от своих же недовольных сотрудников. А не от системы, которая этой инфраструктурой управляет.

03 Что мы сделали

Мы решили: хватит ждать, пока кто-то пожалуется. Будем видеть проблемы сами. И видеть их раньше, чем их заметит пользователь.

Мы взяли каждый интеграционный узел и поставили его под круглосуточный контроль. Проверки идут каждую минуту. Мы смотрим не просто «жив ли сервер», а реально ли работает бизнес-сценарий.

Вот что мы теперь контролируем 24/7:

• Active Directory — синхронизируются ли сотрудники, видят ли они свои рабочие места и переговорные;
• MS Exchange — можно ли создать встречу в календаре, работает ли бронирование переговорных;
• серверы бронирования парковок — видны ли свободные места, можно ли забронировать;
• серверы бронирования рабочих мест — доступны ли места для бронирования;
• шкафчики хранения — каждый блок на каждом этаже;
• СКУД — проходы, доступы, турникеты;
• интеграционные шлюзы между всеми этими системами.

Мы проверяем не «пинг», а реальную работу

Это важный момент. Мы не просто стучимся в сервер и спрашиваем «ты жив?». Мы проверяем, действительно ли он делает то, что должен делать.

Сервер может отвечать на запросы, но при этом не отдавать права доступа. Почтовый сервер может быть «жив», но не создавать встречи в календаре. Сервер парковки может отвечать на «пинг», но не видеть свободные места.

Поэтому мы проверяем по-человечески: система реально пытается создать встречу, забронировать парковку, открыть шкафчик, проверить доступ. Если операция не выполняется или выполняется слишком долго — мы фиксируем проблему. До того, как на неё пожалуется пользователь.

Мы видим не только сбой, но и подход к нему

Оборудование редко ломается мгновенно. Обычно оно сначала начинает тормозить. Растёт время отклика. Ошибки становятся периодическими. Доступность за сутки сползает со 100% до 99,4%.

Мы научились замечать этот момент. У нас есть пороговые значения: если время ответа выросло или доля ошибок превысила норму — мы получаем уведомление. И можем перезапустить узел в 6 утра, до того, как кто-то пришёл в офис.

Самый ценный результат этой работы невозможно показать на графике. Это инциденты, которых не было. Узел, который мы перезапустили по предаварийному оповещению, не попал ни в статистику отказов, ни в жалобы арендаторов. Сотрудник, который утром забронировал переговорную и парковку, даже не узнал, что что-то пошло не по плану.

04 Что видит клиент

Мы не прячем эту информацию. Клиент видит ровно то же, что и мы.

Одна страница, на которой собраны все интеграции: бронирование переговорных, парковок и рабочих мест, шкафчики, AD, Exchange, СКУД. По каждому объекту — текущий статус, время отклика, доступность за сутки и график поведения.

Важный момент: это не «личный кабинет для самообслуживания», куда мы отправляем клиента разбираться самостоятельно. Это ровно та же картина, которую видит наша дежурная смена. Мы работаем с одними и теми же данными. Просто клиенту больше не нужно звонить нам и спрашивать: «А что у вас там происходит?» — он видит это сам.

Оповещения туда, где вы реально сидите

Клиент сам выбирает, как получать уведомления:

• На почту — с деталями: что случилось, когда началось, сколько длится.
• В Telegram — мгновенно, в ту же минуту.

Причём можно настроить, кто о чём узнаёт. Инженер по СКУД получает только по своим узлам. ИТ-служба — по каталогу и почте. Эксплуатация — по шкафчикам и парковке. Каждый получает ровно то, что ему нужно. Никакого информационного шума.

Статистика, которая помогает принимать решения

Оповещения решают сегодняшнюю задачу. А накопленная статистика — завтрашнюю.

Через месяц наблюдений видно, какой узел отказывает чаще других, в какие часы система тормозит, где узкое место — сеть, оборудование или смежная система.

Для управляющей компании это переводит разговор с подрядчиком из области «нам кажется, что парковка тормозит» в область фактов: вот выгрузка с датами, длительностью и долей сбоев. Обслуживание перестаёт быть спором о том, кто виноват, и становится обычным управляемым процессом.

05 Что изменилось в цифрах

Мы не любим говорить про абстрактную «эффективность». Мы считаем деньги и время. Вот что дал переход к проактивному контролю:

Как мы это считаем?

Раньше каждый сбой начинался с нуля: приняли обращение, начали разбираться, запросили доступы, подняли логи, нашли узел. Это занимало часы.

Теперь 6 из 10 проблем мы или клиент видим до того, как кто-то пожалуется. А оставшиеся 4 приходят в поддержку с уже готовым контекстом — инженеру не нужно тратить время на первичную диагностику.

В сумме нагрузка на интеграционный контур снизилась примерно вдвое. А значит, ваши сотрудники занимаются развитием, а не «тушением пожаров».

06 Почему мы не берём за это деньги

Сервис предоставляется абсолютно бесплатно. Для всех клиентов Merusoft и SmartOffice.

Без отдельного договора. Без подключения платных модулей. Без пересмотра условий действующих контрактов.

Это не акция и не пробный период. Это наша позиция.

Объясняем честно.

Мониторинг окупается внутри нашей собственной экономики. Инцидент, который мы нашли за минуту, обходится нам в разы дешевле, чем инцидент, который «висел» сутки и породил шквал звонков в поддержку. Брать отдельные деньги за то, что снижает наши же издержки, было бы странно.

Но есть и вторая причина. Для нас более важная.

Надёжность не может быть платной опцией.

Либо система работает предсказуемо, либо она не сделана до конца. Мы считаем мониторинг таким же базовым свойством платформы, как резервное копирование или журнал операций.

Что получает клиент: круглосуточный контроль всех интеграций, оповещения в почту и Telegram, дашборд со статусами и отчётами.

Что платит: ничего сверх уже действующих лицензий и договора поддержки.

07 Следующий шаг – искусственный интеллект вместо описания проблемы

Мы не останавливаемся. Сейчас мы связываем мониторинг с нашей системой поддержки support.merusoft.ru

Представьте: клиент создаёт заявку. А AI-ассистент уже:

• проверил, как вели себя все интеграции в момент сбоя;
• подтянул актуальные логи и статусы;
• сопоставил время сбоя с событиями в смежных системах;
• предложил готовое решение или передал инженеру уже обогащённый запрос.

Что это значит для клиента?

Ему не нужно ничего описывать. Не нужно объяснять, что случилось и когда. Достаточно нажать «создать заявку» — вся необходимая информация уже приложена.

Время диагностики сокращается в разы.

Это следующий этап эволюции сервиса: от проактивного мониторинга к автоматической преддиагностике обращений.

08 Коротко о результате

• 70% обращений в поддержку — это сбои в интеграциях систем, а не ошибки платформы.
• Мы научились находить эти сбои за минуту, а не за часы или сутки.
• ~60% проблем мы или клиент видим раньше пользователей.
• Нагрузка на поддержку снизилась вдвое.
• Сервис бесплатный — входит в стоимость лицензий Merusoft и SmartOffice.
• В планах — AI-ассистент, который будет автоматически собирать контекст по любой заявке.

Хорошая интеграция — та, о которой никто не вспоминает. Мы делаем интеграции незаметными, а поддержку — предсказуемой.

Merusoft IWMS · Подключение мониторинга для действующих клиентов — по обращению в службу поддержки.