Текст книги "Тайм-менеджмент для системных администраторов"

Автор книги: Томас Лимончелли

сообщить о нарушении

Текущая страница: 13 (всего у книги 16 страниц)

Черт возьми, моя стратегия в том, чтобы заполучить побольше подчиненных. Я документирую все ненавистные мне процедуры, которые я поручил бы помощнику, если бы он у меня имелся. Как только фирма снова станет набирать персонал, я предложу руководству список обязанностей моего возможного помощника: создание новых учетных записей, замена лент для резервного копирования, обычные проблемы принтера и т. д. Как здорово, что все эти дела хорошо задокументированы и их можно передать другому!

Персонал набирают нечасто, но это нестрашно. Мне не нужен штатный сотрудник. Как только возьмут кого-нибудь для обслуживания системы в отделе разработки ПО, тут я и подсуну свою веб-страницу с процедурами и задачами, которые можно на него повесить. Вот такой я мерзкий тип!

Схемы сети

И наконец, хранилище должно содержать схему сети. Если таковая имеется, разместите ссылку на нее. Если нет, нарисуйте сперва простую картину вашей локальной сети с главными серверами. Изобразите что-то вроде облака, обозначающего все настольные компьютеры и ноутбуки. В одной фирме, где я работал, мне приходилось периодически рисовать на доске схему сети, чтобы показать местоположение своего компьютера. (Схема состояла из четырех точек, обозначающих наши сайты, пяти соединительных линий глобальной сети и стрелки к облачку, обозначающему интернет-соединение.) Добавление этой простой схемы в информационное хранилище было хорошей отправной точкой. Вам хватит десяти минут, чтобы нарисовать приблизительный вариант схемы и разместить его на веб-странице.

Самые пылкие сисадмины, вероятно, будут настаивать на схеме, нарисованной в программе Visio, с реалистичными пиктограммами серверов, расположение которых должно быть показано с точностью до миллиметра, но это как мышеловка. Вам не случалось, засев за рисование какой-то схемы, вдруг обнаружить, что весь день ушел только на то, чтобы довести ее до совершенства? В этой мышеловке нет сыра! Потратьте 10 минут, а не 10 часов. Я предпочитаю инструменты, не предназначенные для детализации, что вынуждает меня ограничиваться лишь общей схемой, не увязая в деталях. Как правило, я создаю схемы в PowerPoint и заношу в хранилище оригинал и его PDF-копию.

Если вы вправду не в состоянии противиться желанию создать идеальную схему, начертите ее на доске, сфотографируйте цифровой мыльницей и поместите в хранилище фото. Это быстро и действительно хорошо работает. (Если кто-то заявит, что схему надо перерисовать в профессиональном графическом пакете, обеспечьте ему доступ на запись в хранилище и скажите: «С нетерпением жду Ваших результатов».)

Кроме того, вам следует задокументировать важные информационные потоки внутри вашей фирмы: процесс приема и отправки электронной почты, расположение серверов службы каталогов и т. д.

Технология Wiki

Чтобы создать веб-сайт (хранилище информации) с легко обновляемыми страницами, воспользуйтесь технологией Wiki. Строго говоря, Wiki – это концепция, а не конкретный программный пакет. Есть много программных пакетов, предлагающих пользователю функциональность Wiki. Есть и оригинальное приложение Wiki (в переводе с гавайского – «быстрый»), но также есть TWiki, KwikiKwiki, PHPWiki и т. д. Просто замечательно, что многие разработчики создают программные системы, которыми вы можете пользоваться.

♥ Я не применял технологию Wiki из-за глупого названия. Я думал: «Ни за что не буду пользоваться системой с таким дурацким названием, даже если она превращает свинец в золото». Я даже не пытался выяснить, что это такое. Три года спустя, начав работать с Wiki-приложением, которое установил другой сотрудник, я обнаружил, что моя производительность заметно повысилась. Как же я пожалел, что так долго игнорировал Wiki!

Так что же такое Wiki? Это веб-сайт, на котором любой посетитель может редактировать любую страницу, а установка ссылок на страницы чрезвычайно проста.

