Шаг 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» в течение последних шести лет!)
