В блоге JUG.ru новый разбор, на этот раз под увеличительное стекло попал Никита Макаров из «Одноклассников», многократный участник программных комитетов наших конференций. Сегодня мы рассмотрим доклад о микросервисах для автоматизации тестирования. Выступление состоялось в 2015 году на встрече devclub.eu в Таллинне:
Слайды доклада можно найти тут.
Привязка к слову микро в рассказе Никиты кажется мне излишне сильной. Пуристы могут сказать, что доклад не имеет отношения к микросервисам. Докладчик, скорее всего, подозревал что-то подобное, и так появилась секция о том, какого размера должно быть «микро». Она нужна для того, чтобы при необходимости сослаться на определение.
По-моему, всё это лишнее. Не стоило строить выступление «от баззворда», то есть от микросервисов. Тестирование социальной сети — сложная задача, и те подходы, о которых говорит Никита, интересны и ценны независимо от того, насколько малы созданные для этого сервисы. В докладе речь об интересном — о специфике предметной области — начинается примерно с семнадцатой минуты. Я бы вытащил это в самое начало, а пояснения про микросервисы дозировал по мере того, как они становятся необходимы для понимания происходящего. Так можно освободить место для интересных вещей, которые сейчас в рассказе затронуты лишь косвенно.
Тестирование в продакшене — это очень интересно, и хорошо, что Никите с командой удалось ни разу не уронить портал «Одноклассники». Уронить «Яндекс» изнутри, помнится, оценка качества поиска при некотором моём участии однажды смогла. Если тебя добавили во все белые списки и антивандальные системы поэтому не реагируют, а ты стреляешь в сервис много-много запросов без задержек и прочей вежливости, то случиться может всякое.
Но про нагрузку люди обычно так-сяк помнят, а вот исключать собственных ботов из статистики, по моему опыту, начинают только после инцидентов. Сколько там тех ботов, думают они. Для «Одноклассников» Никита даёт ответ: их ~20 000 человек. Мы, говорит он, своих ботов знаем в лицо и по именам и умеем их не учитывать. Но из дальнейшего хода рассказа видно, что «мы» — довольно узкий круг лиц. Админы в своей статистике считали ботов нормальными людьми. Кем их считают, например, люди, прогнозирующие доходы от рекламы или аналитики, считающие какой-нибудь user engagement, retention или churn rate? Боты выполняют повторяющиеся сценарии без перерывов на сон и еду и, если их не исключать из расчётов, могут наплодить очень много статистики. На 24:20 Никита приводит пример команды тестирования, которая смогла засветиться даже в масштабах Youtube, и это не исключительный случай.
Удалить какой-то класс сценариев или пользователей из статистики — задача трудная, когда решаешь её в первый раз. Обычно есть множество мест, где пользователи учитываются (не все же проектируют систему сбора статистики сразу с расчётом на то, чтобы из неё было удобно что-нибудь исключать), и все эти места не знает никто. Если и правда удалось всё разграничить, то это ценный опыт, которым стоило поделиться.
В общем, тема тестирования в продакшене довольно широкая и факапоёмкая, и я бы добавил в рассказ какие-нибудь кровавые подробности, связанные с ней.
Выводы (озаглавленные «Lessons learned») начинаются на отметке 44:00. Всё, что Никита говорит в конце доклада, связано с проблемами микросервисов в целом и, на мой взгляд, не относится непосредственно к тестированию. «Если у вас 800 фронтов, то как вывести некоторые из них из продакшена и потом включить снова так, чтобы пользователи ничего не заметили?» — это ведь не про сервисы, применяемые именно для тестирования. Это, равно как и остальные пункты выводов, — уроки, извлечённые Одноклассниками в целом в процессе внедрения микросервисов.
Таким образом, рассказ распадается: вступление и заключение посвящены микросервисам в целом, а центральная часть освещает, собственно, их применение в тестировании.
Уверен, вы всё уже знаете про лазерную указку и какой вред она несёт, но отмечу, что в разбираемом выступлении она появляется на 3:37 и 7:40, и тем, кто смотрит видео, оба раза непонятно, где именно находится «вот здесь», на которое ссылается докладчик. Из контекста это можно восстановить, но ценой лишних умственных усилий.
На многих слайдах мы увидим оранжевую плашку в районе левого верхнего угла. То, что на ней написано, отмечает место (главу, если угодно) в сценарии всего выступления, тогда как заголовок слайда относится уже к тому, что находится на экране прямо сейчас. Это попытка реализовать здравую идею сохранения контекста (чтобы зритель в каждый момент понимал, где мы сейчас находимся глобально), но она, на мой взгляд, не срабатывает.
В реальности на многих слайдах заголовок просто дублируется (иногда дословно, иногда только по смыслу):
Кроме приведённого тут четвёртого слайда, на который мы дополнительно посмотрим ниже, эта ситуация возникает на слайдах 3, 5, 6, 7, 8, 9, 10, 16, 17, 18, 19, 21, 22, 24, 25, 28, 29, 31, 32, 37, 50 и 51. Всё внимание, которое зритель тратит на то, чтобы сопоставить эти заголовки и подзаголовки — чистый убыток, хоть и небольшой.
Как уменьшить этот убыток? Нам сильно поможет переработанный план доклада, в котором темы выделены более крупно, тогда оранжевый заголовок не будет меняться так часто. Но ещё больше нам поможет, если мы этот план сможем показать в начале выступления и периодически к нему возвращаться, отмечая пункты по мере того, как проходим их. Это может быть как текстовый список, так и схема. Для наших целей вполне подошла бы схема, изображённая на слайде 48, но об этом ниже.
Пока мы не ушли далеко от слайда 4, обратите внимание, что на нём есть:
Я считаю, что от всего этого стоит избавиться, хотя бы как-то так (вариант не идеальный, но зато очень простой):
На многих других слайдах серый фон добавляет рамочку вокруг содержимого, она работает как дополнительный (лишний) элемент. На мой взгляд, если картинка занимает всё доступное место без полей, это выглядит лучше, например, тут:
или тут:
То, что у Чужого с Хищником доска стоит неправильно и первыми ходят чёрные, отбросим как мелочные придирки: в конце концов, они инопланетяне и не обязаны играть по земным правилам. Но на будущее отметим, что любой человек с шахматным прошлым, видя в художественном произведении доску, тут же начинает проверять, того ли цвета правый нижний угол и как расставлены фигуры. И особенно сильно отвлекается, если замечает несоответствия.
Вернёмся к схеме, которая появляется на слайдах 38-48 (приведу здесь первый и последний из них):
Эти две картинки показывают начальный и конечный вид архитектуры тестирования Одноклассников на момент рассказа. На слайдах 39-47 располагаются промежуточные состояния.
Относительно сложные архитектурные схемы правильно показывать именно так, как это делает Никита. Элементы схемы должны появляться последовательно, тогда в каждый момент зрителям понятно, что именно комментирует докладчик и куда нужно смотреть. Более того, архитектурная схема, как правило, интересна не в статичной форме текущего описания, а вместе со своей историей, в динамике. История появления архитектуры объясняет почему схема именно такая, какие проблемы разработчики решали, вводя каждый новый элемент. Так зрителю гораздо легче понять, что из этого применимо в его случае, а что нет.
Описания лишь текущей архитектуры в отрыве от её истории, столь часто встречающиеся на технических конференциях, на мой взгляд, почти полностью пролетают мимо ушей и мозгов аудитории. Так что в этом месте призываю брать пример с докладчика.
Тем не менее, думаю, что можно было сделать ещё лучше. Если взять слайд 48 за основу, а с 38-го начать выступление, то эта последовательно нарастающая схема могла бы послужить отличным скелетом всей истории. Тогда подробные рассказы про Revolver, Mnemonic и Storekeeper могли бы появляться в те моменты, когда на схеме открывается соответствующий блок.
В Москве 8-9 декабря пройдёт очередной выпуск конференции Гейзенбаг, и Никита там выступит. Он интересные вещи будет рассказывать, точно говорю.
Если вы хотите получить обратную связь по своему выступлению, то я с радостью вам её предоставлю.
Слайды доклада можно найти тут.
Сюжет
Исходная точка
Привязка к слову микро в рассказе Никиты кажется мне излишне сильной. Пуристы могут сказать, что доклад не имеет отношения к микросервисам. Докладчик, скорее всего, подозревал что-то подобное, и так появилась секция о том, какого размера должно быть «микро». Она нужна для того, чтобы при необходимости сослаться на определение.
По-моему, всё это лишнее. Не стоило строить выступление «от баззворда», то есть от микросервисов. Тестирование социальной сети — сложная задача, и те подходы, о которых говорит Никита, интересны и ценны независимо от того, насколько малы созданные для этого сервисы. В докладе речь об интересном — о специфике предметной области — начинается примерно с семнадцатой минуты. Я бы вытащил это в самое начало, а пояснения про микросервисы дозировал по мере того, как они становятся необходимы для понимания происходящего. Так можно освободить место для интересных вещей, которые сейчас в рассказе затронуты лишь косвенно.
Например, для таких
Тестирование в продакшене — это очень интересно, и хорошо, что Никите с командой удалось ни разу не уронить портал «Одноклассники». Уронить «Яндекс» изнутри, помнится, оценка качества поиска при некотором моём участии однажды смогла. Если тебя добавили во все белые списки и антивандальные системы поэтому не реагируют, а ты стреляешь в сервис много-много запросов без задержек и прочей вежливости, то случиться может всякое.
Но про нагрузку люди обычно так-сяк помнят, а вот исключать собственных ботов из статистики, по моему опыту, начинают только после инцидентов. Сколько там тех ботов, думают они. Для «Одноклассников» Никита даёт ответ: их ~20 000 человек. Мы, говорит он, своих ботов знаем в лицо и по именам и умеем их не учитывать. Но из дальнейшего хода рассказа видно, что «мы» — довольно узкий круг лиц. Админы в своей статистике считали ботов нормальными людьми. Кем их считают, например, люди, прогнозирующие доходы от рекламы или аналитики, считающие какой-нибудь user engagement, retention или churn rate? Боты выполняют повторяющиеся сценарии без перерывов на сон и еду и, если их не исключать из расчётов, могут наплодить очень много статистики. На 24:20 Никита приводит пример команды тестирования, которая смогла засветиться даже в масштабах Youtube, и это не исключительный случай.
Удалить какой-то класс сценариев или пользователей из статистики — задача трудная, когда решаешь её в первый раз. Обычно есть множество мест, где пользователи учитываются (не все же проектируют систему сбора статистики сразу с расчётом на то, чтобы из неё было удобно что-нибудь исключать), и все эти места не знает никто. Если и правда удалось всё разграничить, то это ценный опыт, которым стоило поделиться.
В общем, тема тестирования в продакшене довольно широкая и факапоёмкая, и я бы добавил в рассказ какие-нибудь кровавые подробности, связанные с ней.
Выводы
Выводы (озаглавленные «Lessons learned») начинаются на отметке 44:00. Всё, что Никита говорит в конце доклада, связано с проблемами микросервисов в целом и, на мой взгляд, не относится непосредственно к тестированию. «Если у вас 800 фронтов, то как вывести некоторые из них из продакшена и потом включить снова так, чтобы пользователи ничего не заметили?» — это ведь не про сервисы, применяемые именно для тестирования. Это, равно как и остальные пункты выводов, — уроки, извлечённые Одноклассниками в целом в процессе внедрения микросервисов.
Таким образом, рассказ распадается: вступление и заключение посвящены микросервисам в целом, а центральная часть освещает, собственно, их применение в тестировании.
Слайды
Лазерная указка
Уверен, вы всё уже знаете про лазерную указку и какой вред она несёт, но отмечу, что в разбираемом выступлении она появляется на 3:37 и 7:40, и тем, кто смотрит видео, оба раза непонятно, где именно находится «вот здесь», на которое ссылается докладчик. Из контекста это можно восстановить, но ценой лишних умственных усилий.
Дублирующиеся элементы
На многих слайдах мы увидим оранжевую плашку в районе левого верхнего угла. То, что на ней написано, отмечает место (главу, если угодно) в сценарии всего выступления, тогда как заголовок слайда относится уже к тому, что находится на экране прямо сейчас. Это попытка реализовать здравую идею сохранения контекста (чтобы зритель в каждый момент понимал, где мы сейчас находимся глобально), но она, на мой взгляд, не срабатывает.
В реальности на многих слайдах заголовок просто дублируется (иногда дословно, иногда только по смыслу):
Кроме приведённого тут четвёртого слайда, на который мы дополнительно посмотрим ниже, эта ситуация возникает на слайдах 3, 5, 6, 7, 8, 9, 10, 16, 17, 18, 19, 21, 22, 24, 25, 28, 29, 31, 32, 37, 50 и 51. Всё внимание, которое зритель тратит на то, чтобы сопоставить эти заголовки и подзаголовки — чистый убыток, хоть и небольшой.
Как уменьшить этот убыток? Нам сильно поможет переработанный план доклада, в котором темы выделены более крупно, тогда оранжевый заголовок не будет меняться так часто. Но ещё больше нам поможет, если мы этот план сможем показать в начале выступления и периодически к нему возвращаться, отмечая пункты по мере того, как проходим их. Это может быть как текстовый список, так и схема. Для наших целей вполне подошла бы схема, изображённая на слайде 48, но об этом ниже.
Рисунки
Пока мы не ушли далеко от слайда 4, обратите внимание, что на нём есть:
- белый график-картинка на тёмно-сером фоне;
- слово «VISIBILITY», написанное вертикально;
- обрезок слова «MATURITY» по горизонтальной оси
Я считаю, что от всего этого стоит избавиться, хотя бы как-то так (вариант не идеальный, но зато очень простой):
На многих других слайдах серый фон добавляет рамочку вокруг содержимого, она работает как дополнительный (лишний) элемент. На мой взгляд, если картинка занимает всё доступное место без полей, это выглядит лучше, например, тут:
или тут:
То, что у Чужого с Хищником доска стоит неправильно и первыми ходят чёрные, отбросим как мелочные придирки: в конце концов, они инопланетяне и не обязаны играть по земным правилам. Но на будущее отметим, что любой человек с шахматным прошлым, видя в художественном произведении доску, тут же начинает проверять, того ли цвета правый нижний угол и как расставлены фигуры. И особенно сильно отвлекается, если замечает несоответствия.
Схемы и сохранение контекста
Вернёмся к схеме, которая появляется на слайдах 38-48 (приведу здесь первый и последний из них):
Эти две картинки показывают начальный и конечный вид архитектуры тестирования Одноклассников на момент рассказа. На слайдах 39-47 располагаются промежуточные состояния.
Относительно сложные архитектурные схемы правильно показывать именно так, как это делает Никита. Элементы схемы должны появляться последовательно, тогда в каждый момент зрителям понятно, что именно комментирует докладчик и куда нужно смотреть. Более того, архитектурная схема, как правило, интересна не в статичной форме текущего описания, а вместе со своей историей, в динамике. История появления архитектуры объясняет почему схема именно такая, какие проблемы разработчики решали, вводя каждый новый элемент. Так зрителю гораздо легче понять, что из этого применимо в его случае, а что нет.
Описания лишь текущей архитектуры в отрыве от её истории, столь часто встречающиеся на технических конференциях, на мой взгляд, почти полностью пролетают мимо ушей и мозгов аудитории. Так что в этом месте призываю брать пример с докладчика.
Тем не менее, думаю, что можно было сделать ещё лучше. Если взять слайд 48 за основу, а с 38-го начать выступление, то эта последовательно нарастающая схема могла бы послужить отличным скелетом всей истории. Тогда подробные рассказы про Revolver, Mnemonic и Storekeeper могли бы появляться в те моменты, когда на схеме открывается соответствующий блок.
Минутка рекламы
В Москве 8-9 декабря пройдёт очередной выпуск конференции Гейзенбаг, и Никита там выступит. Он интересные вещи будет рассказывать, точно говорю.
Регулярные разборы
Если вы хотите получить обратную связь по своему выступлению, то я с радостью вам её предоставлю.
Что для этого нужно?
Всё это нужно отправить хабраюзеру p0b0rchy, то есть мне. Обещаю, что отзыв будет конструктивным и вежливым, а также осветит и положительные моменты, а не только то, что надо улучшать.
- Ссылка на видеозапись выступления.
- Ссылка на слайды.
- Заявка от автора. Без согласия самого докладчика ничего разбирать не будем.
Всё это нужно отправить хабраюзеру p0b0rchy, то есть мне. Обещаю, что отзыв будет конструктивным и вежливым, а также осветит и положительные моменты, а не только то, что надо улучшать.