Как быть хорошим (и ленивым) сисадмином

Оригинал: How to be a good (and lazy) System Administrator
Автор: Mike Diehl
Дата: 2 июня 2008
Перевод: Александр Тарасов aka oioki
Дата перевода: 14 ноября 2008

Если вы можете назвать себя средним системным администратором, значит вы все время заняты самыми разнообразными компьютерными делами, за которые вам еще и мало платят. Еще вы привыкли к мысли, что никто не знает о вашем существовании до тех пор, пока почтовый сервер не рухнет; после этого события вы становитесь врагом всех. При написании этой статьи я рассчитываю, что под вашей ответственностью работает несколько серверов. Предполагаю также, что вы не хотите работать, в хорошем смысле - хотите сделать свою работу легче; если не так, тогда вам нужно управлять сервером Windows и ежедневно беспокоиться о новых патчах от Microsoft, дырах в безопасности, защите от вирусов, грубом пользовательском интерфейсе и недостатке возможностей писать скрипты. Я не утверждаю, что Linux - совершенная система, однако в ней есть множество вещей, с которыми администрирование серверов ведется куда легче.

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

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

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

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

# servers.sh
export MAILSERVERS="server1 server2 server3"
export WEBSERVERS="www1 www2 www3 www4"

После этого я могу написать простой скрипт, что-то вроде этого:

#!/bin/bash
### Сколько свободного места на почтовых серверах
source ./servers.sh
for i in ${MAILSERVERS} ; do
       echo =========${i} =============
       ssh root@${i} "df"
       echo ============ =============
done

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

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

Обратите внимание на комментарий на второй строчке. Когда у вас накопится, к примеру, 50 различных скриптов, станет сложно запоминать, что делает каждый из них. Можно, конечно, именовать их наподобие свободное_место_на_почтовых_серверах.sh, но мне так не нравится. Так что когда мне нужно узнать, что делает какой-либо скрипт, я набираю:

grep "###" *

Эта команда выводит мне список скриптов с кратким описанием того, что они делают.

Еще из своего опыта я вынес такую технику, что каждый скрипт в зависимости от задачи выполняется каждый день, неделю или месяц - я помещаю его в расписание cron, и результат выполнения приходит мне по электронной почте. Во многих системах есть каталоги, из которых cron выполняет скрипты каждый час (hourly), ежедневно (daily), или еженедельно (weekly). Однако мне не нравится такой подход, ведь администратор должен точно знать, когда должна выполняться операция, а не cron должен решать это за него. Поэтому я предпочитаю ручное редактирование crontab. К примеру, я хочу, чтобы резервное копирование выполнялось в нерабочее время. У меня есть более срочные дела, чем изучение формата crontab, поэтому в каждый такой файл я помещаю следующую строку:

# min   hour    dom     month   dow     command

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

Журналирование (через syslog) - это функция любой Linux-системы, однако по причине большого объема файлов журналов, эти возможности используются не в полную силу. Обычно администраторы настраивают logrotate для удаления старых журналов. Лишь когда что-то происходит, администратор смотрит в логи и ищет причину сбоя. В syslog я добавил журналирование веб-серверов, файрволла, почты и других служб. Никогда не любил читать логи строка за строкой, выискивая там ценную информацию. Вместо этого весьма полезно написать что-то вроде программы для анализа журналов, пусть даже это будет несколько операций grep. Эта программа должна развиваться вами, чтоб она могла отбрасывать все больше и больше ненужных данных. Когда вы сделаете это, и настроите отправку отчетов по электронной почте, вам будет достаточно одного взгляда, чтоб понять, что все в порядке (или наоборот).

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

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

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

Службу мониторинга на самом деле не так сложно установить, и это классный способ знать о проблемах в своей сети. Однако нельзя поставить ее и быть уверенным, что она сама работает как надо. Однажды начальники сказали, чтоб все подразделения задействовали новую систему мониторинга. Конечно, я был рад этой новости, ведь мне больше не приходилось заниматься этой задачей. Будучи хорошим (и ленивым) системным администратором, я быстренько перевел все сервера на корпоративный мониторинг. Я сразу отключил один из серверов, и засек время. Прошло более получаса, прежде чем система мониторинга сообщила о сбое. В моей компании это было немыслимо. После краткого разговора с начальником отдела мониторинга в систему были внесены изменения, и все были счастливы. Всегда следует проверять вводимую систему мониторинга.

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

Было бы неплохо следить за любым событием, которое может вызвать сбой работы, и настроить систему мониторинга, чтоб она отслеживала его. События, происходящие быстро, должны проверяться часто. К примеру, выключить сервер можно за несколько секунд, поэтому пинговать их надо часто. С другой стороны, вряд ли за 15 минут можно забить жесткий диск сервера, поэтому проверка свободного места производится реже. Обычно я устанавливаю низкий порог тревоги. К примеру, если мой диск полон на 30%, я устанавливаю этот порог в 45%. Когда система доходит до этой точки, я начинаю понимать, что что-то идет не так, однако мы находимся не в той точке, когда все может закончиться сбоем. Можно даже проигнорировать проблему и дать себе время подумать насчет путей решения.

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