Жду новый пост

Серия «IT»

Дисклеймер ↓

Этот материал должен был выйти в декабре 2023, прямо перед Новым годом, — и это классический пример про «лучшее враг хорошего». Сначала нам не нравилось, что мало подробностей. Потом — что их излишне много. Была версия с цитатами, но без скринов. Со скринами, но без цитат. Мы записали столько интервью с сетевиками, что сами в них запутались.

Но в итоге сегодня наша статья наконец-то выходит в свет. Из цензуры — только внимательная рука корректора. Передаем слово Максу Яковлеву.

Привет, Пикабу. Меня зовут Максим, я руковожу отделом сетевых инженеров в Таймвебе. Как вы уже поняли из заголовка, речь пойдет про наш прошлогодний DDoS. Это не стандартный постмортем, а скорее история от первого лица. Расскажу и покажу, каково это было изнутри — жить на энергетиках и пересобрать ядро сети всего за пару месяцев.

❯ Некоторое время до

Про Таймвеб вы, скорее всего, знаете. И скорее всего — как про хостинг, работающий по модели shared, с саб-сервисами вроде регистрации доменов, конструктора сайтов и пр. Еще есть облако, выросшее из хостинга, — о нем и пойдет речь.

В 2023 мы начали потихонечку распиливать легаси-сеть хостинга и делать ее похожей на сеть IaaS-провайдера. Но в целом архитектура на момент дня Х была довольно типичной для хостинга: несколько маршрутизаторов, стопка растянутых VLAN, три транзита и пара обменников.

В хостинговом бизнесе объем каналов рассчитывается от объема общего трафика на сеть, плюс запас на случай аварий и атак, обычно не превышающий 10х от трафика в ЧНН. Отсюда выстраивается защита инфраструктуры и клиентов: оценивается максимально ожидаемая совокупная мощность атак, берется небольшой запас и подбираются механизмы противодействия, чтобы и отдельного клиента защитить, и самим при этом не упасть.

Важно понимать, что любой типичный хостинг находится под DDoS-атакой практически 24/7: хоть одного клиента в каждый момент времени да атакуют. Поэтому DDoS для нас — это даже несколько банально. За 17 лет мы повидали много чего и в принципе знаем ключевые (и не только) паттерны, откуда, что, куда и как.

❯ Добрый вечер

14 сентября, ближе к 18:00, в нас влетел очередной DDoS, с которым известно что делать. Отбили — пошли отдыхать. И не успел я допить чай, как атака повторилась, потом опять, а потом еще раз. Каждый раз интервал уменьшался, а объем нарастал.

Далее для любителей краткого изложения перечислю возникшую причинно-следственную связь по инфраструктуре.

В площадку наливается больше, чем та способна переварить → роутеры перегружаются вплоть до потери сигнализации → мы через OOB блокируем атаку через RTBH/FS или переключаем сеть на сторонний центр очистки трафика → цель атаки меняется в течение пяти минут.

Из дополнительных проблем в СПб: аплинки подключены через свитчи с переподпиской, QOS или не работает, или не хватает буфера → разваливается сигнализация. Дополнительно существуют громадные растянутые VLAN, из-за чего атака на одну подсеть затрагивает огромное количество клиентов. Мониторинг и контрмеры работают слишком медленно.

И в остальных локациях: нет своей сети, а ЦОДы нас блочат, защищая свою инфраструктуру. Когда сеть отдается напрямую с железок дата-центра, нет не то что возможности заблокировать атаку, затруднена даже идентификация паттерна: раз — и ноды отвалились. Из доступной информации только триггер в Заббиксе. Самые печальные моменты — когда у нас сутками лежало несколько локаций целиком и наглухо. Даже аплинки наших провайдеров в дата-центрах просто говорили, что мы не готовы это фильтровать, поэтому мы вас отключаем. Как атаки прекратятся, подключим обратно.

❯ Мы накидываем план

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

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

И стратегически: построить свои сети во всех локациях. И собственную защиту.

В первую очередь отказываемся от существующей системы подавления DDoS, потому что она приносит больше вреда, чем пользы. Сетевики начинают спать по очереди, текущий flow-мониторинг меняем на семплированный Inline IPFIX с payload-ом. Таким образом не ждем, пока соберется поток, и принимаем решения за секунды. Этот шаг помог уменьшить среднее время обнаружения каждой атаки: чтобы понять, что она началась и как нужно действовать, нам сначала нужна была пара минут, чуть позже — 15 секунд, а сейчас автоматика реагирует почти мгновенно.

