Информация

Дата основания
Местоположение
Россия
Сайт
rebrainme.com
Численность
11–30 человек
Дата регистрации

Блог на Хабре

Обновить
Комментарии 68

"Собственно, на этом мы и расстались" — удивительное терпение.
По ходу истории звоночки переходящие в колокольный звон.
Неужели так нужны деньги, что приходится работать с чудаками?
Но, как любой опыт конечно полезен, как говорит один мой знакомый — вот так мальчики, становятся мужчинами.
Удачи в дальнейшем!

НЛО прилетело и опубликовало эту надпись здесь

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

Ещё надо добавить 13 число, понедельник. следующий день после любого праздника и три дня после Новогодних каникул.

Это ведь первая заповедь для… да для много кого… для инженера, админа, разраба.

Только если выходные не тех. окно, и как раз релиз надо успеть поставить, протестировать, и, если не пошло, откатить за выходные.

Замечательная история и замечательный опыт.
По вечерам и в пятницу никаких апдейтов!!! Опыт 100500%
Пятёрочка за то что не бросили клиентов, даже таких "ищущих свой путь"...

Ой не напоминайте… Последний рабочий день одной из коммандировок на Байк. За неделю обновлено всё ПО, поставлены и оттестированы комплексы и тут секретчики, со своим випнетом его ставят и всё дружно падает в BSOD… Ну что-ж, финальная пьянка оказалась успешно прос… й. ;-)
ВипНет — как вспомню, так вздрогну. Редкое гэ. Работает через задницу.
Отзывы работают через пень колоду: я их перетягиваю мышкой в сторону, но стоит мне карусель отпустить, чтобы кликнуть на «читать полностью» интересующей новости, как она быстренько убегает от меня за пределы экрана.

«Наши клиенты» работает ещё хуже, там логика поведения вообще не ясна. Их то можно скролить, то нельзя, то они сами скролятся справа налево, то потом слева направо.
Спасибо большое за фидбек, поправляем
Извиняюсь за (несколько) некрокоммент, только набрел эту весьма интересную статью, спасибо, любопытно было почитать.
На сайте есть еще несколько моментов, которые попались на глаза (не технические) и возможно покажутся вам нудными или неважными, но тем не менее по крайней мере я обратил на них внимание, возможно и вы увидете в этом недочеты после их обозначения. Ничего критичного, но:
— Почти на всех страницах висит бейдж с надписью «SLA 5 min». Не думаю что это прямой обман, но вы же понимаете что в SLA включается множество параметров и кроме того, если вы (как и почти все) имели ввиду availability time, то оно дается в доле от времени (обычно процентной)?" 5 минут" просто не имеют никакого смысла.
— В блоке «Вопросы, которые можем решить» не согласованные по форме высказывания. Можно поменять хотя бы вот так: «Требуется повысить» -> «Повышение»
— В «Услугах» тоже несогласованные высказывания. «Мониторинг» и «Внедрение», но «Описываем» и «Консультируем».
— В стеках часть технологий с маленькой буквы — «helm», «jenkins» и т.д. А часть с большой — «Prometheus».
Удачи и еще раз спасибо за статью:)
Авральные ситуация часто дают много опыта. У всех были авральные случаи.

У меня есть похожая история. Я тогда работал в связи, моя задача была чтобы вся оптика в компании работала корректно. Однажды руководству захотелось модернизировать узел агрегации. Узел расположен в чердачном помещении, а на улице Февраль месяц и -20 мороза. Я их долго убеждал дождаться оттепели, т.к. в такой мороз работать с оптикой нельзя и они согласились. Но тут нежданчик. Вот такой вот «Леня», один из моих коллег, сказал, да «Говно вопрос, я все сделаю и в такую погоду».

Итог у него сломалось 95% волокон под корень кабеля, хорошо он сразу сообщил начальству, а они сообщили мне. Запаса в кабеле оставалось около 2-3м, больше возможностей ошибаться нет, центр города без интернета, а завтра понедельник рабочий день.

Итог был утро 8 утра, 10 монтажников утепляют щели в сифонящей шиферной крыше, и расставляют тепловые пушки, что бы поднять температуру хотя-бы до 0… +2, иначе тот кабель который там использовался было не переварить, волокна не выдерживали мороза при зачистке :)

