Запускаешь на железе и lllmfit выдает длинный список моделей с оценкой. Но по факту это всё сферическая модель в вакууме. Надо писать реальный бенчмарк
Если у вас алерты, это непрекращающийся спам во множестве каналов, никаким ИИ их не заткнуть, это я вам как SRE с 20 летним стажем говорю. Сделайте лучше, чтобы каждый Алерт необходимо было обрабатывать. Это примерно на 2 день заставит вас пойти, разобраться, как работает Victoria metrics и ее metricsQL. После чего вы будете вынуждены кратно уменьшить количество срабатываний, улучшив алерты и починив системы, которые вчё время падают.
А когда разберётесь с метриками, вы их полюбите.
Но в целом, спасибо за статью. Я сейчас подобный же инструмент делаю для облегчения дежурств для команд разработки.
Мне дихотомия DevOps|разработчик кажется неверной. Она приводит к подходу "мы пишем код, а девопсов потом его запускают". Добиться какой-то стабильности и качества очень затруднительно. В саппортном канале потом постоянный фон "нам девопсоы тут что-то написали, а оно не работает". Выход - SRE. При чем, не как выделенная команда, а как роль разработчика. Дежурства командами разработки, прием пейджей, вот это всё.
Тут ещё не только про то, где Вы находитесь, а про то, где следует находится. Если работаете в условном Макдоналдсе, Вы в простом домене, а если Вы разработчик, то даже джуну надо стремится в сложный.
Старайтесь не работать длинными сессиями. Делить эрпики на задачки, задачки на подзадачки. Пока они не будут у Вас укладываться в 1 копоткоживущую сессию. Всё ± как в классической разработке. Кроме того длинная сессия - замусоренных контент. Лучше по окончании задачки заставляйте кодекс обновлять марудауны с контекстом. Если всё же никак не можете обходиться без длинных сессий, просто кладите их в гит вместе с проектом.
Не очень понял про ирландцев, но замечу, что менеджмент не должен решать инженерные задачи
При высоком качестве проекта на прод выкатывается протестированный ког, в котором не может быть "не учел"
Чем больше деплоев, тем лучше. Хорошо на тронный проект сам выкатывается по необходимости, даже в выходные
Назвать Sidero Labs васяном, это сильно!
Если так любите RH, почитайте про их подход к immutable OS
Все аргументы против докера очень сомнительны. Это я как сисадмин с 25 летним стажем говорю.
Посмотрите, например, как talos устроен. Там есть ядро, init и containerd. Всё остальное в контейнерах.
Главное, дорогая
Есть ещё вот такой проект
https://github.com/AlexsJones/llmfit
Запускаешь на железе и lllmfit выдает длинный список моделей с оценкой. Но по факту это всё сферическая модель в вакууме. Надо писать реальный бенчмарк
Зашёл почитать про ollama, а тут про CS. Два мира, два Шапиро.
Не очень понял, зачем несколько постгресов в сетапе?
Если у вас алерты, это непрекращающийся спам во множестве каналов, никаким ИИ их не заткнуть, это я вам как SRE с 20 летним стажем говорю. Сделайте лучше, чтобы каждый Алерт необходимо было обрабатывать. Это примерно на 2 день заставит вас пойти, разобраться, как работает Victoria metrics и ее metricsQL. После чего вы будете вынуждены кратно уменьшить количество срабатываний, улучшив алерты и починив системы, которые вчё время падают.
А когда разберётесь с метриками, вы их полюбите.
Но в целом, спасибо за статью. Я сейчас подобный же инструмент делаю для облегчения дежурств для команд разработки.
Несколько дней бьюсь с тем, чтобы подключить вкуссвил mcp к openclaw. Можете показать верную конфигурацию?
Вот примерно такой же опыт. В итоге принялся своего агента писать
Наконец-то!
Так и тестировщик - ИИ
Мне дихотомия DevOps|разработчик кажется неверной. Она приводит к подходу "мы пишем код, а девопсов потом его запускают". Добиться какой-то стабильности и качества очень затруднительно. В саппортном канале потом постоянный фон "нам девопсоы тут что-то написали, а оно не работает". Выход - SRE. При чем, не как выделенная команда, а как роль разработчика. Дежурства командами разработки, прием пейджей, вот это всё.
И в целом, создавать инфраструктуру не привлекая внимания девопсов, не очень правильная стратегия. Это я вам как SRE инженер говорю.
Нельзя ли его попросить завести гит и версионировать свои конфиги в нём?
Умеет в mcp? Мой умеет
Тут ещё не только про то, где Вы находитесь, а про то, где следует находится. Если работаете в условном Макдоналдсе, Вы в простом домене, а если Вы разработчик, то даже джуну надо стремится в сложный.
Тут вижу проблему XY.
Старайтесь не работать длинными сессиями. Делить эрпики на задачки, задачки на подзадачки. Пока они не будут у Вас укладываться в 1 копоткоживущую сессию. Всё ± как в классической разработке. Кроме того длинная сессия - замусоренных контент. Лучше по окончании задачки заставляйте кодекс обновлять марудауны с контекстом. Если всё же никак не можете обходиться без длинных сессий, просто кладите их в гит вместе с проектом.