Апокалипсис сегодня
Введение
О "Проблеме 2000" сказано и написано уже достаточно много - настолько много, что голова, порой, идет кругом. Тем более, что мнения, как обычно, полярно разделились. Одни говорят, что это ужасная проблема и грозит она неисчислимыми бедами для всего человечества. При этом предлагается в спешном порядке обновлять аппаратуру и программное обеспечение (тратя при этом десятки тысяч долларов). Другие, наоборот, говорят, что проблема придумана производителями компьютеров и программного обеспечения и нет нужды "паниковать и тратить деньги неизвестно на что". Должен, однако, заметить, что вторая точка зрения появилась, на мой взгляд, как вполне естественная реакция на более чем навязчивые предложения "помощи" от сторонников первой. С одной стороны, это хорошо, так как не позволяет поставщикам и производителям оборудования и ПО слишком сильно наживаться на "помощи" своим клиентам и потребителям, но, с другой стороны, наличие настроений типа: "Нам все нипочем" или "Нас это не коснется", особенно в среде технических специалистов и руководителей предприятий или организаций, может привести к тому, что однажды морозным январским утром... Вот на вопросы "что и когда может произойти", а также "что надо делать, чтобы этого не произошло", я и попытаюсь дать ответы в этой статье.
1. Что нас всех ждет, или Стоит ли строить убежище
Что же может произойти с компьютерами и информационными системами, если ошибка не будет исправлена? На самом деле проблема не ограничивается только настольными системами - во всем мире эксплуатируется множество так называемых "встроенных" систем, о наличии которых мы узнаем, как правило, только тогда, когда они ломаются. Типичным примером встроенной системы является электроника скоростного лифта в высотном здании - это самый настоящий компьютер, только узкоспециализированный. К этой же категории относятся бортовые системы автомобилей и самолетов, системы, следящие за нагрузкой в электросети и давлении в водопроводе. В большинстве этих устройств имеются часы, которые могут (но ни в коем случае не обязаны) быть подвержены "Проблеме 2000". Описание всех возможных источников бед и их последствий заняло бы слишком много времени, а по объему больше походило бы на монографию, чем на газетную статью, поэтому я позволю себе остановиться на более узком круге устройств и проблемах. Речь пойдет о персональных компьютерах и стандартных офисных приложениях, составляющих неотъемлемую часть любой системы электронного документооборота.
Первый источник бед персоналок заключен в часах реального времени (или RTC), которые присутствуют во всех системах, начиная с PC-AT (в более ранних персоналках, таких, как PC или PC-XT, часов реального времени не было вовсе, так что, как ни парадоксально, эти анахронизмы готовы к работе после 1 января 2000 года). Проблема заключается в том, что в микросхеме MC146818, производства компании Motorola, которая и реализовывала механизм часов реального времени, для обозначения года отводилось только две ячейки памяти, которых хватало для хранения только двух младших цифр года. Эта микросхема, правда, содержала еще флажок для указания текущего столетия, но во время компьютерного бума, разразившегося во второй половине 80-х, многие производители "забыли" про его существование. Кроме того, из-за довольно высокой стоимости носителей информации и их небольшой емкости программисты старались минимизировать объемы данных, которые подлежали хранению, и в базах данных использовали даты с двузначным указанием года. Сейчас это может показаться странным, но в те времена, когда жесткий диск емкостью 10-20 мегабайт считался роскошью, которую могли позволить себе очень немногие, занимать, например, 2 мегабайта в базе данных из 1 млн записей на хранение числа "19", обозначая 20-й век (что, как казалось, и так очевидно), считалось просто расточительством. А расплачиваться за их "экономность" приходится нам сегодня.
При переходе на 1 января 2000 года компьютеры, работающие с "обрезанным" годом, сбросят свои счетчики в положение "00", а BIOS, помня, что на дворе 20-й век, добавит жестко прошитые в нем цифры 19, и пользователь, включив утром компьютер, узнает, что на дворе 1 января 1900 года. Само по себе это не страшно, но если эту дату начнет использовать программа, начисляющая, например, проценты по вкладам, могут произойти довольно интересные вещи: если программист, писавший программу был ленив и не позаботился о том, чтобы период времени, за который начисляются проценты, был всегда положительным числом, то деньги со счета могут исчезнуть в какой-нибудь "черной дыре". И хорошо еще, если сумма этих "процентов" будет меньше остатка средств на счету. А если нет? Можно только догадываться о реакции бухгалтера, пришедшего на работу после Нового года и узнавшего, что у него ненулевые пассивы и счет на "картотеке" и т.д. Голова после праздников и так болит, а тут еще это. А теперь представьте, что в этот момент будет твориться в самом банке, у которого десятки тысяч клиентов и все звонят, приходят и требуют назад свои деньги. То, что происходило в России 17 августа прошлого года, можно будет назвать милой шуткой. (А может они просто так репетировали? Прим. автора.) Это только один пример того, что может произойти из-за неправильной обработки дат. Список можно продолжить "необъяснимыми" исчезновениями документов, хранящихся в рамках автоматизированных систем электронного документооборота, "внезапной" очисткой электронных почтовых ящиков с полной и безвозвратной потерей всей деловой переписки и так далее по всем буквам русского и латинского алфавитов. Так что пессимизм приверженцев первой точки зрения, упоминавшейся в начале статьи, небезоснователен. Правда, в большинстве случаев краски несколько сгущаются (пример, приведенный мной, - не исключение), но делается это исключительно для того, чтобы специалисты и управляющие не упускали проблему из поля зрения, так как хотим мы этого или нет, но проблема была, есть и рассасываться сама собой, похоже, не собирается. Таким образом, самое лучшее в данной ситуации - это встретить проблему во всеоружии. А самым надежным и первейшим оружием в нашем случае является знание о том, когда и откуда ждать врага, а также что предпринимать, чтобы он не пришел, и что с ним делать, если он все-таки появится.
2. Время "Ч" не за горами, или Когда ждать беды
Принято считать, что "Проблема 2000" проявит себя во всей красе 1 января 2000 года. В принципе, верно, но далеко не точно. Во-первых, проблема заключается не только в некорректной смене дат, но и в самой системе летоисчисления, которой мы пользуемся. Как известно, астрономический год не равен точно 365 суткам (он немножко длиннее) и в течение каждых 4 лет теряются почти сутки. Для компенсации этой потери в свое время были введены високосные года - каждый год, номер которого делится на "4" без остатка, считается високосным и имеет 29 дней во втором месяце вместо 28-ми. Однако эта коррекция не очень точная, и за каждые 100 лет будут "набегать" лишние сутки. Поэтому было решено, что каждый год, номер которого делится без остатка на "100", считается не високосным, несмотря на то, что он удовлетворяет первому правилу. Но и эта коррекция оказалась довольно неточной, так как снова теряются одни сутки, теперь уже каждые 400 лет. В Григорианском календаре существует третье правило, в соответствии с которым год, номер которого делится без остатка на "400", считается високосным. При этом достигается точность измерения года в 365.2425 дня, при истинной его длине в 365.24219 дня. ( На самом деле существует еще и четвертое правило, но оно действует раз в 4000 лет и до его ближайшего применения осталось еще как минимум 2000 лет, что нам пока не интересно. Прим. автора.) Проблема же заключается в том, что производители компьютеров и программного обеспечения помнят, обычно, только одно первое правило (в лучшем случае - два). В результате вычисления даты, построенные по этому принципу, будут давать сбои. Дело в том, что 2000-й год удовлетворяет 3-му правилу и, несмотря на то, что он делится без остатка на 100, должен быть високосным. Программы, которые используют в расчетах только 2 правила, в 2000-м году дадут сбой, выдав после 28 февраля 2000 года 1 марта 2000 года. Программы, "знающие" только первое правило, отработают нормально в 2000 году, но сделают ошибку в 2100-м. На то, что до этого срока они не доживут, я бы лично уповать не стал. Кто бы мог подумать, что техника 10-15-летней давности доживет до наших дней, и это при рекомендуемом сроке эксплуатации - 4-5 лет. А программы живут на порядок больше. Широко известна фраза какого-то западного менеджера: "Зачем менять программу, если она работает и справляется со своими обязанностями?!".
Еще одна проблема с датами скрыта в их интерпретации различными программами.
Пример 1. Западными аналитиками было выявлено, что многие программисты в свое время широко использовали комбинацию "9/9/99" в поле даты для внутренних целей, например, для обозначения удаленных записей в базах данных или внутренних, системных данных автоматизированной системы. Ничего себе шутка, особенно, если учесть, что проявится она 9 сентября 1999 года, то есть уже через 4 месяца.
Пример 2. Многие программы имеют собственную нестандартную систему измерения времени (обычно этим грешат операционные системы и СУБД). В частности, ОС Unix считает время в секундах, для чего используется обычный 31-разрядный двоичный счетчик. Нулевое значение этого счетчика соответствует 1 января 1970 года. Переполнение его должно наступить 19 января 2038 года. Точно таким проблемам подвержена и гораздо более распространенная настольная ОС MS-DOS, а точнее - ее файловая система FAT-16, где в таком виде хранится дата создания файла. Срок ее жизни истекает в 2035 году. Самое печальное - это то, что компании-производители предлагают только один способ устранения подобных ошибок - миграцию на новые версии программного обеспечения.
3. Когда за лесом злобный враг, или Что делать, чтобы избежать проблем
Что же можно (и нужно) предпринять, чтобы избежать проявления проблемы и ее последствий? Если проанализировать предложения и рекомендации различных аналитиков и компаний, можно получить примерно следующий план действий:
Шаг 1. Необходимо произвести инвентаризацию компьютерного парка и программного обеспечения, желательно, как можно более полную и детальную. В итоге должны получиться два списка: компьютеров - с указанием их типа процессора, модели материнской платы, названия и версии BIOS, и программного обеспечения - с указанием компании разработчика, версии продукта и версий применявшихся патчей.
Шаг 2. На основе полученных перечней организовать тестирование компьютеров на корректность перевода внутренних часов с 31.12.1999 на 01.01.2000 и, как минимум, с 28.02.2000 на 29.02.2000. На основе результатов тестирования составить перечень систем, не соответствующих требованиям по совместимости. Организовать проверку программного обеспечения на корректность работы с датами. Если Ваше ПО было приобретено по официальным каналам (то есть куплено), то наиболее простым способом будет просто обратиться к продавцу (или производителю). Вам вышлют официальное письмо с указанием, какая версия готова, какая не готова и какие патчи необходимо установить для того, чтобы обеспечить готовность. Кроме того, там Вам наверняка смогут предоставить все необходимые патчи. Если Ваша организация имеет доступ в Интернет, можно попробовать самостоятельно добыть эту информацию, однако, это займет гораздо больше времени и сил, чем послать запрос поставщику. Этот способ больше подходит для тех, чей продавец - парень на рынке Ждановичи без имени и обратного адреса.
Шаг 3. Вооружившись информацией о том, где, что и в каком количестве у Вас не готово к работе в 2000 году, попытаться активно влиять на ситуацию, действуя по принципу "лучшая защита - это нападение". В первую очередь следует заняться компьютерами. Тут есть варианты. Можно заменить BIOS - многие производители системных плат предлагают перешивки, обеспечивающие корректную работу системы с датой. Должен сразу сказать, что этот способ применим для компьютеров на базе процессора Pentium и некоторых поздних версий плат для процессоров I80486DX-x. Мои попытки найти обновления BIOS для более старых материнских плат закончились полным провалом, так как в большинстве случаев информация о них на серверах компаний производителей отсутствует даже в разделе "Музей". Но отчаиваться не стоит, так как безвыходных положений, как известно, не бывает. Для устаревшей техники (т.е. 286-х, 386-х и ранних 486-х) могут применяться аппаратные или программные заплатки. Аппаратная заплатка - это дополнительная плата расширения, которая устанавливается в свободный ISA слот компьютера. Эта плата полностью перехватывает на себя все функции работы с датой и системными часами и решает, таким образом, проблему даже на самых древнейших системах. Правда, цена в 80 у.е. несколько обескураживает. Программные заплатки производят те же функции, только выполнены в виде резидентных программ, которые должны запускаться при включении компьютера. Чаще всего, эти программки вообще бесплатны, но всегда существует риск, что они потеряются, не загрузятся и компьютер запустится без них (плата, в отличие от программ, сама из компьютера не выскочит, да и действию вирусов не подвержена). Следующий этап - необходимо обеспечить корректную работу операционных систем. Вот тут пригодятся патчи, полученные от поставщиков данного ПО. Может так случиться, что Ваша операционная система уже не поддерживается производителем, и соответствующей заплатки для нее нет и не будет. В этом случае выход, к сожалению, только один - менять. И, напоследок, прикладное ПО. С программами общего назначения, написанными более или менее известными компаниями, - понятно. Действия тут такие же, как и в случае с операционными системами. Наибольший интерес представляют уникальные продукты, написанные кем-то исключительно для вас или разработанные собственными силами. Если разработчиков еще можно найти, то контактируйте с ними и требуйте гарантий корректной работы. Желательно получить от них официальное письмо, подтверждающее корректность их детища (этот документ будет вашим основным аргументом при защите, если дело, не дай бог, дойдет до суда). С собственными разработками и/или программами тех, кто по тем или иным причинам недоступен, придется разбираться самостоятельно. Необходимо будет провести исследование работы этого продукта в различных режимах, определить критичность приложения и его чувствительность к датам. В идеальном случае поручить эту задачу следует специальной группе программистов, вооруженной теоретическими и практическими навыками в методологии тестирования программных продуктов. Если у вас работает команда квалифицированных программистов, то можно нагрузить и их, однако, должен заметить, процесс тестирования любого программного продукта очень трудоемок и отнимет у ваших людей массу времени и сил. Независимых квалифицированных тестировщиков можно найти среди преподавателей и студентов старших курсов кафедр информатики (программирования и т.д.) любого технического вуза республики. Как показывает практика, это наиболее приемлемый вариант с точки зрения "цена/качество выполненных работ".
4. Кто виноват. Послесловие
Что делать, если, несмотря на все ваши старания, ошибка все-таки проявилась? В первую очередь - не паниковать и не шарить в ящиках стола в поисках пистолета. Необходимо (и быстро) сделать две вещи: локализовать источник ошибки и нейтрализовать его. Если сбой все-таки произошел, необходимо определить, какая задача его вызвала, и не допустить распространения или повторения сбоя. В идеальном случае сбойную систему необходимо остановить до завершения разбирательства и исправления ошибки, но это не всегда допустимо - есть задачи, имеющие категорию "критически важная" или "жизненно важная", которые останавливать ни в коем случае нельзя (например, бортовой компьютер авиалайнера или система, управляющая реанимационным комплексом, - про компьютерные системы АЭС я молчу). В этих случаях необходимо по возможности изолировать сбоящую систему от остальных или не использовать функцию, вызывающую сбой. В данном случае имеется в виду, что источником ошибки не является сам критически важный модуль, так как он, по идее, должен был тестироваться в первую очередь и наиболее внимательно. В любом случае, каждый факт возникновения ошибки должен регистрироваться и, по возможности, немедленно (пусть и вручную) исправляться. Виновных в возникновении ошибки можно найти и позже - в первую очередь необходимо вернуть ситуацию под контроль и добиться устойчивой работы всей информационной системы. Действовать именно так необходимо потому, что "Ошибка 2000" страшна не сама по себе, а тем, что оказывает разрушительное воздействие на взаимодействующие системы: источник ошибки может быть у вас, а основной ущерб от нее - у ваших партнеров или клиентов.
Наиболее разумным способом подготовки к проявлению ошибки будет разработка так называемых "trouble-plans", в которых продуманы действия по стабилизации ситуации при возникновении ошибки в каждой из эксплуатируемых подсистем. На западе такие "трабл-планы" весьма распространены - порой у каждого сотрудника на столе лежит толстенная инструкция, описывающая, что он должен делать (что хватать и куда бежать) в самых разнообразных нештатных ситуациях. У нас, к сожалению, эта традиция выродилась в развешивание планов эвакуации при пожаре. Уверен, что если спросить любого руководителя о том, как он планирует спасать материальные ценности в любой экстремальной ситуации, то он вряд ли сможет дать определенный ответ. "Проблема 2000" по своей природе такова, что ее, во-первых, можно (и нужно) предупредить, а во-вторых, ее последствия могут оказаться заметно менее серьезными при элементарной готовности ответственных лиц.
И в заключение хочется сказать о самой подготовке к "встрече" 2000 года. В небольших системах (до 10 компьютеров) весь комплекс проверок, тестирований и исправлений найденных ошибок можно провести собственными силами. В более крупных системах процесс тестирования может оказаться настолько трудоемким, что, при выполнении собственными силами, может оказать негативное влияние на основную деятельность предприятия или организации. В этом случае лучший выход - обратиться к специалистам.
Александр Лобинский
О "Проблеме 2000" сказано и написано уже достаточно много - настолько много, что голова, порой, идет кругом. Тем более, что мнения, как обычно, полярно разделились. Одни говорят, что это ужасная проблема и грозит она неисчислимыми бедами для всего человечества. При этом предлагается в спешном порядке обновлять аппаратуру и программное обеспечение (тратя при этом десятки тысяч долларов). Другие, наоборот, говорят, что проблема придумана производителями компьютеров и программного обеспечения и нет нужды "паниковать и тратить деньги неизвестно на что". Должен, однако, заметить, что вторая точка зрения появилась, на мой взгляд, как вполне естественная реакция на более чем навязчивые предложения "помощи" от сторонников первой. С одной стороны, это хорошо, так как не позволяет поставщикам и производителям оборудования и ПО слишком сильно наживаться на "помощи" своим клиентам и потребителям, но, с другой стороны, наличие настроений типа: "Нам все нипочем" или "Нас это не коснется", особенно в среде технических специалистов и руководителей предприятий или организаций, может привести к тому, что однажды морозным январским утром... Вот на вопросы "что и когда может произойти", а также "что надо делать, чтобы этого не произошло", я и попытаюсь дать ответы в этой статье.
1. Что нас всех ждет, или Стоит ли строить убежище
Что же может произойти с компьютерами и информационными системами, если ошибка не будет исправлена? На самом деле проблема не ограничивается только настольными системами - во всем мире эксплуатируется множество так называемых "встроенных" систем, о наличии которых мы узнаем, как правило, только тогда, когда они ломаются. Типичным примером встроенной системы является электроника скоростного лифта в высотном здании - это самый настоящий компьютер, только узкоспециализированный. К этой же категории относятся бортовые системы автомобилей и самолетов, системы, следящие за нагрузкой в электросети и давлении в водопроводе. В большинстве этих устройств имеются часы, которые могут (но ни в коем случае не обязаны) быть подвержены "Проблеме 2000". Описание всех возможных источников бед и их последствий заняло бы слишком много времени, а по объему больше походило бы на монографию, чем на газетную статью, поэтому я позволю себе остановиться на более узком круге устройств и проблемах. Речь пойдет о персональных компьютерах и стандартных офисных приложениях, составляющих неотъемлемую часть любой системы электронного документооборота.
Первый источник бед персоналок заключен в часах реального времени (или RTC), которые присутствуют во всех системах, начиная с PC-AT (в более ранних персоналках, таких, как PC или PC-XT, часов реального времени не было вовсе, так что, как ни парадоксально, эти анахронизмы готовы к работе после 1 января 2000 года). Проблема заключается в том, что в микросхеме MC146818, производства компании Motorola, которая и реализовывала механизм часов реального времени, для обозначения года отводилось только две ячейки памяти, которых хватало для хранения только двух младших цифр года. Эта микросхема, правда, содержала еще флажок для указания текущего столетия, но во время компьютерного бума, разразившегося во второй половине 80-х, многие производители "забыли" про его существование. Кроме того, из-за довольно высокой стоимости носителей информации и их небольшой емкости программисты старались минимизировать объемы данных, которые подлежали хранению, и в базах данных использовали даты с двузначным указанием года. Сейчас это может показаться странным, но в те времена, когда жесткий диск емкостью 10-20 мегабайт считался роскошью, которую могли позволить себе очень немногие, занимать, например, 2 мегабайта в базе данных из 1 млн записей на хранение числа "19", обозначая 20-й век (что, как казалось, и так очевидно), считалось просто расточительством. А расплачиваться за их "экономность" приходится нам сегодня.
При переходе на 1 января 2000 года компьютеры, работающие с "обрезанным" годом, сбросят свои счетчики в положение "00", а BIOS, помня, что на дворе 20-й век, добавит жестко прошитые в нем цифры 19, и пользователь, включив утром компьютер, узнает, что на дворе 1 января 1900 года. Само по себе это не страшно, но если эту дату начнет использовать программа, начисляющая, например, проценты по вкладам, могут произойти довольно интересные вещи: если программист, писавший программу был ленив и не позаботился о том, чтобы период времени, за который начисляются проценты, был всегда положительным числом, то деньги со счета могут исчезнуть в какой-нибудь "черной дыре". И хорошо еще, если сумма этих "процентов" будет меньше остатка средств на счету. А если нет? Можно только догадываться о реакции бухгалтера, пришедшего на работу после Нового года и узнавшего, что у него ненулевые пассивы и счет на "картотеке" и т.д. Голова после праздников и так болит, а тут еще это. А теперь представьте, что в этот момент будет твориться в самом банке, у которого десятки тысяч клиентов и все звонят, приходят и требуют назад свои деньги. То, что происходило в России 17 августа прошлого года, можно будет назвать милой шуткой. (А может они просто так репетировали? Прим. автора.) Это только один пример того, что может произойти из-за неправильной обработки дат. Список можно продолжить "необъяснимыми" исчезновениями документов, хранящихся в рамках автоматизированных систем электронного документооборота, "внезапной" очисткой электронных почтовых ящиков с полной и безвозвратной потерей всей деловой переписки и так далее по всем буквам русского и латинского алфавитов. Так что пессимизм приверженцев первой точки зрения, упоминавшейся в начале статьи, небезоснователен. Правда, в большинстве случаев краски несколько сгущаются (пример, приведенный мной, - не исключение), но делается это исключительно для того, чтобы специалисты и управляющие не упускали проблему из поля зрения, так как хотим мы этого или нет, но проблема была, есть и рассасываться сама собой, похоже, не собирается. Таким образом, самое лучшее в данной ситуации - это встретить проблему во всеоружии. А самым надежным и первейшим оружием в нашем случае является знание о том, когда и откуда ждать врага, а также что предпринимать, чтобы он не пришел, и что с ним делать, если он все-таки появится.
2. Время "Ч" не за горами, или Когда ждать беды
Принято считать, что "Проблема 2000" проявит себя во всей красе 1 января 2000 года. В принципе, верно, но далеко не точно. Во-первых, проблема заключается не только в некорректной смене дат, но и в самой системе летоисчисления, которой мы пользуемся. Как известно, астрономический год не равен точно 365 суткам (он немножко длиннее) и в течение каждых 4 лет теряются почти сутки. Для компенсации этой потери в свое время были введены високосные года - каждый год, номер которого делится на "4" без остатка, считается високосным и имеет 29 дней во втором месяце вместо 28-ми. Однако эта коррекция не очень точная, и за каждые 100 лет будут "набегать" лишние сутки. Поэтому было решено, что каждый год, номер которого делится без остатка на "100", считается не високосным, несмотря на то, что он удовлетворяет первому правилу. Но и эта коррекция оказалась довольно неточной, так как снова теряются одни сутки, теперь уже каждые 400 лет. В Григорианском календаре существует третье правило, в соответствии с которым год, номер которого делится без остатка на "400", считается високосным. При этом достигается точность измерения года в 365.2425 дня, при истинной его длине в 365.24219 дня. ( На самом деле существует еще и четвертое правило, но оно действует раз в 4000 лет и до его ближайшего применения осталось еще как минимум 2000 лет, что нам пока не интересно. Прим. автора.) Проблема же заключается в том, что производители компьютеров и программного обеспечения помнят, обычно, только одно первое правило (в лучшем случае - два). В результате вычисления даты, построенные по этому принципу, будут давать сбои. Дело в том, что 2000-й год удовлетворяет 3-му правилу и, несмотря на то, что он делится без остатка на 100, должен быть високосным. Программы, которые используют в расчетах только 2 правила, в 2000-м году дадут сбой, выдав после 28 февраля 2000 года 1 марта 2000 года. Программы, "знающие" только первое правило, отработают нормально в 2000 году, но сделают ошибку в 2100-м. На то, что до этого срока они не доживут, я бы лично уповать не стал. Кто бы мог подумать, что техника 10-15-летней давности доживет до наших дней, и это при рекомендуемом сроке эксплуатации - 4-5 лет. А программы живут на порядок больше. Широко известна фраза какого-то западного менеджера: "Зачем менять программу, если она работает и справляется со своими обязанностями?!".
Еще одна проблема с датами скрыта в их интерпретации различными программами.
Пример 1. Западными аналитиками было выявлено, что многие программисты в свое время широко использовали комбинацию "9/9/99" в поле даты для внутренних целей, например, для обозначения удаленных записей в базах данных или внутренних, системных данных автоматизированной системы. Ничего себе шутка, особенно, если учесть, что проявится она 9 сентября 1999 года, то есть уже через 4 месяца.
Пример 2. Многие программы имеют собственную нестандартную систему измерения времени (обычно этим грешат операционные системы и СУБД). В частности, ОС Unix считает время в секундах, для чего используется обычный 31-разрядный двоичный счетчик. Нулевое значение этого счетчика соответствует 1 января 1970 года. Переполнение его должно наступить 19 января 2038 года. Точно таким проблемам подвержена и гораздо более распространенная настольная ОС MS-DOS, а точнее - ее файловая система FAT-16, где в таком виде хранится дата создания файла. Срок ее жизни истекает в 2035 году. Самое печальное - это то, что компании-производители предлагают только один способ устранения подобных ошибок - миграцию на новые версии программного обеспечения.
3. Когда за лесом злобный враг, или Что делать, чтобы избежать проблем
Что же можно (и нужно) предпринять, чтобы избежать проявления проблемы и ее последствий? Если проанализировать предложения и рекомендации различных аналитиков и компаний, можно получить примерно следующий план действий:
Шаг 1. Необходимо произвести инвентаризацию компьютерного парка и программного обеспечения, желательно, как можно более полную и детальную. В итоге должны получиться два списка: компьютеров - с указанием их типа процессора, модели материнской платы, названия и версии BIOS, и программного обеспечения - с указанием компании разработчика, версии продукта и версий применявшихся патчей.
Шаг 2. На основе полученных перечней организовать тестирование компьютеров на корректность перевода внутренних часов с 31.12.1999 на 01.01.2000 и, как минимум, с 28.02.2000 на 29.02.2000. На основе результатов тестирования составить перечень систем, не соответствующих требованиям по совместимости. Организовать проверку программного обеспечения на корректность работы с датами. Если Ваше ПО было приобретено по официальным каналам (то есть куплено), то наиболее простым способом будет просто обратиться к продавцу (или производителю). Вам вышлют официальное письмо с указанием, какая версия готова, какая не готова и какие патчи необходимо установить для того, чтобы обеспечить готовность. Кроме того, там Вам наверняка смогут предоставить все необходимые патчи. Если Ваша организация имеет доступ в Интернет, можно попробовать самостоятельно добыть эту информацию, однако, это займет гораздо больше времени и сил, чем послать запрос поставщику. Этот способ больше подходит для тех, чей продавец - парень на рынке Ждановичи без имени и обратного адреса.
Шаг 3. Вооружившись информацией о том, где, что и в каком количестве у Вас не готово к работе в 2000 году, попытаться активно влиять на ситуацию, действуя по принципу "лучшая защита - это нападение". В первую очередь следует заняться компьютерами. Тут есть варианты. Можно заменить BIOS - многие производители системных плат предлагают перешивки, обеспечивающие корректную работу системы с датой. Должен сразу сказать, что этот способ применим для компьютеров на базе процессора Pentium и некоторых поздних версий плат для процессоров I80486DX-x. Мои попытки найти обновления BIOS для более старых материнских плат закончились полным провалом, так как в большинстве случаев информация о них на серверах компаний производителей отсутствует даже в разделе "Музей". Но отчаиваться не стоит, так как безвыходных положений, как известно, не бывает. Для устаревшей техники (т.е. 286-х, 386-х и ранних 486-х) могут применяться аппаратные или программные заплатки. Аппаратная заплатка - это дополнительная плата расширения, которая устанавливается в свободный ISA слот компьютера. Эта плата полностью перехватывает на себя все функции работы с датой и системными часами и решает, таким образом, проблему даже на самых древнейших системах. Правда, цена в 80 у.е. несколько обескураживает. Программные заплатки производят те же функции, только выполнены в виде резидентных программ, которые должны запускаться при включении компьютера. Чаще всего, эти программки вообще бесплатны, но всегда существует риск, что они потеряются, не загрузятся и компьютер запустится без них (плата, в отличие от программ, сама из компьютера не выскочит, да и действию вирусов не подвержена). Следующий этап - необходимо обеспечить корректную работу операционных систем. Вот тут пригодятся патчи, полученные от поставщиков данного ПО. Может так случиться, что Ваша операционная система уже не поддерживается производителем, и соответствующей заплатки для нее нет и не будет. В этом случае выход, к сожалению, только один - менять. И, напоследок, прикладное ПО. С программами общего назначения, написанными более или менее известными компаниями, - понятно. Действия тут такие же, как и в случае с операционными системами. Наибольший интерес представляют уникальные продукты, написанные кем-то исключительно для вас или разработанные собственными силами. Если разработчиков еще можно найти, то контактируйте с ними и требуйте гарантий корректной работы. Желательно получить от них официальное письмо, подтверждающее корректность их детища (этот документ будет вашим основным аргументом при защите, если дело, не дай бог, дойдет до суда). С собственными разработками и/или программами тех, кто по тем или иным причинам недоступен, придется разбираться самостоятельно. Необходимо будет провести исследование работы этого продукта в различных режимах, определить критичность приложения и его чувствительность к датам. В идеальном случае поручить эту задачу следует специальной группе программистов, вооруженной теоретическими и практическими навыками в методологии тестирования программных продуктов. Если у вас работает команда квалифицированных программистов, то можно нагрузить и их, однако, должен заметить, процесс тестирования любого программного продукта очень трудоемок и отнимет у ваших людей массу времени и сил. Независимых квалифицированных тестировщиков можно найти среди преподавателей и студентов старших курсов кафедр информатики (программирования и т.д.) любого технического вуза республики. Как показывает практика, это наиболее приемлемый вариант с точки зрения "цена/качество выполненных работ".
4. Кто виноват. Послесловие
Что делать, если, несмотря на все ваши старания, ошибка все-таки проявилась? В первую очередь - не паниковать и не шарить в ящиках стола в поисках пистолета. Необходимо (и быстро) сделать две вещи: локализовать источник ошибки и нейтрализовать его. Если сбой все-таки произошел, необходимо определить, какая задача его вызвала, и не допустить распространения или повторения сбоя. В идеальном случае сбойную систему необходимо остановить до завершения разбирательства и исправления ошибки, но это не всегда допустимо - есть задачи, имеющие категорию "критически важная" или "жизненно важная", которые останавливать ни в коем случае нельзя (например, бортовой компьютер авиалайнера или система, управляющая реанимационным комплексом, - про компьютерные системы АЭС я молчу). В этих случаях необходимо по возможности изолировать сбоящую систему от остальных или не использовать функцию, вызывающую сбой. В данном случае имеется в виду, что источником ошибки не является сам критически важный модуль, так как он, по идее, должен был тестироваться в первую очередь и наиболее внимательно. В любом случае, каждый факт возникновения ошибки должен регистрироваться и, по возможности, немедленно (пусть и вручную) исправляться. Виновных в возникновении ошибки можно найти и позже - в первую очередь необходимо вернуть ситуацию под контроль и добиться устойчивой работы всей информационной системы. Действовать именно так необходимо потому, что "Ошибка 2000" страшна не сама по себе, а тем, что оказывает разрушительное воздействие на взаимодействующие системы: источник ошибки может быть у вас, а основной ущерб от нее - у ваших партнеров или клиентов.
Наиболее разумным способом подготовки к проявлению ошибки будет разработка так называемых "trouble-plans", в которых продуманы действия по стабилизации ситуации при возникновении ошибки в каждой из эксплуатируемых подсистем. На западе такие "трабл-планы" весьма распространены - порой у каждого сотрудника на столе лежит толстенная инструкция, описывающая, что он должен делать (что хватать и куда бежать) в самых разнообразных нештатных ситуациях. У нас, к сожалению, эта традиция выродилась в развешивание планов эвакуации при пожаре. Уверен, что если спросить любого руководителя о том, как он планирует спасать материальные ценности в любой экстремальной ситуации, то он вряд ли сможет дать определенный ответ. "Проблема 2000" по своей природе такова, что ее, во-первых, можно (и нужно) предупредить, а во-вторых, ее последствия могут оказаться заметно менее серьезными при элементарной готовности ответственных лиц.
И в заключение хочется сказать о самой подготовке к "встрече" 2000 года. В небольших системах (до 10 компьютеров) весь комплекс проверок, тестирований и исправлений найденных ошибок можно провести собственными силами. В более крупных системах процесс тестирования может оказаться настолько трудоемким, что, при выполнении собственными силами, может оказать негативное влияние на основную деятельность предприятия или организации. В этом случае лучший выход - обратиться к специалистам.
Александр Лобинский
Компьютерная газета. Статья была опубликована в номере 19 за 1999 год в рубрике разное :: мелочи жизни
