В апреле коллеги из CloudCastle приглашают на Стачку, секция девопс. С огромным удовольствием приеду! В Ульяновске был несколько раз, но обычно было холодно и совсем не было времени. В этот раз собираюсь на три дня, поэтому, надеюсь, успею погулять, познакомиться с городом.

Хочу продолжить тему, начатую на ДевОпсДейс, какие приемы помогали нам строить инфраструктуру и разработку в условиях роста компании. Накопилось много интересного, чем хочется поделиться, обменяться мнениями. Я поработаю над техникой доклада, добавлю побольше кейсов, историй, провокаций. Так, что если все пойдет как запланировано, то встретимся на Стачке!

В одной книге я читал про такую психологическую защиту, что когда боишься чего-нибудь - экзамена, выступления, то готовишься очень мало или вообще не готовишься. Когда облажаешься, а если не готовиться то как может быть иначе, организм себя оправдает, что дескать, так вышло, потому-что мало готовился. Эта защита подпитывается тем фактом, что если что-то делаешь в первый раз, то сколько бы не старался, то все равно будешь выглядеть не очень.

Противная штука и ее действие испытал в полном объеме при подготовке в этот раз. Вообще начал готовиться месяца за полтора, но довольно вяло. Каждый раз, когда садился за доклад, находилось тысяча дел, которые нужно было сделать очень, очень срочно.

Обмануть природу мне помогли организаторы. Где-то недели за две до события они прислали официальный шаблон презентации (клевый, с ним с первых шагов стало получаться красиво), также установили дедлайн на 7 марта. Но самое главное, что Константин Назаров предложил свою помощь в подготовке всем выступающим. Я записался на созвон за неделю до доклада, и таким искусственным дедлайном как минимум заставил себя подготовить слайды, написать текст выступления и подогнать его на 20 минут.

Потом каждый день я повторял доклад по 2-3 раза каждый день, записывал на видео. Но в любом случае, когда увидел полный зал на 400 человек, очень сильно захотелось сказать: "ой, я кажется заболел и не смог прийти". Но не сказал и выступил .

В субботу прошла конференция ДевОпсДейс. Вау, это было круто, три котика однозначно ! Очень понравилась организация мероприятия, начиная с того, что начали пушить с докладом за две недели, чтобы не было шанса не подготовится, и заканчивая четкостью проведения самого события - строго выдержан хронометраж, классные доклады, огромное количество интересных людей. Я волновался, первый раз выступал на технической конференции за несколько последних лет, но вроде бы материал в целом понравился, спасибо большое за внимание, вопросы и обратную связь!

Материалы с доклада:

• PaaS, выделенные сервера, облако и снова PaaS - слайды.
• Управляем «Виртуальным приватным облаком» с помощью Terraform - пост в блоге Селектела про терраформ.
• grafana-rb - гем для создания дешбордов графаны (сыренький пока, я просто завернул в гем наш внутренний скрипт grafana.rb, с удовольствием помогу адаптировать под ваши задачи, мои контакты внизу).
• ndiazg/nginx-prometheus-exporter - mtail, завернутый в контейнер. Вот такие регекспы хорошо работает с access.log nginx'а, если логи собираются в формате, описанном в README-файле. У нас этот контейнер слушает по несколько гигабайт логов в день на каждом сервере, в чем-то подозрительном замечен не был.
• Магический скрипт, который сравнивает разницу Селектела, DNSimple и терраформ-состояний выложу на этой неделе, хочу еще подумать, как его оформить.

Я сказал, что прометей подглючивает, и был вопрос как он это делает. Наверное это просто субъективное ощущение, которое осталось после перехода с заббикса. В заббиксе мы строили (опять с помощью магических руби-скриптов) дешборды, где на каждой строке был один сервер, а сервера прописывали ручками. Было очень топорно и в лоб.

