Как я поменял профессию: из тканевой инженерии в adult-индустрию
Если ты DevOps, который работает с adult-проектами, то твой типичный «взрослый контент» будет выглядеть примерно так
Одна из самых традиционных тем на Хабре — это внезапные карьерные перемещения из различных профессий в IT и обратно. У меня, вот, чудесный коллега — профессиональный мясник с соответствующим образованием. Мониторинг настраивает как боженька и умеет убедительно отстаивать свою точку зрения. Образование позволяет.
Меня тоже можете принимать в свои ряды людей со странной сменой профессии. Как многие помнят по моим старым постам — я изначально врач, который свернул в направлении фундаментальной науки и тканевой инженерии. Все вот эти развлечения со стволовыми клетками, выращиванием органов в биореакторах и прочими нетиповыми экспериментальными задачами. И вот тут меня внезапно позвали на собеседование в крупный телеком… Короче, очнулся я уже будучи DevOps в компании, которая занимается сложными проектами, некоторые из которых про adult-видео. Ну вот те самые специальные обучающие фильмы для взрослых, которые двигатель прогресса. С петабайтами отданного трафика, набегами миллионов пользователей и прочими радостями.
Работает у нас это примерно так — у бизнеса наступает момент, когда приходит осознание, что все. Приехали. Инфраструктура работает, вроде бы все в порядке, но построена на костылях, которые заботливо укладывали три поколения сотрудников назад. Документации нет, как все это работает — никто не помнит. Если сервер сдохнет, воскресить в случае чего никто не сможет.
И вот где-то в этот момент обычно появляемся мы с командой WiseOps и начинаем перебирать по винтику все археологические слои кода, архитектуры и бизнес-логики. У нас уже есть несколько десятков клиентов и три из них про видеоконтент.
Предлагаю перейти под кат, а я попробую рассказать, как выглядит вся эта индустрия глазами врача/био-инженера/DevOps.
Научный бэкграунд помогает
Первые несколько месяцев после смены профессии учиться приходилось еще интенсивнее, чем перед экзаменом по оперативной хирургии. А он был тем еще квестом, поверьте. В целом, это неизбежно, если берешь 12 лет обучения основной профессии с последипломным обучением, аспирантурой, и торжественно утилизируешь недописанную диссертацию. Это был невероятно крутой опыт, который постоянно помогает мне в жизни, но я понял, что важно вовремя зафиксировать убытки. Именно на этом этапе сталкиваешься с типичным когнитивным искажением — ошибкой невозвратных затрат. Можно воспринимать все годы потраченные на «прокачку персонажа в другой ветке» как бесполезные, а можно попробовать воспользоваться этим опытом под другим углом.
Эксперимент в процессе — взяли и отключили целый регион
Очень быстро у меня возникло ощущение, что при правильном подходе я продолжаю заниматься той же научной деятельностью, но с другими задачами. Ключевой подход в науке звучит примерно так:
Разработай гипотезу
Честно придумай метод, который ее опровергнет
Проведи эксперименты
Выступи с плакатиком на конференции
Как оказалось, те же самые подходы прекрасно ложатся и на обычный для IT-workflow. Даже с плакатиком можно выступить. Например, прилетает задача — нужно увеличить отказоустойчивость регионального кластера. Кластер состоит из балансировщиков, application-нод, узлов sphinx (SQL Phrase Index) и кешей. Нужно нарастить число машин, но непонятно как это сделать правильно. Исторически у клиента добавление мощностей происходило эмпирически. И вот тут ты садишься и начинаешь рисовать список гипотез и собирать данные:
Как декомпозировать нагрузку на отдельные бутылочные горлышки?
Можно ли описать единой моделью идеальное соотношение ужа с ежом ядер vCPU узлов Sphinx и объем RAM на кеширующих серверах?
Точно ли есть смысл добавлять кеш выше определенного порога или он уходит в насыщение?
Короче, говоря, моя любимая работа в обстановке полной неопределенности и разработки оптимизаций для вещей, которые эмпирически сложились, но точного рецепта этой магии ни у кого нет. И стандартного подхода может не быть, так как велосипед уникален. Только вместо набора пробирок с разной концентрацией реагента и стволовыми клетками у меня кластеры по всему миру, а вместо стандартного эксперимента — нагрузочные тесты с отключением целых континентов на короткое время. Зависимость мы в итоге тогда нашли, а модель у меня получилось построить, обвешав ее поправочными коэффициентами на мощность vCPU на серверах разных поколений.
Также оказался крайне актуальным еще один момент, который является стандартом в научных исследованиях, но не всегда используется в IT. Эксперименты нужно ставить не только позитивные, но и негативные.
Например, стоит задача тестирования влияния новой версии API на одну из подсистем, чтобы убедиться в ее работоспособности. Неправильный вариант выглядит так:
Обновляем код API в окружении тестируемого сервиса.
Убеждаемся, что все работает
Празднуем успешный деплой
Правильный вариант:
Выполняем все шаги из неправильного.
Отключаем/ломаем API, чтобы убедиться, что система прекращает работать.
В одной из задач я так внезапно выяснил, что подсистема клиента продолжает работать даже при сломанном API. Оказалось, что она его просто не использует, хотя это ожидалось, исходя из документации.
Все становится веселее, когда данных петабайты
Мониторинг падает громче, чем обычно
На самом деле в индустрии специального видео DevOps делает все то же самое, но веселее. Нагрузки выше, а задачи иногда весьма неожиданны. Когда трафик у твоего клиента начинает превышать петабайтную отметку, многие привычные подходы начинают работать совсем иначе. Так, например, внезапно может выясниться, что из-за стечения множества факторов и неудачно моргнувшей связности между датацентрами сотни инстансов начинают лить в ваш Graylog жалобы на то, что они ног API не чувствуют. Гигабайтами. А следом идет целый каскад:
Datadog — внешняя облачная система мониторинга — начинает спасать уже свои инстансы, включая избирательно ограничивая пропускную способность запросов к своему API. Мониторинг начинает весело тупить и реагировать на все с большой задержкой. Дежурный пытается заглушить активные алерты, а Datadog заботливо ставит запросы на mute в длинную очередь.
Во все мессенджеры сыпятся тысячи писем от различных ботов, graylog и системы мониторинга. Звук на десктопе просто выключается, так как тихие одиночные щелчки о новых сообщениях превращаются в непрерывный треск дозиметра в активной зоне реактора.
Приложение OpsGenie от Atlassian очень помогает с оповещением дежурных об авариях. Проблема в том, что в этом случае оно тоже ложится под нагрузкой. Хуже того, оно начинает эскалировать все аварии следующему по списку сотруднику, если предыдущие не дежурный не взял в работу. А он не может, так как API моргает и икает.
Короче, в итоге для меня это выглядело как 3500 пуш-сообщений от системы мониторинга. Любые попытки заставить его замолчать безрезультатны, верхняя часть экрана не откликается из-за того, что пуши сыплются по несколько штук в секунду. Приложение умеет управлять громкостью и следит за тем, чтобы сирена сработала на каждую входящую аварию, даже если несознательный пользователь пытается выключить звук.
В реальности один из probe-узлов, с которого происходит проверка работоспособности HTTP-эндпойнтов, просто потерял связность и бодро отправил в Datadog пачку сообщений о том, что нескольких датацентров с сотнями эндпойнтов больше нет. Возможно, метеорит.
Мониторинг там специфичный, с алертами на каждую из сотен существующих связей.
Оповещение об алертах мы в итоге пересмотрели. Спасибо внезапному нагрузочному тестированию.
Клиенты жалуются, что камера трясется
В отличие от стандартных сервисов, adult-ресурсы подчиняются не только требованиям DMCA, но и ряду других ограничений. Жалобы пользователя на то, что он увидел себя на видео, на которое не давал разрешение, должны отрабатываться в течение нескольких часов. При этом, жалобы могут поступать по десяткам каналов — в CloudFlare, регистратору доменов, в обратную связь на сайте, провайдеру инфраструктуры и еще куче других мест.
Я как раз помогал внедрить систему обратной связи для того, чтобы пользователь мог отправить жалобу. В итоге, при пилотном тестировании мы обнаружили, что довольно значимый процент людей жалуется не на то, что мы думали, а про «камера трясется», «свет плохо поставлен» или дают рекомендации это сделали бы они, если бы сами там снимались. Насколько я знаю, всем стараются ответить по мере возможности. Тут почти как с письмом Санта-Клаусу, если клиент из любой точки мира написал, то надо ему помочь.
Отрасль консервативная, но иногда просят странное
Очень часто приходится реализовывать для клиента нестандартные варианты. Отрасль, с одной стороны, крайне консервативная и в ядре системы может работать старый, но надежный PHP-код. С другой, все это может быть тесно интегрировано со вполне современным стеком и постоянно меняющимися требованиями.
Например, у меня была задача по бутстрапу железных серверов, выступающих как точка раздачи контента. Каждая группа узлов содержит несколько сотен тысяч файлов, которые активно раздаются и кешируются через CDN. Проблема возникает тогда, когда внезапно возникает острая нехватка мощностей и нужно добавить еще один сервер в группу. Соседи и так перегружены, а нам нужно склонировать с них терабайты данных для нового узла. В итоге, мы тестировали вариант использования torrent-синхронизации для сбалансированной доставки контента на новый сервер при бутстрапе. Об этом расскажу в следующих постах.
Потом в другой проект пришла задача по исследованию LLM-трансформеров с image-to-text возможностями. И вот мы уже собираем для заказчика более сложные каскады из систем автоматического описания кадра, перевода, разметки тегов и прочих вещей, которые должны интегрироваться с легаси-системами.
Контента DevOps не касаются. Почти.
Кто-то видит лишь бегущие строки деплоя конфигурации и поток зеленых символов. Мы видим женщину в красном. Ну или что-то еще.
В целом, задачи нашей группы почти не связаны непосредственно с самим контентом. Несколько мониторов, на одном репозиторий с Ansible конфигурацией, на другом консоль, где настраивается интеграция Hashicorp Vault с Terraform.
Веселее, когда в рамках задачи нужно работать с контентом непосредственно. Скриншоты для превью у клиента обрабатывались относительно простым OpenCV с каскадами Хаара. Когда объемы начали нарастать, решили перейти к более продвинутой автоматической обработке скриншотов с выбраковкой, обрезкой и увеличением резкости на GPU с нейросетками. Я очень сильно удивлялся, насколько у людей богатая фантазия и вкусы, когда собирал тестовый датасет на несколько тысяч изображений. Зато теперь скриншоты красивые.
Провайдер может внезапно вас отключить
Сейчас мы работаем с множеством заказчиков из разных областей. Но наш adult-бэкграунд научил нас здоровой паранойе. В силу специфики направления заказчиков мы привыкли к тому, что любой IP адрес могут отобрать, домен разделегировать, а инфраструктуру отключить от сети в течение нескольких часов. Разумеется, весь подобный бизнес максимально соблюдает все ограничения и законы как региона регистрации, так и расположения датацентров.
Мне было сложно привыкнуть к тому, что жалоба на контент клиента должна отрабатываться в течение считанных часов. Сидишь ты такой, неторопливо препарируешь плохо описанный модуль на Go, и тут мониторинг бодро сообщает, что куска кластера у вас больше нет. А в почте письмо от провайдера вида «уважаемый клиент, по невнятным причинам, пункту 184.a и вчерашнему изменению политики обслуживания, ваш контракт приостановлен».
За несколько лет подобного опыта мы перешли к концепции zero-trust применительно к поставщикам услуг. Сервис должен продолжать работать несмотря на бан доменных имен в CloudFlare, блокировку IP-адресов, полную блокировку арендованных мощностей и других действий со стороны провайдеров. Infrastructure-as-a-code подход позволяет как быстрое развертывание продуктивных мощностей у нескольких провайдеров, так и экстренную аварийную миграцию на заранее подготовленные временные DRP-площадки. Также помогает изначальное проектирование архитектуры с дублированием задач между несколькими провайдерами.
Время от времени мы устраиваем репетиции и что-то красиво ломаем в самом ответственном месте. Если все спроектировано корректно, то ни один Хорхе Марио из Аргентины не должен заметить ухудшения в качестве сервиса в момент переключения. Социальная ответственность, все-таки.
Археология — это нормально
Есть довольно неприятный по последствиям для бизнеса подход «а давайте все сожжем и построим модное и красивое в Kubernetes». На моей памяти такие вещи вместе с «давайте все перетащим в облако» приводили к очень неоднозначным результатам. Так, например, я знаю как минимум одну компанию, которая решила сэкономить на аренде серверов и DBA с помощью отказа от «устаревшего» подхода в пользу AWS. Теперь у них ежемесячно улетает пятизначная сумма только на оплату облачных мощностей. Сильно надежнее при этом, что характерно, не стало. Дешевле тоже.
Мы же скорее стараемся сохранить то, что приносит бизнесу деньги, даже если оно выглядит как окаменелость среди современного стека. Так, я занимался задачей по переносу вручную настроенных сервисов в Ansible/Terraform/Packer и мы с коллегой наткнулись на странный бинарник на чистом C, который что-то упорно молча молотит и логов наружу не отдает. Исходников нет, но есть смутные воспоминания старожилов заказчика о том, что это что-то очень важное. Согласовали краткосрочную симуляцию отказа сервиса. Как только бинарник прекратил работу, начали выть вообще все метрики резко упавшей нагрузки, так как он, как оказалось, управлял всем рекламным трафиком на какой-то платформе.
Как позже выяснилось, это низкоуровневое творение сумрачного гения уже пытались переделать на более современный стек. В итоге, оно работало раз в 10 медленнее и жрало в несколько раз больше ресурсов.
Решили так и оставить. Автоматизировали создание узлов, подняли несколько инстансов для отказоустойчивости, описали в документации с DRP и повесили для будущих поколений табличку «не влезай — убьет». Черный легаси-ящик. Жужжит, работает, приносит деньги.
Профессию менять легко (нет)
Менять профессию всегда тяжело. Что бы там ни говорили на многочисленных курсах, вам потребуется не один год, чтобы стать профессионалом на новом месте. Первые годы придется учиться втрое интенсивнее, чем остальным, развивавшим все это время те же самые скиллы.
Все это совершенно не значит, что весь предыдущий опыт бесполезен. В качестве хобби обвешал полдома датчиками влажности, температуры и прочей автоматикой с агрегацией всех логов? Будет намного проще понять RabbitMQ в рабочей ситуации. Анализировал большие объемы сырых данных в поисках скрытых корреляций в научной сфере? В IT тебе отсыпят не меньший объем для анализа. У меня все коллеги — потрясающие, талантливые люди с самым разным бэкграундом и хобби. Главное, чтобы рабочие задачи вызывали ощущение очередного вызова и заставляли глаза светиться.
Так что, в целом, менять профессию сложно, но весело. Особенно, когда рассказываешь в новой компании про свой карьерный путь из медицины и науки в кровавый энтерпрайз и далее. На последнем этапе я обычно делаю многозначительную паузу и неторопливо пью чай, пока окружающие пытаются сохранить серьезное лицо. Через пару минут от женской половины аудитории уже начинаются робкие просьбы о получении автографа известного астронавта Джонни Синса.
Так что да — мне нравится новое направление. Миллионы посетителей, которые набегают и тащат петабайтами видео. Добрые поисковые боты, которые создают нагрузку и которых приходится терпеть. Злые азиатские боты, которые пытаются клонировать контент и паразитировать на ресурсах заказчика. Совсем нехорошие люди, которые устраивают DDoS, атакуя по наиболее болезненным участкам, вызывая перегрузку бэкенда.
Наша команда тоже решила в итоге двигаться дальше и менять узкий профиль, чтобы помочь и другим клиентам сделать их архитектуру прозрачнее, а технический долг меньше. Накопленный опыт позволяет.
Поэтому, если будет нужно провести аудит и поручить нам заботы об инфраструктуре — загляните сюда. Мы поможем. А я вернусь чуть позже, чтобы рассказать, про то, что интересного мы строим на работе.
