Философия системного администрирования

Copyright © 2005 by Red Hat, Inc. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, V1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/).

Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder.

Distribution of the work or derivative of the work in any standard (paper) book form for commercial purposes is prohibited unless prior permission is obtained from the copyright holder. 

Legal notice

Original material: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/admin-guide/ch-philosophy.html

Translated by Ivan Pesin, May 2006

Перевод: Иван Песин

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

Вот общие идеи:

Ниже мы рассмотрим каждую из этих идей подробнее.

1. Автоматизировать всё, что можно

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

Вот некоторые типы задач, которые обычно автоматизируются:

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

Автоматизация также повышает предсказуемость и устойчивость обслуживания пользователей.

Tip Совет
 

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

2. Документировать всё, что можно

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

"Я сделаю это позже."

К сожалению, обычно это не так. Даже если системный администратор и не обманывает самого себя, сама специфика его работы такова, что задачи возникают слишком хаотично, что "сделать позже". Более того, чем дольше вы откладываете, тем больше вы забываете, и естественно, что документ получится менее детальный (а соответственно и менее полезный).

"Зачем записывать? Я это запомню."

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

"Если я буду держать это у себя в голове, они меня не уволят — у меня будет гарантия занятости!"

Хотя этот подход действительно может работать некоторое время, он неизменно ведёт к меньшей, а не большей, гарантии занятости. Задумайтесь на секунду, что может произойти при возникновении аварийной ситуации или других непредвиденных обстоятельствах. Вы можете оказаться не на месте; ваша документация могла бы сберечь день работы, давая возможность разрешить проблему в ваше отсутствие. И никогда не забывайте,  что аварийные ситуации имеют свойство находиться под пристальным вниманием руководства. В таких случаях лучше, чтобы ваша документация была частью решения, а не её отсутствие — частью проблемы.

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

Будем надеяться, что теперь вы убеждены в преимуществе ведения системной документации. Это приводит нас к следующему вопросу: что вы должны документировать? Вот неполный список:

Правила

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

Процедуры

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

Изменения

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

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

  • Имя или инициалы человека, внёсшего изменения

  • Дата внесения изменений

  • Причина по которой были внесены изменений

В результате получаются короткие и полезные записи:

ECB, 12-June-2002 — Обновил запись для принтера в бухгалтерии (для поддержки дуплексной печати у принтера, установленного взамен старого)


3. Общаться как можно больше

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

Методы общения с пользователями могут разниться в зависимости от организации. В некоторых используют электронную почту; в других — внутренний веб-сайт. Могут также применяться группы новостей или IRC. Где-то будет достаточно листка, прикреплённого к доске объявлений в комнате отдыха. В любом случае, используйте те методы, которые лучше всего работают в вашей организации.

Вообще, при написании сообщений, лучше следовать такому плану:

  1. Рассказывайте пользователям что вы собираетесь делать

  2. Рассказывайте пользователям что вы делаете

  3. Рассказывайте пользователям что вы сделали

Давайте теперь детальнее рассмотрим эти шаги.

3.1. Рассказывайте пользователям что вы собираетесь делать

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

Как минимум вы должны описать:

  • Суть изменений

  • Когда они произойдут

  • Почему это происходит

  • Приблизительно сколько этой займёт времени

  • Изменения (если есть), с которыми столкнутся пользователи

  • Контактная информация для вопросов и предложений

Предположим такую ситуацию: отдел бухгалтерского учёта испытывает трудности с сервером базы данных, который временами очень медленно работает. Вы планируете остановить сервер, заменить процессорный модуль на более мощный и загрузить систему. После этого, вы переместите саму базу данных на более быстрый RAID-массив. Вот возможное сообщение об этой ситуации:

Останов системы запланирован на вечер пятницы

В пятницу, начиная с 18:00 (полночь для наших коллег в Берлине), все бухгалтерские приложения будут недоступны в течении, приблизительно, четырёх часов.

