Взгляд изнутри на надежность сервисов Facebook / Элина Лобанова (Facebook) — Дели + Калькутта на подходе.
Текстовую и фото-трансляцию будут вести Алексей Виноградов и Иван Глушков.
Текстовую и фото-трансляцию будут вести Алексей Виноградов и Иван Глушков.
ну и пока не началось, напоминаем про митапы
✔️В 11:00 в А 1.6 митап «Web Services in C++ in 5 min», проводит C++ User Group.
✔️В 11:00 в А 1.6 митап «Web Services in C++ in 5 min», проводит C++ User Group.
“Надежность Сервисов, ч1”
Элина будет рассказывать про свой опыт “Production Engineer” в Facebook.
Почему Production Engineer а не SRE как в Google?
Чтобы ответить на вопрос - надо погрузиться в историю.
- Стандартная система - Dev & QA & Ops
- в 2009 - появились SRE в Google. В Facebook было все по старому, все в ручном режиме
- в 2010 всю массу Ops поделили на две группы: SRO & AppOps
- SRO - Operations
- AppOpst - интегрированы в команды, работают рядом с разработчиками, очень близко к SRE
- в 2012 - rename SRO -> Production Engineer. Все стали OnCall
- s 2014 - остатки команд SRO закрыли, остались только Production Engineer.
Элина будет рассказывать про свой опыт “Production Engineer” в Facebook.
Почему Production Engineer а не SRE как в Google?
Чтобы ответить на вопрос - надо погрузиться в историю.
- Стандартная система - Dev & QA & Ops
- в 2009 - появились SRE в Google. В Facebook было все по старому, все в ручном режиме
- в 2010 всю массу Ops поделили на две группы: SRO & AppOps
- SRO - Operations
- AppOpst - интегрированы в команды, работают рядом с разработчиками, очень близко к SRE
- в 2012 - rename SRO -> Production Engineer. Все стали OnCall
- s 2014 - остатки команд SRO закрыли, остались только Production Engineer.
Production Engineers - всегда в команде, нет отдельных команд (как в SRE).
Чем занимаются:
- Мониторинг. Периодически (раз в 5 мин) апускают atop, сохраняя результат на каждой машине. Это помогает в дальнейшем разбираться с проблемами. Можно посмотреть кто когда что сломал.
Чем занимаются:
- Мониторинг. Периодически (раз в 5 мин) апускают atop, сохраняя результат на каждой машине. Это помогает в дальнейшем разбираться с проблемами. Можно посмотреть кто когда что сломал.
Чтобы развлечь аудиторию, Элина рассказала про интересную проблему “Malloc HTTP”. Когда пришел заголовок “HTTP”, а malloc перевел 4 байта в int, и выделил ‘malloc(“HTTP”)’ памяти.
Следующий рассказ - про велосипеды в Facebook, когда компания делала решения у себя внутри, потому что не было еще общедоступных решений в Open Source.
Шутки для посвященных. Как завалить систему, интерпретируя ответ HTTP 400 от сервиса, которого надо было вызвать по совсем другому протоколу. Сервис должен был вернуть размер памяти. Ок, "HTTP" -> toHex байт зарезервируем, нет проблем).
Данные из Prometheus хранятся ВСЕГДА. Можно поднять историю за любой момент в прошлом. Сильное решение!
Scuba - хранилище данных внутри Facebook, работает всегда быстро (шутка про ELK), и имеет неплохой UI для отображения графиков и всех данных.
Оказывается, в сети есть даже Paper про эту систему: https://research.fb.com/publications/scuba-diving-into-data-at-facebook/
Facebook Research
Scuba: Diving into Data at Facebook
Facebook takes performance monitoring seriously. Performance issues can impact over one billion users so we track thousands of servers, hundreds of PB of daily network traffic, hundreds of daily code...
Scuba выступает бэкендом для разных систем, например для Logview, поиск по stacktrace, все выглядит очень красиво.
Стандартный мониторинг и как у фейсбука (зелёный, неожиданно). Один пиксель - одна минута.
Каждая линия - один датацентр, сколько сохраняем данных в БД, или сколько получаем 5xx ошибок.
Очень много информации на одной картинке, но надо привыкнуть
Очень много информации на одной картинке, но надо привыкнуть