Как стать автором
Обновить

Комментарии 19

Есть что рассказать про опыт конкретных движков типа вордпресса или Битрикс, всю радость боль работы с ними?

Мне, как админу не важно — битрикс, вордпресс, джумла или что-то еще. Модули разные, а проблемы и схема масштабирования примерно похожи.
А как организовать «плавающий IP»? Если есть информация по VMware ESXi — еще лучше.
Например VRRP, демон keepalived, можно Nginx, есть и другие варианты, лично я выбираю keepalived при работе с базами.
corosync/pacemaker отлично справляются с этой задачей.

Так вроде kernel.org работает на Fedora и ничего. Странный парень...

А что такого ценного в kernel.org чтобы о нем сильно заботиться? Товар не продает, денег не приносит, даже рекламы нет (лого дистртбутивов мне не кажется прямой рекламой). Тем более что есть куча зереал.Даже если он сляжет на пару недель, трагедии не произойдет.
В посте же речь, насколько я вижу, про ифраструктуру, которая не только электричество потребляет, но и приносит немалую прибыль.

А в чем преводсходство Красной Шапки над Дебиановцами? По тексту заметил снисходительно-пренебрежительный тон по отношению к Убунте, поэтому и возник такой вопрос.

Это холиварная тема.
Например, чем мне не нравится убунта (и частично это присуще дебиану, но только частично): в рамках LTS релиза может мажорно измениться версия ядра; мейнтернеры делают так, чтобы после установки сервисов, они автоматом стартовали; репы типа большие, но недостаточное тестирование; медленная реакция на проблемы в багтреккерах; сам deb как формат пакетов ...

Конечно, не ради холивара спросил, а опыта перенять.
Тут ведь как… Можно и Убунту сделать стабильной, но есть еще трудозатраты по поддержке. Отсюда и предпочтение к Красной Шапке.
Unbreakable Linux (ранее дистрибутив назывался менее пафосно — Oracle Enterprise Linux)

Это ядро, а дистрибутив называется почти также: Unbreakable Enterprise Kernel for Oracle Linux.
я вижу старые убунты

IBM не такая привередливая и поддерживает большинство приложений на актуальных Ubuntu LTS.

С почему общий SLA 99,9? Вероятность несвязных событий считается как произведение вероятностей, те общий SLA системы получается 99,8%

My bad. Картинка отражает правило проектирования. Оно не описывает вероятность факапа, оно говорит о том, что надежность системы в первую очередь определяется надежностью самого слабого звена. В эксплуатации, конечно, будет "≤".
«Пока не прихожу злой я и не начинаю показывать пальцем на разные дырки.» Это только в том случае если вы сами администрируете сервера заказчика?
В целом да, если мы не админим виртуалки клиента, то и на блох не указываем. Пока они оттуда не полезут, конечно. Если видим, что происходит какая-то фигня, то связываемся с заказчиком и лечим проблемную машину. Плюс есть NDA и прочие соглашения, по которым мы не можем лезть внутрь серверов клиента без его ведома.
Соответственно и сертифицируются наши linux-администраторы по программе RedHat: RHCE — минимальный уровень, для допуска к продуктивному серверу.
Многие считают, что этот уровень ни о чём не говорит, потому что экзамен проверяет только базовые знания по развёртыванию стандартных сервисов (ссылка). Почему выбрали именно его, и как готовятся и сдают ваши сотрудники?

Расскажите про географически распределённые кластеры, anycast, multihoming, а так же про storage resiliency. Будет очень интересно прочесть.
И есть ли RHCA, который действительно что-то значит.
MMik,navion, спасибо за комментарии.

Выбрали RHCE, потому что большая часть поддерживаемых нами ОС — это именно Red Hat и CentOS. К тому же по нашему опыту данный вид сертификации наиболее хорошо проработан с точки зрения общего понимания работы ОС.

Основной рабочий опыт инженеры получают непосредственно в процессе решения эксплуатационных задач по поддерживаемым клиентским системам. У нас внутри есть механизм кураторства для новичков :-)

Пожелания рассказать о географически распределённых кластерах, anycast, multihoming и storage resiliency учтем. Ждите в наших будущих статьях :-)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий