Site Reliability Engineer
0,0
рейтинг
16 января 2012 в 13:07

Администрирование → 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 использовать. (Да, у нас – 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.
Serhii Balbieko @m0s
карма
27,0
рейтинг 0,0
Site Reliability Engineer
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Администрирование

Комментарии (59)

  • 0
    мотивирующая статья, если не сказать больше. первый пункт хорош пинок, пойду осиливать, хорошо ведь не только для администрирования но и для виртуалочек (комманда, тестирование).
  • +27
    не ходить на сервер по ssh самостоятельно.

    Самый лучший способ контрацепции — воздержание!
    • +1
      image
  • 0
    Не могу назвать себя администратором, но пару вэдээсок админить приходится. Соблюдаю 4 анти-паттерна из пяти. До того, чтобы в /etc устроить mercurial репозиторий додумался. Теперь бы ещё не забывать коммитить и пушить (закоммитил 183 файла...)

    Заинтересовал первый антипаттерн — это что-то вроде capistrano/phing? Имеет смысл использовать на паре независимых вэдээсок? Или это для настоящих админов с 16+ фронтендами?
    • +1
      capistrano — это для деплоя по одному приложению. А тут скорее речь про системы настройки сервера в целом.
      • 0
        Я же не сказал, что полный аналог. Но смысл примерно такой же — описываем конфиги и задачи локально и «деплоим» их на сервера одной командой?
        • +1
          не совсем. капистрано это «что делать» а эти системы — «что получить».
          описывается итоговый результат, пусть для достижения система строит сама в зависимости от окружения и иже с ним.
    • +3
      До того, чтобы в /etc устроить mercurial репозиторий додумался. Теперь бы ещё не забывать коммитить и пушить (закоммитил 183 файла...)

      Для этого есть обвязка удобная, etckeeper называется (в Дебиане есть в пакетах).

      На паре вэдэсок имеет смысл скорее для опыта. Реальная польза ощутима на большом парке машин (особенно с типовыми задачами).
      • 0
        Век живи, век учись, спасибо за наводку :)
      • 0
        Сам пользуюсь etckeeper'ом (правда с git'ом).
        Уже неоднократно помогал, когда новые конфиги перезатирали старые при обновлении. Но кроме того важно не забывать коммитить и самим, если что-то менялось руками…
    • +1
      Chef / Puppet и им подобные – не совсем похожи на capistrano. Capistrano — хорошее дополнение для этих инструментов, хотя и не обязательное. Cap позволяет выполнять команды на удаленных серверах. По сути — обёртка над ssh, особенно удобная для развертывания приложений.
      Системы управления конфигурациями служат для того чтобы выполнить начальную(и повседневную) настройку сервера — установить ПО, развернуть нужные конфигурационные файлы и т.д. Особенно, когда таких(особенно однотипных) серверов больше двух.
      А стоит ли использовать в малых системах — это личное дело каждого.
      Мое мнение — да. Мне удобнее сначала написать рецепт, внимательно его прочитать, а потом запустить chef-client на нужных узлах и применить изменения. Плюс некоторая централизованность есть. Плюс возможность протетстировать предстоящие изменения на тестовой площадке.
      • 0
        Спасибо, надо попробовать. Cap и использую для деплоя своих приложений. Судя по всему порекомендуете Chef поизучать?
        • +1
          Это вопрос религиозный больше.
          Лично я — пользуюсь Chef по ряду причин:
          — мне нравится ruby и писать рецепты на ruby больше чем DSL у puppet
          — мой начальник — один из известных тренеров по chef в европе
          — исходя из предыдущего пункта — chef у нас — стандарт на работе.

          Если сравнивать с puppet — то у puppet немного более длинная история — а значит и немного больше литературы. а вскидку могу назват 2-3 англоязычных книги. chef пока не может этим похвастаться. Но у chef — просто прекрасная wiki и отличное коммьюнити где можно получить ответы на вопросы, а так же найти рецепты, советы и т.д.

          На самом деле самый правильный метод выбора — так же как с linux-дистрибутивом первым. Лучше пользоваться тем, в чем разбирается соседский гуру. Но когда я начинал — у меня такого гуру еще не было, по этому меня выручили запросы в гугл вроде «chef vs. puppet» и «configuration management systems comparison» и просто интуиция совмещенная с авантюризмом, которые подсказали «chef перспективнее, моложе и интереснее для изучения»
          • 0
            Есть хорошая обзорная статья или видео? Понять что за штука.
            • +1
              Посмотрите на хабре тут, вот это и еще это и это
              • 0
                Спасибо, немного прояснило вопрос.
  • 0
    зоопарк из 16 front-end серверов на которых стоят разные версии debian, centos и gentoo

    в таком случае далеко не всегда возможны пункты (1) и (2)
    • 0
      ну пункт 1 скорее наоборот, вполне возможен
  • +4
    Совершенно не согласен с первым пунктом. Для массовых изменений или каких-только-угодно действий на сервере SSH подходит ни крайней мере не хуже Puppet и Chef. Заход по ключу, группы серверов с одинаковыми функциями и привычные shell/perl/python скрипты для автоматизации действий.
    Не вижу смысла изучать дополнительные инструменты со своими ограничениями, новые синтаксисы, шаблоны и пр, особенно осознавая то, что когда-то вам потребуется сделать что-то, и вы это сделать этим инструментом не сможете.
    Да и, спасибо Майкрософту, уже выросло не одно поколение администраторов, не понимающих как можно отправить GET/POST телнетом, или там почту по SMTP отправить через него же. Все эти гуевые прибамбасы, управления кофигурациями при помощи мышки — ровно из той же оперы.
    • –4
      Поясню еще немного, раз уж есть несогласные. Использование систем такого рода накладывает ограничения на инфраструктуру. Преставьте себе, что у вас не просто убунтушечка, а система на которой стоит панель управления хостингом, например Plesk. Которая требует определенного почтового клиента, определенного его конфига, определенных каталогов где лежат юзерские сайты, и пр. Для начинающего админа — мечта. В два клика настраивается (и неплохо настраивается) сервер, автоматизируются до двух кликов рутинные операции и делегируются еще кому-то. Идилия? Кому как.
      То же до систем управления. Как система управления может отслеживать уязвимость (а это одна из функций Puppet enterpize) в пакете, если он собран или взят из неофициального репозитория? Ну и обвес. Я понимаю, сейчас уже не модно ставить юникс без гуя. В минимальной инсталляции ставится столько софта, сколько раньше на рабочей станции то не стояло — и иксы, и апачи, и джава. Конечно, в этом зоопарке, и руби и агенты не так уж заметны.
      Лирическое отступление: приходили тут интеграторы с одной американской системой мониторинга. Не осилили установить агента — не хватило ей 1 гигабайта места в корневом разделе. Видать, жадные мы, раз место на диске экономим.
    • +5
      Тоесть вы предлагаете заменить готовые инструменты самописными скриптами?
      • –1
        Простите, а какие у вас есть периодические задачи, которые нужно выполнять на серверах? У меня раскатка сервера выполняющего роль X делается автоматически, скриптами (да, предпочитаю стягивать конфиги из репозитория одной командой). Скрипты эти — на полтора экрана текста, понятны любому юникс админу, документация на любой из вышеупомянутых инструментов занимает на два порядка больше страниц
        • +2
          все правильно, у вас есть свой велосипед, аналогичный предложенным инструментам и покрывающий часть их функций. и вы им гордитесь.
          Нет, правда — столько текста вокруг простой идеи — вы зачем-то связали отсутствие навыков ручного troubleshooting с использованием системам управления конфигурациями.
          Не подменяйте понятия. Это две разных области, и применение инструментов из одной совсем не лишает знаний в другой.

          А на практике — вы все равно используете систему управления конфигурациями. Только свою, самописную. Это, кстати, тоже вариант решения проблемы описанной в первом пункте. И его право на жизнь никто не оспаривает. (Ну по крайней мере я не оспариваю)
          • –4
            не буду спорить. Но повторюсь, что такой инструмент гибче и написан на понятном каждому админу bash ;)
            • 0
              плох тот админ, которому рецепты для chef на ruby непонятным языком кажутся
              image
            • 0
              Есть только одна проблема, количество людей которые умеют писать правильно на bash вообще мало. Я вот себя не отношу к тем кто умеет. И наверно могу сказать что знаю только двоих которые умеют писать на нём правильно. И мой опыт подсказывает что проще найти человека который разбирается в ruby чем в bash.
              • 0
                А вообще, мне кажется — стоит абстрагироваться от инструментария, по тому что это лишь лишь почва для религиозных войн, не более. А проблему нужно решать слегка сферически и в вакууме — придумывать/применять алгоритмы и методы, а не языки и инструменты.
    • 0
      Поддерживаю данного оратора. Puppet или Chef имеет смысл когда у тебя не 16 а 16000 серверов. А когда у тебя два-три сервера Puppet — это сильный оверкилл, для этого отлично подходит SSH, а главное требует меньше времени и сил на настройку и работу.
  • 0
    Спасибо за подборку полезных ссылок. Может кто еще что-то посоветует почитать?
    • +4
      Из серьезных книг — пожалуй вот эти:

      DevOps: High-impact Strategies — What You Need to Know: Definitions, Adoptions, Impact, Benefits, Maturity, Vendors
      Roebuck, Kevin

      Web Operations: Keeping the Data On Time
      Allspaw, John, Robbins, Jesse

      Cloud Computing Architected: Solution Design Handbook
      Rhoton, John, Haukioja, Risto

      Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))
      Farley, David, Humble, Jez

      Pro Puppet
      Turnbull, James, James Turnbull, Jeffrey McCune December 8, 2011

      Pulling Strings with Puppet: Configuration Management Made Easy
      Turnbull, James

      Configuration Management: High-impact Strategies — What You Need to Know: Definitions, Adoptions, Impact, Benefits, Maturity, Vendors
      Roebuck, Kevin

      А из статей и блогов:
      Стоит обрать внимание на этот и этот блоги. А так же на хэштеги #opschef, #puppet и #devops и прочие тематические в твиттере.
  • 0
    Все понимают как хорошо, а делается обычно как быстрее, временно.
    Нет ничего более постоянного, чем временное.
    самому стыдно
    • 0
      Ну об этом я и на писал в заключении. Нужно просто оглянуться, собраться с духом — и переделать. Пока оно не превратилось в такой страшный для всех администраторов всем legacy который нужно поддерживать и ненавидеть.
      • 0
        В моем случае, проект не коммерческий а чисто ради опыта.
        Сделаю бэкапы и заново построю «город сад» с учетом «замечаний».
  • 0
    > Представьте себе зоопарк из 16 front-end серверов на которых стоят разные версии debian, centos и gentoo c подключенными нестандартными репозиториями сомнительного происхождения?

    А что плохого в разных версиях CentOS? В локальном репозитории со своими пакетами просто нужно учесть, что в 5-ой ветке CentOS младшие версии поддерживают только md5 для пакетов.
    • +1
      Возможно я не совсем понятно написал, извините. Я имел в виду абстрактную ситуацию с различными дистрибутивами на однотипных узлах, отягощенную еще и различными версиями ос. А не просто множество разных версий одной ОС ан разных типах серверов.
  • 0
    Я сам к этому пришел не так давно, но есть в планах на этот год внедрение puppet+git и остановка на одном дистрибутиве — ubuntu 12.04 lts для инфраструктуры + oracle linux для oracle db (сейчас используем как ubuntu 10.04, так и freebsd разных версий + немного centos и oracle linux). для мониторинга внедрить — zabbix + cacti (сейчас используем самописные скрипты для уведомлений и cacti для наглядности графиков). Вообщем планов уйма, дошли бы до всего руки.
    • +1
      у меня сначала глаз дернулся от вашего ника
      а так планы хорошие, только наверное очень смелые в той части где 12.04. Вот правда. Очень смелые.
      • 0
        у меня сначала глаз дернулся от вашего ника

        :)

        а так планы хорошие, только наверное очень смелые в той части где 12.04. Вот правда. Очень смелые.

        Ну почему же. я на 10.04 перешел с 8.04 через пару месяцев с его выхода — проблем не наблюдал. Как правило, в первый месяц, свежий выпуск латается до приемлемого уровня.
      • 0
        Вроде речь о сервере, а там Unity по дефолту не ставится :)
  • 0
    Всё-таки. Кого лучше брать для централизованного управления?
    Паппет съел мне мозг и ушел в помойку сразу. А между шефом и цфе — кого лучше выбирать и почему?
    • 0
      я там выше ответил на похожий вопрос

      если вкратце — то какая вам лично больше нравится. Лучше всего попробуйте обе. Первое впечатление бывает редко бывает обманчиво.
    • +1
      Пытался разбираться со всеми тремя, больше всех пожевал мозг cf, а папетка показалась более ли менее логичной.
      В общем каждому свое.

      Если есть время почитайти холивары Чиф vs Паппет, особенно начинается инетерсно когда появлюятся 50 летние мужики и рассказывают, что cf не зря 17 лет на рынке, а вы все в киндергарден
    • 0
      Есть ещё spacewalk/sattelite от RH.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +3
      вам возможно будет интересно прочитать эту статью
      • НЛО прилетело и опубликовало эту надпись здесь
        • +2
          я программист:-)
          сам отбрекиваюсь от рута на сколько получается, своей работы достаточно
    • 0
      Если я перестану программировать, то мне свой свой сервер админить незачем будет. А если все перестанут программировать…
      • 0
        Подозреваю, что подразумевалось следующее — средний программист владеет администрированием сервера намного хуже сисадмина.
        Впрочем, верно и обратное :)
  • +1
    а какие фишки Circonus?
  • +2
    Спасибо, почитал статью после чего подписался на блог Agile сисадмин и книгу Test Driven Infratructure with Chef купил для Kindle, вечером почитаю.

    Если что, есть еще сравнительно-легковесная альтернатива Шефу — Sprinkle (он построен поверх capistrano), раньше использовал его для автоматизации настройки новых серверов.
    Сейчас смотрю в сторону Chef, потому что у него развитое сообщество и куча готовых рецептов (которые можно либо просто использовать, либо слегка модифицировать под свои нужды).

    Puppet (и ShadowPuppet) когда-то пробовал но сломал мозг, наверное просто не могу заставить себя мыслить в контексте «что я хочу получить в результате» и довериться автоматике вместо «что нужно сделать».
  • +1
    Совсем забыли написать про централизованную аутентификацию на серверах. Когда на 100+ серверах зоопарк учетных записей это ужасно с точки зрения безопасности.

    А вот про системы контроля и распространения конфигураций не соглашусь. У меня в ведении много серверов и ни разу нужны в них не было. В отделе есть сектор развития, который готовит внедренческую документацию, типовые решения и т.д., а также сектор эксплуатации, который по этой документации настраивает реальное оборудование. Получается проще и надежнее, нежели городить единый центр конфигурирования с псевдо-языком. Плюс представьте что его скомпрометируют — можно смело переставлять ОС на всем парке оборудования.
    • 0
      А если хранилище внедренческой документации скомпрометируют?
    • 0
      Может стоит спросить сектор эксплуатации, как им работается, удобно или нет. Если написать внедренческую документацию, а в ней указать, что необходимо на всех 47 серверах обновить ruby до версии 1.8.7patchlevel 251, то это не значит, что сектору эксплуатации так удобно. Это лично вам скорее удобно.

      Проблема у единого центра конфигурации одна — его надо один раз настроить и вбухать кучу времени. Потом все превращается в одну кнопку для всех единиц или десятков машин.

      Концепция DevOps (и chef в частности) позволяет вообще отказываться от таких центров внедренческой документации. Прошлый век какой-то. Сам центр конфигурации и будет таким хранилищем. Рецепты прекрасно документируются в процессе написания, все понятно и доступно, логика прослеживается. Процесс работы не превращается в графики составления графиков и документирование документации по написанию документации. Простите, выдыхаю ))
  • 0
    Третий антипаттерн напомнил цитату с баша
  • 0
    Puppet очень хорошая штука. Но тут она упомянута не к месту немного, т.к. на наворотить дел, наделать ошибок и т.д. при помощи Puppet можно не меньше, а порой и больше, чем просто через SSH.
  • +2
    Каждый выбирает свой путь imgur.com/KO5ke

    Немного не пойму про сложности языка программирования который вроде как навязывают пользователю в системе управления серверами, к примеру chef, казалось бы необходимо учить ruby. Далее башерам посвящается: Я хочу посмотреть как вы будете автоматизировать мониторинг, систему рееврного копирования да и другие сервисы в которых есть API (почти во всех сейчас), вы будете с API работать через *sh или передавать курлу кучу аргументов прям в ссылку? Можно конечно перейти на python bash script в пользу не руби к примеру, что поменялось? Аналогично с взаимосдействием самописных скриптов с использованием разных языков, развертка серверов, его заселение, уровне взаимодействия тех или иных конфигураций между сервисами.
    • 0
      будут curl'ом, очевидно же. зачем нам скальпель, мы и топором можем
  • 0
    а я как лох винды админю(((

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.