Как отвечать за продакшн / Андрей Сумин (Mail.ru)
•Download as PPTX, PDF•
1 like•775 views
У вас, в худшем случае, есть ваш комп, на котором вы всё тестируете перед выкаткой. Проверяете во всех браузерах, запускаете автоматические тесты, возможно, нагрузочные. В хорошем случае — есть ферма машин или даже отдел тестирования. Это стандартные практики по соблюдению качества продукта. Но это малая часть того, что можно сделать. В докладе я расскажу, какой плаcт работ мы еще делаем, чтобы улучшить техническое качество продукта. Сконцентрируюсь на frontend. Рассмотрим вопросы: 1. Логирование. 2. Мониторинг. 3. Алертинг. 4. Бета-пользователи. 5. Саппорт. 6. Плагины. 7. Антивирусы. и т.п.
Recommended
Recommended
More Related Content
What's hot
Viewers also liked
Viewers also liked (20)
Similar to Как отвечать за продакшн / Андрей Сумин (Mail.ru)
Similar to Как отвечать за продакшн / Андрей Сумин (Mail.ru) (20)
More from Ontico
More from Ontico (20)
Как отвечать за продакшн / Андрей Сумин (Mail.ru)
- 1. Как отвечать за продакшн Андрей Сумин Заместитель технического директора почтового сервиса Mail.Ru
- 3. Собеседование Кто отвечает за продакшн?
- 4. Собеседование Кто несет ответственность за продакшн? Расскажите о последней проблеме.
- 5. Собеседование Представьте что нет админов, менеджеров и тестировщиков
- 6. Собеседование Хорошо, теперь вы начальник
- 8. Мониториг
- 10. Ответственность за продакшн — это не отсутствие ошибок, это гарантия возможности пользоваться сервисом.
- 15. Состояние сервиса Свои графики Дашборд Дашборд дашбордов
- 16. Алертинг
- 19. Алертинг Можно нормировать по графику посещаемости
- 20. Алертинг Превращаем плато в пик
- 21. Алертинг Превращаем плато в пик
- 26. Другие каналы оповещения Саппорт Соц. сети Бета пользователи
- 28. Несколько реальных проблем Рейз в мемкэше Тормозит написание письма Антивирус Размер пакета
- 29. Есть один ответственный за проблему!
Editor's Notes
- Делая этот доклад я поставил себе прагматичную цель — слышать больше разумных мыслей от кандидатов на собеседовании. Я вижу много сильных программистов, но в процессе разговора с ними я понимаю что им нельзя давать продукт. Да, им можно дать таски на выполнение, но фичу или продукт не в коем случае. И это удивительно, всегда кажется что чем сильнее разработчик, тем больше у него ответственности, а на практике это совсем разные вещи. Причем бывает и наоборот, технически человек на троечку, но пообщаешься с ним и видишь что с продуктом, с точки зрения стабильности все будет отлично.
- Давайте рассмотрим одно из собеседований. Ко мне на собеседование человек приходит после технического собеседования. Это значит что команда готова с ним работать как с технарем. Я задаю вопрос:
- Я не помню чтобы хоть кто-то вы этот момент сказал "не я". И в целом никто не хочет меня обмануть и правда считает что именно он держит проект на своих хрупких плечах. Но давайте копнем глубже.
- Вот тут выясняются интересные подробности. Разработчик начинает рассказывать подробности бага, а я невзначай спрашиваю: — А как узнал о проблеме? — Менеджер сказал. У меня резонный вопрос, если менеджер сообщает о проблемах на продакшене, в чем заключается ответственность разработчика? Иногда менеджер заменяется за админа, генерального директора фирмы и тп. Но сути это не меняет. В такой схеме контролем продакшена занимается не разработчик а кто-то другой, потому что убери этого менеджера из цепочки и лежащий продакшен будет и дальше лежать. На самом деле некоторые в этот момент осознают проблему и говорят: — И правда я не отвечаю за продакшен. Но есть настойчивые, и находят собственное успокоение в разделении труда. Тестировать должны тестировщики, а я должен заниматься своим делом. И мы плавно подходим к следующему логическому вопросу.
- Тут самые популярные ответы: — Я буду сам все тщательно проверять — Я напишу авто тесты Занятие крайне нужное, на забегая вперед, поставленную в докладе задачу не решает. Не решает по простой причине, все эти меры работают до продакшена. И действительно снижают вероятность проблем в последнем, но не позволяют следить за продакшеном! Но давайте вернемся к кандидату, я задаю резонный вопрос: — Если все это надо делать, почему не делаешь? Тут начинается длинная речь про то что не дают времени, начальству все равно и т.п. Я уточняю: — Наличие тестов увеличит твою производительность? — Да. — Тогда почему ты не делаешь то что увеличит твою производительность? (Слайд про эскалацию?)
- А теперь давайте вообще очистим сознание, вы сами и начальник. Никого не надо убеждать и выбивать время, вы его распределяете. На что вы его потратите? Только учтите что надо платить себе ЗП а это заначит что надо зарабатывать деньги! После этого вопроса даже самые рьяные начинают задумываться, потому что в этой схеме рассказывать что кто-то другой виноват невозможно, других просто нет, есть только вы. Вообще был интересный случай недавно. Один из руководителей группы первый раз пришел на собеседование которое я вел и долго слушал как я веду кандидата по этой схеме. В какой-то момент он не выдержал и спросил: — А зачем ты вообще рассказываешь менеджерам как правильно надо сделать, просто сделай и все.
- Итак, мы выяснили что винить некого. Еще мы выяснили что тесты это хорошо, но этого мало. Что делать?
- Первая мысль у всех одна и она вроде как верная — мониторинг!
- Но тут многие тоже ограниченны рамками программирования, на вопрос что будете мониторить отвечают: — Ошибки. Кто-то говорит про JS ошибки, кто-то про ошибки ответа сервера, кто-то и про то и про то. Шаг верный, но это скорее не шаг а намерение его сделать Ответственность за продакшен это не ответственность за программу это ответственность за то что пользователь может воспользоваться программой.
- А как мы понимаем что пользователи могут пользоваться сервисом? По продуктовым показателям. На примере почты это количество отправок писем, чтений писем, прикрепления файлов к письмам и тп
- Тут надо следить что количество хитов на успешное завершение действия не упало или наоборот не выросло. Например, отвалился канал к какому-то провайдеру. Пользователи вообще не могут попасть к вам на сайт. Никакие графики ошибок не шелохнулись, а сервис недоступен. Надо выяснять звонить провайдеру и разбираться. А был вообще замечательный случай. У нас резко выросло количество заходов в почту. Никаких ошибок нет все гладко, но хиты выросли. Стали копать, оказалось что рост в одной из старых опер. Зашли этой оперой, видим что у курсора мышки все время крутится колесико загрузки. Стало очевидно что пользователи ждут пока оно пропадет, ждут долго, потом решают что что-то зависло и жмут F5. А причина такого кручения — затупивший ответ стоявшего у нас счетчика. Выключили счетчик и переписали его на неблокирующую схему. А вообще прям легко вижу что некоторые в этот момент скажут, ну у меня все работает надо ждать пока счетчик перестанет тупить! Переводится это так: — Я знаю что пользователи сервиса, который я разрабатываю страдают, но мне все равно.
- Начните с простого. Можно с самого простого. Дергайте пиксель в nginx и грепайте логи. Используйте популярные счетчики Инструменты вебмастера.
- В конце концов вы доберетесь до того что будете рисовать свои графики. Инструментов тоже много, самые популярные у нас это rrd и graphite.
- Количество графиков будет расти и вы сделаете дашборд. Он будет у вас на отдельно мониторе/телевизоре и вы будете на него смотреть. Вы все чаще на заявление менеджера — У меня не работает Будете отвечать — В курсе уже исправляю С каждой новой исправленной проблемой буду появляться новые графики.
- Графиков у вас стало так много что некоторые вы не смотрели уже несколько месяцев и если там что-то отклонилось от нормы вы про это не в курсе.
- Теперь вам нужна система, которая автоматом говорит что какой-то график отклонился от нормы. Тут масса вариантов и если вы оказались тут то ваша система мониторинга это уже отдельный проект вы его давно хотите отрефакторить или переписать. Давайте сделаем это с пользой для проекта.
- Тут на самом деле масса вариантов. Есть и очень затратные с машинным обучением А есть и простые, которые тоже дают отличный результат. Если у вас график ошибок, то если случилась ошибка надо алертить. Алгоритм простой и понятный, если есть фон, это плохо , тогда порог алерта выше чем ноль. Если это продуктовый показатель, то он зависит от посещаемости сайта, а значит ночью значения маленькие, а днем высокие. Порог срабатывания не подберешь. Тут есть вариант сравнивать со значение недельной давности, но сами понимаете, праздники все ломают. Есть хитрость, этот график можно пронормировать на график посещаемости и это уже может получиться прямая, которой можно выставить пороги как снизу так и сверху. У себя мы используем два этапа Строим график разницы текущей точки с предыдущей, это позволяет плато превращать в пики Строим значения корреляции последнего временного промежутка с эталонным выбросом и если корреляция высокая это выброс и срабатывает алертинг. У этого способа есть небольшой недостаток, время срабатывания задерживается на время исследуемого промежутка. Но зато не зависит от праздниковАлертинг.
- Мы используем два способа — почта и СМС. Важный момент, надо реагировать на все алерты, иначе довольно быстро они перестанут быть полезными. Если у вас сработал алертинг надо починить проблему, завтра к нему добавится еще один, после завтра еще один а через месяц вам будет приходить 20 СМС в час и вы будете все их игнорить.
- Если у вас есть сапорт, под сапортом я понимаю любого человека который напрямую контактирует с пользователем. В некоторых фирмах это может быть менеджер по продажам. Так вот эти люди для вас такой же мониторинг как и ваши графики. Никогда не общайтесь с ними через менеджера. Причина та же — нет менеджера вы не в курсе о проблеме. Регулярно встречайтесь с этмим людьми, договоритесь об удобном и оперативном способе оповещения вас о проблемах. Прежде чем катить что-то предупредите их на жалобы в каких местах проекта надо обращать внимания.
- Вы не поверите но несколько кране редких и забористых багов мы нашли после того как у видели в ленте жалобу на сервис. Поэтому видите что кто-то жалуется, напишите ему в личку, выясните подробности. Разберитесь.
- Крайне эффективный способ убрать одно звено в виде сапорта. Набираете бета пользователей и даете им возможность пожаловаться прямо с сайта. Жалобы поступают вам на почту. Этот способ показал себя крайне эффективным у нас на проекте. Тут самый важный момент — как выбрать бета пользователей, у себя мы сформулировали ряд критериев: Пользуется и мобильным приложением и вебом Настроил больше 4 костюмных папок