В офис красоту подвезли)

HARDWARE

Про тяжелые вычисления.
Например обучение AI моделей требует обработки большого количества данных. Основной батлнек - пропускная способность памяти. Даже если у нас стоит очень мощный чип, но мы не можем обеспечить его данными то он будет простаивать в IO большую часть времени.
Тут влияет даже проектирование платформы данных и обучение, что бы нужные для обучения данные были на тех нодах где будет происходить.
Плюс скорость самой памяти, тут очен зависит скорость RAM и большой обьем кешей чипа. Ну и скорость диска, конечно же.
Поэтому сейчас очень важно смотреть на подсистему памяти, а не только на мозность чипа, иначе дорогой чип ничем не будет выигрывать более дешевому)

CI/CD

Про разные CI/CD системы.
По своей логике они все одинаковые, просто предоставляют разные фичи.
Например сейчас смотрю один проект который работает на bitbucket. Я ни разу с ним не работал, но с опытом гитлаба тут все понятно, просто чуть другой синтаксис.
Тут, как по мне, нужно понимать логику и основные примитивы CI/CD процесса, а с синтаксисом могут помочь нейросети.
Из различий. По тому что я вижу в битбакете любят использовать шаблонные пайплайны которые предоставляет сам битбакет. Как я понял разные вендоры инфры типа aws и яндекс клауда могут предоставлять свои публичные пайплайны под их инфру. В гитлабе такого особо не встречал, все пишут шаблоны сами.
Ну и по ощущениям гитлаб куда более гибкий.

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

И последнее на сегодня)
"Колаба" бостонов и ролинг стонс)
https://www.youtube.com/watch?v=XnZH4izf_rI

PROXY

Как пробрасывать определенный трафик из контейнера через прокси? Разберем на примере апи openai.
Допустим наше приложение расологается в России, но нам нужно делать запросы к моделькам.
Для начала поднимаем иностранный сервер и ставим туда пакет nginx-full, он включает в себя модуль проксирования tcp трафика.
В nginx conf добавляем такой блок:

stream {

    upstream backend {
        server api.openai.com:443;
    }
        server {
        listen 443;
        proxy_pass backend;
        proxy_ssl_server_name on;
        ssl_preread on;
    }

}

Он будет слушать на 443 порту и весь трафик который пришел на него пробрасывать на api.openai.com.
Далее, при старте контейнера указываем ему переписывание hosts для этого домена:

--add-host=api.openai.com=$YOUR_PROXY_IP

Где $YOUR_PROXY_IP это адрес сервера с nginx.

Все, теперь если приложение в контейнере будет обращаться на api.openai.com то все запросы будут идти через прокси.

CLOUD

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

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

HELM

Есть шаблонные хельм чарты которые предоставляют сами вендоры софта.
Например bitnami предоставляет свой регистри с чартами, с свое реализацией софта. Сегодня ставил рабит и редис оттуда.
Когда использовать такие чарты? Когда это небольшой проект где не нужно что то кастомное.
Для таких проектов хватит готовых чартов, которые и так очень хорошо настроены, лучше чем сделают многие на коленке)
Как использовать такие чарты:
- Добавляем репу helm repo add bitnami
- Обновляем кеш helm repo update
- Скачиваем чарт helm pull bitnami/memcached --version 8.0.4
- Делаем install скачанного чарты
Чаще всего все заведется с первого раза, можно сразу начинать пользоваться)

QUESTION

Пара моих любимых вопросов которые задают на собесах.
1. При канареечном релизе мы постепенно переключаем трафик на новую версию. На что ориентироваться при повышение процента трафика? На какие метрики?
2. Есть релизы в которых мы держим новую и старую версию одновременно. Но новая версия может накатить миграцию в БД которуа сломает старую версию. Что делать?
3. Есть сервер с постгрей. В нормальном режиме диск потребляется на 30%. Но начались волны потребления, пару раз в день диск забивается до 100 процентов и возвращается к 30. В чем может быть проблема и что делать?

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

MIGRATE

Несколько вариантов запуска миграций при релизах, от простых к сложным:
1. Запускать при старте приложения, либо как часть запуска либо отдельной командой.
2. Контейнер с миграциями. Собираем их в образ и стартуем как обычное приложение.
3. Из CI/CD процесса, просто отдельная job которая подрубается к бд и катит туда миграции.
4. K8s job. Кубовый обьект который запускает образ с миграциями перед релизом.

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

NET BALANCER

