Почему на «нашем» ПО нельзя делать ни Госуслуги, ни единый регистр граждан

Тема пандемии уже больше десяти недель не сходит со страниц СМИ и является основным предметом обсуждения почти всех людей, кого коснулось либо само заболевание, либо меры по борьбе с ним. Но мы бы хотели коснуться одного аспекта нашей повседневной жизни, который показывает, как информационные технологии влияют на неё. Это те платформы электронного государственного управления, что мы используем для получения государственных услуг, а наши дети — для дистанционного обучения. В первые дни режима самоизоляции школьники и их родители столкнулись с тем, что не смогли воспользоваться системами «Российская Электронная школа» и «Московская электронная школа» — их постоянно, как говорится, выбрасывало с сайта, страницы не открывались, работа с сервисом была фактически сорвана, пропало несколько учебных дней. А ведь речь идет об очень важной части жизни детей — получении образования, которое гарантировано Конституцией Российской Федерации. Мы также нередко наблюдаем неполадки на сайте Госуслуг, который функционирует уже несколько лет, и, казалось бы, за это время все ошибки должны быть исправлены. Но нет, пользователь время от времени не может записаться к врачу, записать ребенка в кружок, подать показания счетчиков и так далее. О неполадках в онлайн платформах, об их причинах и возможностях устранения мы беседуем с генеральным директором компании «Бизнесинтерсофт» (город Рязань), разработчиком платформы ODANT Роман Александровичем Перепёлкиным. * * * Роман Александрович, на ваш профессиональный взгляд, как разработчика цифровой платформы, принципиально отличающейся от тех программных продуктов, которые используются для портала Госуслуг и дистанционного обучения школьников, почему происходят сбои в работе их систем? Роман Перепёлкин: Сбои в работе систем, построенных на так называемых «современных информационных технологиях», неизбежны, так как если повнимательней присмотреться, то эти технологии окажутся не такими уж и современными. Работа любой информационный системы основана на хранилище — СУБД (системе управления базами данных). От того, насколько СУБД соответствует решаемым задачам, зависит работа этих систем, их надежность, масштабируемость, нагрузочная способность, безопасность и т.д. Западные корпорации и их специалисты прекрасно понимают эту специфику и умеют эффективно использовать особенности различных СУБД для своих систем. Например, в Facebook быстро сообразили, что ни одна из существующих СУБД не способна эффективно управлять информационной системой соцсети, и написали собственное ядро — Cassandra, что и позволило создать мощную, надежную соцсеть. И вообще, практически каждая крупная IT-корпорация создает собственные СУБД для своих целей (Google — Spanner, Microsoft — CosmosDB, Amazon — Aurora). Всего в мире есть около 400 различных СУБД (99% американские), которые различаются по типам и назначению. Несмотря на такое разнообразие технологий, 99% всех систем в России строится на основе так называемых реляционных СУБД (Oracle, MSSQL, PostrgeSQL и т.п.), практически полностью игнорируя более современные и подходящие для этих целей платформы. Причина поломок подобных систем вполне объяснима и закономерна. Попробую объяснить. Как правило, все крупные системы имеют три основных блока: СУБД — уже обсудили выше (по аналогии с человеком — мозг). Бэкенд (Baсkend) — объектное логистическое процессное ядро, так называемый сервер приложений. Именно здесь происходит основная работа, выполняются процессы и различные действия, производятся проверки, расчеты и т.д. (по аналогии с человеком — руки и ноги). Фронтенд (Frontend) — сервер визуализации на котором создаются пользовательские интерфейсы, те самые приложения или сайты, с которыми работает конечный пользователь. Бэкенд оперирует прикладными информационными сущностями, как правило, реализованными в объектном виде (справочники, документы и т.п.). Для хранения данных этих информационных сущностей и используется СУБД, и вот тут как раз возникает первая проблема — так называемое ORM-преобразование (ObjectRelativeMapping). Дело в том, что реляционная модель хранит данные в связанных таблицах, и для размещения объектных сущностей не предназначена. В результате, сначала, надо построить адекватную реляционную модель, а потом, при каждом обращении — конвертировать данные в объекты, а при каждой записи — наоборот — раскладывать объект по таблицам. Все бы ничего, да только при построении модели связи может возникнуть критическая ошибка, которая приведет к полной неработоспособности (и это происходит почти каждый раз, при очередном обновлении системы). К тому же, процесс сборки/разборки данных требует до 95% серверных ресурсов, которые тратятся на поддержание работоспособности, вместо полезной работы. Кстати, можно заметить, что несмотря на то, что в соцсетях постоянно находится большое количество пользователей, там практически не бывает тормозов, в то время, как при массовом обращении пользователей к информационным ресурсам (например, Госуслугам) возникают «заторы» — заметное замедление работы, а иногда и полное игнорирование запросов. Это опять же, связано с технологическими особенностями реляционных СУБД. Дело в том, что для обеспечения целостности связей, такие системы выстраивают запросы в транзакционные очереди, и при каждом изменении производят перепроверку связей. Даже если Бэкенд написан идеально и обеспечивает максимальную пропускную способность запросов к базе, сама база становится «бутылочным горлышком», пропускающим по одному запросу за раз. В объектных же системах нет необходимости контролировать целостность связей, так как объекты по своей природе изначально являются целостными. Решение простое и очевидное — отказаться от реляционного хранения данных и хранить информацию в естественном для неё объектном виде. Помимо технологических проблем, сильное влияние оказывает информационная архитектура системы. В большинстве случаев некая архитектура присутствует только на бумаге, а внутри систем царит полный хаос. Из-за отсутствия внятной архитектуры, большинство систем полностью построены на «костылях». Такие системы быстро ломаются и практически не ремонтируются. С другой стороны, этому способствует сама система госзакупок, где главное — цена и сроки. Не до архитектуры. Тем не менее, существует абсолютно универсальный архитектурный подход к идеальному построению абсолютно любой информационной системы, на основе единого журнала операций, реализованного на принципе двойной записи (наподобие бухгалтерской). Наличие единой архитектуры способно стать настоящим драйвером развития информационных технологий, так как оно открывает возможности компонентного построения систем из автономных совместимых модулей, производимых различными разработчиками. Часто у людей возникают опасения по поводу сохранности их персональных данных, которые хранятся и обрабатываются на платформе Госуслуг. Граждане подозревают, что персональные данные могут быть украдены и использованы в коммерческих целях или злоумышленниками. Насколько обоснованы их опасения? Роман Перепёлкин:Опасения эти не напрасны, и одна из причин низкого уровня защиты — опять же реляционные СУБД. Несмотря на то, что в каждой СУБД уже есть собственная система безопасности, как правило, она не используется, так как реализуется на уровне Бэкенда (а иногда и Фронтенда), а СУБД подключается к системе с полными административными правами. Это опять же связано с различиями моделей при работе и хранении — невозможно правильно установить права доступа к данным таблицах так, чтобы они соответствовали логистике процессов, поэтому система безопасности пишется с нуля, для обслуживания именно объектной модели. По сути, Бэкенд обладает правами администратора при работе с СУБД. И даже, если удалось собрать крутую команду безопасников и сделать идеальный (по безопасности) Бэкэнд (что уже вызывает сомнения), вся система остается уязвимой на уровне СУБД через так называемые SQL инъекции — специальные запросы, нацеленные на взлом системы. По данным компании PositiveTechnologies: 83% сайтов и web-приложений содержат критические уязвимости; 78% уязвимостей относятся к средней степени риска; вероятность автоматизированного заражения web-приложения вредоносным кодом составляет 15−20%. Вы же не будете пользоваться автомобилем, у которого вероятность аварии со смертельным исходом — 83%, но в информационных технологиях это абсолютно никого не смущает, главное, при сдаче проекта предоставить сертификат государственного образца, что всё безопасно. Часто, в качестве главной причины взлома систем называют человеческий фактор, потому что администратор системы всегда имеет полный доступ ко всему массиву данных и ничто не мешает ему их скопировать. Да, это так, но при условии, что база реляционная и все данные уже удобно собраны в таблицы. Отдельно хотелось бы коснуться вопроса «импортозамещения» и развития отечественных технологий. Из федеральных СМИ мы каждый день слышим восторженные речи о том, как бурно и успешно идет этот процесс. А так ли обстоят дела на самом деле? Давайте разберемся. Я не буду касаться вопроса «железа» (не моя тема), поговорим о программном обеспечении (ПО). Любую компьютерную систему можно представить в виде слоеного пирога: Железо (материнская плата с процессором + BIOS + периферия). Операционная система (ОС). Программная оболочка, позволяющая взаимодействовать с железом с помощью специального набора команд (API). Пользователи могут общаться с ОС либо через командную строку, либо через графический интерфейс (например,"оконный»). СУБД. Многие могут возразить, что на их компьютере или телефоне не установлена СУБД, но это не так. Любое устройство работает с файлами, а файлы управляются с помощью файловой системы (FAT32, NTFS и т.д.), которая фактически является СУБД, предоставляющей доступ файлам всем программам работающим на устройстве; Программная платформа. Для обеспечения кроссплатформенности приложений активно используются всевозможные фреймворки (Framework). Фреймворк — это специальная платформенная среда разработки и исполнения ПО, как правило, не привязанная к конкретной ОС (Java, .Net и т.д.). Промежуточное ПО. Это специальный класс ПО, объединяющий различные приложения, сервисы, функции и создающее исполняемое ядро систем (тот самый Бэкенд). Конечное (пользовательское) ПО. Это те самые программы и визуальные интерфейсы, которые доступны конечным пользователям. Слои 1−2 являются инфраструктурными (обеспечивают работоспособность). Слои 3−4 являются платформенными (именно они определяют инструментарий и методику разработки ПО, то есть технологию). Слои 5−6 являются прикладными (они определяют, что умеет делать ПО и как с ним взаимодействует пользователь). Очевидно, что если мы говорим об импортозамещении, то речь должна идти о замене всех слоев «пирога. А что же «замещается» на самом деле. Пропустим железо, начнем с ОС. Новости пестрят заголовками о разработке отечественных ОС, но, если внимательно присмотреться, окажется, что большинство этих систем — это Linux, на который повешен фирменный бренд и получен сертификат соответствия. В редких случаях бывает доработан или адаптирован графический интерфейс. То же касается и СУБД. Сейчас самая популярная «российская» СУБД PostgreSQL (правообладателем которой является Университет Беркли, США). Фактически, сейчас существует не более 5 чисто российских СУБД, среди них ODANT (BIS), ClickHouse (Yandex), Tarantool (Mail.ru) Тема со свободным (Open Source) ПО вообще весьма скользкая, сегодня оно свободное, а завтра правообладатель передумает и что тогда? Ярким примером является Java. Много лет она была свободной, абсолютно бесплатной средой разработки, и вот новость… В середине 2018 года Oracle объявил, что собирается изменить лицензионную политику. 16 апреля 2019 года изменение вступило в силу. Теперь все опубликованные после этой даты сборки Java SE можно использовать бесплатно только для личных нужд и с целью разработки. Для использования в коммерческих целях надо оформить платную подписку у Oracle. Надо заметить, то львиная доля всех разработок в России делается именно на Java. А есть ли Российские платформы для разработки и исполнения ПО? Для этого надо ответить на простой вопрос: сколько разработчиков пользуется российскими технологиями разработки ПО? Ответ простой — нисколько! То есть их просто не существует. Тогда какие же Российские технологии мы развиваем? Справедливости ради, надо отметить, что 1С вполне можно назвать российской технологический платформой (несмотря на узкую специализацию и использование сторонних СУБД). И только два последних слоя «пирога» реально являются предметом отечественной разработки. К сожалению, этих слоев недостаточно для того, чтобы говорить о полноценном импортозамещении, ведь работоспособность прикладного ПО абсолютно зависит от четырёх нижних слоев, которые мы абсолютно не контролируем. Существует ли альтернативная, безопасная технология, которая обеспечит и надежный, бесперебойный доступ к государственным и образовательным услугам, и сохранность персональных данных? Роман Перепёлкин: При использовании объектных систем такая ситуация исключена, так как ещё нужно потрудится собрать всё в один массив из множества объектов, плюс существует возможность защищать сами объекты даже от администратора. В худшем случае, злоумышленник сможет удалить данные, но не сможет получить к ним доступ на чтение и тем более на изменение. Как я уже говорил ранее, и бесперебойный доступ гораздо легче обеспечить, если система не блокируется при каждом изменении данных, то есть не является реляционной. Почему при наличии более совершенной во всех отношениях платформы наши чиновники продолжают использовать те, с которыми постоянно возникают проблемы, доставляя неудобство гражданам и вызывая их возражения? Роман Перепёлкин: С одной стороны, возможно, это связано с консерватизмом разработчиков (нет времени переучиваться и все такое), а с другой стороны, такая ситуация, как ни странно, выгодна как разработчикам, так и госзаказчикам — мы имеем практически бесконечный процесс по выделению бюджетных средств на разработку систем, которые через некоторое время гарантированно сломаются, и все повторится заново. С другой стороны, IT-рынок сильно ангажирован и коррумпирован, особенно в госсекторе. Я имею в виду, что у каждого госзаказчика (точнее у конкретных чиновников) есть «свои» IT-компании, под которые пишется конкурсная документация, с такими условиями, что никто со стороны их не выполнит, что гарантирует выигрыш «своим», обеспечивающим освоение бюджета. Кстати, именно поэтому, после запрета закупок западного ПО, закупки только увеличились. Мало кто знает, сколько реально стоит SAP или Oracle. Одно ясно, что гораздо больше, чем любой российский продукт из Урюпинска. Следовательно: Денег на западное ПО можно выделить радикально больше. Получить «кэшбэк» от западной компании можно гораздо безопаснее (за пределами российской юрисдикции), чем от той же кампании из Урюпинска, поэтому с российскими продуктами связываться, как минимум, неразумно. И даже если чиновник абсолютно честный (что тоже встречается нередко), он не имеет права на ошибку, которые неизбежны при внедрении новых непроверенных продуктов российских разработчиков. В свое время, компания Боинг при создании 737 модели заказала разработку принципиально нового двигателя. Подрядчик взялся за работу, на выходе выяснилось, что двигатель не получился. Тогда Боинг еще раз заказал разработку, и снова ничего не вышло… Если не ошибаюсь, это повторялось около 60 раз, пока наконец, не получился двигатель с нужными характеристиками. В российских условиях к моменту второго заказа вся команда, которая делала первый, уже бы «сидела». Надо понимать, что инновационный продукт потому и инновационный, что до этого никто ничего подобного не делал, и сбои неизбежны. К сожалению, наше законодательство не приемлет слова «не получилось», а следовательно по факту, в России невозможны никакие инновационные процессы, зато процветает их бурная имитация.