Изначально управление было ручным, чуть позже принятие решений стало автоматизированным: мониторинг научился блокировать DDoS сразу же после обнаружения. В итоге за период с 14 по 20 сентября мы заблокировали более 20 тысяч отдельных паттернов.

В это время по всем каналам — в телеге, в соцсетях, в тикетах — клиенты переживали, ругались и задавали вопросы. И я их прекрасно понимаю. Кстати, о прекрасном:

Дорабатываем защиту: делаем ее быстрее, технологичнее, чтобы принимала максимально правильные решения. Разбираем всю старую архитектуру и избыточные куски сети — все под нагрузкой и идущими атаками и так, чтобы воздействие на клиентов было минимальным.
Примерно в это же время атакующие понимают, что мы что-то сделали, поэтому меняют паттерны. Мы стали получать мощные краткосрочные волны трафика, на которые не успевала реагировать ни наша программа, ни большинство предлагаемых на рынке защит: заливало настолько разнообразно и быстро, что наши стыки и некоторые обменники начали складывать в нас сессии по prefix-limit. В эти периоды бывало и такое:

❯ Строим свою сеть

Начинаем с Питера. План включал в себя апгрейд маршрутизатора с установкой дополнительных плат и подключение к различным каналам и точкам обмена трафиком. Цель — увеличить пропускную способность: нам нужно было научиться принимать трафик атак и блокировать более точечно, а не просто кидаться блекхолами и снимать префиксы. Кроме того, стало понятно, что объемы атак могут расти и нам нужно будет научиться расширять емкость более оперативно, не проходя весь цикл «найти железо → найти емкость → собрать».

Обычные маршрутизаторы не всегда эффективны для такой деятельности: они обладают слишком сложным и дорогим конвейером обработки трафика, предназначенным для других задач. Исходя из этого мы решили действовать комплексно: помимо расширения каналов и увеличения портовой емкости сервисных и пограничных маршрутизаторов начали внедрять пакетные платформы на базе Juniper PTX. Они хоть и попроще, но в них много дешевых 100G/400G-портов, как раз то, что нам нужно.

Благодаря хорошим отношениям с поставщиками мы смогли быстро найти сетевое оборудование: поставка заняла всего полтора месяца. Для техники такого класса это очень быстро.

В итоге в Питере мы добили емкость по основным направлениям до 500+ гбит, а по автономке у нас сейчас суммарно около терабита. Уже через две недели после этого ситуация в СПб стабилизировалась: емкости хватало, фильтры отрабатывали оперативно. В остальных локациях сеть была арендованная: и в Казахстане, и в Европе. По этой причине параллельно с выравниванием ситуации в Питере у нас появилась новая приоритетная задача: поставить в заграничные локации собственные маршрутизаторы и дотянуться до них из Питера — тянуться решили через M9.

Девятка до сих пор крупнейшая пиринговая точка и сосредоточение телеком-инфраструктуры РФ и СНГ. Кроме основных трасс для всей России, туда же заходят каналы от СНГ — зачастую единственные.

Магистральные каналы между площадками дают несколько преимуществ:

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

2. Возможность предоставлять клиентам дополнительные сервисы в виде каналов связи.

3. Наше управление не развалится никогда, даже если внешние стыки в локации будут забиты под полку.

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

Кстати, с доставкой в Казахстан повезло не с первого раза. На казахской таможне менялся состав — и все встало мертвым грузом. Ситуацию решили творчески: отправили одного из наших сотрудников везти 204. Забавно, что изначально мы собирались отправлять MX104 — довольно старую и давно снятую с поддержки платформу, которой, впрочем, с запасом хватает на нужды этой площадки.

Но из-за ее громоздкости отправили 204 — и теперь в казахстанском ЦОДе у нас стоит платформа, которой хватит на целый машинный зал облака, а не на наши несколько стоек. На память осталась только фотка со стикером из аэропорта Екб:

К декабрю дотянулись и в Европу: теперь у нас есть узлы во Франкфурте и Амстердаме с арендованной магистральной емкостью. Там появились выходы и в интернет — через Tier-1 операторов, и на европейские обменники.

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

