47
На фазе приёмочного тестирования возможен риск выявления боль-
шого количества ошибок в программном коде, что потребует больших
затрат на доработку и устранение всех выявленных ошибок. Невозможно
предсказать, сколько ошибок будет найдено и как много времени пона-
добится на их устранение. Дополнительную сложность и риски добав-
лял формат передачи данных для партнёра и описанный в документации
способ взаимодействия, когда получение обратной связи о тестировании
зависило полностью от сотрудников компании партнёра. Данный риск
тяжело было оценивать, но он имел решающее значение на результаты и
длительность разработки.
Для предотвращения большинства рисков, еще на этапе разработ-
ки использовалась методология разработки через тестирования (TDD),
большое внимание уделялось юнит-тестированию и созданию и описа-
нию статических типов. Однако на длительность итераций общения с
коллегами со стороны партнёра мы физически не могли ни коим образом
повлиять. Поэтому было принято решение сократить количество итераций
взаимодейсвия с коллегами со стороны партнёра до минимума. В идеаль-
ном раскладе до одного единого. Для этого были написаны дополнитель-
ные функциональные тесты и модуль валидации результата при помощи
предоставленного в документации Perl-скрипта. Это позволило получить
результат – пройти проверку требований у партнёра с первой попытки.
Фаза внедрения.
Фаза внедрения может оказаться очень длительной, если заказчик по
каким-либо причинам будет не доволен разработанным продуктом, пер-
сонал автоматизируемой компании может негативно относиться к внедре-
нию нового программного обеспечения.
Для предотвращения рисков на данной фазе необходимо произвести
качественное обучение персонала ещё до начала внедрения, обучить служ-
48
бу сопровождения и поддержки. Понять какие проблемы могут возникнуть
в процессе внедрения и уже быть готовым к их решению. Постоянно
консультировать персонал по поводу возникших у них трудностей, создать
горячую линию для решения данных проблем. Снабдить подробной и
качественной документацией и инструментами автоматического развора-
чивания, запуска и остановки программного продукта.
49
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
По мере развития человечества происходит структуризация и оп-
тимизация имеющихся у нас данных и возможностей их использования.
При этом ключевой является информационная модель. Информацион-
ная модель — это важный и полезный инструмент, если правильно его
использовать. При создании сложных систем (например, программного
обеспечения) он позволяет проработать основные технические вопросы и
устранить возможные не состыковки.
Информационная модель представляет собой схему движения
входных, промежуточных и результативных потоков и функций
предметной области.
Представим информационную модель общения между серверами в
виде схематичной зарисовки. Имеется три стороны общения:
– Внешний сервер или релей, с которого электронное письмо поступа-
ет в ДЦ Интермедии;
– Почтовый сервер в ДЦ Интермедии;
– Сервер обслуживания запросов доступа к Блок и стоп листам на
стороне партнёра.
Информационная модель обработки входящего соединения пред-
ставлена на Рис.2.1
50
Рисунок 2.1 – Информационная модель системы взаимодействия с
партнёром
Как представлено на модели, внешний сервер инициирует подклю-
чение по SMTP протоколу, главной частью которого является SMTP-
сессия. SMTP-сессия это абстрактное представление процесса общения
между серверами по SMTP протоколу. На момент запроса и создания TCP
соединения для общения между серверами, почтовый сервер Интремедии
записывает в лог информации о входящем сообщении. Далее, когда внеш-
ний сервер по установленному соединению ”представляется”(при помощи
SMTP команды HELO/EHLO передаёт информацию о себе), почтовый сер-
вер с полученными данными (IP-адрес и HELO) делает запрос к партнёру
с целью получения информации – находится ли внешний сервер в чёрном
списке. В зависимости от полученного ответа почтовый сервер принимает
решение о необходимости отказать в принятии электронного сообщения
и закрыть SMPT-сессию, или на оборот вычитать всё содержимое и сло-
жить в свою внутреннюю очередь обработки (временное хранилище). На
51
каждое свое действие почтовый сервер формирует соответствующее лог-
сообщение.
Все лог сообщения сформированные почтовым сервером поступаю
на новое приложение, где агреринуются, формируются в соответствующий
формат и отправляются в приёмщик партнёра.
2.2.2 Характеристика нормативно-справочной, входной и опера-
тивной информации
Рассмотрим подробнее основные лог сообщения, которые поступа-
ют на приложение. Как видно из модели на Рис2.1 имеется два пути для
обработки входящего соединения по результату проверки у партнёра.
– Принять входящее соединение;
– Отвергнуть входящее соединение;
В зависимости от принятого почтовым сервером решения формиру-
ется разный набор лог-сообщений. Ниже приведены только значимые лог-
сообщения.
52
Listing 1: Пример логов принятого электронного письма
Nov 29 05:00:00 #serverName [#serverProcessId1]: Anonymous
TLS connection established from #clientRDNS[#clientIP]:
TLSv#TLSversion
Nov 29 05:00:01 #serverName [#serverProcessId1]: #
serverQueueId: client=#clientRDNS[#clientIP]
Nov 29 05:00:03 #serverName [#serverProcessId2]: #
serverQueueId: warning: header Subject: Test message
from #clientRDNS[#clientIP]; from=<
testMailBox1111@test15.com> to=<testMailBox7006@test11.
com> proto=ESMTP helo=<public1−server.net>
Listing 2: Пример логов отвергнутого электронного письма
Nov 29 05:00:00 #serverName [#serverProcessId1]: Anonymous
TLS connection established from #clientRDNS[#clientIP]:
TLSv#TLSversion
Nov 29 05:00:02 #serverName [#serverProcessId1]: NOQUEUE:
reject: RCPT from #clientRDNS[#clientIP]: 454 4.7.1 <
prodnotify@emaillabs.com>: Relay access denied; from=<
testMailBox1111@test15.com> to=<testMailBox7006@test11.
com> proto=ESMTP helo=<public2−server.net>
Где:
– serverName — Имя почтового сервера.
– serverProcessId1, serverProcessId2 — Идентификатор процессов за-
нимающихся обработкой входящих электронных писем. При этом
как видно, для отвергнутых писем обработкой занимается только 1
процесс, а для прошедших писем дальнейшая обработке передаётся
другому.
– clientRDNS, clientIP — Имя сервера и IP-адресс с которого поступило
соединение.
53
– serverQueueId — Идентификатор от временного хранилища присво-
енный сохранённому электронному письму.
Несмотря на современные рекомендации безопасности при общении
в сети, многие пренебрегают созданием защищённых соединений. В таком
случае лог-сообщение о входящем соединении будет иметь немного другой
формат – информации о TLS отсутствует.
Listing 3: Пример лог-сообщения при не защищенном канале
Nov 29 05:00:00 #serverName [#serverProcessId1]: Anonymous
connection established from #clientRDNS[#clientIP].
Из приведённых выше сообщений, не зависимо от результата, важ-
ными являются поля:
1 Наличие/Отсутствие TLS и его версия;
2 clientIP и clientRDNS
3 Значения полей последней записи:
3.1. proto
3.2. helo
Как видно из примеров Listing 1 и Listing 2 требуемая информация
находится в разных лог-сообщениях, приходящих в разное время. Соот-
ветственно данную информацию необходимо агрегировать принимая во
внимание следующие факторы:
– На приложение будут поступать логи с разных серверов. serverName
– важный параметр.
– Каждый почтовый сервер одновременно может обрабатывать сотни
и тысячи входящих соединений. На каждое соединение создаётся
свой процесс (в данном случае не процесс операционной системы,
а внутренний процесс сервера). serverProcessId – важный параметр.
54
– В зависимости от принятого решения, если письмо будет принято,
то оно будет передано другому процессу для дальнейшей обработки.
serverQueueId – важный параметр.
Итого, для агрегации данных мы имеем два способа.
Получение ключа для отвергнутых электронных писем:
???????????? = ???????????????????????????????????????? + ???????????????????????????? ????????????????????????????????1 >>= ℎ????????ℎ()
Для принятых писем алгоритм сложнее. Сперва необходимо по-
лучить ключ, как и ранее, и сохранить результат. После, если придёт
сообщение о передачи электронного письма в очередь (хранилище), то
следует по ключу получить значение TLS и перепривязать его к новому
ключу.
???????????? = (???????????????????????????????????????? + ???????????????????????????? ????????????????????????????????1 >> ℎ????????ℎ()) >>
???????????????????????????????????????? + ???????????????????????????????????????????????????? >>= ℎ????????ℎ()
2.2.3 Характеристика результатной информации
На выходе, после получения и агрегации всех необходимых данных
требуется сформировать исходящее сообщение в формате json Listing 4
требуемым приёмщиком со стороны партнёра. Оно обязательно должно
содержать рассчитанный хэш от всего сообщения и соль по формуле:
ℎ????????ℎ???????? ???????????????????????????????? ????????ℎ???????????????? = (???????????????????????????????????????????????? + ????????????????????????????????????) >>=
????????5()
55
Listing 4: Пример исходящего сообщения
#hashOfMessageWithSalt
{
”TYPE”:”SMTP_C”,
”feed”: ”our−feed”,
”timestamp”: Now(),
”srcip”: #clientIP,
”HELO”: #heloFieldValue,
”rDNS”: #clientRDNS,
”proto”: #protoFiledValue,
”TLS”: bool,
”TLSv”: #TLSversion
}
Где:
– Type — Тип записей. Всегда константа
– feed — Идентификационные данные для партнёра. Константа
– timestamp — Время отправки сообщения в формате Unixtime
– TLS — true/false в зависимости от типа соединения
– TLSv — Версия TLS если значение TLS=true
– srcip, HELO, rDNS, proto — Данные о SMTP-сессии.
Исходящие данные необходимо валидировать по следующим мини-
мальным условиям:
– ”srcip” (source ip) – IP-адреса источника входящего соединения не
должен быть пустым;
– Необходимо отсеивать ”srcip” в локальных подсетях;
– ”HELO” – строка представления сервера не должна быть пустой;
– Необходимо экранировать все символы выходящие за пределы про-
межутка (”x21”, ”x7e”);
56
2.3 Программное обеспечение задачи
2.3.1 Общие положения (древо функций и сценарии диалога)
Реализованный программный продукт имеет сквозное строение с
несколькими тупиковыми ответвлениями. Где главным объектом проходя-
щим через систему является Message(Сообщение). Как представлено на
Рисунке 2.2, входящие данные (лог-сообщения) поступают к приложению
по UDP, где принимаются при помощи программной сущности Listener, в
задачу которого входит вычитать получившееся сообщение и передать его
обработчикам (Worker).
Рисунок 2.2 – Обработка сообщений в системе.
Такой подход зарекомендовал себя как самый производительный, в
противовес когда каждый обработчик пытался вычитать лог-сообщение
самостоятельно. В этом случае происходила борьба за ограниченные ре-
сурсы, что в итоге приводило к деградации производительности. Подход
с обработчиками так же был выбран с целью переиспользовать ресурсы и
сократить нагрузку на сборщик мусора.