Введение

Эта статья – скорее из разряда «для самых маленьких», чем «для умудренных опытом», но она призвана повышать профессиональную культуру системных администраторов.
В силу специфики работы мне «по наследству» достается самый разнообразный облачный ад, который приходится разгребать, оптимизировать, приводить в чувство и делать прозрачным и красивым. Эти заметки, пожалуй, иллюстрация к тем моментам, которые вообще недопустимы в системном администрировании.
В причинах, которыми порождаются эти анти-паттерны, можно разбираться очень долго: дедлайны, законы и темпы бизнеса, да и просто идиотизм, наконец. Но цель статьи другая. Мне бы хотелось породить конструктивную дискуссию. А вот уже её результаты и являются основной целью статьи.

Встречайте, анти-паттерны:

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 использовать. (Да, у нас – Circonus. Нет, это не реклама).
А еще есть замечательный инструмент — PagerDuty – заверните на него все ваши email-alert’ы, и он радостно будет слать вашим Ops смс-сообщения, поможет составить расписание дежурств и вообще очень крутой и гибкий.

5. Отсутствие отслеживания изменений файлов.

Что это, и что с этим делать?
Я вчера отредактировал конфигурационный файл. И еще один. А потом пришел сменщик и еще что-то там правил. А сегодня нас обоих вызвали в 3 часа ночи в офис и теперь мы злые и готовы убить ближнего, правда? Это тоже знакомо многим, не сомневаюсь. Но ведь Линус создал Git еще в 2005, а до git были и другие vcs. Сделать git commit после того, как вы что-то отредактировали – дело одной секунды. Но именно эта полезная привычка избавит вас от проблем с откатом конфигурации в случае каких-то неожиданностей. А в совокупности с системами управления конфигурациями это становится чуть ли не основным и самым важным навыком в повседневной работе. Стоит выработать правильную привычку пользоваться системами контроля версий и никогда ей не изменять.

Заключение?

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

Полезные ссылки

1. devopsweekly.com — англоязычная, но очень интересная еженедельная рассылка
2. agilesysadmin.net — прекрасный блог на английском языке от очень опытного системного администратора и одного из евангелистов движения DevOps
3. Chef Cookbooks — коллекция рецептов для Chef, созданных сообществом
4. Книга Test-Driven Infrastructure with Chef — книга, рассказывающая о том как писать и тестировать свои рецепты для Chef.