Слайды с мастер-класса по эксплуатации. Эти тезисы мы обсуждали 6 часов.

1. Как организовать службу
эксплуатации вашего проекта
Николай Сивко

2. План
• Задачи
• Экономика
• Команда
• Архитектура
• Выбираем технологии
• Uptime
• Взаимодействие с разработкой
• Deploy

3. Задачи:
• Всё настроить (из горы железа сделать
“инфраструктуру”)
• Выкладывать новый код
• Обновлять всякое другое ПО
• Следить, чтобы ничего не сломалось
• Чинить, если сломалось/тупит
• Знать, как это всё работает

4. Экономика
• Хостинг+
• Люди
• Консалтинг
• Софт/сервисы

5. Экономика: хостинг
Прикинем на средне-маленький проект
2 x frontend: CPU + 4Gb RAM + SSD
4 x backend: CPU + 8Gb RAM + SSD
2 x DB: CPU + 64Gb RAM + SSD

6. Экономика: хостинг=облако
• DigitalOcean: 2*40 + 4*80 + 2*640 = 1680$
• AWS: 2*38+4*75 + 2*689 = 1754$
• Selectel: 2*3700+4*4318+2x35000 = 1452$

7. Экономика: хостинг=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$
*получили сильно больше ресурсов

8. Экономика: хостинг=железо
• SM: 2*1600+ 4*1600 + 2*4800= 19200$ =
800$/месяц (на 2 года)
• Colocation: ~30тр=463$ за ½ стойки/месяц
• Итого: 1263$/месяц

9. Экономика: хостинг
Цена, avg + -
Облако 1650 $ • Можно добавлять/убирать серверы
быстро
• LB, storage, backup
• Не паримся про поломки железа
• Часто недополучаете ресурсы
• Latency на diskio/net
Dedicated 1414 $ • Получили сильно больше ресурсов
относительно облака
• Бывает доступно: LB, storage, backup
• Не паримся про поломки железа*
• Может быть setup fee
• Получить новый сервер 1h-7d
• Платим всегда за месяц
Свое 1263 $ • Получили сильно больше ресурсов
относительно облака
• Затраты на покупку – CAP
• Можем купить любую конфигурацию
• Большие первоначальные вложения
• Нужно покупать сетевые железки
• Паримся про поломки железа

10. Экономика: каналы
• Оптика по Москве: ~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: бесплатно для контент генераторов

11. Экономика: люди
• Junior admin: 100тр+
• Senior admin: 150тр+
• DBA: 150тр+
• Сетевик: 150тр+
+ налоги + офис + мебель + печеньки

12. Экономика: консалтинг
• Стоимость консалтинга ~ 0.5-5 ЗП спеца
• Если консультация разовая, платим больше
• Постоянная поддержка дешевле
• Можете получить целую команду 24x7 за ЗП 1 спеца в
штат

13. Экономика: cофт и cервисы
• Обычно вы покупаете то, что можно сделать из
open source + время ваших сотрудников
• Вы получаете уже реализованный функционал
с поддержкой
• Обычно софт/сервис дешевле, так как он
делается для многих компаний

14. Экономика: cофт и cервисы
• Делаем внутри замену чего-то простого:
• Прототип будет через ½ месяца
• Реализация оставшихся 60% функционала - еще месяц
• Поддержка и улучшения ¼ месяца в месяц
За год потратим (½+1+¼*12)*150 = 675тр (если делал
senior) – можно сравнить со стоимостью
софта/сервиса

15. Экономика: cофт и cервисы
Что вообще может понадобится покупать:
• Безопасность: WAF, AntiDDOS
• Инфраструктура: доставка почты, CDN,
dedicated storage, backup сервисы,
конвертация видео,...
• Мониторинг: сам мониторинг, процессинг
логов, аналитика ошибок, профилирование

16. Экономика: ИМХО
• Люди – самый дорогой ресурс
• Нужно всегда помнить, что время ваших
сотрудников не бесплатное
• Сервисы и консалтинг позволяют не
заниматься непрофильными задачами и не
нанимать экспертов

17. Экономика: ИМХО
• Для больших закупок лучше делать мини-
тендеры, чтобы просто поставщиков
“столкнуть лбами”
• При закупках брэндового железа, нужно
начинать с общения с вендором, он даст
поставщика и обеспечит его скидкой
(диапазон скидок: 40-80%)

