Comments 68
"Собственно, на этом мы и расстались" — удивительное терпение.
По ходу истории звоночки переходящие в колокольный звон.
Неужели так нужны деньги, что приходится работать с чудаками?
Но, как любой опыт конечно полезен, как говорит один мой знакомый — вот так мальчики, становятся мужчинами.
Удачи в дальнейшем!
Поддерживаю. Иначе релиз в пятницу это до первого пллхого случая.
Видимо каждый хоть раз натыкался на этом грабли.
У нас кстати кроме пятницы есть запрет на выкладку во время фриза. Особого времени для клиентов, когда они считают зп, выгружают отчётность и т.п. это пару дней, но тоже лучше не выкладывать.
Просто держу задачи до "разморозки".
Это ведь первая заповедь для… да для много кого… для инженера, админа, разраба.
Замечательная история и замечательный опыт.
По вечерам и в пятницу никаких апдейтов!!! Опыт 100500%
Пятёрочка за то что не бросили клиентов, даже таких "ищущих свой путь"...
«Наши клиенты» работает ещё хуже, там логика поведения вообще не ясна. Их то можно скролить, то нельзя, то они сами скролятся справа налево, то потом слева направо.
На сайте есть еще несколько моментов, которые попались на глаза (не технические) и возможно покажутся вам нудными или неважными, но тем не менее по крайней мере я обратил на них внимание, возможно и вы увидете в этом недочеты после их обозначения. Ничего критичного, но:
— Почти на всех страницах висит бейдж с надписью «SLA 5 min». Не думаю что это прямой обман, но вы же понимаете что в SLA включается множество параметров и кроме того, если вы (как и почти все) имели ввиду availability time, то оно дается в доле от времени (обычно процентной)?" 5 минут" просто не имеют никакого смысла.
— В блоке «Вопросы, которые можем решить» не согласованные по форме высказывания. Можно поменять хотя бы вот так: «Требуется повысить» -> «Повышение»
— В «Услугах» тоже несогласованные высказывания. «Мониторинг» и «Внедрение», но «Описываем» и «Консультируем».
— В стеках часть технологий с маленькой буквы — «helm», «jenkins» и т.д. А часть с большой — «Prometheus».
Удачи и еще раз спасибо за статью:)
У меня есть похожая история. Я тогда работал в связи, моя задача была чтобы вся оптика в компании работала корректно. Однажды руководству захотелось модернизировать узел агрегации. Узел расположен в чердачном помещении, а на улице Февраль месяц и -20 мороза. Я их долго убеждал дождаться оттепели, т.к. в такой мороз работать с оптикой нельзя и они согласились. Но тут нежданчик. Вот такой вот «Леня», один из моих коллег, сказал, да «Говно вопрос, я все сделаю и в такую погоду».
Итог у него сломалось 95% волокон под корень кабеля, хорошо он сразу сообщил начальству, а они сообщили мне. Запаса в кабеле оставалось около 2-3м, больше возможностей ошибаться нет, центр города без интернета, а завтра понедельник рабочий день.
Итог был утро 8 утра, 10 монтажников утепляют щели в сифонящей шиферной крыше, и расставляют тепловые пушки, что бы поднять температуру хотя-бы до 0… +2, иначе тот кабель который там использовался было не переварить, волокна не выдерживали мороза при зачистке :)
Ой-ё, если правда — это очень больно
Но какой должен быть провайдер, чтобы не научить монтажников основным требованиям...
Да, прокладывать можно и в -30, пользоваться и в -50, но про сварку везде указывается от 0, а чаще от +5… не зря же палатки продают...
А от пыли, которую теплопушки подняли, как защищались?
В итоге проблема была с кривым кодом или бага clock house?
Интересно, конечно, но хотелось бы "услышать" обе стороны.
Привет, Лёня!
Не угадали
Мне всего лишь в белизну плаща автора слабо верится:
- не мог всем там заправлять один "разраб Лёня", всегда можно идти к тому, с кем заключен договор;
- почему не разобрали схему хранения с самого начала — не ясно;
- почему не обговорили и не подписали условия в договоре — кто знает...
PS: кидаться обвинениями в программистов — древняя народная забава админов
PPS: сам админ, знаю о чём говорю
Ну и аутсорсеры часто заявляют, что всё будет работать как часы, и само собой никаких проблем. И всё автоматизировано, в облаках.
А договор — он и на переговорах договор и в суде он тоже договор, на него смотреть будут в первую очередь.
Молодец автор, что сейчас сначала смотрит в лужу и тыкает палочкой, прежде чем наступить.
У клиента тоже есть шанс познакомиться с работой аутсорсера и показать свои поделки, ведь админа штатного может и не было никогда, всё в облаках, зачем нам.
Почему, почему, почему… Да потому что опыта в таких вещах нет, статья же как раз про то, как прошлись по граблям из-за этого. Уметь хорошо админить/кодить — одно, уметь правильно оценивать риски и выстраивать отношения с заказчиком — СОВСЕМ другое.
Не могу согласиться, ведь хорошо админить/кодить как раз включает в себя оценку рисков, иначе это не хорошо, а посредственно.
Как и умение обсудить условия и взять на себя обязательства, а на что-то сказать чёткое «Нет», но это, кмк, топ уровень инженера.
PS: конечно я понимаю, что статья про первые потуги без опыта ведения бизнеса, как со стороны автора, так и со стороны его заказчика.
почему не разобрали схему хранения с самого начала — не ясно;
Потому что инвестировать время и деньги в изучение инфраструктуры потенциального клиента не рентабельно. Хорошая конверсия может быть 10% — это значит, что на каждые 10 проектов, которые вы изучите, вы заключите один договор. Ваши сотрудники очень быстро вам расскажут, что они думают о перспективе потратить еще пару недель на изучение проекта каких-то дядек, с которыми они работать все равно не будут.
почему не обговорили и не подписали условия в договоре — кто знает...
Потому что прописать всеобъемлющий SLA на такую штуку как БД не реально. БД лежит потому что ваш косяк или потому что «Леня» написал хитрую хранимку? В два часа ночи разбудят и вас и Леню. Вы, конечно, разберетесь и гордо скажете «мы не виноваты, этого нет в SLA», но уже после того как разберетесь, а это 90% работы.
Начинать с малого: выяснить потребности, ознакомиться с текущей схемой взаимодействия и обговорить риски — потом предложить аудит и обслуживание, как автор делает сейчас.
Договорённости должны как минимум включать зоны ответственности, чтобы избежать путаницы вроде «перепутали админов с дибиэйщиками» и защитить и себя и заказчика от «Лёниных смелых решений», я так считаю.
2. Очень даже понятно. Провести грамотный аудит — это получить ответы на все вопросы, почему тут такое говно. Это совсем чуть-чуть меньше, чем переделать всё и поэтому стоит соотвественно. А владельцы бюджета очень редко соглашаются платить за то, чтобы им показали какое тут говно.
3. См. П. 2. Потому что если все-все-все прописывать, то надо делать аудит, в какое конкретно говно исполнитель не наступает.
1) Раз уж с куратором проекта не удалось прийти к согласию — то пойти к заказчику и сказать, что «Лёня принимает смелые решения», которые ты сам лично не готов поддерживать. Предложить решение, какое считаешь верным/приемлемым, показав сравнение плюсов и минусов, объяснить не в кудахтерах, а в деньгах, в деньгах все понимают.
2,3) Как уже отвечал комментатору выше — можно начинать с малого, с общей оценки и разделения зон ответственности, а после предложить полный аудит.
К слову, да, проблема сбоя не раскрыта, где треть данных терялась?
Почему после пересоздания таблицы данные стали сохраняться?
Что было в логе/статусе?
С чем пришли на разбор и постмортем?
Штатные разрабы сочинили свой кастомный «вставлятор» данных. Он работал так: батчил файлики, запускал скрипт и сливал данные в табличку.
ClickHouse — база колоночная, чем больше батч и реже вставки, тем быстрее отрабатывает в соотношении строк в секунду.
Но главная проблема была в том, что огромное количество данных принималось для одного простейшего запроса. Запрос джойнил данные посекундно. Все ради одной циферки — суммы за день.
Для частых однотипных запросов есть буфер, лимиты памяти на пользователя и тд, кроме того для графаны рекомендуется использовать отдельного пользователя с ограничением qps.
ClickHouse — база аналитическая, для посекундного обновления нужен другой инструмент, например Tarantool.
Могли на берегу узнать, чего хотят клиенты, и если нужно — посоветовать другой инструмент, но, как говорит мой коллега: "Знал бы где соломку подстелить — жил бы в Сочи".
Перефразирую презентацию Алексея Миловидова:
Если у вас тормозит ClickHouse, скорее всего вы его неправильно используете
ozar.me/2016/12/how-i-handle-weekend-and-holiday-work
Кстати, реальный случай из жизни, про иностранный подход.
Пятница, вечер — инцидент с высшим приоритетом, все стоит.
Все специалисты по всем направлениям подключились.
Разгребали все выходные.
Причина — разрабы поменяли запрос от приложения и получили Декартово произведение.
Ещё раз — пятница, вечер.
Компания мирового уровня.
Когда, я встречаю тоску типа "а вот в Европе порядок", я всегда улыбаюсь, люди они везде одинаковы.
Кстати, опять таки про аутсорт и оплату в выходные. Платят не по КЗОТ и это политика компании, не нравится — увольняйся, что я и сделал.
Ничего не понял, но было интересно.
Фраза стара как мир.
«Когда ты просрал данные, делается так — ты берешь средние данные за предыдущие дни и вставляешь их в просранные.»
От смеха у меня зашевилились волосы. Что ж это за бизнес такой, где можно так нахерачить данных?
Как многократная «жертва» аутсорсеров, я не люблю аутсорс. Как админу мне приходилось и приходится сопровождать много разных систем от аутсорсеров. Давно брошенных, с потерянными исходниками, исчезнувшими с горизонта людьми… Качество продукта чаще всего так себе. А кубернетес там будет или вижуал бейсик 1.0 с толстым клиентом, это вообще без разницы.
Но Лёня крепко вцепился в штурвал и слушать мои доводы отказался. Мы долго с ним собачились в чатике, но делать нечего — Лёня рулил на проекте, мы были просто нанятыми пацанами с улицы.
Ошибка номер раз. Это все должны было быть задокументировано и завизированно руководителем Лёни или как минимум им самим. Хотя за бекапы в виде активной реплики вас следует считать профнепригодными, уж извините.
И услышал что-то в духе: «Вы просрали наши данные! Я плачу вам, но ничего не работает! Вы отвечали за бэкапы, и не сделали нихрена! Давайте чините!» — только еще грубее.
— Знаешь что, иди-ка ты нахрен! У меня сегодня день рождения, и сейчас я буду бухать, а не заниматься вашими джуновскими самоделками из дерьма и палок!
А стоито спокойно объяснить что в таком тоне вы общаться не намерены и попросить спокойно изложить суть проблем. Если нет — все же нахрен.
Нет, я бомбил, я адски бомбил! Сыпал в чатик едкие «я же говорил» — потому что бэкап, который нифига бэкапом не был, — конечно же, ничего не спас.
Это не помогает. Заказчики _всегда_ будут считать себя умнее и очень редко будут прислушиваться к голосу разума. Единственный способ их вразумить — позволить влететь с размаху в пень, но предварительно надо зафиксировать, что это они приняли решение наперекор вашим советам.
Оказалось, порядок в компании был такой: после вставки данные удалялись безвозвратно
Как вовремя вы это выяснили…
В этих срачах мы наконец начали понимать — в компании думали, что мы те ребята, которые работают с данными и следят за структурой таблиц. Они перепутали админов с дибиэйщиками. И пришли спрашивать с нас далеко не как с админов.
Забыли прописать SLA? Жжетенько…
В итоге Лёни на встрече не оказалось. И мы отлично обо всем поговорили с главным! Сергей рассказал мне про свою боль. Он хотел не «автоматизировать Кликхаус» — он хотел, «чтобы запросы работали».
С этого начинать нужно было.
Штатные разрабы некорректно использовали инструмент для аналитики. Они ходили в графану, писали свой царский запрос. Он выгружал данные за 2 недели. Получался красивый график. Но на деле запрос данных шел каждые 10 секунд. Все это копилось в очередь, поскольку Кликхаус попросту не вывозил обработку. Тут и скрывалась основная причина. В графане ничего не работало, запросы стояли в очереди, постоянно прилетали старые неактуальные данные.
Дичь какаято…
Я вот признаюсь, я не работал с кликхаусом, но если взять pg + timescaleDB, создать гипертаблицу и навесить Continuous Aggregates (если нужно — realtime) то все это веселье вывозит ну совершенно любую нагрузку на чтение.
Собственно, на этом мы и расстались — сделали, что смогли.
А можно было еще разочек с собственником поговорить, благо контакт есть.
С набитыми шишками, умудренные этой историей, мы открыли свой бизнес и сформировали для себя несколько принципов. Сейчас мы никогда не начнем работу также, как тогда.
А вот это красиво. Можно еще дальше: инфраструктура ваша — данные клиентские.
Остановили запись, посчитали число ивентов, которые там лежат за день. Закинули еще данных, от которых не записалась только треть. Три шарды по 2 реплики. Вставляешь 100.000 строк — 33.000 не записываются.
Звучит как какая то магия, вам кликхаус что возвращал после вставки? OK?
Кликхаус умеет тихо скипать вставки если они побайтно идентичны, не похоже ли это на ваши «вставляешь 100к строк, а 33к не записываются»?
Наличие двух разных независимых кластеров и пайплайнов данных это в принципе достаточно разумная схема.
Я уже не первый раз читаю про такое… Видимо это такой модный-манипулятивный способ скидывать с себя ответственность.
Эскалация вопроса — нормальный взрослый подход. Если волнует конечный результат, конечно.
Любой может ошибаться. Не надо ждать, что само рассосется. Эскалируем, пробуем решить вопрос.
Это касается любой деятельности, хоть аутсорс, хоть внутри конторы.
В статье же прямым текстом написано — банальное недопонимание, без всяких "видимо". Пока задача дошла от топа до аутсорсера через несколько промежуточных звеньев, она исказилась до неузнаваемости, в результате у топа и аутсорсера сложились принципиально разные взгляды на то, кто за что отвечает.
Да это во всех сферах, медицина, обучение, ИТ, бухгалтерия, сервис автомобильный. Люди такие. Главное, что накосячил не я.
Ну вы поставьте себя на место заказчика. Вы заплатили чувакам деньги за создание бэкапов. Чуваки сказали, что сделали, брали деньги за поддержку, время шло. А когда понадобились бэкапы, оказывается, что вместо бэкапов вам сделали активную копию, потому что ваш инженер им так предложил. Ну если бы я хотел, чтоб эту проблему решал мой инженер — я бы не обращался к фрилансерам.
Это как я приеду в автосервис, попрошу поменять масло, мне скажут «да-да, мы все сделали». А когда движок сдохнет, окажется, что по факту поменяли магнитолу, потому что жена спросила, почему музыка плохая.
Бэкап вроде должен просто восстановить состояние БД на продакшене, то есть те же 67%
Это уже снова не бэкап получается, а что-то другое. И надо бы не забыть это "что-то другое" тоже бэкапить...
Но вот только это не бэкап. Обычно это вроде логом или журналом называют.
Это не взаимозаменяющие вещи и бывает так, что нужно и то и другое. И если бы автор эти две темы развел с самого начала, то его предложению скорее всего никто бы не сопротивлялся.
Не удивлён, что автор получил негативный опыт, при таких коммуникациях с заказчиком.
Глава компании, напротив, не хотел винить своих. Скрины и слова на него не действовали. Он считал, что раз мы тут эксперты, то должны были всех переубедить и настоять на своем решении.
Дальше можно не читать. Глава делегирует полномочия решения одному человеку, но спрашивает в выборе с другого, полномочия которому не делегировали.
Очень много воды, почему терялась треть данных так и не написал
Клиент заказал мониторинг, что для меня, например, подразумевает и мониторинг сбоев, по какой причине он не сработал?
То есть вас, как экспертов, попросили сделать бэкап, а вы послушали их инженера, сделали активную реплику, отчитались о сделанной работе, а потом еще и брали деньги за поддержку этого решения.
Мне кажется, слоган «ДОВЕРЬТЕ ИНФРАСТРУКТУРУ FEVLAKE» говорит о другом подходе.
+1 жаль у меня кармы нет
При этом автор пишет про «страшное недопонимания внутри их команды», а я из статьи вижу «страшное недопонимание» в треугольнике заказчик-Лёня-автор.
«хера, нахрен, хреновый, идите нахрен, буду бухать, клиент не понял, увидел не козла, а хорошего парня, хреновая инфраструктура, пивасик из алкомаркета, джуновскими самоделками из дерьма и палок»
И большинство тут про клиента, которому они подрядились делать работу, ну акей!
Штатные разрабы сочинили свой кастомный «вставлятор» данных. Он работал так: батчил файлики, запускал скрипт и сливал данные в табличку.
Объясните, в чем недостатки такого подхода? И как именно вы переделали вставку?
Пока все праздновали мой день рождения, я до утра чинил кластер — а разрабы валили на меня свои ошибки