Хмельной Девопс

2019-04-26 14:50:16 Время завершения в днях Открыть/Комментировать

2019-04-26 14:50:15 Кол-во задач Открыть/Комментировать

2019-04-26 14:49:53 Как я работаю с задачами.

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

На самом деле интеграции только полбеды. Я квантую свое время как могу. Вот выдался часик ген дира - подпиши всякие юридически значимые штучки. А вот часик фин дира на подходе - распланируй бюджет, занеси все для учета, выплати зп, да и про себя не забудь. Или часик продажника - сходи на встречу, поболтай, расскажи как вы работаете и закрой на аудит. Часик CTO - поработай с подрядчиками и проверь что ивенты на просмотр видео успешно приходят и апдейтят сделку в битре (сюда же QA вписываем часик). Часик программирования от него тоже никуда не деться - api'шки сами себя не привяжут. А еще было не плохо вебинарчик зачитать с довольной мордой

К чему я это все? Да просто с этими интеграциями наткнулся на api wunderlist'а, который прекрасно отдает время создания и закрытия задачи. Заимпортил все в постгрю (часик программиста на питоне) и построил пару графиков.

На первом - количество задач. Вообще оно не так сильно плавает, не считая отпуска. Но есть реперные точки - особенно Airpush в октябре 2017 года. И конечно запуск Rebrain в начале 2019. Хотя тут я больше склонен считать, что мой уровень декомпозиции задач вышел на новый уровень. Особенно если сравнить эти же числа со вторым графиком - среднее время завершения задач в днях. Видно же, что стал быстрее вхерачивать.

Вообще я давно искал метод как мне работать с задачами. Всякие жиры, трелло и асаны идут лесом, поскольку до них очень тяжело дотянуться. А задач прилетает достаточно много - порядка 20 штук в день. Это могут быть как и мелкие вещи, типа залить сайти, добавить страничку оплаты, зарендерить вчерашний видос, так и более муторные - типа описать процесс проверки ДЗшек или проанализировать схера ли мы тут в кассовый разрыв попадаем.

И пришел я к простому выводу - в параллель я могу делать порядка 3-4 задач. При этом я точно не должен отвлекаться ни на что другое. Поэтому когда мне прилетает сообщение в ТГ / почту и так далее - я просто за 5 секунд не раздумывая над ним закидываю его в wunderlist. И продолжаю делать то что делал. При этом текущие задачи из головы я не выгружаю пока не дойду до промежуточной точки. Ну или не усну. Как только задача доведена до чекпоинта - сижу и разгребаю wunderlist - кому-то отвечаю, что-то смотрю, что-то заливаю. И так до следующей тяжелой и долгой задачи. Открыть/Комментировать

2019-04-15 12:10:57 Рассказывал я тут на вебинаре про Nginx tips & tricks. Про nginx check module, mirroring и lua.

Всю жизни думал, что mirroring модуль не аффектит продакшен запросы, но я ошибался. Действительно, есть некоторый набор параметров при котором nginx может дожидаться ответа от тестового окружения и при этом откладывать ответ боевому клиенту. Больше информации здесь от Nginx Lead Developer: https://forum.nginx.org/read.php?2,281042,281042#msg-281042.

За комментарий, который направил меня на путь истинный спасибо Alex (к сожалению, ни имени, ни телефона я не знаю). Алексу пришлось добираться до исходников этого модуля, когда они миррорили трафик на кафку. Alex, если вы меня читаете - напишите мне в личку, пожалуйста, очень хочу узнать подробности той истории. Открыть/Комментировать

2019-02-15 19:17:33 Пилил я тут недавно дашбоард по нашим тикетам. Сколько времени тратим, сколько тикетов каждого типа к нам приходит, какие severity у инцидентов. И была там одна метрика, которая нам очень важна, но подсчитать ее в лоб не так-то просто. Это - время ответа на заявку и время закрытия заявки.

С одной стороны ничего сложного - вычитаем из поля responded_timestamp значение поля created_at и получаем время ответа. Или среднее или персентили - все что душе угодно. Но блин, ведь заявка, созданная вечером, в нерабочее время будет обработана только с утра. Это как минимум часов 8. А нам надо как-то учитывать только рабочее время - исключать праздники, выходные и время с 19 до 10

Забыл упомянуть, что все данные хранились в эластике - просто грузили все тикеты и информацию о них в json'ке. А для визуализации у нас была кибана. Собственно выбор был очевиден - нужно использовать scripted fields и писать скрипт на языке painless. Быстрый гуглинг результатов не дал - никаких исходников или скриптов примерно решающих ту же задачу не нашлось.

