вторник, 20 сентября 2016 г.

Как делаются дела в ОК



Всем привет, меня зовут Виталий Куликов, я занимаюсь продуктом в компании Одноклассники. 
  
Под словом "занимаюсь" я понимаю все, что связано с продуктом - от принятия решения, как он [продукт] должен работать до написания кода, поддержки его в production и анализа бизнес-метрик.


7 лет назад я работал в другой компании и чувствовал себя примерно также, как этот парень на фотографии справа! Но прошло время и я с уверенностью могу сказать, что…

Я – счастливый человек.

Именно мой предыдущий опыт позволил мне по достоинству оценить разницу в подходах к работе в этих двух компаниях
и помог мне сформировать мнение о том, как все должно быть устроено на самом деле.

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



Для программиста в любом проекте одним из самых важных на мой взгляд аспектов являются технические решения. Мало того, на эту тему есть бесчисленное множество исследований, которые подтверждают этот постулат. Ведь технические решения - это именно то, с чем придется жить человеку годами, а иногда и десятилетиями и это будет напрямую влиять на отношение человека к работе.

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

Первое правило: технические решения принимают те же самые люди, которые их будут в последствии реализовывать и поддерживать в эксплуатации.
Вот задайте себе вопрос, у кого в компании есть архитекторы?
Может кто-нибудь из вас сам является архитектором?

Архитектор – наверное не буду объяснять кто это и чем именно они занимаются, скажу только что у нас таких людей нет.

Если быть точнее, выполнять работу архитектора - это обязанность каждого нашего разработчика.  Соглашаясь на то или иное техническое решение, команда и каждый конкретный человек понимает, что все проблемы, связанные с этим решением, им же и придется разгребать. Отсюда вытекает несколько следствий.

Следствие первое: мы используем только то, что можем починить.

Действительно, мы стараемся использовать только те технологии, в которых мы имеем глубокую экспертизу. К примеру, мы используем java виртуальную машину не только потому что она хорошо работает, но и потому что в случае необходимости мы можем ее запатчить. И поверьте мне, мы делали это уже не раз!

На картинке слева небольшой список продуктов, которые были так или иначе модифицированы под наши нужды.





Следствие второе: мы используем одинаковые технологии во всех наших продуктах.

У нас унифицированный технологический стек среди подавляющего большинства проектов, разрабатываемых в нашей компании.  Я думаю никто из вас не станет спорить с тем, что каждая технология приносит за собой уникальный для нее набор проблем? Решение этих проблем одновременно может быть и интересной, и достаточно затратной задачей. Мы можем себе позволить исследовать какие-то новые технологии, но если мы решаем их внедрить, то делаем это везде.

Есть у нас еще одно интересное правило – называется правило одного неизвестного или "не отстрели сам себе ногу".

Сталкивались ли вы с ситуацией, когда кто-то из ваших знакомых хочет сделать стартап? Модная тема последние лет 10.

И вот этот человек всю жизнь использовал, допустим, MySQL для хранения данных. Но вдруг он понимает, что MySQL сейчас не модно, а модно, например Mongo.
И этот человек думает, а давай-ка я в своем стартапе буду использовать Mongo. Это и в тренде, и заодно разберусь что за хреновина такая.

Так вот, мы так не делаем!
Когда ты берешься за новый для тебя проект, ты столкнешься с десятками различных, неизвестных тебе проблем. И их надо будет решать, и это будет отнимать у тебя силы и время.
А если к тому же ты используешь еще и новое техническое решение или новый язык программирования, ты неизбежно столкнешься с кучей проблем и с ним! Одни проблемы помножатся на другие и в результате запал быстро исчезнет.

Хватит правил, перейдем к апдейтам! 

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

За годы работы в одноклассниках мое отношение к апдейтам кардинально изменилось. Я жду каждый апдейт, жду его с нетерпением, иногда даже не могу заснуть ночью. Вот так вот я его жду. Это то чувство вдохновения и трепетного ожидания чего-то очень приятного, как последняя ночь перед путешествием, когда ты не можешь успокоить свое воображение, думая о предстоящем.

