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

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

DNS

Про нейминг стендов на уровне доменов.
Допустим у нас есть кластер под дев/тест/препрод стенды. И на каждый стенд и проект нужен свой домен.
Я обычно выбираю такую структуру:
компонент.проект.стенд.кластер.верхний_домен

Например у нас есть проект под названием site, с бекендом и фронтом. Для дев стенда домен будет выглядеть так:
api.site.develop.cloud.example.com - для бекенда
ui.site.develop.cloud.example.com - для фронтенда

Да, это может быть громостко, но зато просто по самому домену можно сразу понять что это и где находится)

GITLAB

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

А было бы удобно, в группе было бы несколько переменок типа:

K8S_URL **** env dev
K8S_URL **** env preprod
K8S_URL **** env prof

И в пайпланах указывать просто env.

TAG

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

VIBE

Сегодня в полу ручном режиме сканил проекты в sonarqube.
Локально поднял его, через docker-compose и навайбкодил скрипт который проходит по всем локальным проектам и сканируют их.
Хороший вариант для быстрого анализа инструмента. Контейниризация и вайбкод хорошо подходят для "приключения на 15 минут", где нужно просто собрать прототип системы и получить быстрые результаты.
Из минусов - нет полного погружения и раскрытия всех возможностей инструмента. Но как способ "быстро понять" идеально)

DAST

В контексте динамического анализа безопасности тоже есть черный, серый и белый ящик.
Черный ящик - просто даем адрес системы для атаки.
Серый ящик - даем, например, просто пользака.
Белый ящик - даем максимального пользака и схему апи.

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

Поэтому важно покрывать все сценарии)

SWAGGER

Сейчас прогоняю на одном проекте DAST. И как же больно что для каждого микросервиса свой отдельный сваггер.
То есть есть гетвей через который мы можем обращаться на микрач, и что бы найти его апи схему нужно открывать его свагер и выкачивать схему.
Понятно почему это сделано - разработчики конкретного микрача актуализирует свою схему и раскатывают сервис, и не нужно делать обновлений на гейте. Но иногда это очень не удобно.
Есть подходы когда гейт сам похватывает изменения схемы на микрачах и добавляет их в свой свагер. Это позволяет просмотреть все нужные эндпоинты из одного места.
Ну и автогенерацию схему никто не отменял)

TBD

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

VIBE

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

ROLLING

В контексте линукса есть такая схема обновлений rolling release.
Это когда нет обновления между версиями, только постоянные апдейты. Например это fedora.
Да, там могут быть версии, но по сути это просто фиксация текущего состояния. Нет такого как например в убунте - обновления в рамках одной версии, и обновление до новой как отдельная сущность.
В федоре мы просто постоянно ставим обычные апдейты и таким образом получаем самую новую версию системы.
Чаще это куда удобнее, особенно на серверах. Ведь в классическом случае для обновления до новой версии часто нужен даунтайм сервера, и не выйдет сделать это без простоя.

SHIFT LEFT

В контексте CI/CD процесса значит что мы делаем что то как можно ближе к началу разработки.
Этот процесс можно представить как прямую, слева которой первым коммит фичи, а справа деплой в прод. Между этими краями может быть какое то количество действий и определенный флоу.
И вот некоторые вещи мы хотим делать как можно ближе к левому краю, так как это уменьшает время по доработки и прохождения процесса до этого момента заново.
Сюда можно отнести тесты, проверки безопасности, линтеры и все что связанно с качеством продукта с разных сторон.
Основная суть - сделать дешевле и быстрее. И так же снизать риск попадания проблемного кода в последний шаг)