(l) Копилефт (copyleft) 1998-2018 гг.

• результат использования наследует лицензию "copyleft";
• в полученном результате присутствует отсылка на автора, лицензию "copyleft" и место размещения настоящего текста.

=== Серверная "служба доставки" (данных) ===

(‘Delivery service’ conception)

Предисловие

Для обеспечения долговременного решения стоявших передо мной задач, в конце 90-х была разработана и реализована "служба доставки" данных (далее - "служба"). На платформе ОС Windows. В составе: самодельный монитор/шедулер (далее - "пускач") + обвязка на интерпретируемых скриптах (CMD, AWK, VBS) + комплект вспомогательных утилит (например: BinkD, BlAt, 7z, etc.).

Предназначение

Служба предназначена для регулярного автоматического транзита данных (в т.ч. и с преобразованием) от систем, их предоставляющих (далее - "источники"), к системам, в них нуждающимся (далее - "потребители"). Т.е. служба выступает как посредник между системами, не имеющими штатной возможности (приемлемого качества) взаимодействовать напрямую.

Историческая справка

1996. Постановка задачи: "нужно регулярно копировать/перемещать данные туда-сюда между рабочими местами (персонала) и между ними и общим файловым сервером предприятия".
1998. Формирование концепции службы в самом общем виде, первый работающий макет, выдача технического, задания на разработку технологического пускача.
1999. Сдача в опытную эксплуатацию (на производстве, в режиме 24/7) прототипа службы, около 15-и источников/потребителей на головном предприятии (г. Владивосток).
2001. Расширение обслуживания на весь Приморский край, около 50-и источников/потребителей. Формирование концепции службы в целом завершено. Продолжается формализация и обкатка технческих требований к отдельным подсистемам службы. Расширяется номенклатура обслуживаемых типов интерфейсов взаимодействия (далее - "стыки") с источниками и с потребителями.
2003. Начало постулирования ключевых требований к персоналу, обеспечивающему сопровождение и поддержку службы и требований к партнёрам, обслуживающим источники и потребителей (разграничение ответственности).
2005. Начало обслуживания данных от контрагентов (сторонних организаций, в масштабах края).
2007. Скачкообразный рост количества источников и объёма обслуживаемых данных. Развёртывание экземпляров службы в других городах Дальнего Востока (Благовещенск, Магадан, Петропавловск-Камчатский, Южно-Сахалинск), подключение к службе источников/потребителей в гг. Москва и Санкт-Петербург.
2012. Пик востребованности службы, сотни первичных источников данных по всему Дальнему Востоку, десятки каналов "точка-точка" до головных серверов во Владивостоке, гигабайты данных, обслуживаемых ежедневно.
2018. Служба остаётся востребованной и работает стабильно уже 18 лет. Без существенных замечаний.

=== Концепция службы ===

Основные положения

1. Разграничение ответственности вовлечённых.
2. Круглосуточный автоматический режим работы.
3. Гибкость.
4. Прозрачность.
5. Живучесть (устойчивость и надёжность).
6. Ремонтопригодность.
7. Самодостаточность (автаркия, в т.ч. и самообслуживание).
8. Бюджетность (лирическая констатация).

Подробности…

1. Разграничение ответственности вовлечённых.

1. Источник отвечает за все проблемы источника;
2. Служба отвечает за все проблемы службы;
3. Потребитель отвечает за все проблемы потребителя;
4. За стык отвечают состыкованные + ответственные за среду передачи;
5. Возможно добровольное участие сторон в "не их" проблемах;
6. Ответственность за службу несёт технолог, а админ - за место размещения оной, - если это разные люди, то админ не имеет права непосредственно вмешиваться в работу службы, а технолог, - в работу места размещения. Исключения:
   • критическая аварийная ситуация;
   • предварительно согласованное (с другой стороной) действие.
7. Любые "заинтересованные" лица (включая начальство) получают доступ к данным, протоколам и т.п. службы только через технолога (т.е. опосредствованно). Исключение — специально обустроенные в составе службы "шары" (места с жёсткой регламентацией доступа);
8. Ответственность за собственно данные:
   • источник отвечает за корректность отправляемых данных (включая их целостность и непрерывность); Вплоть до поступления от потребителя квитка "принято";
   • если служба видоизменяет поступившее, то она (частично) разделяет вышеуказанную ответственность;
   • оперативные проблемы с данными должны устраняться вовлечёнными сторонами незамедлительно (по возможности);
   • такие же проблемы, но обнаруженные post factum, устраняются с помощью механизма служебных расследований.

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

2. Круглосуточный автоматический режим работы.

