Читаю совершенно феноменальный текст свежего 100 миллионного контракта [1] между ФГБУ РОСИНИВХЦ и ООО "ТЕКТУС.ИТ" на Создание сегментов государственной информационной системы Цифровая платформа "Водные данные" Федерального агентства водных ресурсов (ГИС ЦП Вода).
И не могу не поделиться мыслями о деградации ИТ интеграции. Мало того что ТЗ на 100 миллионный контракт всего на 22 страницы, так это ещё и не техническое задание, а технические требования.
В тексте контракта присутствуют формулировки вроде:
5.6. Создание API
Исполнителем должна быть обеспечена разработка API (не менее 10 методов) для вновь создаваемых модулей ЦП Вода.
По результатам оказания услуг модернизируется программный интерфейс для обеспечения внутреннего взаимодействия ЦП Вода, а также инструкция с описанием реализованных методов.
—
Обратите внимание, сами API методы не перечисляются, требования к ним не перечисляются, зачем они нужны не указано, дополнительные требования вроде авторизации не указаны. Исполнитель и заказчик тут настолько вольно могут трактовать этот пункт что можно сдать вообще что угодно.
Или вот
5.4.3. Создание блока «Наборы открытых данных» сегмента «Открытые данные»
Блок «Наборы открытых данных» создается на базе прототипа Цифровой платформы «Водные данные».
Исполнителю необходимо обеспечить размещение в разделе «Наборы открытых данных» не менее трех новых наборов с возможностью выгрузки (в том числе подписанных ЭП). В отношении новых наборов данных необходимо сформировать паспорта.
—
Обратите внимание, что заказчику вообще наплевать что будет опубликовано, хоть "набор данных" из одной строки, главное чтобы не менее трёх. А про возможность выгрузки их подписанными ЭП - это отдельный разговор.
А вот в продолжение про ЭП (электронную подпись)
5.4.2. Создание модуля «Верификация» сегмента «Открытые данные»
В рамках оказания услуг Исполнителю необходимо обеспечить возможность верификации выгружаемых данных из сегмента «Открытые данные» в формате pdf путем подписания ЭП ОГВ.
—
Ну, Вы меня поняли. Верифицированные открытые данные это теперь PDF файлы с электронной подписью органа власти.
Там ещё много всего, выглядящее крайне куцо для большого ИТ контракта. Я лично вчитывался в разделы про данные, насчёт других разделов надо читать другим специалистам.
Когда я был ближе к государству, я бы сказал что прочитав такое "ТЗ" я бы предположил скорую проверку этого контракта/системы в ФГБУ со стороны Счетной палаты/Генпрокуратуры и тд. Сейчас, находясь уже во внешнем контуре по отношению к госуправлению, я даже вполне допускаю что результат будет не так уж плох, но продолжаю удивляться госзаказчикам и поставщикам которые сами себе роют сами знаете что и закапывают себя сами знаете куда.
Ссылки:
[1] https://zakupki.gov.ru/epz/contract/contractCard/document-info.html?reestrNumber=1616305712422000006&contractInfoId=70636526
[2] https://rwec.ru/
[3] https://zakupki.gov.ru/44fz/filestore/public/1.0/download/rpec/file.html?uid=D539BBBD9AB6DD94E05334548D0A0844
#procurement #governmentit #opendata #data
И не могу не поделиться мыслями о деградации ИТ интеграции. Мало того что ТЗ на 100 миллионный контракт всего на 22 страницы, так это ещё и не техническое задание, а технические требования.
В тексте контракта присутствуют формулировки вроде:
5.6. Создание API
Исполнителем должна быть обеспечена разработка API (не менее 10 методов) для вновь создаваемых модулей ЦП Вода.
По результатам оказания услуг модернизируется программный интерфейс для обеспечения внутреннего взаимодействия ЦП Вода, а также инструкция с описанием реализованных методов.
—
Обратите внимание, сами API методы не перечисляются, требования к ним не перечисляются, зачем они нужны не указано, дополнительные требования вроде авторизации не указаны. Исполнитель и заказчик тут настолько вольно могут трактовать этот пункт что можно сдать вообще что угодно.
Или вот
5.4.3. Создание блока «Наборы открытых данных» сегмента «Открытые данные»
Блок «Наборы открытых данных» создается на базе прототипа Цифровой платформы «Водные данные».
Исполнителю необходимо обеспечить размещение в разделе «Наборы открытых данных» не менее трех новых наборов с возможностью выгрузки (в том числе подписанных ЭП). В отношении новых наборов данных необходимо сформировать паспорта.
—
Обратите внимание, что заказчику вообще наплевать что будет опубликовано, хоть "набор данных" из одной строки, главное чтобы не менее трёх. А про возможность выгрузки их подписанными ЭП - это отдельный разговор.
А вот в продолжение про ЭП (электронную подпись)
5.4.2. Создание модуля «Верификация» сегмента «Открытые данные»
В рамках оказания услуг Исполнителю необходимо обеспечить возможность верификации выгружаемых данных из сегмента «Открытые данные» в формате pdf путем подписания ЭП ОГВ.
—
Ну, Вы меня поняли. Верифицированные открытые данные это теперь PDF файлы с электронной подписью органа власти.
Там ещё много всего, выглядящее крайне куцо для большого ИТ контракта. Я лично вчитывался в разделы про данные, насчёт других разделов надо читать другим специалистам.
Когда я был ближе к государству, я бы сказал что прочитав такое "ТЗ" я бы предположил скорую проверку этого контракта/системы в ФГБУ со стороны Счетной палаты/Генпрокуратуры и тд. Сейчас, находясь уже во внешнем контуре по отношению к госуправлению, я даже вполне допускаю что результат будет не так уж плох, но продолжаю удивляться госзаказчикам и поставщикам которые сами себе роют сами знаете что и закапывают себя сами знаете куда.
Ссылки:
[1] https://zakupki.gov.ru/epz/contract/contractCard/document-info.html?reestrNumber=1616305712422000006&contractInfoId=70636526
[2] https://rwec.ru/
[3] https://zakupki.gov.ru/44fz/filestore/public/1.0/download/rpec/file.html?uid=D539BBBD9AB6DD94E05334548D0A0844
#procurement #governmentit #opendata #data
rwec.ru
Главная / ФГБУ РосИНИВХЦ
Introduction to MODX
О данных, веб-сайтах и том как с ними работают. Я рассказывал что веду архивацию госсайтов, в том числе самописными инструментами, которые архивируют данные из открытых API которые веб-краулеры не поддерживают. Такая утилита есть APIBackuper для сфокусированной архивации и ещё для 5 популярных CMS у которых такое общедоступное API есть по умолчанию. Некоторые владельцы сайтов это API по умолчанию сразу отключают, но у большинства оно доступно и через него можно скачивать весь тот же контент что есть на сайте, только быстрее, удобнее и автоматически.
Но бывают и вопиющие случаи. Не буду называть конкретный орган власти/госорганизацию, но у них на веб-сайт предусмотрена подписка на рассылки СМИ. Подписка реализована встроенными средствами CMS и, барабанная дробь, открытые интерфейсы этой CMS отдают данные о всех подписчиках. К счастью, их там не так много, чуть более 200 человек и данные там хоть и персональные, но не самые чувствительные, только email+ФИО+факт подписки, но картина показательная о том как организована работа с данными в госорганах.
В данном случае даже не знаю что лучше, написать им чтобы исправили, или забить на них и пусть сами разбираются с последствиями (там правда, ничего серьёзного нет, обычный контентный сайт).
Таких случаев много, много случаев публикации чувствительных данных, просто доступа к данным и тд. Госзаказчики чаще всего просто не знают на каких инструментах создана их инфраструктура и поэтому так много недокументированных API у госсайтов и государственных информационных систем. Это вопрос не только культуры работы с данными, но и обычной технологической культуры и полнейшее отсутствие централизованного аудита и мониторинга государственного технологического сектора.
#tech #government #governmentit #privacy #leaks
Но бывают и вопиющие случаи. Не буду называть конкретный орган власти/госорганизацию, но у них на веб-сайт предусмотрена подписка на рассылки СМИ. Подписка реализована встроенными средствами CMS и, барабанная дробь, открытые интерфейсы этой CMS отдают данные о всех подписчиках. К счастью, их там не так много, чуть более 200 человек и данные там хоть и персональные, но не самые чувствительные, только email+ФИО+факт подписки, но картина показательная о том как организована работа с данными в госорганах.
В данном случае даже не знаю что лучше, написать им чтобы исправили, или забить на них и пусть сами разбираются с последствиями (там правда, ничего серьёзного нет, обычный контентный сайт).
Таких случаев много, много случаев публикации чувствительных данных, просто доступа к данным и тд. Госзаказчики чаще всего просто не знают на каких инструментах создана их инфраструктура и поэтому так много недокументированных API у госсайтов и государственных информационных систем. Это вопрос не только культуры работы с данными, но и обычной технологической культуры и полнейшее отсутствие централизованного аудита и мониторинга государственного технологического сектора.
#tech #government #governmentit #privacy #leaks