N8N

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

LLM

Про использование языковых моделей для анализа кода.
Как по мне основной кейс использования это анализ дифференца в МР, так как что бы на каждый чих анализировал весь код нужно много токенов.
Что стоит ожидать в этом случае?
1. Анализ синтаксиса
2. Явные баги
3. Опечатки
4. Код стайл
5. Потенциальные проблемы

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

Не мог не поделится)

SUPPORT

Когда вся инфра и сам проект уже развернуты то для девопса настоет период поддержки.
Что обычно сюда входит:
1. Реакция на алерты
2. Реагирование на запросы разработки (чаще мелочи)
3. Зависит от проекта, но еще могут быть доступы
4. Мастшабирование
5. Иногда затаскивание новых сервисов и релизы старых

Чаще все это занимает не более часа в день, так как после первых релизов команда разработки может почти все сделать сама)

Уже кидал этот клип года 2 назад, но пожалуй повторюсь)
https://www.youtube.com/watch?v=lPlkGFDZn4I

VM

Сегодня столкнулся с кейсом: полетели настройки ссш ключей на виртуалке в яндексе.
Какое тут решение:
1. Делаем снимок диска нужно машины
2. Стопаем или удаляем машину
3. Конфигурим новую машину из снимка
4. Указыаем там нужный ключ и ip
5. Поднимаем машину

Все, после того как машина поднимется то там снова будут актуальные ключи, яндекс добавит их через cloud-init)

RELEASE

Как ускорить релизы фичей в прод.
Есть несколько базовых, именно технических, приемов которые могут сильно помочь:
1. Флоу разработки. Если фиче нужно пройти через несколько веток и стендов то это замедляет. Чем меньше промежутков от фича ветки до мастера тем лучше. (Смотрим на TBD)
2. Паралельность. Все мы запускаем проверки в пайплайнах, многие из них можно запускать паралельно а не последовательно.
3. Повторение. Если, допустим, юнит тесты прошли на тестовом стенде то после создания прод тега нет смысла запумкать их еще раз. (зависит от качества тестов)
4. Базовые сборки. Можно сразу собрать нужные образ и при релизах обновлять в них только артифакты.
5. Переиспользование. В идеале нам не нужно собирать прод сборку, можно просто сделать новый тег для препрод сборки.

По опыту, внедрение этих простых првил может ускорить выкатку фичей в разы)

TBD

Важно понимать один момент про транк.
Это методология разработки в контексте гита, которая описывает как мы должны сливать свои фичи в мастер. Но она не говорит о том что сразу после слива в мастер нам нужно релизится. В транке мы просто накапливаем изменения в мастере, а решение о релизе в прод принимается уже людьми)
То есть транк это больше CI процесс, а не CD.

PENTEST

Сейчас прохожу обучение по пентесту.
Это позволяет посмотреть на свою работу с другой стороны. То где могут быть ошибки в конфигурирование систем которые могут привести к эксплуатации.
Вот примеры:
- Использование простых паролей
- Одинаковые учетные данные в разных подсистемах
- Открытие лишних портов
- Разрешение входа по пароль по ссш
- Избыточные привелегии
- Сетевая связанность там где она не необходима

Это самые базовые вещи которые могут сильно облегчить проникновение. Дальше уже стоит думать про уязвимости в софте)

HEALTHCHECK

Каким в идеале должен быть хелсчек? Думаю из названия очевидно, он должен проверять состояние всей системы.
То есть не как обычно это делается - эндпоинт которые просто отвечает 200. Ведь состояние одного конкретного эндпоинта ничего не говорит нам о состоянии системы в целом.
Хелсчек должен проверять критичные для нас вещи. Как пример:
- Доступность бд
- Доступность критичных эндпоинтов
- Время ответа
И ответ должен быть бинарным, системы либо работает как нужно либо нет.
Ну и идеально было бы делать ответ на уровне http кода, а не в теле ответа. По необходимости в теле можно отдать детали)

CONF

Как может выглядить иденпотентное применение конфигурации. На примере nginx:
1. Пуш конфигурации в гит
2. Запуск джобы с ansible манифестом
3. Переписывание конф файла на серверах только при наличии диффа
4. После изменения конфигурации проводится тест самого nginx
5. Если конфигурация валидна то запускается reload
6. Если не валидна то откат до прошлой версии

