Привет, Хабр! А особенный привет тем, кто в этом году идет на конференцию Highload++, потому что мы там обязательно встретимся. Мы придем, и не с пустыми руками: восемь докладов в семь разных секций.
Но нам не хочется просто показать описания наших докладов, чтобы вы прочитали и сказали: “Понятно”. Мы разыграем 3 билета на конференцию. Для того, чтобы получить их, нужно задать вопрос в комментариях к этому посту одному из нижеперечисленных спикеров, а мы посоветуемся и наградим троих участников. Чтобы вы смогли придумать вопросы, каждый из ребят немного рассказал о команде, в которой работает, и о своей роли в ней.
Под катом – имена, пароли и, конечно, описания наших докладов на конференции.
Первый день Highload++, 7 ноября
Михаил Овчинников, Scalar, глава команды Антиспам
О команде и о себе:
В Badoo я занимаюсь борьбой со спамом, с мошенничеством и с другими неприятными шутками. Дело это непростое, никаких точных методик или специализированных решений для борьбы со спамом в соцсети не существует, и каждая компания изобретает свой антиспам заново.
Наша команда создает ручные и автоматические инструменты, которые помогают нам оперативно находить и блокировать сотни тысяч нехороших аккаунтов. Мы активно используем наши внутренние технологии, такие как скриптовое облако и стриминговый демон LSD, а также Spark для задач обработки данных и машинного обучения. Пишем на PHP и Scala. Пишем В MySQL, Tarantool и HDFS/Hive.
Тема: Вычисляем по IP: как бороться со спамом в социальной сети
Секция: Big Data и машинное обучение
Время и зал: 13:00, зал «Найроби + Касабланка»
О чем доклад:
Badoo — социальная сеть знакомств и очень привлекательное место для спамеров и мошенников, нигерийских принцев и разносчиков adult-контента.
В докладе будет рассказ о том, почему вы не найдете этих персонажей на нашем сервисе, как классифицировать миллиарды действий пользователей и выявлять спам в реальном времени, как мы используем модели машинного обучения и избавляемся от ложных срабатываний.
Поговорим про обряды выявления порчи на IP-адресе, проклятия на устройстве или отворота на номере телефона. Определяем спам по фотографии и чертам лица и изучаем раздвоение личности с помощью Apache Spark.
Как антиспам в Badoo прошел путь от 2 скриптов и 75 регулярных выражений до целого множества систем всех сортов и расцветок.
Алексей Рыбак, fisher, ex-глава разработки Badoo
О команде и о себе:
Бывший глава разработки Badoo. Работал в Badoo с 2005 до 2017 года, поэтому можно задавать любые вопросы, которые касаются разработки Badoo.
Тема: Как построить хороший performance review: опыт Badoo
Секция: Управление командой разработки (тимлиды)
Время и зал: 15:00, Главный зал
О чем доклад:
Многие инженеры нервно кривят лицо, когда слышат слова «оценка производительности работы». Кто-то вспоминает слухи о разнарядках Microsoft, кто-то – бессмысленные длиннющие формы, которые приходится заполнять раз в год по указке сверху.
– Менеджерская мутотень!
– Инженеров нельзя измерить, ревью только мешают!
– KPI для инженеров не работают, только раздражают!
Всё это можно услышать во время обсуждения performance review и, наверное, во многих случаях это сущая правда.
Badoo – инженерная компания, и, конечно, мы не родились с performance review. Наше первое знакомство случилось давно, когда нам было, кажется, лет шесть. Тогда в нашей компании был старший товарищ, который уже имел дело c performance review, и он уговорил нас попробовать. Мы решились, убеждая себя: «Ну, один или два раза. Всегда сможем остановиться».
В общем, нам так понравилось, что ревью с тех пор работает у нас практически без изменений, и мы уже не можем себе представить, как без него жить. С помощью него мы ретранслируем наши ценности, делимся новостями, благодарим, подсказываем коллегам, куда и как расти, и этот процесс очень помогает в работе техлидам.
В этом докладе расскажу:
- о простых правилах успешного ревью;
- как мы создавали и внедряли сам процесс;
- с какими проблемами столкнулись и как их решаем;
- нужен ли вообще вам review.
Второй день Highload++, 8 ноября
Виталий Шароватов, vsh, глава Front-End
О команде и о себе:
В Badoo я руковожу отделом frontend-разработки, управляю двумя командами: Mobile Web и Desktop Web. Фронтенд в Badoo релизится каждый день (а то и по два раза), выпускает сотни A/B-тестов и поддерживает множество проектов.
Я занимаюсь исключительно управлением, веду стратегию команд, помогаю тимлидам обоих проектов выстраивать процессы, мотивацию и атмосферу. Мои команды каждый квартал бьют свои же собственные рекорды по производительности, а проекты растут как на дрожжах.
Тема: Как я был тимлидом, а теперь – руководитель направления
Секция: Управление командой разработки (тимлиды)
Время и зал: 11:00, Главный зал
О чем доклад:
В докладе я расскажу о двух темах: как выглядит рост из тимлида в руководителя отдела, и как выбирать тимлида себе на замену, помогать ему становиться эффективным.
Выступление основано только на моем опыте работы с двумя командами: Mobile Web и Desktop Web. Возможно, вы уже читали мой пост на Хабре о том, как из разработчика я вырос в тимлида, но это мое выступление будет чуть более высокого уровня. Я поделюсь моим обновленным опытом.
Немного поговорю о психологии, об атмосфере в команде, менторстве, конечно, о найме и многом другом.
Из моего выступления вы узнаете, как:
- грамотно выбрать тимлида: на основании каких критериев, как проверить, насколько человек может подойти, как продавать идею смены карьеры и бороться с классическими страхами;
- помочь выбранному человеку уверенно войти в курс дела и стать максимально эффективным, бороться;
- мониторить обстановку в командах и держать руку “на пульсе”;
- перестать лидить команды самому, и чем управление лидами отличается от управления разработчиками.
Илья Аблеев, ableev, глава команды мониторинга
О команде и о себе:
Я руковожу мониторингом в Badoo, знаю всё о технической и организационной части отдела. Проблемы случаются постоянно, поэтому и отдел наш – круглосуточный. На Хайлоаде буду рассказывать про то, как мы с ними (проблемами) живём, как уведомляем о них, следим и разбираемся после починки.
В качестве платформы для проверки работоспособности критичных компонентов у нас используется Zabbix: я неоднократно выступал с различными докладами, рассказывая, как мы его готовим.
Много скриптуем и автоматизируем, внедряем в Zabbix, допиливаем его, не меняя основной код, – в основном bash (просто и понятно для всех) и Python (так как позволяет сложные вещи просто, когда на bash получается монструозно).
Тема: Инцидент-менеджмент в Badoo
Секция: DevOps и эксплуатация
Время и зал: 12:00, зал «Китай»
О чем доклад:
Технологические команды разного размера рано или поздно сталкиваются с тем, что возникающие проблемы становится сложнее контролировать. Какие-то события возникают сами по себе, какие-то – "благодаря" человеческому вмешательству, – или что-то идёт не так после заранее запланированных работ.
Всё это приводит к тому, что страдают и пользователи (потому что у них что-то не работает), и сотрудники (потому что им приходится тратить больше времени на выяснение причин случившегося).
В своём докладе я расскажу про эволюцию того, как мы в Badoo контролировали инциденты, какие методы позволяют нам минимизировать временные затраты для решения возникающих проблем и что мы делаем после того, как их локализовали.
Михаил Курмаев, demi_urg, глава A-Team
О команде и о себе:
Я руковожу отделом, который называется A-Team. A-Team — это PHP-разработчики, занятые написанием кода для работы с базой данных, сишными демонами и созданием инструментов для решения задач, с которыми сталкиваются другие разработчики в Badoo. Например: системы очередей, кэширование, облачные вычисления, сбор технической статистики и т. д.
Также наша команда занята разработкой внутренних утилит для управления серверами и выкладкой кода.
Тема: Жизнь после шардинга
Секция: Архитектуры, масштабируемость
Время и зал: 14:00, Главный зал
О чем доклад:
Многие считают, что для создания хорошего highload-проекта нужно расшардить данные правильным образом и спать спокойно, доставляя сервера по мере необходимости. На самом деле только после шардинга начинается все самое интересное, так как после физического разделения данные не перестают быть логически связанными. Именно поэтому необходимо создать инструменты для поддержания целостности этих данных.
Я расскажу, как мы в Badoo подходим к решению задач подобного класса.
Александр Гутников, alxgutnikov, фронтенд-разработчик, Desktop Web
О команде и о себе:
В Badoo я занимаюсь фронтенд-разработкой, пишу и поддерживаю инструменты сборки и релиза статики, иногда пишу статьи на Хабр. Web в Badoo – очень динамичное направление, мы много работаем над экспериментами в области UI/UX, ведем большое количество А/Б-тестов и релизим десятки задач в неделю. Что касается технической части: у нас не так много сторонних средств, которые мы активно используем, но они есть: например, WebPack или Sass, и еще мы поглядываем в сторону средств статической типизации.
Тема: Мониторинг производительности фронтенда в Badoo
Секция: Архитектура и производительность фронтенда
Время и зал: 15:00, зал «Москва»
О чем доклад:
Производительность – важный аспект работы современных web-приложений, и с каждым годом разработчики уделяют ему все больше внимания. Мы вкладываем много сил в разработку и оптимизацию, тщательно все тестируем, но достаточно ли этого, чтобы в день релиза быть уверенными, что у наших пользователей все действительно хорошо и быстро работает? Лучший способ в этом убедиться – следить за тем, как приложение ведет себя у реальных пользователей.
В докладе поговорим о сборе и анализе данных в целом и о том, какие инструменты для это используются в Badoo.
Ярослав Голуб, yagolub, PHP-разработчик, SRV Team
О команде и о себе:
Меня зовут Ярослав, и я PHP-программист в серверной команде. Я из той части команды, которая занимается поддержкой и разработкой внутреннего API для наших клиентов на стороне back-end. Мы пишем на PHP, протокол у нас Protobuf, и у нас сотни тысяч человекочасов опыта хождения по граблям разработки API.
Тема: Как мы поддерживаем 100 разных версий клиентов в Badoo
Секция: секция Бэкенд, теория программирования
Время и зал: 16:00, Главный зал
О чем доклад:
В Badoo на данный момент на общей кодовой базе работают несколько разных проектов на всех основных платформах (iPhone, Android, Web и т.д.), где каждая платформа может иметь больше десятка одновременно работающих версий.
В этом докладе я расскажу о том, как мы с этим живем и какими подходами решаем задачи разного кода для разных версий клиентов. А именно: как мы меняем протокол, как мы поддерживаем разный серверный код для разных версий клиентов, что такое минорная фича, почему старый клиент – это не страшно, – и как это все помогает в A/B-тестировании.
Антон Турецкий, banuchka, системный администратор, IT Ops
О команде и о себе:
В Badoo я занимаюсь администрированием серверов, инфраструктурой, деплоем внутренних и других сервисов, контейнерезацией и Puppet-изацией. Иногда про это пишу статьи, а иногда даже выхожу в люди и рассказываю что-то со сцены. Мне не нравится определение DevOps!
Админы в Badoo – это почти люди подземелья: то, что мы делаем, обычно никто не знает, чем занимаемся – тоже.
На самом деле, мы не динозавры и технологический стек у нас довольно обширный: xCAT, docker, puppet, glpi, consul, elasticsearch, kibana и все в таком духе. Да, совсем забыл: нам больше всего нравится, чтобы было по максимуму просто и надежно. Внутри команды нам нравится (тем, кому не нравится, – мы прививаем это чувство) шарить знания, что является одной из причин успешной работы команды.
Тема: Джентльменский набор сисадмина
Секция: Системное администрирование
Время и зал: 18:00, зал «Индия»
О чем доклад:
Мне хочется поделиться примерами рабочих процессов и наработанных нами практик в Badoo. Рассказать о том, как можно автоматизировать ресурсоемкие процессы, после чего они покажутся совсем простыми.
- вы увидите говорящего админа;
- я не буду рассказывать про lsof, strace и Linux. Вы и так про них знаете!
- я расскажу о том, что инструменты планирования, о которых вы слышали от менеджеров, могут быть полезными с точки зрения простого админа;
- писать документацию и шарить знания – залог успеха команды;
- какие бывают админы и какие есть у нас;
- я расскажу о том, что инфраструктура датацентра – это не страшно и не так сложно при должном подходе;
- xCAT, Puppet, Docker, Consul? Легко!
P.S. Наличие бороды и свитера с оленями у слушателей приветствуется!
Комментарии (83)
youROCK
19.10.2017 13:26+3Вопрос Александру Гутникову:
Скажите пожалуйста, как у вас сделана локализация для статики (JS/CSS)? Используете ли вы готовые решения вроде webpack и модулей для локализации, или у вас какие-то свои решения?
Поскольку у вас много языков, нет ли у вас такой проблемы, что генерируется множество почти одинаковых JS-файлов, которые отличаются только небольшим набором фраз внутри? Влияет ли это на скорость генерации и объем статики, как вы её сжимаете?
Как сделана сборка статики? Кешируете ли вы промежуточные результаты? И как это всё работает на development-окружении, особенно что касается разработки со стороны backend? Им нужно запускать, грубо говоря, gulp dev каждому, или оно само запускается?
alxgutnikov
19.10.2017 13:55+7Юрий, спасибо за вопросы.
Вы попали в точку, языков действительно много, и когда-то у нас была старая система сборки в которой действительно были такие проблемы. К счастью мы над этим поработали и теперь локализационные бандлы генерируются и хранятся отдельно. Это позволило решить проблемы со скоростью и количеством файлов, а так же сильно повысило скорость генерации. Все что касается переводов, в том числе и сервер, генерирующий бандлы — написано нашей командой backoffice — это свое решение, и оно нас более чем устраивает.
Для сжатия используем UglifyJS, для сборки большей части статики мы используем webpack. Всем кому нужно работать над js/css — запускают его локально, тем же кто работает только с серверной частью — по умолчанию отдается собранная актуальная статика из мастера — им ничего запускать не нужно.youROCK
19.10.2017 14:01+1Тогда еще маленький вопрос: если по умолчанию отдается статика из мастера, то как разрабатываются новые фичи на бэкенде? Т.е. бэкенд сначала разрабатывает отдельно апи, а вы потом его просто используете? Возникает ли необходимость дебажить интеграцию JavaScript-части вместе с бекенд-разработчиками? Как это происходит?
alxgutnikov
19.10.2017 14:39+5У нас все достаточно гибко, любой разработчик может настроить для себя проксирование статики из:
1) мастера ( по дефолту )
2) из шота ( про шоты можно почитать вот в этой статье например habrahabr.ru/company/badoo/blog/317700 )
3) с девела другого разработчика
либо может запустить сборку статики локально, что тоже довольно нетрудно.
Обычно на начальном этапе и фронтенд и бэкенд разработчик могут сделать какую-то часть работы независимо друг от друга. Когда же необходимо тестировать совместную работу — бэкэнд разработчик может собрать шот для клиентской задачи и взять статику оттуда, либо может подмерджить клиентскую задачу и собирать статику локально.
LionAlex
19.10.2017 14:23+2Насколько широко вы используете Go, где и для чего, почему ровно столько и не больше/меньше и планируете ли увеличивать или уменьшать его использование в своих проектах?
Судя по всему, он бы отлично лег на задачи A-Team, например.
Как жизнь с Protobuf? Не слишком ли много времени на возню с ним уходит при отладке/тестировании/и т.д.?
demi_urg
19.10.2017 14:43+2Спасибо за вопрос.
Вы правы в A-Team действительно некоторые задачи решаются на Go, в основном это узкоспециализированые сервисы, которые решают конкретную задачу.
Сильно уменьшать или увеличивать его долю не планируем. Мы стараемся использовать те инструменты которые лучше подходят для задачи не разводя при этом зоопарка.LionAlex
19.10.2017 14:48+1Ну в вашем стеке уже есть как минимум PHP, Java/Scala, C, Go. То есть его использование не добавляет зоопарка.
А "узкоспециализированые" это какие? Ну то есть какие задачи для Го, а какие – нет, с вашей точки зрения?
einstein_man
19.10.2017 17:38Go мы часто используем для задач, которые плохо ложатся на php и хорошо — на Go (concurrency ж киллер фича).
Если при этом же нет жестких требований по контролю памяти или cpu — тогда Go в самый раз.
Например — у нас есть сервис, который шедулит задачи в нашем скриптовом облаке. Сервис (с прекрасным названием LSD) доставки логов между машинами (a-la facebook scribe).
Еще — хороший кейс, имхо, для Go — когда нужна интеграция данных из кучи источников. Например — для распределенного кеша, нужны данные о пользователе, его контактах, последних онлайн действиях и координатах.
Сходить в кучу источников, объединить данные в правильном выходном формате — очень удобно и быстро делается на Go.
einstein_man
19.10.2017 17:40Насчет protobuf — в чем сложность с ним при отладке?
Если речь про «он же бинарный» — у нас есть простые инструменты превращения бинарки в json. Например — даже конфиги сервисов описываются в .proto, но фактически пишутся/генерируются и хранятся в json (слегка пропатченном, с комментами и tail comma).
fredrsf
19.10.2017 14:39+1Вопрос yagolub, Какой подход вы используете для версионирования API, насколько легко/сложно поддерживать несколько версий?
YaGolub
19.10.2017 22:54Спасибо за вопрос!
Если прямо отвечать на ваш вопрос, то никак. Все клиенты всегда работают с последней и единственной версией API.
А вот как мы при этом умудряемся не ломать старых клиентов, то это к сожалению в один комментарий не упихнуть, но вы сможете это узнать из моего доклада. Вкратце скажу, что мы используем специальные флаги поведения для того, чтобы понимать, что поддерживает клиент, и еще несколько подходов в тех случаях, где использование флагов поведения не совсем удобно.
a15199732
19.10.2017 14:53+2Вопрос Алексею Рыбаку. Зачем, и каково это — после 12 лет в одной компании, которая все эти 12 лет делает по-сути один сервис, сменить место работы :)
fisher
19.10.2017 15:13+4Зачем: Badoo перевёл позицию главы разработки в Лондон. Несколько лет мы проводили достаточно серьёзную «перебалансировку» инженерных групп, лондонский офис сильно вырос, так что это абсолютно разумно. По личным причинам я не захотел переезжать. Каково: уточните вопрос. Весело, работы — море. Но вы не правы, что Badoo делает один сервис. Badoo начинался как соц-сеть, у меня на Badoo, например, до сих пор сотни фотографий с тех времён. Были фото-альбомы, ленты активности друзей, комментарии, что-то наподобии «групп» — мы выли воодушевлены тем, что тогда называлось web 2.0 и экспериментрировали очень много, даже сделали однажды аналог чат-рулетки (и быстро закрыли, потому что там началось адище). Совершенно другой сервис, но мы его делали на той же архитектуре, ничего не меняли, что лишний раз подтверждает, что мы изначально выбрали удачные подходы в разработке. Затем большая часть аудитории стала мобильной, Badoo стал mobile-first компанией. Затем Badoo стал превращаться в платформу, на базе которой растет уже несколько продуктов. Ну и для меня лично этот опыт был как три-четыре разные работы — совершенно разный и очень полезный опыт.
a15199732
21.10.2017 19:32В технологиях Badoo крут, спору нет, и это не сарказм.
Но мне интересно узнать вот что — где реализоваться человеку, который так долго выстраивал разработку в отдельно взятой компании со специфическим продуктом и технологическим стеком? Ещё и не покидая России…
Не поверю что уже пенсия, огород и рыбалка? :)
reversecode
19.10.2017 14:57+1Вопрос к разработчикам, почему у меня в веб интерфейсе баду лезут везде баннеры?
Или это в моей геолокации кто то сделал MITM и через https сует свой контент?
Баннеры обычные с гугла, коих хватает на любом сайте
LionAlex
19.10.2017 14:59+2banuchka смотрели ли на какие-нибудь системы управления контейнерами типа Kubernetes? Есть ли планы по внедрению или какие-то аргументы почему оно вам не подходит?
banuchka
19.10.2017 15:05+2Привет,
лучше всего посмотреть вот тут: habrahabr.ru/company/yamoney/blog/339350, youtu.be/pp9nTXa2DTQ. Буквально менее месяца назад я рассказывал в том числе про это.
Если отвечать тут, не переходя по ссылкам: смотрели на все, на которые стоило смотреть, в том числе K8S, Mesos, Nomad. Конкретных планов по внедрению не было и нет. Они могут появиться, если внезапно в какой-то день мы на нашем тестовом стенде поймем, что «вот она серебряная пуля».LionAlex
19.10.2017 15:11+1Ну серебрянной пули не существует.
По нашему опыту, тот же настроенный k8s с шаблонами всех конфигов в скелете сервиса позволяет достаточно легко и быстро распиливать монолит на сервисы и деплоить их в "облако". Проблем по стабилизации, конечно, дофига, но разработчикам сервисов удобно. 30 секунд и твой сервис работает. И никакой беготни по админам/девопсам/еще кому-то.banuchka
19.10.2017 15:21+1Спасибо, я слышал, что k8s хорош. Девопсов у нас нет, а разработчики до нас, скорее всего, не добегут.
Процесс деплоя сервиса на prod окружение несколько сложнее, чем просто «разработчик захотел», а раз это так, то как вывод – мы не упираемся в скорость поднятия в облаке. Облака-то тоже нет :)
ealebed
19.10.2017 15:12+1Вопрос Антону Турецкому:
Используете ли docker в продакшн? И, если да:
— используете ли вы data-only контейнеры для доставки кода или упаковываете код сразу в контейнер (например, с php)?
— какой оркестратор используете и почему?
— сколько нод в docker-кластере, в скольки датацентрах и на скольки континентах они расположены?
— чем мониторите docker-контейнеры (cAdvisor, свои решения, что-то еще?)
— перечислите, какие docker-контейнеры используете. Например, у меня в стеке разворачиваются:
- data-only контейнер с кодом
- nginx
- php-fpm
- redis
- memcached
- websocket
- sdcv (консольный словарь)
- staticus (https://github.com/KIVagant/staticus)
- node-exporter
- cadvisor
Заранее спасибо за ответы!banuchka
19.10.2017 16:14+2Привет!
Docker в production используем, про последние актуальные цифры(что где и сколько) вы можете посмотреть в моем докладе на мероприятии habrahabr.ru/company/yamoney/blog/339350. Ссылка на видео – youtu.be/pp9nTXa2DTQ.
— используете ли вы data-only контейнеры для доставки кода или упаковываете код сразу в контейнер (например, с php)?
Контейнеры с php кодом приложения(читай Badoo) мы как таковые не используем. Причина тому – наличие отдельных(выделенных) машин, на которых кроме nginx+php-fpm, а также кода, более ничего нет. Применение контейнеров там, по нашему мнению, не оправдано и не нужно.
Однако у нас есть некоторые сервисы, которым нужно:
- php
- наличие кода
Для таких случаев делаем так:
- — на машине, на которой предположительно планируется запуск сервиса, который требует вышеописанное, создается «data-»/«mapping-» контейнер, который содержит в себе все необходимые маунты. Обычно это php, code, которые в свою очередь линкуются на директории хост системы.
- — управление версиями кода и php выполняется стандартными инструментами НЕ для контейнеров
- — запускается тот самый сервис, используя инструкцию "--volumes-from mapping_container"
- — актуальность маунтов «вспомогательного» контейнера, конечно мониторится
- Еще бывает такое, что сервис должен где-то хранить statefull данные – для этого мы применяем named volumes, что удобно и, скорее всего, очевидно.
— какой оркестратор используете и почему?
На данный момент самописный свой. Ответ на этот вопрос скрывается также в ссылках на последнее видео.
— сколько нод в docker-кластере, в скольки датацентрах и на скольки континентах они расположены?
Нод:
# mco find hosts -F docker_package=true | wc -l
687
Дата центры:
4 или 6(смотря как считать); 2 континента
— чем мониторите docker-контейнеры (cAdvisor, свои решения, что-то еще?)
Стабильный и основной инструмент:
Если кратко, то у нас на хостах запущен «мониторинговый» контейнер, который:
- — читает эвенты от демона docker
- — читает системные метрики
- — отправляет это в zabbix/graphite
Если чуть подробнее, то советую посмотреть на вот эти 2 выступления, где я касался данного вопроса: tech.badoo.com/ru/presentation/191/docker-v-badoo и tech.badoo.com/ru/presentation/137/docker-v-rabote-vzglyad-na
Параллельный, находящийся в разработке инструмент:
- — prometheus
- — grafana
- — telegraf
Telegraf запускается на хосте, собирает host & dockerd related информацию и открывает порт, на котором готов отдавать статистику для и в формате Prometheus. Prometheus берет информацию из Consul по маске наличия сервиса docker на хосте. Далее в grafana рисуем картинки + тестируем алертинг от Prometheus.
На данный момент это прототип, хоть лично мне он очень нравится :)
— перечислите, какие docker-контейнеры используете. Например, у меня в стеке разворачиваются:
Это не будет иметь никакого смысла, т.к. 90% названий вам, скорее всего, ничего не скажут. Мы не используем контейнеры с dockerhub(за редчайшим исключением) и собираем их самостоятельно, даже если это просто nginx || redis – это будет собранный нами контейнер на базе SLES.
Sannis
19.10.2017 17:30В дополнение к Антону отвечу почему PHP код мы не выкладываем контейнерами. Причины довольно простые: мы хотим выкладываться часто (сейчас это 2 раза в день на продакшен и, по статистике, каждые минут 10 на стейджинг), при этом PHP приложение представляет из себя монолит, один код которого занимает ~200Mb, завендорено ещё столько же (можно уменьшить елси почистить тесты и много чего ещё в них). При раскладке на продакшен всё это нужно доставить на сотни серверов, потому нам приходится постоянно изменять собственную систему деплоя. Более подробно об этом можно посмотреть в докладе Юры youROCK Насретдинова на Youtube.
ealebed
20.10.2017 08:49Спасибо за информацию и ссылку на доклад!
В моем случае код php и vendor (без тестов), упакованные в docker-контейнер занимают 358Mb, пока решили выкатывать этот контейнер отдельно (как data-only) не обновляя без надобности остальные.
Хотя docker-капитан Bret Fisher советовал мне добавлять код в контейнер с php-fpm (который сам весит ~600Mb) — мол, это «лучшие практики»…youROCK
20.10.2017 12:32В принципе, благодаря слоям, не требуется каждый раз скачивать и записывать эти самые 600 Мб. То есть можно сделать базовый образ из текущего состояния репозитория (условно ветки master) и потом при сборке нового контейнера делать git pull. Но со временем всё равно разница будет накапливаться и нужно будет базовый контейнер пересоздавать. Если при сборке нужно ещё что-то генерировать, то такой способ, конечно, уже будет работать плохо. Собственно, это является одной из причин, почему ИМХО для деплоя PHP тот же rsync в 2 директории подходит намного лучше.
banuchka
20.10.2017 12:34Доставку вообще никто не мешает делать не через docker distribution!
youROCK
20.10.2017 12:36Речь скорее не про доставку, а про то, что на машину всё равно будет записывать намного большее количество данных, чем по факту было изменений. Если для компилируемых языков диффы между бинарями делать никто не будет, то вот для того же PHP/Python/Ruby можно относительно легко сделать деплой только изменений.
banuchka
20.10.2017 12:44+1можно относительно легко сделать
это в теории, а на деле ты сам все прекрасно помнишь!
poxvuibr
19.10.2017 15:28+1Вопрос к Ярославу Голубу
В одной конторе было серверное приложение с толстыми клиентами для разных устройсв.
Клиенты умели работать с файликами в бинарном формате и обмениваться ими с сервером.
Как и во многих других стартапах, версионированием формата никто не занимался, работает и ладно, программисты просто по мере своих сил следили за обратной совместимостью.
Новый формат для новой фичи
И вот однажды в формате запилили фичу. Протестировали, всё было хорошо, пока один хитрый тестировщик не удумал посмотреть, как эта фича смотрится в устаревшей версии клиента, которая, тем не менее всё ещё поддерживается.
Оказалось, что если передать клиенту файлик с фичей, он падает.
А падать этому старому проверенному клиенту нельзя, потому что его использует ешё одна крупная контора.
Костыль и велосипед
Разработчики, забив большой болт на спецификацию формата и внешний вид кода, реализуют всё так, что старый клиент считает новый формат комментариями.
И вот этот набор костылей релизят.
Далее появляется возможность начать работать с ещё одной конторой, которой приложение нравится, но они тоже умеют работать с этим форматом, но у них он естественно сделан нормально, потому что вопросы совместимости со старыми клиентами нашего производства их не волнуют.
Нужно делать как все
Если наша контора будет нормально работать с форматом, можно расширить клиентуру, но забить на старые не обновлённые устройства нельзя.
Вернее можно, но только когда истечёт срок поддержки.
Есть идея отдавать сервером файл в правильном формате в зависимости от версии клиента, но на сервере конверсию форматов придётся реализовать с нуля.
Как вы обрабатываете такие ситуации?
YaGolub
19.10.2017 23:29Спасибо за вопрос!
Если я правильно понял — то суть проблемы в том, что у вас есть два несовместимых протокола, старый и новый, причем последний ломает старые клиенты? Если это так, то мы в Badoo с этим справляемся так: избегаем такого.
Либо изменения протокола должны быть такими, чтобы старые клиенты продолжали работать как ни в чем не бывало, либо старые клиенты о новом протоколе ничего знать не должны. Решается это в основном тем, что сервер новым клиентам отвечает по новому, более лучшему протоколу, а старым — по старому.
Но если у вас формат файлов общий еще с кем-то, а вы там, суровые парни, пишущие фичи комментариями в бинарных файликах, стесняетесь, то ладно вы, у нас в баду тоже в комментариях бывает чего-то только непонаписано, да такого, что детей в код не запустишь. Строго 21+.poxvuibr
20.10.2017 07:50Писать наново серверный код, который будет работать с форматом нам очень не хотелось, тем более, что его пришлось бы развивать одновременно с кодом клиента.
И вот, мы запилили в клиент поддержку двух форматов — код получился совсем жуткий, но это было лучше, чем ничего. В этой новой двухформатной версии клиента была одна фишка — он сохранял файлы в той версии формата, в которой он их считал. Так как в новом, хорошем формате у нас пока ничего не было — всё и работало по старому.
Прошло время, у поддержка старых клиентов кончилась, у нас остались только гибридные клиенты и мы поменяли настройку сохранения — теперь всё всегда сохранялось в новом формате. И, соответственно, файлы из старого формата на клиентах потихоньку конвертитись в новый.
Следующим шагом мы убрали поддержку старого формата (в котором фича сделана комментариями), и зарефакторили код. Теперь у нас остались старые клиенты, которые работали с новым форматом нормально и новые клиенты, которые не умели работать со старым форматом, которого в природе уже не осталось.
Такой вот хитрый план.
youROCK
19.10.2017 18:14+2Вопрос товарищу demi_urg:
Как вы относитесь к новым SQL-базам с автоматическим шардингом? Например CockroachDB или TiDB (https://github.com/pingcap/tidb)? Пробовали ли вы их использовать для чего-нибудь? Как вы решаете проблему в текущих условиях, когда нужно одновременно закоммитить что-то на двух и более серверах? Например когда нужно послать подарок пользователю (нужно атомарно уменьшить баланс пользователя и добавить подарок другому, который может жить на другом шарде).
Как вы шардируете мемкеш? Если про схему хранения данных в MySQL и про фотографии вы рассказывали на конференциях, то про шардирование кеша я такого не припомню, хотя это тоже интересно, как мне кажется.
Ну и последний вопрос — как вы относитесь к ClickHouse, прижился ли он у вас и как вы шардируете данные в нём, если прижился?
demi_urg
19.10.2017 18:58+1Юрий, спасибо за вопрос.
Мы хорошо относимся ко всему что может облегчить нам жизнь, но TiDB мы пока не пробовали. Возможно в будущем мы найдем задачи в которых сможем его попробовать, но заменять работающее решение на что-то другое только что бы посмотреть как оно работает мы не планируем.
Сейчас все проблемы синхронизации решаются через очереди. Атомарное изменение в двух шардах практически никогда не нужно. Если пользователь увидит подарок который ему подарили через секунду после того как его подарили ничего страшного не случится.
С мемкешом у нас все просто. У нас стоит N серверов ключи по которым раскидываются равномерно по определенному хешу. В случае выпадения одного из мемкешей мы просто теряем 1/N кеша и получаем небольшой прирост запросов на базы, что вообщем то не критично.
ClickHouse у нас используется для обсчета статистики. Подробнее про него я попрошу ответить ребят из BI.
alexkrash
23.10.2017 11:59+1В настоящий момент мы проводим эксперименты по применению ClickHouse к нашей системе потоковой агрегации событий. В общем и целом, нам удалось найти схему хранения, которая удовлетворяет нашим задачам. Осталось дело за одним нюансом — мы ждём кастомного партицирования. Нужно оно нам из соображений партицирования — мы не хотим хранить месяц данных (на самом деле — два, т.к. удалять можно только по месяцу), т.к. нам нужно максимум 1-2 дня.
Когда система войдёт в production использование, мы выпустим статью на эту тему.
sinty
19.10.2017 20:15+1Вопрос Александру Рыбаку:
Я от сервер сайд разработчиков все время слышу что в хайлоаде не бывает офсетов, нельзя посчитать общее количесво объектов у пользователя, запрашивать данные большими кусками и ещё куча других орграничений. Есть ли какой-то подход чтобы обойти все это и дать фронтэнду и мобильным разработчикам удобное апи? Вы сталкивались с такими проблемами? Как вы их решаете?banuchka
19.10.2017 20:21Алексей Рыбак
sinty
19.10.2017 20:47Перепутал. Извините.
poxvuibr
19.10.2017 20:53Вам интересно услышать ответ кого-нибудь, кроме Алексея Рыбакова? Всю тему я, конечно не подниму, но про оффсеты, подсчёт количества объектов, большие куски данных и некоторые решения с АПИ могу сказать.
sinty
19.10.2017 20:55Конечно интересно!
poxvuibr
19.10.2017 21:44+1Ну, сначала про подсчёт общего количества объектов.
Для реляционных СУБД это проблема, если речь идёт о подсчёте объектов в выборке по произвольным критериям. Для того, чтоб посчитать количество объектов в такой выборке — в лучшем случае придётся сделать полный скан индекса, а в худшем — полный скан таблицы, то есть просмотреть все строки таблицы на предмет того, попадают они в выборку, или нет.
Это очень медленно.
Как решить эту проблему для произвольной выборки я не знаю, тут надо заранее говорить аналитикам, что таких мест в приложении быть не должно.
Единственное, что можно сделать — это кешировать количество элементов в некоторых фиксированных выборках.
Оффсеты
Проблема с оффсетами это по сути та же самая проблема.
Для того, чтобы пропустить первые N строк, которые попадают в выборку — нужно смотреть каждую строку в таблице и, если она попадает в выборку, увеличивать счётчик на еденицу, пока мы не наберём N строк. Если мы хотим с помощью оффсета попасть на последнюю страницу выборки — это по затратам равносильно подсчёту всех её элементов.
Поэтому про навигацию по номеру страницы аналитикам нужно сказать то же самое, что про подсчёт количества элементов в выборке по произвольным критериям.
Чтобы дать пользователю возможность перемещаться между страницами выборки и не сжечь при этом сервера, нужно строить интерфейс по принципу — "перейти на следующую страницу", или "перепрыгнуть через 5 страниц" или "перейти на последнюю страницу". Это базу не нагружает, потому, что оффсет для этого можно не использовать, или использовать ограниченно.
Подробно, как обойтись без оффсета я тут не расскажу — времени и места не хватит, но, если коротко, то можно выбрать из БД первые 10 записей, отсортированных по какому-то полю, а потом первые 10 записей из той же выборки, но с дополнительным условием, что значение поля, по которому сортируем — больше, чем значение этого поля в последней строке предыдущей страницы. Если на это поле есть индекс — операция достаточно быстрая.
Большие выборки
Большие выборки лучше не делать, потому что это создаёт в БД длительную транзакцию на чтение, а это делает СУБД больно.
Воркараунд тут — вычитка выборки постранично и последовательно, так же как и в случае с постраничной навигацией на UI.
API
Тут всё точно так же, как в предыдущих пунктах — нельзя отдавать в апи страницы по номеру, если необходимо отдать через апи всю выборку, нужно отдавать сначала первую страницу, потом вторую и так до последней.
Вот как-то так выглядит краткая выжимка из того, что мне известно по теме.
sinty
19.10.2017 21:56Грустно. Пользователю-то хочется иметь произвольный доступ к любой части больших списков, знать сколько у него постов/фоток, посмотреть что он делал в заданную дату и т.п.
poxvuibr
19.10.2017 22:09Пользователю-то хочется иметь произвольный доступ к любой части больших списков, знать сколько у него постов/фоток
Сколько постов и фоток у определённого пользователя это как раз и есть одна из тех заранее заданных выборок, которые можно кешировать :), не всё так плохо
посмотреть что он делал в заданную дату и т.п.
Тут может помочь индекс с датой первым полем :) и, возможно, секционирование таблиц по датам.
ameli_anna_kate
19.10.2017 22:03На собеседование к вам в компанию на должность front-end разработчика может попасться такой вопрос.
Реализовать функцию, которая возвращает результаты
foo(1)(2)(3) -> 6
foo(1)(2)(3)(4) -> 10
foo(-1)(2)(3)(4)(7) -> 15
foo(1)(2)(3)...(n) вернет результатом сумму 1+2+3...+n
Как вы сами реализуете решение? Сколько времени это займет у вас?
Это не я на собес ходила, но что-то этот вопрос так и запал в память, а здесь такой шанс.alxgutnikov
19.10.2017 23:51Добрый вечер! Задачу можно решить как-то так:
function foo(value) { var acc = value; function addNext(next) { acc += next; return addNext; } addNext.valueOf = function() { return acc; } return addNext; }
Теперь вы должны прислать нам вопрос на замену этому.
RubaXa
20.10.2017 12:33[irony] но это нерабочее решение:
console.log(foo(1)(2)(3)) // functionalxgutnikov
20.10.2017 16:04Да, спасибо за замечание, все верно говорите.
Насколько я помню там речь шла не про вывод в консоль, а про выражения вида:
foo(1)(2)(3) == 6
foo(1)(2)(3) + 4 == 10
foo(1)(2)(3) > 5
и т д
alxgutnikov
20.10.2017 16:09console.log вроде же зависит от конкретной реализации console.spec.whatwg.org/#printer. В хроме например value выводится в том числе
RubaXa
20.10.2017 16:35Да это понятно, я уж просто так :] и вот вам задача на замену, хоть и бредовая
for (const num of 0..VI) { console.log(num); // 1, 2, 3, 4, 5, 6 }
ameli_anna_kate
21.10.2017 10:24Спасибо. Только меня не много смутило
Для alert
Хотя я не придумала ни чего лучше. Получилось только не много улучшить.
function foo(value) { var acc = value; function addNext(next) { acc += next; return addNext; } addNext.toString = addNext.valueOf = function() { return acc; } return addNext; }
Теперь alert возвращает число, но typeof все равно function.
Zmey14
19.10.2017 22:55Александр Гутников, alxgutnikov,
Как отслеживаете ошибки яваскрипта на prod?alxgutnikov
20.10.2017 16:50Мы используем подход, похожий на тот что используется в raven.js от sentry. Если по-простому, то любая возникающая ошибка в итоге попадает в try {} catch() {} на уровнях выше, после чего со своим стектрейсом и разной дополнительной информацией отправляется на сервер.
На сервере ошибки агрегируются по разным признакам: номеру билда, браузеру, сообщению и т д. Так же можно посмотреть когда и как часто эта ошибка вопроизводилась до этого
6ec_uk
19.10.2017 22:55Вопрос demi_urg:
- Как у вас происходит процесс обновления схемы баз данных?
- Как накатываете схемы на кластер баз данных?
- Как вы решаете проблемы выполнения долгих alter table и лока таблиц при них
- Если у вас сценарии деплоя для: добавления колонки в бд, удаления колонки в бд, изменения колонки в бд?
Спасибоdemi_urg
20.10.2017 14:53Спасибо за вопрос
Давайте я попытаюсь ответить сразу на все вопросы.
Любой ALTER делается в несколько этапов:
1 подготавливается код (если надо)
2 делается ALTER
3 удаляется код (если надо)
Каждый из этих пунктов может занимать время, главное чтобы они не пересекались.
Например добавление таблицы или колонки обычно не требует пункта 1, удаление — не требует пункта 3.
В основном все изменения делаются простым альтером в оффпик. Там, где альтер долгий делается через pt-online-schema-change6ec_uk
20.10.2017 22:09Расскажите про воркфлоу. Разработчики пишут миграции или же как-то по-другому готовят свои обновления схем, и высылают вам?
demi_urg
21.10.2017 14:30Разработчики ставят тикеты на альтер и следят когда они будут выполнены. Как я сказал есть в общем случае 3 этапа. Задача разработчика не допустить их пересечение.
GrigoryPerepechko
20.10.2017 05:00Фишеру.
В команде разрабочиков достаточно быстро сменился состав, и не осталось родоначальников, ввиду чего растёт тех. долг, падает velocity команды. Бизнес на это не реагирует, на команду растёт давление по задачам, текучка усиливается, летят инциденты, бизнес перфоманс еще сильнее падает, и тут замкнутый круг.
Как выруливать?fisher
20.10.2017 09:48Надо понять про "руководство не реагирует", обычно за этим стоят проблемы коммуникации, разговор на разных языках, забивания друг на друга, всякиое горделивое типа "если надо обьяснять, то не надо обьяснять" и прочее… надо обьяснять! Продакшн-качество, стабильность — бизнес-метрика, если вдруг что-то не получает должного внимания — приучать. В любом случае нужно по-партизански или открыто сделать команду, которая будет фиксить долг. Лучше открыто, по-партизански можно только очень ненадолго и в большой конторе (минимально зааффектит бизнес).
fisher
20.10.2017 09:50Ну а если никак — смириться и терпеть или найти место получше, это уж как кто привык.
altexxx
20.10.2017 12:34+1Вопросы Алексею Рыбаку.
Первый вопрос про ревью и мотивацию. Смотрел в записи ваш доклад о performance review с одного из митапов в Баду, было очень интересно. Насколько я понял, материальные поощрения после review довольно существенные, потому что это хороший инструмент мотивации. Как это сказывается на основной (обязательной) части зарплаты? Пример для наглядности — в одной компании ценят стабильность, и ежемесечная зарплата программиста 180 К (ниже этого он не получит), а ежеквартальные премии могут составлять например 20 К за очень хорошее review — условно говоря на пятёрку по пятибальной шкале, а если сотрудник хорошо работал, но после нормировки оказался ниже середины, то премию он не получит вообще. В другой компании с точно таким же зарплатным фондом обязательная часть зарплаты — это 120 К, но если он постарается, то в конце квартала у него будет премия 200 К (это плюс к обязательной части). Как следует из расчётов, у компании одинаковый зарплатный фонд (оба сотрудника получат по 560 К за три месяца работы, при высшей оценке на ревью). Соответственно в одной компании минус в том, что премия после review слабо мотивирует, а минус второй компании, что хороший, но невыдающийся сотрудник чаще всего будет получать 120 К, что будет его демотивировать так же, как высокая премия мотивирует лучших сотрудников. В каких пределах находится премиальный процент от обязательной части зарплаты, в каких границах находится основная базовая зарплата относительно рыночной зарплаты, и как решаются проблемы демотивации для тех, кто останется недоволен премией?
Второй вопрос частично связан с первым, но больше про HR-стратегию и привлечение новых сотрудников. В Бадушных официальных зарплатных вилках, которые можно встретить на сайтах по поиску работы (и даже на хабре), указываются верхние границы, существенно превышающие среднерыночтные. Но вместе с информацией из доклада про ревью складывается впечатление, что обязательная зарплатная часть существенно ниже нижней границы вилки, а верхняя граница вилки актуальна для очень маленького процента сотрудников и далеко не каждый месяц, и только при условии максимальной оценки на ревью. Часто встречал мнение (как HR-персонала, так и менежеров и разработчиков), что на самом деле для большинства сотрудников вилка по факту меньше, с учётом результатов ревью. Многие относятся с недоверием к официальной вилке. Так вот вопрос — насколько она верна для существующих сотрудников, насколько это честная цифра?
Третий вопрос про тимлидов. Не секрет, что в разных компаниях очень сильно различаются обязанности тимлидов, а так же различается количество уровней IT-шной иерархии управления. Иногда над тим-лидом уже CEO, а иногда ещё три уровня технических управленцев. Иногда тимлиды програмирут 90% времени и по сути больше похожи на ведущих разработчиков, а иногда совсем не программируют, а управляют командой из 15-20 человек. Например, существует мнение, что при команде в 6-8 человек на программирование времени не остаётся. В некоторых компаниях тимлиды отвечают за продуктовую часть, у них свои бизнесовые KPI, а в других ответственность ограничена исключительно качеством кода команды. В некоторых — у тимлида в подчинении кроссфункциональная команда, состоящая как из серверсайд разработчиков, так и клиентсайд разработчиков, тестеровщиков, админов, техписателей и так далее, в то время как в других компаниях у серверсайд тимлиодов в подчинении исключительно серверсайд разработчики. Расскажите, пожалуйста, какой процент времени тимлиды в Баду тратят на непосредтсвенное программирование, как этот процент времени зависит от размера команды, какие у них KPI и входят ли в них бизнесовые и продуктовые показатели, могут ли быть в одной команде и серверсайд и клиентсайд разработчики в подчинении у одномго тимлида, какого размера команды, и какой дальнейший путь развития тимлидов в Баду, кто ими руководит и за что он отвечает?fisher
20.10.2017 21:15Отвечать буду частями. (1) влияет ли и как бонусная часть. Да, влияет, обычно практика такая: база в рынке, а с бонусами получится выше ожидаемой — но есть масса ньюансов, конечно. Бонус — десятки процентов. Недовольство = минимальная премия = нет полного соответствия ожиданиям, тут очень важно, чтобы руководитель это подробно разьяснял, и ревью воспитывает и эту культуру тоже. При трудоустройстве можно всегда спросить, какой средний бонус был в этой группе — и вам скажут.
fisher
20.10.2017 23:20(2) Фактически вы спрашиваете: сколько получают сотрудники. По понятным причинам я не могу это разглашать, но вот утверждение о "существенно низкой базе" — неверное, выше обьяснял, почему, это вообще антипаттерн и я был бы вам крайне признателен, если вы скажете место в докладе, в котором у слушателя по-вашему создается такое впечатление, я обязательно его исправлю.
fisher
20.10.2017 23:28(3) в разных командах по-разному. Подчинение обычно такое: Тим-лид/менеджер — директор — глава разработки с вариациями. KPI — в зависимости от команды, но главный: сделать что обещал, в срок. Формулы доли программирования и размера нет, поскольку может быть разный профиль, разное число стейкхолдеров и соотвественное разное время на общение/синхронизации. Обычно в командах 3-4 человека еще 50% можно программить, но 7-8 уже почти нереально. Но если человек стремится совмещать — это можно делать и в больших командах, просто в ущерб другим активностям (я бы не рекомендовал, но на вкус и цвет).
altexxx
21.10.2017 02:52Спасибо большое за ответы, Алексей.
если вы скажете место в докладе, в котором у слушателя по-вашему создается такое впечатление
Это не из доклада, это — из общения с различными людьми. Но я понял, что это было ошибочное мнение. В докладе этот момент не был освещён.
Обычно в командах 3-4 человека еще 50% можно программить, но 7-8 уже почти нереально. Но если человек стремится совмещать — это можно делать и в больших командах, просто в ущерб другим активностям (я бы не рекомендовал, но на вкус и цвет).
Абсолютно согласен. По личному опыту я сделал точно такие же выводы.
badhop
20.10.2017 14:28+1У меня вопрос Илье. Развернутый ответ на него мог быть стать хорошей темой для доклада.
Знаю, что в Badoo используется Zabbix для мониторинга инфраструктуры, возможно ли его применение в современной методологии разработки и развёртывания приложений(микросервисная архитектура, Continuous Delivery , контейнеры)? Нет ли в планах компании интеграции Zabbix и Consul?
ableev
20.10.2017 17:26+1Привет!
Спасибо за вопрос и пищу для размышлений – возможно, станет темой для доклада на следующем митапе :)
Применение Zabbix возможно в современном стеке технологий.
Теперь подробнее и по порядку.
- Мы используем Заббикс не только для инфраструктуры: серверы, диски, сеть, память, проц; но и для приложений: работоспособность сервисов, внутренние метрики [время ответа, cpu usage per instance, свежесть данных в них, наличие бэкапов [для всех или выборочно] сервисов.
- Сервисы – различные, как опенсорсные, так и внутренние. Например, nginx, php-fpm MySQL, Tarantool. Внутренние, понятное дело, называть не буду, смысла нет.
- Под каждый сервис – обычно заводится мониторинг с нуля (очень-очень редко берём готовые шаблоны из паблика, да и то – сильно правим их). Во-первых, мы всегда можем и должны ответить на вопрос “что это и зачем”, во-вторых, есть правила, по которым мы всё добавляем более или менее однообразно.
- “Заббикс ничего не умеет” – у нас очень много кастомных скриптов, которые проверяют всё подряд. Заббикс умеет запускать эти скрипты с разными шаблонными параметрами.
- Чтобы каждый раз ручками не кликать в интерфейсе – используем API, в основном для заведения хостов, (благо, библиотек полно) и LLD (low level discovery), для заведения айтемов/триггеров.
Как мониторим
Обычно: идём на порт демона и опрашиваем его.
Редко: идём в файловую систему (например, демон пишет дампы каждый час, они важны, надо проверять работоспособность), в случае с контейнерами – тяжелее добраться до файлов (пути не очевидные, либо добраться нужно через docker), но это возможно (и мы так делаем).
Иногда: сходить в базу, населектить значения. Например, очередь вMySQL – SELECT COUNT(*). Или сходить по определённому урлу – nginx status page.
По поводу контейнеров: контейнер для нас (мониторинга) – просто сервис. Точнее, все наши сервисы (или почти все) живут в контейнерах, поэтому нам особой разницы нет, что мы мониторим: сервис, запущенный через systemd, или сервис, который живёт в контейнере. Нам важно то, как мы его мониторим – это обсуждается, как уже говорил, для каждого сервиса отдельно (или дорабатывается в процессе эксплуатации)
Как мы узнаём о том, что и где мониторить?
Написали свою дискаверилку всего-всего, которая умеет добавлять хосты, писать адекватные логи, линковать с нужными шаблонами, класть их в нужные группы и выдавать необходимые права (если используете Zabbix и его внутреннюю дискаверилку хостов – точно натыкались на её непрозрачную работу). Суть работы простая – проверяем «где должно быть», смотрим в заббиксе «где уже есть», недостающие создаём и цепляем к шаблонам, лишние удаляем.
Чаще всего дискаверим (для сервисов) из DNS и PuppetDB (если интересно об этом, тут Антон Турецкий banuchka может прокомментировать откуда Puppet знает про сервисы, да и он вроде уже рассказывал на Хайлоаде).
Отдельно про DNS – повелось давно, чтобы можно было переносить сервисы без изменения каких-либо конфигов: перекинул сервис/контейнер, перекинул dns запись, код пошёл к новому хосту. И мониторинг – обращаемся по DNS имени, не нужно менять ничего в нашей системе. По сути, на один инстанс сервера имеется одна DNS запись.
Далее – два варианта:
- цепляем целиком хост (dns алиас) к шаблону
- цепляем шаблон с low level discovery к имеющемуся хосту: lld приходит на хост, проверяет, какие сервисы должны быть на хосте и уже мониторит их пачками (таким образом, при переезде сервисов у нас один набор проверок удаляется на одном реальном хосте и появляется на другом, lld же)
Очень редко – бывает, что нужно мониторить работу контейнера, но это укладывается в первый вариант «понять, где нужно проверять работоспособность и прицепить нужный шаблон к нужному хосту».
Схема в первом случае выглядит так:
<шаблон> –> (дискавери работает) –> <хост для сервиса> –> , , …
Схема во втором случае:
<шаблон> –> (дискавери работает) –> <хост, где живут сервисы/контейнеры> –> (low level дискавери работает) –> , , , , …
Выводы
У нас есть своя дискаверилка – прицепить туда Consul не составляет большого труда (нет, сейчас не используем, он у нас в качестве эксперимента и/или используется только для инфраструктурных сервисов)
Контейнеры мониторить можно, разными способами. Но мы мониторим не контейнеры, а сервисы – это важно понимать (ок, если надо контейнеры – мониторим, как описал выше)
Точно знаю, что есть много людей, которые говорят, что «заббикс не предназначен для мониторинга контейнеров!!!11 в моём прометеусе это делается из коробки!!1» (или тулзами, которые умеют взаимодействовать с ним)
В целом – да.
Но если у вас уже есть одна система (как у нас) и она работает давно, и вам не хочется поддерживать несколько систем мониторинга – заббикс можно научить работать с тем, что вам нужно.
Не устану повторять, что Zabbix – это просто платформа, а не готовое решение. Ровно как и Prometheus – вам нужно будет настроить его, прежде чем катить в прод.
P.S. Как-то рассказывал, как мы скрестили заббикс и аппликейшен/бизнес метрики: www.youtube.com/watch?v=QhFpVc_iHKA так что, возможно всё :)
artemirk
23.10.2017 11:04+1Михаил Scalar, всегда очень больно обижать настоящих добрых клиентов.
Как вы поступаете в этом варианте если антиспам система блокирует добропорядочный аккаунт. Например взломанный, или возможно есть спамеры которые бодаются что их сообщение «выплаты без смс» вообще не спам и друзья хотят их видеть :)
Есть какая то выборочная ручная проверка заблокированных? Или вероятностные оценки системы никогда не ошибаются? Вопрос только в выборе правильной вероятности для блокировки.
Montefiori
Вопрос на билет:
Кто-нибудь из выступающих на конференции пользуется своим продуктом (badoo)?
Кому помог?
Задаю такой вопрос т.к. сам пробовал его лет 10 назад, когда проект начинался. На то время было удобно. Год назад решил снова посмотреть, после того, как увидел публикации здесь на хабре в блоге компании. Пользоваться стало крайне неудобно.
reversecode
Аналогично, тоже хотел бы задать кому то ГЛАВНОМУ на баду, о том — кто именно додумался убить одиного из конкурентов мамбе? видимо засланный козачек в баду есть ))
Хотя возможно одна из причин — почти полная монетизация сервиса, я не удивлюсь если через пару лет регистрация на баду тоже будет платная
fisher
выступающих немного — малая выборка — но несколько разработчиков нашли себе жен на badoo. что именно неудобно, напишите, интересно.
reversecode
нет ничего проще, достаточно зарегистрироваться на баду попытаться им пользоваться, а не использовать логин разработчика с фулл доступом ко всему
sayber
Я так же как и автор вопроса, пользовался приложением в самом начале.
И так же как автор, после поста на хабр, решил запустить badoo.
Что первое оттолкнуло, это множество монетизации, как уже заметили.
После захода спустя годы, мне зачем то показывается табличка для оценки сервиса «Нравится Badoo?»
Как он мне может нравиться, если я только зашел? Ну это так, что первое бросилось в глаза.
Убрав табличку, вижу какую то девушку. Мне она на данный момент не интересна, но занимает все рабочее поле.
Висят циферки, что я кому то нравлюсь.
Хочешь что то глянуть и на тебе, мозаика. Нет, я люблю мозаику, но тут она мне явно не интересна.
Тыкаешь на мозаику, думаешь — сейчас посмотрим кто там беспокоит. Ан нет, заплатите деньгу.
Ну собственно на этом я закрыл проект и больше не возвращался.
Раньше (лет 10 назад) было как то по другому и направление проекта было другое.
Насколько я помню, знакомство в Х радиусе. Сейчас даже не знаю, есть эта функция или нет, но искать не стал.
P.S.
Еще тыкнул пункт — двойники. Алгоритм конечно хромает жестко.
Я далеко не азиат (глаза большие=) ) и на том фото мне лет 20-25, а находит китайцев/малазийцев которым лет 50.