Ой-ё, если правда — это очень больно


Но какой должен быть провайдер, чтобы не научить монтажников основным требованиям...


Да, прокладывать можно и в -30, пользоваться и в -50, но про сварку везде указывается от 0, а чаще от +5… не зря же палатки продают...


А от пыли, которую теплопушки подняли, как защищались?

1. Мы немного изолировали часть чердака пленкой, просто прибив ее к деревянным балкам
2. Я не помню особо много пыли, хотя вот сейчас логически бумам, что должно было ее быть много… видимо я был сосредоточен на оптике и не обращал внимание ни на что вокруг… надо было оперативно восстановить связь.

В итоге проблема была с кривым кодом или бага clock house?

Интересно, конечно, но хотелось бы "услышать" обе стороны.

Не угадали


Мне всего лишь в белизну плаща автора слабо верится:


  1. не мог всем там заправлять один "разраб Лёня", всегда можно идти к тому, с кем заключен договор;
  2. почему не разобрали схему хранения с самого начала — не ясно;
  3. почему не обговорили и не подписали условия в договоре — кто знает...

PS: кидаться обвинениями в программистов — древняя народная забава админов
PPS: сам админ, знаю о чём говорю

Договор часто заключается с топами, которые сильны (хорошо если) в бизнесе, но не ахти в айти и для них что Лёна, что Вася — существа, которые должны решить проблему, «ведь мы им платим ТАКИЕ деньги», что автоматически подразумевает делегирование на них любых около-IT вопросов без желания самим в них углубляться. Ну и при даунтайме договор эти же топы могут очень доходчиво объяснить, куда надо засунуть. Чем полезен вот такой опыт — появляется чуйка и понимание «звоночков», в какие проекты не стоит лезть за любые деньги.

Ну и аутсорсеры часто заявляют, что всё будет работать как часы, и само собой никаких проблем. И всё автоматизировано, в облаках.


А договор — он и на переговорах договор и в суде он тоже договор, на него смотреть будут в первую очередь.


Молодец автор, что сейчас сначала смотрит в лужу и тыкает палочкой, прежде чем наступить.


У клиента тоже есть шанс познакомиться с работой аутсорсера и показать свои поделки, ведь админа штатного может и не было никогда, всё в облаках, зачем нам.

«Зачем нам админ, у нас облака».
Потом это бывает очень долго и больно разгребать.

Почему, почему, почему… Да потому что опыта в таких вещах нет, статья же как раз про то, как прошлись по граблям из-за этого. Уметь хорошо админить/кодить — одно, уметь правильно оценивать риски и выстраивать отношения с заказчиком — СОВСЕМ другое.

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


Как и умение обсудить условия и взять на себя обязательства, а на что-то сказать чёткое «Нет», но это, кмк, топ уровень инженера.


PS: конечно я понимаю, что статья про первые потуги без опыта ведения бизнеса, как со стороны автора, так и со стороны его заказчика.

почему не разобрали схему хранения с самого начала — не ясно;

Потому что инвестировать время и деньги в изучение инфраструктуры потенциального клиента не рентабельно. Хорошая конверсия может быть 10% — это значит, что на каждые 10 проектов, которые вы изучите, вы заключите один договор. Ваши сотрудники очень быстро вам расскажут, что они думают о перспективе потратить еще пару недель на изучение проекта каких-то дядек, с которыми они работать все равно не будут.

почему не обговорили и не подписали условия в договоре — кто знает...

Потому что прописать всеобъемлющий SLA на такую штуку как БД не реально. БД лежит потому что ваш косяк или потому что «Леня» написал хитрую хранимку? В два часа ночи разбудят и вас и Леню. Вы, конечно, разберетесь и гордо скажете «мы не виноваты, этого нет в SLA», но уже после того как разберетесь, а это 90% работы.

Начинать с малого: выяснить потребности, ознакомиться с текущей схемой взаимодействия и обговорить риски — потом предложить аудит и обслуживание, как автор делает сейчас.


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

