Мы не пишем программ, или почти не пишем. Мы живем за чужой счет. Мы — паразиты. Вы, наши дорогие коллеги, в тиши кабинетов, попутно печатаясь и защищаясь, создаете один из видов национального продукта — программное обеспечение. Мы же не создаем национальный продукт. Мы лишь пытаемся его хоть как-то использовать в тех вычислительных центрах, в которых мы работаем. Спору нет, вы научились делать надежное программное обеспечение, и мы знаем, чего вам это стоило. Мы, ведь, тоже читаем книги по технологиям программирования, хотя, значительно реже их пишем. Надежное программное обеспечение, то есть соответствующее документации — это уже хорошо. Hо нам этого мало. Этого достаточно там, где нас нет, например, на Луне, там, где программное обеспечение все делает "само", без участия человека. Надежное программирование — панацея от всех бед и там, где программное обеспечение работает независимо от предыстории (трансляторы, библиотеки стандартных программ), то есть, оно не создает и не поддерживает какие-то жизненно важные файлы. Там же, где программное обеспечение включено в одну систему обработки данных (сод) вместе с человеком, там, где поведение системы зависит от предыстории (операционные системы, банки данных, АСУ, например) там надежного программирования оказывается мало. Там уже нужна живучесть и жизнеспособность всей системы обработки данных, что, увы, выходит за рамки традиционного системного программирования. В последнее время вы всерьез занялись анализом качества программ и даже больших программных комплексов [1,8]. Hо если говорить о системах, которые я называю СОД, то этот анализ затрагивает в основном разработчиков ПО, пользователей ПО и тех, кто сопровождает ПО СОД. Вопросы же обслуживания не ПО, а всей СОД, как единого целого, остаются все еще без внимания. Потому-то мы и существуем, парасистемные программисты, приставленные денщиками то к генератору ввода, то к операционной системе, то к системе управления базами данных (СУБД), а то еще и к какой-нибудь АСУ "зарплата" или "подготовка кадров". Чаще всего одна такая система одним денщиком не обходится, а систем этих — великое множество. Hа каждом ВЦ они завязаны в иерархические системы. Hа нижнем их уровне находятся, как правило, операционные системы со своим обслуживающим персоналом и пользователями. Затем, выше, идут СУБД и системы, вроде "Rамы", "PPB", "JEC" и т. п. Со своим обслуживающим персоналом и пользователями. За ними идут всевозможные АСУ и сапр, естественно, со своими пользователями, а главное, с обслуживающим их персоналом. В общем, до безработицы нам, парасистемным программистам далеко. Вот такие системы, как правило, с участием людей (обслуживающего персонала и пользователей самой разной квалификации), допускающие, в основном, перерывы в функционировании на ремонт и восстановительные работы, но абсолютно не допускающие утери текущего состояния (в том числе, файлов или баз данных) я и хочу проанализировать. Проанализировать с точки зрения их жизнеспособности, с точки зрения их, если хотите, угодливости и понятливости, выносливости и живучести, честности и верности. Вы уже поняли, чего я хочу. Я хочу, что бы не я был лакеем при программном обеспечении системы обработки данных, а оно было лакеем при пользователе этой СОД. Как вы уже догадались из названия, этот анализ не претендует на научность. Он лишь представляет собой попытку на отдельных этюдах из жизни парасистемных программистов поставить проблемы. Решать же эти проблемы придется вам, решать настоящими, системными методами.
Как известно, первый кризис программного обеспечения (по) был связан с ненадежностью программ, причем, источником ненадежности являлись ошибки кодирования программ. Благодаря появлению дисциплин и даже технологии программирования наступил некоторый перелом на этом этапе борьбы человека со стихией. Hо несмотря на повышение надежности ПО (в смысле адекватности кодирования), человекомашинные системы обработки данных внедряются очень медленно. Более того, уже создано большое количество СОД и продолжается создание новых систем, которые никогда внедрены не будут. Сидя у очередного разбитого корыта, изготовители таких систем обвиняют во всех бедах, как правило, внешнюю по отношению к их системе среду, начиная от пользователей системы, которые "сами не знают, чего хотят", и кончая низкой квалификацией и дефицитностью обслуживающего сод персонала. Между тем, создатели СОД, знают они это или нет, являются прежде всего математиками. Если на проблему посмотреть с этой точки зрения, то вышеприведенные оправдания, это оправдания математика, который для исследования некоторого явления природы выбрал неадекватную модель и теперь ее, эту модель, пытается в чем-то обвинять. Да, каждая программа, входящая в программное обеспечение СОД (ПО СОД) может соответствовать своему описанию и не содержать ни одной ошибки, но всю систему это не спасет, если математическая модель той среды, в которой по СОД должно функционировать, плоха. Попробуем же проанализировать подобного рода ошибки с целью найти закономерности в их возникновении, и попробуем сформулировать требования к СОД, которые позволят ей освободиться от указанных выше недостатков. Попробуем, также, дать рекомендации пользователям СОД, как по внешним признакам оценить СОД с точки зрения внедряемости. Итак, первый кризис программного обеспечения родил технологию программирования, второй кризис программного обеспечения, являющийся частью кризиса идеологии систем обработки данных, должен родить новую идеологию, а точнее, технологию систем обработки данных [2]. Рассматриваемые проблемы могут показаться несущественными тем, кто чуть ли не единолично пользуется и сам же обслуживает собственую СОД (например, собственный файл с исходными текстами). Другое дело, когда несколько десятков людей в вцкп круглосуточно эксплуатируют СОД, результатами работы которой пользуются другие несколько десятков, а то и сотен людей, не имеющих понятия о принципах работы вцкп, в то время, как третий коллектив перманентно изменяет программное обеспечение и документацию этой СОД. Тогда уже методы и средства организации работы такой СОД выходят за рамки отдельных программ и даже ППП. Здесь впору задуматься архитекторам вычислительных систем. Приведенные ниже примеры, если это не оговорено особо, относятся прежде всего к ПО, разработанному в рамках операционной системы ОС ЕС ЭВМ, однако, они не загромождены спецификой этой ОС, а выводимые закономерности носят общий характер.
Разработчики некоторых систем обработки данных, видимо, работают в идеальных условиях. В тех вычислительных центрах (вц), в которых они изготавливают свои системы, никогда не бывает сбоев и отказов оборудования. Поэтому, они никогда не заглядывали в документацию по аппаратным средствам, в которой указаны те или иные вероятностные характеристики сбоев и отказов. Hу, а если какой-либо сбой все же доставит некоторую неприятность, то виноваты, конечно же, неграмотные и ленивые электронщики. Видимо, те вц, где электронщики столь же плохи, просто недостойны такой замечательной системы. Hу, а в целом, дела идут хорошо. Ведь контрольный пример проходит так быстро, а выполнить правильно его нужно всего лишь один раз… Если передо мной лежит документация на некоторую программную систему, входящую в состав СОД, и в ней нет ни слова о реакции этой системы на те или иные сбои, то я или отказываюсь сразу же от такой системы, либо выясняю возможность доработки и планирую ее. Примерами таких систем являются генераторы ввода [3,4], которые могут применяться лишь там, где они, в общем-то, и не нужны, там где вводится за один прием столь мало данных, что вероятность сбоя невелика.
Этюд.
Ппп "оргвыц" [6] накапливает данные о работе вц в наборах данных на магнитных дисках. По мере их заполнения данные из этих наборов копируются на мл. Ппп услужливо предоставляет в распоряжение пользователя процедуру дозаписи в конец МЛ после ранее записанных во время предыдущей работы данных. При этом не предлагается ни одна процедура, которую должен выполнить пользователь после того, как эта мл, наконец, перестанет читаться или записываться во время дозаписи.
Любопытно, что чем надежнее работает оборудование в вц, использующем такой ППП, тем больший удар ожидает пользователя, когда сбой произойдет, и он потеряет все то, что так долго собирал. Возможно, я не объективен по отношению к разработчикам ППП "оргвыц". Что говорить о них, если даже в книге дж. Мартина [7] проблемам организации баз данных посвященно 660 страниц, а проблемам, связанным с аппаратной надежностью и живучестью (целостностью) баз данных, говорится на 14 строках 45-й страницы и 8-ми строках 309-й. Десять страниц этой книги посвящены индексно-последовательным наборам данных, а о проблемах, связанных с их целостностью, не говорится ни слова.
Вот пример того, как возникают иллюзии. В документации по ОС ЕС написано, что добавление записи по ключу в индексно-последовательный набор данных равносильно для программиста добавлению этой записи на свое место в физической последовательности. Действительно, равносильно, но лишь в том случае если эта операция успешно завершилась. Более того, у меня есть подозрения, что даже и этого мало. В некоторых случаях необходимо еще, чтобы успешно завершилась операция закрытия набора данных. Если какое-то из этих условий не выполнено, то либо весь набор данных, либо некоторая его часть окажутся недоступными для последующего чтения. Если программист пишет программу, которая сама такой набор данных создает, сама его после создания корректирует, а по окончании этой программы набор уже не нужен, то программисту достаточно поверить написанному о том, как просто корректировать индексно-последовательные наборы данных. Если же такой набор данных создается для многократного использования, может быть, в течение нескольких лет после его создания, то разработчику сод, использующей этот набор данных, следовало бы знать, что такая простая с точки зрения написания программы операция, как добавление записи по ключу в индексно-последовательный набор данных представляет собой несколько операций записи в этот набор данных, разнесенных во времени и пространстве (занимаемом этим набором). Окончательная же фиксация изменений происходит по закрытию набора данных. Что прикажете делать пользователю СОД, разработчик которой по своей простоте не подумал о возможности сбоя и не предоставил пользователю никаких средств борьбы с ней? Примером может послужить все тот же ППП "оргвыц". Еще пример доверия к печатному слову: в паспорте на устройство вывода на перфоленту написано, что это устройство обеспечивает так мало сбоев, что на пять тысяч метров перфоленты приходится всего одна неправильная пробивка [5]. Очень трудно позавидовать пользователю СОД, разработчик которой прочел указанный документ и поверил ему. Вместо так нужной ему перфоленты он получит возможность участвовать в многочисленных склоках с обслуживающим персоналом, размахивая вышеуказанным паспортом, который в отличие от волшебной палочки перфоленту не сотворит. Возможно, что пользователь будет писать рекламации на завод-изготовитель ЭВМ, перфоратора или перфоленты. В любом случае, если только ему на самом деле нужна перфолента и он лишен садистских наклонностей, он вряд-ли будет в большом восторге от такой СОД. Хорошо еще, если он поймет, что собака зарыта прежде всего в программном обеспечении, которое не ломается, которое не надо чинить и которое сделать надежным значительно легче, чем перфоратор.
Рассмотрим последний пример подробнее, чтобы определить, как должна быть построена программа вывода перфоленты, если она должна выводить ее действительно много (по сравнению с реальной наработкой на сбой). Более того, как она должна работать, даже если сбои в среднем достаточно редки (настолько редки, что после сбоя при повторном пуске программы перфолента скорее всего не будет содержать ошибок). Для построения такой программы нужно учесть следующие соображения. Первое. По-прежнему действует закон "чем лучше — тем хуже". Если возможность сбоя не принимается во внимание, то чем позже он произойдет, тем более потрясающий эффект он произведет среди тех, кто так верил этой системе. Поэтому, если вероятность сбоя в течение некоторого промежутка времени больше вероятности того, что ВЦ сгорит дотла (за тот же промежуток времени). То программа должна его учитывать. Прежде всего, она должна позаботиться о том, чтобы пользователь получил заведомо правильные результаты (с указанной выше вероятностью), либо не получил их вообще. Второе. Пользователя скорее всего не устроит неполучение результатов вообще, хотя это уже лучше, чем получение возможно неправильных результатов. Хорошая программа вывода перфоленты должна либо выдать правильный результат, либо обеспечить возможность ремонта сбоящего устройства (принцип "встроенного теста"). Встроенный тест нужен тогда, когда устройство сломалось еще не настолько, что уже известно, как его чинить (нет явного отказа, а есть пакет сбоев). Действительно, допустим, что частота сбоев превысила указанную в паспорте величину на пол-порядка. "Юридически" устройство сломано (какой ценой обычно доказывается факт такой "полусломанности"!). Hо если обслуживающий персонал будет вынужден его чинить, то он должен будет в течение длительного времени "гонять" на устройстве бесполезные с точки зрения пользователя тесты, занимая не только это устройство, а скорее всего, всю ЭВМ, изводя впустую уйму машинного и рабочего времени и перфоленты. Хорошо еще, если такие тесты существуют. Каждый бит драгоценной для обслуживающего персонала информации будет оплачиваться сотнями килобайт информации, бесполезной для пользователя СОД. Так пусть уж лучше вместо теста работает программа этой СОД. Тогда она, выдавая результат, заодно еще даст информацию о сбоях. Третье. Чтобы результатом, полученным в условиях сбоя можно было пользоваться, программа должна локализовать сбой и принять меры к восстановлению корректности результата. Возможно, ведя диалог с оператором ЭВМ и разбивая всю перфоленту на контролируемые и повторяемые в случае сбоя участки. Для контроля результата она должна использовать устройство ввода перфоленты. Четвертое. Ценность встроенного теста заключена еще и в том, что другие тесты могут не вызывать сбой в устройстве, так как они тестируют устройство в режиме, отличном, от режима его использования.
Этюд.
Hа одном ВЦ купили две ЭВМ единой системы и стали постепенно загружать их работой в пакетном режиме в среде ОС ЕС, с общим полем памяти прямого доступа на восьми дисководах (по 29 мегабайт). Сначала объем данных на устройствах прямого доступа был невелик, и сбои на дисках особенно не докучали. Hо по мере наращивания объема данных работать становилось все труднее и труднее, пока ВЦ не подошел к некоторому "информационному барьеру". Стало ясно, что необходимо менять технологию настройки дисководов на взаимозаменяемость. Электронщики, обслуживающие дисководы, заявили, что тесты проверки взаимозаменяемости у них идут. В свою очередь, системные программисты, представили богатый материал, из которого следовало, что при работе с ОС ес взаимозаменяемость отсутствует. Теперь, как это обычно принято в других вц, можно было и подраться.
Hо в этом вц обычно делали по другому. Электронщики и системщики вместе стали разбираться, в чем заключается разница в подходе к взаимозаменяемости у тестового обеспечения и у ОС ЕС. Для выяснения этого вопроса системщикам пришлось отложить бесполезные в этом случае книги по управлению данными ОС ес и взяться за "чужие" для большинства системщиков книги по тестовому программному обеспечению и даже по аппаратуре, благо в этом благородном порыве электронщики помогали системщикам всей душой. Обнаружилось, что электронщики пользовались следующим определением взаимозаменяемости: для любых целых I и K, не больших N, где N — количество дисководов, инициализация на I-том дисководе, запись на I-том же дисководе и чтение на K-том должны закончиться без сбоев с некоторой, близкой к единице вероятностью. Системщики (точнее, те системщики, которые разработали ос ес), понимали под взаимозаменяемостью следующее: для любых целых I, J и K, не больших N, инициализация на I-том, запись на J-том и чтение на K-том дисководах должны закончиться без сбоев с все той же, близкой к единице, вероятностью.
