Хмельной Девопс
4059
@drunkdevops
Будничный хаос и мрак при поддержке ИТ систем.
-
Хмельной Девопс
Время завершения в днях -
Хмельной Девопс
Кол-во задач -
Хмельной Девопс
Как я работаю с задачами.
В последнее время часто приходиться заниматься интеграциями. Тут надо zoom api привязать к бекенду на гошечке, чтобы генерировать уникальные ссылки на вход. А тут инфу по сделке в битрикс закидывать. А вот здесь еще оплату через я.кассу принимать. Ну и давайте еще рассрочку от тинкова и альфы подключим, чего уж там.
На самом деле интеграции только полбеды. Я квантую свое время как могу. Вот выдался часик ген дира - подпиши всякие юридически значимые штучки. А вот часик фин дира на подходе - распланируй бюджет, занеси все для учета, выплати зп, да и про себя не забудь. Или часик продажника - сходи на встречу, поболтай, расскажи как вы работаете и закрой на аудит. Часик CTO - поработай с подрядчиками и проверь что ивенты на просмотр видео успешно приходят и апдейтят сделку в битре (сюда же QA вписываем часик). Часик программирования от него тоже никуда не деться - api'шки сами себя не привяжут. А еще было не плохо вебинарчик зачитать с довольной мордой 🙂
К чему я это все? Да просто с этими интеграциями наткнулся на api wunderlist'а, который прекрасно отдает время создания и закрытия задачи. Заимпортил все в постгрю (часик программиста на питоне) и построил пару графиков.
На первом - количество задач. Вообще оно не так сильно плавает, не считая отпуска. Но есть реперные точки - особенно Airpush в октябре 2017 года. И конечно запуск Rebrain в начале 2019. Хотя тут я больше склонен считать, что мой уровень декомпозиции задач вышел на новый уровень. Особенно если сравнить эти же числа со вторым графиком - среднее время завершения задач в днях. Видно же, что стал быстрее вхерачивать.
Вообще я давно искал метод как мне работать с задачами. Всякие жиры, трелло и асаны идут лесом, поскольку до них очень тяжело дотянуться. А задач прилетает достаточно много - порядка 20 штук в день. Это могут быть как и мелкие вещи, типа залить сайти, добавить страничку оплаты, зарендерить вчерашний видос, так и более муторные - типа описать процесс проверки ДЗшек или проанализировать схера ли мы тут в кассовый разрыв попадаем.
И пришел я к простому выводу - в параллель я могу делать порядка 3-4 задач. При этом я точно не должен отвлекаться ни на что другое. Поэтому когда мне прилетает сообщение в ТГ / почту и так далее - я просто за 5 секунд не раздумывая над ним закидываю его в wunderlist. И продолжаю делать то что делал. При этом текущие задачи из головы я не выгружаю пока не дойду до промежуточной точки. Ну или не усну. Как только задача доведена до чекпоинта - сижу и разгребаю wunderlist - кому-то отвечаю, что-то смотрю, что-то заливаю. И так до следующей тяжелой и долгой задачи. -
Реклама
-
Хмельной Девопс
Пилил я тут недавно дашбоард по нашим тикетам. Сколько времени тратим, сколько тикетов каждого типа к нам приходит, какие severity у инцидентов. И была там одна метрика, которая нам очень важна, но подсчитать ее в лоб не так-то просто. Это - время ответа на заявку и время закрытия заявки.
С одной стороны ничего сложного - вычитаем из поля responded_timestamp значение поля created_at и получаем время ответа. Или среднее или персентили - все что душе угодно. Но блин, ведь заявка, созданная вечером, в нерабочее время будет обработана только с утра. Это как минимум часов 8. А нам надо как-то учитывать только рабочее время - исключать праздники, выходные и время с 19 до 10
Забыл упомянуть, что все данные хранились в эластике - просто грузили все тикеты и информацию о них в json'ке. А для визуализации у нас была кибана. Собственно выбор был очевиден - нужно использовать scripted fields и писать скрипт на языке painless. Быстрый гуглинг результатов не дал - никаких исходников или скриптов примерно решающих ту же задачу не нашлось.
Пришлось отдавать на аутсорс и писать собственное решение. Именно им я и хочу поделиться с вами, уважаемые коллеги. Если вдруг кто-то использует kiban'у как BI инструмент и хочет рассчитывать разницу между двумя датами с учетом рабочего времени - welcome! Скрипт вы можете найти здесь: https://gist.github.com/vozerov/c3578e727e511cd99fd7e9af3e348e14
Если у кого-то если желание его доработать или добавить функционала - пишите, опубликую ваши апдейты 🙂
P.S. В итоге все равно ушли на редаш с постгресом - не смогли добить некоторые метрики в эластике без join'ов. -
Хмельной Девопс
Вы наверняка забыли про мой опрос от 1 июня 2018 года, но Васян все помнит! Давайте немного освежу вам память: Было бы прикольно записать какие-нибудь простые видосики на разные темы: Основы работы сетей, Как работает DNS, Как работает HTTP/SMTP/etc. Что скажете? Если вдруг вам идея понравилась, то заходите и предлагайте о чем рассказать - https://goo.gl/forms/w4J811agiSrNtvii2, я соберу все ответы и попробую успеть записать первое видео на следующей неделе.
Со следующей неделей я конечно погорячился, но мы сели, подумали и решили реализовать более масштабное мероприятие. Идея родилась сама собой. Как вы наверняка знаете, в последние полгода мы активно влезли в обучение молодых ИТ-шников. И мы явно видим запрос на крутые профильные мероприятия. К сожалению, лично посетить офлайн митапы или конференции могут не все. Либо из-за невозможности приехать, либо из-за стоимости билета.
Поэтому, мы с гордостью представляем первую онлайн конференцию по инфраструктуре и DevOps - http://bit.ly/fevlakeconf! Формат мероприятия абсолютно новый, отчасти можно сказать даже экспериментальный.
Все выступления будут проходить в режиме реального времени. Вы сможете задать интересующие вас вопросы, на которые спикер ответит после выступления. Так же мы пригласим вас в закрытый чат, где вы сможете пообщаться и получить ответы на любые вопросы. Коммьюнити - это самое крутое что у нас есть, ведь так? 🙂
Что касается меня, то я планирую рассказать про troubleshooting инфраструктурных проблем на примере реального проекта. А послушать точно пойду Бориса Горячева про принятие хаоса в разработке на примере Медузы (у всех же хаос есть, да?).
До встречи! Увидимся на конференции! -
Хмельной Девопс
Все. Не могу больше. За последние три дня я получил 5 вопросов о том что такое percentile (он же персентиль или процентиль). А я всего-лишь имел неосторожность указать в ТЗ на разработку системы аналитики для нашего курса, что помимо среднего времени прохождения задания нам еще нужны персентили. Это же персентиль, Карл! Они же практически везде в IT вылезают.
Ну да ладно. Внесу свою лепту в улучшение жизни на земле и в двух словах расскажу про персентили. Надеюсь это кому-нибудь да пригодится.
Вместо предисловия рекомендую купить и прочитать отличную книгу про статистику: https://www.mann-ivanov-ferber.ru/books/golaya-statistika/. Книга написана простым языком и повествует о том как вообще смотреть на всякие статистические показатели.
Возвращаемся к персентилям. Давайте представим себе ситуацию, что на нашем небольшом, обитаемом острове живет 10 человек. И у первого зарплата 10 тысяч, у второго 11 тысяч, у третьего 12 и так далее. У последнего 19 тысяч.
Средняя зарплата 14 500 рублей (не верьте на слово - проверьте!). А теперь давайте одному аборигену зарплату поднимем до 300 тысяч. Среднее тут же возрастает до целых 42600. Но блин, ведь у большинства зарплата в несколько раз меньше среднего! Вот тут на сцену и выходят персентили - они позволяют легко и непринужденно отсекать различные пики и всплески.
50-ый персентиль (он же медиана) в нашей гипотетической ситуации до повышения зарплаты будет так же равен 14500. Он показывает, что 50% людей получают 14500 или меньше, а другие 50% - 14500 или больше. Если взять 70-ый персентиль, то он уже будет равен 16300, что означает что 70% людей получают 16300 или меньше. А остальные 30% 16300 или больше.
Все просто? Круто! Теперь давайте повысим зарплату нашему поселенцу до 300к. Как мы помним среднее у нас поднялось до 42600. А вот 50-ый и 70-ый персентили не изменились - потому что у нас 70% как получали 16300 так и получают. Изменения коснулись только оставшихся 30%.
Где это применяется? Да везде. Когда вам говорят среднее значение зарплаты и не говорят медианы - вас набманывают. Точнее говорят приятную часть и опускают ту, которую вам лучше не знать. Но без медианы абсолютно непонятно как получилось среднее - может 100 человек получают 100 рублей, а один известный нефтяной управленец миллиард, вот вам и нормальная средняя зарплата.
Если возвращаться к IT, то самое частое применение - это полоса трафика к вашим серверам. Очень часто счет вам выставляют на основании 95-ого персентиля по используемой полосе. Что следует читать как: 95% времени вы использовали 3 mbit/s (или сколько там у вас). А остальное время может и были какие-то пики, но мы их не учитываем.
Или еще хороший пример - время ответа веб сервера. Если 99-ый персентиль равен 200ms - это означает, что 99 процентов ваших клиентов получают ответ от сервера за 200 ms или быстрее. И если вдруг какой-то тип по 2G будет получать ответ в течении 10 минут - ваша статистика не сильно испортится и вам не придется гадать почему вдруг среднее время ответа выросло до 300 ms.
Ну и в заключение, чтобы закрепить прочитанное, предлагаю посмотреть на график времени ответа. На нем очень хорошо видно, как соотносится среднее, медиана и прочие персентили с реальными данными. -
Хмельной Девопс
Как чистить место на диске?
Вроде и вопрос банальный и проблеме сто лет в обед, но в последнее время он возникает так часто, что я решил написать несколько строк по этому поводу. С технической стороной вопроса все вроде бы понятно. Мониторинг настроили, алерты приходят, rm -rf отрабатывает. Но как быть с организационной частью?
Если мы говорим про данные (пользовательские, логи, статистика и тд), то непременно встает вопрос о том как долго их хранить. Без ответа на этот вопрос невозможно настроить автоматическую очистку старых данных, невозможно рассчитать объем хранилища, которое потребуется, да вообще ничего сделать нельзя.
Когда в ответ на этот вопрос вам говорят что храните столько сколько влезет на диск, то это не ответ. Хотя выглядит похоже. По сути этим ответом, проблему с политикой хранения переложили на диск. А диск ни черта не знает про то, что это за данные, кто их использует и как их используют.
Простой пример. У вас есть статистика по продажам вашего продукта. И вот вы поставили задачу хранить столько, сколько влезет на диск. Отлично! В какой-то момент на этой же базе разрослась тестовая таблица. Действуя согласно плану по хранению статистики продаж вы взяли и дропнули все данные за последний год и оставили там последние пару дней. Под условие подходит? Да. Мы нарушили инструкцию? Нет. Все правильно сделали? Да. А бизнес только что продолбал все историю продаж благодаря условию "храним сколько влезет".
Если бы у вас была политика хранения и очистки статистики продаж, то вы бы не смогли взять и удалить эти данные. Вы бы пошли искать что еще занимает место на диске, попытались бы очистить что-то другое. И в конце пришли бы к бизнесу с вопросом - нам нужны деньги на диск. И смогли бы это обосновать за 10 секунд. Примерно так: "Согласно политике, эти данные надо хранить 5 лет. Диск у нас на 1Тб - он закончился. Так что либо докупаем диск, либо меняем политику хранения".
Поэтому ответ на вопрос "Сколько и какие данные хранить?" безумно важен. Вы должны четко понимать кто и как использует какие данные и в зависимости от этого выработать политику очистки, агрегации и архивации этих данных. Совместно с продуктом, конечно.
Если вам отвечают хранить столько сколько влезет, то это означает ровно одно: Тот кто отвечает абсолютно не понимает кто и как использует эти данные. И вы со спокойной душой можете взять и дропнуть все нафиг, оставив данные за последний день. Чтобы такого не случилось - сходите и выясните политику очистки ваших данных. -
Хмельной Девопс
Напомнило.
Была у нас (да и сейчас есть) группа студентов, которых мы обучаем девопс практикам. И было у нас одно задание на terraform. Выдали мы значит ребятам токен от Амазона, чтобы потренировались виртуалки создавать, security настраивать ну и тому подобное.
Все шло как по маслу. Виртуалки создавались, знания получались, солнышко светило. Но тут пришла тучка. Точнее не тучка даже. В общем закоммитили конфиг терраформа в гит вместе с токеном от амазона. Естественно в открытом виде. Боты это дело быстро просекли и насоздавали по 20-30 самых мощных виртуалок в каждом регионе. Майнили, сцуки.
Первыми забивили тревогу нащи ребята, которые в тот момент (3 ночи примерно МСК) игрались с терраформом. Начали пинговать, звонить и гасить левые виртуалки. Я в этот момент видел свой любимый десятый сон. В общем с утра я проснулся. Охренел. Токен заблочил. Тачки снес. Посмотрел cost explorer - 36$. Ну и отлично, - подумал я. Чуть выше обычного.
Прошел день. И обновилась статистика использования. 4k$. В тот момент я немного (нет) напрягся. Расстроился. Испугался. Не помню, но было не круто.
Написал в саппорт с описанием произошедшего. Меня заставили сменить все токены, пароли, подрубить 2fa и сделать прочию любимые всеми безопасниками вещи. В конце передали мой запрос в billing team. Три напряженных дня и мне выдали промо код на 3970$.
Вывод будет тот же самый - не бойтесь писать и спрашивать. Главное не бегите и не блокируйте карты - попадете в какие-нибудь черные списки. -
Хмельной Девопс
Amazon две недели разбирался и ответил, что простит половину счета за трафик, который мы случайно нагенерили в конце года. Cloudflare простил весь счет за трафик в указанном периоде. УРА!
Не стесняйтесь просить помощи. Люди и компании вполне могут пойти вам навстречу. -
Хмельной Девопс
Обрабатываем 10 000 RPS входящих сообщений на инфраструктуре за 60$ / month. Это самый желтушный заголовок, который я когда либо писал.
На самом деле в последнее время получаю много вопросов по поводу того что выбрать - kafka или rabbitmq для организации очереди сообщений. Чтобы снизить поток входящих, набросал статейку с очень простым субъективным мнением о том что и когда стоит использовать. В конце вы найдете полезные ссылки для более глубокого погружения.
Ах, да, чуть не забыл - вот ссылка на статью - https://medium.com/@vozerov/kafka-vs-rabbitmq-38e221cf511b -
Хмельной Девопс
Очень крутую штуку ребята сделали конечно - https://github.com/spiral/roadrunner. Вдохнули в пхп проекты новую жизнь, так сказать. Больше деталей и описания здесь: https://habr.com/company/badoo/blog/434272/ -
Хмельной Девопс
Отвыступался на devops conf 2018 в этом году. Прикладываю запись выступления. Если есть идеи о чем еще интересно было бы послушать - пишите в личку, буду благодарен 🙂 С выбором тем у меня тяжко идет в последнее время.
https://www.youtube.com/watch?v=sZdEDHaNhY8 -
Хмельной Девопс
Отличный разбор инцидента от github'а: https://blog.github.com/2018-10-30-oct21-post-incident-analysis/. Люблю читать детективы 🙂
На самом деле при прочтении не отпускало ощущение, что ну блин, проблема же реально во всех этих автоматических переключателях. В итоге так примерно и оказалось:
"Adjust the configuration of Orchestrator to prevent the promotion of database primaries across regional boundaries. Orchestrator’s actions behaved as configured, despite our application tier being unable to support this topology change. Leader-election within a region is generally safe, but the sudden introduction of cross-country latency was a major contributing factor during this incident. This was emergent behavior of the system given that we hadn’t previously seen an internal network partition of this magnitude."
Но лучше всего описать мою мысль смогли комментарии под переводом статьи на хабре:
"Странно это все. Без всяких оркестраторов у них был бы даунтайм 43 секунды. Смысл в этих наворотах, если они не выполняют единственную свою задачу? Было ли тестирование такого сценария? Почему при небольшом рассогласовании данных нет другого механизма, кроме как восстановление из бэкапа?"
И вот в последнее время я все больше подхожу к мысли, что обычные интуитивные методы решения технических задач не всегда работают. Всегда хочется поставить задачу сделать отказоустойчивую систему. А вам точно это нужно? Может у вас день простоя стоит 100$ и вам нет смысла тратить 100k$ на решение и внедрение в этом случае? Или нужно ли вам резервирование active-active между ДЦ, если ваш текущий датацентр лежал 2 часа за прошлый год? Или нужна ли вам реплика базы физическая, если вы сможете восстановиться из бекапа за 10 минут?
Я конечно понимаю, что я сейчас накинул и мне прилетит, но все же я считаю, что нафиг не надо внедрять все подряд что в тренде. Надо всегда оценивать что вам принесет или не принесет то или иное решение. Старайтесь смотреть на ситуацию шире, подводить к какому-то общему знаменателю (да, это я про свой доклад revenue based monitoring :)). Ведь все эти айтишные штуки и задачи - это всего лишь инструменты бизнеса. И в итоге мы это все пилим чтобы нести какую-то ценность, а не просто ради "О! Прикольная / сложная / интересная задача." -
Хмельной Девопс
Отличное дополнение пришло от Ивана Боровкова по предыдущему посту:
"Привет. Про антиддос совет. Если не за L7 лоад балансером находится нгинкс, который отбивает соединения, то лучше возвращать 444, это специальный код ответа, который просто забывает о соединении и бережет ресурсы фронтенда. Нгинкс мощный, но и его можно положить, если не отбить соединение раньше."
Описание кода 444 можно посмотреть тут - https://httpstatuses.com/444. Действительно использовать лучше его.
P.S. К слову я почему-то всегда использовал в блоках 444, но я думал что это просто левый код 🙂 -
Хмельной Девопс
Что делать если вас начали досить или и того хуже - ддосить?
Ну вообще-то желательно обратиться к профи антиддоса, но если надо прямо здесь и сейчас - есть один небольшой лайфхак.
Обычно ддос идет из стран, которые вашему сервису не интересен. Например, если у вас интернет магазин работает в России, то навряд ли можно считать валидными пользователей из Вьетнама. Абсолютно понятно, что it depends, но если вы подходите под этот случай, то быстро отбить небольшую атаку можно и с помощью nginx. Делает это примерно так.
В начале определяется map:map $geoip_country_code $allowed_country {
default no;
RU yes;
UA yes;
}
Мапим мы переменную, которую предоставляет geoip модуль, поэтому он должен быть подключен к nginx. В данном примере если пользователь пришел из России или Украины, то $allowed_country будет содержать значение yes. В остальных случаях - no.
Ну а дальше дело техники добавить в нужный server или location простенький if:
if ($allowed_country = no) {
return 403;
} -
Реклама
-
Хмельной Девопс
Наверняка все сталкивались с проблемой блокировок отдельных личностей, которые постоянно лезут на вашу апишку и делают что-то гадкое. Кто-то просто забивает вам все ресурсы, кто-то регает аккаунты пачкой, а кто-то под уже существующем аккаунтом делает гадости.
Искали и смотрели как лучше избавиться от наглецов и в итоге остановились на lua + nginx. Почему? Во-первых - это просто удобно. Для lua даже специальная библиотечку уже имеется с примерами - https://github.com/openresty/lua-resty-limit-traffic. Во-вторых - никакой дополнительной логики не надо писать в приложении. А в-третьих решение простое как бревно - никаких связей приложения с nginx / fail2ban через логи. Просто видим и блочим.
Всем пятницы! -
Хмельной Девопс
Ух, интересный сегодня денек. Дебажили с какого перепугу на nvme ssd такая маленькая скорость записи рандомных блоков по 4k. Публикую что нарыли. Если у кого-то появятся какие-то идеи - пингуйте в личку, буду благодарен.
Итак, дано: SAMSUNG MZVLW512HMJP-00000, материнка https://www.supermicro.com/products/motherboard/Xeon/C236_C232/X11SSE-F.cfm, проц: Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz
Тестируем через:fio —filename=/dev/nvme0n1 —name=randwrite —ioengine=libaio —iodepth=1 —rw=randwrite —bs=512b —direct=0 —size=128M —numjobs=8 —runtime=240 —group_reporting —fsync=1
Да, fsync стоит специально, чтобы не использовать дисковый кеш. Этот бенч выдает ~ 3-6 mb/s и 2k iops. Та же команда на mac book air с обычной ssd выдает 65 mb/s, 11k iops.
А судя по https://ssd.userbenchmark.com/SpeedTest/181300/NVMe-SAMSUNG-MZVLW512 - эта ссд должна выдавать от 70 до 100 mb/s на рандомные 4k.
Перерыл кучу тредов по slow performance с этим ssd на *nix системах и выделил основные направления советов:
- Проверить что разделы выравнены по 512 байт. У всех все было выравнено и все было медленно.
- Проверить что диски действительно подключены к pci express. Проверял через lshw - все ок.
- Проверить что все PCI Express подключены на CPU, а не на PCT (хз что имеется ввиду, но судя по графу lshw - PCI Express подключен к CPU).
- Проверить что процессор не ниже sky lake. У нас следующее поколение - kybe lake, так что все должно быть ок.
- Проверить в BIOS что в биосе для слотов PCI-E стоит режим M.2, а не auto и скорость X4. Не нашел таких параметров на нашей материнке, так что пропускаю.
- Очень многие писали про драйвера - типа под винду установили драйвера от ocz и сразу стало все работать - не можем проверить, поскольку у нас linux и на них нет этих драйверов.
- Так же многие писали про то, что нельзя вставлять nvme ssd в слот ниже графической карточки - типа кто-то переткнул и у них все заработало. Звучит странно, но думаю тут дело кроется в настройках биоса каким-то образом.
- И еще очень много писали про смену материнки - про supermicro ничего не писали, но много было про gigabyte & msi, типа переехали на asus и все стало волшебно.
- У nvme есть параметр write voliate memory - который похоже вообще ни на что не влияет 🙂 Я его и врубал и отрубал и результаты были идентичными (кто хочет проверить - вот так можно его врубить: nvme set-feature -f 0x06 -v 0x01 /dev/nvme0, так - вырубить: nvme set-feature -f 0x06 -v 0x00 /dev/nvme0, а так посмотреть: nvme get-feature -f 0x06 -H /dev/nvme0n1 текущее значение.
В общем я пока склоняюсь к проблеме с драйверами - хотим на винде это же железо погонять, возможно станет понятнее. Есть идеи? -
Хмельной Девопс
Всем привет, друзья! Что-то давно ничего не писал сюда. То времени нет, то настроения. Да и честно признаюсь, давно в технические проблемы не влезал - все больше проектами занимаюсь. А там основное - это команда. Ну и метрики естественно.
В общем я принял волевое решение, что данный канал теперь будет содержать мой поток сознания по всему что со мной происходит. Канал авторский, так что я могу себе такое позволить. Технические темы так же останутся, но не думаю что их будет слишком много. Зато около технической лабуды станет явно больше 🙂
Из последнего хотел поделиться с вами прикольным зацикливанием на ansible, которое предложил один из наших студентов (да-да, мы сейчас проводим обучение):
handlers:
- name: reload nginx
service: name=nginx state=reloaded
notify: restart nginx
- name: restart nginx
service: name=nginx state=restarted
notify: reload nginx
Я вообще ставил на то, что не зациклится, но оно зациклилось. Зачем это нужно? Да фиг его знает, просто понравилось 🙂
И последнее на сегодня. Мои большие друзья, с которыми я работал достаточно долгое время ищут себе крутого инженера, который будет двигать devops практики и создавать инфраструктуру-как-продукт для внутреннего пользования. Чуть больше подробностей ниже.
Список страшных слов: java, php, linux, mysql, clickhouse, prometheus, docker, bash, dns, cdn, ansible, teamcity, CI/CD
Задачи:
- поддержка внутренних пользователей (программисты, манагеры, вот это все)
- разработка, построение и внедрение инфраструктуры как внутреннего продукта
- уверенное движение к chat-ops, no-ops
- Поддержка кучи баз данных (кол-во которых постепенно снижается), надо не бояться Кликхауса.
- Мониторинг всего и вся
- внедрение красивых CI/CD
- тотальная автоматизация, но без фанатизма
- on-call пока сутки через трое 🙂
Деньгами не обидим. Но сильно зависит от ваших талантов и умений
Работа full-remote, в Москве и Питере есть коворкинги, если не хочется сидеть дома 🙂
Откликаться можно сюда: https://airpush.com/job/devops/