Триатлон S03E01

На прошлых выходных открыл сезон. Гонка была формата спринт (400+20+5), проходила в Лужниках. Погода не подвела, а организация была, как всегда, на высоте. Мне вообще нравится формат сити триатлона. Когда никуда не надо ехать, а можно проснуться и через час проверять велик в транзитке.

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

Фан фэкт, за последние пол года, я нормально тренировался один месяц в Бишкеке. Не плавал я 3 месяца и это сразу стало видно. Темп на плавании увеличился на 30 сек на 100 метров. Велик я тоже не крутил 3 месяца. Но перфоманс на велоэтапе упал не сильно, можно списать на другие факторы (было достаточно холодно и ветрено).

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

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

P.S.: Если хочешь попробовать триатлон, но вся эта затея кажется сложной, попробуй короткий сити-триатлон. Например серия гонок Гром или старт в Крыласком отличные варианты для начала !

#sport #health

Безопасность docker образов 👩‍💻

Недавно на работе появилось новое развлечение (таск с приоритетом asap) - сканирование докер образов для поиска уязвимостей. Уязвимости ищутся в списке CVE, это по сути база данных со всеми известными уязвимостями информационной безопасности. И конечно же в каждом нашем пайтон образе было 190+ проблем с уровнями от critical до low. Надо было что-то сделать, чтобы пропали уязвимости уровня high и critical.

Смотрю как собирается базовый образ самого свежего пайтона в докере. Собирается он на основе debian 11. В этом релизе сохраняется большая часть критичных уязвимостей. Выходит что пайтон образами пользоваться не выйдет. Пум-пум, какие вариантики есть ещё 😵‍💫

Есть образы с тэгом alpine. Это легкие, очень минималистичные сборки, в которых больше внимания уделяется безопасности. Пытаюсь собрать свое код, построенный на вычислениях, на таком образе. Иии, ничего не выходит 🧐 Потому что альпайн хорош для простого пайтон скриптинга, но как только тебе понадобится выполнить более сложный код с пакетами типа scipy, numpy или cvxpy, скорее всего сделать это не получится. Система просто не предназначена для этого.

Остается один вариант - брать голый ubuntu образ и собирать его под свои требования. Процесс собственно не очень сложный, особенно если пользуешься ubuntu как основной операционкой. Рецепт прост - последний релиз, полный апгрейд системных пакетов, установка нужного пайтона 👨‍💻 А дальше все как обычно.

Собрал, пушу в репозиторий, жду пока прокатится пайплайн. Открываю лог, а уязвимостей не найдено. Вообще ни одной ! Салют, фанфары, коллеги спрашивают как собрать такой же образ, я открываю шампанское 🎆🪩🎉🥂

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

P.S.: Мне эта история нравится с технической точки зрения. Типа, как можно пожонглировать технологиями так, чтобы твое решение стало более безопасно и более расширяемо🤹 Наверное надо написать заметку в блог про это

#insight #dev

Безопасность докер контейнеров №2 🐳

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

Если сильно упрощать, то докер контейнер это своего рода виртуальная операционная система, изолированная от системы в которой контейнер запускается. Как и у любой ОС, в докер контейнере тоже есть пользователи, группы пользователей и разные права доступа к системе.

По умолчанию, контейнер запускается с root правами. Эти права позволяют контролировать все процессы запущенные в контейнере и иметь полный доступ ко всем файлам системы. С одной стороны это удобно, не надо думать над тем, как создавать файлы. Но с другой стороны это не очень безопасно, и вот почему.

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

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

RUN addgroup --gid $GROUP_ID user && \
  adduser --disabled-password --gecos '' --uid $USER_ID --gid $GROUP_ID user
USER user

В аргументы GROUP_ID и USER_ID надо передать номера группы и пользователя.

Ещё хорошо бы убрать у системных исполняемых файлов возможность исполнения от имени владельца. Декодинг такой - находим все файлы с нужными разрешениями и убираем возможности установки битов доступа:

RUN find / -perm /6000 -type f -exec chmod a-s {} \; || true

Это все конечно выглядит не очень просто и понятно для человека, который не использует линукс. Но заботать базовые навыки сисадмина очень полезно, даже если ты занимаешься ML, а тем более разработкой. Эти навыки позволят писать более безопасные и тонко настраиваемые решения ✌🏻👨‍💻

#dev

Персональные данные и личная безопасность 🥷🏻

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

Причиной для написания поста стала статья в NY Times о том, как компании, аффилированные с российским гос сектором, научились анализировать зашифрованный трафик месенджеров. Нет, у них пока нет прямого доступа к чату, но понимать что именно (текст, картинки, голосовые сообщения или видоски) и кому ты отправляешь они уже могут. Очевидно, что если эти технологии есть у гос сектора, то ими могут пользоваться все правоохранительные структуры.

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

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

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

Прочитаем ещё немного новостей и поймем что у ФСБ скоро будет доступ к базам данных аггрегаторов такси. А это опять же твои передвижения и способы их оплаты. Косвенно можно понять как часто и в каких барах ты тусуешься, куда ездишь на массаж и когда возвращаешься домой после ужина с родителями.

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

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

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

Однако очевидно, что работы по автоматизации этого процесса ведутся, а нам остается только ждать когда они будут закончены. До глубины души надеюсь что это будет реализовано не скоро, если будет вообще !

Несмотря на всю мерзость и гадость сложившихся условий с ними можно и нужно бороться. Делать все, что бы твои данные принадлежали именно тебе, а не всем гос структурам страны. Тогда ты, как единица гражданского общества, будешь менее уязвим и более свободен. Расскажу как это можно сделать в следующих постах ✌🏻🌎

Stay anonymous, stay free, stay safe !

#security

Масштабирование продукта 📈

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

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

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

Теперь про инсайт. Инфраструктурное масштабирование продукта это супер важный скилл. Потому что качество продукта определяется, в том числе, удовлетворенностью пользователей. Если при резком увеличении нагрузки будет увеличено время ответа, появится нестабильная работа или невозможность использования фичей, это все приведет к недовольству пользователей. Недовольные пользователи увеличивают отток. Большой отток, сложнее зарабатывать деньги. Невозможность быть прибыльным ведет продукт сначала к стагнации, а потом к смерти.

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

P.S.: И если с сервисами типа AWS, GCP, Azure примерно понятно что делать при росте нагрузок. То как быть со своими железками - не очень. Покупка своих ресурсов требует точного и долгосрочного планирования, которое кажется редко достижимым в стартап среде

#startup #dev

Спроси маму

Дочитал книгу Роба Фитцпатрика - Спроси маму. Небольшая и очень интересная книга о том, как проверять свои бизнес идеи. Мне её рекомендовали знакомые продакты. А ещё, когда то давно, ее рекомендовали менторы из ФРИИ в своем стартап-акселераторе.

Книга маленькая, всего 150 страниц. Текст несложный и главы небольшие по объему. Пару раз встречался с такой историей - большая часть главы описывает одну тему, а в конце, парочка абзацев совсем про другое. И это другое гораздо интереснее чем основная часть. Общую канву это никак не нарушает, даже становится интереснее читать. Очень много живых примеров, благодаря которым можно понять, что имел ввиду автор, когда описывал теоретическую часть.

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

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

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

#book