18. Команда
• Кто такой админ?
• Стадии развития админа
• Тимлид
• Нанимаем
• Распространение знаний
• Командная работа

19. Команда: кто такой админ?
• Это НЕ угрюмый и злой разработчик, который
перестал писать код :)
• Большой кругозор в ПО
• Постоянные вопросы: как это работает?
• Гипертрофированное чувство ответственности
• Цель в работе – ничего не делать

20. Команда: экспертиза
Как работает OS:
• Процессы, сигналы, лимиты, привилегии
• Файловые системы
• Ядро, драйверы, syscalls, другие интерфейсы ядра
• Память: кэши, shared mem, huge pages…
• Пакетные менеджеры
• Системное: syslog, time/ntp/tz, ssh, sudo,…

21. Команда: экспертиза
Как работает сеть:
• Физика: arp, ethernet, оптика, уплотнение
• Протоколы: ip, tcp, icmp, app-level protos
• Роутинг: static, ospf, bgp,…
• Коммутация: stp, mpls, lacp,…
• Железки

22. Команда: экспертиза
Как примерно работают БД:
• Процессы/треды
• MVCC
• Индексы, кэши, prepared statements
• Backup/restore
• Репликация
• Работа с диском, сетью

23. Команда: экспертиза
Как работают сервисы:
• Архитектура: process/thread/event loop
• Работа с ресурсами: память/диск/сеть
• Лимиты: обработчики, память, …
• Диагностика: логи, статусы
• Фичи

24. Команда: экспертиза
Инструментарий:
• Автоматизация: shell, sed, awk,…
• Скриптинг: perl, python, некоторые даже
golang
• Дебаг: ping, traceroute, tcpdump, perf, strace,
…

25. Команда: стадии развития админа
Начальный уровень:
• смог настроить, чтобы заработало
• troubleshooting – АД
• если нет того, кто подскажет, спрашивает на
форумах, невнятно гуглит

26. Команда: стадии развития админа
Эмпирический опыт:
• Покрутил ручку – стало лучше, запомнил,
всегда крутит при случае
• Не понимает, почему стало лучше
• Может решать много стандартных проблем,
крутя ручки, которые запомнил

27. Команда: стадии развития админа
Первая стадия просветления:
• Начал понимать, как на самом деле все работает
• Делает предположения и их проверяет
• Крутит ручки вдумчиво, внятно оценивает
результативность
• Докапывается, почему помогло

28. Команда: стадии развития админа
Вторая стадия просветления:
• Понял, что можно читать код софта, БД, ядра
• Сразу понимает, какая ручка может помочь
• Вовремя понимает, что данный софт не
справляется по построению и надо менять

29. Команда: стадии развития админа
Дальше наверное что-то еще есть, но я
застрял на предыдущем уровне :)

30. Команда: стадии развития админа
• Очень большой процент остается на стадии
“эмпирический опыт”
• Есть люди, которые проходят эту стадию быстро:
помогает атмосфера в команде, правильные
вопросы от тимлида
• Если в команде нет ни одного “просветленного” –
всё пропало :)

31. Команда: тимлид
• Вам нужен “просветленный” + способный
работать с людьми
• Нет денег на такого - нужно аутсорсить
эксплуатацию
• Не можете оценить квалификацию – найдите
консалтера, пусть поможет со вторым этапом
интервью
• Способность руководить – оценивайте сами

32. Команда: нанимаем
• Нанимаем только просветленных или тех, кто точно
осилит просветлиться
• Не умеете отличить потенциальных, нанимайте
сразу нормальных - их проще отличить
• Позже сами поймете, что можете находить
смышленых и учить их

33. Команда: распространение знаний
• Каждый должен уметь делать все стандартные
операции
• С помощью wiki
• Или SCM (software configuration management)

34. Команда: поток задач
• Есть backlog + приоритеты, как правило он
бесконечен
• С заказчиками можно договориться про SLA на
время реакции на critical/blocker задачи
• Учите заказчиков не искать других путей постановки
задач и коммуникаций по задачам кроме issue
tracker

35. Команда: если завязли в рутине
• Профилируем
• Коммуникация – часто очень дорого, требуем
формализовать задачи
• Можно автоматизировать?
• Может помогут чудо-технологии? :)
• Может часть задачи переложить на
разработчиков? (их как правило больше)

36. Команда: “задачи развития”
• Автоматизация части рутины
• Протестировать технологию X для задачи
• Убрать костыль Y

