Эд Йордан возглавляет службу по проблеме 2000 года в Cutter Consortium. С ним можно связаться по электронной почте по адресу yourdon@acm.org.
В то же время возможны и скрытые проблемы, которые потребуют внимания и немалых затрат в течение всего следующего года, — это искажение данных.

Я не имею в виду массовое, внезапное и очевидное искажение данных, скажем, когда система начисления зарплаты «впадает в транс» и обнуляет поле зарплаты всех сотрудников. Больше всего меня беспокоит такое проявление ошибки 2000 года, которое затрагивает достаточно небольшую часть базы данных, в силу чего оно не столь очевидно. В результате подобной ошибки активные записи базы данных могут обновляться корректно, но при этом портить неиспользуемые записи. К примеру, программа, которая выполняет обновление, может корректно заменить двузначное представление поля года YY в записях активной базы данных на четырехзначное YYYY, одновременно искажая первые два байта соседней записи. Могут пройти месяцы или даже годы, прежде чем потребуется не используемая ранее запись базы данных или прежде, чем подобные искажения возникнут в таком числе записей базы данных, что это приведет к видимой ошибке или сбою. Проблема может оказаться еще более завуалированной, если ошибка связана с интерфейсом между системами, работающими в различных организациях.

Искажение данных не новая концепция и отнюдь не уникальна для проблемы 2000 года. Но по иронии судьбы некоторые организации узнали о том, что ошибки, связанные с искажениями данных в их базах данных, проявляются уже давно, только тогда, когда начали реализацию проектов, направленных на решение проблемы 2000 года.

Так каким же образом мы можем обезопасить себя от искажения данных? Большинство организаций уверены, что они смогут избежать таких ошибок за счет тщательного тестирования и использования механизмов коррекции ошибок, встроенных в код приложения и пакетов производителей СУБД. Но во многих случаях это не более чем самообман. Вероятность избежать ошибки в базе данных, содержащей 10 млн. записей, с которой компания работает более 10 лет, очень мала. В действительности, скорее всего, организации могут рассчитывать на то, что их система стабильна, только в том случае, если эта система создается единовременно и в дальнейшем меняется относительно медленно.

Решение проблемы 2000 года имеет фундаментальное отличие от других задач, поскольку требует массового изменения всей системы, причем одновременно. Действительно, в большинстве крупных компаний проводилось и проводится очень тщательное тестирование, и, скорее всего, оно позволит «выловить» большинство видимых ошибок. Но нужно быть слишком большим оптимистом, чтобы предположить, что мы устраним скрытые ошибки, вызывающие незаметные сразу искажения данных. Особенно когда независимые производители, выполняющие тестирование и проверку, такие как Cap Gemini, MatriDigm и Reasoning Systems, сообщают, что в системах, которые были объявлены исправленными и протестированными, обнаруживается от 400 до 900 ошибок на миллион строк кода. Я уверен, что намного реалистичнее предположить, что ошибки, связанные с искажениями данных, будут проявляться и, возможно, это произойдет через месяцы, а то и через годы после 1 января 2000 года.

Так что вопрос остается прежним: как же обезопасить себя от искажения данных? Решение очевидное, хотя отнюдь не простое. Нам нужно разработать программы тщательной проверки данных, подтверждения правильности и целостности, а затем периодически использовать их в 2000-м и, возможно, в последующие годы. В зависимости от размера базы данных и мощности имеющихся центральных процессоров, первые месяцы нового года нам придется запускать такие программы ежедневно или по крайней мере раз в неделю. В дальнейшем с учетом полученного результата можно будет несколько ослабить поводья и запускать эти программы ежемесячно.

Существуют и коммерчески доступные пакеты проверки корректности данных, а кроме того, некоторые организации разрабатывают свои собственные программы с целью минимизировать искажения данных. Но так происходит далеко не всегда, и большинство организаций, которые я посетил, не планируют тратить в следующем году средства и компьютерные ресурсы на реализацию подобной стратегии. Я уверен, что подобный недосмотр может обойтись крайне дорого и проблема 2000 года может стать намного острее, чем могла бы быть.