Это невероятное чувство делать что-то для миллионов людей, делать то, что тебе действительно нравится, что ты сам с удовольствием будешь использовать каждый день.

В первую очередь это вдохновение толкает нас делать процесс апдейтов лучше, быстрее, надежнее, проще. И дальше я поделюсь с вам тем, как мы это делаем.

Не секрет, что у нас очень много серверов, на которых работает под сотню различных приложений. Просто так взять руками и обновить все это невозможно. Поэтому апдейты у нас проходят в автоматическом режиме со сложными сценариями выкладки.
Мы можем выкладывать сервера по одному, группами, устанавливать последовательность выкладки и многое другое.

Вот примерно так выглядит интерфейс диплоймент системы. Расскажу пример сценария апдейта фрон-эндов и серверов бизнес логики.

Сценарий апдейта:
1) вывести из ротации сервера вебов, потом бизнес логики (далее БЛ);
2) остановить вебы, потом
БЛ;
3) переложить вебы;
4) переложить
БЛ;
5) запустить БЛ;
6) дождаться поднятия;
7) запустить вебы;
8) дождаться поднятия;
9) завести обратно в ротацию;

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

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

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

Это было обусловлено теми технологиями, которые были в нашем распоряжении и размерами нашей инфраструктуры, уже на тот момент это были тысячи серверов. Шло время, мы понимали, что несем из-за простоев большие потери, как репутационные, так и финансовые. Надо было что-то делать. Результатом работы команды платформы стала новая технология ремоутинга, поддерживающая эволюцию типов, что позволило нам перекладывать сервера на новые версии приложений, не ломая взаимодействие между версиями. И таким образом апдейты стали онлайновыми, т.е. без даун тайма.
Если кому-то будет интересно, то эта технология доступна на гитхабе под названием one-nio


Мы запускаем каждую неделю десятки изменений на сайте и далеко не все изменения нравятся нашим пользователям.
Одна из самых популярных жалоб в суппорт – это вернуть старую версию функциональности.
Одно дело когда это касается просто личного восприятия человека, совсем другое, когда после апдейта что-то работает плохо, либо не работает совсем. В такой ситуации поможет только откат!

Откат – это то что мы умеем делать. Делаем мы это с любой нашей системой безболезненно для портала. Правда способность к откатам требует от нас особого внимания к коду, т.е. код написан так, чтобы откат был возможен.

Но не смотря на то что откаты мы делать умеем, мы точно делать их не хотим. Это все же доставляет нам неудобства, как в плане лишней работы, так и в плане отложенных запусков. 
На картинке слева изображено место, которое называют «Врата Ада». В начале 70-х советские геологи искали газ в Туркменистане. Как это ни странно нашли! Но грунт под буровой платформой провалился и из разлома начал выходить на поверхность газ. Чтобы не травить людей и животных геологи решили сжечь выходящий газ, по их расчетам он должен был выгореть за пару дней. Но что-то пошло не так, и он выгорает уже почти 50 лет!

Чтобы не повторять таких просчетов и не жить с результатами наших апдейтов и экспериментов десятилетиями, все что попадает в production, попадает туда в выключенном виде. Это дает нам целый ряд приятных преимуществ:
1) Человек, который ставит апдейт, почти никогда не сталкивается с проблемами, вызванными новым кодом.
2) Запуск нового кода может осуществляться частично для разных групп пользователей.
3) Новый код в любой момент может быть выключен в процессе эксплуатации, если он вызывает проблемы.
 

Таким образом от апдейтов мы плавно переходим к управлению production средой.






Чтобы управлять всеми тысячами серверов, сотнями экспериментов и десятками проектов нам необходима какая-то общая централизованная система управления. И она у нас есть.

Под кодовым названием – ПМС (Portal Management System).