37. Команда: “задачи развития”
• Формулируем
• Список “неизвестных”
• Исследуем возможность решения способом Х
• Не получается протестировать за несколько
дней – ищем варианты
• Вытаскиваем человек(а|ов) из “рутины”
• Внедряем дальше или ищем варианты

38. Команда: ИМХО
• Либо “правильный админ”, либо аутсорсим
• Хотя бы один должен НЕ быть социопатом
• Админы склонны биться над задачей до
последнего, если это не то, что вы хотите –
проговаривайте сразу

39. Команда: ИМХО
• Микроменеджмент недопустим – у вас же
команда “просветленных”, они могут и
должны думать сами
• Но нужно ставить рамки, лучше в ходе
обсуждения в команде

40. Архитектура
• Отказоустойчивость
• Масштабируемость
• Практика

41. Архитектура: отказоустойчивость
Отказоустойчивость - всегда избыточность:
• Компоненты железа: raid, блоки питания,
компоненты сетевых железок
• Сеть: multipath, дублирование оборудования
• На уровне серверов

42. Архитектура: масштабируемость
Возможность добавить ресурсов и получить
больше производительности
• Вертикальная
• Горизонтальная

43. Архитектура: практика
• Точка входа: фронтенды
• Данные: бд
• Бэкенды
• Вспомогательные сервисы

44. Архитектура: точка входа
• DNS RR: не знает о доступности серверов
• Shared IP: vrrp, carp
• DNS RR между shared IPs

45. Архитектура: точка входа
Если есть cетевые железки на входе:
• cisco: равнозначные статические маршруты
+ IP SLA checks
• juniper: равнозначные статические
маршруты + BFDd + monit

46. Архитектура: данные в БД
• Практически всегда нужно иметь реплики
• На мастер только INSERT/UPDATE + SELECT,
чувствительные к replication lag
• Основной функционал у большинства - чтение,
пробуйте работать при неработающем
мастере

47. Архитектура: данные в БД
• Реплики можно поставить за балансер (TCP)
• Но дублируется трафик + вносим
дополнительные задержки
• На TCP балансере сложно понять жива база
или нет

48. Архитектура: данные в БД
• Лучше научить приложение работать с
несколькими репликами
• Можно делать умные retry на другой
сервер и не отдавать пользователям
ошибки

49. Архитектура: данные в БД
• Всегда нужно понимать, сколько живых
реплик требуется для работы
• Периодически тестируем отказ реплики

50. Архитектура: данные в БД
Что происходит при проблемах с master:
• Решаем, что будем переключаться (может быстрее починить
текущий сервер?)
• Переключаем на один из slave
• Переключаем остальные slave на новый мастер
• Чиним старый сервер, делаем его репликой

51. Архитектура: данные в БД
• Переключение мастера на автомате – очень
стрёмно!
• Лучше взять под БД железо по-надежнее
• Сделать инструкцию/скрипт
• и провести учения

52. Архитектура: данные в БД
• Репликация – не бэкап
• Нужно делать backup + копировать WAL
• Можно иметь реплику, отстающую на N
минут

53. Архитектура: бэкенды
• Бэкенд должен быть stateless
• Отдаем правильные статусы при проблемах: не
нужно брать лишние запросы при перегрузе,
отдаем 503, балансер сделает retry на соседа
• Если балансер умеет health checks – делаем
внятный /status: проверяем, что есть соединение с
БД итд

54. Архитектура: memcached
• Нужен ли кэш?
• Живет ли сайт при пустом MC?
• Насколько эффективен кэш?
• Шардинг/решардинг
• Таймауты
• Трафик/задержки

55. Архитектура: очереди сообщений
• At least one / at most one
• Надежность хранения
• Производительность
• Что происходит, если брокер лежит (умер диск с 10М сообщениями)
• Кластеризация брокера (из коробки, сами)
• Мониторинг

56. Uptime: суть работы админа
• Мониторинг
• Работа с инцидентами
• Учения

57. Мониторинг: задачи
• Оповещение: узнать, что есть проблема
• Сокращение длительности инцидентов:
показать, где проблема
• Инструмент анализа работы проекта: от
оптимизаций до отслеживания бизнес
показателей

58. Мониторинг: оповещение
Что значит “сайт не работает”:
• Внешние проверки
• HTTP-5xx ответов больше чем N в секунду
• Медленных ответов > 10%

