Как быть всегда готовым зарабатывать больше: мониторинг, план Б
•Télécharger en tant que PPTX, PDF•
2 j'aime•750 vues
Почему всё рано или поздно поломается. Случаи из нашей практики. Советы как с этим бороться. Доклад Владимира Лучанинова 2018-07-14 на конференции 8P.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Как быть всегда готовым зарабатывать больше: мониторинг, план Б
Similaire à Как быть всегда готовым зарабатывать больше: мониторинг, план Б (20)
Как быть всегда готовым зарабатывать больше: мониторинг, план Б
- 1. Как быть всегда готовым зарабатывать больше: мониторинг, план Б Владимир Лучанинов
- 2. Потери при поломках • Сейчас: $ • Потом: репутация • люди • Bot Quality Score: AdWords, Search Владимир Лучанинов, Playtini
- 3. План доклада: Где поломается? Что поломается? Что делать? Владимир Лучанинов, Playtini
- 5. Где поломается? Владимир Лучанинов, Playtini
- 6. Ваш сайт 99.8% uptime = 18h / year downtime на наших shared hostings – 98-99% Владимир Лучанинов, Playtini
- 7. Ваш сайт TDS У вас одна TDS на одном сервере? Владимир Лучанинов, Playtini
- 8. Ваш сайт TDS партнёрки TDS Вы мониторите чужие сервисы? Владимир Лучанинов, Playtini
- 9. Ваш сайт TDS партнёрки TDS Money- сайт Достаточно глубоко? Владимир Лучанинов, Playtini
- 10. Ваш сайт TDS партнёрки TDS Money-сайт Платёжка Достаточно глубоко?? Владимир Лучанинов, Playtini
- 11. Ваш сайт TDS партнёрки TDS Сайт аффилиата Помогите важным партнёрам За 10 лет нам никто из партнёрок не сказал о поломанном сайте Владимир Лучанинов, Playtini
- 12. Что поломается? Владимир Лучанинов, Playtini
- 14. Закончился Интернет • Забыли оплатить • Поломка на магистрали • Ошибка в биллинге Владимир Лучанинов, Playtini
- 15. Абуза • Хостеру • Сервису рассылок • Сервису платежей • Google • Доменному регистратору Владимир Лучанинов, Playtini
- 16. Поломался диск • Bad sectors • RAID поломался • 100% диска занято Владимир Лучанинов, Playtini
- 17. Что поломается: Сервис • База данных • Обновление вашего сайта • Обновления на сервере • Не поднялся после рестарта • Взлом Владимир Лучанинов, Playtini
- 18. Что поломается: Борбаг • Поломался клоакинг • Поломался хитрый редирект • Самоуничтожение • закрылись в robots.txt от *Bot (включая AdsBot) • переусердствовали в борьбе с DDOS и парсилками Владимир Лучанинов, Playtini
- 19. Что поломается: SEO-баг • robots.txt – Disallow: / • и ещё 5 способов закрыться • Скрытые 404-е • Поломанные внутренние ссылки Владимир Лучанинов, Playtini
- 20. Что поломается: Cruel World • NS: сервера, записи (A, AAAA, MX, TXT) • РКН, DMCA, фильтры поисковиков • Трояны у клиентов • Проблемы на money-сайте • поломалась регистрация • поломалась соц. регистрация • Проблемы с платежами • иногда только на мобильных Владимир Лучанинов, Playtini
- 21. Что делать? Владимир Лучанинов, Playtini
- 22. Составить таблицу угроз Вероятность Вред Простота предотвращения Владимир Лучанинов, Playtini
- 23. Настроить мониторинг • Прокладки для детального мониторинга • Уведомления по критичным проверкам • Ручные еженедельные чеклисты для сложноавтоматизируемых проверок Владимир Лучанинов, Playtini
- 24. Настроить бекапы и автопочинку • MySQL slave • Несколько IP на всех этапах • бонус: nginx healthcheck • Закрыться от лишних ботов Владимир Лучанинов, Playtini
- 25. План восстановления • Чеклист для «дежурного» • Учения • Пересмотр раз в год Владимир Лучанинов, Playtini
- 26. Ломаться – это плохо - потеря $ сейчас - потеря $ потом Что поломается - ваши сервера - ваши сервисы - иногда незаметно - внешние сервисы Что делать - составить список угроз - настроить мониторинг - планы починки Владимир Лучанинов, Playtini
- 27. Давайте дружить! P.S. Ищем умных людей в команду Playtini facebook.com/luchaninov
Notes de l'éditeur
- Всем привет! Я занимаюсь интернет-маркетингом уже больше 10 лет и понимаю, что, конечно, важнее всего найти правильную нишу, правильный способ привлекать трафик и конвертить его. Но! Всё это умножается на 0, если у вас не работает сайт или, что более подло – вы недополучаете 10-20% из-за того, что часть трафика уходит в никуда. Это можно не замечать месяцами. Поэтому, если вы уже нашли любимую нишу и трафик идёт и конвертится, мой доклад вам пригодится.
- Что именно вы теряете при поломках. Очевидно, что деньги сейчас. Если люди хотят заплатить вам деньги и не могут, то это прямые потери. Сложнее посчитать потери в будущем. Думаю, многие сталкивались с тем, что когда заходите на сайт и он не работает или работает не полностью, кажется, что там работают не самые толковые люди. Это влияет на конверсию. Боты тоже оценивают ваш сайт и его работоспособность – одна из метрик. Все знают Quality Score в AdWords – downtime уменьшает Landing Page experience и тем самым этот Score. По органике ещё хуже – если ваш сайт не работает, то будет сумасшедший bounce rate. Поэтому потери в будущем могут значительно превышать прямые потери.
- Я расскажу о том что и где поломается и что с этим делать
- Disclaimer: я буду рассказывать только о тех вещах, которые случались с нами и которые мы переживали особенно неприятно. Возможно, я не учёл какие-то другие факторы – если у вас случались другие неприятные истории, расскажите мне об этом после доклада, поплачем вместе )
- Итак, понятно, что поломки это плохо, но нельзя говорить, что поломался автобус, нужно попытаться разложить поломки по месту возникновения.
- Плохо, если поломался ваш сайт. Хуже, если вы об этом не знаете. Следите за тем, какой uptime у вашего сайта, ищите хостинги, которые гарантируют uptime. Когда вам гарантируют 99.8% uptime – это значит, что сайт может лежать суммарно почти день в год и хостинг будет говорить, что это в пределах нормы. И даже это вполне хорошо. Много наших сайтов находятся на shared hostings и мы эволюцинно убирали самые плохие годами, мониторим и быстро переносим и максимум чего получается добиваться – 98-99%. Для важных парней существует SLA, когда при неработоспособности вам компенсируют не просто стоимость простоя, а чуть больше. У Amazon, если месячный uptime меньше 99.99%, то можно получить 10% скидку.
- Дальше вы с кучи сайтов отправляете трафик на TDS, чтобы считать статистику и оперативно управлять потоками трафика. Если у вас одна TDS, то её поломка превращает все ваши сайты в тыкву. В принципе, общее правило – нужно дублировать всё что можно в пределах разумного. Если бы была ещё одна TDS полностью настроенная про запас в другой стране, вы бы просто поменяли IP и хоть статистика слетела, как минимум, трафик не потеряли.
- Ваша TDS может слать трафик не напрямую на money-сайт, а на TDS партнёрки, CPA-агрегатора. Они тоже могут поломаться. Полезно их мониторить и быстро переключаться на запасные методы монетизации. Также, если вы скажете о поломке партнёрке или агрегатору, это уменьшает время починки.
- И может не работать сайт, который монетизирует ваш трафик. Причины не важны: они обновляют сайт, переносят на более мощные сервера, их заблокировал РКН. Главное – это то, что вы теряете деньги. Поругайтесь с партнёркой, если они вас не уведомили и как с TDS переключите трафик на альтернативную монетизацию.
- Иногда и сайт работает, а заказов нет или они просели. Это может быть из-за того, что не работает какая-то из подсистем сайта. Например, платёжка. И только на мобильных. И только в одной стране. Опять же можно говорить, что это проблема того сайта, но это не добавляет денег. А переключение трафика из этой страны для мобильных на другого партнёра добавляет.
- Если вы сами монетизирующий сайт и у вас есть партнёры – дружите с ключевыми партнёрами, узнавайте их топовые площадки, мониторьте их. Есть много аффилиатов, которые работают не каждый день и могут только через несколько дней заметить, что их сайт поломался. Когда мы только начинали – у нас тоже такое было. И несмотря на то, что мы отправляли уже много трафика, нам не сказал об этом ни один из партнёров, на которые мы сливали трафик. И они потеряли не только возможность построить более хорошие взаимоотношение, но и деньги от недополученного трафика.
- Перейдём к тому, что именно ломалось у нас и к чему мы не были готовы. У программистов есть “Bus Test”. Его суть, оценить насколько пострадает бизнес, если кого-то из команды переедет автобус. Это убирает отговорки, что этого не случится, этот человек никогда не уйдёт. Автобус может переехать каждого и мы на это не влияем. У меня есть аналогичный тест для проверки нечеловеческих частей системы. Когда мне рассказывают как будет работать сайт или другая система, я спрашиваю, а что будет, если сервер сгорит. В смысле сгорит? Я объясняю – совсем сгорит, пламя-паника-сгорел, что мы будем делать, какой план. И начинают придумывать, задумываются о бекапах. Для важных систем я потом задаю ещё вопрос, а что будет, если датацентр сгорит. В смысле? Попала молния, всё сгорело. Что делаем? И бекапы выносятся в другие страны. Естественно именно так сервисы ломаются редко, но эффект такой же как от других плохих событий, но сложнее придумать отговорку почему это не произойдёт.
- Итак, возьмём условных PPCшников, которые полезли делать рекламу в запрещённых тематиках. Посчитали, что на $1 получаем в тот же день $1.20. Класс – золотая жила. Но кроме того, что на них будут писать абузы в AdWords, накликивать, им ещё сделают трафика столько, сколько они не ожидали. Сайт грузится 10 секунд, 50% людей не доходят куда нужно и на $1 уже получаем $0.60 и это уже не выгодно. Можно частично защититься от этого CloudFlare, блеклистами, но важно не перестараться и не заблокировать настоящих пользователей, за которых вы заплатили. Долгосрочно правильнее делать сайты настолько простые и на таких широких каналах, что DDOS будет делать очень дорого. Если сайт на Wordpress без кеша – его можно положить с одного компьютера, если сайт статический на хорошем хостинге, то это уже очень сложно и с тысяч компьютеров.
- Наши сервера неожиданно отключались от Интернета по разным причинам. Банальная – человек уволился или ушёл в отпуск и не передал задачи по продлению. От этого мы защитились тем, что у нас все сервера вносятся в предсказуемые места и несколько человек знает как с этим работать и когда продлять. Раз в несколько лет у большинства хостеров случается «поломка на магистрали». Это может быть заметно, так как к серверу никто не может достучаться, так и более подло, когда только пользователи части провайдеров или регионов не могут на него попасть. И бывают ошибки в контрол-панелях хостеров, когда они не видят ваш платёж и вместо того, чтобы связаться с вами, решают, что эффективнее отключить ваш сервер. Это обычно случается с небольшими хостингами, где не отлажены процессы.
- Ещё конкуренты, а иногда и честные правообладатели любят жаловаться. Ябедничают всем, кто вам помогает строить бизнес в интернете: хостеру, доменному регистратору, SaaS-сервисам, которыми вы пользуетесь, гуглу. Обычно это не очень эффективно, но зависит от обоснованности претензии и пугливости сервис-провайдера. Иногда говорят, мы понимаем, что вы не нарушаете наших правил, но мы не хотим предоставлять услуги тем, на кого жалуются. В целом, я считаю, что бороться так с конкурентами – глупая затея, потому что в ответ тоже будут жаловаться и вместо того, чтобы улучшать продукт для клиента, все тратят время на гадости и в итоге меньше зарабатывают.
- По статистике несколько процентов жёстких дисков умрёт в этом году. Физически – или будут плохие сектора или не будет включаться. С этим борятся тем, что берут в 2-3 раза больше дисков и делают RAID. Но при этом мы добавляем ещё одну точку отказа – RAID-контроллер, который тоже может поломаться и записать гадости на оба диска одновременно. Конечно, вероятность поломки RAID значительно меньше, но всё равно это не панацея. Ещё может ничего не поломаться, но база данных не сможет зарегистрировать нового пользователя, потому что диск занят на 100% какой-то важной и полезной информацией, например логами, которые неправильно настроили или забили DDOSом.
- Что ещё у нас ломалось: база данных MySQL со старым движком MyISAM, при обновлении сайта он не запускался, потому что production окружение отличалось от настроек у программистов. Запускали важные обновления на сервере, которые перезапускали базу данных и она не перезапускалась, обновляла версию PHP, а приложение не работало на этой версии. Дата-центры неожиданно переносили сервера в другие локации, для этого всего на 15 минут выключали и включали сервера, но сервера не были настроенты правильно запускаться при загрузке сервера. Ну и конечно, нам добавляли дополнительный функционал, который мы не просили, какие-то анонимные доброжелатели. Обычно это что-то относительно безобидное, вроде нового контента со ссылками на релевантные ресурсы.
- Когда вы добавляете сложную логику в обработку трафика эта логика может поломаться. Например, при клоакинге вы нормальным людям показываете версию для Googlebot и наоборот. Вы делаете хитрые редиректы при переезде, разделяя версию для Google и Yandex, но при этом всем ботам показыватся ошибка https-сертификата. Вы этого не видите, потому что нормальным людям показывается всё ок. Также вы во имя добра боретесь с ботами и случайно закрываетесь от рекламных ботов и вас банят в AdWords за клоакинг, хотя вы как раз в этот раз и не клоачили. Вы начинаете бояться DDOS и парсилок, закрываете кол-во заходов с одного IP и всё работает хорошо. Потом кому-то приходит гениальная идея закрыться через CloudFlare. CloudFlare ходит через не так много IP, вы его блочите и у всех людей ломается сайт.
- Для SEO-шников есть бесчисленное разнообразие вариантов налажать. От простого, когда программисты, чтобы stage не индексился, добавляют в robots disallow слеш, потом заливают новую версию на production и вы не понимаете, где ошиблись в текстах или html, что теперь из google начали пропадать страницы. Некоторые программисты знают более изощирённые способы убирания страниц из индекса: meta-теги, блок noindex, хедеры X-Robots, неправильные hreflang и canonical, которые тоже могут быть в html и в headers. Однажды мы поломали сразу почти 100 сайтов тем, что из-за ошибки в CMS на внутренних страницах показывали нормальную страницу, но http status code 404. Также часто случалось, что ссылки поменяли с games на game, но забыли поставить редиректы со старых страниц и все тяжёлым трудом наработанные ссылки стали ссылаться на 404.
- Даже если вы у себя сделали всё правильно, всё будет ломаться у остальных. Хостинги переносят сайты и сервера между IP без предупреждения. Ваши коллеги переносят домен на другого регистратора или хостера и копируют только A-запись для основного домена, забывая про поддомены, MX и TXT-записи. Вас банят другие компании, которые влияют на дохождение трафика до вас. У нас был интересный случай: довольно много клиентов начало говорить, что заходят на наш сайт и видят на весь экран баннер конкурента. Мы перепроверили весь наш код, переехали на новый чистый сервер – не помогло. Потом разобрались, что они все установили плагин к браузеру для просмотра бесплатных фильмов. Разобрали плагин – там было много e-commerce сайтов, на которых такое работало. К счастью, Интернет не настолько анонимен как кажется, мы нашли их в оффлайне. По-моему, они тогда вообще убрали всех из нашей ниши на всякий случай. Ну и о проблемах на сайтах, которые монетизируют ваш трафик, я уже говорил.
- Итак, что же с этим всем делать.
- Не все вредные последствия одинаковы. Составьте табличку с тем, что может угрожать вам. Оцените вероятность, ущерб и простоту предотвращения. Вы не уберёте все угрозы, но хотя бы самые важные и самые простые.
- Настройте мониторинг на всё, что можно. Обычно мониторинг – это просто зайти на сайт и посмотреть, что ответ 200 ОК или 302 с нужным Location, но иногда нужно что-то сложнее. Не ищите систему мониторинга, которая умеет проверять всё. Проще написать скрипт, который делает эту сложную логику и возвращает 200 OK или 500 при ошибке. Часть вещей могут ломаться и вам об этом не надо знать моментально, достаточно знать uptime за последний день. На критические вещи настройте моментальные уведомлялки – удобно, когда это отдельный чат, а не тот, которым вы пользуетесь для общения, чтобы было заметнее. Что сложно мониторить, не автоматизируйте. Сделайте чеклист с инструкциями и дайте кому-то его заполнять раз в неделю и уведомлять вас, если что-то пошло не так.
- Есть много готовых решений как делать бекапы, дублировать сервисы, автоматически исключать те, которые поломались. Смотрите, чем вы пользуетесь, заставляйте программистов и девопсов думать. Вам достаточно того, чтобы они могли внятно объяснить, что произойдёт, когда сгорит сервер: когда вы об этом узнаете, сколько данных потеряется, какой будет downtime, починится само или нужно участие человека.
- Почти всё можно чинить автоматически, но может быть сложно настроить. Для сложных починок достаточно текстового чеклиста и человека, который может по этим инструкциям восстановить сайт даже на выходных или ночью. Автоматика сбоит, поэтому даже там, где есть автопочинка должен быть ещё и ручной план. У нас было такое: сайты находятся на 2 серверах и одновременно на обоих они начинают удаляться. Потом разобрались, что это была ошибка в CMS, но 1000 сайтов работали с перебоями. Благодаря тому, что были люди, которые знали как чинить, мы починили это за 1.5 часа. По-хорошему, нужно самому создавать такие критические ситуации для проверки автопочинок и готовности людей. Также инструкции должны быть актуальными, иначе они не будут работать.
- Итого. Ломаться – это очень плохо, и надо учитывать и потери в будущем. Поломаться может что угодно, проверяйте по тесту «этот сервер в огне». Бороться с этим можно: составьте список угроз, настройте мониторинг, чтобы знать, когда они настанут и составьте инструкции на случай этих угроз.
- Если вам это не показалось сильно сложным и вы ищете работу с сфере интернет-маркетинга, пишите мне. Playtini всегда ищет умных людей. И даже если не ищете работу и вопросов нет, добавляйте меня в Facebook.