1. Как показывает практика, таких Лёнь — больше половины. Договор заключается с владельцем бюджета, у него есть деньги, но он не специалист и полагается на Лёню.
2. Очень даже понятно. Провести грамотный аудит — это получить ответы на все вопросы, почему тут такое говно. Это совсем чуть-чуть меньше, чем переделать всё и поэтому стоит соотвественно. А владельцы бюджета очень редко соглашаются платить за то, чтобы им показали какое тут говно.
3. См. П. 2. Потому что если все-все-все прописывать, то надо делать аудит, в какое конкретно говно исполнитель не наступает.

1) Раз уж с куратором проекта не удалось прийти к согласию — то пойти к заказчику и сказать, что «Лёня принимает смелые решения», которые ты сам лично не готов поддерживать. Предложить решение, какое считаешь верным/приемлемым, показав сравнение плюсов и минусов, объяснить не в кудахтерах, а в деньгах, в деньгах все понимают.


2,3) Как уже отвечал комментатору выше — можно начинать с малого, с общей оценки и разделения зон ответственности, а после предложить полный аудит.

Всё ради последней подводочки: «у нас свой бизнес, приходите». Не упрекаю, но случай довольно рядовой, мало ли ещё будет просранных дней рождения и внеурочки, пока работаешь на мелкие компании единственным специалистом.

Это блог компании, так что могут рекламироваться


+1 к рядовому случаю


- Как у аутсорсера называется день,
  когда у клиента всё сломалось
  и нужно срочно всё починить?

- Вторник

За такую историю не жалко посмотреть рекламу бизнеса ребят

К слову, да, проблема сбоя не раскрыта, где треть данных терялась?
Почему после пересоздания таблицы данные стали сохраняться?
Что было в логе/статусе?
С чем пришли на разбор и постмортем?


Штатные разрабы сочинили свой кастомный «вставлятор» данных. Он работал так: батчил файлики, запускал скрипт и сливал данные в табличку.

ClickHouse — база колоночная, чем больше батч и реже вставки, тем быстрее отрабатывает в соотношении строк в секунду.


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

Для частых однотипных запросов есть буфер, лимиты памяти на пользователя и тд, кроме того для графаны рекомендуется использовать отдельного пользователя с ограничением qps.
ClickHouse — база аналитическая, для посекундного обновления нужен другой инструмент, например Tarantool.


Могли на берегу узнать, чего хотят клиенты, и если нужно — посоветовать другой инструмент, но, как говорит мой коллега: "Знал бы где соломку подстелить — жил бы в Сочи".

Кэпский вывод. Так можно про любую базу сказать.
Я бы еще добавил вопрос: а при чем тут бекап, оказавшийся репликой, если данные вообще не писались? Как бы тут спас бекап?
Все же отличается от иностранного подхода. Я так понял вы работаете на аутсорсе. Что мешало вам договориться о такой почасовой ставке для работы в выходные/ночью которая бы позволила вам получать удовольствие от этой работы. И условно «радоваться» если у клиента возникает такая потребность
ozar.me/2016/12/how-i-handle-weekend-and-holiday-work

Кстати, реальный случай из жизни, про иностранный подход.
Пятница, вечер — инцидент с высшим приоритетом, все стоит.
Все специалисты по всем направлениям подключились.
Разгребали все выходные.
Причина — разрабы поменяли запрос от приложения и получили Декартово произведение.
Ещё раз — пятница, вечер.
Компания мирового уровня.
Когда, я встречаю тоску типа "а вот в Европе порядок", я всегда улыбаюсь, люди они везде одинаковы.
Кстати, опять таки про аутсорт и оплату в выходные. Платят не по КЗОТ и это политика компании, не нравится — увольняйся, что я и сделал.

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

Ничего не понял, но было интересно.

Кроилово ведёт к попадалову.
Фраза стара как мир.
Вся страшная серьезность факапа стала очевидна после фразы

«Когда ты просрал данные, делается так — ты берешь средние данные за предыдущие дни и вставляешь их в просранные.»


От смеха у меня зашевилились волосы. Что ж это за бизнес такой, где можно так нахерачить данных?