Таким образом мы можем надежно заменить конфигурацию и делать это только там где есть необходимость)

SSDLC

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

Заметка:
Разделять сервисы по пользакам в БД может помочь с дебагом, когда нужно найти сервис который ее кладет.

PRE COMMIT

Технология которая позваляет делать флоу перед попаданием кода в репозиторий.
Как пример, на локальной машине разработчика мы можем вызывать:
- Тесты
- Линтеры
- Сканирование на безу и сикреты
Это позволяет нам не допускать в репозторий код с явными проблемами.
Проблема в том что нельзя напрямую заставить всех разработчиков использовать его, максимум кастомить CI/CD джобы которые по косвеным признакам определит запуск. Но по большей части инструмент нужен самим разработчикам, что бы сделать проверку на дурака)

INTERVIEW

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

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

STACK

Как подбирать стек для проекта, в контексте инфры и DevOps практик:
1. Задачи. Определить что мы хотим от инструмента, какие задачи он должен закрывать?
2. Перспектива. Планируется ли в будущем какие то задачи которые не сможет закрыть конкретный инструмент?
3. Популярность. Есть ли на проекте или на рынке люди которые смогут работать с ним?
4. Надежность. Хватит ли нам той надежности которую предоставляет данный инсрумент?
5. Безопасность. Тут не надо пояснять)

Вот к примеру:
Gitlab CI/CD по всем пунктам плюс минус такой же как CircleCi, по сути делает тоже самое. Но в реалиях рынка РФ gitlab сильно популярнее и бОльшее количество людей умеют с ним работать, для меня выбор очевиден)

Что выгоднее?
1. Доставить на орбиту солнеыные панели и отправлять электричесвто на землю
2. Отправить в космос то что потребляет энергию

Смотрим тут)
https://www.youtube.com/watch?v=XYQ_NmzeD6c

ERLANG

Иногда читаю про язык erlang и его виртуальную машину. И каждый раз нравится все больше.
Основная идея состоит в надежных распределенных вычислениях. Как это добивается:
1. Виртуальная машина предоставляет простой способ поднять кластер на разных нодах
2. Она сама распределяет нагруку и создает процессы на нодах
3. Есть специальный фреймворк для вычислений на кластере
4. Hot reload, можно без поростоя обновить код
5. Миграции, позволяет настраивать переход состояния процессов при hot reload
6. Автоматический перенос процессов между нодами

Все это позволяет делать высоко доступные производительные решения. Чаще всго применяется в телекоме, где необходимо давай высокий uptime без простоя)

MONO

Один из вариантов ведения разработки это монорепы.
Как пример - в репе несколько модулей одного проекта, плюс общие компоненты. Чаще всего все эти модули собираются в отдельные микросервисы, и при сборке сразу из репы тащаться общие компоненты.
Зачем так делать? Для кого то это проще. Если все модули имеют сильную связанность то куда легче вести все это вместе. Плюс, в какой то мере, это проще поддерживать и выкатывать.
Какой обычно флоу для CI/CD:
- При изменения файлов кокнретного модуля тригер на сборку этого модуля
- Тригер сборки модуля тригерит его деплой
- При изменения файлов общих компонентов пересобираются и деплоятся все компоненты

TOOLS

Про зоопарк инструментов.
Периодически втречаю проекты где есть какое то количество инструментов которые делают одно и тоже, но их схлопывают.
Например репозиторий в гитлабе, а пайпланы запускаются в jenkins. Казалось бы, почему не сделать сразу все в гитлабе? Ну или не переделать сейчас.
Чаще это бывает легаси которое сложно выпилить. Например когда то дженкинс закрывал что то чего нет в гитлабе. Но со временем база пайлпайнов сильно разрастается, и уже сложно просто взять и переписать все на гитлаб. Так и продолжается, все новые пайпланы по привычке заводятся на jenkins.
Что тут можно сделать? Ну если команду все устраивает то ничего делать не нужно.
А так, изначально не стоит заводить зоопарк инструментов, это сильно увеличивает сложность поддержки и необходимую экспертизу.
Если же это уже случилось то можно просто остановится и оставить этот кусок как легаси, все новое уже заводить как нужно. А легаси можно уже потихоньку разгребать)

Очень классное выступление манискин, как обычно Итальянцы делают очень жарко)
https://www.youtube.com/watch?v=_kOzW0HPLT0