В это время будут вносится изменения в аппаратную и программную части сервера баз данных бухгалтерии. Эти изменения должны будут значительно уменьшить время, необходимое для запуска программ Кредиторская задолженность, Дебиторская задолженность и генерации недельного балансового отчёта.

Большинство пользователей не должны заметить никаких изменений, кроме увеличения скорости работы. Однако, те пользователи, которые написали собственные SQL-запросы, должны учитывать, что будут внесены изменения в схему некоторых индексов. Эти изменения задокументированы на внутреннем веб-сайте, в разделе "Бухгалтерия".

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

Несколько пунктов, которые стоит отметить:

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

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

  • Используйте выражения, понятные пользователям. Их не интересует, что новый процессор имеет частоту 2ГГц и вдвое больший кэш второго уровня, или что база данных будет перенесена на массив RAID 5.

3.2. Рассказывайте пользователям что вы делаете

Этот шаг, в основном, является последним предупреждением о предстоящем событии; по существу, это должно быть краткое повторение первого сообщения, но с подчёркнутым приближающимся сроком события ("Обновление системы будет выполнено СЕГОДНЯ ВЕЧЕРОМ"). Также это хорошее место для ответов на любые вопросы, которые вы получили после первого сообщения.

Развивая наш случай из предыдущего раздела, приводим пример последнего предупреждения:

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

Напоминание: Останов системы, анонсированный в понедельник будет выполнен, как и запланирован, сегодня в 18:00 (полночь для берлинского офиса). Детальное сообщение про останов системы находится на внутреннем веб-сайте, в разделе "Системное администрирование".

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

Напоминаем, что те из вас, кто написал свои SQL-запросы возможно будут должны внести в них изменения, поскольку изменятся схемы некоторых индексов. Изменения задокументированы на внутреннем сайте компании, в разделе "Бухгалтерия".

Ваши пользователи предупреждены; теперь вы можете приниматься за работу.

3.3. Рассказывайте пользователям что вы сделали

После того, как вы закончили вносить изменения в систему, вы должны сообщить пользователям что именно вы сделали. Опять таки, это сообщение должно резюмировать предыдущие сообщения (всегда найдётся кто-то, их не читавший).[1]

Однако, есть важное дополнение, которое вы должны сделать. Нужно обязательно сообщить пользователям текущее состояние. Прошло ли обновление так, как планировалось? Хватило ли пространства на сервере для данных бухгалтерии или на нём разместились только данные технического отдела? Все эти вопросы должны быть раскрыты в сообщении.

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

В нашем случае, при выполнении работ администратор столкнулся с проблемами. Новый процессорный модуль не заработал; после звонка к производителю оказалось, что для замены на месте необходим специальный модуль. Миграция базы данных на RAID-массив прошло успешно (хотя и заняло больше времени чем планировалось, из-за проблем с процессорным модулем).

Вот возможное объявление:

Останов системы завершён

Останов системы запланированный на вечер пятницы (объявление можно найти в разделе "Системное администрирование" на внутреннем веб-сайте компании) завершён. К сожалению, проблемы с аппаратным обеспечением не позволили выполнить одну из запланированных задач. В связи с этим, остальные задачи заняли больше времени, чем запланированные четыре часа. Системы были запущены в рабочий режим в полночь (для берлинского офиса — в субботу, 6 утра).

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

Обратите внимание, что были внесены изменения в индексы баз данных; пользователи, написавшие собственные SQL-запросы, должны просмотреть раздел "Бухгалтерия" на внутреннем веб-сервере компании.

Если у вас есть вопросы обращайтесь в отдел системного администрирования по тел. 4321.

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

Примечание

[1]

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

4. Знать свои ресурсы

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

Некоторые доступные ресурсы вполне очевидны:

  • Системные ресурсы, такие как вычислительная мощность, память и дисковое пространство

  • Пропускная способность сети

  • Имеющиеся в вашем бюджете средства

