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 после того, как вы что-то отредактировали – дело одной секунды. Но именно эта полезная привычка избавит вас от проблем с откатом конфигурации в случае каких-то неожиданностей. А в совокупности с системами управления конфигурациями это становится чуть ли не основным и самым важным навыком в повседневной работе. Стоит выработать правильную привычку пользоваться системами контроля версий и никогда ей не изменять.