Раз уж пошли по локациям, то добавлю, что в этом году запустились и в Москве, в IXcellerate. Это Tier-3 с уникальной системой охлаждения по типу «холодная стена». Я там был на экскурсии — наверное, самое интересное, что я видел в России и СНГ, а поездил я немало. Пиво еще вкусное у них было — тоже плюс 🙂

Москва, кстати, у нас сразу же запустилась с нормальной архитектурой: широкие линки на стойку, 200G до девятки, масштабируемый слой агрегации. По умолчанию даем на все виртуальные серверы по гигабиту в секунду вместо 200 мегабит, на всех дедиках доступно 10G/40G по запросу. В результате, если клиентам это необходимо, мы можем дать гораздо больше емкости, чем могли бы в Петербурге еще полгода назад.

❯ Почему мы не спрятались за подрядчиками

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

Решения по комплексной защите от DDoS, по сути, делятся на два вида: это готовые решения, устанавливающиеся непосредственно на сети компании, и сторонние центры очистки трафика, через которые этот самый трафик нужно пропускать. На тот момент у нас существовали собственные чистилки и был опыт постройки подобных решений. Посоветовавшись с коллегами по цеху, решили двигаться именно по такому сценарию: принимать трафик → очищать большие потоки на уровне сети, привлекая центры очистки в отдельных случаях → заниматься тонкой очисткой с помощью вендорских решений.

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

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

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

❯ Что сейчас

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

Работы еще много: всю эту новообразовавшуюся сеть нужно резервировать и расширять. На М9 мы взяли целую стойку и собираемся ставить шасси MX960 — с большим запасом на будущее. Оно будет выполнять роль магистральной развязки, принимать внешние стыки и выступать ядром сети дата-центров по Москве, у нас там большие планы. Не забываем и про Северную столицу: платформа PTX10003 станет ядром нового узла на Кантемировской («Радуга»), где будет перемыкать магистрали и стыки с внешними сетями, выступая частью инфраструктуры очистки трафика в Санкт-Петербурге.

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

Много работы будет по пирингам: думаем, что скоро мы сделаем прямые подключения к Google, AWS, Azure и другим гиперскейлерам. Хотим организовывать серьезные продуктовые преимущества для наших клиентов: если ваш продукт требует очень хорошей связности с мировыми облаками или у вас мультиклауд — мы сможем обеспечить как хорошую связность по интернету, так и выделенные линии, если потребуется.

Для выделенных серверов по части сети у нас получилось очень интересное предложение. По запросу скорости мы даем вплоть до 100—200 гигабит на сервер, так мало кто умеет. Кроме простого интернета — широкий набор сетевых решений: тут и более-менее стандартные L2/L3 VPN на MPLS, и любые манипуляции с внешней маршрутизацией. Для владельцев своих AS соберем транзит, притянем любую популярную точку обмена трафиком. Для тех, кто хочет ими стать, — поможем выпустить ASN, арендовать или купить сети, анонсировать их в мир.

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

❯ И напоследок — неудобный вопрос от маркетинга

— Почему не начали делать все это раньше, а триггером стало то, что на нас пришла атака?

Расширение в целом планировалось, Таймвеб всегда делал упор на качество сети, но процесс шел постепенно. Исторически мы сфокусировались на нашем центральном хабе в СПб, а стройка в остальных локациях планировалась по мере их расширения.

А почему атаки стали триггером? Все банально. Во-первых, мы поняли, что начали расти сильно быстрее, чем планировали. Стало понятно, что нужно больше емкости, больше сервисов — и не когда-то, а сейчас. Во-вторых, появились новые угрозы, которые не отражаются стандартными средствами. В какой-то момент мы переросли «стандартные» подходы, которые мог бы использовать игрок меньшего размера, — нужно было пилить какой-то кастом или средствами сторонней компании, или самостоятельно. Мы выбрали второе.

Присоединяйтесь к нашему комьюнити в Телеграме — здесь можно общаться с сообществом, задавать вопросы руководителям, гендиректорам и фаундерам, и предлагать идеи ↩

Когда на меня накатывает хандра, я бросаю всё и пилю свой игровой движок. Это неблагодарное занятие, но меня прёт.

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

И вот я тут спустя 5 лет.