Как многократная «жертва» аутсорсеров, я не люблю аутсорс. Как админу мне приходилось и приходится сопровождать много разных систем от аутсорсеров. Давно брошенных, с потерянными исходниками, исчезнувшими с горизонта людьми… Качество продукта чаще всего так себе. А кубернетес там будет или вижуал бейсик 1.0 с толстым клиентом, это вообще без разницы.
Ага. А если поглядеть внимательно, то наверняка оажется, что им никакой кликхаус с тераформом докером и гитом и не нужны были, а просто модно-молодежно. Хотя у них же «Ежедневно она обрабатывала тысячи запросов», это же без десятка модных продуктов никак не обойтись!
Очень кстати популярный кейс.
Стандартные работающие решения это скучно, давайте «модно-молодежно», увеличим команду разработчиков в 5 раз, навешаем дополнительно kaffka, Elastic Search.
Попутно остановим разработку и назовем это рефакторингом.

Интересно, а что было в предмете договора? А то из описания неудивительно, что кто-то в бизнесе перепутал админов, отвечающих в какой-то части за БД, с DBA-шниками, ведь DBA = DataBase Administrator. Откуда же произвольному заказчику знать все 50 оттенков администрирования, да еще и в том же виде, как вы их себе предствляете?
Но Лёня крепко вцепился в штурвал и слушать мои доводы отказался. Мы долго с ним собачились в чатике, но делать нечего — Лёня рулил на проекте, мы были просто нанятыми пацанами с улицы.

Ошибка номер раз. Это все должны было быть задокументировано и завизированно руководителем Лёни или как минимум им самим. Хотя за бекапы в виде активной реплики вас следует считать профнепригодными, уж извините.

И услышал что-то в духе: «Вы просрали наши данные! Я плачу вам, но ничего не работает! Вы отвечали за бэкапы, и не сделали нихрена! Давайте чините!» — только еще грубее.

— Знаешь что, иди-ка ты нахрен! У меня сегодня день рождения, и сейчас я буду бухать, а не заниматься вашими джуновскими самоделками из дерьма и палок!

А стоито спокойно объяснить что в таком тоне вы общаться не намерены и попросить спокойно изложить суть проблем. Если нет — все же нахрен.

Нет, я бомбил, я адски бомбил! Сыпал в чатик едкие «я же говорил» — потому что бэкап, который нифига бэкапом не был, — конечно же, ничего не спас.

Это не помогает. Заказчики _всегда_ будут считать себя умнее и очень редко будут прислушиваться к голосу разума. Единственный способ их вразумить — позволить влететь с размаху в пень, но предварительно надо зафиксировать, что это они приняли решение наперекор вашим советам.

Оказалось, порядок в компании был такой: после вставки данные удалялись безвозвратно

Как вовремя вы это выяснили…

В этих срачах мы наконец начали понимать — в компании думали, что мы те ребята, которые работают с данными и следят за структурой таблиц. Они перепутали админов с дибиэйщиками. И пришли спрашивать с нас далеко не как с админов.

Забыли прописать SLA? Жжетенько…

В итоге Лёни на встрече не оказалось. И мы отлично обо всем поговорили с главным! Сергей рассказал мне про свою боль. Он хотел не «автоматизировать Кликхаус» — он хотел, «чтобы запросы работали».

С этого начинать нужно было.

Штатные разрабы некорректно использовали инструмент для аналитики. Они ходили в графану, писали свой царский запрос. Он выгружал данные за 2 недели. Получался красивый график. Но на деле запрос данных шел каждые 10 секунд. Все это копилось в очередь, поскольку Кликхаус попросту не вывозил обработку. Тут и скрывалась основная причина. В графане ничего не работало, запросы стояли в очереди, постоянно прилетали старые неактуальные данные.

Дичь какаято…
Я вот признаюсь, я не работал с кликхаусом, но если взять pg + timescaleDB, создать гипертаблицу и навесить Continuous Aggregates (если нужно — realtime) то все это веселье вывозит ну совершенно любую нагрузку на чтение.

Собственно, на этом мы и расстались — сделали, что смогли.

А можно было еще разочек с собственником поговорить, благо контакт есть.

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

А вот это красиво. Можно еще дальше: инфраструктура ваша — данные клиентские.
Остановили запись, посчитали число ивентов, которые там лежат за день. Закинули еще данных, от которых не записалась только треть. Три шарды по 2 реплики. Вставляешь 100.000 строк — 33.000 не записываются.

Звучит как какая то магия, вам кликхаус что возвращал после вставки? OK?
Кликхаус умеет тихо скипать вставки если они побайтно идентичны, не похоже ли это на ваши «вставляешь 100к строк, а 33к не записываются»?

