Собрали подробный гайд для начинающих о Grafana и Zabbix — эффективном комбо для контроля IT-инфраструктуры. Zabbix выступает инструментом для сбора данных, контроля состояния систем и приложений. Grafana же обеспечивает широкие возможности визуализации.
Почему Grafana и Zabbix полезно использовать вместе:
Grafana отображает данные, которые поступают из Zabbix — отсюда оперативное обнаружение проблем;
интеграция позволяет создавать кастомизированные дашборды и графики, адаптированные под потребности конкретных команд или проектов, а также упрощает работу с данными и оптимизирует процесс мониторинга;
можно настроить систему оповещений в Grafana и оперативно реагировать на проблемы;
объединение мониторинга в единой платформе дает целостное представление об IT-инфраструктуре.
В базе знаний Облака Рег.ру читайте о подготовке к совместной работе Grafana + Zabbix и смотрите подробную инструкцию по настройке инструментов.
Если супер просто, то вот что такое MCP сервера внутри Claude Desktop
Прослойка с кодом, которая связывает клиент, например Claude Desktop, и сервис на той стороне
Связывает таким способом, что я могу человеческим языком писать в чат Claude, а эта прослойка сама понимает, какую функцию нужно вызвать
Есть официальные прослойки, которые пишут сами компании. А есть те, которые написаны энтузиастами. К одному MCP серверу, нужному мне, я тоже приложил руку, а точнее форк
Пока что технически установить и подключить эти сервера не так просто, хотя Anthropic, создатели протокола, постоянно думают над упрощением процесса установки и подключения
Вот какие MCP сервера подключены у меня
🟢 Notion (на чтение и на запись) 🟢 GitHub (на чтение и на запись) 🟢 TickTick — мой таск трекер (на чтение и на запись) 🟢 Google Analytics 4 (только на чтение)
Какие сценарии использования есть у меня
MCP Server TickTick — мой сервис для задач
Через подключенный MCP сервер я обычным языком, как живому ассистенту, говорю список задач. Он их может ставить, удалять, передвигать, менять описание и все, что могу делать я.
Например,
Поставь мне вот эти 10 задач на неделю, к каждой напиши Definition of Done и выстави время в течении недели, когда эту задачу лучше сделать, учти зависимости с другими задачами
Или
Передвинь задачи из этого проекта на день вперед, я не успеваю сегодня их сделать
А что у меня сегодня запланировано
В общем, как будто через ассистента задачами управляете
Дальше идет Notion — моя база знаний и хранение всего подряд
Claude через Notion MCP знает все файлы, к которым я дал ему доступ. Может создавать там сложные таблицы и контент, который я его прошу В Notion у него есть доступы к моей таблице управления UTM ссылками, финансовому дашборду и бизнес дашборду.
Во все эти места у Claude есть доступ, и все это он умеет заполнять, пока я просто ему наговариваю, что хочу
Затем — Google Analytics
К моему продукту, гайду по ChatGPT, подключеные две аналитики. Яндекс и Гугл. И вот в Google Analytics мой Claude умеет смотреть.
Может приносить мне инсайты недели, какие источники лучше работают, по каким источникам лучше / хуже удержание и возвращаемость
И последний в списке, но не по значимости — GitHub
Через MCP GitHub я улучшаю мои MCP сервера — если понимаю, что их можно улучшить. Claude сам мне может подсказать, что текущая конфигурация MCP сервера ему не нравится, и предлагает улучшения. Мы с ним делаем форк существующего MCP сервера и улучшаем
Плюс все мои сайты могу создавать напрямую из Claude -> GitHub
Это был краткий экскурс в MCP сервера, надеюсь в течении пары дней я смогу упаковать это в подробный пост 🧑💻
Запускайте контейнерные приложения в облаке с Evolution Container Apps 💭
❓ Что за сервис?Evolution Container Apps позволяет запускать контейнерные приложения в облаке, причем для этого не нужно разбираться в Kubernetes или развертывать виртуальные машины. Запуск проиcходит на базе Docker-образов.
🖥 Особенности и преимущества. Возможности сервиса применимы для любого стека — контейнеры могут использовать любую среду выполнения и любой язык программирования. В зависимости от нагрузки экземпляры контейнеров создаются или удаляются автоматически. Не нужно настраивать кластеры Kubernetes: достаточно загрузить Docker-образы в реестр и создать контейнеры в личном кабинете. А еще у Evolution Container Apps есть free tier: ежемесячный объем бесплатных ресурсов — 480 ГБ RAM и 120 vCPU, запускать небольшие приложения можно без оплаты.
👨💻 Кому будет полезно. Всем, кто использует Docker и хочет облегчить развертывание и масштабирование:
Разработчикам и DevOps-инженерам, чтобы быстро тестировать и запускать приложения.
Небольшим компаниям и стартапам, которые хотят сэкономить на инфраструктуре и попробовать бесплатные возможности Evolution Container Apps.
Большим проектам с микросервисной архитектурой, чтобы облегчить оркестрацию, развертывание сложных приложений за счет контейнеров sidecar и init.
Хотите узнать больше о сервисе? Смотрите запись доклада с GoCloud 2025, где мы рассказали, как сохранить данные в S3 при работе с Evolution Container Apps. А еще сохраняйте пошаговый туториал, как запустить облачное приложение с Evolution Container Apps, без Kubernetes и развертывания ВМ.
Я внедрил скрам и не могу закончить ремонт на балконе.
Начинал всё по уму: разбил эпик на задачи, расставил приоритеты. Какие-то оценил сам, по другим — созвал консилиум. Привлек электрика: в команде не было экспертизы, хотя сын уверенно заявил, что справится. Оставим это на его совести — еще вчера он пытался вставить батарейку в игрушку вверх ногами, но делал это с таким выражением лица, что потенциал сеньора виден невооружённым глазом.
Проект, конечно, со спецификой: параллелить задачи сложно. Идею "я утепляю, а жена в это время красит обои, а потом как-нибудь сольем" мы отвергли сразу — архитектура не позволяла.
Поначалу шло бодро: за первый месяц 30% задач закрыто — утепление, 3 из 4 стен покрашены. Но как водится, наступил кризис ресурсов - внезапно вышел Kingdom Come: Deliverance II и съел все капасити ведущего разработчика. Прогресс застопорился.
Ретроспективы с женой проходят регулярно: я зажигаю команду речами о важности коммитмента, о наших ценностях и цели. Но стена всё еще не покрашена.
Дополнительные таски множатся: надо помыть окна по всей квартире, разобраться с дверцей шкафа, которая теперь открывается строго по фазе луны. Думаю, пора внедрять SAFe — горизонт проектов растёт.
P.S. Прогресса по основной задаче нет, но радует, что бизнес пока не планирует резать косты.
Контур проводит исследование о том, как живёт .NET-сообщество в России. Анкета активна до 15 июля.
Вопросов чуть больше 20, но большинство из них закрытые, так что много времени не займет. Мы не спрашиваем ваши персональные данные и зарплатные вилки. Мы хотим узнать, как C# разработчики обмениваются знаниями и какие выбирают инструменты для развития.
Привет Хабр! Это мой первый пост, и я просто хотелось спросить, стоит ли уходить в Go? У меня есть небольшая база в программировании, делал сайты на реакт и ларавел, реализовывал бэкенд с Солид и паттернами, писал на нативном пхп файловые обменники и апи. Не много знаю базы данных соответственно, гит, докер. Сейчас засматриваюсь на Go, где то вычитал что мол крутая штука для бигтехов в России, а сам я студент и пока сижу на шее у родителей, но в следующем году я окончу к курс, и хочу где то месяца за 4-5 изучить все нужное в го и во всех других сопутствующих технологиях для разработки высоконагруженных приложений и микросервисов и всякого подобного. Стоит ли сворачивать на этот путь, или добить стек ларавел плюс вью? Немного боюсь, так как слышал что в го нужны уже 25 летние синьоры со стажем работы минимум в 20 лет, но и не хочется проторчать всю жизнь в челябинской галере на фуллстеке за 70 деревянных на руки.
Control Plane и User Plane в мобильной связи: зачем нужны два типа трафика и как они работают
Опорная сеть — это мозг мобильной связи. Именно она делает возможными звонки, мобильный интернет и все функции, к которым мы привыкли. Когда базовая станция ловит сигнал, переводит его в цифровой вид и передает дальше — в дело вступает опорная сеть. Она решает, что это за данные, кому они адресованы, есть ли у абонента на них право и куда их направить.
На ней держится все: авторизация пользователей, выдача IP-адресов, маршрутизация трафика, подсчет минут и гигабайт, подключение сервисов и связь между базовыми станциями и внешним интернетом. Все, что выходит за рамки простого «поймать сигнал», — уже ее зона ответственности.
Высокоуровневая архитектура любой сети мобильной связи
Физически между базовой станцией и опорной сетью проходят два потока:
Control Plane — управляющий трафик. Отвечает за процедуры подключения к сети, аутентификации, переключения между станциями, сессий и т. д.
User Plane — пользовательский трафик. Это все, что идет от приложений пользователя: стриминговые сервисы, мессенджеры, браузер и так далее.
Они разделены как логически, так и физически. Такой подход нужен, чтобы обеспечивать надежность, безопасность и гибкость.
В статье Елена Степанова, ведущий инженер-программист в YADRO, объясняет, чем опорная сеть отличается от базовой станции, зачем в 5G сотни микросервисов и как устроена архитектура мобильной связи.
Карма vs Инженерная честность: Почему рейтинги убивают экспертизу
Есть в инженерной культуре наивная вера: если система имеет метрики и правила - она безусловно и по умолчанию объективна. Карма на Хабре тому идеальный контрпример. Формально всё честно: пост → оценка → рейтинг. На практике же это цифровой аналог пассивно-агрессивного "не зашло". Без объяснений. Без контекста.
Карма против инженерной честности
Социальная инженерия вместо экспертной оценки
Главный парадокс: чтобы выжить, ты должен угадывать не истину, а ожидания аудитории. Тон, формат, табу. Это краш-тест на конформизм:
Написал, что 80% мониторинга в проде — это фейковый SLO? → Минус ("негатив"). Сказал, что ChatGPT пишет ТЗ лучше джуна? → Минус ("ересь"). Осмелился быть лаконичным без смайликов? → Минус ("агрессия").
Почему так? Потому что карма измеряет не глубину мысли, а комфорт восприятия. Инженерная точность = высокомерие. Прямолинейность = токсичность. Даже если за этим — годы практики и статистика.
Карма как инструмент подавления инакомыслия
Самое циничное на мой взгляд, найдутся и оппоненты, несомненно, это - непрозрачность. Минус прилетает анонимно, без мандата на критику. И неважно, что твой вклад в тему - как у топ-комментатора. Система молчит, а ты получаешь ярлык "ненадёжного".
Итог: Действительно качественные и экспертные умы, готовые спорить и рушить догмы, — уходят. Остаются те, кто мастерски жонглирует банальностями в дружелюбной обёртке. Звучит довольно резко, соглашусь. Но иначе не донести усть мысли. Платформа медленно превращается в клуб взаимного одобрения.
Что делать?
Игнорировать карму как погрешность системы (но тогда зачем она?).
Требовать мандат для минусов ("Укажи причину: факт ошибка/оффтоп/токсичность"). Хотя у кого тут истребуешь - не нравится, двери на кнопке "выйти".
Ввести верифицированную карму - например, чисто теоретически, только от пользователей с 100+ постами в профильных хабах.
Пока же мы имеем соцсеть, где алгоритмическая справедливость проигрывает человеческой... нетерпимости.
P.S. Этот текст - эксперимент. Проверим, сколько стоит сказать: "Император голый". За инженерную честность - не жалко. P.P.S. Карма — временна. Культура дискуссии — вечна.
Java — один из самых востребованных языков, но с чего начать, если вокруг столько информации, а подходы быстро устаревают? В прямом эфире разберем:
✔️ С чего начать в Java, чтобы не тратить время на устаревшие методы
✔️ Ключевые инструменты (JUnit, Maven, Git) — как их применять с первых шагов
✔️ Кейсы, которые помогут на собеседованиях и в реальных проектах
✔️ Как избежать типичных ошибок новичков и сразу писать чистый код
Почему стоит прийти?
🔹 Узнаете, как быстро войти в Java с актуальными знаниями
🔹 Увидите разбор реальных примеров и учебных проектов
🔹 Получите рекомендации по ресурсам и дальнейшему развитию
👨🎓 Спикер:Судакевич Игорь — преподаватель международного уровня, более 15 лет работает в ИТ. Уполномоченный инструктор корпорации Oracle. Магистр компьютерно-информационных технологий. Инструктор платформы Udemy.
Хочу поделиться с вами видением хорошей архитектуры Go проекта, к которой я пришёл на данный момент и также интересно послушать ваши варианты и мнения по данному поводу.
Моё видение:
У нас ядро приложения это сервисный слой (юзкейсы), именно ядро самая основная часть приложения, которая взаимодействует с какой‑то логикой.
Если логика основана на внешних компонентах, то для связи ядра с компонентом(адаптер) и обратно используются абстракции в виде интерфейса(порт). При этом неважно какая связь (от ядра к компоненту или наоборот), внешние компоненты реализуют интерфейсы ядра и не содержат бизнес‑логики, они лишь преобразуют данные к форматам, понятным ядру (интерфейсы также основаны на моделях ядра).
Так как мы не хотим, чтобы логика из ядра уходила во внешние компоненты (по моему мнению, это повлечет переплетение зависимостей и нарушение принципов разделения ответственности), то вся логика должна выполняться на уровне ядра (например, вместо default значений полей в базе, мы создаём модель на уровне ядра, а база служит лишь в качестве хранилища, не выполняя какой‑либо бизнес логики). То есть бизнес‑валидация (инварианты агрегатов) остаётся в ядре, а адаптеры проводят schema‑валидацию (обязательные поля и форматы) до передачи в юзкейсы, тем самым мы избегаем лишних вызовов ядра (при некорректных данных), и не засоряя само ядро валидацией (отличным примером служит то, когда HTTP адаптер валидирует модель до передачи её в юзкейсы).
При этом всё, самое лучше место для интерфейсов (портов) будет отдельный пакет в ядре, к которому могут иметь доступ адаптеры, чтобы проверить реализации контракта (при это адаптеры будут "знать" лишь интерфейсы, а не весь сервисный слой, если бы порты хранились бы в месте использования), а также сами сервисы могут спокойно ссылаться на данные интерфейсы, не подтягивая их с адаптеров (в том случае, если бы мы хранили интерфейсы по месту имплементации).
То есть я считаю идеальной архитектурой для большинства Go проектов, работающих на основании адаптеров (к примеру, REST или gRPC сервис) гексагональную архитектуру с включением подхода DDD.
У меня остались также холиварные вопросы к вам. Как считаете:
Передавать в юзкейсы структуру или поля по отдельности?
Должно ли хранилище, в виде БД например, иметь валидацию данных? Операции по крону? Дефолтные значения полей?
Транзакции: где их начинать/заканчивать?
Когда и где вводить versioning: в HTTP‑уровне, в домене (разные агрегаты) или в репозиториях (Multi‑tenant)?
Должны ли доменные ошибки возвращать rich‑error (с кодом/контекстом) или достаточно обычных error с текстом?
Можно ли развернуть кластер Kubernetes на процессоре с открытой архитектурой RISC-V?
Короткий ответ: нет.
К сожалению, на данный момент «классический» K8s неполноценно портирован на RISC-V. Один из необходимых модулей K8s — kubelet — отказался запускаться на RISC-V-машине (в роли нее — микрокомпьютер Lichee Pi 4A).
Плата с кулером и подключенной WiFi-антенной
Зато облегченная версия оркестратора K3s и Docker Swarm заработали на RISC-V, но с разными компромиссами:
→ Docker Swarm проще в развертывании.
→ K3s — более гибкий в работе, так как поддерживает Kubernetes-инструменты.
В синтетических тестах (stress-ng) K3s показал лучшую производительность на матричных вычислениях — он обошел показатели Docker Swarm примерно в 16 раз. В цифрах: 2.996 bogo ops/s (K3s) против 188 bogo ops/s (Docker Swarm). Возможно, это связано с оптимизацией Kubernetes или меньшими накладными расходами: K3s потребляет меньше ресурсов на фоновые процессы, такие как управление кластером и сетью, что важно для маломощных устройств.
Интересно узнать больше? Тогда переходите по ссылке и читайте подробности экспертимента по заапуску известных оркестраторов на RISC-V.
Как развернуть среду разработки и сервис управления проектами в облаке?
Группа IT-компаний Lad сократила время запуска клиентских проектов, автоматизировала сборку клиентских приложений для iOS и развернула производительную инфраструктуру для публичных сервисов. И все это — на инфраструктуре Selectel.
В основе инфраструктуры — облачные серверы с быстрым запуском, автомасштабированием и возможностью использовать подход GitOps.
Чтобы автоматизировать сборку клиентских приложений для iOS, компания арендовала в Selectel серверы Mac mini®.
За производительность инфраструктуры для публичных сервисов отвечает связка из Managed Kubernetes, Container Registry и S3. Она позволяет поддерживать микросервисную архитектуру с отказоустойчивыми кластерами, автоскейлингом и надежным хранением файлов.
Как группа IT-компаний Lad развернула окружения для разработки и тестирования, а также запустила сервис для управления проектами и ИИ-ассистента для бизнеса, читайте в Академии Selectel.
Вайб-кодинг это TDD в блестящей обёртке и с хорошим пиаром. Change my mind.
И в этом очень-очень много иронии. Давайте прямо: за дцать лет TDD не стал ни стандартом де факто, ни даже общепризнанной хорошей практикой. Если оценим комментарии к местнымстатьямпро TDD, то они скорее всего будут негативными. Даже саму необходимость юнит-тестов постоянно подвергают критике.
Дцать лет апологеты пытаются продвинуть TDD под предлогом улучшения надежности систем и снижения количества дефектов. И дцать лет их полоскают.
Но тут приходит Андрей Карпатый (разработчик ИИ, научно-технический просветитель, ныне больше с креном в инфоцыганство) и говорит страшную вещь. А давайте детально опишем поведение юнита со всеми корнеркейсами и скормим нейронке. А когда нейронка выдаст не совсем то - уточним описание. И так по кругу, пока результат не станет идеальным.
И все такие: ВАУ!!!111 10 ИЗ 10, ГОСПОДИ, 10 ИЗ 10!1
Внезапно оказалось, что если продумать спецификацию, то кодинг - дело техники. А если еще обмазать тестами, то надежность будет железобетонная. И чем детальнее спека, тем лучше результат. Кто бы мог подумать! Хотя погодите-ка...
Мои коллеги по ИТ-компании "Криптонит" пишут на Go. Я попросила их придумать ошибку — сможете её найти? Ждём в комментариях ваши варианты.
package main
import "fmt"
type User struct {
name string
meta map[string]string
}
func (u *User) SetMeta(key, value string) {
u.meta[key] = value
}
func main() {
u := &User{name: "Alice"}
u.SetMeta("role", "admin")
fmt.Println("Meta:", u.meta)
}
.
.
.
ОСТОРОЖНО! ДАЛЬШЕ СПОЙЛЕР
В main() мы создаём указатель на User, но не инициализируем вложенную map[string]string (Meta)
Присвоение значения через u.Meta[key] = value, вызовет панику (panic: assignment to entry in nil map), потому что u.Meta всё ещё nil, и в Go нельзя присваивать значения в nil-мапу.
Одним из вариантов было бы добавить функцию NewUser(), создавать пользователя через нее, и сразу инициализировать мапу:
Второй вариант решения изменить SetMeta что бы инициализировать мапу, если она равна nil
func (u *User) SetMeta(key, value string) {
if u.meta == nil {
u.meta = make(map[string]string)
}
u.meta[key] = value
Ошибку и решение нам помог составить Алексей Косов, системный инженер департамента инфраструктуры в «Криптоните». Его материал про особенности, применение, плюсы и минусы Golang можно прочитать в этой статье.
Вы наконец победили. Потратив большую часть карьеры на охоту за багами, вы достигли невозможного: багов нет. Вообще. Пусто. Доска с багами пуста, QA тихо плачет в углу, а CI-сервер бездельничает, ровно светясь скучно-зелёным цветом. Но вместо того чтобы попасть в рай, вы оказываетесь в лимбе. Если вы играли в игры начала нулевых, это похоже на выход за границы карты: голый ландшафт, странная геометрия и надпись от разработчика: «Ты не должен был оказаться здесь. Но раз уж оказался — молодец, конечно, только смысла в этом нет».
Что происходит дальше? Ничего хорошего. Первый сюрприз — вас никто не похвалит. Бонуса нет, промоушена тоже. Менеджер лениво листает ваш performance-review, хмурится и спрашивает: «А что ты делал весь квартал?» Ты отвечаешь: «Я избавил нас от багов». Он пожимает плечами: «Так они и раньше вроде не были критичными».
Кто-то бросится чинить метрики, и начнётся новый головняк, потому что вы уж слишком постарались. «Багов не может не быть, значит, сломана метрика», — уверены все. Предлагаете метрику «отсутствие багов» — слышите в ответ: «Недоказуемо, выборка мала!»
Вы думали, что победа откроет двери в рай, а распахнули портал в лимб, где невозможно доказать собственную полезность. Пару поколений инженеров мы упорно объясняли бизнесу, что «баги бывают, это нормально». Благодаря нам продакт-оунеры научились бравировать SLA с допуском на косяк. Мы воспели «умеренное количество дефектов» как здоровый холестерин IT-организма — и вдруг вы свели холестерин к нулю.
Парадокс: все процессы настроены на борьбу, а не на мир. Метрике нужен враг, а процессу — вызов. Без них графики плоские, алерты молчат. Добро пожаловать туда, где ваши достижения стоят ровно ничего. Вся организационная религия строилась на борьбе с багами. Уничтожив последний баг, вы «убили бога» процесса. Всё, что давало смысл (defect-метрики, ретро-ритуалы, баг-баунти), обесценивается; наступает инженерный нигилизм. Великая битва окончена, триумфаторов нет, система сломана. Баг умер — и ты его убил!
Совет: в следующий спринт оставьте пару багов — ради здоровья экосистемы.
В обсуждениях тестирования микросервисов часто всплывает статья Мартина Фаулера Testing Strategies in a Microservice Architecture. Опубликованная в 2014 году, она опирается на концепцию тестовой пирамиды, сформулированную ещё в 2009-м. С тех пор ландшафт тестирования заметно изменился — в первую очередь за счёт появления и широкого распространения Docker и Testcontainers, которые существенно повлияли на практики и экономику тестирования.
Эта трансформация хорошо отражена в более современных источниках:
В контексте вашего проекта это означает, что использование интеграционных тестов в 2025 году оказывается существенно проще, дешевле и эффективнее, чем это предполагалось в рамках модели 2009 года.
В Облаке Рег.ру добавили образ NextCloud + OnlyOffice
Запустили удобное корпоративное хранилище для совместной работы с документами в Облаке Рег.ру. Набор офисных приложений OnlyOffice теперь также доступен в облаке — добавили предустановленный образ NextCloud + OnlyOffice. Обновленное облачное решение предлагает универсальную экосистему для совместной работы:
NextCloud подходит для хранения любых документов и файлов;
OnlyOffice позволяет редактировать документы и закрывает большинство стандартных задач пользователей.
Для заказа доступны облачные серверы во всех локациях. Минимальная конфигурация — 4 vCPU, 16 ГБ RAM, 40 ГБ диска.
Новый образ NextCloud 31 + OnlyOffice 5 уже можно тестировать на нашем сайте.
Если у вас в приоритете — опыт работы над масштабным продуктом и строчка в резюме, с ходу впечатляющая HR-ов… Другими словами, если в ваши карьерные планы входит работа в крупной технологической компании — значит, мы придумали этот тест для вас.
Он поможет сориентироваться: проверить хард- и софтскилы и понять, какие навыки уже на высоком уровне — а что стоит прокачать, чтобы повысить шансы оказаться в бигтехе.
Тест вам подходит, если:
Ваша специальность — разработчик, DevOps-инженер, аналитик данных или ручной тестировщик.
Ваш грейд — джун+ и выше. Нужна теоретическая база, коммерческий опыт или опыт решения учебных проектов на реальных кейсах.
Чтобы давать релевантные задачи, мы консультировались с нанимающими менеджерами Яндекса — они знают, чего ждут от соискателей в больших технологических компаниях.
