Проблемы технических партнёров и их предупреждение в мини-историях

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

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

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

Как-то так это всё и работает...

По началу у меня дыбом волосы вставали, когда я узнавал, что по ту сторону нет никакой информационной системы, более продвинутой, чем табличка в Excel (в лучшем случае). Но, как оказалось — это одни из лучших партнёров (вторая категория лучших партнёров — это те, кто реализовывал наш протокол). Мы очень быстро написали собственную информационную систему, которая решала не только проблему обмена информацией, но и в какой-то степени автоматизировала бизнес партнёра, за что мы получали плюс в карму.

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

Пример одной крайности: партнёр выдал нам протокол (SOAP). Ок, вот вам Java, вот JCP (т.к. там была ГОСТовая ЭЦП) — работаем. Шлюз написан, на нашем тестовом эмуляторе всё работает — переходим к тестам с партнёрами. И… что бы вы думали? Не работает! Причину искали 3 (три) месяца (саппорт партнёра реагировал очень вяло и в результате проблему подключения пришлось решать на уровне руководства двух компаний). Оказалось, что на той стороне SOAP был реализован с «небольшой особенностью»: вместо

<tagName></tagName>

нужно отправлять

<tagName><tagName>

А что же JCP? Не понадобилось, т.к. на той стороне отсутствовала реализация.

Пример другой крайности: коммерческий отдел приносит протокол, ок, да? Протокол реализован, совместные тесты с партнёром (!) пройдены, нужно включать продакшн.
У партнёра этим занимается другое подразделение, которое, как оказалось, не в курсе, что реализованный нами протокол — это протокол их же компании. Результат: или реализовывайте другой протокол или ждите n месяцев (точную цифру не помню, но что-то около 10 месяцев).

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

А был ли мальчик?

Смог ли партнёр получить, а, самое главное, обработать полученные данные? Если вы думаете, что да, то пора взглянуть на мир по-новому.
Один из партнёров пропускал 10-20% запросов. Ну как пропускал… Принимал, но не обрабатывал. Это было особенностью их системы и преподносилось как фича. Я немного упростил проблему, т.к. там «отложенная обработка данных» была только для некоторых типов запросов и работала по настроению удалённой стороны, но суть не изменилась. Ещё раз замечу, что мы получали код ответа «запрос успешно принят» (кода ответа «запрос успешно обработан» не было), но по факту ничего не происходило. В описании протокола, естественно, эта особенность не была учтена.

Другой партнёр сообщал нам о поступлении нового запроса (XML-протокол, транспорт-HTTP), но не особо интересовался принят запрос или нет.
Тут был забавный прикол при разговоре с руководством компании-партнёра (тех. директора и ком. директора) на тему «как так». Дело в том, что с нашей стороны (в ответ на такую несправедливость) был реализован запрос с частотой раз в 5 минут «а нет ли весточки для нас?» и тех. директор партнёра назвал это dos'ом и заблокировал нас с указанием «пофиксить на своей стороне» (естественно, указание мы получили только после обращения с нашей стороны в саппорт партнёра, а не по факту отключения). Я подключил всё свое «обаяние» и убедительные аргументы при общении с коммерческим директором, а по факту его согласия, что мы со своей стороны всё делаем правильно (о позиции тех. директора он ещё не знал) потребовал e-mail с подтверждением. В результате ответы от ком. директора и тех. директора ушли им обоим на почту с просьбой договориться. Через час нас включили по нашей схеме.

Правило второе: ответ об успешном получении запроса (а иногда и об успешной обработке запроса) не всегда означает, что запрос действительно успешно обработан.
Вывод: необходимо (естественно, при наличии возможности) удостовериться другим способом об успешном выполнении запроса.

Вы под надёжной защитой.

Об SSL-сертификатах будет дальше, но я не могу здесь не упомянуть одну забавную историю.
Мы получили протокол, который подразумевает SSL-шифрование. Всё работает, тесты пройдены, но… не с тем сертификатом.
В результате небольшого исследования выяснилось, что удалённая сторона вообще не проверяет сертификат.
Другой партнёр (которые работал по нашему протоколу) слишком буквально принял примеры запросов и во время тестов отправлял сигнатуру из примера (видимо, не осилил раздел N «Подпись сообщения»). Естественно, со словами «ничего не работает» наши коммерсы прибежали в отдел интеграции (который на тот момент уже существовал).

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

Есть такая штука, 3-D Secure ^[1] называется. Реализуется на стороне банка.
В один прекрасный день, ко мне подходит коммерс и сообщает, что 3-D Secure не работает (на самом деле, не моя проблема, но так уж сложилось, что если никто не знал к кому подойти с проблемой, то подходили ко мне). Как не работает? Ну работает, только там в самом низу страницы (скроллить где-то две пустых страницы в браузере) есть серым по белому кнопка «отмена» (которая просто пропускала платёж без 3DS). Вот так не хитро без регистрации и без смс без авторизации у одного (довольно крупного) банка работал 3-D Secure.

