Ночь. Метро. ИС. Милиционеры

В один из знойных дней минувшего лета в «Полном ПК» появилась освежающая заметка (№ 5, «Метро дешевеет»). Оказывается, срок службы магнитной карты московского метро, вошедшей в оборот после внедрения новой автоматизированной системы прохода, путем нехитрых манипуляций можно продлить в два раза, придав билету, так сказать, «вторую свежесть».

Суть в том, что магнитная полоса карты спроектирована для надежности из двух частей: основной и резервной, и запрограммированный механизм их обработки допускает (путем заклеивания скотчем и последующего отклеивания) ездить сначала «по одной полосе», а потом «по другой».

Наблюдения за действиями моего сына с картой метро позволили реконструировать (вот он, «риверс инжиниринг«!) заложенный механизм обработки и обнаружить (вот оно, открытие!), что срок использования билета может быть значительно больше. Вот как, с точностью до деталей, должен действовать этот механизм.

• В обычном случае автомат читает число поездок с основной полосы, увеличивает на единицу, записывает новое число на основную и на резервную полосы и пропускает пассажира.
• Если резервная полоса вышла из строя, работа идет только с основной.
• Если основная полоса вышла из строя, автомат читает число поездок с резервной, увеличивает на единицу и записывает туда же новое число, то есть работает только с резервной полосой.

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

  Получается, что если билет рассчитан на n поездок, то, заклеивая в нужные моменты основную полосу, можно всего проехать n + (n — 1) + (n — 2) + ... + 1 раз, то есть, как догадался еще в школе юный Гаусс, (n + 1) * n / 2. При n = 30 «свежесть» много больше двойной. Вот такая история.

  Очевидно, что в случае с метро мы имеем один из немногих примеров развитой производственной распределенной ответственной автоматизированной системы массового обслуживания, разработанной в последнее время. Уже по этим качествам труд известной фирмы-разработчика заслуживает уважения: это вам не продать дорогую зарубежную систему, хотя бы и «настроив» ее на потребителя. Оценка результата прозрачна и не упирается в непроверяемый пресс-релиз или бодрую статью: система либо работает, либо нет; либо вы в метро проходите, либо нет. Этим система — увы! — уязвима для досужей критики, но зато она позволяет достоверно судить об уровне производства ПО в нашей стране. Поэтому только некоторые наблюдения, сделанные под впечатлением от «двойной свежести», приобретают несколько более общий характер.

• Во-первых, приведенный практический пример напоминает «академическую» истину о чрезвычайной важности тщательной проработки постановочного этапа. Неучтенные изначально ситуации могут вылиться в девальвирующие общую цель процессы, приостановить которые бывает непросто.
• Второе. В реальных масштабных распределенных информационных системах внесение изменений составляет самостоятельную проблему, процесс решения которой должен осуществляться на уровне не ниже уровня решения задачи. Подавляющее число современных отечественных разработок рассчитано на отдельный компьютер или локальную сеть, там эта проблема сильно облегчена, и беда, если навыки создания локальных систем некритически трансформируются на системы существенно распределенные.
• Проблема сопровождения сданной системы, как видно из примера, составляет важнейшую часть ее функционирования.
• Наконец, следует признать, что по своему уровню лучшие отечественные разработки программного обеспечения (к которым можно отнести систему автоматизации для метро) пока не могут сравниться с лучшими разработками советского периода. Как, например, не вспомнить, что бортовой компьютер Аргон-16, созданный в 1973 году и безотказно проработавший на станции «Мир», одобрен американской стороной для использования на станции нового поколения «Альфа» (www.computer-museum.ru/ History_CCCP/13-3.htm). А ведь число нештатных ситуаций для него, помноженное на вес последствий неправильной обработки, ничуть не менее весомо, чем для системы в метро!

Почему я решил сначала не писать эту заметку

Понаблюдав за сыном, я решил повторить его затею. Заклеил полосу, отъездил положенное число раз, отклеил и... ничего не получилось. Грешил, конечно, на следы, оставленные скотчем на полосе, но в какой-то момент подумал: не буду писать заметку. Все-таки не стоит поучать профессионалов своего дела, как нужно делать информационные системы. Они и так зафиксировали «прокол» и устранили недочет в проекте. Интересно, как они сумели настолько хорошо наладить сопровождение, что достаточно оперативно довели исправление до всех станций метро и до всех турникетов?

Почему я все-таки решил написать эту заметку

Вхожу на днях в метро, и тут меня останавливает милиционер. Просит билет и начинает долго рассматривать. Спрашиваю, милицейское ли это занятие — билеты в метро проверять. А он, со свойственной младшим милицейским чинам простодушием и откровенностью, возьми да и скажи: «Это другое. Если у вас билет скотчем заклеен, то это уголовное дело». Вот такой милицейский «патч» на информационную систему. Чисто российское решение проблем разработки и сопровождения информационных систем. Ну как об этом не написать?!

Между прочим, интересно: все ли из нескольких миллионов ежедневных пассажиров московского метро осведомлены (это должно быть одной из организационных процедур внедрения новой автоматизированной системы) о том, что наклеивание скотча на билет уголовно преследуется? И каковы параметры соответствующей статьи УК?

А для руководителей подразделений информационных служб, гораздо внимательнее относящихся к своей профессиональной деятельности, нежели к УК, следующий и последний в этой заметке вопрос: как в данном случае был организован жизненный цикл системы и какие упущения в нем (на ошибках учатся!) стали причиной ночного знакомства с милицией?