Для чего используются сетевые балансировщики? Чаще всего что бы скрыть внутреннию инфру и распределять нагрузку.
Как пример - ингрес на куб кластере. По дефолту мы можем просто открыть в интернет все ноды и прописать их в днс, все будет работать. Но таким образом мы откроем наш кубер наружу.
А если поставить один сетевой балансер и распределять трафик по нодам то для всех внешних чуваков это будет просто ip адрес куда идет трафик, без понимания что находится за ним.
Под сетевым балансером чаще подразумевается балансировка tcp трафика, на апстримах система должна уметь сама принимать его и работать как нужно. То есть в случае куба трафик будет приходить как есть на nginx ingress и он уже будет работать с ним по своим правидам.

VIBE

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

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

HTTP BALANCER

Когда стоит выбрать http балансер а не просто сетевой?
Для начала - он в любом случае будет менее производетелен чем обычный сетевой балансер, так как лезет в пакеты а не просто пересылает их.
Так вот, его стоит выбрать когда нужно настроить строгие правила маршрутизации не на приложении. Например роутить одни эндпоинты на один сервер а другие на другой. Обычный сетевой балансер не сможет так, так как он не видит конкретные эндпоинты из http запроса, для него это просто tcp пакеты.
Так же http прокси дает возможность поиграться с производительностью и защитой. На нем можно тонко настроить правила кеширования и rate лимитинг.
Ну и в зависимости от реализации на него можно переложить работу с клиентскими tls сертами.
По реализации, чаще всего, это просто машина с nginx и публичным ip. На него приходят клиентские запросы и он уже роутит их по приложениям внутри сети)

MACOS

Немного оффтопная тема)
На той неделе обновился на новый мак, сейчас тут стоит sequoia и думаю обновится до tahoe.
Так вот, мне не не очень нравится что современная макось все больше становится похожа на мобильную систему. Все больше элементов и схожести с IOS.
Запутанные настройки, неудобный finder, не самый интуитивный интерфейс и все прочее.
При том что я очень люблю эту систему, и все еще считаю ее самой удобной. Но это движение в сторону обьединения всех операционок apple мне явно не нравится.
Просто сравните скрины из snow leopard и tahoe, поймете в чем прикол)

MIGRATE

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

UP

Как проверить способность системы к востановлению?
Стопнуть всю инфру и потом заново стартануть ее)
Сегодня на одном из проектов, из за одно проблемы, все ресурсы яндекс клауда остановились. Это базы данных, кафка, виртуалки, балансеры и куб кластер. После решения проблемы мы стартанули ее разом и вся система поднялась сама.
Как этого добится? На самом деле довольно просто:
1. Restart police на уровне контейнеров
2. Retry к инфровым сервисам на уровне приложения
3. В некоторых случаях скрипты старта которые запускаются по крону после старта машины

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

SDLC

Про баланс скорости и безопасности в процессах разработки.
Скорость разработки в этом контексте это время за которое фича проходит от идеи до прода.
Какие аспекты безопасной разработки могут замедлить:
1. Ручные проверки. Когда сканирования проходят не автоматом а по заявке ИБ.
2. Паралельность. Когда несколько команд не могут проверять свои проекты одновременно.
3. Полные сканирования. Если на каждый коммит делаем полный скан, а не инкрементальный.
4. Позднее сканирование. Когда фича уже на препроде, и после фикса нужно пройти весь процесс заново.

Все это чинится, технически и процессно. И при хорошо выстроенным SSDLC время доставки фичи не будет сильно увеличиваться.

DAST

Для динамического секьюрити теста необходимо подготоваливать стенд максимально идентичный проду.
Часто все остальные стенды закрыты в контуре и в первую очередь будут атакавать не их а именнно прод, который открыт наружу.
Плюс ко всему, на проде часто другие настройки - нет дебага, rate limit, другие настройки безы, фильтрации разные на баланере. А тестирую приложение на тесте в дебаге и дев настройками часто будет не показательно, так как это уже немного не то приложение.
Например один и тот же код может быть уязвим на тесте и безопасен в проде, например из за более жестких лимитов и проверок.
Поэтому для DAST выделяем время на preprod среде, и проводим его перед релизом.

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

https://www.youtube.com/watch?v=FUdteCBRX9c

И, наверно, один из самых неизвестных их клипов
https://www.youtube.com/watch?v=IMRxAi8_xx0

FALSE POSITIVE

Ложные срабатывания.
В процессе сканирования приложения на безопасность могут быть срабатывания на места где на самом деле нет проблем.
Например, есть ридми в котором указан пример переменных окружения, например:

Для подключения к бд используйте переменную
DB_PASS=some_pass

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