Наличие двух разных независимых кластеров и пайплайнов данных это в принципе достаточно разумная схема.
«раз мы тут эксперты, то должны были всех переубедить и настоять на своем решении».
Я уже не первый раз читаю про такое… Видимо это такой модный-манипулятивный способ скидывать с себя ответственность.
Это не ответственность.

Эскалация вопроса — нормальный взрослый подход. Если волнует конечный результат, конечно.
Любой может ошибаться. Не надо ждать, что само рассосется. Эскалируем, пробуем решить вопрос.

Это касается любой деятельности, хоть аутсорс, хоть внутри конторы.

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

Да это во всех сферах, медицина, обучение, ИТ, бухгалтерия, сервис автомобильный. Люди такие. Главное, что накосячил не я.

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

Я бы все равно в таком случае настоял на нормальном бэкапе. Оставить только реплику это реально несерьезно, даже если на той стороне глупцы. Даже если сохранены все переписки и доводы обеих сторон.
Кстати, не уловил, как связан бэкап и потеря в БД на продакшене 33% входящих данных?

Бэкап вроде должен просто восстановить состояние БД на продакшене, то есть те же 67%
Тут предлагали бекапить сырые данные, перед их отправкой в БД.

Это уже снова не бэкап получается, а что-то другое. И надо бы не забыть это "что-то другое" тоже бэкапить...

Спасибо, нашел это в статье, и правда автор сохранять хотел входящий поток.

Но вот только это не бэкап. Обычно это вроде логом или журналом называют.

Это не взаимозаменяющие вещи и бывает так, что нужно и то и другое. И если бы автор эти две темы развел с самого начала, то его предложению скорее всего никто бы не сопротивлялся.

Не удивлён, что автор получил негативный опыт, при таких коммуникациях с заказчиком.
Глава компании, напротив, не хотел винить своих. Скрины и слова на него не действовали. Он считал, что раз мы тут эксперты, то должны были всех переубедить и настоять на своем решении.


Дальше можно не читать. Глава делегирует полномочия решения одному человеку, но спрашивает в выборе с другого, полномочия которому не делегировали.

Очень много воды, почему терялась треть данных так и не написал

Отдельной строкой хочется отметить экономический и технический аспект бэкапов больших кластеров баз данных от сотен террабайт (без учета реплик). :-)
С бэкапами, допустим, понятно, но почему данные терялись?
Клиент заказал мониторинг, что для меня, например, подразумевает и мониторинг сбоев, по какой причине он не сработал?
Спасибо!!! Очень крутая статья. Да интересно понять как был настроен ETL что терялись данные.

То есть вас, как экспертов, попросили сделать бэкап, а вы послушали их инженера, сделали активную реплику, отчитались о сделанной работе, а потом еще и брали деньги за поддержку этого решения.
Мне кажется, слоган «ДОВЕРЬТЕ ИНФРАСТРУКТУРУ FEVLAKE» говорит о другом подходе.

Тут вся соль ситуации в том, что заказчику нужен был не только бэкап БД, и они как эксперты предлагали по сути НЕ бэкап. И только Лёня как раз предлагал решение наиболее похожее на бэкап БД, но которое НЕ решало одну из важнейших проблем заказчика.

При этом автор пишет про «страшное недопонимания внутри их команды», а я из статьи вижу «страшное недопонимание» в треугольнике заказчик-Лёня-автор.

Люди в мире разделяются на 2 категории: одни решают проблемы, а другие делают задачи. Но вот эти ребята, они же ни проблему не решили, ни задачу (бэкап) не сделали.

Я бы постеснялся с ними вообще связываться.
«хера, нахрен, хреновый, идите нахрен, буду бухать, клиент не понял, увидел не козла, а хорошего парня, хреновая инфраструктура, пивасик из алкомаркета, джуновскими самоделками из дерьма и палок»
И большинство тут про клиента, которому они подрядились делать работу, ну акей!
Штатные разрабы сочинили свой кастомный «вставлятор» данных. Он работал так: батчил файлики, запускал скрипт и сливал данные в табличку.

Объясните, в чем недостатки такого подхода? И как именно вы переделали вставку?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.