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



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

    Компания, которая написала, занималась аналитикой данных. Ежедневно она обрабатывала тысячи запросов. К нам они пришли со словами: ребят, у нас есть ClickHouse и мы хотим автоматизировать его настройку и установку. Хотим Ansible, Terraform, Докер и чтобы это все хранилось в гите. Хотим кластер из четырех нод по две реплики в каждой.

    Стандартная просьба, каких десятки, и нужно такое же хорошее стандартное решение. Мы сказали «окей», и через 2-3 недели все было готово. Работу они приняли и начали переезжать на новый кластер Кликхауса с помощью нашей утилиты.

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

    Мы сопровождали переезд, появились другие задачи — настроить бэкапы и мониторинг. В этот же момент СТО этой компании слился на другой проект, оставив нам за командира одного из своих — Леонида. Лёня был не шибко одаренный парень. Простой разработчик, которого вдруг поставили главным по Кликхаусу. Кажется, это было его первое назначение чем-то поруководить, и от навалившейся чести у него проступила звездная болезнь.

    Вместе мы принялись за бэкапы. Я предлагал бэкапить сразу исходные данные. Просто брать, зиповать и элегантно закидывать в какой-нибудь с3. Исходные данные — это золото. Был и другой вариант — бэкапить сами таблицы в Кликхаусе, с помощью фриза и копирования. Но Лёня придумал свое решение.

    Он объявил, что нам нужен второй кластер Кликхауса. И отныне мы будем писать данные на два кластера — основной и бэкапный. Я ему говорю, мол, Лёня, выйдет не бэкап — а активная реплика. И если данные начнут теряться на продакшене, на твоем бэкапе будет то же самое.

    Но Лёня крепко вцепился в штурвал и слушать мои доводы отказался. Мы долго с ним собачились в чатике, но делать нечего — Лёня рулил на проекте, мы были просто нанятыми пацанами с улицы.

    Мы послеживали за состоянием кластера и брали плату только за работу админов. Чистое администрирование Кликхауса без залезания в данные. Кластер был доступен, диски в норме, ноды в порядке.

    Мы еще не подозревали, что получили этот заказ из-за страшного недопонимания внутри их команды


    Руководитель был недоволен, что Кликхаус работает медленно и иногда теряются данные. Он поставил своему СТО задачу разобраться. Тот разобрался, как смог, и сделал вывод, что надо просто автоматизировать Кликхаус — и все. Но как вскоре выяснилось — им нужна была совсем не команда девопсов.

    Все это выяснилось очень-очень болезненно. А самое обидное, это было в мой день рождения.



    Пятница, вечер. Я забронировал столик в любимом винном баре и позвал корешей.

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

    В ресторане было по-пятничному шумно. Заказав выпивки, еды, развалились на диванчиках. Все это время мой слак потихоньку заваливали сообщения. Писали что-то про нехватку данных. Я подумал — утро вечера мудренее. Особенно сегодняшнего.

    Ближе к одиннадцати начали уже названивать. Это был руководитель компании… «Наверное, решил меня поздравить», — очень неуверенно подумал я, снял трубку.

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

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

    Вот так я не сказал. Вместо этого достал ноут и принялся за работу.

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

    Мы с пацанами придумали, как вручную остановить запись и все проверить. Действительно убедились, что часть данных не пишется.

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

    Творилась полная неразбериха. Все слали друг друга на хер по очереди: первым туда отправился Лёня, за ним последовали я сам и основатель компании. Только присоединившийся СТО пытался вывести наши созвоны с криками и переписку в сторону поиска решения проблемы.

    Что происходило на самом деле — никто не понимал


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

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

    Я не давал клятву разраба, но бросать парней на том конце провода было непорядочно — пусть даже они во всем винили нас. Я на 99% был уверен, что проблема залегла не в наших решениях, не на нашей стороне. 1% шанса, что облажались все же мы, жег тревогой. Но на чьей бы стороне беда не находилась — это надо было пофиксить. Оставлять клиентов, какими бы они ни были, с такой страшной течью данных — это слишком жестоко.

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

    После трех утра мы с друганом пошли ко мне домой, заказали из алкомаркета пивасик. Я сидел с ноутом и проблемами Кликхауса, друг мне что-то рассказывал. В итоге, через час он обиделся на то, что я работаю, а не с ним пиво пью, и уехал. Классика — побыл другом девопса.

    К 6 утра я пересоздал таблицу заново, и данные начали заливаться. Все заработало без потерь.



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


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

    Их основная претензия — какого хера, вы отвечали за бэкапы и не сделали их нормально, продолбали данные. И все это с матами-перематами.

    Мне хотелось справедливости. Я откопал переписку и приложил всех скриншотами, где Леонид со всей силы заставляет делать такой бэкап, какой был сделан. Их СТО встал на нашу сторону после моего телефонного звонка. После свою вину признал и Леня.

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

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



    Это была самая стремная встреча в моей карьере. Мой союзник от клиента — СТО — не смог найти время. На встречу я ехал к боссу и Лёне.

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

    Пока поднимался, так чиркал зажигалкой, что сломал ее.

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

    Я увидел не козла, а хорошего парня, переживающего за свой бизнес, погруженного в работу 24/7. Чат частенько рисует нам злодеев, подлецов и тупиц. Но в жизни это такие же люди, как и ты.

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

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

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



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

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

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

    Мы перенастроили кластер, переделали вставку. Штатные разработчики переписали свой «вставлятор», и он начал шардировать данные корректно.

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

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



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

    Дибиэйщик Макс после этого проекта присоединился к нам, и мы до сих пор отлично работаем вместе. Кейс с Кликхаусом научил проводить перед началом работы полный и основательный аудит инфраструктуры. Мы вникаем, как все работает, и только потом принимаем задачи. И если бы раньше мы сразу рванули обслуживать инфраструктуру, то теперь сначала делаем разовый проект, который и помогает понять, как привести ее в рабочее состояние.

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

    P.S. Так что, если у вас есть вопросы по вашей инфраструктуре, смело оставляйте заявку.

    У нас есть 2 бесплатных аудита в месяц, возможно, именно ваш проект будет в их числе.
    Ребреин
    REBRAIN: Онлайн-практикумы для Инженеров

    Комментарии 67

      +8

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

        +13
        Почти перед выходом нам прилетает задачка сделать альтер,

        Никаких релизов в пятницу, золотое правило.

          +3

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

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

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

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

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

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

                  «Наши клиенты» работает ещё хуже, там логика поведения вообще не ясна. Их то можно скролить, то нельзя, то они сами скролятся справа налево, то потом слева направо.
                    +4
                    Спасибо большое за фидбек, поправляем
                    +20
                    Авральные ситуация часто дают много опыта. У всех были авральные случаи.

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

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

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

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


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


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


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

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

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

                        –4

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

                          +22

                          Привет, Лёня!

                            +1

                            Не угадали


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


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

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

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

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


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


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


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

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

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

                                  +1

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


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


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

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

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

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

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

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


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

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

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


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

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

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


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


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

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

                                    +8

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


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

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


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

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


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

                                      +3

                                      Перефразирую презентацию Алексея Миловидова:
                                      Если у вас тормозит ClickHouse, скорее всего вы его неправильно используете

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                              +1

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

                                                                +3

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

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

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

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

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

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

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

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


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

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

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

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

                                                                                  –1

                                                                                  +1 жаль у меня кармы нет

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

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

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

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

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

                                                                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                      Самое читаемое