ТОП-5 анти-паттернов системного администрирования
В причинах, из-за которых появляются эти анти-паттерны, можно разбираться очень долго: дедлайны, законы бизнеса и просто невнимательность с неопытностью. Тем не менее, эти анти-паттерны существуют и их надо знать.
1. Ручное управление/конфигурация системы администраторами
Что это?
Это – пожалуй, самый частый и наиболее опасный анти-паттерн, особенно когда он подкреплен остальными. Суть проблемы можно описать тремя словами — «людям свойственно ошибаться». А если, согласно известному закону, неприятность может случиться — она случится обязательно. Конечно, именно вы никогда не делаете глупостей, но не проще ли принять превентивные меры?
Что вы можете с этим сделать?
Самое простое – не ходить на сервер по ssh самостоятельно. Вообще! Освойте системы управления конфигурациями: Opscode Chef, Puppet ну или CFEngine, например. Базовой информации более, чем достаточно для успешного понимания и старта использования.
2. Сторонние компоненты, мешающие обновлению системы
Что это и что с этим делать?
Наверняка, каждый системный администратор, который сталкивался с ruby, но не открыл на тот момент для себя rvm/rbenv, хоть раз в жизни собирал его из исходников у себя на сервере и использовал в production. А теперь вопрос: вам нужно на 16 front-end серверах очень срочно обновить ruby, потому что вышел патч, закрывающий критическую уязвимость, позволяющую получить права root удаленно.
Пойдёте на каждый из серверов компилировать вручную? Или, всё же, на тестовой машине соберёте новый пакет и централизованно обновите все сервера, пользуясь инструментарием из описания первого анти-паттерна? Ответ очевиден.
3. Отсутствие стандартизации
Что это и что с этим делать?
Как ни странно, этот анти-паттерн является то ли причиной, то ли следствием первых двух. Представьте себе зоопарк из 16 front-end серверов на которых стоят разные версии debian, centos и gentoo c подключенными нестандартными репозиториями сомнительного происхождения. Представили? Перекрестились? Это хорошо.
К счастью, бороться с этим совсем не сложно. Напишите гайдлайны и следуйте им. Что может быть проще?
4. Недостаток мониторинга и уведомлений
Что это и что с этим делать?
Странно, но иногда кажется, что этим грешит чуть меньше 50% компаний. Если у вас нет хотя бы Nagios и Monit для сбора всевозможных метрик и радостной рассылки писем Operations Team в случае чего-то экстраординарного, вы гарантированно однажды, довольно сильно нервничая, проведете в офисе 24 часа подряд. А может и все 48.
Бороться с этим анти-паттерном очень просто и полёт вашей фантазии в выборе инструментов ограничен лишь вашими убеждениями. Хотите — можете Nagios или Zabbix + Cacti у себя держать, хотите — SaaS-решения типа Circonus и/или NewRelic использовать.
А еще есть замечательный инструмент — PagerDuty. Заверните на него все ваши email-alert’ы, и он радостно будет слать Ops смс-сообщения, поможет составить расписание дежурств и вообще очень крутой и гибкий.
5. Отсутствие отслеживания изменений файлов
Что это и что с этим делать?
Вы вчера отредактировали конфигурационный файл. И еще один. А потом пришел сменщик и еще что-то там правил. А сегодня вас обоих вызвали в 3 часа ночи в офис и теперь вы злые и готовы убить ближнего, правда? Это тоже знакомо многим, не сомневаюсь.
Но ведь Линус создал Git еще в 2005, а до git были и другие vcs. Сделать git commit после того, как вы что-то отредактировали — дело одной секунды. Но именно эта полезная привычка избавит вас от проблем с откатом конфигурации в случае каких-то неожиданностей. А в совокупности с системами управления конфигурациями это становится чуть ли не основным и самым важным навыком в повседневной работе. Стоит выработать правильную привычку пользоваться системами контроля версий и никогда ей не изменять.
Заключение
Лучшим итогом этой статьи будет то, что каждый оглянется на свой production и исправит то, до чего обычно руки не доходят месяцами, переборет лень и сделает один раз по уму.