Под управлением в данном контексте я понимаю следующие вещи:
1) Включение/выключение функциональности.


2) Перевод функциональности в аварийный режим – частичная деградация.
3) Проведение экспериментов, А/Б тестирование.

Инструмент на самом деле очень простой и надежный как топор. Я не буду вдаваться в технические детали, расскажу быстро его возможности.
ПМС позволяет нам включать/выключать
фичи по отдельным серверам или на группы серверов.

По юзер агентам браузеров


По партициям пользователей, которые мы определяем, вычисляя остаток от деления Id пользователя на 256.
Либо по заданному списку
ID пользователей, который к тому же мы можем передавать как ссылку на другую настройку, чтобы не копировать везде одинаковые списки.

Также мы можем запускать эксперименты для определенных версий мобильных приложений.
Это может быть очень полезным, если вы подозреваете, что в будущем может поменяться ваш
апи. В таком случае вы можете предусмотреть полное отключение функциональности, либо сделать фолбэк на скажем реализацию через вебвью.

И это далеко не все, что позволяет нам PMS! Мы можем налету менять css на сайте, менять порядок портлетов, размеры аватарок и многое другое.

У нас в компании работает много  сотрудников, и все они запускают свои проекты, фичи, проводят эксперименты. Т.к. вся экосистема сильно взаимосвязана и эксперимент одних может сказаться на работе других, все изменения production среды  мы документируем. Документация происходит в несколько этапов:
1) Перед началом эксперимента в специальном чате рассылается оповещение о его начале. К оповещению прикладывается тикет в джире, где есть детальное описание эксперимента, и ожидаемые результаты
2) Все изменения в PMS записываются в бэклог, и доступны через аудит, на случай расследования инцидентов.

Как же судить об успешности того или иного запуска? В этом нам помогает статистика!






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

В данном контексте могу рассказать вам про одну из моих задач - про регистрацию. Она является очень показательным примером того, насколько важна статистика в нашей работе.
Казалось бы, какие тут могут быть проблемы, ввел номер, получил код и готово, но нет…

Вместе с новой регистрацией мы начали собирать данные по всему что пользователи делают в процессе.
Какие ошибки и на каком шаге они 
получают, в какие ситуации попадают, на каких экранах отваливаются.

В результате обсчета всех данных по регистрации я получаю документ с конверсионной воронкой.
Сразу после запуска мы получили конверсию порядка 68%. В течение года мы опробовали десятки различных решений, визуальных ухищрений, разных коррекций номеров
и после более чем 200 коммитов имеем конверсию в 90%. Чтобы вы понимали масштабы, речь идет о миллионах пользователей в месяц!

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

Один из наиболее распространенных видов экспериментов, которые мы проводим – это А/Б тестирование новых идей.
Расскажу вам историю одного эксперимента:
У нас на портале есть статус онлайн человек или нет, этот статус отображается в виде мигающей точки в углу
аватарки
.

Для веб версии точка оранжевая, для моб версии синяя. Собственно, ничего нового в этом нет, похожим образом статус онлайна сделан в ФБ. За одним исключением - у нас точка мигает. И вот мы решили это мигание убрать. Вполне логичное желание с точки зрения дизайна, без миганий выглядит приятнее. 
В общем запустили мы эксперимент по отключению мигания, и казалось бы все работает круто, выглядеть стало лучше, но…
Пользователи начали писать письма в суппорт о том, что сердца друзей перестали биться!

Мало того, начала проседать статистика. Как видно на графике справа, стала сильно проседать отправка сообщений.
После анализа всех данных мы получили следующие цифры, простое отключение мигания статуса онлайн
уменьшило дневную аудиторию портала на 1%,
отправку сообщений на 3%,
просмотры профилей друзей на 7%.
Эксперимент пришлось откатить.

Еще одним из вариантов применения статистических данных является построение улучшенных алгоритмов и обучение математических моделей.
Мы применяем это повсеместно, начиная от рекомендаций дружб, заканчивая  радио в музыке, которое автоматически подстраивается под твои предпочтения.

