Стабильность — признак мастерства

ФО́� РУМ, (лат. forum) - Площадь в древнем Риме, на которой сосредоточивалась общественная жизнь города (ист.).

|| перен. употр. для обозначения того, что является центром, средоточием чего-нибудь.

Как задать вопрос докладчику?

• Через веб-форму http://techforum.mail.ru/question

• SMS на номер 2420, начиная сообщения с ZAL1 или ZAL2 (стоимость SMS сообщения 1.7 рубля)

• Twitter: #ZAL1 и #ZAL2

Стабильность – признак мастерства.

Важна ли стабильность для интернет-проекта?

Большинство сервисов в интернете бесплатно.

Порог вхождения в конкурирующие сервисы очень низкий.

О́трицательные эмоции полученные от недоступности сайта помнятся дольше и ощущаются сильнее, чем положительные.

Средний uptime интернет-сервиса: 98.60%.

Что такое 98.60% ?

7356 минут простоя в год.

123 часа простоя в год. 5 суток простоя в год.

Средний uptime крупных сайтов рунета: 99.96%.

(примерно 4 часа простоя в год).

Немного статистики:

Немного статистики:

8%1%

25%

50%

16%

Количественное распределение :

Сетевые аварии

Аварии датацентров

Программные аварии

Аварии при деплое

Аварии оборудования

30%

30%

15%

20%

5%

Качественное распределение:

10 причин иметь мониторинг

Вы не должны узнавать о вашей проблеме от ваших пользователей.

О́бсуждение downtime-а приносит больший урон репутации, чем сам downtime.

По закону Мерфи ваш сайт обязательно упадет. Чем раньше вы узнаете о проблеме – тем быстрее она будет решена.

Большинство ISP не будет нести ответственность за downtime вашего сайта.

10 причин иметь мониторинг

Хороший мониторинг расскажет не только то, что ваш сайт лежит, но и почему именно.

Стоимость создания мониторинга ничтожна по сравнению со стоимостью разработки сервиса.

Без мониторинга невозможно отследить системные проблемы в разработке. С вашим вебсайтом может быть все ок, но в остальном интернете его никто не увидит.

Вы должны знать о проблеме даже ночью (в России 9 часовых поясов).

Какие мониторинги бывают в Mail.ru?

Мониторинг сетевой доступности.

Мониторинг скорости работы сайта.

Мониторинг работы сервиса (ответ по HTTP). Функциональный мониторинг сервисов.

Мониторинг заполняемости хранилищ данных.

В Mail.ru более 140 различных типов мониторингов и более 150 тысяч объектов наблюдения.

Мониторинг статистических выбросов. Мониторинг мониторинга.

Как добиться аптайма в 100% ?

Резервирование и балансировка

Различные уровни резервирования:

Автоматический ввод резерва.

Тип сервера Необходимое резервирование

Сервера обработки данных N+1

Хранилища данных 2N + offline копия

Сеть 35%

Quagga

Keepalived

Router

IPVS

Что нужно что бы сделать отказоустойчивую систему:

Простейший роутер с поддежкой RIP

Средство общения с роутером по RIP.

Балансировщик и энкапсулятор траффика в IPencap.

Утилита проверки живости серверов.

Internet

Датацентр 1

Quagga

Группа серверов

Router

IPVS

Keepalived

RIP: updateRIP: poison reverse

IPencap

траффикПроверка

работы фермыПрямой,

неинкапсулированный

ответ сервера

Об

новлени

е табл

иц

ы

IPV

SОтвет

пользователю

В другой

датацентр Запрос

Internet

Датацентр 1 Датацентр 2

QuaggaIPVSKeepalived

Группа серверов Группа серверов

QuaggaIPVSKeepalived

QuaggaIPVSKeepalived

Router Router

QuaggaIPVSKeepalived

Балансировщик Балансировщик Балансировщик Балансировщик

Для того что бы все это на самом деле заработало:

1. Патчим таймеры RIP-update в Кваге уменьшая их до 1 сек.2. Патчим Квагу еще раз так, что бы административно выставленная RIP-метрика не попадала в poison reverse пакет.

4. Выключаем IRQbalance, балансировать будем вручную.

3. Патчим KeepAlived таким образом что бы пакет уходящий на real server был 1500 байт.

Модульная архитектура проекта.

Кешируйте «негативные» ответы.

Разделяйте нагрузку по типам.

Деградируйте сервис вместо того, что бы «упасть» целиком.

Работайте с модулями асинхронно.

Релиз-менеджмент и тестирование

Чем более автоматизирован процесс релиза – тем меньше сюрпризов.

Половина проблем стабильности связанно с релизом нового кода. Релиз менеджменту - быть.

Сплит-тестирование.

Каждый раз релизим «все», а не только готовое.

Прогнозирование нагрузки

Помните о специфике вашего проекта.

Имейте оценку нагрузки релиза, пусть даже неточную.

Следите за графиками.

Часто разрабатывают популярные фичи одни люди, а прогнозируют нагрузку другие.

Имейте пороговое значение времени ответа.

Планирование аварий

Время потраченное на придумывание воркэраунда можно сэкономить, если спланировать аварию заранее.

Автоматизированная выкатка бекапа.

Заглушки и «лайт-версии».

Верить нельзя никому!

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

Проверьте сами, что все заработало.

Любые планы восстановления после сбоя должны регулярно проверяться. Бекапы.

Вопросы?

Владимир Габриелянgabrelyan@corp.mail.ru

СПАСИБО́!