На днях, в обсуждении статьи, посвящённой проблеме перспектив отрасли «информационных технологий» в условиях кризиса, в ответ на критику был высказан аргумент, замечательный бездной не-понимания предметной области:
Я работаю в государственной системе много лет. И все работает как часы.
Миром правят не талантливые и амбициозные одиночки, а дисциплина, исполнительность и организация.
© Gringoire
Далее, перед тем как переходить к предмету статьи, полагаю необходимым сделать некоторые предварительные замечания:
Во-первых: рассматриваемая отрасль, сама по себе, не создаёт ништяков, знаком которых являются деньги в традиционном смысле понятия.
Во-вторых: проблемная тенденция свойственна далеко не только и может быть даже не столько государственным органам. См. воплощение коллективного безсознательного с ибаша (#15518):
> дык это главный прицып интырпрайза — просрать миллиарды и бояться чихнуть рядом, потомушо никто не знает, как это потом чинить
И в-третьих: относительно перспектив тестирования сколько-нибудь сложной (реальной) системы категорически рекомендую руководство Дж. Фокса («Программное обеспечение и его разработка.»).
Имел возможность наблюдать за поведением профессионала, у которого тоже «всё работало», при разборе инцидента. Пытался переводить стрелки на нас. Был неприятно удивлён наличием не только достаточно адекватно настроенной подсистемы журналирования, но и наличием навыка анализа сообщений (что не всегда тривиально).
Иллюстрацией данной тенденции полагаю ответ камрада Корректор о необходимых предпосылках карьерного роста:
Лояльность, усидчивость, молчаливая покорность, абсолютная исполнительность и отсутствие карьерных амбиций.
Тейлоризм. :))) Ну да, ну да, а потом выясняем, что действиетльно сложные технологии и системы организации для имеющейся организации недостижимы. Боле того, со временем существования организации она медленно, но верно и неизбежно, деградирует. :)))
Вы не один такой руководитель в своих убеждениях. ;)
А теперь можно переходить к предмету статьи в виде впечатлений от первого знакомства с Единой системой межведомственного электронного взаимодействия (СМЭВ).
Страница портала, используемого для распространения документации и дистрибутивов ПО:
Обратите внимание на то, как не смотря на декларируемую кросс-платформенность выдерживается традиционный для самой распространённой ОС стиль, являющийся первопричиной необходимости выплаты дани распространителям вредоносного («антивирусного») ПО.
Если скачать дистрибутив для «Linux», то можно увидеть традиционный для мира Windows «установщик» и сделать вывод о том, что авторы благополучно разминулись с основополагающим принципом компоновки дистрибутивов GNU/Linux (в нормальной логике которых использование данного подхода — однозначный источник проблем и наглядная иллюстрация злободневной проблемы идеальной доказуемости):
Если Вы ставите программы или драйвера руками в обход [И-23: приказчика пакетов дистрибутива], например, так:
./configure
make
make installили используете установщики производителя (nVidia, AMD/ATi и т.п.), то не надо просить помощи на форуме или писать в [И-23: убрал имя собственное ибо справедливо для любого дистрибутива, хотя тырпрайс-вендоры вынужденно пытаются рыпаться] Bugzilla. Вы и только Вы сломали свою систему. Здесь Вам, как говорится, не тут, и тем более не Microsoft® Windows™.
Идём дальше в направлении инструкции по установке, не забывая оценивать практику распространения документов в редактируемых форматах проприетарного текстового процессора (который год на дворе наблюдаются попытки импортозамещения?):
И видим родную жабу. Ту самую, про которую справедливо говорится:
I had a problem so I thought I would use Java. Now I have ProblemFactory.
Прекраснее только предложение скачать устаревшие версии зависимостей (для commons-logging актуальная версия 1.2 датируется июлем 2014 года, прописанная — маем шестого! для xmlsec актуальная версия — 2.1.5 от марта сего года) с недействительного адреса (в руководстве администратора выпущенной 23 апреля сего года версии 3.1.8 адреса (но только адреса!) исправили). Естественно, без никаких хотя бы намёков на необходимость верификации скачанного. Как основного ПО, так и зависимостей.
У разработчиков проприетарных зависимостей (КриптоПро) дела обстоят несколько лучше. Но ненамного.
Ими предлагается два варианта контрольных сумм. MD5 и ГОСТ. Причём, естественно, описание проверки контрольных сумм по алгоритму ГОСТ не предполагает существования ОС отличных от Microsoft® Windows™.
В остальном было бы очень интересно услышать ответы на пару простых и конкретных вопросов:
1. Когда (и почему) в основных дистрибутивах отказались от использования алгоритма MD5:
2. Почему в стандартный формат манифеста помимо контрольных сумм входит размер файла?
А теперь, для контраста и наглядности процитирую фрагмент документации СПО, описывающий правильный процесс скачивания ПО. Цитируется по русскому переводу Gentoo Handbook AMD64 (достаточно давно документация переведена в wiki-формат, то есть тождество цитаты описанию по ссылке не гарантируется):
Проверка скачанных файлов
Заметка
Это необязательный шаг и не требуется для установки Gentoo Linux. Однако его рекомендуется выполнить, чтобы удостовериться, что скачанный файл не поврежден и действительно был предоставлен командой Gentoo Infrastructure.
При наличии файлов .DIGESTS и .DIGESTS.asc можно проверить целостность файла ISO с использованием различных программ. Данная проверка обычно делается в два шага:
1. Сначала проверяется криптографическая подпись, чтобы удостовериться, что данный установочный файл предоставлен командой Gentoo Release Engineering
2. Если криптографическая подпись верна, то проверяется контрольная сумма, чтобы удостовериться, что сам скачанный файл не поврежден
[И-23: описание проверки контрольных сумм в Windows ((!) сравните с КриптоПро) и фрюниксах опускаю.]
Если контрольные суммы совпадают, то файл не поврежден и можно продолжать установку.
[И-23: сравните с описанием процедуры удовлетворения зависимостей из инструкции по установке СМЭВ.]
Сюда же отмечу периодически случавшиеся в моей практике эпизоды подмены выложенного дистрибутива разработчиком.
Вот так «всё работает»©. До тех пор, пока в пространстве-Времени не совпадёт необходимость разбора инцидента с технической возможностью.
Наглядная иллюстрация следствий делегирования задачи разработки документации специально отобранным профессионалам.
Или, возвращаясь к примеру обсуждения:
И напоследок анекдот в тему: