Comments 53
Сам работаю в Туту.ру, а тут материал от коллег. Прочитал как детектив. Крутой разбор! Редкий случай и от того вдвойне интереснее. Пиши еще. И спасибо за оперативность в публикации.
P.S. Факапы случаются, но редко когда компания признает его, да еще и делится опытом, как все полечили.
Лучше бы компания выделила ресурсы на оптимизацию и устранение технического долга.
А то сейчас это какой-то повальный тренд — забивать на алгоритмическую сложность и копить техдолг.
Лучше бы
Люблю, когда люди решают, как поступать другим людям. Или вы SEO этой компании?
У нас идет большое количество проектов, направленных на отдачу техдолга (в вводной части поста были ссылки про это: раз, два). Другое дело, что всегда (как мне кажется) технари будут считать, что этого недостаточно, и что нужно переделать еще в паре мест, а бизнес — что слишком много и что технари не вылезают из рефакторингов. Просто разные взгляды и разные подходы, нужно уметь договариваться )
Никто не думал, что к серверному мониторингу нужно прикручивать ещё мониторинг того, что говорит президент на прямой линии
вот уж да уж, никогда не знаешь кто накинет на вентилятор и с какой стороны на тебя этот вентилятор подует))
Стоит внимательнее следить даже за минорными апдейтами софта.
А вот эту мысль я всю жизнь пытаюсь донести до всех с кем работаю. Бизнес против, апдейты это или простой или ещё что… а бизнес во главу стола ставит деньги… Начальство против, начальство нарисовало строгий график апдейтов, ему и надо следовать и неважно что вчера выкатили важный патч на важную . Коллеги против, коллегам лень..
На самом деле всегда всё решаемо и обсуждаемо. Вот пришёл на новую работу, надеюсь тут я увижу картину не хуже (а может и лучше).
Моя мысль — именно следить внимательно, это не равно «сразу накатывать». И не только из бизнесовых соображений, хотя они тоже есть, но и из технических — на каждый починенный баг может приходиться новый посаженный, проявляющийся примерно в настолько же редких краевых случаях. И как все эти краевые случаи выловить не на продакшене, а раньше — большой вопрос.
Думаю, реализуйся сценарий из анекдота про бар и президента, краны бы тоже встали в перегрузку, стаканы кончились, и все бы молились чтобы справилась канализация.
непонятно (т.к. не специалиист), но очень интересно)
а уж формулировка «Выводы от капитана» повеселила отдельно.
а уж формулировка «Выводы от капитана» повеселила отдельно.
чОрт, я даже не подумал ее так прочитать. Десять лет прошло )
Ничего не понял:
Как прочитать?
После чего десять лет?
Как прочитать?
После чего десять лет?
Простите, пожалуйста, эта ветка совсем оффтопная от темы статьи. Просто когда-то давно мы с lexxair играли в спортивное «что? где? когда?» в одной команде и я был ее капитаном.
UFO just landed and posted this here
Я не из туту, но мне прям очень кажется, что здесь проблема не в туту вовсе, а в том, что автовокзал из второго случая напрочь пытается саботировать работу с ИТ-системами.
Насколько я знаю, пассажироперевозки сейчас имеют одну общую систему, и все автовокзалы должны с ней работать.
Комиссионщиками в целом можно сказать про любую кассу/сайт продажи каких-либо билетов, не относящуюся к авто/жд/вокзалу / аэропорту. То, что какой-то автовокзал вводит свои правила регистрации пассажиров вовсе не означает, что туту плохой комиссионщик. Но как минимум одно туту полезное для вас сделал — вам не пришлось ехать заранее на автовокзал и покупать в кассе билет, а значит некую пользу он вам принёс.
Насколько я знаю, пассажироперевозки сейчас имеют одну общую систему, и все автовокзалы должны с ней работать.
Комиссионщиками в целом можно сказать про любую кассу/сайт продажи каких-либо билетов, не относящуюся к авто/жд/вокзалу / аэропорту. То, что какой-то автовокзал вводит свои правила регистрации пассажиров вовсе не означает, что туту плохой комиссионщик. Но как минимум одно туту полезное для вас сделал — вам не пришлось ехать заранее на автовокзал и покупать в кассе билет, а значит некую пользу он вам принёс.
UFO just landed and posted this here
по-сути, остался без билета на этот рейс, в маршрутной квитанции у меня другой рейс, другой номер маршрута, другое время отправления. Если бы вокзал саботировал, то меня не посадили бы вообще.Может быть как-раз и саботировал — в базу забивает один номер маршрута, а едет фактически другой. Делает так, чтоб все покупали только в кассе, чем сталкивались с такими трудностями.
А что, есть хорошие (посредники)?Ну например авиабилеты очень часто покупал в авиакассах, и нормально. Из плюсов — через такие авиакассы можно очень нестандартно изменить билет — например докупить один билет на несовершеннолетнего и прикрепить ко взрослому билету, чего ни один сайт не предложит.
Они — художники, они так видят. Но они ниасиливают в точное значения отметок времени.Да, это треш конечно по времени. Но что-то мне подсказывает, что не только у туту такая жопа.
TimsTims что в Вас побуждает защищать раздолбаев tutu.ru?Всё очень просто, я ищу истину, которая рождается в споре.
Во-первых, от лица компании и от меня, как от руководителя вертикали автобусов, примите наши извинения о несоответствии сервиса вашим ожиданиям.
По времени отправления и прибытия мы получаем информацию напрямую от систем продаж билетов автовокзалов и перевозчиков, время прибытия является плановым, о чем мы предупреждаем на сайте, и зачастую зависит от ситуации в дороге, может изменяться как в меньшую, так и большую сторону. К сожалению, на текущий момент у нас в стране нет в открытом доступе системы онлайн мониторинга за передвижением автобусов, и мы не можем узнать о текущем местоположении или состоянии транспортного средства без информации со стороны перевозчика или пассажиров, СМИ.
Про электронный билет: одно из самых важных изменений, которого мы, tutu.ru, помогли достичь — это изменения в федеральном законе касающиеся признания электронного билета достаточным основанием для посадки на автобус, о чем я рассказывал в материале habr.com/ru/company/tuturu/blog/551090. К сожалению, не везде на местах соблюдают постановление, мы регулярно проводим мониторинг направлений где пассажиров не пускают с электронным билетом и видим, что за 4 месяца этого года количество вокзалов, осуществляющих посадку по электронному билету увеличилось на 30-40%и охватывает большую часть России. Мы актуализируем информацию о приёме электронного билета регулярно на основании информации от автовокзалов и из отзывов. То есть вас должны были принять по билету в электронном виде, и когда отказали — нарушили действующее законодательство. Но поскольку такие нарушения достаточно часты, мы предупреждаем пользователей о том, на какие вокзалы надо печатать билет. Очевидно, в вашем случае эта система дала сбой.
Про замену ТС: В соответствии с законодательством, перевозчик вправе заменить транспортное средство в любой момент осуществления перевозки, поэтому если после покупки произошло такое изменение и перевозчик не отразил его в системе продаж, то мы не можем информировать об этом в билете. В маршрутных квитанциях к билету мы всегда отражаем актуальную информацию о времени и месте отправления автобуса, а также дополнительных характеристиках рейса, если их предоставил перевозчик/вокзал в системе продаж билетов.
Пожалуйста, отправьте мне в личку или на info@tutu.ru с темой «Вопрос с Хабра» номер ваших билетов и данные пассажиров, чтобы мы могли проверить действия наших сотрудников по вашим обращениям, а также провести проверку перевозчика и его расписания.
По времени отправления и прибытия мы получаем информацию напрямую от систем продаж билетов автовокзалов и перевозчиков, время прибытия является плановым, о чем мы предупреждаем на сайте, и зачастую зависит от ситуации в дороге, может изменяться как в меньшую, так и большую сторону. К сожалению, на текущий момент у нас в стране нет в открытом доступе системы онлайн мониторинга за передвижением автобусов, и мы не можем узнать о текущем местоположении или состоянии транспортного средства без информации со стороны перевозчика или пассажиров, СМИ.
Про электронный билет: одно из самых важных изменений, которого мы, tutu.ru, помогли достичь — это изменения в федеральном законе касающиеся признания электронного билета достаточным основанием для посадки на автобус, о чем я рассказывал в материале habr.com/ru/company/tuturu/blog/551090. К сожалению, не везде на местах соблюдают постановление, мы регулярно проводим мониторинг направлений где пассажиров не пускают с электронным билетом и видим, что за 4 месяца этого года количество вокзалов, осуществляющих посадку по электронному билету увеличилось на 30-40%и охватывает большую часть России. Мы актуализируем информацию о приёме электронного билета регулярно на основании информации от автовокзалов и из отзывов. То есть вас должны были принять по билету в электронном виде, и когда отказали — нарушили действующее законодательство. Но поскольку такие нарушения достаточно часты, мы предупреждаем пользователей о том, на какие вокзалы надо печатать билет. Очевидно, в вашем случае эта система дала сбой.
Про замену ТС: В соответствии с законодательством, перевозчик вправе заменить транспортное средство в любой момент осуществления перевозки, поэтому если после покупки произошло такое изменение и перевозчик не отразил его в системе продаж, то мы не можем информировать об этом в билете. В маршрутных квитанциях к билету мы всегда отражаем актуальную информацию о времени и месте отправления автобуса, а также дополнительных характеристиках рейса, если их предоставил перевозчик/вокзал в системе продаж билетов.
Пожалуйста, отправьте мне в личку или на info@tutu.ru с темой «Вопрос с Хабра» номер ваших билетов и данные пассажиров, чтобы мы могли проверить действия наших сотрудников по вашим обращениям, а также провести проверку перевозчика и его расписания.
Напомнило:
habr.com/ru/post/369777
британские энергетики вынуждены смотреть «Би-Би-Си» и срочно корректировать запросы энергосети. По окончании передач, которые не прерываются рекламой, британцы немедленно включают электрочайники и открывают холодильники. Явление получило название TV pickup.
habr.com/ru/post/369777
Полнотекстовый поиск в mysql — это провал.
Это легаси. Когда-то это было оправданно, сейчас переросли и отказываемся от него в пользу более подходящего решения.
Полнотекстовый поиск в mysql — это провал.
А можно подробнее? Что с ним не так?
Моя история успеха
От себя скажу, что реализация json_arrayagg в Маше провал: в случае пустого множества возвращается не NULL или строка "[]" (пустой JSON массив), а строка "[null]"
rdaemon а что по осям ординат на графиках то? время ответа, кол-во запросов?
Нагрузочное тестирование могло бы помочь?
Не особо — мы знали, что х2 выдержим, а больше не ожидалось по бизнес показателям. Обычно под ожидаемый рост заранее мощностей добавляем. А тут такой Black Swan очередной прилетел
Ну и нагрузочное тестирование на 99% не отловило бы «кривой» state с незакрытыми коннекшнами на proxysql
Наверное, это на 99% было неправильное тестирование.
Возможно ) Но я очень плохо представляю, как его можно было бы устроить, чтобы оно это поймало. Для полного воспроизведения ситуации нам нужно было бы в один из прогонов произвести на стенде те же манипуляции, которые мы делали на проде за неделю до дня X (из-за которых коннекшны подвисли). И тогда следующий прогон дал бы искомый результат. Но вот как сообразить заранее в тест-планы вписать эту первую манипуляцию — не представляю.
Вы в облаке живете или много свободного железа? Не очень понял, куда вы наливать начали софт под нагрузкой?
А можно еще нейронные сетки и прогнозирующий алгоритм прикрутить, и будет предупреждать чуть раньше чем сам можешь достоверно убедится визуально.
И как бы они справились в данном случае? Или кормить в сетку все текущие новости, чтобы сетка по ним пыталась понять, будет ли новый трафик?
Что-либо качественно прогнозировать по новостям это пока не делается, пока не изобрели, насколько я знаю. Я же подразумеваю, что какая-либо новость имеет инерцию, что она не сразу в полной степени отражается на всем, на что она может влиять.
Скажем в статье, график отнюдь не моментально уходит в пик. И по начинающемуся подьему можно предугадать тенденцию, что оно дальше будет расти. Но опять же, не всякий начинающийся подъем будет расти дальше, или угадать и на сколько именно. И не всякая новость начинает действовать от момента объявления, может и раньше.
Можно элементарно из графика по подобию отрезков смотреть какому варианту событий предшествует текущий момент, с каким разбросом (дисперсией) может развиваться ситуация. Вариантов анализа много, и текущий график вероятно прогнозируем, это не форексовские графики, где сами люди пытаются обмануть график.
В случае достижения заранее определенных границ, высылать оповещение ответственным лицам, это что бы не нужно было мониторить ситуацию ежеминутно уткнувшись в это дело. Возможно предупреждения и сейчас высылаются, но это позволит чуть пораньше среагировать.
Любое прогнозирование, самим человеком или компьютеризированное, это возможность среагировать пораньше, и на сколько пораньше, это как раз зависит от качества прогнозирования. Вопрос лишь в целесобразности таких средств.
Скажем в статье, график отнюдь не моментально уходит в пик. И по начинающемуся подьему можно предугадать тенденцию, что оно дальше будет расти. Но опять же, не всякий начинающийся подъем будет расти дальше, или угадать и на сколько именно. И не всякая новость начинает действовать от момента объявления, может и раньше.
Можно элементарно из графика по подобию отрезков смотреть какому варианту событий предшествует текущий момент, с каким разбросом (дисперсией) может развиваться ситуация. Вариантов анализа много, и текущий график вероятно прогнозируем, это не форексовские графики, где сами люди пытаются обмануть график.
В случае достижения заранее определенных границ, высылать оповещение ответственным лицам, это что бы не нужно было мониторить ситуацию ежеминутно уткнувшись в это дело. Возможно предупреждения и сейчас высылаются, но это позволит чуть пораньше среагировать.
Любое прогнозирование, самим человеком или компьютеризированное, это возможность среагировать пораньше, и на сколько пораньше, это как раз зависит от качества прогнозирования. Вопрос лишь в целесобразности таких средств.
А потом вы прикручиваете эту штуку к бирже и делаете миллион процентов в неделю? по вашей логике мир новостей детерминирован )
По крайней мере не является абсолютно стохастическим. Кому-то нравится запускать сервера и сервисы, и как следствие такие в этом разбираются. А кому-то нравится считать вероятности.
Только я не понимаю, почему Вы хотите именно новости ловить? Если Вы видите расходящиеся круги на воде, Вам совсем не обязательно было видеть куда упало, что бы знать где оно примерно упало. И совсем не обязательно знать что именно упало, и после еще дожидаться когда они дойдут до точки Х, что бы знать, что они до точки Х дойдут. Особенно если есть возможность померить и посчитать.
Только я не понимаю, почему Вы хотите именно новости ловить? Если Вы видите расходящиеся круги на воде, Вам совсем не обязательно было видеть куда упало, что бы знать где оно примерно упало. И совсем не обязательно знать что именно упало, и после еще дожидаться когда они дойдут до точки Х, что бы знать, что они до точки Х дойдут. Особенно если есть возможность померить и посчитать.
Спасибо за статью. Было интересно. Круто когда компания не стесняется писать о своих недостатках. Вы молодцы.
Как по мне, редкие факапы, которые успешно разгребаются — не недостаток, а достоинство. Потому что сломаться может что угодно и у кого угодно, но если ломается редко, значит обслуживают хорошо. Ну а уж когда сломалось, а его под все растущей нагрузкой починили, то это уж совсем очевидное достоинство.
«наш ДБА, вывел реплику из-под нагрузки, прибил долгоживущие процессы и выполнил стандартную процедуру оптимизации таблиц».
Мне одному кажется, что истории из серии прибить долгие запросы в БД и сделать оптимизацию — должно быть делом рук службы мониторинга/дежурных админов и/или вообще какой-то автоматизации?
А роль ДБА — предотвращать в т.ч. ситуации с долгими запросами.
Мне одному кажется, что истории из серии прибить долгие запросы в БД и сделать оптимизацию — должно быть делом рук службы мониторинга/дежурных админов и/или вообще какой-то автоматизации?
А роль ДБА — предотвращать в т.ч. ситуации с долгими запросами.
Вот это очень хорошие вопросы и достаточно сложная тема.
Написать автоматику, которая бы прибивала только «вредные» долгие запросы, при этом не трогая те, которые долго работают ожидаемо, не очень тривиально. Написать что-то простое для использования во время подобных сбоев — можно, но пользы от этого будет не очень много.
Про процессы и людей. Мы пробовали жить с выделенной второй линией, которая как раз обрабатывала поток сервис-деска, что-то автоматизировала, что-то чинила вручную. Не зашло. Сейчас админы сами дежурят, сами автоматизируют, сами настраивают мониторинг и следят за ним. Все это, как мне кажется, стимулирует изначально делать более надежные системы, потому что все ошибки прилетают тебе же и это прям идеальный вариант обратной связи. У такого подхода есть свои недостатки, он наверняка применим далеко не в каждой команде и не в каждой компании, но нам сейчас норм
Написать автоматику, которая бы прибивала только «вредные» долгие запросы, при этом не трогая те, которые долго работают ожидаемо, не очень тривиально. Написать что-то простое для использования во время подобных сбоев — можно, но пользы от этого будет не очень много.
Про процессы и людей. Мы пробовали жить с выделенной второй линией, которая как раз обрабатывала поток сервис-деска, что-то автоматизировала, что-то чинила вручную. Не зашло. Сейчас админы сами дежурят, сами автоматизируют, сами настраивают мониторинг и следят за ним. Все это, как мне кажется, стимулирует изначально делать более надежные системы, потому что все ошибки прилетают тебе же и это прям идеальный вариант обратной связи. У такого подхода есть свои недостатки, он наверняка применим далеко не в каждой команде и не в каждой компании, но нам сейчас норм
Мы пробовали жить с выделенной второй линией, которая как раз обрабатывала поток сервис-деска, что-то автоматизировала, что-то чинила вручную. Не зашло.
А можно про это подробнее? Я помню, на эту вторую линию подавалось много надежд, когда АБ её возглавил, но что же случилось потом?
Привет) Ниже — исключительно про команду, не про компанию в целом, у нас все-таки специфика.
Вторая линия помогла перенастроить мониторинг и автоматизацию и в этом она надежды оправдала. Но потом с выделенной второй линией получалось, что система отдельно у админов, а мониторинг и автоматизация той же системы — отдельно, у саппорта. Эффективно взаимодействовать получалось не всегда, обмен знаниями в обе стороны был достаточно ограниченным. Кроме того, были проблемы с приоритизацией, когда что-то было нужно друг от друга, ощущение единой команды тоже то было то нет. Ну и у ребят из саппорта было непонимание куда и как расти и развиваться.
В итоге через достаточно тяжелый для всех период пришли к «you build it, you run it» и по ощущениям стало сильно проще. Наверное, все проблемы, о которых я писал выше, тоже можно было бы решить как-то иначе, без смены подхода. Но пока кажется, что этот переход был удачным — летаем так уже больше двух лет и желания вернуться не возникало.
Вторая линия помогла перенастроить мониторинг и автоматизацию и в этом она надежды оправдала. Но потом с выделенной второй линией получалось, что система отдельно у админов, а мониторинг и автоматизация той же системы — отдельно, у саппорта. Эффективно взаимодействовать получалось не всегда, обмен знаниями в обе стороны был достаточно ограниченным. Кроме того, были проблемы с приоритизацией, когда что-то было нужно друг от друга, ощущение единой команды тоже то было то нет. Ну и у ребят из саппорта было непонимание куда и как расти и развиваться.
В итоге через достаточно тяжелый для всех период пришли к «you build it, you run it» и по ощущениям стало сильно проще. Наверное, все проблемы, о которых я писал выше, тоже можно было бы решить как-то иначе, без смены подхода. Но пока кажется, что этот переход был удачным — летаем так уже больше двух лет и желания вернуться не возникало.
Привет-привет :)
пришли к «you build it, you run it»
Ясно. С повальной докеризацией и serverless замечаю тенденцию, что админов в компании может вообще не быть. Зачем платить зарплату человеку, которого может заменить AWS или просто достаточно рукастый разработчик, чтобы поддерживать супервизор в свободное от разработки время? Но это с оговоркой, что я сужу по ситуации в "столице стартапов" (Берлин).
Не очень понятно зачем вам полнотекстовый поиск в его классическом понимании и тем более в mysql. Он просто обязан был навернуться.
Вроде поиск самих билетов — вполне себе параметрический, да и саджестам обычный полнотекст сдался, как рыбе зонтик. Может в «приключениях» он еще хоть как-то оправдан, но там нагрузки не должно быть. Хм.
Вроде поиск самих билетов — вполне себе параметрический, да и саджестам обычный полнотекст сдался, как рыбе зонтик. Может в «приключениях» он еще хоть как-то оправдан, но там нагрузки не должно быть. Хм.
Sign up to leave a comment.
Как новость про +4 выходных дня уронила нам базу данных