59. Мониторинг: внешние проверки
• Покрывают не все страницы
• Не позволяют хорошо замерить время
ответа

60. Мониторинг: по логам
• Сколько было запросов: как
обычно/больше/меньше
• Сколько было ошибок
• Времена ответов: на сколько масштабны были
тормоза

61. Мониторинг: по логам

62. Мониторинг: правильные severity
• CRITICAL: уведомляем по SMS/IM
• WARNING: можно уведомлять на email или
без уведомления
• INFO: без уведомления

63. Мониторинг: CRITICAL
• Сайт не работает
• Ошибки приема платежей
• Пропал поток покупок

64. Мониторинг: CRITICAL
• Бросаем все и чиним
• Починку нельзя отложить
• Никто никуда не уходит пока есть проблема

65. Мониторинг: WARNING
• Диск кончается
• Какой-то сервис не доступен, дает много ошибок или тупит
• Много ошибок на сетевом интерфейсе
• Сервер недоступен
• Swap IO процесса > 1 Mb/s

66. Мониторинг: WARNING
• Желательно закрыть в течении дня
• Если алерт не по делу – добавляем
исключение
• Если часто флапает - сглаживаем

67. Мониторинг: INFO
• CPU usage > 99%
• Disk IO > 99%
• Использование других ресурсов

68. Мониторинг: INFO
• Используем как подсказки во время поиска
причин CRITICAL или WARNING
• Если загораются бессмысленные алерты –
добавляем исключения

69. Мониторинг: покрытие
• Определяем CRITICAL
• Все внешние сервисы: БД, очереди, …
• Свои сервисы
• Бизнес показатели
• Железо

70. Мониторинг: свои сервисы
• Потребление ресурсов
• Активность: запросы, cache hit rate, …
• Общение с внешними сервисами: запросы, ошибки, времена
ответа
• Значимые вычисления
• Какие-то состояния: размер кэша, количество соединений

71. Мониторинг: дашборды
• Основной сводный: показывает состояние с точки
зрения пользователя и кратко про все подсистемы
• Видно где что-то не так
• По каждой подсистеме свой подробный дашборд
• 2 шага при поиске проблемы уже нормально

72. Мониторинг: триггеры
• Алерты должны показывать причину проблем
• Зависимости и автомагия не нужны
• Глазами можно быстро просмотреть 100+ алертов и
выбрать подходящий
• Алертам, которые не помогают, можно понизить
severity

73. Мониторинг: работа с инцидентами
• Downtime нужно считать
• Полезно классифицировать проблемы (по
зоне ответственности, компонентам системы)
• Обязательно докопаться до причины
проблемы

74. Мониторинг: работа с инцидентами
• Админы работаю аккуратнее, если все
проблемы фиксируются и потом разбираются
• Если нужно разломать prod - заранее
объявляем плановый downtime
• Сравниваем uptime между периодами, делаем
выводы

75. Мониторинг: работа с инцидентами
• Uptime - отличный KPI для админов
• Но отвечать можно только за то, что они в силах
исправить
• Выделяем классы проблем, за которые будем отвечать
• Бонус = f(uptime)

76. Мониторинг: учения
• Кроме того, что текущие проблемы
решаются, бизнесу нужна уверенность, что
новые проблемы будут решены
• Это хорошо показывают учения

77. Мониторинг: учения
Выписываем риски:
• Умер сервер master БД
• Умер ДЦ
• ddos
• Нас взломали, увели базу, cookie

78. Мониторинг: учения
• Планируем действия, пишем сценарий
• Объявляем downtime и эмулируем ситуацию
• Действуем только по инструкции
• Замеряем время восстановления

79. Мониторинг: учения
• По результатам исправляем инструкцию
• Повторяем, пока инструкция не заработает
• Пробуем уменьшить время восстановления

80. Выбор технологий
• Физика
• Здравый смысл
• Экспертиза
• Выбираем nosql

81. Физика
L1 cache 0.5 ns
L2 cache 5 ns
Memory 100 ns
Compress 1K bytes with Snappy 3 000 ns
Send 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

82. Физика
• За счет чего прирост производительности?
• За счет чего лучше надежность?
• За счет чего меньше задержки?
• За счет чего latency стабильнее?

83. Здравый смысл
• KISS (Keep it simple, (stupid|short|small…))
• Нужно хорошо думать, как не перемудрить

84. Здравый смысл
• Всегда нужно помнить, какую проблему мы
решаем
• Формулируем требования

