Некоторые считают, что все уже закончилось, и проблема, по сути, была надуманной. Однако посмотрим на это с разумных позиций. Возникает ряд вопросов:
- чего еще можно ожидать и когда?
- решена ли проблема окончательно?
- каков «сухой остаток» от решения этой проблемы?
 |
| Валерий Иванович Артемьев — начальник отдела координации проектных работ Главного центра информатизации Банка России. С ним можно связаться по электронной почте: art@gci.cbr.ru |
Конечно же, «Проблема 2000» имела под собою реальную почву. Ажиотажа тоже было предостаточно. Однако солидные фирмы рассматривали ее как сложную организационно-техническую задачу, требующую решения, и готовились к различным сюрпризам в течение по крайней мере года. То, что катаклизмов не было, говорит о степени готовности к 2000 году. Правда, основная деловая активность ожидается только во второй половине января, тогда возникнут дополнительные условия для проявления «Проблемы 2000». Кроме того, конкретные сбои не становятся достоянием гласности по самым разным причинам: исправляются локально или обходятся при резервировании, замалчиваются по соображениям престижа, да и не настало еще время для «разбора полетов».
Когда и чего еще можно ожидать?
Многие спрашивают, когда же все это кончится. В ближайшей перспективе следует обратить внимание на две критические даты и связанные с ними переходы: 29 февраля и 31 декабря 2000 года. Но сбои могут проявиться в любое другое время, обусловленное цикличностью ведения бизнеса и обработки информации, ну и, конечно же, степенью готовности к 2000 году.
Если вы протестировали и обновили технику и программы, имеете план мероприятий на случай проявления неучтенных ошибок 2000 года, то можете ли спать спокойно? Все-таки нет. Есть еще один важный аспект, который практически все упускают из виду: наличие искаженных дат в базах данных. Рассмотрим этот вопрос подробнее.
Несколько слов о природе этого явления. В ходе первичного тестирования приложений было выявлено, что программы, на первый взгляд (по итогам инвентаризации) готовые к 2000 году, позволяют вводить даты в коротком формате в поля с полным представлением даты.
Правильные реакции на такой ввод:
- для любых дат или только для дат далеких событий выдается сообщение об ошибке;
- для дат близких событий используется интерпретация дат в коротком формате.
Во многих же программах реакция была неверной: так, вместо ожидаемых 20хх годов после интерпретации в базу данных попадали даты с 19хх годами.
Если вы доработали такие программы (запретив короткий формат ввода или обеспечив правильную интерпретацию), то в дальнейшем искажений дат уже не возникнет. Однако даты, полученные с помощью этой программы до ее обновления, могут остаться в базе данных искаженными.
Подобное искажение касается дат будущих событий, введенных в коротком формате до 2000 года. Инвентаризация не позволяет выявить все даты будущих событий, которые могут подвергнуться искажениям. Тем более если у вас имеются сотни задач и тысячи полей типа «дата» в миллионах записей БД. В таком случае может помочь сплошное или выборочное инспектирование дат в БД. Для этого нужно во всех записях, где содержатся даты, отыскать их значения, лежащие в диапазоне 1900 - 1919 (верхняя граница достаточно условна). Если не отыскать и не исправить такие искаженные даты, то они в любое время могут сработать как мины замедленного действия.
Я принимал участие в разработке программы инспектирования дат в базах данных СУБД Oracle. Программа включает две процедуры:
- анализ словаря БД для поиска полей типа DATE;
- генерацию и выполнение SQL-фильтров для отбора записей с искаженными датами.
Такая программа не очень сложна, но достаточно эффективна, легко может быть написана для других типов БД. Вообще-то выборочное инспектирование можно выполнить и вручную с помощью подходящего интерпретатора SQL-запросов.
А что нам сулит долгосрочная перспектива? Решили ли мы календарные проблемы раз и навсегда?
Решена ли проблема окончательно?
В долгосрочной перспективе нас и наших потомков ожидает еще много малых и больших неприятностей, связанных с календарем. Некоторые программистские решения проблемы 2000 года (такие, как, например, специфические методы кодирования и метод фиксированного окна для интерпретации односимвольного представления года) имеют ограниченные сроки годности — до 2005 или 2010 года! Другие будут корректно работать, например, до 2030 года. Возможно, это были прагматичные временные решения, но теперь их нужно вовремя скорректировать. Но, даже если использован метод скользящего окна для интерпретации двухразрядных годов или полный формат представления дат, то проблемы будут поджидать в другом месте. Так, системные часы персональных компьютеров смогут работать только до 2035 года, часы операционных систем Unix и программ на Си — до 2037 года.
Что из всего этого следует? То, что любой компонент информационной системы (аппаратура, ОС, СУБД, база данных и прикладная программа) имеет ограниченный диапазон поддерживаемых дат, зависящий от их электронного представления. А значит, и приложение имеет ограниченный диапазон дат, полученный наложением диапазонов в составляющих компонентах.
В практическом плане следует в документации каждого компонента явно указывать диапазон представленных дат, чтобы можно было определить диапазон дат для приложения в соответствующем окружении. Нужно фиксировать этот диапазон в паспорте эксплуатируемого приложения, постоянно отслеживать временные горизонты и вносить необходимые коррективы.
В глобальном плане следует отметить, что пока нет общего решения для электронного представления временной переменной, неограниченной сверху. Возможно, такое общее календарное представление включает счетчик фиксированной разрядности для относительного времени (даты) и представление базового (подразумеваемого) года в виде поля переменной длины. Но такой формат на сегодняшний день нужно унифицировать для каждого компонента с учетом его реализации. А пора бы решить эту проблему раз и навсегда!
Дело не только в том, что не стоит ограничивать временной горизонт приложения сроком вашего выхода на пенсию. Просто одна из особенностей программирования состоит в том, чтобы создавать стандартные решения подобных задач.
Итак, уважаемые разработчики, не создавайте проблем для потомков, готовьтесь к встрече 10 000 года!
Каков «сухой остаток» от решения Проблемы?
На решение «Проблемы 2000» потрачено много сил, времени и материальных средств. В конечном итоге были задействованы известные, но редко используемые и малоизученные методы и средства:
- инвентаризация и инспектирование приложений и данных;
- тестирование информационных систем;
- планы чрезвычайных обстоятельств;
- резервирование технологий и приложений;
- диспетчеризация и разрешение нештатных ситуаций.
Важно найти место и закрепить примененные методы, средства и достигнутые результаты в практике разработки информационных систем.
Инвентаризация и инспектирование приложений и данных
Комплексная инвентаризация, выполненная при решении «Проблемы 2000», позволила составить общий перечень используемых приложений, связанных с ними баз данных и файлов, а также системно-технического обеспечения. Помимо основного назначения такие постоянно обновляемые перечни компонентов с подробными характеристиками способствуют планированию развития информационных систем, пониманию взаимосвязей между ними и проведению унификации и стандартизации самих компонентов и интерфейсов. Некоторые испробовали средства автоматизации для составления описей вычислительной техники, сетевого и телекоммуникационного оборудования, системного и прикладного ПО.
Инспектирование в грубом виде можно рассматривать как разновидность инвентаризации, касающейся внутреннего устройства компонентов. Один частный пример инспектирования дат в БД мы рассмотрели ранее. Другие примеры инспектирования относятся к кодам программ, форматам файлов и системным настройкам. Инспектирование имеет целью проверить соответствие соглашениям по именованию, правилам оформления программ, форматам представления данных, общим и локальным стандартам и иным требованиям, найти искажения данных. Регулярное проведение инспектирования способствует повышению качества программных продуктов и улучшению их сопровождения.
Тестирование информационных систем
Несмотря на широкое распространение хакинга (здесь подразумевается программирование без проведения серьезного проектирования и тестирования) при разработке приложений, роль и значение тестирования весьма велики. Правильно поставленное тестирование является важнейшим механизмом обеспечения качества и стабильности программ. И решение «Проблемы 2000» лишний раз подтвердило эту истину.
Постоянно приходилось сталкиваться с непониманием необходимости направленного тестирования в соответствии с заранее разработанными сценарием и набором тестов. У многих велико было желание свести все к «генеральскому показу» правильного функционирования приложения. При разработке программ нередко тестирование и вовсе игнорировалось со ссылкой на нехватку времени.
На практике при тестировании ситуация часто выходила за узкие рамки «Проблемы 2000». Так, например, сокращенный ввод года в ошибочно вводимых датах в приложениях, написанных с использованием средств Microsoft, вызывал удивительные реакции:
Разъяснения, данные представителями корпорации, и ряд описаний функций свидетельствуют о том, что так и было задумано: при наличии дат, не удовлетворяющих формату ddmmyy, применяются форматы mmddyy или yymmdd. Мало того, и при полном формате наблюдались подобные «кульбиты»: 01.13.1999 -> 13.01.1999.
Строго говоря, все это не имеет отношения к «Проблеме 2000», однако соображения дела заставили запретить ввод дат в сокращенном формате и отдельно проверять допустимость месяца.
Всегда ли необходимо тщательное тестирование и как можно сократить его объем? Типовые случаи должны быть унифицированы и закреплены в функциях проверки (validation function) для коллективного использования во всех приложениях. Более сложные случаи должны быть описаны в требованиях к программам и тщательно проверены.
Комплексное и системное тестирование нацелены на проверку интерфейсов, имеют свои особенности, связанные с генерацией тестовых данных (обеспечение смесей значений и форматов), использованием производственной среды и восстановлением ее после испытаний. Проблема возврата «назад из будущего» была ключевой. И конечно же, задача сравнения результатов с неким (не всегда явным) эталоном доставила массу хлопот.
Нелишне сказать, что системное тестирование позволяет также выявить организационные и технологические недочеты при взаимодействии центрального офиса и филиалов.
Планирование действий в чрезвычайных обстоятельствах
Абсолютно новой для многих из нас явилась технология обеспечения работоспособности информационных систем в чрезвычайных и аварийных ситуациях путем планирования необходимых восстановительных мероприятий.
Разработка подобных планов выходит далеко за рамки «Проблемы 2000», но является неотъемлемой частью любой сложной корпоративной системы с критически важными приложениями. Планирование чрезвычайных обстоятельств позволило оценить критичность прикладных задач и систем, определить уязвимые места в плане надежности и безопасности.
Нужно отметить особенность «Плана чрезвычайных обстоятельств 2000 года»: он не в полной мере соответствует «Аварийному плану», создаваемому на случай разного рода природных и техногенных катастроф. При решении «Проблемы 2000» резервирование с помощью однотипных компонентов не имеет смысла, так как в них ошибки 2000 года вызовут ту же реакцию. Это обстоятельство нужно учитывать при разработке комплексных «планов чрезвычайных обстоятельств», куда должны войти оба типа резервных компонентов, используемых в зависимости от ситуации.
Важный аспект — согласованность «планов» центрального офиса и филиалов, а также информированность пользователей о планируемых мероприятиях в чрезвычайных обстоятельствах.
Одним из «сухих остатков» является решение о том, что «План чрезвычайных обстоятельств 2000 года», доработанный с учетом внешних аварийных ситуаций, разнесения обработки в пространстве и нужной степени «теплоты резерва», может стать комплексным «Аварийным планом».
Резервирование
Сутью любого «Аварийного плана» или «Плана чрезвычайных обстоятельств» является резервирование технологий и приложений с использованием альтернативных информационных ресурсов и средств.
В качестве альтернативных информационных ресурсов могут выступать оперативная БД и хранилище данных или промежуточный технологический архив при приеме информации. Специально для целей резервирования может регулярно создаваться реплика базы данных на удаленной площадке. В качестве альтернативного источника нормативно-справочной информации могут использоваться бумажные копии справочников.
Альтернативными средствами приема/передачи информации могут служить различные режимы обмена: терминальный доступ, удаленная пересылка файлов, электронная почта, Web, факс и телеграф, а также доставка дискет и лент курьером. Резервные режимы могут образовывать целые каскады средств.
Альтернативными средствами обработки являются инструментальные средства разработчика и конечного пользователя, а также ручные способы обработки.
Резервирование для критически важных приложений позволяет вполне легально установить в производственной среде инструментальные средства, которые, однако, могут использоваться только в заранее оговоренных аварийных ситуациях с временными правами доступа, предоставляемыми для устранения сбоев. Если это сделано, программисту не нужно будет украдкой выполнять многие профессиональные работы. А ведь это — обычная ситуация для организаций, в которых существуют жесткие ограничения на доступ разработчика в производственную среду.
Диспетчеризация и разрешение нештатных ситуаций
Это — другая важная составляющая любого «Аварийного плана» и практической эксплуатации систем. Необходимость фиксировать нештатные ситуации, знать текущее состояние и отслеживать разрешение конкретной нештатной ситуации требует диспетчеризации запросов. В больших корпорациях такая служба централизована, она выполняет еще и роль helpdesk — горячей линии для обслуживания пользователей и поддержки приложений. Кроме того, этой службе может быть доступна информация мониторинга, ей могут передаваться извещения о проблемах в системе.
Разрешение нештатных ситуаций остается в компетенции инженеров по эксплуатации, системных и прикладных администраторов, экспертов и служб поддержки и сопровождения. Задача диспетчера на этом этапе — обеспечить определенную последовательность диагностирования и локализации ситуации в различных компонентах. При этом важно «не потерять запрос», поддержать связь между специалистами. А в случае невозможности в заданное время устранить сбой или отказ осуществляется переход в резервный режим работы и/или извещение вышестоящего диспетчера о проблеме.
«Проблема 2000» заставила многих создать у себя подобные диспетчерские службы. Желательно этот опыт сохранить. Организация такой многоуровневой диспетчерской (оперативной) службы позволит успешно ликвидировать различные сложные нештатные ситуации в корпоративной информационной системе.
Итак, серьезный подход к решению проблемы 2000 года вооружил специалистов разных категорий неоценимым практическим опытом и дал результаты. Их необходимо использовать для повышения качества проектирования и эффективности работы информационных систем.