Ладно, если быть честным, то я почти не уделял времени разработке, потому что постоянно спотыкался на всяких бесящих меня ошибках: то сериализация не работает с наследованием, то потоки не хотят нормально разделять память, то обновление языка ломало совместимость… Я могу, блин, целую Камасутру написать про соитие с игровым движком. Все эти ошибки сильно демотивируют, потому что хочется уже наконец-то заняться делом, а не ковыряться с байтиками.

Это не моё видео, но оно очень точно передаёт, как у меня происходит разработка:

С другой стороны, конечно, когда эти проблемы решаешь, чувствуешь себя богом и королём жизни, и после этого ты вроде как опять хочешь программировать. И даже кажется, что это была последняя трудность. Ха-ха, наивный!.. Но мне это нравится. Типа как альпинисты идут в гору и страдают, когда можно пойти в бар с друзьями и попить пивко. Каждому своё.

Ну и вот про одну такую ошибку я хотел поговорить. Есть такой движок — ODE (Open Dynamics Engine). Он появился где-то в палеолите, динозавры его накодили, от документации остались только царапины на скалах. Но он работает, он простой в использовании, и у него есть сишные заголовки, поэтому я мог просто написать враппер на Nim и использовать его в своём движке. В Nim вообще ни хрена нету, поэтому канонический способ — это взять какую-нибудь библиотеку из Си, научиться её вызывать, а потом говорить всем, что ты написал крутую программу на Nim.

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

Разумеется, если вы не планируете делать Minecraft, то вам может понадобиться что-то поинтересней, чем кубик. В ODE есть специальный класс Trimesh, который как раз позволяет вам сделать сложную геометрию. Фактически, вы можете создать любое тело из набора треугольников. Типа такого:

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

Я создал треугольник, он успешно отрисовался на сцене, я начал ходить по миру… и обнаружил, что треугольник не в том месте, где нарисован, а где-то непонятно где.

Так и появилась эта дурацкая невидимая стена.

Фактически, я мог ходить по сцене, и где-то я упирался в тот самый треугольник, который вообще-то должен был быть там, где нарисован. Я в принципе даже что-то такое и ожидал, потому что, как я уже где-то писал, только три раза в своей жизни я написал код, который заработал с первого раза. Наверняка я где-то перепутал координату — вместо X передал Y, или наоборот, ну что-нибудь такое. Эти программисты, вы знаете!

Отрисовать этот треугольник я не мог, потому что координаты были правильные, графический движок всё отрисовывал правильно, но вот физический движок как-то неправильно интерпретировал мои правильные данные. Поэтому я стал ходить по миру и пытаться определить очертания этой невидимой стены. В конце концов я её нашёл (она была достаточно странной), и я решил немного подвигать треугольник, чтобы посмотреть, как он влияет на эту стену. Казалось бы, если я просто где-то перепутал координаты, то подвинув треугольник, я немножко подвину эту стену. Но хрен мне там! Стена исчезала и появлялась совершенно случайно, прыгала далеко даже от малейшего изменения координат, и я не мог понять, почему.

И тут я вспомнил эту недалёкую женщину из заЩИТников! Если кто не знает, она сделалась невидимой и решила спрятаться в дожде. Отличный план, надёжный, как швейцарские часы:

Я подумал, что это прям мой случай, и решил полить свою стену дождём, чтобы увидеть её. Дождя у меня не было, зато были кубики, поэтому я создал штук 50 и стал кидать их вниз. При касании стены они к ней прилипали, и я мог видеть её очертания. А когда что-то видишь — отлаживать в разы легче!

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

Если нужно где-то найти таких же неудачников, как я, то самое лучшее место для этого — интернет. И я нашёл его — единственного человека, который отстрадал своё и рассказал об этом. Представляете, в 2006 году у какого-то чувака из Германии пятая точка горела точно так же, как у меня сейчас! Не знаю, что он выкурил (похоже, что исходники), но, ОКАЗЫВЕТСЯ, физический движок ожидает от вас трёхмерные точки, но передавать их надо как четырёхмерный вектор, просто в четвертой координате надо поставить мусор, типа так: [x1, y1, z1, 0, x2, y2, z2, 0, ...]. Скажите, как по const dReal* Vertices я должен понять, что там ждут в гости четырёхмерные вершины?