Запуск и проведение экспериментов очень важная и интересная часть нашего быта, но что делать с уже давно запущенной и работающей системой?
С ней же тоже могут возникнуть неожиданные проблемы, и мало того, они у нас возникают в огромной количестве!
Как же мы об этом узнаем? Иногда из писем в суппорт, но это самый худший сценарий, гораздо лучше, когда мы узнаем о проблеме прежде, чем ее заметили пользователи.
Для этих целей у нас есть мониторинг – краеугольный камень любой production системы с высокой доступностью. 

Мы следим за всем, что происходит с нашей системой и замечаем малейшие отклонения в трендах.
Но как можно адекватно уследить за работой десяти тысяч серверов, на которых работает больше сотни различных систем?
Ответ очевиден – сделать это непросто. 
Раньше нам надо было постоянно просматривать глазами тысячи отчетов.  И очень часто в тот момент когда проблему замечали, понять какая система стала источником неисправности было невозможно, т.к. все они уже вылетали по кругу и имя этому явлению – «карусельная колбасность». И вот, чтобы исправить ситуацию мы сделали: та-да!

Автоматическую систему распознавания аномалий. Эта программа получает информацию обо всех удаленных вызовах всех систем, она знает которая из систем стала первой отвечать медленнее или сыпать ошибками и строит граф инцидента как на картинке справа.

Итак, нашли мы проблему, и что же дальше? А дальше вот что: все сбои документируются и расследуются. Даже если сбой был временный и в процессе самоустранился, мы все равно расследуем причину его возникновения, чтобы в будущем знать как себя вести или вовсе избежать похожих проявлений.

Немного статистики: на сегодняшний день в сутки мы регистрируем порядка 200 инцидентов. Но не все инциденты одинаково полезны, и это большой минус, часть из них не является инцидентами вовсе, либо являются инцидентами, неподвластными нашему контролю, как например падение сети в каком-нибудь регионе. Но мы вынуждены тратить время на выявление и анализ причин. Печально, но пока так.

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

Что же мы имеем в результате?

Мы имеем:
  1. Технические решения принимают сами разработчики;
  2. Огромное множество статистики, мы знаем все обо всем;
  3. Все изменения на production попадают выключенными;
  4. Production управляется централизованной системой;
  5. Все мониторится в полу-автоматическом режиме;
  6. Все аномалии фиксируются и детально разбираются;



Спасибо, что дочитали до конца! 
Задавайте вопросы в комментариях, постараюсь на все ответить!





13 комментариев:

  1. Виталик, прекрасный пост!!!
    Хнык-хнык, СКУЧАЮ!
    И ещё я как-то умудрилась на картинку к тебе в статью попасть :)
    Про автоматическую систему выявления аномалий - КРУТО!

    ОтветитьУдалить
    Ответы
    1. Привет! Большое спасибо, рад что понравилось :-)

      Удалить
  2. Такой-же рабочий интерфейс и у службы поддержки? (Которые банят).

    ОтветитьУдалить
    Ответы
    1. Пожалуйста, расскажите о нем?
      Он удобный хотя-бы?

      Удалить
  3. Thanks for sharing, nice post! Post really provice useful information!

    Giaonhan247 chuyên dịch vụ order hàng nhật, ship hàng đức, order nhận mua hộ hàng hàn quốc, dịch vụ đặt hàng trung quốc giá rẻ cũng như chia sẻ kinh nghiệm mua hàng trên amazon giá rẻ nhất.

    ОтветитьУдалить
  4. Thanks for sharing, nice post! Post really provice useful information!

    Giaonhan247 chuyên dịch vụ ship hàng đức, đặt mua order hàng đức và dịch vụ order hàng hàn quốc giá rẻ cũng như mua hộ hàng hàn quốc giá rẻ và giá cước gửi hàng đi mỹ uy tín nhất.

    ОтветитьУдалить