Но есть и не очевидные:

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

  • Время (часто критической важности, когда оно включает в себя такие параметры, как время резервного копирования системы)

  • Знания (не зависимо от того, хранятся ли они в книгах, системной документации или голове человека, проработавшего в компании последние двадцать лет)

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

5. Знать своих пользователей

Хотя некоторые люди не любят, когда их называют "пользователями" (вероятно потому, что некоторые системные администраторы используют его в унизительном смысле), здесь этот термин используется безо всякого подтекста. Пользователи, это те люди, которые используют системы и ресурсы, за которые отвечаете вы — ни больше, ни меньше. Таким образом, они являются ключевым звеном успешного администрирования ваших систем; как вы сможете понять, какие системные ресурсы нужны пользователям, не понимая самих пользователей?

Например, возмём банковского служащего. Он использует чётко определённый набор приложений и требует относительно небольшого количества системных ресурсов. Теперь возмём программиста: он использует множество разнообразных приложений и всегда рад дополнительным ресурсам (для ускорения компиляции). Два совершенно разных пользователя с совершенно разными потребностями.

Всегда старайтесь как можно лучше узнать своих пользователей. 

6. Знать своё дело

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

Каково назначение систем, которые вы администрируете?

Здесь важно понимать назначение системы в более глобальном смысле:

  • Приложения, которые должны запускаться в определённые периоды, например в конце месяца, квартала или года

  • Время, когда можно выполнять техническое обслуживание систем

  • Новые технологии, которые могут помочь в решении существующих коммерческих задач

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

7. Безопасность не может быть второстепенной задачей

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

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

  • Характер возможных уязвимостей каждой из ваших систем

  • Расположение, тип и значение данных на этих системах

  • Тип и частота авторизованного доступа к системам

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

Что случится, если этот человек попытается нарушить безопасность наших систем?

Note Примечание
 

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

7.1. Риски социальной инженерии

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

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

Оператор второй смены отвечает на телефонный звонок. Абонент представляется финансовым директором вашей фирмы (имя, фамилия финансового директора и другая информация получена с вашего веб-сайта, из раздела "Руководство").

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

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

Вы знаете, что сделает оператор в такой ситуации? Если у оператора нет чётких инструкций (в форме правил и процедур), вы не можете быть уверенным в его действиях.

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

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

Вкратце: любыми способами доносите информацию до ваших пользователей.

8. Планировать

Системные администраторы, которые отнесутся серьёзно ко всем этим советам и будут стараться их выполнять, станут отличными администраторами... но не на долго. Рано или поздно, что-то изменится и однажды он окажется в луже. В чём же причина? Наш супер администратор не смог правильно спланировать события.

Конечно, никто не может предугадать будущее со 100% точностью. Однако, немного наблюдательности сделает очевидным множество вещей:

  • Сказанное вскользь на нудном еженедельном собрании замечание о готовящемся новом проекте является верным знаком, что в скором будущем вам придётся поддерживать новых пользователей

  • Разговор о близящемся поглощении другой фирмы, означает, что вы станете отвечать за новые (возможно несовместимые) удалённые системы

Умение видеть такие знаки (и соответствующе на них реагировать) облегчит жизнь вам и вашим пользователям.

9. Предвидеть непредвиденное

Фраза "предвидеть непредвиденное" банальна, но она отражает истину, которую должны понимать все системные администраторы:

В вашей практике будут случаи, которые вас застанут врасплох.

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

Что же в таком случае должен делать системный администратор, который предвидит непредвиденное? Вероятно вы можете держать несколько запасных дисков на случай аппаратных проблем[1]. Такие диски можно временно добавить [2] в систему для решения возникшей необходимости в пространстве. Кроме того, это даст время для основательного решения проблемы (например, для выполнения стандартной процедуры заказа дополнительного диска).

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

Примечание

[1]

И конечно, системный администратор, который предвидит непредвиденное, будет применять RAID (или подобные технологии) для уменьшения последствий сбоя критических дисков при эксплуатации систем.
[2]

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