У вас, в худшем случае, есть ваш комп, на котором вы всё тестируете перед выкаткой. Проверяете во всех браузерах, запускаете автоматические тесты, возможно, нагрузочные. В хорошем случае — есть ферма машин или даже отдел тестирования. Это стандартные практики по соблюдению качества продукта. Но это малая часть того, что можно сделать.
В докладе я расскажу, какой плаcт работ мы еще делаем, чтобы улучшить техническое качество продукта. Сконцентрируюсь на frontend. Рассмотрим вопросы:
1. Логирование.
2. Мониторинг.
3. Алертинг.
4. Бета-пользователи.
5. Саппорт.
6. Плагины.
7. Антивирусы.
и т.п.
Делая этот доклад я поставил себе прагматичную цель — слышать больше разумных мыслей от кандидатов на собеседовании.
Я вижу много сильных программистов, но в процессе разговора с ними я понимаю что им нельзя давать продукт.
Да, им можно дать таски на выполнение, но фичу или продукт не в коем случае.
И это удивительно, всегда кажется что чем сильнее разработчик, тем больше у него ответственности, а на практике это совсем разные вещи.
Причем бывает и наоборот, технически человек на троечку, но пообщаешься с ним и видишь что с продуктом, с точки зрения стабильности все будет отлично.
Давайте рассмотрим одно из собеседований. Ко мне на собеседование человек приходит после технического собеседования.
Это значит что команда готова с ним работать как с технарем.
Я задаю вопрос:
Я не помню чтобы хоть кто-то вы этот момент сказал "не я".
И в целом никто не хочет меня обмануть и правда считает что именно он держит проект на своих хрупких плечах.
Но давайте копнем глубже.
Вот тут выясняются интересные подробности.
Разработчик начинает рассказывать подробности бага, а я невзначай спрашиваю:
— А как узнал о проблеме?
— Менеджер сказал.
У меня резонный вопрос, если менеджер сообщает о проблемах на продакшене, в чем заключается ответственность разработчика?
Иногда менеджер заменяется за админа, генерального директора фирмы и тп. Но сути это не меняет.
В такой схеме контролем продакшена занимается не разработчик а кто-то другой, потому что убери этого менеджера из цепочки и лежащий продакшен будет и дальше лежать.
На самом деле некоторые в этот момент осознают проблему и говорят:
— И правда я не отвечаю за продакшен.
Но есть настойчивые, и находят собственное успокоение в разделении труда. Тестировать должны тестировщики, а я должен заниматься своим делом.
И мы плавно подходим к следующему логическому вопросу.
Тут самые популярные ответы:
— Я буду сам все тщательно проверять
— Я напишу авто тесты
Занятие крайне нужное, на забегая вперед, поставленную в докладе задачу не решает.
Не решает по простой причине, все эти меры работают до продакшена.
И действительно снижают вероятность проблем в последнем, но не позволяют следить за продакшеном!
Но давайте вернемся к кандидату, я задаю резонный вопрос:
— Если все это надо делать, почему не делаешь?
Тут начинается длинная речь про то что не дают времени, начальству все равно и т.п.
Я уточняю:
— Наличие тестов увеличит твою производительность?
— Да.
— Тогда почему ты не делаешь то что увеличит твою производительность?
(Слайд про эскалацию?)
А теперь давайте вообще очистим сознание, вы сами и начальник.
Никого не надо убеждать и выбивать время, вы его распределяете.
На что вы его потратите? Только учтите что надо платить себе ЗП а это заначит что надо зарабатывать деньги!
После этого вопроса даже самые рьяные начинают задумываться, потому что в этой схеме рассказывать что кто-то другой виноват невозможно, других просто нет, есть только вы.
Вообще был интересный случай недавно. Один из руководителей группы первый раз пришел на собеседование которое я вел и долго слушал как я веду кандидата по этой схеме.
В какой-то момент он не выдержал и спросил:
— А зачем ты вообще рассказываешь менеджерам как правильно надо сделать, просто сделай и все.
Итак, мы выяснили что винить некого.
Еще мы выяснили что тесты это хорошо, но этого мало.
Что делать?
Первая мысль у всех одна и она вроде как верная — мониторинг!
Но тут многие тоже ограниченны рамками программирования, на вопрос что будете мониторить отвечают:
— Ошибки.
Кто-то говорит про JS ошибки, кто-то про ошибки ответа сервера, кто-то и про то и про то.
Шаг верный, но это скорее не шаг а намерение его сделать
Ответственность за продакшен это не ответственность за программу это ответственность за то что пользователь может воспользоваться программой.
А как мы понимаем что пользователи могут пользоваться сервисом?
По продуктовым показателям. На примере почты это количество отправок писем, чтений писем, прикрепления файлов к письмам и тп
Тут надо следить что количество хитов на успешное завершение действия не упало или наоборот не выросло.
Например, отвалился канал к какому-то провайдеру. Пользователи вообще не могут попасть к вам на сайт.
Никакие графики ошибок не шелохнулись, а сервис недоступен. Надо выяснять звонить провайдеру и разбираться.
А был вообще замечательный случай.
У нас резко выросло количество заходов в почту. Никаких ошибок нет все гладко, но хиты выросли.
Стали копать, оказалось что рост в одной из старых опер.
Зашли этой оперой, видим что у курсора мышки все время крутится колесико загрузки.
Стало очевидно что пользователи ждут пока оно пропадет, ждут долго, потом решают что что-то зависло и жмут F5.
А причина такого кручения — затупивший ответ стоявшего у нас счетчика.
Выключили счетчик и переписали его на неблокирующую схему.
А вообще прям легко вижу что некоторые в этот момент скажут, ну у меня все работает надо ждать пока счетчик перестанет тупить!
Переводится это так:
— Я знаю что пользователи сервиса, который я разрабатываю страдают, но мне все равно.
Начните с простого. Можно с самого простого.
Дергайте пиксель в nginx и грепайте логи.
Используйте популярные счетчики
Инструменты вебмастера.
В конце концов вы доберетесь до того что будете рисовать свои графики.
Инструментов тоже много, самые популярные у нас это rrd и graphite.
Количество графиков будет расти и вы сделаете дашборд.
Он будет у вас на отдельно мониторе/телевизоре и вы будете на него смотреть.
Вы все чаще на заявление менеджера
— У меня не работает
Будете отвечать
— В курсе уже исправляю
С каждой новой исправленной проблемой буду появляться новые графики.
Графиков у вас стало так много что некоторые вы не смотрели уже несколько месяцев и если там что-то отклонилось от нормы вы про это не в курсе.
Теперь вам нужна система, которая автоматом говорит что какой-то график отклонился от нормы.
Тут масса вариантов и если вы оказались тут то ваша система мониторинга это уже отдельный проект вы его давно хотите отрефакторить или переписать.
Давайте сделаем это с пользой для проекта.
Тут на самом деле масса вариантов.
Есть и очень затратные с машинным обучением
А есть и простые, которые тоже дают отличный результат.
Если у вас график ошибок, то если случилась ошибка надо алертить. Алгоритм простой и понятный, если есть фон, это плохо , тогда порог алерта выше чем ноль.
Если это продуктовый показатель, то он зависит от посещаемости сайта, а значит ночью значения маленькие, а днем высокие. Порог срабатывания не подберешь.
Тут есть вариант сравнивать со значение недельной давности, но сами понимаете, праздники все ломают.
Есть хитрость, этот график можно пронормировать на график посещаемости и это уже может получиться прямая, которой можно выставить пороги как снизу так и сверху.
У себя мы используем два этапа
Строим график разницы текущей точки с предыдущей, это позволяет плато превращать в пики
Строим значения корреляции последнего временного промежутка с эталонным выбросом и если корреляция высокая это выброс и срабатывает алертинг.
У этого способа есть небольшой недостаток, время срабатывания задерживается на время исследуемого промежутка. Но зато не зависит от праздниковАлертинг.
Мы используем два способа — почта и СМС.
Важный момент, надо реагировать на все алерты, иначе довольно быстро они перестанут быть полезными.
Если у вас сработал алертинг надо починить проблему, завтра к нему добавится еще один, после завтра еще один а через месяц вам будет приходить 20 СМС в час и вы будете все их игнорить.
Если у вас есть сапорт, под сапортом я понимаю любого человека который напрямую контактирует с пользователем.
В некоторых фирмах это может быть менеджер по продажам.
Так вот эти люди для вас такой же мониторинг как и ваши графики.
Никогда не общайтесь с ними через менеджера. Причина та же — нет менеджера вы не в курсе о проблеме.
Регулярно встречайтесь с этмим людьми, договоритесь об удобном и оперативном способе оповещения вас о проблемах.
Прежде чем катить что-то предупредите их на жалобы в каких местах проекта надо обращать внимания.
Вы не поверите но несколько кране редких и забористых багов мы нашли после того как у видели в ленте жалобу на сервис.
Поэтому видите что кто-то жалуется, напишите ему в личку, выясните подробности. Разберитесь.
Крайне эффективный способ убрать одно звено в виде сапорта.
Набираете бета пользователей и даете им возможность пожаловаться прямо с сайта.
Жалобы поступают вам на почту.
Этот способ показал себя крайне эффективным у нас на проекте.
Тут самый важный момент — как выбрать бета пользователей, у себя мы сформулировали ряд критериев:
Пользуется и мобильным приложением и вебом
Настроил больше 4 костюмных папок