В прометее сервера ищутся с помощью консул-дискавери и релейбелинга. Когда я строю график какой-нибудь типа такого sum(rate(http_requests_total{code="200",job="front"}[1m])), то нет четкой уверенности, что это именно будет сумма 200-х запросов по аппликейшен серверам. Может быть кто-нибудь неправильно настроил теги консул-сервисов и сюда попали лишние запросы или не попали нужные. То есть подглючивание скорее связано с тем, что я еще не до конца привык к более динамическому окружению.

Контакты:

• vakhov@gmail.com
• telegram - @avakhov

Cервер, в котором древние chruby-роли, качают chruby из интернета, лезущий за файлом checksums.sha512, недоступным вчера несколько часов, накатывал вчера я. Шах и мат, господа мои дорогие. Нету файла - нету и сервера .

Выглядело это так:

$ curl url

....
<h1>Error 503 first byte timeout</h1>
<p>first byte timeout</p>
<h3>Guru Mediation:</h3>
<p>Details: cache-ams4123-AMS 1489075171 688230291</p>
...

Лучшим решением оказалось написать тикет в гитхаб, и через несколько часов проблема ушла. В этой истории символично, что репозитарий, в котором лежит злосчастный файл, называется postmodern.

Когда я вел блог в прошлый раз, то моим KPI было количество подписчиков в твиттере. Сейчас это не работает, старый прием простого репоста каждой истории просто перестал работать. Значит надо брать новую линейку.

Тадам! Добавил подписку на новости сайта - это будет новая метрика. У меня есть идеи о расширении активности, поэтому в рассылке будет обязательно какой-нибудь эксклюзивчик.

Если вам нравится блог и вы хотите его поддержать, заполните пожалуйста форму наверху сайта.

Спасибо, вы супер!

Сам факт бэкапов (особенно, восстанавливаемость которых каких-то образом проверятся), в некоторых дискуссиях преподносится, как высшая степень профессионализма. Конечно бэкапы это хорошо, но классических pg_dump-, WAL-логов или каких-то подобных бинарей, даже разложенных в географически удаленные точки, в идеальном мире недостаточно.

Классно было бы время от времени подниматься с бэкапа, полностью зарубая старый сторадж. Тогда архив, с которого мы поднялись, был бы эталонным для точки поднятия. Если продакшен работает дальше, значит мы владеем реальным дампом продакшена на тот момент. В гуглах всяких насколько понимаю как-то так и делают, постоянно поднимая какие-то данные из бэкапов, но вот какого-то рабочего подхода для маленьких и гордых пока не встречал.

В этом плане я в восторге от гита. В сущности IT-ценность стартапа - это код и базы. Код в гите со всей историей раскладывается в так много точек, что его сложно потерять целиком, а вот с базами так пока не получается. Поэтому битва с бэкапами продолжается и выиграть ее нельзя, задача - все время играть в ничью.

Когда в ансибл настраиваешь бокс и запускаешь ansible-playbook the-server.yml раз за разам, то обычно хочется запускать только какой-то кусочек файла, я знаю два способа: колхозный и красивый.

Колхозный - просто комментим то, что не нужно запускать, главное не забыть раскоментить перед пушем обратно. В виме у меня компанда gc почему-то комментирует или раскомментирует более менее правильно любой фрагмент кода на любом языке. Видимо это плагин какой-то, так как пальцы помнят, а разум нет.

Красивый - на нужные констукции повесить тег, например так:

- {role: manage_user, user: root, keys: "{admin_users}", tags: [keys] }

и вызывать ansible-playbook the-server.yml --tags keys.

Во время разработки я обычно использую колхозный способ (все мои дедушки, бабушки и пра- из крестьян), а вот, например, в новых репозитариях команда ansible-playbook *.yml --tags keys как раз обновляет все ключи на всех серверах, если нужно дать доступ коллеге или наоборот забрать. В принципе возможна ситуация, когда в одной подсети может быть разный доступ к разным серверам и данное решение DRY.

Прелесть хайлоада заключается в том, что у сервиса много запросов и они вам пытаются устроить DoS, то есть отказ от обслуживания, забивая канал, базы, провоцируя редкие случая и так далее, а мы, чаще мужчины, нередко бородатые, соответственно с этой ситуацией боремся на регулярной основе. Это реально круто, но жизнь может вызвать DoS гораздо большим количеством способов и без большой нагрузки.

