На сегодняшний день высокая доступность сервисов требуется всегда и везде, не только в крупных дорогих проектах. Временно недоступные сайты с сообщением «Извините, проводится техническое обслуживание» ещё встречаются, но обычно вызывают снисходительную улыбку. Прибавим к этому жизнь в облаках, когда для запуска дополнительного сервера нужен лишь один вызов к API, причем думать о «железной» эксплуатации не надо. И уже не остается оправданий, почему критичная система не была сделана надежно с использованием кластерных технологий и резервирования.

Мы расскажем, какие решения мы рассматривали для обеспечения надёжности баз данных в своих сервисах и к чему пришли. Плюс демо с далеко идущими выводами.

Январь 2005
(Я написал эту речь для выступления перед выпускниками школы. Мне не удалось с ней выступить, так как школьная администрация запретила меня приглашать.)

Когда я рассказал, что меня пригласили выступить перед старшеклассниками, мои друзья очень заинтересовались. Что такого ты мог бы им рассказать? Я же поинтересовался у них, что бы они хотели услышать от более опытного взрослого, когда учились в школе? И теперь я расскажу вам, что мы все хотели бы знать еще в школе.

Как-то стал свидетелем разговора двух приятелей и услышал:
«У вас уже внедряют DevOps? Просто у нас в МегаТелеКо все идет полным ходом! Недавно мы набрали команду DevOps из 35 человек!»

Так почему нанять команду DevOps это плохая идея?

В тот момент я удержался от фейспалма в стиле Капитана Пикара. К несчастью, найм сотрудников на должность, содержащую слово DevOps и радость участника этого разговора по этому поводу не случайное заблуждение. По быстрому обзору источников в интернете следует, что множество компаний ищут инженеров DevOps, которые в числе прочих будут заниматься:

• автоматизацией изменений в инфраструктуре
• настройкой JIRA
• администрированием MySQL
• поддержкой масштабных Linux проектов
• ведением всего, что связано с puppet
• написанием скриптов на ruby, python или bash
• оперативным подпиранием «костылями» тут и там

Статья расчитана на людей, хорошо знакомых с продуктом System Center Operations Manager.

Терминология:
SCOM — вместо полного названия;
Алерт — то же самое, что alert. Просто хорошего аналога в русском языке нет.

Введение

В SCOM, в отличие от многих других систем мониторинга, алерт является самостоятельным объектом. В зависимости от настроек, проверка может быть уже зеленой, но алерт так и оставаться активным. Алерты используются и обрабатываются:

• оператором (человеком)
• стандартными коннекторами (например, Command Channel)
• внешними коннекторами (например, коннектор для синхронизацией с системой Service Desk)