company_banner

Интеграция — байки



    Тебе хана, если ты не влез в бизнес-процесс заказчика, а копаешься только в ИТ-процессе.

    Это общее правило почти не знает исключений. Потому что ИТ-структура часто не владеет данными и не знает, зачем они дальше нужны. А когда речь про интеграцию (без которой не обходится ни одно внедрение цифрового инструмента, будь то модный чат-бот или олдскульный CRM) — это нужно очень точно и детально понимать.

    Я видел много разных историй: и то, как один малюсенький сервис для работы с факсами после внедрения начал вести себя как вирус и бороться с почтовым сервером и другими сервисами компании (кстати, победил), и то, как сегмент «малый и средний бизнес» не включал в себя средний бизнес (к искреннему удивлению ИТ-отдела), и как люди просто не знали, в чём смысл обрабатываемых данных и зачем они нужны — это часто касается финансов.

    Поэтому давайте расскажу пару баек про то, что случается, когда нужно просто взять и соединить несколько ИТ-систем. Делов-то!

    Что такое интеграция в российском понимании


    Самые частые примеры такие:

    • Нужно получить что-то от имеющихся систем. Например, есть система бронирования билета на сайте, есть система регистрации в аэропорту. Если их соединить, то можно сделать онлайн-регистрацию. Естественно, не всё так просто — по ходу исполнения возникнет очень много вопросов.
    • Нужно подключить что-то новое. Например, есть интернет-банк и есть старая добрая АБС для банковских служащих. Нужно разделить слой исполнения и слой интерфейса: то, что делает сотрудник в отделении, и то, что делает сам клиент в интернет-банке, — это интерфейсы. АБС плевать, кто запросил перевод со счёта на счёт: клиент онлайн или он же в отделении или по телефону. Главное — чтобы операция была достаточным образом авторизована.
    • Надо построить цепочку. То есть чтобы несколько систем работали как единое целое, чтобы операции начинались, например, в одной из систем, продолжались во второй, а заканчивались в третьей. Так работают переводы в банках: если переводить с карты на вклад, то задействуются обычно сразу несколько систем — АБС по вкладам, процессинг по картам, мобильный или интернет-банк, SMS-шлюз и т. п.


    Общий подход — между системами надо как-то налаживать обмен данными. Можно делать это по старинке, через обмен выгрузками и метание файлов на дальние дистанции, можно чуть современнее, можно через веб-сервисы и так далее. Важна не техническая реализация, а общий принцип. Под интеграцией мы понимаем ситуацию, когда ИТ-системы предприятия работают с издержками ниже заданного уровня. Да, можно сделать на коленке с бабушкой и дискетами, но помните, что у бабушки внуки, лунный календарь посадки рассады и всё такое, а ИТ-инфраструктура должна работать всегда как часы, быстро перестраиваться и не быть тормозом для бизнес-процессов, которые на этой инфраструктуре работают.
    Вот для всего этого и нужна правильная интеграция.

    Подходы разные. Иногда мы используем прямой обмен данными, но чаще разделяем интерфейсы (потребителей сервиса — web-приложения, мобильные приложения, системы партнёров и т. п.) и поставщиков сервисов (АБС, ERP и так далее). И затем строим, например, шину для обмена данными. Если говорить о «бабушке-файлоперекладчице» как о самой древней технологии интеграции, то подход с шиной уже — индустриальный век. Интерфейсы отдают данные в шину, шина несёт их к исполняемым модулям и «говорит» им, что делать. По пути может выполняться преобразование форматов данных или протоколов взаимодействия, делаться дополнение данными из третьих систем, могут координироваться операции в разных системах и т. п. Потом результаты исполнения идут обратно к интерфейсам. Такой подход позволяет навешивать любое количество подсистем, более сложен во внедрении на первых этапах, но при более-менее большой информационной инфраструктуре имеет смысл, потому что позволяет экономить время и деньги за счёт повторного использования, надёжности, прозрачности и целой кучи других плюшек.

    Хотя видел один раз, что у заказчика было удивительно стабильное образование из пяти систем, которые напрямую бегали в базы друг друга и нормально обменивались данными. Года четыре это работало как часы. Потом они узнали, что можно сделать шину, и стало шесть глючных систем — пять имеющихся и ещё шина. Так что тоже не всегда идеальный вариант. Ошибка была в том, что они взяли шину и, не думая, перенесли как есть на неё свои прямые обмены данными. Дополнительный слой сложности и точку отказа получили, а выгод никаких от неё не получили — нужно было правильнее продумывать архитектуру и процессы.

    В реальном мире в чистом виде идеальная архитектура получается крайне редко. Потому что чтобы построить всё правильно и работающим как часы, сначала надо:
    • Понять, что происходит (причём у каждого отдела будет своё видение)
    • Понять, что нужно бизнесу в итоге (то есть нужен тот, кто видит картину в целом, и это чаще всего даже не ИТ-директор)
    • Понять, почему народ сопротивляется изменениям, не хочет пускать в свои системы и делиться своими данными (чаще всего — кому-то не выйдет воровать или кто-то потеряет контроль)

    Именно тут начинается самое интересное.

    Как начинается проект


    Обычно заказчик существует не в вакууме, и какая-никакая интеграция у него есть. То есть что-то уже работает, и его стараются не трогать. Есть, например, кол-центр, он умеет подтягивать данные о клиентах из общей базы. Организовано это через задницу, но организовано, и всё, уже хорошо. Проходит пять лет, поддержка выстраивает вокруг этого костыли. Затем система начинает обрастать новым функционалом, который вообще-то не для неё. Например, на базе корпоративного мессенджера вдруг появляется обмен большими файлами, на базе кол-центровой CRM начинают строить бизнес-аналитику (потому что там были зачатки готового модуля, и решили быстро сделать на них) — и в итоге в систему передают на порядок больше данных со всей компании, только чтобы нарисовать графики, и так далее. Выглядит, с моей точки зрения, это так:
    — Парни, вы же из ИТ, вы же умные. Сделайте нам вот такую мааааленькую штуку быстро и дёшево.
    — Для этого нужна такая-то система, это непросто.
    — Да ладно вам, слепите по-быстрому, это ж времянка.

    А нет ничего более постоянного, чем такие времянки.

    В итоге примерно раз в 5–7 лет заказчики понимают, что нужно внедрять новую большую систему или заменять совсем уже задыхающуюся старую — и вот здесь всплывает море всего того, с чем мирились годами. Начинается стадия разгребания ошибок.

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

    Вот взять то же внедрение секси-интернет-банков. Это фронт к АБС, то есть ядру банка. Надо соединять АБС, кредитный офис и все подсистемы, нужна шина и интерфейсы. Поначалу «на костылях» лепят выгрузками, и получается не очень онлайн-то банк. Потом приходит понимание, что можно разбить каждую операцию фронт-офиса на абстракции и сделать API к системе, которой пользуются служащие банка, и это API отдать интернет-банку. И только потом уже приходит понимание, зачем шина.

    Мы учим людей договариваться


    Как я уже говорил выше, если не влезть в бизнес-процессы, то проект обречён.

    Вот пример: сначала всё просто технически. Два отдела, в одном данные обрабатываются в 1С (бухгалтерия), во втором — в HRMS (система кадрового учёта). Пока сотрудников было две сотни, всё было хорошо: выгружали CSV, импортировали в другую систему, выдавали зарплату и всё хорошо учитывали. Через 6 лет сотрудников стало под тысячу. Шесть человек в отделе кадров занимались тем, что вручную выполняли такты скрипта. Мы пришли писать этот скрипт. Звучит просто, правда?

    Пересадить кадровиков в 1С и наоборот нельзя (точнее, экономически необоснованно) — их приклад делает то, что прикладной софт другого отдела не может. Поэтому можно или сделать на основе одной из систем мастер-хранилище данных, или же сделать его снаружи.

    И вот в этом месте уже начинается политическая грызня, чья система главнее. Потом — кто и как будет выгружать данные, в каких форматах, в какой кодировке. Эпический холивар между 1251 и UTF-8 в одной компании длился месяц совещаний (это в другом проекте, обычно конкретно этот вопрос как раз шина решает с лёгкостью).

    Затем надо договориться, какой формат данных универсален. Здесь оба отдела рассказывают, что им нужно в базе данных и что они будут использовать. Только потом, когда они точно поймут, что и как, можно решать. В этой истории мы использовали индексное хранение — на сервере интеграции были ссылки к разным кускам базы (и конвертеры) — как картотека в библиотеке, отдельного data lake не было.

    Ключевой момент — чтобы люди договорились между собой, какие данные, как и где будут использоваться, кто их туда кладёт, откуда и почему. Если это есть — всё остальное уже техника. Именно это мы и помогаем делать, и уже из того, что нужно бизнесу, рождаются технические решения.

    Если пример с бухгалтерией и кадровиками слишком абстрактен и прост, представьте ситуацию, когда один банк поглощает другой. Просто подумайте, что вам нужно соединить и дописать, чтобы разные ИТ-системы работали вместе и позволяли в отделениях делать вообще всё, что привыкли делать клиенты. Я бы очень хотел почитать хроники такого ИТ-директора, например. Но это всё обычно под жёстким NDA.

    Истории


    Первая история — не байка. Просто посмотрите, как развивалась СМЭВ — интеграционная шина масштаба всей страны. Это обмен данными между ведомствами. Например, чтобы при получении загранпаспорта вам не пришлось собирать справки и приносить военник. Логично же, правда? Все документы на вас у государства есть, и надо просто запрашивать их внутри системы. Но нет. Кто знает эту историю — теперь подключиться к СМЭВ довольно сложно. Потому что сейчас в боевом виде работает уже третья реинкарнация шины. Первая версия была уровня беты — было очень сложно научить ведомства просто определять, что за данные у них есть и как их выгружать. Во второй подключали многих, и в результате появилось дикое количество функций без должного уровня абстракции, разработанных не всегда оптимально. В третьей версии обновили документацию, ввели больше проверок и аттестаций. Теперь данные приходят в систему в более-менее едином формате.

    Вообще, части любой интеграции — это данные, интерфейсы, люди, приложения. Приложения — понятно, это обработчики данных. Например, если надо выдать зарплату Иванову, то обработчик может этим заняться. Данные — это абстракции в чистом виде, то есть информация о том, как отличить Иванова от других людей, какая у него зарплата и так далее. Интерфейсы — это откуда берутся команды, например, софт кадровика предприятия или XLS. Люди — это люди, которые что-то хотят и делают. Их обычно упускают из виду.

    Вот ещё пример. Помогали одной организации выстроить клиентский сервис и продавать больше. При этом организация немолодая, информационных систем у неё много, а данных — ещё больше. Для начала надо было понять, а кто вообще клиенты этой организации. Один и тот же человек мог оказаться Васей Ивановым (или вообще «Пушистым Чепушилой», если данные из профиля соцсетей), Ивановым Василием, Ивановым В. А. или «паспорт номер 1234 5678901». Для начала нужно понять, сколько здесь человек: это всё один и тот же Вася или это ошибки типизации? У той организации было несколько миллионов записей о клиентах. Оценка была — по пять записей на человека. Сделали очистку, дедупликацию — сократили до 1,4 записи на человека. Было очень много неоднозначных данных ещё с бумаги, в том числе со старых гроссбухов — там могли оказаться только фамилия и инициалы.

    Часто заказчик неправильно ставит ТЗ, не думая, что и как. Например, было у нас требование про 100 транзакций в секунду. Но при этом имеющаяся система умела обрабатывать всего 5 записей в минуту. Говорили, расширяются. Пришлось менять железо, лицензии, перестраивать очень многое в инфраструктуре. Оказалось, им нужно было около 2 записей в секунду (120 в минуту), и это можно было сделать на текущем железе с минимальными изменениями. И это требование на 5 следующих лет. Не посчитали — потратили много лишних денег. Спрашиваем: мол, почему сотня транзакций-то? Нам объясняют: это специальный аналитик посчитал. Когда мы потом отмечали запуск в эксплуатацию, то этот аналитик признался: мол, число красивое.

    Само по себе внедрение редко делается долго. Больше — проектирование. На этом этапе владельцам систем надо договариваться, какие данные кто кому открывает, кто несёт ответственность за данные, какие процедуры контроля. Начинается разворашиваться муравейник — это дико сложно организационно и психологически. Потому что люди в России цари: «Мои системы, мои данные, не отдам снаружи, а то вдруг скажут, что плохо работаем. Не хочу такого». Большой риск, но при должной настойчивости решается.

    Больше всего усилий на этой стадии могут потребовать совещания на выживание. Был, например, проект объединения нескольких подсистем в одной компании с госучастием. И за часть подсистем отвечали другие компании, которые там жили очень долго до этого. И привыкли работать в своём темпе. Самое страшное случилось в середине проектирования — одна из компаний очень хотела повысить свою значимость, и мы каждую неделю приезжали на совещания с ними. Полгода они вырабатывали решение, что разница между численными показателями внедряемых систем не очень важна, а важно, чтобы всё это работало.

    Или другой пример: в одном банке собирали на совещания всех, при этом моего участия было явно минут на 5. В итоге — минус 3–4 часа. По сути — полностью потраченный день, что бывает очень обидно. Но если заказчику важно, ничего не поделаешь.

    Есть мнение, что любой подход можно шаблонизировать, то есть у нас есть конкретная задача, которую можно декомпозировать до того, чтоб там сделать действие 1, действие 2, действие 3, переложить файлик. И потом под неё выбрать уже готовый инструмент либо написать свой, если ты понимаешь, что ты делаешь. Но надо сначала понять задачи, для чего мы это делаем. Когда сталкиваешься с конкретной интеграционной задачей, ты решаешь конкретную интеграционную задачу.

    Бывает, после построения стучат к нам: мол, «шина ваша не работает». Правильно, появилась новая сущность — валите всё на неё! Поэтому в правильных проектах вводят специализированные системы мониторинга, чтобы долго и мучительно не разбираться в том, что и где упало. Такие инструменты сразу показывают, какая подсистема и где не отвечает. В одном из проектов всё равно первый алерт получали те, кто отвечал за шину, то есть мы.
    — У вас шина не работает!
    — Да не, это у вас вот тут не работает.
    — Ааа, ну ладно. Не расслабляйтесь там.

    Или вот сдача-приёмка. Есть 8 сервисов, надо сдать их за один тестовый день. Два модуля наши, остальные писали другие компании. Бизнес в субботу «играет» в свою деятельность в новой системе, по очереди испытывая модули. Всё отлично. Суббота закрыта, вечером все едут по домам. Переключение. Это правильный процесс.

    Другой банк перенимал опыт, построил процесс так же. Только тестировал не на полной инфраструктуре, а по частям. Не сводя всё в полный процесс, не проверяя связки между модулями (точнее, проверяя базово, на уровне простых тестов). А в понедельник после переключения оказывается, что никому у заказчика в голову не пришло проверить взаимодействие систем при определённых условиях. То есть они протестировали все отдельные сервисы, но не то, как они взаимодействуют между собой, Карл! Начинают колбасить запросы, что-то отправлять, получать, ещё что-то. Вечером одна из подсистем начинает создавать поток данных, который просто перегружает другую, и начинается цепная реакция. Всё падает.

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

    Широкополосное шоссе с данными


    Мы, по сути, работаем переводчиками. Есть заказчик от бизнеса, который говорит: «Нам надо вот этот». А его никто не понимает дальше. Поэтому проблемы, цели и устремления бизнеса надо перевести на технический язык, чтобы донести разработчикам. А потом проблемы разработчиков донести до бизнеса так, чтобы им было понятно, что упадёт, если не учесть их потребности. И прежде всего — как это всё выстроить в архитектуру, потому что чаще всего на предприятии образуется некое лоскутное одеяло: здесь одно, здесь другое, здесь третье. Это совсем разные языки, разные справочники, разные команды. До каких-то пор они как-то друг с другом ладят, но задача всей интеграции заключается в том, чтобы из этого одеяла сделать такое широкополосное шоссе с данными, на которое приезжают со всех сторон, и всем всё понятно: откуда, куда, на каких автомобилях и зачем.

    Самое страшное, что ИТ-отдел и бизнес живут в разных реальностях. ИТ далеко не всегда знает, что реально важно для бизнеса (какие операции наиболее ценны, например, где нужно оптимизировать прямо до зарезу, а где совершенно не важно), а бизнес не знает, какие проблемы у ИТ. «Серваки надо докупить, а то новый год не переживёте» — и вдруг всё становится понятно. А до этого они просто не знали, что «максимальная расчётная нагрузка» — это то, что имеет отношение к очередям на праздники. В таких случаях нужен кто-то, кто способен переводить ИТ-язык на бизнес и помогать им между собой договариваться.

    А ещё я обожаю истории, когда кто-то молча что-то меняет в уже готовых системах. Был у нас один герой, который перед Новым годом «навёл порядок в справочнике», удалив записи, которые показались ему ненужными. В результате на таможне сгнило несколько фур продуктов, потому что данные не шли. Мы знали, что сломалось, но человек, который имеет доступ к маршрутизатору, был в отпуске. Это по регламенту мог сделать только он. По правилам безопасности нужно прийти в комнату, открыть один замок, потом второй замок, зайти в серверную, открыть клетку, там открыть консоль, записать информацию в консоли и сделать всё в обратном порядке.

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

    Ну и на всякий случай моя почта: AnIvanov@croc.ru.
    КРОК
    IT-компания

    Комментарии 12

      0
      А в понедельник после переключения оказывается, что никому у заказчика в голову не пришло проверить взаимодействие систем при определённых условиях. То есть они протестировали все отдельные сервисы, но не то, как они взаимодействуют между собой, Карл! Начинают колбасить запросы, что-то отправлять, получать, ещё что-то. Вечером одна из подсистем начинает создавать поток данных, который просто перегружает другую, и начинается цепная реакция. Всё падает.


      Андрей Иванов
      Эксперт по корпоративной архитектуре

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

      Спасибо, ваш кэп. )
        +3
        подрядчик не всегда имеет весомый голос, как правило его может перевесить слово заказчика.

        пост хороший, чем-то стиль Сергея Абдульманова напомнил. Жалко мало деталей, Сергей на них не скупился :)
          +2
          Ну не знаю, я все понял.
          Че-то там начало куда-то отравлять, получать, колбасить запросы, поток данных и как результат цепная реакция.

          Интеграционное тестирование? Нагрузочное тестирование? Нет не слышали.
          И эксперт бесплатно про эти риски не обязан рассказывать, только если его поставят Самым Главным Генеральным Подрядчиком. )
            +4
            Эксперт (и не только) обязан про это рассказать. Но рассказы хорошо работают, если за проект отвечает один исполнитель. А как быть в случае, если исполнителей на проекте пять-десять, у всех свои контракты, все контракты заключены в разное время и разными людьми от заказчика? Как-то так все время получается, что без Самого Главного Генерального Подрядчика (которым, кстати, бывает и сам заказчик при наличии экспертизы и опыта) не то что про тестирование забывают, но и про синхронизацию работ по датам, про взаимозависимости и т.п.
              +3
              как-то так все время получается, что без Самого Главного Генерального Подрядчика


              А вот такой он, корпоративный сектор. В тепличных-то условиях и дурак справится.

              Вообще говоря, работали с вами, и отлично помню что у вас народ большие любители совещаний и ВКСов. Вот и бейте на них тревогу, предупреждайте Заказчика и прочих участников что без такого-то и такого-то тестирования запуск не получится. Солидарная ответственность, знаете ли.

              В крайнем случае обсуждайте санкции, чтоб они были не в вашу сторону, когда «все упадет».
        0
        Спасибо, уточнили некоторые ранее неизвестные «грабли».
          +1
          Как все знакомо до жути, не смотря на то, что всего лишь занимался автоматизацией мелкой конторы по распилу ДСП…
          Весело, когда свой внутренний IT-отдел кроме всего прочего выступает переводчиком между бухгалтерий и руководством. Ну вот когда реально люди каждый день встречаются на совещаниях, а разруливать фантазии руководства и требования бухгалтерии приходится тебе, ибо сами они договориться не могут. Челночная дипломатия…
            0

            Хорошо, когда внутренний IT-отдел может выступить переводчиком между бухгалтерией и руководством. Плохо, когда они все разговаривают на разных языках. И не только бухи с манагерами, но к ним добавляются логисты, закупщики, продажники...

              0
              Скажем так, остальные отделы просто втихую саботировали работу из принципа «нам и так норм», что было преодолимо, но постоянно приходилось к каждому отдельно приходить и договариваться.
              Но вот были еще вначале один, потом другой программисты 1С и приходилось еще и им на пальцах объяснять, что от них хотят все эти люди. Благо второй хотя бы после этого задачи решал быстро и хорошо, ага. Про первого этого сказать не могу…
            0

            Радует, что наш корпоративный сектор дорос до ESB. С нетерпением жду внедрения SOA в следующем десятилетии.

              0
              ...100 транзакций в минуту — это специальный аналитик посчитал. Когда мы потом отмечали запуск в эксплуатацию, то этот аналитик признался: мол, число красивое.
              .

              Метод «пальцем в небо» характерен для большинства аналитиков.
                0
                Так что если решитесь что-то менять в ИТ

                … в случае незапланированныйх изменений (даже на первый взгяд незначительных) не делайте это по пятницам и перед праздниками.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое