Embed Size (px)
Citation preview
Как организовать службу эксплуатации вашего проекта
Николай Сивко
План• Задачи• Экономика• Команда• Архитектура• Выбираем технологии• Uptime• Взаимодействие с разработкой• Deploy
Задачи: • Всё настроить (из горы железа сделать
“инфраструктуру”)• Выкладывать новый код• Обновлять всякое другое ПО• Следить, чтобы ничего не сломалось• Чинить, если сломалось/тупит• Знать, как это всё работает
Экономика• Хостинг+
• Люди
• Консалтинг
• Софт/сервисы
Экономика: хостингПрикинем на средне-маленький проект
2 x frontend: CPU + 4Gb RAM + SSD4 x backend: CPU + 8Gb RAM + SSD2 x DB: CPU + 64Gb RAM + SSD
Экономика: хостинг=облако• DigitalOcean: 2*40 + 4*80 + 2*640 = 1680$
• AWS: 2*38+4*75 + 2*689 = 1754$
• Selectel: 2*3700+4*4318+2x35000 = 1452$
Экономика: хостинг=dedicated• OVH: 2*69 + 4*69 + 2*147 = 708$
• Servers.com: 2*97+4*97+ 2*839 = 2260$
• Selectel: 2*8600+4*8600+2*15550 = 1275$
*получили сильно больше ресурсов
Экономика: хостинг=железо• SM: 2*1600+ 4*1600 + 2*4800= 19200$ =
800$/месяц (на 2 года)
• Colocation: ~30тр=463$ за ½ стойки/месяц
• Итого: 1263$/месяц
Экономика: хостингЦена, avg + -
Облако 1650 $ • Можно добавлять/убирать серверы быстро
• LB, storage, backup• Не паримся про поломки железа
• Часто недополучаете ресурсы• Latency на diskio/net
Dedicated 1414 $ • Получили сильно больше ресурсов относительно облака
• Бывает доступно: LB, storage, backup• Не паримся про поломки железа*
• Может быть setup fee• Получить новый сервер 1h-7d• Платим всегда за месяц
Свое 1263 $ • Получили сильно больше ресурсов относительно облака
• Затраты на покупку – CAP• Можем купить любую конфигурацию
• Большие первоначальные вложения• Нужно покупать сетевые железки• Паримся про поломки железа
Экономика: каналы• Оптика по Москве: ~50тр за 1 ОВ
– Часто хватает 1 OB + уплотнение• IP transit:
– 1Gb/s: 30+ тр– 10Gb/s: 150+ тр– 20Gb/s: 200+ тр
• Peering:MSK-IX: 1Gb/s ~30тр, 10Gb/s ~90трData-IX: бесплатно для контент генераторов
Экономика: люди• Junior admin: 100тр+• Senior admin: 150тр+ • DBA: 150тр+• Сетевик: 150тр+
+ налоги + офис + мебель + печеньки
Экономика: консалтинг• Стоимость консалтинга ~ 0.5-5 ЗП спеца
• Если консультация разовая, платим больше
• Постоянная поддержка дешевле
• Можете получить целую команду 24x7 за ЗП 1 спеца в штат
Экономика: cофт и cервисы• Обычно вы покупаете то, что можно сделать из open
source + время ваших сотрудников
• Вы получаете уже реализованный функционал с поддержкой
• Обычно софт/сервис дешевле, так как он делается для многих компаний
Экономика: cофт и cервисы• Делаем внутри замену чего-то простого:
• Прототип будет через ½ месяца• Реализация оставшихся 60% функционала - еще месяц• Поддержка и улучшения ¼ месяца в месяц
За год потратим (½+1+¼*12)*150 = 675тр (если делал senior) – можно сравнить со стоимостью софта/сервиса
Экономика: cофт и cервисыЧто вообще может понадобится покупать:• Безопасность: WAF, AntiDDOS• Инфраструктура: доставка почты, CDN, dedicated
storage, backup сервисы, конвертация видео,...• Мониторинг: сам мониторинг, процессинг
логов, аналитика ошибок, профилирование
Экономика: ИМХО• Люди – самый дорогой ресурс
• Нужно всегда помнить, что время ваших сотрудников не бесплатное
• Сервисы и консалтинг позволяют не заниматься непрофильными задачами и не нанимать экспертов
Экономика: ИМХО• Для больших закупок лучше делать мини-
тендеры, чтобы просто поставщиков “столкнуть лбами”
• При закупках брэндового железа, нужно начинать с общения с вендором, он даст поставщика и обеспечит его скидкой (диапазон скидок: 40-80%)
Команда• Кто такой админ?• Стадии развития админа• Тимлид• Нанимаем• Распространение знаний• Командная работа
Команда: кто такой админ?• Это НЕ угрюмый и злой разработчик, который
перестал писать код :)
• Большой кругозор в ПО• Постоянные вопросы: как это работает?• Гипертрофированное чувство ответственности• Цель в работе – ничего не делать
Команда: экспертизаКак работает OS:• Процессы, сигналы, лимиты, привилегии• Файловые системы• Ядро, драйверы, syscalls, другие интерфейсы ядра• Память: кэши, shared mem, huge pages…• Пакетные менеджеры• Системное: syslog, time/ntp/tz, ssh, sudo,…
Команда: экспертизаКак работает сеть:• Физика: arp, ethernet, оптика, уплотнение• Протоколы: ip, tcp, icmp, app-level protos• Роутинг: static, ospf, bgp,…• Коммутация: stp, mpls, lacp,…• Железки
Команда: экспертизаКак примерно работают БД:• Процессы/треды• MVCC• Индексы, кэши, prepared statements• Backup/restore• Репликация• Работа с диском, сетью
Команда: экспертизаКак работают сервисы:• Архитектура: process/thread/event loop• Работа с ресурсами: память/диск/сеть• Лимиты: обработчики, память, …• Диагностика: логи, статусы• Фичи
Команда: экспертизаИнструментарий:• Автоматизация: shell, sed, awk,…• Скриптинг: perl, python, некоторые даже
golang• Дебаг: ping, traceroute, tcpdump, perf, strace,
…
Команда: стадии развития админаНачальный уровень:
• смог настроить, чтобы заработало• troubleshooting – АД• если нет того, кто подскажет, спрашивает на
форумах, невнятно гуглит
Команда: стадии развития админаЭмпирический опыт:
• Покрутил ручку – стало лучше, запомнил, всегда крутит при случае
• Не понимает, почему стало лучше• Может решать много стандартных проблем, крутя
ручки, которые запомнил
Команда: стадии развития админаПервая стадия просветления:
• Начал понимать, как на самом деле все работает• Делает предположения и их проверяет• Крутит ручки вдумчиво, внятно оценивает
результативность• Докапывается, почему помогло
Команда: стадии развития админаВторая стадия просветления:
• Понял, что можно читать код софта, БД, ядра• Сразу понимает, какая ручка может помочь• Вовремя понимает, что данный софт не
справляется по построению и надо менять
Команда: стадии развития админа
Дальше наверное что-то еще есть, но я застрял на предыдущем уровне :)
Команда: стадии развития админа• Очень большой процент остается на стадии
“эмпирический опыт”
• Есть люди, которые проходят эту стадию быстро: помогает атмосфера в команде, правильные вопросы от тимлида
• Если в команде нет ни одного “просветленного” – всё пропало :)
Команда: тимлид• Вам нужен “просветленный” + способный работать с
людьми• Нет денег на такого - нужно аутсорсить эксплуатацию• Не можете оценить квалификацию – найдите
консалтера, пусть поможет со вторым этапом интервью
• Способность руководить – оценивайте сами
Команда: нанимаем• Нанимаем только просветленных или тех, кто точно
осилит просветлиться
• Не умеете отличить потенциальных, нанимайте сразу нормальных - их проще отличить
• Позже сами поймете, что можете находить смышленых и учить их
Команда: распространение знаний• Каждый должен уметь делать все
стандартные операции
• С помощью wiki
• Или SCM (software configuration management)
Команда: поток задач• Есть backlog + приоритеты, как правило он бесконечен
• С заказчиками можно договориться про SLA на время реакции на critical/blocker задачи
• Учите заказчиков не искать других путей постановки задач и коммуникаций по задачам кроме issue tracker
Команда: если завязли в рутине• Профилируем• Коммуникация – часто очень дорого, требуем
формализовать задачи• Можно автоматизировать?• Может помогут чудо-технологии? :)• Может часть задачи переложить на
разработчиков? (их как правило больше)
Команда: “задачи развития”• Автоматизация части рутины
• Протестировать технологию X для задачи
• Убрать костыль Y
Команда: “задачи развития”• Формулируем• Список “неизвестных”• Исследуем возможность решения способом Х• Не получается протестировать за несколько дней –
ищем варианты• Вытаскиваем человек(а|ов) из “рутины”• Внедряем дальше или ищем варианты
Команда: ИМХО• Либо “правильный админ”, либо аутсорсим
• Хотя бы один должен НЕ быть социопатом
• Админы склонны биться над задачей до последнего, если это не то, что вы хотите – проговаривайте сразу
Команда: ИМХО• Микроменеджмент недопустим – у вас же
команда “просветленных”, они могут и должны думать сами
• Но нужно ставить рамки, лучше в ходе обсуждения в команде
Архитектура• Отказоустойчивость
• Масштабируемость
• Практика
Архитектура: отказоустойчивостьОтказоустойчивость - всегда избыточность:
• Компоненты железа: raid, блоки питания, компоненты сетевых железок
• Сеть: multipath, дублирование оборудования
• На уровне серверов
Архитектура: масштабируемостьВозможность добавить ресурсов и получить больше производительности
• Вертикальная
• Горизонтальная
Архитектура: практика• Точка входа: фронтенды
• Данные: бд
• Бэкенды
• Вспомогательные сервисы
Архитектура: точка входа• DNS RR: не знает о доступности серверов
• Shared IP: vrrp, carp
• DNS RR между shared IPs
Архитектура: точка входаЕсли есть cетевые железки на входе:• cisco: равнозначные статические маршруты
+ IP SLA checks
• juniper: равнозначные статические маршруты + BFDd + monit
Архитектура: данные в БД• Практически всегда нужно иметь реплики
• На мастер только INSERT/UPDATE + SELECT, чувствительные к replication lag
• Основной функционал у большинства - чтение, пробуйте работать при неработающем мастере
Архитектура: данные в БД• Реплики можно поставить за балансер (TCP)
• Но дублируется трафик + вносим дополнительные задержки
• На TCP балансере сложно понять жива база или нет
Архитектура: данные в БД• Лучше научить приложение работать с
несколькими репликами
• Можно делать умные retry на другой сервер и не отдавать пользователям ошибки
Архитектура: данные в БД• Всегда нужно понимать, сколько живых
реплик требуется для работы
• Периодически тестируем отказ реплики
Архитектура: данные в БДЧто происходит при проблемах с master:
• Решаем, что будем переключаться (может быстрее починить текущий сервер?)
• Переключаем на один из slave
• Переключаем остальные slave на новый мастер
• Чиним старый сервер, делаем его репликой
Архитектура: данные в БД• Переключение мастера на автомате – очень стрёмно!
• Лучше взять под БД железо по-надежнее
• Сделать инструкцию/скрипт
• и провести учения
Архитектура: данные в БД• Репликация – не бэкап
• Нужно делать backup + копировать WAL
• Можно иметь реплику, отстающую на N минут
Архитектура: бэкенды• Бэкенд должен быть stateless
• Отдаем правильные статусы при проблемах: не нужно брать лишние запросы при перегрузе, отдаем 503, балансер сделает retry на соседа
• Если балансер умеет health checks – делаем внятный /status: проверяем, что есть соединение с БД итд
Архитектура: memcached• Нужен ли кэш?
• Живет ли сайт при пустом MC?
• Насколько эффективен кэш?
• Шардинг/решардинг
• Таймауты
• Трафик/задержки
Архитектура: очереди сообщений• At least one / at most one
• Надежность хранения
• Производительность
• Что происходит, если брокер лежит (умер диск с 10М сообщениями)
• Кластеризация брокера (из коробки, сами)
• Мониторинг
Uptime: суть работы админа• Мониторинг
• Работа с инцидентами
• Учения
Мониторинг: задачи • Оповещение: узнать, что есть проблема
• Сокращение длительности инцидентов: показать, где проблема
• Инструмент анализа работы проекта: от оптимизаций до отслеживания бизнес показателей
Мониторинг: оповещениеЧто значит “сайт не работает”:
• Внешние проверки• HTTP-5xx ответов больше чем N в секунду• Медленных ответов > 10%
Мониторинг: внешние проверки• Покрывают не все страницы• Не позволяют хорошо замерить время
ответа
Мониторинг: по логам• Сколько было запросов: как
обычно/больше/меньше
• Сколько было ошибок
• Времена ответов: на сколько масштабны были тормоза
Мониторинг: по логам
Мониторинг: правильные severity• CRITICAL: уведомляем по SMS/IM
• WARNING: можно уведомлять на email или без уведомления
• INFO: без уведомления
Мониторинг: CRITICAL• Сайт не работает
• Ошибки приема платежей
• Пропал поток покупок
Мониторинг: CRITICAL• Бросаем все и чиним
• Починку нельзя отложить
• Никто никуда не уходит пока есть проблема
Мониторинг: WARNING• Диск кончается
• Какой-то сервис не доступен, дает много ошибок или тупит
• Много ошибок на сетевом интерфейсе
• Сервер недоступен
• Swap IO процесса > 1 Mb/s
Мониторинг: WARNING• Желательно закрыть в течении дня
• Если алерт не по делу – добавляем исключение
• Если часто флапает - сглаживаем
Мониторинг: INFO• CPU usage > 99%
• Disk IO > 99%
• Использование других ресурсов
Мониторинг: INFO• Используем как подсказки во время поиска
причин CRITICAL или WARNING
• Если загораются бессмысленные алерты – добавляем исключения
Мониторинг: покрытие• Определяем CRITICAL• Все внешние сервисы: БД, очереди, …• Свои сервисы• Бизнес показатели• Железо
Мониторинг: свои сервисы• Потребление ресурсов
• Активность: запросы, cache hit rate, …
• Общение с внешними сервисами: запросы, ошибки, времена ответа
• Значимые вычисления
• Какие-то состояния: размер кэша, количество соединений
Мониторинг: дашборды• Основной сводный: показывает состояние с точки зрения
пользователя и кратко про все подсистемы
• Видно где что-то не так
• По каждой подсистеме свой подробный дашборд
• 2 шага при поиске проблемы уже нормально
Мониторинг: триггеры• Алерты должны показывать причину проблем
• Зависимости и автомагия не нужны
• Глазами можно быстро просмотреть 100+ алертов и выбрать подходящий
• Алертам, которые не помогают, можно понизить severity
Мониторинг: работа с инцидентами• Downtime нужно считать
• Полезно классифицировать проблемы (по зоне ответственности, компонентам системы)
• Обязательно докопаться до причины проблемы
Мониторинг: работа с инцидентами• Админы работаю аккуратнее, если все проблемы
фиксируются и потом разбираются
• Если нужно разломать prod - заранее объявляем плановый downtime
• Сравниваем uptime между периодами, делаем выводы
Мониторинг: работа с инцидентами• Uptime - отличный KPI для админов
• Но отвечать можно только за то, что они в силах исправить
• Выделяем классы проблем, за которые будем отвечать
• Бонус = f(uptime)
Мониторинг: учения• Кроме того, что текущие проблемы
решаются, бизнесу нужна уверенность, что новые проблемы будут решены
• Это хорошо показывают учения
Мониторинг: ученияВыписываем риски:• Умер сервер master БД• Умер ДЦ• ddos• Нас взломали, увели базу, cookie
Мониторинг: учения• Планируем действия, пишем сценарий
• Объявляем downtime и эмулируем ситуацию
• Действуем только по инструкции
• Замеряем время восстановления
Мониторинг: учения• По результатам исправляем инструкцию
• Повторяем, пока инструкция не заработает
• Пробуем уменьшить время восстановления
Выбор технологий• Физика• Здравый смысл• Экспертиза• Выбираем nosql
ФизикаL1 cache 0.5 ns
L2 cache 5 ns
Memory 100 ns
Compress 1K bytes with Snappy 3 000 nsSend 1K bytes over 1 Gbps network 10 000 ns
Read 4K randomly from SSD 150 000 ns
Read 1 MB sequentially from memory 250 000 ns
Round trip within same datacenter 500 000 ns
Read 1 MB sequentially from SSD 1 000 000 ns
Disk seek 10 000 000 ns
Read 1 MB sequentially from disk 20 000 000 ns
Send packet CA->Netherlands->CA 150 000 000 ns
Физика• За счет чего прирост производительности?• За счет чего лучше надежность?• За счет чего меньше задержки?• За счет чего latency стабильнее?
Здравый смысл• KISS (Keep it simple, (stupid|short|small…))
• Нужно хорошо думать, как не перемудрить
Здравый смысл• Всегда нужно помнить, какую проблему мы
решаем
• Формулируем требования
Здравый смысл• Можно ли пренебречь какими-то
требованиями?
• Чем уже область применения какого-либо решения, тем оно проще
Здравый смысл• Приносит ли решение новые проблемы?
• Можно ли не решать эту проблему сейчас?
Экспертиза• Приоритет у технологий, для которых у нас
есть экспертиза внутри
• Сможем ли мы купить поддержку
• Сможем ли нанять людей с экспертизой?
Выбираем nosql• Write path + latency
• Read path + latency
• Сохранность данных
• Overhead на хранение данных
Выбираем nosql• Репликация
• Consistency
• Что происходит при -1 нода?
• Сколько нод можно потерять?
• Как меняется нагрузка на оставшиеся?
Выбираем nosql• Точка входа: нужна ли балансировка или клиент
умеет ходить по списку нод
• Шардинг: равномерность, кто роутит
• Вопросы про клиент: timeouts, retries, load balancing
Выбираем nosql• Как добавить ноду
• Как выключить ноду
• Upgrade кластера
• Backup/restore
• Мониторинг
Выбираем nosql• Тестируем производительность на объеме данных и нагрузке
5x от расчетных за год
• Тестируем отказы, смотрим логи (kill -9 на процесс, firewall на N минут итд)
• Читаем issue tracker проекта: обращаем внимание на баги – их серьезность, скорость закрытия, возможные workaround
Взаимодействие с разработкой• Админам интересен стабильный прод
• Разработчикам быстрая доставка фич до пользователей
Взаимодействие с разработкой• Конфликт интересов – это хорошо
• Но, чтобы работа не встала нужно договариваться
Взаимодействие с разработкой• SLA на время реакции админов на задачи
от разработки
• Админ может не выпускать задачу, если видит, что не полетит
Взаимодействие с разработкой• Defenition of done задачи у разработчика =
“Задача в production”
• Разработчик заинтересован выполнить все здравые требования админов
Взаимодействие с разработкой• Чтобы как можно раньше узнавать о возможных проблемах, нужно
общаться
• Совместное проектирование: AB, design docs, …
• Разработчики получают дополнительную экспертизу про отказоустойчивость, производительность
• Админы получают более качественный код, в котором учтены их требования
Взаимодействие с разработкой• Конфликты неизбежны
• Идеально, если админы и разработка – разные подразделения
• В этом случае рефери – начальство
• Это на крайний случай, но стимулирует договариваться
Deploy• Чем меньше изменений за одну итерацию,
тем лучше
• Готово ли тестирование?
• Готова ли инфраструктура?
Deploy: тестирование• Должно тестироваться в похожем на prod окружении
(балансеры, таймауты)
• Сборка должна включать все необходимые изменения в окружении
• Несколько версий должны уметь работать параллельно
Deploy: инфраструктура• Формулируем критерии успешной работы
сервиса в мониторинге
• Мы должны быстро понимать, работает ли новая версия или нет
• Атомарная выкладка на N серверов невозможна
Deploy: инфраструктура• Rolling upgrade – катим в N потоков
• Graceful reload сервиса – дорабатываем текущие запросы, новые не берем – они ретраятся на соседей
Deploy: инфраструктура• Если приложению нужен прогрев, это
должно происходить до того, как на него пойдут пользовательские запросы
• Процесс выкладки не должен сопровождаться ошибками
Deploy: инструментарий• Вы должны понимать, что происходит в каждый
момент времени
• Вы должны быть в состоянии исправить руками любую ошибку в конфигурации
• Лог изменений: кто, что делал
Deploy: общение с разработкой• Changelog – важно понимать, что изменилось с
точки зрения работы приложения
• Инструкция, если выкладка нестандартная
• Rollback инструкция, если были изменения схемы БД итд
Deploy: общение с разработкой• Если у вас много сервисов, деплоим всё
равно по одному
• За очередностью выхода сервисов должны следить разработчики (через последовательную постановку задач)
Deploy: общение с разработкой• Учимся избегать изменения схемы БД
(дублирование данных, работа с 2 версиями, миграция, удаления старого)