За что я люблю опенсорс — можно всегда докопаться до истоков всего. Я полез в исходники, и вот что обнаружил.

В 2003 году пришёл Russel Smith и добавил всю эту функциональность с trimesh collisions, в том числе интересующую меня строчку:

Тут всё понятно, потому что в определении чётко говорится, что dVector3 — это четырёхмерный вектор (есть некий шарм в этой логике).

А потом через пару месяцев врывается Erwin Coumans и переписывает так, чтобы тип был непонятен:

И только представьте себе, через 20 лет это изменение находит какого-то чувака (меня), который пишет вообще на другом языке программирования, и заставляет этого чувака гореть в тщетных попытках понять, какого хрена не работает.

Я переписываю код с добавлением четвертой координаты, и все начинает работать.

Такие дела.

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

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

Не только лишь все могут смотреть в будущее, но вы сможете, если подпишетесь на мой уютненький канал Блог Погромиста.

А ещё я держу все свои яйца в одной корзине (в смысле, все проекты у одного облачного провайдера) — Timeweb. Поэтому нагло рекламирую то, чем сам пользуюсь — вэлкам.

Детектив kesn всегда готов помочь!

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

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

❯ Функция не выполняется

Попросил меня как-то клиент отладить его скрипт. Говорит, не работает. Невероятно!

Я, когда клиент говорит, что ничего не работает

Скрипт секретный — ну как, для трейдинга на бирже, и принесёт миллионы денег, конечно же, но только когда заработает без ошибок. Поэтому клиент не пересылает мне его, а запускает screen share и делает, что я ему говорю. То ещё удовольствие, но хозяин-барин — оплата почасовая.

Всё шло хорошо, я потихоньку распутывал кривую логику, говорил как лучше сделать, а потом мы дошли до неё... До функции, которая не выполнялась. То есть буквально, чел вызывает функцию, а она ничего не возвращает и ничего не делает.

Смотрим в содержимое функции. Как и положено, это полотно кода на пару экранов, сходу так и не поймёшь, что она делает. Повсюду return что-то там, ветвления всякие итд. То глупое чувство, когда клиент тебя ждёт, а ты ничо не понимаешь и косплеишь рыбу.

Осложнялось всё тем, что отлаживать через клиента — ну такое. Он может запустить скрипт, но вот отладчик для него - страшное слово, и максимум, на что можно рассчитывать — это поставить print() в нужных местах. Разгадка оказалась проста: где-то в середине функции, там, где это было менее всего заметно, вместо return клиент написал yield. А в питоне yield — это магическое слово, которое превращает функцию в генератор, а все return ... - в как бы raise StopIteration(...), и вместо результата возвращается итератор, и выполнение кода останавливается до следующего обращения... Короче говоря, всего-навсего одним ключевым словом клиент полностью раздолбал логику своей программы. Маэстро!

❯ Как ловить эксепшн из генератора

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

Вот, например, кусок кода:

Тут у меня есть функция cache.apply(), которая берет quota_chunks, делает с ними какой-то вжух-вжух и возвращает новые quota_chunks. Я нарисовал диаграмму, чтобы изобразить этот процесс в более понятной форме.

Иногда случается так, что эта вжух-функция не срабатывает, и тогда, как и положено приличному питон-коду, бросается исключение.

Возможно, раньше эта вжух-функция была действительно функцией, но потом она превратилась в генератор (для большей эффективности). Генераторы всем хороши, кроме одного: они откладывают выполнение кода, и в реальности узнать, когда ваш код выполнится, бывает затруднительно. Вы можете создать генератор, отправить его на вход другому генератору, затем передать это в функцию, и уж тогда где-то внутри этой функции вызовется код.

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

Именно это тут и случилось. Я вызвал этот генератор и проверил, что он отработал без ошибок, но на самом деле генератор отработал совершенно в другом месте — там, где вызывается spy() — и именно там он и упал.

А знаете как я это отловил? В тестах. Поэтому пишите тесты.

❯ Строго по инструкции

Клиенты бывают разные: какие-то умеют немножко в HTML и frontend, а некоторые из наших клиентов умеют в backend. Один из таких клиентов часто сам писал backend логику и давал нам её на проверку, чтобы мы ему исправили баги, а может быть где-то сделали рефакторинг или code review.

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

