Если у вас алерты, это непрекращающийся спам во множестве каналов, никаким ИИ их не заткнуть, это я вам как SRE с 20 летним стажем говорю. Сделайте лучше, чтобы каждый Алерт необходимо было обрабатывать. Это примерно на 2 день заставит вас пойти, разобраться, как работает Victoria metrics и ее metricsQL. После чего вы будете вынуждены кратно уменьшить количество срабатываний, улучшив алерты и починив системы, которые вчё время падают.
А когда разберётесь с метриками, вы их полюбите.
Но в целом, спасибо за статью. Я сейчас подобный же инструмент делаю для облегчения дежурств для команд разработки.
Мне дихотомия DevOps|разработчик кажется неверной. Она приводит к подходу "мы пишем код, а девопсов потом его запускают". Добиться какой-то стабильности и качества очень затруднительно. В саппортном канале потом постоянный фон "нам девопсоы тут что-то написали, а оно не работает". Выход - SRE. При чем, не как выделенная команда, а как роль разработчика. Дежурства командами разработки, прием пейджей, вот это всё.
Тут ещё не только про то, где Вы находитесь, а про то, где следует находится. Если работаете в условном Макдоналдсе, Вы в простом домене, а если Вы разработчик, то даже джуну надо стремится в сложный.
Старайтесь не работать длинными сессиями. Делить эрпики на задачки, задачки на подзадачки. Пока они не будут у Вас укладываться в 1 копоткоживущую сессию. Всё ± как в классической разработке. Кроме того длинная сессия - замусоренных контент. Лучше по окончании задачки заставляйте кодекс обновлять марудауны с контекстом. Если всё же никак не можете обходиться без длинных сессий, просто кладите их в гит вместе с проектом.
Я бы для небольшой компании брал парочку nvidia gb10, можно тысяч в 800 уложиться
Зашёл почитать про ollama, а тут про CS. Два мира, два Шапиро.
Не очень понял, зачем несколько постгресов в сетапе?
Если у вас алерты, это непрекращающийся спам во множестве каналов, никаким ИИ их не заткнуть, это я вам как SRE с 20 летним стажем говорю. Сделайте лучше, чтобы каждый Алерт необходимо было обрабатывать. Это примерно на 2 день заставит вас пойти, разобраться, как работает Victoria metrics и ее metricsQL. После чего вы будете вынуждены кратно уменьшить количество срабатываний, улучшив алерты и починив системы, которые вчё время падают.
А когда разберётесь с метриками, вы их полюбите.
Но в целом, спасибо за статью. Я сейчас подобный же инструмент делаю для облегчения дежурств для команд разработки.
Несколько дней бьюсь с тем, чтобы подключить вкуссвил mcp к openclaw. Можете показать верную конфигурацию?
Вот примерно такой же опыт. В итоге принялся своего агента писать
Наконец-то!
Так и тестировщик - ИИ
Мне дихотомия DevOps|разработчик кажется неверной. Она приводит к подходу "мы пишем код, а девопсов потом его запускают". Добиться какой-то стабильности и качества очень затруднительно. В саппортном канале потом постоянный фон "нам девопсоы тут что-то написали, а оно не работает". Выход - SRE. При чем, не как выделенная команда, а как роль разработчика. Дежурства командами разработки, прием пейджей, вот это всё.
И в целом, создавать инфраструктуру не привлекая внимания девопсов, не очень правильная стратегия. Это я вам как SRE инженер говорю.
Нельзя ли его попросить завести гит и версионировать свои конфиги в нём?
Умеет в mcp? Мой умеет
Тут ещё не только про то, где Вы находитесь, а про то, где следует находится. Если работаете в условном Макдоналдсе, Вы в простом домене, а если Вы разработчик, то даже джуну надо стремится в сложный.
Тут вижу проблему XY.
Старайтесь не работать длинными сессиями. Делить эрпики на задачки, задачки на подзадачки. Пока они не будут у Вас укладываться в 1 копоткоживущую сессию. Всё ± как в классической разработке. Кроме того длинная сессия - замусоренных контент. Лучше по окончании задачки заставляйте кодекс обновлять марудауны с контекстом. Если всё же никак не можете обходиться без длинных сессий, просто кладите их в гит вместе с проектом.
Что-то такое было у Лемма
Нет, никогда не собираю никакие тяжелые проекты локально. Всегда использую github/gitlab runner
Вот пример приложения, полностью навайбкоженного в termux с помощью codex и claude code https://github.com/pastukhov/iishnitsa
Не очень понятна проблема.
Поставил termux, туда npm install codex.
...
Profit!
Я работаю с gitlab ci последние 10 лет и для себя определил несколько правил:
Избегай needs, это запутывает логику. Всегда хватает stages
Если Шелл скрипт становится длиннее 5 строк, старайся выносить его из ямля в файл. Это позволит проверять его литерами или даже написать тесты
Когда в CI доходит до include, необходимо их так же версионировать и стараться не делать инклуды глубиной более 2
Есть же figma mcp
Некогда объяснять, катим на все компы!