вторник, 1 марта 2011 г.

Первые шаги. Изучить инструменты.

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

Наши инструменты - это программы и ОС. Без этого мы никуда не попадем.
Для того, что бы выбрать хороший инструмент, надо знать для чего мы его выбираем. Лично я выбираю инструмент по следующим признакам:
1. Наличие хорошей документации.
2. Хорошая управляемость.
3. Быстрая повторяемость
4. Журналирование инцидентов.

По поводу первого пункта думаю всё ясно. Нет документации - много магии. Проходить всю магию самому - сложно и долго. А значит, что дорого. Чем понятнее документация, чем подробнее она объясняет как и зачем, тем проще работать с инструментом.

Под вторым пунктом я подразумеваю простые и доступные формы настройки инструмента. Многие не задумываются над этим, и это часто вызывает ошибки. Тут варианта два. GUI администрирования (M$ like) или text-config style (nix like). Какие у них преимущества:
GUI:

  • Удобство настроек - часто варианты выбора и пояснения к ним уже заданы (+)
  • Отсутствует повторяемость (-)
  • Нет механизма точных подстроек - если и есть, то интерфейс часто представляет из себя regedit из-за обилия настроек. (-)
Text:

  • Начальная сложность в освоении - надо понимать, для чего каждая настройка. (-)
  • Компактность параметров - все в одном месте (+)
  • Точные подстройки прямо в файле. (+)
  • Повторяемость (+)
Часто бывает так, что GUI администрирования, это лишь оболочка для редактирования какого-то набора файлов. Те кто видели редактор реестра M$ поймут, как не просто возиться с GUI.

Быстрая повторяемость.
Я не фанат "начального готового образа системы". А почему? А всё просто. Я знаю, что такое netinstall и как быстро и просто разворачивать любое кол-во машин. У образа есть косяки. Например время создания файлов из прошлого. Различные параметры будут совпадать, хотя на деле не должны. Образ стареет со временем. За ним приходиться следить. Очень много мусора накапливается, если система поддерживается и не факт, что со старым мусором мы не утянем зловреда.
Для сетевой инсталляции достаточно подготовить набор софта и файл ответов, а так же разместить набор конфигов. Инсталляция будет свежей.  

Журналирование инцидентов(логирование).
Собственно система логирования всего и вся.
Важные замечания к системе.
  1. Возможность выбора уровня логирования.
  2. Подробные настройки уровня логирования.
  3. Удобное восприятие информации.
  4. Централизованное логирование всего и вся.
По первому пункту всё просто. Когда я только запускаю или отлаживаю систему, мне нужен очень подробный журнал. Когда система уже пашет в рабочем режиме, журнал должен быть простым и понятным.
По второму. Желательно иметь возможность каким-то способом указывать что хочется видеть в данных об инциденте.
По третьему. Это мы видим часто: "Ошибка №23. Обратитесь к администратору." Я сам администратор, и мягко говоря я не помню все кода.
Вот примеры минимально удобных ошибок "Ошибка 404. Страница не найдена."
Или из другой оперы "Ошибка 12. Сервер ключа не найден."
Тут понятно, какой-то сервер ключа не найден. Видимо нужен, но куда-то пропал.
А вот если лог был бы таким: "Ошибка 12. Сервер ключа по запросу ххх.ххх.ххх.ххх:3182 не найден". То уже информация интереснее.
И последнее, и самое важное. Я хочу иметь общий инструмент слежения за ошибка. По возможность, что бы журнал инцидентов от всех инструментов был бы в одном месте.

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



Комментариев нет: