 |
|
|
|
Введение в системное программирование. Часть 1. Постановка задачи
Введение в системное программирование Автоматизация в информационных технологиях является синонимом программирования. В то же время круг обязанностей системного администратора при сложившихся обстоятельствах предусматривает больше ручных операций, чем автоматизированных. Почему так получилось? Кому это выгодно? Как это исправить? Деятельность системного администратора направлена на управление сложными информационными объектами. И хотя эти объекты являются в высшей степени алгоритмизированными, работа системного администратора зачастую не затронута автоматизацией ни на йоту. Это парадокс, когда в управлении высокотехнологическими системами используются такие неразвитые операции, как «открыл меню», «кликнул мышкой», «закрыл меню». Причем очень часто подобный подход насаждается специально, как основа разделения бизнес-решений и, как следствие, разделения доходов от деятельности. Попробуем обосновать иную парадигму системного администрирования. Для этого вспомним, что еще совсем недавно в отечественной практике системного администратора в силу бытового стереотипа называли системным программистом. Так ли уж сильно ошибались? Жизненный цикл информационного объекта Рассмотрим подробнее, чем занят сисадмин. Как уже было сказано, предмет деятельности системного администратора – это обслуживание информационных систем и их компонентов. Будем считать, что обязанности формируются по индуктивному принципу, и при обслуживании многокомпонентной системы сисадмин в отношении каждой её части применяет почти те же действия, что и ко всей системе в целом. То есть задача обслуживания большой сети состоит из набора операций по обслуживанию её компонентов. Безусловно, это весьма «смелое» предположение. В нем как минимум не учитывается закон перехода количества в качество. Но предлагаю на данном этапе обсуждения согласиться с такой версией построения вычислительных систем, так как это позволит сделать ряд необходимых обобщений и тем самым сосредоточиться на основных вопросах, оставив детали для дальнейшего развития темы. Другими словами, будем считать перечень операций для работы с сетью во многом подобым перечню операций для работы с самым маленьким сервером или даже рабочей станцией, потому что сеть образуется как совокупность серверов и рабочих станций. Меняются объем труда, перечень включаемых подзадач, но в целом деятельность по обслуживанию всех информационных объектов схожа настолько, что все персоналии, занятые таким трудом, делают примерно одно и то же. Собственно, именно это сходство позволяет именовать данную категорию наёмных рабочих системными администраторами. Таким образом, обсуждение операций по обслуживанию гипотетического сервера позволит сделать правильные выводы в отношении труда системного администратора в целом. Ограничив рассматриваемый объект пространственно, сведя все многообразие информационных систем к одному серверу, еще более упростим задачу и ограничим или, точнее, определим рассмотрение во времени – введем понятие жизненного цикла информационного объекта. В общем случае по отношению ко всему многообразию информационных объектов эта задача просто непосильная. Но так как теперь рассматривается только один сервер, то надо всего лишь согласиться с некоторой моделью его жизненного цикла. Грубо говоря, вот, его купили, настроили, долго-долго использовали и списали. В течение своего существования объект претерпевает разного рода трансформации, например изменения в результате старения электронных компонентов или изменения спецификации из-за обновления программного обеспечения. Но в данном случае рассмотрим степень усложнения внутреннего программного содержания сервера в процессе его подготовки к выполнению основной задачи. Здесь «сложностью» буду называть интуитивно ясную величину, пропорциональную числу настроенных программных компонентов информационного объекта. Согласно предположениям на верхнем графике рисунка изображена зависимость сложности от времени существования для типичного сервера: на начальном отрезке она повышается, пока не удовлетворит заданной спецификации, а потом не меняется существенно вплоть до завершения эксплуатационного периода.
Жизненный цикл информационного объекта На оси времени отмечены две важные в данном рассмотрении точки. Первая, время приобретения – начало жизненного цикла, и вторая, время завершения настройки, после чего, как предполагается, сервер эксплуатируется без существенных изменений до своего списания. Конечно, «без существенных изменений» является допущением, позволяющим сосредоточить внимание на периоде интенсивного роста сложности сервера в самом начале графика. То есть в общем случае возможны обновления и изменения в течение времени сопровождения, но здесь они рассматриваться не будут, так как не носят характера закономерности и потому не могут учитываться как систематический фактор. Кастомизация как предмет деятельности сисадмина Теперь представим начальный этап графика зависимости сложности от времени эксплуатации в увеличенном масштабе (средний график на рисунке). В этой проекции выделим условную точку, соответствующую этапу, когда произведена установка операционной системы с дистрибутивного носителя, но не произведено никаких дополнительных настроек кроме предусмотренных процедурой установки. Бывает, что серверы приобретаются вместе с предустановленной ОС, тогда будем считать, что первоначальный установочный этап для такого сервера построен ретроспективно. То есть все равно можно условно выделить некий нулевой момент времени, когда ОС на сервере не была установлена, и второй момент, когда системный администратор начал настройку согласно целевой спецификации. Это очень важная точка. С одной стороны, производители дистрибутивов стремятся сделать их максимально универсальными, значит, в процедуру установки ОС должно входить как можно меньше настроек, специфических для целевого применения платформы, что должно сужать первую зону. Но, с другой стороны, они стремятся увеличить потребительскую (и рыночную, конечно же) стоимость дистрибутива как завершенного продукта, для чего в процедуру установки включаются всевозможные средства, облегчающие целевую настройку системы, что приводит к расширению первой зоны. В данном рассмотрении зона диаграммы сложности, расположенная слева от точки установки ОС, полностью определяется свойствами дистрибутива, выбранного для сервера. А зона, расположенная справа, соответствует области компетенции системного администратора. Если согласиться с тем, что стоимость сервера как продукта пропорциональна его сложности, то получается, что точка установки ОС делит гонорар за готовый к использованию сервер межу производителем дистрибутива и сисадмином, производящим установку и настройку. Положение этой точки является результатом компромисса выбора подходящего дистрибутива. Не следует думать, что подобные рассуждения относятся только к «Миру» *NIX. Нет! Появление Windows Server Core доказало, что и в «Мире» Windows действуют те же законы. Точка окончания настройки и перехода к эксплуатации системы гипотетически может разграничивать зону ответственности подрядчика, настраивающего систему, и локального системного администратора, занятого её эксплуатацией. Но так как по роду деятельности и тот и другой занимаются настройками (не продажами) информационных систем, то можно утверждать, что начиная с момента установки все свойства информационного объекта полностью определяются системным администратором. Таким образом, актуальный жизненный цикл сервера делится временными точками установки ОС и завершения настройки на три периода, которые можно охарактеризовать по типу деятельности: установка, кастомизация и сопровождение. Эти три периода присущи всем информационным объектам от сверхдорогих кластерных систем до мобильных телефонов. Системный администратор может принимать участие во всех трех периодах жизненного цикла информационной системы, но только начиная с этапа кастомизации он ни с кем не делит ни ответственность, ни доходы от работы. Если в том же временном масштабе изобразить объем труда системного администратора в процессе жизненного цикла информационного объекта, то получится кривая, скорее всего, характерная гауссовой такая, что пик её придется на этап кастомизации, а нисходящие «плечи» – на этапы установки и сопровождения (нижний график на рисунке). Можно сказать, что именно кастомизация является основной и определяющей деятельностью сисадмина. Таким образом, согласившись с вышеприведенными рассуждениями, получаем очевидную цепочку логических заключений:
Теперь, когда предмет деятельности сисадмина полностью определен, настало время обсудить методы, которые используются для автоматизации работы системного администратора. Инструментальный подход Снова обратим внимание на три заключения из предыдущего раздела. Последнее из них является самым важным! Косвенно оно дает основания предположить, что методы и инструменты, используемые на этапе кастомизации, должны отличаться как от методов и инструментов, применяемых на этапе установки ОС, так и от тех, что будут использоваться в период штатной эксплуатации. Любое нарушение этого правила должно приводить к ухудшению свойств программ, используемых в целях автоматизации. Причина очень проста: разработчики недостаточно полно проанализировали требования области применения и пошли на недопустимые компромиссы. Иначе говоря, это ошибка постановщика задач. Вот, для сравнения. Установка ОС производится с помощью специальной программы, которая должна стартовать в ненастроенной системе, работать в условиях жестких ресурсных ограничений и быть рассчитанной только на самые общеупотребимые, массовые устройства. Все перечисленное приводит к тому, что программа начальной установки является весьма специфичной по характеристикам. Конечно, средство, отвечающее столь специфическим условиям, скорее всего не будет применяться во время регулярной работы, так как там можно использовать более удобные программы. Приведу пример. ОС семейства SUSE Linux устанавливается с помощью SUSE Installation Program, называемой linuxrc. После установки хоть сколько-нибудь работоспособной ОС эта программа далее не используется, и вся последующая настройка производится с помощью других средств. Таким образом, все в полном соответствии с предложенной концепцией. Аналогично и в семействе Red Hat – установщик ОС с дистрибутивных носителей Anaconda в кастомизации подсистем не участвует. Но, с другой стороны, как правило, средства администрирования эксплуатационного периода ничем не отличаются от тех, что используются на этапе кастомизации. Это верно как для семейства SUSE, тот же YaST, так и для Red Hat, утилиты категории system-config-* . Более того, это вообще типичная ситуация для большинства систем, включая и семейство Windows. Такое положение дел вполне объяснимо. Здесь опять сказывается недоработка постановщика задач или, точнее, элементарная лень. Зачем делать два программных продукта, если можно обойтись одним, так как технические условия исполнения позволяют, а возможности одного (инструментарий кастомизации) заведомо перекрывают возможности другого (инструментарий сопровождения)? Следствием такого подхода является избыточность систем, используемых в период сопровождения, что приводит к необоснованному усложнению и снижению надежности, например, реестр Windows, в котором можно обнаружить множественное дублирование значений полей. Или, наоборот, приводит к несовершенству систем кастомизации, требующих дополнительных, ручных действий, а также к снижению защиты «от дурака», допускающей некорректные настройки на этапе кастомизации. Например, последнее частично компенсируется использованием так называемых «мастеров», что характерно для Windows-систем. Еще хуже, если предлагается единая, «сквозная» система автоматизации настроек от установки до этапа сопровождения, как, например, Alterator в ALT Linux [1]. Причем дело даже не в том, что подобное невозможно. Нет, отчего же? Смотрите, ALT Linux – там все работает. Дело лишь в том, что такая система на каждом из этапов жизненного цикла будет или недостаточной, или избыточной, в зависимости от степени полноты её реализации. Большинство замечаний в адрес Alterator именно такого свойства: одних он не устраивает простотой, других пугает сложностью. Иначе говоря, подобную систему невозможно удачно специфицировать. Для того чтобы наглядно продемонстрировать спецификационные противоречия программ, обслуживающих каждый из этапов жизненного цикла, сведем их в единую сравнительную таблицу. В левой колонке перечислим выполняемые задачи, а в правых отметим соответствие их этапам жизненного цикла информационной системы. Сравнение решаемых задач на разных этапах жизненного цикла
Для удобства использован фоновый маркер. Единственная одноцветная полоса – это строка 4. Получается, что функция, которая равно необходима на всех этапах жизненного цикла – это «создание пользовательских учетных записей». Итак, рассуждая с позиции инструментального и функционального подхода, средства автоматизации, используемые на этапе кастомизации, отличаются собственным уникальным набором функций и, следовательно, должны создаваться строго с учетом сферы их применения. Нарушение этого правила является просчетом проектирования. Но это редко приводит к созданию проблем в силу того, что сами средства автоматизации очень часто несовершенны. Кроме того, в подавляющем большинстве случаев автоматизация подменяется своего рода «компьютерной механизацией». Механистический подход В настоящее время общепринятым является метод, когда каждая операция автоматизируется по отдельности. Это исторически сложившаяся практика. Любая сложная задача разбивается на составляющие её этапы так, чтобы одновременно упрощалось и понимание этой задачи, и уменьшалась работа по её автоматизации. Изначально человечество, ранее ставившее гораздо более скромные задачи, так приучилось решать вопросы механизации. Например, «выкопать яму» воспринималось как «воткнуть штык лопаты», «отломить пласт», «выкинуть», умноженные на объем ямы. Все понятно – заменяем штык лопаты на ковш экскаватора, и вот уже яма образуется после совсем ничтожного числа итераций. Или иначе, заменяем одну лопату на ротор и получаем траншеекопатель, который выполняет большее число циклов за то же самое время. Аналогично строится сейчас и автоматизация работы системного администратора. Каждая операция разбивается поэлементно, и затем все субоперации поочередно подвергаются автоматизации. Причем успех этого прямо пропорционален элементарности субоперации. Ведь чем она проще, тем легче её преобразовать в последовательность встроенных машинных операций. Вот тут-то и возникает со всей очевидностью ощущение тупиковости подобного метода! Автоматизация строится по тому же «землеройному», механистическому принципу. Например, сисадмин должен настроить некоторый сервис. В неавтоматизированном варианте придется вручную искать конфигурационные файлы, сверяться с документацией, проводить их настройку, «поднимать» сервис и проверять его работоспособность. Как решается вопрос автоматизацией в традиционном случае: создается некоторая графическая оснастка, которая освобождает сисадмина от поиска нужных файлов, от ручного синтаксического контроля, от проверки работоспособности... и все! Внесение нужных настроек остается ручной операцией! Она может быть максимально упрощена до единственного клика манипулятора мышь в зоне настройки, но, тем не менее, этот «клик» является ручной операцией by design. Конечно, выгода «налицо»! Представляете, теперь сисадмин может избавиться от консольных команд, включая самую ненавистную – «man сервис.conf». Великое достижение – ни капли иронии! Целью такой автоматизации является понижение уровня подготовки обслуживающего персонала. Вспомните, перевод кустарного производства на технологию машинной обработки привел к промышленной революции лишь потому, что позволил использовать на фабриках неквалифицированный труд пролетариев – бывших крестьян и одновременно привел к краху старой цеховой системы, основанной на контроле передачи навыков от мастера к ученикам. Но современное общество не является «компьютерно-аграрным», оно считается постиндустриальным. И вряд ли привлечение широких слоев населения к труду системных администраторов приведет к новой индустриальной или компьютерной революции. В этом нет необходимости, да и такое невозможно! Потому что многообразие виртуального мира уже сейчас значительно выше мира материального, и непрерывно растет. А, значит, система «сисадмин – информационный объект» уже сегодня не является симметричной, а в дальнейшем будет создаваться подавляющее соотношение числа информационных систем к числу системных администраторов, их обслуживающих. Хотя не исключаю, что в планы некоторых компаний [2] входит стратегия «один админ – один сервер». Но главная проблема даже не в этом. Внедрение графических систем автоматизации администрирования, основанных на изменении, а точнее, на упрощении интерфейса взаимодействия, приводит к увеличению уровня интерактивности информационного обмена и, одновременно, к снижению уровня вербальности, в процессе выполнения задач администрирования. Что, как следствие, заставляет менять подходы к дальнейшему развитию тех же систем автоматизации, поскольку затрудняет последующую формализацию. Почему так получается? Очень просто, символьный обмен заменяется манипуляциями компьютерных указателей, потому что так проще – двинул мышку, кликнул кнопку. А кажущаяся простота взаимодействия до некоторой степени скрывает действительную назойливость сильноинтерактивных сред. Проблемы выходят на поверхность лишь в случае, когда надо, например, установить ОС с дистрибутивного диска на несколько серверов и потом все их настроить. В традиционном подходе автоматизируется не более чем «раздача» дистрибутива, если все серверы связаны сетью, или если все они имеют одинаковое оборудование, то можно воспользоваться установочным шаблоном, например в autoyast или kickstart. Но при нарушении любого из условий, например, серверы изолированы от сети, или имеют несхожее оборудование, автоматизировать работу путем элементарного мультиплицирования уже невозможно. И это в отношении самого простого этапа – установки ОС! Если же речь заходит о кастомизации, то традиционный подход, основанный на подмене интерфейса, не только не дает существенных преимуществ, так как направлен не столько на ускорение или автоматизацию, сколько на увеличение удобств работы и снижение квалификации оператора, но и создает препятствия в дальнейшем развитии автоматизации путем программирования операций для мультипликации или агрегирования. Вот главная причина, почему раскрученные маркетингом графические интерфейсы оказываются столь неподходящими для решения задач администрирования. В доказательство этого можно привести бурный рост числа средств скриптового программирования операций администрирования на платформах Microsoft в последнее время. Таким образом, использование графических интерфейсов основывается на заранее заданных шаблонах формализации представления (элементах меню), и приводит к ограничению возможностей по дальнейшей формализации и не позволяет применить аналитико-синтетические методы для последующего развития автоматизации. Мысль эта не нова. В обобщенном, философском плане данный вопрос рассматривается в известной статье [3]. Там, правда, все сводится к тому, что «предупредительные» или «дружественные» программы очень часто оказываются в реальных ситуациях «глупыми» и «неуклюжими», в силу ограничения формальных моделей, заложенных в их основу. А вот командные интерфейсы, предоставляющие среду для создания собственных формальных моделей, напротив, демонстрируют примеры настоящей дружественной среды. Применительно к сфере автоматизации задач администрирования все выглядит точно так же. Развитые графические интерфейсы заставляют сисадмина воспринимать объект администрирования не ниже уровня формализации интерфейса и не выше, чем допускают те же элементы интерфейса, положенные в основу невербальной среды. Если элементы интерфейса не позволяют построить на своей основе полноценную систему описания всего спектра решаемых задач, то есть не являются языком программирования, то их применение может носить только вспомогательный характер. Данное правило уже неоднократно доказывалось в области решения задач обработки текстов, когда текстовые процессоры, будучи изначально чисто интерактивными, по мере своего развития оснащались не только макроязыками, но и полноценными языками программирования. Так должно произойти и в области автоматизации задач системного администрирования. Но здесь все проще, поскольку изначально задачи данного круга решались за счет консольных или поточных (неинтерактивных) по своему характеру средств и только в погоне за маркетинговыми целями стали решаться с помощью графических интерфейсов. Иначе говоря, быть может, настало время вернуться к ранее существовавшим методам администрирования? Постановка задачи Теперь уже можно сформулировать задачу построения средства автоматизации системного администрирования. Начну с того, что точно укажу назначение подобной системы: система автоматического администрирования должна решать задачи кастомизации в первую очередь. Именно на этом этапе её внедрение принесет максимальный эффект. Системы автоматизации сопровождения в большей своей части могут быть созданы путем простой редукции из систем кастомизации. Реальное положение дел таково, что существующие проекты автоматизации решают скорее задачи сопровождения, поскольку это проще (см. график трудоемкости на рисунке). Даже те проекты, что привычно анонсируются, например в [4], как администрирующие, тем не менее в большой части решают задачи мониторинга и сопровождения. Достаточно привести следующие два примера: Cfengine на сайте [5] определена как «autonomic maintenance system», что прямо указывает на назначение этой системы как системы сопровождения; а проект PIKT [6] сразу в титуле квалифицируется как «software for monitoring and configuring computer systems», причем мониторинг в первую очередь. Определить границу, где кончается кастомизация и начинается сопровождение, очень просто: лишь только регулярно и регламентно повторяемые функции администрирования могут составлять перечень обязанностей по сопровождению. Таким образом, ограничивается предел расширения функционала систем автоматического администрирования. Это происходит бесконфликтно и всем очевидным образом. А вот взаимоотношение системы автоматической кастомизации и средств первоначальной установки ОС, или платформы, следует считать более антагонистичными. Во-первых, они фактически конфликтуют за «нишу». Во-вторых, проникновение средств начального конфигурирования в системы кастомизации является атавизмом и ведет к проблемам. Одно из противоречий в том, что средства начального конфигурирования, как правило, создают настройки «с нуля», даже если они есть в установочном пакете, а вот кастомизирующие, и в том числе сопровождающие, не должны так делать категорически. Приведу пример: утилита SuSEconfig попала в инструментарий кастомизации «по-наследству» от системы установки. Она, ввиду её древнего происхождения и примитивного дизайна, не «способна» редактировать конфигурационные файлы, она их только может синтезировать из шаблонов. Столь «эгоистичное поведение» данной утилиты приводит к тому, что любые модификации файлов, обрабатываемых ею, должны обязательно предварительно синхронизироваться. В общем случае верно правило, заставляющее системных администраторов выбирать платформы с минимальными предустановками. Иначе говоря, все, что ранее было преимуществом, теперь стало помехой. И именно аскетичные платформы оказались самыми привлекательными с точки зрения процесса кастомизации. Благодаря этому дистрибутив Slackware, обладающий минимальными удобствами сразу «из коробки», успел послужить прототипом значительному числу основанных на нем практических решений. Другой дистрибутив, несущий в себе огромный потенциал для использования его в качестве превосходной кастомизационной платформы, это всем известный Gentoo! Созданием «тонких» серверных платформ озаботились также и разработчики из Microsoft, благодаря чему появился Windows Server Core. Собственную «тонкую» платформу «сделала» компания Oracle [7]. И совсем недавно эту идею снова «изобрела» компания Novell [8]. Таким образом, можно утверждать, что средства автоматической настройки, или кастомизации, должны включать в себя столько функций, заимствованных из процедуры установки, сколько окажется фактически возможным. И наоборот, средства первоначальной установки платформы должны быть максимально сокращены и создавать как можно более толерантную платформу для работы систем кастомизации. Другими словами: Gentoo – наше будущее! Поскольку назначение «от» и «до» определено, распишем функционал такой системы в первом приближении. Воспользуемся данными из таблицы. Итак, вот какого рода задачи должна выполнять система автоматической кастомизации:
Получилось 7 задач: 7 – простое число, 7 цветов радуги, 7 периодов в таблице Менделеева, 7 – ключевое число в закономерности Миллера [9], наконец, 7 – это число совершенства! Значит предположение о функционале автоматической системы администрирования сделано верно. Шутка, конечно! Тем не менее именно приведенный перечень функций во второй части статьи будет использован как отправная точка для создания вычислительной модели системы автоматической кастомизации.
|
Алексей Барабанов
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