Не безумие ли это? В смысле, если любой посетитель может редактировать любую страницу, как быть с вандализмом? Кто-то может зайти на него, все удалить, занести в систему неверную информацию и т. д. Это будет катастрофа!

Не беспокойтесь, есть функциональные возможности, полностью исключающие подобные проблемы. Давайте сначала рассмотрим положительные стороны:

• Легко добавлять новые страницы. Любой посетитель может добавлять новые страницы. Если младший системный администратор заключит контракт с новым производителем, он легко добавит страницу, касающуюся этого производителя, разместит на ней первичную контактную информацию и т. д.

• Wiki-сайты централизованны и доступны. Любой пользователь может получить доступ к ним с помощью веб-броузера (если все его элементы управления на месте). На клиентской стороне не нужно никакого специального программного обеспечения.

• Каждый может внести свой вклад. Любой посетитель сайта может отредактировать любую страницу, если заметит опечатку или владеет дополнительной информацией. Документ может появиться на свет в виде небольшого маркированного списка, потом кто-нибудь добавит в него новые пункты, а затем кто-то еще превратит документ в полноценное описание процедуры.

• Wiki-страницы отражают текущую ситуацию. Когда добавляются новые страницы, снимается одна из самых больших проблем, связанных с документированием, состоящая в том, что документы нередко устаревают до момента опубликования. Wiki – это набор страниц, которые может немедленно обновить тот, кто обнаружил устаревшую информацию.

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

Wiki-нотация и ссылки на страницы

Wiki ослабляет все эти препятствия. Вам не нужно проходить специальный курс обучения этой технологии, знание HTML тоже не требуется. Вам не нужна учетная запись для чтения документов. Если у вас нет учетной записи, а вы хотите отредактировать документ, то тут же получаете возможность создать ее. Учетные записи создаются с таким уровнем доступа по умолчанию, что пользователи могут выполнять большинство базовых операций. Самое приятное, что, хотя пользователи могут писать на чистом HTML, есть так называемая Wiki-нотация, позволяющая им вводить простой текст, который Wiki затем отформатирует. Например, Wiki понимает, что слова, окруженные звездочками, символами подчеркивания или иными, должны быть как-то отформатированы. Если вы введете *такой текст*, то на экране появится такой текст. А если -такой текст-, то на экране появится такой текст. Если вы создадите список, каждая строчка которого начинается со звездочки, Wiki преобразует эти строчки в маркированный HTML-список с тегами

. Большинство людей быстро осваивает эту кодировку, поскольку уже пользуется ею в электронной почте, а если кто не пользуется, то справочной информации по форматированию в Сети предостаточно.

Создание ссылок на Wiki тоже не составляет труда. Если вставить во вводимый текст URL-адрес, Wiki превратит его в ссылку. Установка ссылок на другие Wiki-страницы проходит еще забавнее. У Wiki-страниц есть имена, имеющие специальный формат WikiWord. Программистам, работающим на Perl, он известен как CamelCase или Studly-Caps. Имя представляет собой слово, содержащее буквы как в верхнем, так и в нижнем регистре. Например, страницу можно назвать СписокПолезныхВещей Каждый раз, когда вы используете в тексте это имя, Wiki превращает его в ссылку на страницу, даже если страницы с таким именем нет. В последнем случае щелчок по ссылке позволит пользователю создать страницу с этим именем. Иными словами, чтобы создать новую страницу, создайте ссылку, щелкните по ней и приступайте к редактированию.

Размещать документы на Wiki-сайте тоже очень просто. Документ присоединяется к странице. Таким образом, любая страница может стать контейнером для документов в формате PDF, Word и др. Однажды мне поручили организовать хранение документов Microsoft Word для сотрудников, не разбирающихся в технике. Я создал Wiki-страницу, назвал ее ТекущийПроект и показал им, как присоединять к ней документы. Wiki автоматически выводит таблицу присоединенных файлов. Может, кто и не осилит Wiki-нотацию, но уж присоединить документ к странице все в состоянии. Возникает разделение труда: специалисты создают Wiki-страницы и структуру хранилища, а те, кто далек от техники, присоединяют страницы. По мере привыкания к технологии Wiki эти пользователи смогут освоить и более сложные задачи.