Правило третье: самостоятельно реализованные системы ограничения доступа не работают.
Вывод: необходимо дополнительно усиливать меры безопасности стандартными и проверенными средствами (но см. правило 5).

Спутник в Тихом океане.

Один раз я получил звонок на мобильный: «Здравствуйте, Алексей! Это компания **** (тут название всем известной компании). Вы оставили заявку на наш продукт ****». Я думаю, что вы понимаете, что если бы я действительно оставлял заявку на этот продукт, то об этом бы здесь не писал ^[2]. Как выяснилось, двумя минутами раньше, и нашему коммерсу поступил аналогичный звонок.
Ситуация оказалась простая: мы с коммерсом тестировали свежеиспечённый функционал нашей системы, результатом которой был реестр, предназначенный для передачи партнёру. И партнёр этот реестр получил (вручную отправленный нашим коммерсом по электронной почте менеджеру с той стороны с просьбой проверить формат реестра). Что произошло на удалённой стороне я не знаю, но в результате он как-то попал в обработку.

Другой случай: в определённый момент наша система была развёрнута одновременно на двух технологических площадках (по бизнесОвым соображениям) и работала то там, то там. Через некоторое время мы получили претензии от некоторых наших клиентов, что их запросы не обработаны. Внезапно. Не знаю как такое может быть, но по каким-то причинам, в зависимости от технологической площадки, запрос уходил либо на продакш-сервер партнёра, либо на тест. Выясняли причину долго, пока наш саппорт не догадался провести traceroute с обеих площадок и выяснилось, что, в зависимости от площадки, запрос, направленный по одному IP-адресу, уходил на разные сервера (судя по traceroute, в случае запроса с одной из площадок, внутри сети клиента запрос проходил даже по разным маршрутизаторам).

Правило четвёртое: если запрос может уйти не туда, он уйдёт не туда.
Вывод: см. правило 2.

Кто здесь?

А можно ли доверять уважаемым и проверенным решениям? Думаю, что вы уже понимаете, что нет, если настройка этих решений в руках партнёра. Про роутинг история выше, про SSL тоже, но вот ещё парочка:

Однажды нам выдали шлюз с адресами похожими на: gateXXX.comp_name.com (где XXX не adult, а вид шлюза). Надо ли говорить, что после первой недели продакшена упал DNS партнёра? Думаю, что и лишнем будет говорить, что после подъёма DNS он отдавал ИП-адреса в обратном порядке. Но к этому моменты мы были уже «прошаренные» и не доверяли primary-серверам DNS.

SSL — это вообще отдельная песня.
Вы всё ещё доверяете сертификатам? Тогда мы идём к вам ^[3]. Хорошо, если у партнёра из коробки была хоть какая-то защита данных (хотя бы от подмены в виде ключа и md5). Вообще, у нас был целый отдел информационной безопасности (который работал параллельно с другими отделами безопасности), который на своём уровне проталкивал идею криптографии. Но очень часто и это не помогало. Некоторые партнёры предлагали просто передать md5 от тела сообщения, кто-то использовал, в лучшем случае, самоподписные сертификаты, в худшем — от godaddy, но выданные на другой домен. Про криптографию по ГОСТ (и как саппорт настраивал оборудование) я вообще не хочу писать.

Одно мы знали точно: без объявления войны в любой момент времени может произойти всё, что угодно: от истёкшего срока годности сертификата (на это мы, как правило, вообще не обращали внимание — только в мониторинге появлялся ещё один аларм) до смены алгоритма шифрования.

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

(Опять) Ничего не работает.

Ох, как часто я слышал эту фразу от… неееее… не бухгалтера, а от технарей по ту сторону.

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

Белые и пушистые

Нет, я не хочу сказать, что мы были такие белые и пушистые, что у нас всё работало. Естественно, и у нас косяки встречались. Были даже очень не приятные, о которых не буду писать (т.к. я последнее время занимался не столько техникой, сколько «бизнесом»). Но соблюдение технологий, глубокое понимание соответствующих стандартных (а так же наших!) протоколов, ответственность, готовность думать «за всех» — это были требования к кандидатам на должность начальника отдела интеграции.

А вообще, интеграция с on-line системами — это весело, увлекательно и интересно. Я познакомился со многими хорошими специалистами, увидел много интересных архитектур протоколов и систем. И стал лечить по фотографии.

Автор: devpreview

Источник ^[4]