« Rev
@ru_devops   36
Fwd »


nvkv
все эти ваши естимейты и таймспенты...
Эстимейты в часах самая беспомощная вещь на свете
CMDR Jack
Ну потому что они работают только в случае хорошо известных много раз проделанных действий.
CMDR Jack
И в малых масштабах
nvkv
Это заблуждение.
Совершенно верно, они вообще никогда не работают
nvkv
Человеки не умеют во время
nvkv
хорошо человеки умеют сравнивать разные штуки
nvkv
это обычная штука, а вон та штука примерно в три раза больше первой
nvkv
а вот третья штука, где-то 1/4 от первой
nvkv
Сколько времени тебе надо чтобы сделать третью штуку? Да хрен знает. В четыре раза меньше, чем для того чтобы сделать первую
nvkv
Поэтому эстимейты в часах это такой способ чем-то занять людей, они всё равно неправильные, всегда
nvkv
но все делают вид, что чем-то заняты
Александр
Вы сейчас пишите о теоритическом времени разработки - т.е. стоимости затраченного времени? Мы же общались на тему фактического времени затраченного на писание кода.
nvkv
Ну Дак померяйте время, которое таск в разных стейтах находился
nvkv
Называется cycle time
yopp
Совершенно верно, они вообще никогда не работают
И в космос летают по чистой случайности, и самолёты вовремя прилетают по божьей воле?
Pavel
Бизнесу понятны только метрики сроки/ресурсы, так что от этого не уйти.
Denis
https://sam.riolet.com/ странная херовинка
nvkv
И в космос летают по чистой случайности, и самолёты вовремя прилетают по божьей воле?
А я не говорил, что эстимейт времени нельзя сделать, я говорил что спрашивать у разработчика эстимейт бесполезно
nvkv
Чуваки, вот смотрите. Есть команда, пока небольшая. У команды нет офиса, нет никакой "ЛВС", команде хочется SSO, но гугл кажется дорогим.
Александр
и самим поднимать любым программным продуктом
nvkv
вот интересуют как раз программные продукты
Александр
ааа
nvkv
я вообще смотрю в сторону Atlassian Crowd
nvkv
но там есть проблема и большая, как только команда выйдет за пределы 50 юзеров, он станет неприлично дорогим
Александр
Хм, да он золотым получается
nvkv
угу
Александр
Тут вариант только искать opensource
Александр
Увы ничего подсказать не могу, ен пользовался
Dmitriy
а это разве не правильно ?
Денис, это не правильно потому-что без управления данными, без культуры вот этой - вы будете платить всё больше денег не понятно ради чего. У нас уже так, накопили дохера данных, о некоторых вообще не понятно, на кой они. Но лежат. Пока просто лежат - чорт бы с ними, а как надо железо новое покупать или переезжать в эти ваши облака - так эта неряшливость в данных - оно может дорого стоить
Dmitriy
Чуваки, вот смотрите. Есть команда, пока небольшая. У команды нет офиса, нет никакой "ЛВС", команде хочется SSO, но гугл кажется дорогим.
делать ссо самим, не имея подобного опыта - оно может быть более дорогим, чем взять гугл тот же
Denis
К тому же, я думаю почти все архивят всякие логи за длительный период
Denis
А культура, на мой взгляд, она не про то что бы не налить лишнего, она про то что бы потом убрать за собой )
Dmitriy
Не, смотри. Есть бизнес-риски, есть экономика предприятия. Например ты сторишь все данные на с3, чтобы считать проще было
Dmitriy
Каждый терабайт данных, которые ты не особо используешь - вычитает из твоей компании определенную сумму денег в месяц
Dmitriy
Пока у тебя много бабла или мало данных - можно жить как-то
Dmitriy
Когда данных становится больше - надо либо думать про оптимизацию (деривативы там считать и хранить только их, например), про риски (а что будет, если данных не будет, а какие данные точно нужны, а какие не нужны), про протухание данных (у всего есть срок годности, данные - не исключение)
Dmitriy
В целом - жить сильно лучше, если ты заранее думаешь про то, как ты эти данные использовать будешь
Dmitriy
А не как обычно
Dmitriy
У нас сейчас переезды, миграции - и мы в полной мере огребаем все минусы этого подхода (сохраним, а дальше разберемся)
Denis
именно поэтому желательно хранить максимально широкую копию 1го варианта всех данных, и уметь ее резат ьи считать по ней что угодно, не правда ли ?
Dmitriy
А тратим ресурсы, чтобы разбирать все эти сотни etl-обработок, кто что куда от чего почему и кто в конечном виде это использует
Denis
То что ты описываешь, это и так понятно. Но в реальной жизни проблема скорее в том, что данные задублированны много где.
Dmitriy
данные задублированы на хдфс
Dmitriy
зачем их где-то еще хранить
Dmitriy
вы, наверное, метрики по логам nginx считаете
Dmitriy
каждые сутки сгружаются логи nginx в обработку - обрабатываются - и всё, с фронтов эти логи можно удалять
Dmitriy
либо я не понял :)
Denis
да, но получается все равно ты оставил хранить сырые данные
Dmitriy
это если выбран подход "не выбирать подход"
Dmitriy
а так - ты посчитал деривативы - и сохранил только их
Dmitriy
а сырые данные у тебя вычистились
Denis
а чем хранение дериватива лучше ? ) значение меньше ? инт короче ?)
Dmitriy
и то, по хорошему у тебя не деривативы посчитались и остались
Dmitriy
а я пишу, да :)
Dmitriy
у тебя есть понятная цепочка получения ценности из данных, в данном случае - из этих вот деривативов
Denis
сырые данные никуда не вычистились
Denis
они остались на hdfs
Dmitriy
если цепочки получения ценности нет - то может и данные нафиг не нужны?
Denis
ценность данных это как акции ) то стоит то нет )
Denis
чаще всего, лично у меня, когда встает какая то новая проблема, хочется получить историю какой либо метрики.
Denis
Но вобще мы помоему говорим об одном и том же
Denis
только в разных степенях детализации
Dmitriy
возможно :) я говорю о том, что данными надо управлять, а не складывать просто так
Dmitriy
для каждого датасета должна быть понятна цепочка его использования
Denis
Нет, ты все равно говоришь что сырые даныне нужно сложить, а оперативные(по факту копии) держать только те, чья необходимость обусловленна какой то ценностью, потому что каждая новая копия это кост.
Denis
А я тока про первое говорю )
Denis
*данные
Dmitriy
ненене, я против складывания сырых данных, если они не нужны
Dmitriy
сырые данные обычно нужны до момента их обработки
Denis
Тоесть вы не храните логи на hdfs ?
Denis
старые, в течении длительного периода времени
Vladimir
O'Reilly выложили в свободный доступ ряд книг по DevOps (Monitoring Distributed Systems, DevOps in practice, Docker in the Cloud и др.) и по Performance (Effective Performance Engineering, Optimizing Cloud Migration, и др). Скачать можно по ссылке: http://www.oreilly.com/webops-perf/free/
Vladimir
да я уже качаю )
Vladimir
решил сначала форварднуть сообщение, а потом уже качнуть )
Denis
там книжки не книжки половина
« Rev
@ru_devops   36
Fwd »