Данный пост Ричарда Лехейна (на фото) был опубликован 20 ноября 2018 года на блоге британской Коалиции по электронной сохранности (Digital Preservation Coalition, DPC) среди материалов, приуроченных к Международному дню электронной сохранности, который отмечался 29 ноября 2018 года (см. https://dpconline.org/blog/idpd ).
Мой комментарий: первая половина поста – лишь «зачин», будьте терпеливы! :)
Когда у меня бывает свободное время, я работаю над программой «Зигфрид» (Siegfried) - инструментом идентификации файловых форматов наподобие известных программ DROID и Fido. Я вожусь с ним уже более пяти лет. (см. перевод заметки Ричарда за 2015 год, http://rusrim.blogspot.com/2015/04/siegfried.html об инструменте идентификации файловых форматов на основе реестра форматов PRONOM – Н.Х. ) Автоматизация работы играла для меня решающую роль в плане продолжения работы над проектом – без неё я просто не смог бы сделать всё то, что что необходимо было сделать помимо совершенствования самого инструмента. К настоящему времени я автоматизировал:
- Тестирование,
- Создание и публикация релизов,
- Обновление подписей,
- Профилирование кодов, и
- Бенчмаркинг.
Первым я автоматизировал набор тестов для «Зигфрида». Этот пакет тестов включает в себя базовый набор Росса Спенсера (Ross Spencer) и запускается каждый раз, когда новый код отправляется на сайт Github через сервис Travis-CI (облачный сервис для разработки и тестирования программного обеспечения, базирующегося на сайте Github – Н.Х.). Эти тесты в полной мере окупаются при каждом новом выпуске инструмента PRONOM, потому что они всеохватывающие, в том числе покрывающие широкий спектр пограничных случаев для файловых сигнатур из PRONOM. За эти годы благодаря данному базовому набору тестов была выявлена масса ошибок в «Зигфриде» (а также был подготовлен ряд отчётов об ошибках, которые были направлены разработчику PRONOM – Национальным Архивам Великобритании).
Travis-CI также отвечает за сборку пакетов Debian (операционная система на основе открытого исходного кода – Н.Х.). Это была следующий крупный этап работы, который я автоматизировал. Любое изменение мастер-кода запускает сборку исполняемого кода для Debian на Travis-CI и сборку для Windows на Appveyor. Затем исполняемые файлы автоматически публикуются на Bintray и обратно на Github. Иными словами, как только я прихожу к выводу, что код готов для выпуска нового релиза, я могу просто направить этот код в хранилище, и новые версии программы под Linux и Windows будут автоматически созданы и опубликованы.
В прошлом году я написал «сборочный» скрипт, который исполняется в Travis-CI. Он берёт базу данных PRONOM после очередного её обновления и формирует свежие версии набора базовых тестов. Это не только экономит мое время, но и означает, что мне не нужны инсталлировать на моих локальных компьютерах для разработки все зависимости Java и Python для базового набора тестов.
Самая недавняя автоматизация, которую я добавил в июле этого года, является, вероятно, самой крупной и сложной из всех. Это непрерывно работающий индивидуально-настроенный сервис бенчмаркинга, который выполняет крупномасштабные тесты с использованием программы Siegfried (а также программ DROID и Fido) при внесении изменений в репозиторий кода на Github. Этот сервис также выполняет автоматическое профилирование кода. Я не буду здесь рассказывать подробности, но, если Вам это интересно, прочитайте пост здесь: https://www.itforarchivists.com/post/benchmarks/ .
Итак, теперь, когда я дал понять, что являюсь фанатом автоматизации (и бесстыдно слегка порекламировал своего «Зигфрида»), давайте поговорим об общих вопросах и обсудим автоматизацию в области электронной сохранности.
Автоматизация часто продвигается как необходимый элемент работы по обеспечению электронной сохранности из-за проблемы масштаба: идея заключается в том, что, поскольку сегодня создается столь много электронного контента, то если мы не сможем автоматизировать нашу работу, мы утонем в этом «электронно-цифровом потопе». Хотя в этом аргументе определенно есть доля истины, я хотел бы предостеречь, что автоматизация не следует применять вслепую или же в качестве универсального решения, подходящего во всех случаях жизни.
Преждевременная оптимизация - корень всех зол
В следующий раз, когда Вы услышите, как кто-то (или Вы сами) говорит: «это всё здорово, но это не будет масштабироваться», стоит задуматься, что именно понимается под «масштабом», «масштабированием». У всех у нас есть проблемы с масштабированием, но они не обязательно одинаковы. Размышляя о масштабе и электронной сохранности, следует принято во внимание ряд аспектов:
- масштаб нашей собственной деятельности (обычно маленький)
- размер нашей потенциальной клиентской базы или юрисдикции (часто большой)
- размер нашей фактической клиентской базы или той части нашей юрисдикции, которая желает сотрудничать с нами (часто небольшой)
- количество запросов на передачу материалов на хранение (может быть разным)
- размер пакетов передаваемых данных (может быть разным)
- сложность этих процессов передачи (может быть разной).
Я недавно ушёл из Государственного архива австралийского штата Новый Южный Уэльс, где был частью команды проекта «электронного архива». Несколько лет назад, в начале этого проекта, мы потратили немало времени на проектирование (и отчасти создание) workflow-механизма и стандартного портала ведомства с тем, чтобы мы могли справиться с большими объемами передаваемых ведомствами материалов, которые, как мы ожидали, скоро к нам поступят. В конечном итоге мы переключились на гораздо более индивидуальную модель (с использованием шаблонов документов для взаимодействия с ведомствами и скриптов для выполнений значительной части обработки), которая оказалась лучше подходящей для того типа масштабирования, с которым мы столкнулись: небольшое число сложных пакетов передаваемых материалов, объёмы которых сильно варьировались.
В сообществе специалистов по машинному обучению часто говорят: «Бесплатного обеда не бывает». Это означает, что не существует такого универсального алгоритма, что подходил бы для всех областей, и Вам нужно экспериментировать с разными алгоритмами, чтобы определить правильный подход к Вашей конкретной проблеме. То же самое справедливо в отношении электронной сохранности. Выберите правильный набор инструментов для условий, в котором Вы работаете, и осознайте, что при использовании любого из инструментов есть определённые компромиссы. Это связано с тем, что автоматизация чего-либо включает в себя установление соответствующих ограничений. Прекрасным примером может служить нормализация формата: если вы готовы заплатить возможную «цену» в плане верности представления, то установление ограничения, предусматривающего поддержку ограниченного числа форматов «для длительного хранения», возможно, окажется оправданным (а может быть, и нет).
Автоматизация важна, но осуществлять её следует тактически (как я сделал это для «Зигфрида»): начните с малого и «вручную», выясните, в чём заключаются Ваши потребности в плане масштабировании, и поймите, на какие компромиссы Вы готовы пойти.
Хорошего Вам Международного дня электронной сохранности. И попробуйте использовать «Зигфрида»!
Ричард Лехейн (Richard Lehane)
Мой комментарий: Знаете, о чём я подумала, переводя эту заметку? Раз за разом Росархив и ВНИИДАД пытаются навязать стране, давно уже живущей в условиях многоукладности, быстрых изменений технологий, неоднородности и изменчивости законодательства, большой разницы в располагаемых организациями ресурсах, - некие единые, причем написанные на уровне пошаговых инструкций правила работы с документами «на все случаи жизни», а теперь ещё и правила обеспечения долговременной сохранности электронных документов… Да и некоторые другие ведомства тоже хороши, снова и снова «выкатывают» идеи осчастливить все государственные и/или муниципальные органы страны какой-нибудь единой СЭД. И если австралийцы разок наступили на грабли и поняли, что так делать не стоит, то в нашей стране, чтобы понять тупиковость изначально выбранного направления (и, самое главное, признать ошибку!), надо в кровь лоб расшибить…
Источник: блог Коалиции по электронной сохранности
https://dpconline.org/blog/idpd/automation-in-digital-preservation
Комментариев нет:
Отправить комментарий