В крупных организациях огромная инфраструктура и множество систем, каждой из которых предоставлен определенный раздел функций и операций. Проекты в этих организациях зачастую охватывают не одну систему, а несколько. Для полноценного и правильного функционирования бизнес-логики в таких проектах эти системы должны корректно взаимодействовать, передавая потоки данных с необходимой скоростью и в определенных форматах.
К сожалению, бывают неприятные ситуации, когда продуктивный запуск таких проектов показывает, что системы реально работать вместе не могут. Это связано с тем, что реализация корректного взаимодействия - непростой процесс.
Как не заблудиться команде разработки в IT-инфраструктуре и как не попасть в ловушки интеграции, чем нужно вооружиться, ступая на этот путь?
В данной статье описаны основные стадии реализации эффективного взаимодействия систем с точки зрения команды разработчиков. Важные моменты, сложности и методы борьбы с ними, на собственном опыте проверенные не одной командой разработчиков в самых разных проектах.
Стадия нулевая. Решение о необходимости интеграции.
Бизнес-функциональные требования составлены. Без IT-решения не обойтись. Формирование состава программной части IT-решения начинается на уровне системных архитекторов. Именно эти люди продумывают архитектуру сложных систем, формируют инфраструктуру и определяют, какие системы и как будут взаимодействовать. И только когда решение принято, к проекту подключается команда разработки. Вот тут-то и начинается сложный процесс интеграции систем.
Стадия первая. Анализ архитектуры.
Начало проекта положено. Команда разработки изучает архитектуру IT-решения и бизнес-функциональные требования. Здесь важно, чтобы архитектура была понятной и не вызывала вопросов. «Мутные» моменты могут таить в себе ошибки архитектуры, поэтому их нужно как можно раньше прояснять совместно с архитекторами. Требования к системе должны быть не противоречивыми и полными. Прояснение всех неопределенностей и противоречий на данном этапе может сильно сократить затраты на последующих этапах. К сожалению, иногда из-за невнимательности ошибки архитектуры выявляются слишком поздно. И тогда IT-решение не выполняет своих бизнес-функций, а архитекторы, допустившие ошибку, стараются переложить вину на разработчиков. Чтобы не попадать в такие спорные ситуации, команде разработки нужно проводить полный анализ архитектуры решения и требований к системе.
Стадия вторая. Согласование интерфейсов.
У разработчиков новый интересный проект, и им хочется скорее приступить к разработке, но спешить нельзя. В первую очередь необходимо согласовать с архитекторами и разработчиками смежной системы интерфейсы взаимодействия.
Интерфейсы могут быть известных стандартов. Могут быть и нестандартные интерфейсы: например, использование одной системой специфических методов другой. В первом случае, необходимо указать редакцию стандарта и в каком объеме он будет применен, а во втором случае детально описать новый интерфейс.
Важно вовремя остановить коллег, которые пытаются отложить выяснение неопределенностей на потом. При согласовании интерфейсов важно обсудить и зафиксировать все до мелочей, в большинстве случаев именно в них и кроются самые сложные и опасные проблемы.
Особое внимание следует обратить на следующие моменты:
• соответствие типов данных, например, int и longint, со знаком или без
• кодировки, применяемые для данных на стороне отправляющей и принимающей систем, если речь идет о частичном использовании файлов известного стандарта, что именно и каким образом будет использовано
• какой тип протокола будет использован, например, http или https
• время будет передаваться в формате GMT или только время, без указания часового пояса
• что ожидает смежная система для отображения пустого значения (null, 0 или, может быть, еще что-то)
• будет ли реализован метод в виде процедуры или функции
• все ли параметры являются обязательными или часть может отсутствовать
• коды ошибок передается в десятичном или шестнадцатеричном виде
• будут ли параметры приходить в определенном порядке или позиция параметра не имеет значения
• с какой стороны предполагается возможность завершения соединения
• соблюдается ли уникальность идентификаторов
и т.д.
Использование электронной почты для обсуждения деталей, как показывает практика, крайне медленный и неэффективный способ. Поэтому, по возможности, лучше организовать встречу разработчиков, именно разработчиков. Ни менеджеры, ни аналитики не знают технических тонкостей, которые могут иметь решающее значение. При необходимости такая встреча может быть и не одна. Если возможности встретиться нет, то можно использовать видео-конференции или Conference Call. В любом случае проговорить вопросы и проблемы голосом всегда быстрее и эффективнее, чем обмениваться текстовыми сообщениями.
Все окончательные решения и договоренности, принятые в ходе обсуждения интерфейсов взаимодействия, должны быть зафиксированы в виде документа. Таким документом может являться спецификация интерфейса, техническое задание на разработку каждой из смежных систем или любой другой документ, описывающий технические детали реализации каждого интерфейса. Этот документ должен быть внимательно изучен и одобрен представителями всех взаимодействующих систем. Здесь необходимо письменное подтверждение для простейшего разрешения спорных ситуаций на следующих этапах.
Таким образом, согласование интерфейсов взаимодействия – это основа успешной интеграции систем.
Стадия третья. Разработка.
Итак, все интерфейсы согласованы и начинается разработка. Кажется, что уже все согласовано и должно идти как по маслу. Но это только кажется, и расслабляться нельзя.
Процесс разработки системы может происходить: «после», «параллельно» и «до» разработки и тестирования смежной системы.
Первый вариант, после создания и тестирования смежной системы, является наиболее комфортным. Смежная система имеет стабильную версию и основные дефекты исправлены или известны. В этом случае применяется раннее интеграционное тестирование, т.е. тестирование программистом в процессе разработки. Зачастую, сложные и серьезные проблемы обнаруживаются именно разработчиком и именно на этой стадии. Решение обнаруженных проблем на раннем этапе является минимально трудоемким и дорогостоящим.
Во втором варианте, т.е. в случае параллельной разработки применить раннее тестирование сложнее. Здесь важно тесное сотрудничество разработчиков смежных систем. Для осуществления проверок на стадии разработки, программистам необходимо договариваться о последовательности создания модулей. Также необходимо согласовывать время внесения изменений на интеграционные тестовые среды. Отсутствие взаимодействия между людьми в некоторых случаях приводит к необходимости переделывать интерфейсы, а иногда и по несколько раз.
Еще одной важной особенностью параллельной разработки является необходимость определения, на чьей же стороне дефект. Всем понятно, что сценарий не работает, но почему? Какая именно из систем что-то делает неправильно? Эти вопросы нельзя оставлять без ответа. Очень часто в подобных случаях включается подход «с нашей стороны пуля вылетает, проблема на стороне мишени». Задача менеджеров выключить этот подход в командах и разобраться: алгоритмы какой системы необходимо скорректировать.
Если же не разобраться в ситуации до конца или просто про нее забыть, то она в любом случае проявится, причем, скорее всего, в самый не походящий момент.
При параллельной разработке смежных систем нужно уделить особое внимание человеческому фактору, т.к. часто разработчики вступают в противостояние в случае возникновения проблем. В такой момент нужно вспомнить основную цель взаимодействия систем в рамках инфраструктуры: высокоэффективная работа нескольких систем с целью выполнения определенных бизнес-операций. Цель не будет достигнута, если каждая из смежных систем будет работать в соответствии с собственной спецификацией, и при этом вместе они работать не будут. А если цель достигнута не будет, то и профессионализм участников проекта будет подвергнут сомнению. К сожалению, приходится наблюдать и такие неприятные ситуации.
В третьем варианте, т.е. если необходимо разработать систему до начала разработки смежной системы, то речь не идет ни о раннем тестировании, ни тем более об интеграционном тестировании. Поэтому тут особую роль играет согласованный документ, в котором детально описаны интерфейсы взаимодействия.
Стадия четвертая. Функциональное тестирование.
Опытный тестировщик всегда скажет, что на интеграционном тестировании находятся самые хитрые и интересные дефекты. Нужно только знать, где и как их искать.
Интеграционное тестирование проходит в несколько этапов. В начале, тестировщикам необходимо провести статическое тестирование. Нужно проверить, что интерфейсы взаимодействия соответствуют описаниям.
Далее, если смежные системы еще не разработаны или не протестированы, возможно интеграционное тестирование через «заглушки» или эмуляторы. Этот вид тестирования широко применяется на этапе разработки. Однако, использование таких инструментов применимо не всегда. Затраты на создание «заглушек» должны быть не велики. Взаимодействие с «заглушками» должно происходить по протоколам, соответствующим работе смежной системы.
Следующий и самый важный этап тестирования взаимодействия систем – это интеграционное тестирование в среде, аналогичной продуктивной. Здесь должно быть все почти по-настоящему. Тестовая среда должна соответствовать продуктивной по таким параметрам, как:
• оборудование
• ОС с соответствующими обновлениями
• ПО окружения соответствующих версий и в нужном объеме
• сертификаты
• специфические драйверы необходимых устройств
• необходимые права и привилегии пользователей
Иногда, даже самое минимальное несоответствие может привести к необходимости начинать практически сначала.
Таким образом, задача создания среды является одной из ключевых. И тут не обойтись без представителя смежной системы: нужно договориться с ним о предоставлении тестовых данных и согласовать требования к ним. Это одна из тех задач, которая не даст менеджеру скучать.
Начинается тесное взаимодействие тестировщиков одной системы и администраторов другой. Для полной проверки всех интерфейсов взаимодействия тестировщикам необходимо изменение настроек и данных на стороне смежной системы. Такая совместная работа позволяет администраторам заранее изучить работу новой системы. Как показывает практика, иногда бывает полезно столкнуться с рядом проблем и найти их решения еще до продуктивного запуска.
Если при обсуждении интерфейсов было детально оговорено и согласовано все до самых мелочей, этап интеграционного тестирования протекает гладко. К сожалению, это случается крайне редко.
В случае обнаружения дефектов и их исправления, последует следующая итерация тестирования. Если для повторной итерации используется та же среда, необходимо привести ее в исходное состояние. Например, изменить или удалить предоставленные за время тестирования привилегии, удалить добавленных пользователей и другие внесенные изменения.
Стадия пятая. Нагрузочное тестирование.
Особое внимание следует уделить этапу интеграционного нагрузочного тестирования. Как показывает практика, даже если функциональное тестирование проходит успешно, то реальную нагрузку системы при взаимодействии могут и не держать.
При проведении нагрузочного тестирования необходимо убедиться, что предоставленные экземпляры смежных систем именно тестовые, т.к. нагрузочное тестирование на продуктивных экземплярах может привести, например, к реальным финансовым убыткам. Такие ситуации, к сожалению, бывают на практике: людям свойственно ошибаться – представитель смежной системы по ошибке мог предоставить ссылку не на тот сервер. Хотя иногда сознательно приходится тестировать нагрузку на продуктиве, например, когда тестовых сред смежных систем просто не существует. Поэтому иногда тестировщикам приходится работать в ночную смену, когда нагрузочное тестирование окажет минимальное влияние на реальных пользователей системы.
Если для интеграции разрабатывается абсолютно новая система, то часто применяется прием превращения тестовой версии в продуктивную. После завершения тестирования смежных систем данные на стороне новой системы удаляются, и она конфигурируется на работу с продуктивным экземпляром смежной системой.
Стадия шестая. Интеграция работает.
Наконец, все стадии пройдены, и системы запущены в продуктивную эксплуатацию. Но работа по реализации взаимодействия смежных систем не заканчивается. Теперь важно отслеживать тенденции развития каждой из них, а также согласовывать любые вносимые изменения настроек интерфейсов.
Ответы на следующие вопросы могут снова привести администраторов к системным архитекторам. Соответствуют ли параметры одной системы объему данных от другой? Не появилось ли между системами дополнительного оборудования? Повлияет ли добавление нового поля в сообщении на работу смежной системы? И многие другие вопросы.
P.S.
На протяжении всего проекта полезно записывать все трудности и особенности, с которыми столкнулись, а также проводить анализ этих записей, и, конечно, использовать полученный опыт в следующих проектах. Тут важен человеческий фактор, т.к. все детали и тонкости выявляют и контролируют люди – команда разработки.
Но все предусмотреть не получится никогда, т.к. каждый проект уникален. И именно уникальность каждого проекта добавляет команде разработки тот драйв, без которого было бы просто скучно!
Автор
Анастасия Аулова - Менеджер проектов. Ведущий тестировщик.