Первый DoS у меня был когда я выдал емейл и все остальные доступы примерно тридцатому сотруднику. Это не фига не весело сбрасывать пароль человеку, которому сбрасывал уже утром, и который очень хороший человек, но немного такой, не собранный.

Тимлидерский DoS возник, когда на доске закончился сотый магнит для примагничивания листиков с задачами и пришлось прикреплять по несколько к одному (а сама доска был ответ на DoS ситуации, когда было понятно, что каждый сотрудник усердно работает весь день, но вот только над чем?)

В прошлой жизни, да и в этой жизни, я знаю людей, которые, дернув кофейку после 6 часов совещаний, радостно приступают к разобру накопившейся почты. Поэтому DoS совещаний я, пожалуй, избежал, жестко стараясь слинять абсолютно с каждого совещания на которое позвали, чисто на рефлексах. Также избежал DoS почты, дисциплинированно отписываясь от каждого треда в который попал, дожидаясь меншена, который затянет обратно.

Мне кажется сегодня железо давно не самое слабое место IT-продукта, если нода держит 4000 открытых веб сокетов с одного сервера, то человек, а тем более отношения между людьми, держат на порядки меньше и ломаются гораздо быстрее. Современная разработка - это изучение и поддержка как раз вот этого малого трафика и малых нагрузок. А железо, хм, просто купите побольше.

Несколько лет назад я постулировал для себя, что хайлоад - это 1000 запросов в секунду. 500 - полхайлоада, 800 - три четверти хайлоада, арифметика простая. Я даже написал шуточный пост для друзей, не хотел его публиковать, но все сказали, что нормально, вот он по ссылке, можете прочитать.

Но самое забавное, что как только проект достигает некоторых высот, инженеры делают все, чтобы нагрузкой не работать. Разработчикам создается безопасная среда, в которой можно спокойно пилить бизнес-логику. Опсы тоже придумывают свой набор правил в стиле "работает не трогает". В принципе мне кажется большинство архитектур нагруженных систем строится по принципу - взять ту архитектуру, в которой сервис принял трафик и по возможности не трогать (естественно я говорю про стартапы, которые пилят-пилят на коленке и во, поперло. Если создается система под заказ, в которой одно из требований - нагрузка, ну например, не знаю продажа билетов по всей стране, то там конечно берутся какие-то проверенные архитектурные решения или, что чаще, адаптируется готовая система).

На прошлой работе я даже видел настоящий памятник хайлоаду, сервис в который не комитили 7 лет, а он принимал на себя практически весь биржевой трафик, который обрабатывался в компании. Насколько я помню это был какой-то траслятор из одного формата в другой. Он был настолько нагруженный, что тот кто мог туда что-то закомитить, не хотел, а кто хотел, того не пускали.

Хайлоад, это перефразируя советский анекдот про дефецит, объективно большие нагрузки, данные в ощущениях, но не нам. А завтра я хочу написать про лоулоад, который был объективен, дан в ощущениях и лично мне.

Я сейчас активно готовлюсь к ДевОпсДейс с помощью прекрасной книги по презентациям от Глеба Шулишова Скелет презентации. Она небольшая и мне кажется ее стоит почитать, даже если вам не нужно в ближайшее время делать никаких презентаций вообще.

Глеб делит презентации на два типа:

Я конечно буду стараться сделать офигенную презентацию, но так как Новый Год в моей жизни пока бывает чаще публичных выступлений, то как минумум ставлю задачу заглянуть в бизнес-класс, за вот эту занавесочку и стибрить там вилку и плед.

Обычно встречаются два способа подписывать API-запросы, прямо в урл ?token=abc, либо в специальных заголовках к запросу. Я разницы между ними раньше не видел, но сейчас считаю, что с заголовком лучше, так как иначе токен будет лежать в логах веб-сервера и сервера приложения, что в общем случае не хорошо.