Пришлось отдавать на аутсорс и писать собственное решение. Именно им я и хочу поделиться с вами, уважаемые коллеги. Если вдруг кто-то использует kiban'у как BI инструмент и хочет рассчитывать разницу между двумя датами с учетом рабочего времени - welcome! Скрипт вы можете найти здесь: https://gist.github.com/vozerov/c3578e727e511cd99fd7e9af3e348e14

Если у кого-то если желание его доработать или добавить функционала - пишите, опубликую ваши апдейты

P.S. В итоге все равно ушли на редаш с постгресом - не смогли добить некоторые метрики в эластике без join'ов. Открыть/Комментировать

2019-01-31 15:05:51 Вы наверняка забыли про мой опрос от 1 июня 2018 года, но Васян все помнит! Давайте немного освежу вам память:

Было бы прикольно записать какие-нибудь простые видосики на разные темы: Основы работы сетей, Как работает DNS, Как работает HTTP/SMTP/etc. Что скажете? Если вдруг вам идея понравилась, то заходите и предлагайте о чем рассказать - https://goo.gl/forms/w4J811agiSrNtvii2, я соберу все ответы и попробую успеть записать первое видео на следующей неделе.

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

Поэтому, мы с гордостью представляем первую онлайн конференцию по инфраструктуре и DevOps - http://bit.ly/fevlakeconf! Формат мероприятия абсолютно новый, отчасти можно сказать даже экспериментальный.

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

Что касается меня, то я планирую рассказать про troubleshooting инфраструктурных проблем на примере реального проекта. А послушать точно пойду Бориса Горячева про принятие хаоса в разработке на примере Медузы (у всех же хаос есть, да?).

До встречи! Увидимся на конференции! Открыть/Комментировать

2019-01-29 20:44:13 Открыть/Комментировать

2019-01-29 20:44:03 Все. Не могу больше. За последние три дня я получил 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.

Ну и в заключение, чтобы закрепить прочитанное, предлагаю посмотреть на график времени ответа. На нем очень хорошо видно, как соотносится среднее, медиана и прочие персентили с реальными данными. Открыть/Комментировать

2019-01-19 16:54:20 Как чистить место на диске?

Вроде и вопрос банальный и проблеме сто лет в обед, но в последнее время он возникает так часто, что я решил написать несколько строк по этому поводу. С технической стороной вопроса все вроде бы понятно. Мониторинг настроили, алерты приходят, rm -rf отрабатывает. Но как быть с организационной частью?

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

Когда в ответ на этот вопрос вам говорят что храните столько сколько влезет на диск, то это не ответ. Хотя выглядит похоже. По сути этим ответом, проблему с политикой хранения переложили на диск. А диск ни черта не знает про то, что это за данные, кто их использует и как их используют.

Простой пример. У вас есть статистика по продажам вашего продукта. И вот вы поставили задачу хранить столько, сколько влезет на диск. Отлично! В какой-то момент на этой же базе разрослась тестовая таблица. Действуя согласно плану по хранению статистики продаж вы взяли и дропнули все данные за последний год и оставили там последние пару дней. Под условие подходит? Да. Мы нарушили инструкцию? Нет. Все правильно сделали? Да. А бизнес только что продолбал все историю продаж благодаря условию "храним сколько влезет".

Если бы у вас была политика хранения и очистки статистики продаж, то вы бы не смогли взять и удалить эти данные. Вы бы пошли искать что еще занимает место на диске, попытались бы очистить что-то другое. И в конце пришли бы к бизнесу с вопросом - нам нужны деньги на диск. И смогли бы это обосновать за 10 секунд. Примерно так: "Согласно политике, эти данные надо хранить 5 лет. Диск у нас на 1Тб - он закончился. Так что либо докупаем диск, либо меняем политику хранения".

Поэтому ответ на вопрос "Сколько и какие данные хранить?" безумно важен. Вы должны четко понимать кто и как использует какие данные и в зависимости от этого выработать политику очистки, агрегации и архивации этих данных. Совместно с продуктом, конечно.

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

2019-01-17 20:17:57 Amazon две недели разбирался и ответил, что простит половину счета за трафик, который мы случайно нагенерили в конце года. Cloudflare простил весь счет за трафик в указанном периоде. УРА!

Не стесняйтесь просить помощи. Люди и компании вполне могут пойти вам навстречу. Открыть/Комментировать