И вот клиент взял нашу инструкцию и начал следовать тому, что там написано, слово в слово. Надо понимать, что разработчики обычно пытаются понять, что они делают (по крайней мере я на это надеюсь). Соответственно, те, кто читал этот скрипт, понимали, что должно быть сделано, и в случае, если у них, например, вместо pip используется poetry, а вместо apt-get у них pacman (i use arch btw), то они заменяли соответствующие команды.

Клиент же делал всё слово в слово, и он написал нам, потому что на одном из шагов у него случилась проблема. Если быть точнее, у нас в инструкции была описана ветка master, а на гитхабе по умолчанию ветка main, поэтому какая-то команда не находила нужную ветку.

«Изи фикс» — подумал я, созвонился с клиентом объяснил, что нужно делать, и хотел отключаться... когда возникла ещё одна ошибка. Оказывается, в инструкции был косяк, и при выполнении команды шелл делал подстановку, когда видел $SOMETHING — то есть не было экранирования. Мы исправили и это, и буквально через несколько секунд всплыл ещё один косяк. А потом ещё. И ещё.

Где-то через час я сказал клиенту, что пусть он всё бросит и я задеплою всё сам, а потом мы обновим ридми. Было стыдно.

❯ Ответочка

Когда-то я работал на интернет-магазин, и мы заметили, что у нас появляются фейковые заказы каждые утро и вечер. Сначала мы не смекнули, что к чему, но потом поняли фишку: идентификаторы заказа у нас были обычные IDшки из Postgres, поэтому конкурент мог сделать заказ утром (номер заказа 10), сделать заказ вечером (номер заказа 15) и просто вычесть второй номер заказа из первого и получить количество заказов, которые мы получили за день (15 - 10 = 5). Я до сих пор часто нахожу эту ошибку во многих проектах, и примерно могу оценить размер этих проектов.

Эту ошибку легко исправить: достаточно заменить последовательные ID на случайные — например, вместо номера заказа использовать timestamp или UUID.

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

Мой девиз — «кто ищет тот всегда найдёт» (посмотрите мои статьи про уязвимости на хабре - 1, 2). Так и тут, я искал и обнаружил, что конкурент выкладывает розничные прайсы публично, а вот оптовые — только для зарегистрированных и проверенных партнёров. Сам файл он раздаёт nginx'ом с адреса вроде http://some-site.com/files/розничный_прайс.xls. А если так, то, скорее всего, никакой аутентификации при помощи бэкенда для самого файла нет, а значит, можно попробовать найти оптовый прайс.

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

❯ Скрапинг со скоростью света

В одном из моих проектов я использовал api ВКонтакте, чтобы анализировать кожаные мешки. Там не нужна была супер-скорость, поэтому я не полез в async, а просто написал функцию и распараллелил её по потокам при помощи ThreadPoolExecutor.

Программа начала просто летать! Вот как это делают сеньоры! Саенс, бич!

Слева направо: саенс, бич

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

Поэтому если всё работает слишком хорошо, то, возможно, всё очень плохо.

❯ Бог рефакторинга

Пришел ко мне клиент и говорит: Саня, давай позумимся и посмотрим, что-то вебхук отвалился и ничего не принимает.

Ну я такой про себя «опять клиент что-то сломал, бывает», полез туда смотреть. Глядел-глядел, глаз вообще ни за что не цеплялся. Ошибок в sentry не было. Потом нашёл вот такой код:

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

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

И вот я смотрю, а этот код написал... я сам. Вот так я примерно выглядел:

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

❯ Детектив kesn и тайна ssh

Говорят мне как-то: клиент, с которым мы работали год назад, восстал из мертвых, и теперь ему нужно перенести и обновить проект в AWS. Вон там наш девопс написал какие-то скрипты сто лет назад, возьми их и задеплой.

Я человек простой, мне сказали задеплоить — я и задеплою, хоть на AWS, хоть на тапок.

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

Сначала пробую ssh -i ключ root@ip. Не работает. Потом вспоминаю, что юзер в AWS обычно ec2-user, поэтому пробую ssh -i key ec2-user@ip. Не работает. Может, там авторизация не по ключу? Пробую ssh ec2-user@ip. Не работает. Сделал dig, попробовал подключиться не напрямую, а через load balancer. Согласен, тупая затея.