85. Здравый смысл
• Можно ли пренебречь какими-то
требованиями?
• Чем уже область применения какого-либо
решения, тем оно проще

86. Здравый смысл
• Приносит ли решение новые проблемы?
• Можно ли не решать эту проблему сейчас?

87. Экспертиза
• Приоритет у технологий, для которых у нас
есть экспертиза внутри
• Сможем ли мы купить поддержку
• Сможем ли нанять людей с экспертизой?

88. Выбираем nosql
• Write path + latency
• Read path + latency
• Сохранность данных
• Overhead на хранение данных

89. Выбираем nosql
• Репликация
• Consistency
• Что происходит при -1 нода?
• Сколько нод можно потерять?
• Как меняется нагрузка на оставшиеся?

90. Выбираем nosql
• Точка входа: нужна ли балансировка или
клиент умеет ходить по списку нод
• Шардинг: равномерность, кто роутит
• Вопросы про клиент: timeouts, retries, load
balancing

91. Выбираем nosql
• Как добавить ноду
• Как выключить ноду
• Upgrade кластера
• Backup/restore
• Мониторинг

92. Выбираем nosql
• Тестируем производительность на объеме данных и
нагрузке 5x от расчетных за год
• Тестируем отказы, смотрим логи (kill -9 на процесс,
firewall на N минут итд)
• Читаем issue tracker проекта: обращаем внимание
на баги – их серьезность, скорость закрытия,
возможные workaround

93. Взаимодействие с разработкой
• Админам интересен стабильный прод
• Разработчикам быстрая доставка фич до
пользователей

94. Взаимодействие с разработкой
• Конфликт интересов – это хорошо
• Но, чтобы работа не встала нужно
договариваться

95. Взаимодействие с разработкой
• SLA на время реакции админов на задачи
от разработки
• Админ может не выпускать задачу, если
видит, что не полетит

96. Взаимодействие с разработкой
• Defenition of done задачи у разработчика =
“Задача в production”
• Разработчик заинтересован выполнить все
здравые требования админов

97. Взаимодействие с разработкой
• Чтобы как можно раньше узнавать о возможных проблемах,
нужно общаться
• Совместное проектирование: AB, design docs, …
• Разработчики получают дополнительную экспертизу про
отказоустойчивость, производительность
• Админы получают более качественный код, в котором учтены
их требования

98. Взаимодействие с разработкой
• Конфликты неизбежны
• Идеально, если админы и разработка – разные
подразделения
• В этом случае рефери – начальство
• Это на крайний случай, но стимулирует договариваться

99. Deploy
• Чем меньше изменений за одну итерацию,
тем лучше
• Готово ли тестирование?
• Готова ли инфраструктура?

100. Deploy: тестирование
• Должно тестироваться в похожем на prod
окружении (балансеры, таймауты)
• Сборка должна включать все необходимые
изменения в окружении
• Несколько версий должны уметь работать
параллельно

101. Deploy: инфраструктура
• Формулируем критерии успешной работы
сервиса в мониторинге
• Мы должны быстро понимать, работает ли
новая версия или нет
• Атомарная выкладка на N серверов
невозможна

102. Deploy: инфраструктура
• Rolling upgrade – катим в N потоков
• Graceful reload сервиса – дорабатываем
текущие запросы, новые не берем – они
ретраятся на соседей

103. Deploy: инфраструктура
• Если приложению нужен прогрев, это
должно происходить до того, как на него
пойдут пользовательские запросы
• Процесс выкладки не должен
сопровождаться ошибками

104. Deploy: инструментарий
• Вы должны понимать, что происходит в
каждый момент времени
• Вы должны быть в состоянии исправить
руками любую ошибку в конфигурации
• Лог изменений: кто, что делал

105. Deploy: общение с разработкой
• Changelog – важно понимать, что изменилось с
точки зрения работы приложения
• Инструкция, если выкладка нестандартная
• Rollback инструкция, если были изменения
схемы БД итд

106. Deploy: общение с разработкой
• Если у вас много сервисов, деплоим всё
равно по одному
• За очередностью выхода сервисов должны
следить разработчики (через
последовательную постановку задач)

107. Deploy: общение с разработкой
• Учимся избегать изменения схемы БД
(дублирование данных, работа с 2
версиями, миграция, удаления старого)

108. Спасибо за внимание
Николай Сивко
nsv@okmeter.io
skype: nikolay.sivko