Предотвращение Wiki-вандализма

Для Wiki-страниц есть комплекс социальных и технических средств, гарантирующий, что вандалы и злоумышленники не разрушат хранилище информации.

Во-первых, есть простой общественный контроль: каждое изменение регистрируется в журнале с указанием автора изменений. Удивительно эффективный метод! Полагаю, факт регистрации автора на 90 % удерживает пользователей от внесения безответственных исправлений. Это тем более справедливо в корпоративных условиях.

Есть и технические средства борьбы с вандализмом. Все Wiki-страницы хранятся в системах, подобных RCS, CVS, Subversion или Microsoft SourceSafe. Это обеспечивает практически бесконечные возможности отката. Вы без труда отмените исправления или сравните две версии страницы для контроля изменений. Когда последствия вандализма легко устранимы, сам акт нередко теряет привлекательность в глазах хулигана. Если бы аэрозольная краска смывалась дождем, не было бы элемента азарта в том, чтобы написать на эстакаде «Фрэнсин любит Харви».

В большинстве Wiki-систем есть контроль доступа. Для каждой страницы или группы страниц можно установить, кто может их читать, редактировать или переименовывать. По умолчанию каждый посетитель может отредактировать любую страницу, в чем и заключается «принцип Wiki». Однако вы скорее предпочтете, чтобы главная страница, меню и некоторые другие страницы были доступны для редактирования ограниченному кругу пользователей.

Пуристы Wiki заявляют, что подобный контроль доступа не нужен, потому что в том-то и прелесть Wiki-культуры, что как вандалу несложно испортить страницу, так и кому-то еще несложно тут же восстановить ее. Это правда, но я лучше сплю ночью, зная, что страницу с номером телефона моей службы технической поддержки вправе отредактировать только один человек – я сам. В Wiki-культуре фраза «Wiki с ориентацией на бизнес» равносильна фразе «Wiki с контролем доступа».

Завершающим ударом против вандализма в Wiki является уведомление по электронной почте. Большинство Wiki-систем могут отправлять уведомления по электронной почте при любом изменении страницы. Обычно такое уведомление содержит информацию о том, что было изменено (HTML-отчет о различиях), и вы можете быстро определить, было ли изменение благотворным или вредоносным. Некоторые Wiki-системы по умолчанию извещают веб-мастера о любом изменении. Пожалуй, это превышение необходимой самообороны.

♠ Хотя стремление задокументировать абсолютно все можно понять, ни в коем случае не указывайте пароли на веб-странице. Не стоит рисковать, даже если она защищена паролем и находится на безопасном сервере. Например, однажды я обнаружил сайт, который его владельцы считали безопасным, потому что пароли хранились на странице, защищенной паролем и доступной только через SSL-соединение. Однако пользователи с учетными записями shell-account могли войти в систему и просматривать файлы напрямую. Поскольку это был основной сервер подразделения, такие учетные записи были у всех.