Пошел в дэшборд AWS смотреть настройки файрволла. Вижу два странных айпишника. Очень странно. Беру первый, проверяю геолокацию по ip. По локации понимаю, что это, кажется, статический ip девопса. Какого хрена? У нас же есть бастион, и все соединения должны проходить через него... Проверяю второй ip из файрволла. О, так это же и есть бастион. Ну отлично, теперь делов-то — добавить всю эту конфигурацию с бастионом в .ssh/config, чтобы в будущем было легко подключиться. Лезу в конфиг, а там уже есть эта конфигурация.

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

❯ Ошибка платежа

На sentry прилетел отчёт об ошибке, попросили посмотреть. Стал разбираться. Мой код двухгодичной давности.

Логика была простая: есть намерение клиента платить за подписку, и есть прикрепленная карта клиента. Пока намерение активно, мы пытаемся списывать деньги с карты. Это логично: даже если на карте нет денег, то раз клиент хочет пользоваться сервисом, мы будем пытаться списать до тех пор, пока это не получится. Если клиенту не нужна подписка — он отзывает намерение.

Единственное, что я не учел — что клиент может просто всё забросить, ничего не отменяя. И вот на протяжении года наш сельдерей-разнорабочий (celery worker) запускался, пытался списать у клиента деньги, получал отлуп, жаловался в sentry, и засыпал, чтобы назватра всё повторилось, и так каждый день, без конца и края.

❯ Лёгким движением руки сэкономить кучу денег

Я заметил, что очень часто клиенты могут сэкономить неплохую такую кучу денег, сделав просто какое-то минимальное телодвижение. Вот несколько примеров:

• Чувак хостил видео на aws s3 и раздавал через амазоновский CDN. Выходило $655 в месяц. Потом нашёл BunnyCDN, я перенастроил приложение (заменил где-то 4 строчки минуты за две), и внезапно с новым CDN в месяц стало уходить только $70. Ну не эпично ли за пару строчек кода?

• Клиент платил сотни долларов за жирный инстанс Elasticsearch на AWS. Почему — я хз. Потом он заподозрил неладное. Мы замерили реальную нагрузку и перенесли Elastic на одну из самых дешёвых машин в digital ocean, за которую клиент теперь платит $24 в месяц. Профит!

• У клиента было много файлов на s3, платил он тоже много. Потом перенесли всё на b2, там даже делать почти ничего не надо — у них интерфейс совместим с s3. Получили экономию раза в 4.

❯ От судьбы не уйдёшь

У нас есть шаблон для новых проектов на cookiecutter. Он удобен тем, что если мы что-то меняем в шаблоне, то можем легко обновить проекты клиентов при помощи cruft.

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

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

Прошло много месяцев, и угадайте, кого они наняли, чтобы разрешить все конфликты и залить их ветку в мастер?

Ага, меня.

❯ Детектив kesn и поиски пароля

Настраивал я как-то инстанс elasticsearch. Там была отдельная машина, я на ней с помощью docker разворачивал ElasticSearch. Сначала делал всё в ручном режиме, проверял, потом писал скрипт для автоматизации. Для начала просто запустил сервер без всего, потом начал разбираться с авторизацией.

В эластике есть специальный скрипт — elasticsearch-setup-passwords — он настраивает пароли. Ну я его запустил, он мне выдал списки паролей для apm_system, kibana_system, kibana, logstash_system, beats_system, remote_monitoring_user и, собсна, elastic. И хотя мне показалось, что паролей было слишком мало и вообще-то для приличной поисковой системы их должна быть хотя бы сотня, но пароль для elastic был, я его забил в систему автоматизации и пошёл дальше настраивать. Дальше было SSL — не знаю, почему это не встроено (наверно, потому что если не будет https, то и взламывать elastic будет сложнее, а куда без этого!). Ну я пошёл в гугол и говорю: пацаны, сертификаты для эластика привезли? Когда я заикнулся про letsencrypt, они мне сказали, что у нас тут не загнивающий запад и мы сами сертификаты делаем, свои собственные. Короче, прям на официальной странице лежит огроменный docker-compose.yml, в котором вжух-вжух, сертификаты настраиваются, конфиги генерируются. Я его скопировал, применил, всё заработало, и я добавил это в автоматизацию.