1. Служба действует по принципу: данные, - это "горячая картофелина", т.е. поступившие данные должны незамедлительно обрабатываться и отправляться дальше (получателю);
2. Обслуживаемые данные формируются/предоставляются источниками периодически (по мере готовности/возможности);
3. Период поступления зависит от особенностей источника и типа данных. Может варьироваться от "один и более раз в час" и до "один раз в месяц";
4. Допускается приостанавливать получение/обслуживание новых данных в ЧНН (часы наименьшей нагрузки) для самообслуживания службы (см. ниже секцию "7. Самодостаточность");
5. Устанавливается общий минимальный допустимый интервал времени обслуживания данных. Для некоторых типов данных, требующих длительную обработку, минимальный допустимый интервал обслуживания соответственно увеличивается;
6. Устанавливается общая максимальная задержка в транспортировке данных от источника до потребителя;
7. Однако, по возможности, служба должна обслужить все, сформированные и предоставленные источниками данные за последние 24 часа, к началу очередного рабочего дня;
8. Вмешательство технолога (ответственный за службу) требуется только в случаях:
   • развёртывание службы;
   • добавление/изменение/удаление отдельных задач (или подсистем целиком);
   • ремонт после аварий;
   • свёртывание/перенос службы в другое место.
   NB.Тем не менее, технолог обязан обеспечивать надлежащий присмотр за службой ("ломается всё").

3. Гибкость.

1. Независимость отдельных задач (обслуживания потоков данных) от других таких задач;
2. Простота внесения изменений в:
   • конфигурационные файлы;
   • рабочие области подсистем;
   • алгоритмы работы подсистем;
   • общий состав службы.
3. Низкие требования к месту развёртывания/эксплуатации службы;
4. Унификация (по возможности) всех компонентов/решений службы (соглашения, структуры, интерфейсы, протоколы и т. п.);

NB. Сторонние потребные компоненты, несоответствующие требованиям унификации, должны, или дорабатываться, или "заворачиваться" в соответствующие скрипты (и применяться только посредством этих скриптов);

4. Прозрачность.

1. Все действия службы и события (оной касающиеся) должны детально протоколироваться; В частности, вмешательства технолога в службу должны (по возможности) тоже протоколироваться;
2. Процессы службы должны вести собственные протоколы:
   • либо в виде "plain text" файлов (процесс типа "ЗАДАЧА");
   • либо в виде выдачи на StdOut (процесс типа "ФУНКЦИЯ") для перехвата пустившими их процессами (типа "ЗАДАЧА").
3. Протоколы в виде файлов должны создаваться/пополняться в обустроенном "особом" месте ("для протоколов");
4. Причём каждый протокол должен содержать достаточный набор атрибутов и сведений для выяснения:
   • "КОГДА" (дата/время);
   • "КТО" (какой именно процесс);
   • "КАК" стартовал (в каких условиях и обстоятельствах);
   • "ЧТО" сделано;
   • "ЧЕМ" закончилась работа;
   • "ГДЕ" (и что) взято;
   • "КУДА" (и что) помещено.
5. Протоколы "ФУНКЦИЙ" включаются "as is" в протоколы вызвавших их "ЗАДАЧ";
6. Пускач службы должен вести собственный протокол вне указанного "общего" места. В этом протоколе должны регистрироваться все события (в границах ответственности пускача), влияющие на функционирование службы, как и все действия самого пускача в связи. Иными словами, протоколы пускача должны обеспечивать альтернативный вариант учёта/фиксации происходящего в службе;
7. Если технолог вынужден (по уважительным обстоятельствам) вмешаться в обработку данных и это вмешательство не обеспечено надлежащим автоматическим протоколированием, то [этот] технолог обязан вручную отобразить своё вмешательство надлежащим образом. В соответствующем протоколе процесса или рядом;
8. Для обеспечения служебных расследований (касаемо деятельности службы) должно быть организовано хранение (на срок не менее срока юридической ответственности):
   • всех протоколов;
   • актуальных (на момент) конфигов, скриптов и т.п.;
   • полученных/отправленных службой данных;
   • + если транзитные данные разделяются на "нужное" и "мусор/брак", то и этот "мусор/брак" должен также попадать на хранение.

NB. Иными словами, хранимое должно обеспечивать восстановление полной картины любого события/обстоятельства (в указанных временных границах).
+ должна быть обеспечена возможность предъявить (при надобности) любые поступившие и отправленные данные. Как [предъявить] и то, что служба рассмотрела как "мусор".
В т.ч. должна быть обеспечена возможность повторить любой цикл обслуживания данных, прошедших через службу (в оговоренном интервале прошлого), т.е. возможность эмуляции post factum имевшего место ранее быть.

5. Живучесть (устойчивость и надёжность).

1. Ни при каких обстоятельствах служба в целом, как и отдельные подсистемы/задачи в частности, не имеют права "тихо" (внезапно, полностью или частично) прекращать свою работу. Т.е. должны быть предусмотрены и обустроены надлежащие действия при:
   • полном отказе места размещения ("железо", электропитание, etc.);
   • локальном отказе какой-то подсистемы/задачи;
   • проблемах со стыками или у источников/получателей;
   • проблемах с собственно пересылаемыми данными.
