Катастрофа ИТ в госсекторе⁠⁠

По мотивам поста про плохую работу ЕГР ЗАГС (https://pikabu.ru/story/_6217894).

Ремарка - в 2005-2007 годах я отвечал за информационный обмен между налоговой, полицией (ПВС/ГИБДД), БТИ, Росимуществом, ЗАГСом, ФССП. Помимо этого работал с информационными системами  Роспотребнадзора, ГО ЧС, местного самоуправления, Почты России, ЖКХ, ЦЗН.

Из указанных систем самая простая информационная система у органов ЗАГСа, а самая сложная у налоговой, во многих органах по тем или иным причинам информационные системы фактически не используются (или создаётся иллюзия использования).

С информационными системами в бюджетном секторе сейчас ситуация катастрофическая и это проблема не только органов ЗАГСа, это всеобщая проблема. С государственными ИС я работаю на протяжении 13,5 лет, поэтому своеобразная подборка причин и следствий этой катастрофы. Причин и следствий по настоящему очень много, поэтому "топ-10".

Сразу оговорюсь - я не буду топить за конкретную программу/решение/технологию. Каждому решению есть своё время и место.

1. Откаты. Ценники практически на все государственные системы заоблачные, так что "подрядчик наварился, а заказчик ничего не получил"... Ну думаю, что это будет что-то из области фантастики и поверить в такие расклады может только школьник (и то начальных классов). Тема избитая, останавливаться не будем.

2. Безграмотность административного персонала заказчиков. Технические задания на информационные системы должны (и по закону даже обязаны) писать заказчики. По факту ТЗ пишут "свои" подрядчики и естественно под себя. Это связано с тем, что специалистов, достаточно квалифицированных для составления ТЗ, у государственных/региональных/муниципальных заказчиков практически нет. В итоге системы собираются по принципу "сделать по минимуму и разгрузить склады нахрен не нужного барахла". Как я это понял? Если проанализировать ТЗ, то видна их несбалансированность. Техническое решение информационной системы эффективно только тогда, когда оно сбалансировано. Когда отдельные элементы системы работают "под предел" или вообще перегружены, а другие элементы работают на единицы процентов, то очевидно что система плохо сбалансирована и "простаивающие" элементы можно и нужно заменить на более дешевые аналоги. Присматриваемся и понимаем, что оборудование работающее на доли процента - это устаревшие  и дорогие решения. Коммерческим организациям это оборудование уже не интересно в принципе (т.к. есть более новое и дешевое), а бюджету можно впарить и притом втридорога. Ключевые параметры оборудования и программного обеспечения заказчики не знают (и знать не хотят), порядки цифр, технологии и т.п. вообще для заказчиков абстрактные вещи.

3. Безграмотность пользователей. Тут можно только всплакнуть. Меня уже очень много лет интересует вопрос (моя версия в конце абзаца) - как можно пользоваться интерфейсом социальной сети и тупить в более простых? На мой взгляд для обычного бюджетного пользователя компьютер - это просто некоторая шайтан-машина к которой боятся подойти.

4. Безграмотность исполнителей создающих ИС. Это, кстати, вообще феерично. Любой специалист знает, что задачу можно решить разными путями. Есть более эффективные, есть менее эффективные, естественно есть "через жопу". Так вот ГОС ИС это обычно "через жопу". Для "непосвящённых" объясню просто - есть некоторые правила построения ИС, естественно что правила - это не фиксированные законы и при определённых обстоятельствах правила нужно нарушать, но вот отдельные моменты проектов ИС... Это реальный сказочный звиздец. Системы которые по всем канонам и здравому смыслу должны быть централизованными делают распределёнными и наоборот. Системы используют приёмы которые вообще в голову придти не должны. Например, печально знакомая бюджетникам "Криста" имеет несколько интерфейсов работы с шаблонами, умудряется терять свои библиотеки (лежащие в папке программы), делает полную синхронизацию вместо отправки изменённых данных, интерфейс выбора, логика и формы в одном файле... Уже 9 лет я пытаюсь понять что нужно курить, чтобы это написать. Для тех кто "не в теме" объясню на доступных аналогах. Представьте, что у вас есть:

- отдельный Word для файлов начинающихся на А, Б и т.д.;

- что периодически приходится вынимать и вставлять жесткие диски для запуска ОС;

- для замены 1 буквы в тексте Вас заставляют перепечатывать на компьютере всю страницу;

- что в магазине продаётся мясорубка с куском мяса, причём сделано так, что эта мясорубка может прокрутить только вставленный кусок мяса.

Бред? Бред. И такой бред повсюду. В итоге многими системами сложнее пользоваться, чем просто в офисе формочки заполнять и в Excel считать (хотя должно быть наоборот). Причём это не ошибки - это просто реальный чемпионат идиотизма. Такое чувство, что подобные ИС пишут студенты 2-3 курса для получения допуска к зачётам по прогулам.

Для тех кто начнёт говорить про "специфику" - во-первых это далеко не уникальные продукты и у подобных ИС есть много аналогов (по сути это всё вариации ERP-систем, коих овердохрена) в т.ч. с открытым кодом, во-вторых подобные "особенности" не могут быть заложенными со стороны заказчика принципиально - они даже не подозревают об этих особенностях разработки ПО, в-третьих это нарушение правил подтвердивших свою эффективность в течении десятилетий и которые пишут в каждом учебники программирования.

Недавно попросили глянуть новую программу, разработка 2018 года, служит для заполнения определённой формы отчётности. Данные хранятся в FoxPro. Кем нужно быть, чтобы для хранения ОДНОГО документа (с NoSQL данными по сути) и использовать для этого БД выпущенную в 1988 году? Зачем там вообще БД?

Оцените уровень маразма (помним, что программа разработана в 2018 году): разработчик этой программы берёт NoSQL данные (для хранения которых все уже много лет XML/JSON используют), создаёт под неё (естественно избыточную, причём это принципиально не обходится) реляционную модель данных, потом берёт эти данные загоняет в древнюю базу данных, потом видать понимает, что хрень спорол и выгружает в собственный (упрощённый) аналог JSON. У меня на это нет слов - конвертируем данные в заведомо неподходящий формат, затем конвертируем данные обратно. Данные - числовые т.е. реляционная модель данных тут вообще неприменима в принципе.

Ну и ещё маразмы, коротко:

- Локальная структура проектируется как информационная система регионального уровня. Данные, которые актуальны непосредственно "на месте", собираются "на месте", потом передаются "в регион", потом возвращаются "на место". Второй режим - чисто локальная работа. Вот нахрена гонять данные в 2 противоположных направления? На вопрос "а нахрена собственно" идут пояснения достойные лучших наркоманов мира. Аналогичная система, основной задачей которой является координация регионального уровня, проектируется локальной. Так же маразмы идут, когда локальная система аппаратно проектируется как "клиент-серверная" (сервер с виртуальной машиной в которой установлена обычная ОС с обычным софтом), в итоге этот маразм просто забросили.

- Шаблонное решение тиражируемое в десятки мест. То есть одно и то же серверное решение применяется к системе со 500 узлами и с 10.

- Развёртывается доменная структура и Home версия ОС на рабочих станциях.

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

- Под 4-10 каналов связи с максимальным трафиком 10 Мбит/с используются Cisco 2960 (одна из топовых конфигураций), а под 2-х канальную систему с проектной нагрузкой 53 Мбит/с ставят бюджетный Dlink.

- В качестве маршрутизатора (чистый NAT, даже без файервола) используется Windows Server

- "Упрощённый" браузер "для более быстрой работы" (нет JavaScript, чисто GET/POST запросы) установщик весит 340 Мб, страница быстро жрёт ОЗУ, за 20 минут отжирается 1,4 Гб ОЗУ. Через час работы плюнули и открыли страницу через обычный.

5. Устаревшая программная и научная база. Я полагаю ответственные за разработку ИС сотрудники во-первых пенсионного или предпенсионного возраста, во-вторых работают в ВУЗах. Иначе я не могу объяснить почему современные системы используют популярные в образовательной среде и малоэффективные в современном продакшене анахронизмы, которые были актуальные 10-30 лет назад. Я не говорю, что эти решения "морально устарели", где-то мне это даже импонирует. Но это не решения сегодняшнего дня, сегодня для использования этих решений нет никаких объективных причин. DBF/FoxPro/Internet Explorer и прочие старички. Радует, что отдельные элементы стали актуализироваться, но пока их число очень незначительно.

Это особенно обидно, потому что:

Во-первых качество разработки программного обеспечения в России достаточно высокое, студенты и ИТ компании очень достойно смотрятся на мировом фоне.

Во-вторых отдельные программы требуют устаревшее оборудование и системное программное обеспечение. Последний реально вопиющий случай (своеобразный рекорд) - это в 2011 году искать железо под Windows 95 т.к. железка (лабораторный прибор за 700к) подключается через COM-порт и имеет драйвера исключительно под 95.

6. Отсутствие стимулов к развитию информационных технологий. Технологии в госсектор внедряются "для галочки", не смотря на положительный эффект заинтересованности во внедрении ни у кого нет. Пользователи (на всех должностях) не хотят учиться, многие боятся (совершенно справедливо, кстати) что программа легко может заменить большую часть чиновников.

7. Низкие зарплаты технического персонала. Информационные системы, это всё-таки достаточно сложные системы и для обслуживания требуется уровень специалиста несколько выше обычного эникея. Зарплаты в бюджете очень печальные, в лучшем случае 25-30 % от рыночных (специалистов с аналогичной нагрузкой и квалификацией). В итоге специалисты уходят из бюджета, а системы без должного обслуживания достаточно быстро разваливаются или работают на небольшую долю реальных возможностей.

8. Самодурство чиновников. Знания об информационных технологиях чиновники получают судя по всему из фильмов и рекламы. Очень напрягает, что невозможность воспроизвести киношный трюк воспринимается как признак слабой квалификации специалиста. Люди, не имеющие не то что образования в сфере ИТ, но даже любого технического, ни разу не работавшие в организациях и структурах связанных с ИТ выдают "задания". При этом "задания" очень сильно напоминают наборы логически не связанных друг с другом терминов. Предлагаешь "А давайте HelpDesk внедрим?", в ответ "А зачем?"... Через определённое время "Внедряем систему централизованного отображения информации!", на вопрос "А нахрена?" затыкают. Отыгрались, закупились... При ширине видеостены 4 м максимально можно обеспечить расстояние до пользователя порядка 1,5 - 2 м. В итоге использовать систему невозможно (посмотрите на монитор с расстояния 1/2 ширины и поймёте почему)... Оператору "тяжелой" информсистемы ставим "труп", зато у какой-нибудь фифы вполне приличный игровой, в итоге человек ждёт пока комп оттормозится, а мощный игровой комп используется для фермы в ОК. На VPN по отправке отчётов (200 Мб/год) 10 Мбит/с, на электронную почту секретаря канал 8 Мбит/с... На отдел из 8 человек работа которых напрямую связана с "Интернетом" 1 Мбит/с и то еле отстояли, хотели 521 кбит/с... Важные файлы на компьютере 2006 года, без бэкапов? "А зачем они нужны?". Бэкапы. И 10000 на простенький СХД для бэкапов не дадим. Ну и что, что технике 5-12 лет, до этого работала и ещё поработает (это кстати краткий пересказ реального диалога). И т.д. и т.п.

9. Кумовство. Идиотское заблуждение, что работа админа не сложнее работы уборщицы приводят к тому, что на должности в ИТ подразделениях протаскивают "сыночков", "племянников" и т.п. Последствия немного предсказуемы... Например, несколько лет назад руководитель крупной региональной структуры уволил админа за то, что он подрабатывал фрилансом (имея зарплату 40% от средней по региону и около 25 % от зарплат на аналогичных должностях). ИТ-инфраструктура предприятия была очень сложной - в единую систему заведён "зоопарк" Windwos+Linux+FreeBSD, домен, IP-телефония... Короче много чего. Пригласили "своего" работника, но даже принимать не стали т.к. когда старый админ отдал листочек с паролями он задал вопрос "а куда их вводить?". Админ не знает куда вводить логины и пароли от админки сайта WordPress, SSH и т.п...

10. Подлог аппаратного обеспечения. Что это такое объясню на примере - супер-пупер блок "РогоКопыта" (опечатанный и опломбированный) при разборке (после неисправности вернули не опломбированным и без крепёжных болтов, корпус сам развалился) стоимостью 97 000 рублей оказался модифицированным нетбуком за 7000 рублей. Основной прикол в том, что на нём запущено единственное приложение, которое вполне может тянуть "малинка", или даже планшет зе 3000 рублей, или вообще софтверно (HTTP запрос раз в 20 секунд, при определённом флаге блок запускает звуковой сигнал).

Как с этим сражаться? Не знаю. Система устраивает всех участников - пилятся бюджеты, получаются откаты, бюджету впаривается старьё, софт почти бесплатный (т.к. его скорее всего пишут студенты за зачёты), операторы один хрен ничего не понимают.

Больше всего меня удивляет другое. Откуда такая сверхнаглость? Почему бы подобным "специалистам" просто не брать на субподряд адекватные фирмы? До нормальной балансировки бюджетов их пилить так или иначе будут, но хотя бы задачи будут решены на деле, а не словах.