Через несколько дней (когда я ужё наполовину всё забыл) мне вдруг понадобилось всё снести и настроить заново (спасибо, digital ocean, за то, что не умеешь даунскейлить диски!). Я запустил скрипт автоматизации, всё развернулось, и тут я вспомнил, что вроде как пароль генерируется сам и его можно узнать, если запустить elasticsearch-setup-passwords. Ну я полез на машину, чтобы запустить эту команду — а она не работает! Сначала был не тот url инстанса, пришлось узнать, что есть опция --url. Окей, теперь не хочет подключаться, т.к. кастомные сертификаты. Как добавить сертификаты? Прописать их в elasticsearch.yml. Читаю доки и там говорится:

All of these settings can be added to the elasticsearch.yml configuration file, ...

ура! так просто!

... with the exception of the secure settings

ffuuuuuuuuu...

which you add to the Elasticsearch keystore. For more information about creating and updating the Elasticsearch keystore, see Secure settings

Ну я полез читать, что за Elasticsearch keystore и зачем он нужен, и даже прочитал про bootstrap password и keystore passphrase. Мне показалось, что ещё чуть-чуть, и я дойду до чтения про большой взрыв и основы зарождения вселенной, а ведь я просто хотел узнать пароль от эластика!

Тут я бросаю взгяд на docker-compose.yml, и вижу, что там везде мелькает $ELASTIC_PASSWORD, и оказывается всё это время пароль был у меня в настройках и я сам его задавал!

Сказочный... эээ... патруль!

❯ Как дропнуть продакшен-базу

Клиенты любят нанимать фрилансеров или брать сотрудников в штаты, чтобы они работали над фичами — потому что нанимать нашу компанию достаточно накладно >:)

Ну и вот как-то клиент нанял стороннего разработчика, чтобы он перенёс систему поиска с эластика на postgres full-text search. Он сделал это именно так, как делал я лет 7 назад. Следите за руками:

• Огромная ветка с кучей коммитов

• В коммитах смешались изменения в БД и рефакторинг логики нескольких почти не связанных приложений

• Миграции не откатывались

• Тестов не было

• Бэкапов перед деплоем сделано не было (хотя это одна команда)

• Не было переключателя «новая система / старая система», то есть старую систему просто вынесли нафиг и заменили новой

• Не было оговорено временное окно для безопасного деплоя

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

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

Я откатил git revision на сервере на рабочий коммит, а СЕО зашёл в админку Digital Ocean и восстановил снэпшот базы данных, назвав его production-db-backup-Mar-24. Всё запустилось. Из-за использования снэпшота мы потеряли немного новых данных, но ничего критичного.

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

Через много месяцев (да, много историй именно после этого и начинаются) клиент говорит: а чё это за production-backup-Mar-24, давайте её удалим. Как же здорово, что он спросил у нас. Потому что программист клиента на самом деле ничего не починил, а просто свалил в закат, и вся инфра осталась в этом «пофикшенном» состоянии. И база использовалась резервная. Поэтому удалять нужно было сломанную БД с названием production, а рабочей была именно production-backup-Mar-24.

Такие дела.

❯ Детектив kesn и загадочные тормоза

Серьёзно, я уже подумываю написать книгу про похождения детектива kesn'а.

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

Я кэшировал функции, пропускал ненужные фрагменты данных, уменьшал циклы. Сначала стало быстрее, но потом чем больше я отлаживал, тем медленнее код работал. Может, мой рефакторинг упустил какую-то важную деталь, и поэтому я делаю что-то совсем не то? Я начал логгировать и отлаживать даже самые маленькие функции. В конце концов дошло до того, что я, кажется, всерьёз начал задумываться об оптимизации скорости словарей в питоне (sic!), и в то же время моя версия работала медленнее, чем оригинальный код.

Потом до меня допёрло.

Чем больше я добавлял отладочной инфы, тем больше был оверхед. То есть я делал программу быстрее, но отладочная инфа делала программу медленнее.

Ха-ха. Я выключил отладочную инфу, и всё залетало. Ну и дурак!

Если вам понравилась эта статья, то посмотрите вот эту, она тоже весёлая: Погромист. Мои самые эпичные провалы за всю карьеру.

Если вам понравился я лично, как умная и образованная гиена, то вот моя тележка: Блог погромиста

Подпишись на наш блог, чтобы не пропустить новые интересные посты!