Система Wiki, с которой я больше всего работал, называется TWiki (http://www.twiki.org). Ее основным достоинством является управление доступом на добавление. Есть и другие системы – от чрезвычайно простых (одна из них написана на языке awk) до полнофункциональных. Некоторые крупные системы включают в себя технологию Wiki как одну из функциональных возможностей, другие целиком построены на концепции Wiki, например изумительная всеобъемлющая энциклопедия с открытым доступом – Wikipedia (http://www.wikipedia.org).

Резюме

• Хранилище документов – прекрасный инструмент тайм-менеджмента.

• Хранилище, ориентированное на клиентов, предоставляет им необходимую информацию, и они меньше беспокоят вас.

• Хранилище для внутренней ИТ-информации позволяет вам организовать справочный материал для экономии времени впоследствии. Особенно полезными могут оказаться технологические карты – короткие заметки о том, как следует выполнять сложные процедуры, – вашим коллегам не придется изобретать велосипед.

• Хорошо задокументированную процедуру легче делегировать другому сотруднику. Это позволит вам вычеркнуть пункт из своего списка дел, поручив эту процедуру кому-то другому.

• Технология Wiki облегчает доступ к хранилищу и не требует знания HTML. Позволив всем пользователям редактировать (почти) все страницы, вы добьетесь того, что страницы будут содержать самую свежую информацию.

• Создавать хранилище документов для группы системного администрирования не так страшно, как может показаться. Выбирая, что именно документировать, вы управляете масштабом хранилища. Приведенные в этой главе образцы помогут вам в начинании. Технология Wiki позволяет документам динамически расти и развиваться.

• Часто бывает трудно составить новый документ. Технология Wiki облегчает задачу разработки нового документа, создавая для вас все ссылки. Первоначальный документ может быть простой технологической картой, которая впоследствии будет дополняться. Вам совсем не обязательно с самого начала создавать безупречный документ. Напишите то, что важно в данный момент, и позвольте документу развиваться.

Личное хранилище информации

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

Часть информации я держу в хранилище Subversion. Подобно CVS и Microsoft SourceSafe, технология Subversion позволяет мне читать и обновлять информацию в хранилище из любой точки сети. Технология Subversion часто применяется для хранения исходного кода и отслеживания изменений. Теоретически, где бы я ни находился, я могу либо загрузить последнюю версию хранилища, либо обратиться через SSH к компьютеру, у которого есть связь с хранилищем. В личном хранилище я держу очень большую адресную книгу и некоторую другую информацию.

13

Автоматизация

Автоматизация наших задач – отдельное удовольствие. В какой еще профессии можно запрограммировать машины, чтобы они делали за нас нашу работу? Ах, если бы это было так просто! Автоматизация задачи требует времени, но выигрыш может быть огромным.

Я не собираюсь здесь давать уроки Perl, Python, Ruby, UNIX shell, VBasic или Kix32. В этой главе я расскажу зачем, что и как следует автоматизировать. Кроме того, я приведу фрагменты кода, которые помогают мне в работе уже много лет.

Достоинство автоматизации очевидно. Она сокращает нам объем работы, потому что автоматизированная задача требует от нас меньше внимания и времени или, благодаря «хрону» (cron) UNIX или планировщику Windows, выполняется автоматически, без нашего участия. Неожиданным положительным эффектом автоматизации является простота делегирования автоматизированной задачи. Любая задача, которую вы переложили на кого-то другого, уже является маленькой победой.

Достаточно ли автоматизирована ваша работа?

Адам Московиц (Adam Moskowitz), известный сисадмин, сказал мне, что для него «лакмусовой бумажкой» уровня автоматизации является возможность поручить работу менее квалифицированному сотруднику. Например, в одной фирме он автоматизировал задачу ежедневного резервного копирования диска до такой степени, что замену ленты могла выполнить секретарша. Каждый день система отправляла ей и Адаму электронное сообщение с отчетом о статусе резервного копирования, проведенного предыдущей ночью. Как правило, в сообщении содержались указания, какую ленту следует заменить. Если происходил какой-то сбой, секретарша знала, что ничего не следует предпринимать, пока Адам не устранит проблему сам. Со временем он усовершенствовал процедуру так, что система автоматически справлялась со все большим количеством аварийных ситуаций. В конце концов он добился, что система могла работать без его вмешательства месяцами.

В этой главе терминами «сценарий» и «программа» я буду обозначать разные понятия. Сценарий – это короткая программа, возможно всего из нескольких строк. Типичным сценарием является ВАТ-файл, несколько строк на языке Perl или небольшой shell-файл UNIX. Программой я буду называть более длинные программы, разработка которых требует обдумывания и планирования. Как правило, формальный процесс создания программы включает сбор требований, разработку и тестирование. Программы обычно пишутся на компилируемых языках, таких как C++. Интерпретируемые языки, вроде Perl, тоже подходят для создания больших программ, но используются реже. Программисты, пишущие на языке Perl, называют свой код сценарием, если он невелик, и программой, если код имеет значительный объем.



Что автоматизировать?

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

• Простые задачи, выполняемые один раз. К первой категории относится большая часть вашей повседневной работы. Если задача проста и вы выполняете ее один раз, нет смысла ее автоматизировать. На автоматизацию уйдет больше времени, чем на саму задачу.

• Сложные задачи, выполняемые один раз. Вторая категория включает задачи, достаточно сложные, чтобы выполнить их с первой попытки, поэтому, оформив последнюю (работающую) последовательность команд в виде сценария, вы получите инструкцию для ее следующего выполнения. Если вам понадобилось сделать что-то один раз, когда-нибудь придется делать это еще. Задачи этой категории состоят из длинных последовательностей команд, причем каждую команду лучше тестировать отдельно, постепенно строя цепочку из работающих команд. После этого вы сможете использовать эту последовательность с уверенностью, что она работает.

• Простые задачи, выполняемые часто. Третья категория – очевидный случай, здесь отдача от автоматизации будет максимальной. Время, потраченное вами на автоматизацию процедуры, вскоре окупится, потому что вы будете выполнять задачу снова и снова. Всегда автоматизируйте скучные и повторяющиеся дела.

• Сложные задачи, выполняемые часто. Четвертая категория – ловушка для системных администраторов, которые часто взваливают на себя больше, чем могут нести. Эта категория требует, чтобы вы убедили руководство в необходимости выделить ресурсы (время и деньги) на решение проблемы. Результатом может быть покупка коммерческого программного продукта, интеграция бесплатных инструментов и/или инструментов с открытым кодом в вашу систему или разработка собственного решения.

Теперь, специально для читателей, мыслящих зрительными образами, приведу эти категории в виде таблицы (рис. 13.1).



Рис. 13.1. Категории задач системного администрирования

Многие удивляются, узнав, что я автоматизирую простые, но часто выполняемые задачи. Если задача проста, зачем ее автоматизировать? Я автоматизирую многие процессы из второй и третьей категории – от крупных задач до небольших последовательностей команд – по одной причине. Автоматизация процесса придает ему повторяемость и масштабируемость, гарантируя выполнение без ошибок:

• Повторяемость означает, что я могу многократно выполнять этот процесс. Например, устанавливая новые компьютеры, я хочу, чтобы все они запускались с одной конфигурацией программного обеспечения и с одинаковыми настройками. В противном случае обслуживание этих компьютеров превратится в кошмар. Если я автоматизирую процесс установки, он станет повторяемым, и все компьютеры будут иметь одинаковую конфигурацию. Если у меня какой-то процесс работает, я хочу, чтобы он каждый раз работал одинаково.

 Автоматизация избавляет меня от необходимости запоминать редко выполняемые сложные процессы. Иногда очень много времени уходит на выяснение опций командной строки, необходимых для выполнения поставленной задачи. Я превращаю в сценарий даже одиночную команду, чтобы через несколько месяцев мне не пришлось изобретать велосипед. Это, так сказать, долгосрочная повторяемость. Например, в Mac OS X я могу «прожечь» ISO-образ диска на CD-ROM с помощью команды hdutil. Однако вместо того чтобы читать руководство всякий раз, когда мне нужно вспомнить, какие опции подходят лучше всего, я инкапсулировал эту команду в сценарий. Теперь я всегда смогу использовать текст сценария для справки, даже не запуская его.

• Масштабируемость. Это качество означает, что я смогу выполнить процесс независимо от того, как разрастется моя сеть. Автоматизировав процесс один раз, я смогу запускать сценарий на всех компьютерах, распространяя свое умение на все узлы сети. Например, очень легко изменить настройку конкретного SSH-сервера. Несколько секунд работы в текстовом редакторе, и файл sshd_config изменен. Однако если автоматизировать этот процесс, то я смогу запустить его на сотнях компьютеров, возможно, оставив его выполняться ночью. Мне не нужно будет присутствовать при его выполнении и волноваться о том, на скольких компьютерах он работает – на 10 или 10 000.

• Автоматизация помогает избежать опечаток. Многие команды трудно ввести с клавиатуры без ошибок. Например, ту короткую последовательность команд, которую я постоянно использую. В нескольких строчках мне приходится трижды вводить имя пользователя и дважды – его учетный номер. Все это несложно набрать на клавиатуре, но довольно просто допустить опечатку. Превратив эту задачу в сценарий, я исключаю опечатки. Даже если надо ввести лишь несколько строк, имеет смысл создать сценарий.

Процесс автоматизации

Чтобы что-то автоматизировать, сначала следует выполнить это вручную. Затем нужно написать код для каждого шага. После этого вы должны собрать эти фрагменты кода воедино, тестируя каждое добавление. В завершение необходимо протестировать всю систему.

Шаг 1: выполнение процесса вручную

Первый шаг при автоматизации процесса состоит в обязательном выполнении его вручную. Задокументируйте каждый шаг и убедитесь, что вы знаете, как закодировать его. Потом соберите все фрагменты кода.

Один мой юный помощник постоянно подходил ко мне с просьбой помочь ему автоматизировать тот или иной процесс: «Я бьюсь над этой проблемой уже несколько часов! Я в тупике!»

«О'кей,» – отвечаю я, – «Покажи, как ты это делаешь вручную».

«Я не знаю. Мне не удалось это выяснить».

«Вот в этом твоя главная проблема, балбес. Понял?»

Как было сказано в главе 12, одним из плюсов документирования является то, что запись шагов процесса позволяет вам впоследствии автоматизировать его. Я не шучу. Если у меня нет времени автоматизировать какую-то задачу, я привожу ее поэтапное описание на своем Wiki-сайте и поручаю кому-нибудь ее выполнить. Тем самым я достигаю сразу две цели. Во-первых, я расширяю документацию, описывающую работу нашей системы. Во-вторых, я делаю первый шаг на пути автоматизации этой задачи!

♥ Документируйте все шаги процесса, а затем автоматизируйте их. Если вы не в состоянии записать шаги, вы никогда не сможете автоматизировать их.

Запись процесса уже вынуждает вас идентифицировать все его этапы. Вместо того чтобы держать их в голове, вы покажете документ другим, и они смогут проверить его на практике.

Если у вас нет Wiki-сайта, воспользуйтесь ручкой и бумагой или текстовым файлом. Выполняйте процесс вручную и записывайте, что вы делаете. Каждую введенную вами команду следует включить в документ.

Шаг 2: кодирование каждого шага

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

Если на каком-то шаге вы используете графический пользовательский интерфейс, необходимо найти его эквивалент в виде последовательности команд. В некоторых операционных системах это просто. Например, в SAM (System Administration Manager, диспетчер системного администрирования) из HP-UX есть кнопка, позволяющая отобразить команду операции, которую диспетчер выполнит следующей. В Mac OS X есть Automator и AppleScript, позволяющие автоматизировать операции, выполняемые с помощью графического интерфейса. Для Windows есть множество аналогичных утилит. Однако инструменты, автоматизирующие щелчки по кнопкам, могут оказаться менее эффективны, чем непосредственная установка ключей реестра или записей LDAP.

Рекомендуемая литература для администраторов Microsoft Windows:

• «Windows Server Cookbook» (Сервер Windows. Сборник рецептов), O'Reilly. Прочитав ее от корки до корки, вы узнаете массу полезных вещей. Вас удивит, как много операций, которые вы привыкли выполнять с помощью графического интерфейса, может быть записано в виде сценариев путем несложного редактирования реестра. Эта книга откроет вам глаза на многое. Примеры приводятся на нескольких языках, как правило на VBasic и Perl.

• «Perl for System Administration», O'Reilly.^[4] Эта книга особенно пригодится тем, кто работает и в UNIX, и в Windows. Как следует из названия, основное внимание в ней уделено языку Perl, и люди с опытом работы в Enterprise или UNIX с легкостью осилят ее. Кроме того, она будет полезна тем, кто много работает с ActiveDirectory и/или LDAP.

• «Win32 Perl Scripting: The Administrator's Handbook» (Создание сценариев на Perl для Win32. Справочник системного администратора), Sams. Тоже весьма полезная книга, особенно если вы только начинаете писать сценарии.

Рекомендуемые книги для администраторов UNIX/Linux:

• «Perl for System Administration» (см. выше).

• «UNIX System Administration Handbook»,^[5] Prentice Hall PTR. Эта книга не только учит вас основам системного администрирования в UNIX, но и содержит много полезных ссылок и инструментов. В большинстве примеров приводится командная строка, что облегчит написание сценариев.

• «Essential System Administration» (Основы системного администрирования), O'Reilly. Еще одна великолепная книга с примерами, в которых используется командная строка.

• «Advanced Bash-Scripting Guide» (Расширенное руководство по написанию скриптов bash). Посетите сайт http://www.tldp.org/gui-des.html.

Шаг 3: сборка шагов воедино

Если код каждого шага работает, вы можете собрать все фрагменты в один сценарий.

При сборке кода все-таки лучше добавлять по одному шагу за раз. Тестируйте код после каждого добавления. Такой подход называется итеративной разработкой и является оптимальным при автоматизации. Тестируя сценарий после каждого добавления, вы в большей степени уверены, что вся конструкция работает, как задумано.

Например, когда на работу приходит новый сотрудник, нужно создать для него запись в каталоге LDAP, выделить ему место на внутреннем веб-сервере и протестировать его учетную запись, чтобы убедиться в ее корректности. Каждое из этих действий может быть автоматизировано само по себе. Убедитесь, что команды, выполняемые на каждом шаге, работают. Затем соберите первую группу команд в сценарий и протестируйте его. Убедитесь, что последовательность команд работает и выводится необходимая вам отладочная информация. Запустите сценарий и убедитесь в корректности записей LDAP. Если все работает, добавьте следующую группу команд и протестируйте, что получилось. Убедитесь, что записи LDAP по-прежнему корректны и что пространство на внутреннем веб-сервере выделено. Добавьте еще одну группу команд и снова все проверьте.

Шаг 4: тестирование всего процесса

Наконец, мы должны протестировать процесс в целом. Если мы тестировали его после добавления каждого шага, тут будет совсем немного работы.

Вообще-то программисты не любят тестировать. Им хочется, чтобы программа правильно работала с первого запуска. Если выполнять тестирование на каждом шаге, оно не выглядит особо трудоемким; в результате на последней стадии приходится делать не так уж много.

Простые задачи, выполняемые часто

Приведу несколько примеров часто выполняемых простых задач. Обращаю внимание системных администраторов Windows, что эти примеры ориентированы на UNIX/Linux. Тем не менее, общие принципы применимы ко всем операционным системам.

Сокращения для команд

Большинство систем с командной строкой имеет ту или иную возможность создания псевдонимов. Это позволяет вам создавать новые команды на основе существующих. В каждой операционной системе принят свой синтаксис. В системе UNIX имеется множество языков оболочки (командной строки), самыми популярными из которых являются bash и csh. Они сильно различаются, и вы заметите, что, в первую очередь, в bash приходится употреблять знак равенства. Я приведу примеры для обеих оболочек.

♥ Примеры на bash будут работать в любой оболочке, смоделированной по оригинальной Bourne Shell, созданной Стивом Борном (Steve Bourne) (/bin/sh), например в Korn Shell (/bin/ksh) и Z Shell (/bin/zsh). Аналогичным образом примеры на csh будут работать в любой оболочке, имеющей корни csh, включая оболочку Tenex С shell (/bin/tcsh).

Как попасть в нужный каталог

Мне нередко приходится выдавать команду cd для перехода в каталог с очень длинным путем. Вот пример использования псевдонима:

bash:

alias book='cd "tal/projects/books/time/chapters'

csh:

alias book 'cd "tal/projects/books/time/chapters'

Теперь я могу набирать на клавиатуре book каждый раз, когда мне нужно перейти в каталог, где находятся файлы для текущей книги. Если я возьмусь написать другую книгу, я обновлю этот псевдоним. (Я ввожу «book» в течение последних шести лет!)

Это не только позволяет сэкономить на вводе. Вы избавлены от необходимости запоминать путь к каталогу. Освободить свою память всегда полезно.

Чтобы сделать псевдоним постоянным, вы должны добавить указанную строку в файл .profile, bashrc (bash) или .cshrc (csh). Эти файлы считываются только во время входа в систему, так что либо выйдите из системы и войдите обратно, либо введите команду source, чтобы файлы были прочитаны снова.

Назад к карточке книги "Тайм-менеджмент для системных администраторов"