2. Соответственно, контроль ситуации должен включать следующие мероприятия:
   • внешний (автоматический) контроль "живости" службы, например методом "пинг-понг";
   • внутренний контроль "успешности" [завершения] пускаемых процессов;
   • внутренний контроль наступления оговоренных событий в оговоренной время;
   • внутренний контроль текущей достаточности наличного дискового пространства (как и прочих обязательных ресурсов, при целесообразности и по возможности);
   • внешний эпизодический персональный контроль "рисунка" работы службы;
   • регулярное зеркалирование (всей службы) или backup (критически важного).
3. Служба должна быть оснащена развитой системой оповещения (участников и "сочувствующих") о значимых событиях в службе (и в "окрестностях"):
   • аварийная сигнализация;
   • нарушения в штатном обслуживании данных (брак, неполучение или не отправка данных и т.п.);
   • оперативная отчётность о значимых событиях (касаемо данных);
   • оперативные рабочие результаты/сводки (для заинтересованных);
4. Служба должна быть обеспечена достаточным дисковым пространством (места размещения) для исключения исчерпания оного пространства при непрерывной долговременной работе без вмешательства технолога;
5. Служба и технолог должны быть обеспечены средствами удалённого оперативного вмешательства технолога в работу службы;
6. Обслуживание поступающих данных должно включать обязательные механизмы контроля целостности и корректности этих данных. Причём, таких механизмов может быть сразу несколько. Например:
   • целостность архивов (+соответствие пароля, если используется);
   • отсутствие в поступившем постороннего;
   • отсутствие выпадений в потоках данных;
   • корректность именования файлов/архивов;
   • соответствие поступившего заявленному формату;
   • попадание значений данных в заданные границы.
   NB. Не допускается приём в обслуживание потоков данных совсем без таких механизмов.

6. Ремонтопригодность.

1. Все обслуживаемые данные (в обязательном порядке) буферизируются (обеспечивается их полноценное временное хранение);
2. Частые типовые аварии должны (по возможности) устраняться службой автоматически (самостоятельно);
3. Редкие типовые аварии должны устраняться минимальным вмешательством технолога;
4. Протоколирование работы подсистем должно включать (по возможности) понятное описание "когда/почему" и что именно "упало";
5. Если указанное в предыдущей позиции невозможно, протокол должен ясно указывать на последнюю (перед аварией) запущенную команду (со всеми фактическими параметрами);
6. Если "обломки" (от аварии) не могут помочь при локализации/устранении проблемы, они должны "убираться автоматически";
7. Технолог должен быть обеспечен возможностью легко приостанавливать (на какое-то время) те или иные задачи службы без вмешательства в рабочие конфиги оной;
8. Технолог должен быть обеспечен (по возможности) средствами запуска ("на бис") тех или иных подсистем без вмешательства в упомянутые конфиги;
9. По возможности, желательно развернуть отдельное (пространственно) полнофункциональное зеркало службы с целями:
   • быстрое восстановление работы службы на зеркале при критическом отказе штатного места размещения (например отказ винта);
   • доступ к нужным сведениям при служебных расследованиях, не трогая саму работающую службу.

7. Самодостаточность (автаркия, в т.ч. и самообслуживание).

1. Всё, потребное для работы службы должно находиться в границах оной;
2. Допускается (при обоснованной необходимости) использовать возможности/ресурсы места размещения (рассматриваемой службы);
3. Использование внешних (по отношению к месту размещения) средств допускается только в плоскости средств организации/обеспечения стыков службы;
4. Не допускается бесконтрольный рост "продуктов жизнедеятельности" службы (протоколы, сохранённые копии транзитных данных и т.п.);
5. Соответственно, такие "продукты" должны регулярно автоматически обслуживаться, т.е. архивироваться и сдвигаться в архивы (сначала в текущие, затем - на долговременное хранение).

8. Бюджетность (лирическая констатация).

1. Потребные/использованные в службе утилиты/решения, - это, или "самоделки", или Freeware (очевидная натяжка);
2. В начале пути у меня был в распоряжении "No name" Desktop IBM AT под WinNT4. Сейчас... производственные экземпляры службы работают на серьёзном промышленном "железе" под W2k8 (требования времени;), но всё работало (бы без нареканий;) и в условиях попроще - почти все, имевшие место быть, критические отказы службы - из-за "железа" + грубые ошибки уполномоченного персонала, увы...
3. Некоторые следствия "бюджетности":
   • нет GUI - серверным процессам он ненужен, технолог использует FAR;
   • нет некоторых, сравнительно важных механизмов (например, отсутствует надлежащий автоматический контроль версий). Соответственно, такие механизмы эмулируются (технологом вручную);
   • нет смысла обустраивать автоматическое восстановление (recovery) для редких типовых аварий.
4. В целом, предложенная концепция, - это в первую очередь "решение для бедных" (минимально возможный потребный объём начальных вложений и последующих расходов на эксплуатацию отдельного экземпляра службы).

.