Мы на Highload++ в этом ноябре: задай вопрос инженерам Badoo

— используете ли вы data-only контейнеры для доставки кода или упаковываете код сразу в контейнер (например, с php)?

• php
• наличие кода

• — на машине, на которой предположительно планируется запуск сервиса, который требует вышеописанное, создается «data-»/«mapping-» контейнер, который содержит в себе все необходимые маунты. Обычно это php, code, которые в свою очередь линкуются на директории хост системы.
• — управление версиями кода и php выполняется стандартными инструментами НЕ для контейнеров
• — запускается тот самый сервис, используя инструкцию "--volumes-from mapping_container"
• — актуальность маунтов «вспомогательного» контейнера, конечно мониторится
• Еще бывает такое, что сервис должен где-то хранить statefull данные – для этого мы применяем named volumes, что удобно и, скорее всего, очевидно.

— какой оркестратор используете и почему?

— сколько нод в docker-кластере, в скольки датацентрах и на скольки континентах они расположены?

— чем мониторите docker-контейнеры (cAdvisor, свои решения, что-то еще?)

• — читает эвенты от демона docker
• — читает системные метрики
• — отправляет это в zabbix/graphite

• — prometheus
• — grafana
• — telegraf

— перечислите, какие docker-контейнеры используете. Например, у меня в стеке разворачиваются:

В дополнение к Антону отвечу почему PHP код мы не выкладываем контейнерами. Причины довольно простые: мы хотим выкладываться часто (сейчас это 2 раза в день на продакшен и, по статистике, каждые минут 10 на стейджинг), при этом PHP приложение представляет из себя монолит, один код которого занимает ~200Mb, завендорено ещё столько же (можно уменьшить елси почистить тесты и много чего ещё в них). При раскладке на продакшен всё это нужно доставить на сотни серверов, потому нам приходится постоянно изменять собственную систему деплоя. Более подробно об этом можно посмотреть в докладе Юры youROCK Насретдинова на Youtube.

function foo(value) {
	var acc = value;
	function addNext(next) {
		acc += next;
		return addNext;
	}
	addNext.valueOf = function() {
		return acc;
	}
	return addNext;
}

Надо понять про "руководство не реагирует", обычно за этим стоят проблемы коммуникации, разговор на разных языках, забивания друг на друга, всякиое горделивое типа "если надо обьяснять, то не надо обьяснять" и прочее… надо обьяснять! Продакшн-качество, стабильность — бизнес-метрика, если вдруг что-то не получает должного внимания — приучать. В любом случае нужно по-партизански или открыто сделать команду, которая будет фиксить долг. Лучше открыто, по-партизански можно только очень ненадолго и в большой конторе (минимально зааффектит бизнес).

Отвечать буду частями. (1) влияет ли и как бонусная часть. Да, влияет, обычно практика такая: база в рынке, а с бонусами получится выше ожидаемой — но есть масса ньюансов, конечно. Бонус — десятки процентов. Недовольство = минимальная премия = нет полного соответствия ожиданиям, тут очень важно, чтобы руководитель это подробно разьяснял, и ревью воспитывает и эту культуру тоже. При трудоустройстве можно всегда спросить, какой средний бонус был в этой группе — и вам скажут.

(2) Фактически вы спрашиваете: сколько получают сотрудники. По понятным причинам я не могу это разглашать, но вот утверждение о "существенно низкой базе" — неверное, выше обьяснял, почему, это вообще антипаттерн и я был бы вам крайне признателен, если вы скажете место в докладе, в котором у слушателя по-вашему создается такое впечатление, я обязательно его исправлю.

(3) в разных командах по-разному. Подчинение обычно такое: Тим-лид/менеджер — директор — глава разработки с вариациями. KPI — в зависимости от команды, но главный: сделать что обещал, в срок. Формулы доли программирования и размера нет, поскольку может быть разный профиль, разное число стейкхолдеров и соотвественное разное время на общение/синхронизации. Обычно в командах 3-4 человека еще 50% можно программить, но 7-8 уже почти нереально. Но если человек стремится совмещать — это можно делать и в больших командах, просто в ущерб другим активностям (я бы не рекомендовал, но на вкус и цвет).

• Мы используем Заббикс не только для инфраструктуры: серверы, диски, сеть, память, проц; но и для приложений: работоспособность сервисов, внутренние метрики [время ответа, cpu usage per instance, свежесть данных в них, наличие бэкапов [для всех или выборочно] сервисов.
• Сервисы – различные, как опенсорсные, так и внутренние. Например, nginx, php-fpm MySQL, Tarantool. Внутренние, понятное дело, называть не буду, смысла нет.
• Под каждый сервис – обычно заводится мониторинг с нуля (очень-очень редко берём готовые шаблоны из паблика, да и то – сильно правим их). Во-первых, мы всегда можем и должны ответить на вопрос “что это и зачем”, во-вторых, есть правила, по которым мы всё добавляем более или менее однообразно.
• “Заббикс ничего не умеет” – у нас очень много кастомных скриптов, которые проверяют всё подряд. Заббикс умеет запускать эти скрипты с разными шаблонными параметрами.
• Чтобы каждый раз ручками не кликать в интерфейсе – используем API, в основном для заведения хостов, (благо, библиотек полно) и LLD (low level discovery), для заведения айтемов/триггеров.

1. цепляем целиком хост (dns алиас) к шаблону
2. цепляем шаблон с low level discovery к имеющемуся хосту: lld приходит на хост, проверяет, какие сервисы должны быть на хосте и уже мониторит их пачками (таким образом, при переезде сервисов у нас один набор проверок удаляется на одном реальном хосте и появляется на другом, lld же)