Эту статью написала Рэйчел Виталек (Rachel Witalec), директор по продукту в Redox.
Момент запуска кажется финишной чертой. Но для команды, которая обслуживает интеграцию, это на самом деле только первый день.
Большинство команд относятся к интеграции медицинских данных как к разовому проекту. Оценить масштаб, разработать, протестировать, выпустить, поставить галочку «готово». Составить маппинг данных, разобраться с семнадцатью пограничными случаями, о которых никто не упомянул на старте, протестировать, развернуть. Но это понятная величина. У нее есть дедлайн, и под нее можно выделить ресурсы. Затраты вполне реальны, и большинство считает, что они заканчиваются с запуском интеграции.
Однако существует вторая статья расходов, у которой нет срока окончания, и никто не внес ее в проектный план. Она начинается в момент запуска и никогда не прекращается. Кто-то должен следить за трафиком, отлавливать сбои, разбираться, почему что-то сломалось, и устранять неполадки. И это не масштабируется линейно. Ваше десятое подключение не добавляет 10% к объему работы по мониторингу. Оно добавляет совершенно новый объект для наблюдения со своими особенностями, своим партнером на другом конце и своим собственным уникальным способом сломаться в 2 часа ночи.
Я знаю это потому, что команда Redox в настоящее время ежедневно поддерживает более 15 000 работающих интеграций (и их число растет). Наши клиенты полагаются на нас в вопросах мониторинга и поддержки своих интеграций, и мы относимся к этой ответственности со всей серьезностью.
Если вы не являетесь клиентом Redox, именно здесь подход «давайте просто сделаем это сами» начинает давать сбой. Создание подключения к Epic или athenahealth вполне выполнимо. Вы можете оценить трудозатраты, выделить команду и успеть к сроку. Но оценить масштаб усилий, необходимых для поддержания этого подключения в рабочем состоянии в течение следующих пяти лет, гораздо сложнее.
Реальность такова, что на самом деле это не два вида расходов. Это две разные ментальные модели. Первая рассматривает функциональную совместимость как проект. Вторая — как инфраструктуру, нечто, что никогда нельзя назвать завершенным, потому что вы зависите от этого до тех пор, пока в этом нуждаетесь. Как только вы начинаете смотреть на это так, вопрос меняется. Речь больше не идет о том, «сколько стоит подключение?». Вопрос звучит так: «кто будет этим управлять и как?». В сегодняшнем мире искусственного интеллекта, где умение отделить сигнал от огромного потока шума становится еще важнее, все чаще возникает вопрос: «как нам делать это лучше?»
В недавней публикации, в которой мои коллеги Кайлин Гигот (Kalyn Gigot), вице-президент по работе с клиентами, и Энди Пунг (Andy Pung), вице-президент по корпоративным продажам, рассказали о том, как оценивать партнера по интероперабельности, мы назвали это «налогом на ресурсы». Ситуация выглядела несколько иначе, поскольку речь шла о том, кто будет нести ответственность за обслуживание и мониторинг после запуска, а не о том, каких усилий требует поддержка и насколько эффективно она работает. В любом случае, вот как это выглядит на практике и почему самый разумный способ управления этим процессом — выявлять проблемы до того, как они станут критическими.
Мониторинг — это невидимая работа... пока не станет слишком поздно
После запуска проекта важнее всего ответить на один вопрос. Действительно ли данные перемещаются так, как предполагалось?
Звучит просто. Но это не так, и сложность возрастает с каждым новым подключением. Каждое из них представляет собой отдельный поток трафика со своим собственным определением «нормального» состояния и своими уникальными рисками отклонений. Сложите десятки или сотни подключений, и вы получите полноценную работу на полный день. Опытные команды и руководители знают это. Мы определенно живем с этим каждый день. Самая сложная часть для организаций, которые управляют собственными интеграциями, — это обосновать необходимость найма персонала до того, как первый инцидент сделает это за них.
Рисунок 1. Пример панели управления пользователя Redox. Так выглядит хороший ответ на вопрос «перемещаются ли данные так, как предполагалось?».
Некоторые сбои заявляют о себе вежливо. Конечная точка падает, возникает ошибка, срабатывает оповещение, и все знают, что делать. Это «простые» дни, потому что проблема налицо. Гораздо сложнее дни, когда ничто не выглядит сломанным. Проблемы невидимы. Трафик незаметно взлетает. Тип сообщения начинает вести себя немного иначе. Данные технически идут, просто не туда, куда нужно. Больница перекодирует поле со своей стороны, и три системы ниже по цепочке начинают испытывать трудности в течение недели, и никто не объясняет вам почему.
Не имея четкого представления о том, что изменилось, вы вынуждены заниматься расследованием. Запись не поступила. Результат так и не был опубликован. Кто-то создает тикет, и теперь вы движетесь в обратном направлении от симптома к причине, которой может быть уже несколько недель.
Эта задержка и есть самое дорогое. Будь то перекодированное поле, истекший срок действия сертификата или изменение формата сообщения партнером без предупреждения; дефект проявляется в первый день, а сбой обнаруживается на тридцатый. К тому времени вы не просто устраняете первоначальную проблему. Вы восстанавливаете месячное отклонение в разгар реального инцидента, что намного хуже, чем обнаружить его на ранней стадии.
И что же с этим делать? Независимо от того, управляете ли вы собственными интеграциями или работаете с партнером, перестайте воспринимать мониторинг просто как способ узнать о проблеме быстрее. Цель состоит в том, чтобы узнать о ней до того, как это станет проблемой. Отклонение, замеченное на второй день, — это маленькая и дешевая починка. Тютелька в тютельку то же отклонение, оставленное без внимания до тридцатого дня (или дольше!), превращается в масштабный сбой, который может нарушить клинические рабочие процессы, потребовать больших затрат на устранение последствий или подорвать доверие медицинского учреждения к вам. Мониторинг стоит денег. Сбой — тоже. Разница в том, что мониторинг — это расход, который можно заложить в бюджет. Сбои случаются тогда, когда им вздумается, и могут стоить вам клиентского счета, трех месяцев возмещения расходов или даже перерыва в уходе за пациентами.
Это не просто нравоучительная история. Во время недавнего вебинара о выборе правильного партнера по интероперабельности (теперь доступен по запросу!), Кайлин рассказала историю об одной медицинской организации (не являющейся клиентом Redox, если что), которая шесть недель не отправляла ни одного результата. Организация работала с интеграционной платформой без каких-либо настроенных оповещений или мониторинга. Никто не замечал отсутствия трафика до тех пор, пока кто-то не спросил, почему прекратились поступления от выставления счетов, потому что в этом рабочем процессе отсутствие результатов означало отсутствие счетов. Шесть недель молчания данных в компании с оборотом почти в миллиард долларов в год — это не погрешность округления. Это реальная выручка, которую приходится возвращать задним числом.
Один из вопросов, который не дает мне спать по ночам: «Как мы можем улучшить мониторинг?». Сейчас у нас есть все эти передовые инструменты искусственного интеллекта и агентские возможности. Должны быть способы использовать их для снижения задержек, выявления скрытого, фильтрации шума, более быстрого расследования и устранения неполадок (или даже без вмешательства человека). Эту гипотезу моя команда активно исследует.
Видеть проблему помогает только в том случае, если ваша команда может на нее отреагировать
Предположим, теперь все согласны с тем, что мониторинг имеет значение. Но видимость ради самой видимости — пустая победа, если единственным человеком, который действительно может что-то с этим сделать, является ваш вендор.
Ваш вендор не должен быть единственным, кто знает, что происходит с вашими данными. Задача хорошего вендора — подготовить вашу команду к успеху: чтобы она могла видеть проблемы, исправлять то, что может, и передавать наверх то, с чем не справляется. Ваша команда должна уметь делать три вещи:
- Будьте в курсе происходящего. Реальный трафик, реальное поведение вплоть до отдельного лога, а не просто зеленая галочка на странице статуса
- Исправляйте то, что можете. Доберитесь до сути («почему») самостоятельно, вместо того чтобы заводить тикет и ждать
- Эскалируйте то, что не можете. Передавайте задачу с уже собранным контекстом, чтобы это был быстрый и конкретный запрос, а не «что-то идет не так, хз»
Это важно даже тогда (особенно тогда), когда сервис полностью управляем. Чем меньше ваша команда вовлечена в ручные операции день за днем, тем больше такая прозрачность вызывает доверие. Выражение «полностью управляемый» не должно быть красивым способом сказать «мы сообщим вам, если все сломается». Черный ящик, которым управляет кто-то другой от вашего имени, все равно остается черным ящиком.
Один из наших принципов в Redox — «Делай сам, но не в одиночку». Это значит, что мы стремимся предоставить нашим клиентам инструменты самообслуживания, чтобы они могли делать то, что им нужно, тогда, когда это нужно, но также гарантируем, что мы обеспечим руководящие указания и все преимущества нашего совокупного опыта, когда это полезно или необходимо.
Инструменты на базе ИИ, которые мы внедрили в платформу Redox Engine, такие как суммирование логов в один клик, созданы именно для этого. Это не уловка. Это сокращает расстояние между «что-то произошло» и «я понимаю почему». Один лог может представлять собой путь обработки с вложенными преобразованиями в нескольких системах и дюжиной с лишним шагов — то есть вещь, на выяснение которой у инженера раньше уходило двадцать минут вглядывания в дерево JSON. Теперь это объяснение на понятном языке в один клик, созданное на основе многолетнего реального опыта и мудрости. Ваша команда сможет сразу понять, что произошло, вместо того чтобы ждать, пока кто-то другой это объяснит.
Рисунок 2. Инспектор логов. Нажатие кнопки «Суммировать» в правом верхнем всплывающем окне превращает это в понятную фразу вместо квеста.
Время историй! Сдерживание всплеска сетевых запросов
Вот еще один реальный пример, над которым моя команда недавно работала. Сеть передачи данных, обслуживающая поставщиков услуг для пожилых людей и долгосрочного ухода, начала возвращать ошибки практически на каждый поступающий запрос, хотя на ее стороне ничего не изменилось.
Причина была на вышестоящем уровне. Сторонняя служба поиска участников имела дефект и начала отправлять запросы на поиск пациентов в объеме, который сеть никогда не была рассчитана обрабатывать. Объем ежедневных запросов подскочил примерно в 6 раз и держался на уровне от 150 до 175 миллионов запросов в день в течение нескольких дней. Для принимающей системы это выглядит как потоп.
Рисунок 3. Объем ежедневных запросов в период всплеска
Поскольку Redox находится на пути передачи данных и отслеживает трафик по каждому соединению и каждому идентификатору организации (OID), изменение паттерна было заметно в момент его возникновения. Эти срезы трафика изолировали поведение, а ограничение скорости защитило пункт назначения, в то время как наша платформа поглощала поток данных, на порядок превышающий привычный.
Это сократило нагрузку на пункт назначения со ста тысяч запросов в минуту примерно до десяти тысяч, в то время как Redox поглощал всплески до 450 000 в минуту. Стоит отметить, что наша платформа справилась с этим всплеском без малейших сбоев.
Рисунок 4. Защита с помощью ограничения скорости в действии. Слева: объем до и после включения ограничения скорости. Справа: фактический объем данных в период аномалии.
Мы поделились исходными данными с операторами сети, чтобы они могли устранить первопричину. Все видели одну и ту же картину, а это значит, что никому не пришлось задним числом гадать, что же произошло. Объем пошел на спад, как только проблема была решена.
Интеграции будут ломаться. Почти невозможно предсказать, когда и как, но это произойдет. Эту ситуацию удалось удержать под контролем, потому что ответственные лица смогли увидеть проблему на ранней стадии, быстро отреагировали и работали вместе над ее устранением. В этом и заключается истинная ценность мониторинга. Не просто знать, когда что-то горит, а увидеть дым достаточно рано, чтобы совместными усилиями что-то с этим сделать.
Это невероятный пример того, как мы заботимся о наших клиентах и сотрудничаем с ними. Если бы я руководил внутренней командой и такая аномалия происходила бы раз в три года, я бы, наверное, со всеми похлопал друг другу по рукам и пошел дальше. Но мы регулярно управляем подобными ситуациями. Мы действительно немало похлопали друг друга по плечу, но мы также ставим перед собой задачу понять, как управлять этими ситуациями более эффективно и результативно, чтобы быть еще лучшим партнером для наших клиентов.
Запуск — это начало, а не финишная прямая
Интеграционные дискуссии годами были зациклены на самом факте подключения. Как быстро вы можете выполнить сборку, к скольким системам можете получить доступ, сколько инженерных усилий это требует, FHIR или HL7v2. Это было единственным, что имело значение.
Но запуск движения данных — это только начало. Обеспечение их непрерывного перемещения и уверенность в том, что ответственной команде не придется ждать кого-то еще, чтобы узнать, что происходит, — это невидимая работа, которая никогда не заканчивается.
Поэтому, если вы решаете, создавать ли это самостоятельно или выбираете вендора для совместной работы, не ограничивайте свои расчеты моментом запуска. Кто на самом деле следит за вашими данными? Как быстро они узнают об изменениях? И когда им нужно будет узнать причину, будет ли ваша команда готова разобраться в этом или застрянет в очереди?
Если у вас уже есть партнер, вопросы меняются. Насколько надежно обнаружение проблем? Является ли процесс устранения неполадок партнерством, вызывающим доверие, или вы чувствовали себя в неведении все это время? Затягивается ли инцидент или он решается быстро?
Истинная стоимость интеграции никогда не заключалась лишь в затратах на ее создание. Она заключается в том, что требуется для поддержания ее работоспособности в течение многих лет без необходимости для кого-либо сильно об этом задумываться. Стоит закладывать это в проект с первого дня. Интероперабельность — это не проект с конечной датой. Это долгосрочная инвестиция в способность вашей команды управлять тем, от чего они зависят.
Поэтому в следующий раз, когда кто-то скажет вам, что интеграция завершена, задайте единственный важный вопрос: кто следит за ней сейчас?
