Все потоки
Поиск
Написать публикацию
Обновить
332.36

DevOps *

Методология разработки программного обеспечения

Сначала показывать
Порог рейтинга

Миграция сервера GitLab: инструкция от практика

Нужно перенести GitLab на новый сервер, но боитесь потерять данные? Я покажу проверенный способ миграции, сохраняющий все проекты, настройки и историю.

Подготовка

Убедитесь, что:

  • у вас есть root-доступ к обоим серверам;

  • на старом сервере ≥50% свободного места;

  • Вы знаете точную версию GitLab (критически важно!)

Шаг 1: Подготовка нового сервера

Установите идентичную версию GitLab на новую машину:

sudo apt-get update && sudo apt-get install -y curl openssh-server ca-certificates perl 
# Установка конкретной версии (пример для 17.5.5) 
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash sudo apt-get install gitlab-ee=17.5.5-ee.0

Шаг 2: Создание бэкапа на старом сервере

# Проверка свободного места 
df -h  
# Создаем резервную копию
sudo gitlab-backup create

Процесс создания бэкапа может занять от минут до часов.

Шаг 3: Копирование файлов на новый сервер

Важно! Используем nohup для обеспечения непрерывности процесса и SSH-ключ для безопасного соединения:

# Копирование файла секретов 
nohup /bin/bash -c 'rsync -avh --delete --rsync-path="sudo rsync" -e "ssh -o StrictHostKeyChecking=no -i k" /etc/gitlab/gitlab-secrets.json root@new-server:/etc/gitlab/gitlab-secrets.json'
# Копирование бэкапа 
nohup /bin/bash -c 'rsync -avh --delete --rsync-path="sudo rsync" -e "ssh -o StrictHostKeyChecking=no -i k" /var/opt/gitlab/backups/1742165326_2025_03_16_17.5.5_gitlab_backup.tar root@new-server:/var/backups/gitlab/1742165326_2025_03_16_17.5.5_gitlab_backup.tar'

Примечание: В примере k — это файл приватного ключа. Файл конфигурации (gitlab.rb) намеренно не копируем, но при необходимости полной копии скопируйте и его.

Шаг 4: Восстановление на новом сервере

Сначала остановите необходимые сервисы:

sudo gitlab-ctl stop puma 
sudo gitlab-ctl stop sidekiq

Затем запустите восстановление (с nohup для надежности):

nohup /bin/bash -c "gitlab-backup restore BACKUP=1742165326_2025_03_16_17.5.5 force=yes"

Важно: Идентификатор бэкапа — это часть имени файла до gitlabbackup.tar. Параметр force=yes избавляет от подтверждений.

Шаг 5: Перезапуск и проверка

sudo gitlab-ctl restart 
sudo gitlab-ctl reconfigure  
# Проверки целостности данных 
sudo gitlab-rake gitlab:check SANITIZE=true 
sudo gitlab-rake gitlab:doctor:secrets 
sudo gitlab-rake gitlab:artifacts:check 
sudo gitlab-rake gitlab:lfs:check 
sudo gitlab-rake gitlab:uploads:check

Финальная проверка

Убедитесь, что:

  • вход работает;

  • репозитории открываются;

  • CI/CD пайплайны запускаются;

  • все проекты на месте.

Типичные проблемы и их решение

Ошибка 502 при доступе к некоторым репозиториям:

sudo gitlab-ctl restart 
sudo gitlab-ctl reconfigure

Рекомендации от практика

  1. Тестовая миграция: Сначала попробуйте на тестовом сервере.

  2. Окно обслуживания: Предупредите команду заранее.

  3. Резервный план: Не выключайте старый сервер до полной проверки нового.

  4. Мониторинг: Следите за логами первые дни после миграции.

  5. DNS: Обновите DNS-записи после успешной миграции.

Заключение

Ключ к успешной миграции — точное соблюдение версионности, использование nohup для длительных операций и тщательная проверка после восстановления.

Подробнее: docs.gitlab.com/ee/administration/backup_restore/restore_gitlab.html

Бонус: инструмент для построения последовательности обновления гитлаба

Теги:
Всего голосов 2: ↑2 и ↓0+3
Комментарии0

5 книг, чтобы прокачать скиллы в SRE 📚

Со всеми, кто развивает инженерные практики, подборкой делится Антон Быстров — SRE-инженер Cloud․ru.

📖 SRE Table of Contents OT Google. Это своего рода «путеводитель» по принципам Site Reliability Engineering (SRE). Он объясняет, почему определенные методы и процессы должны использоваться в разработке и эксплуатации систем. Книги служат отличной базой для понимания философии и практических аспектов SRE, включая мониторинг, автоматизацию, управление инцидентами и многое другое.

📖 Проект «Феникс». Книга, которая рассказывает историю трансформации крупной компании через призму внедрения методов DevOps. Автор романа Брайан Дэрроу показывает, как команда разработчиков и операционных сотрудников объединяется для достижения общей цели — создания и запуска нового продукта. Хотя «Проект „Феникс“» — это прежде всего художественное произведение, оно содержит множество реальных примеров и идей, которые будут полезны как разработчикам, так и менеджерам, стремящимся внедрить современные подходы к управлению проектами и процессами.

📖 Грокаем алгоритмы. Иллюстрированное пособие для программистов и любопытствующих — Бхаргава А. Алгоритмы играют ключевую роль в работе любой системы, и эта книга поможет вам глубже понять их принципы. Она проиллюстрирована и написана понятным языком, что делает её идеальной даже для начинающих.

📖 Запускаем Prometheus. Мониторинг инфраструктуры и приложений: Пивотто, Бразил. Одна из базовых книг по мониторингу. Она подробно описывает, как использовать Prometheus для сбора и анализа метрик, что является неотъемлемой частью работы SRE. Понимание экосистемы Prometheus значительно упростит вашу повседневную работу.

📖 Киф Моррис — Программирование инфраструктуры. Это руководство по подходу к инфраструктуре как к самостоятельному продукту. Оно охватывает как теорию, так и практику, помогая понять, как эффективно управлять инфраструктурой и обеспечивать ее надежность и масштабируемость.

Уже читали книги из списка? А какие готовы порекомендовать от себя? Делитесь в комментариях 👇

Теги:
Рейтинг0
Комментарии0

Привет, зачастую после тыкания в какой-нибудь стручок (pod) приходится подниматься на уровень выше в деплой, стейтфулсет или даемонсет. Для этого в kui надо было сначала посмотреть чем контролируется стручок, сделав describe, потом сменить тип объекта, найти нужный... Хватить теребонькать эти стручки! Добавил для стручков команду Controlled by, она сразу тыкает kui в нужное место!

controlled by
controlled by

Творите, выдумывайте, пробуйте!)

Теги:
Рейтинг0
Комментарии0

Почему классический мониторинг не работает для микросервисов и облаков? Переход к Observability

Современные системы давно перестали быть монолитами — теперь это сложные экосистемы из микросервисов, облачных сервисов и распределенных баз. Но если ваш мониторинг всё ещё фокусируется только на CPU и RAM, вы рискуете пропустить критические сбои.

Главные проблемы классического подхода:

  1. Невидимые бизнес-сбои: Сервер «живой», но конверсия платежей падает.

  2. Поиск иголки в стоге сена: При ошибке в цепочке из 10 микросервисов метрики инфраструктуры не укажут на источник проблемы.

  3. Ручная настройка: Часы на алерты для каждого сервиса вместо автоматизации.

Решение — Observability:

Объедините метрики (Prometheus), логи (EFK) и трейсы (Jaeger), чтобы система сама «объясняла» свои сбои.

Пример кода

Отслеживание конверсии платежей в .NET-сервисе:

// Отслеживание конверсии платежей  
using App.Metrics;  
public class PaymentService  
{  
    private readonly IMetrics _metrics;  
    public PaymentService(IMetrics metrics) => _metrics = metrics;  

    public void ProcessPayment()  
    {  
        try  
        {  
            // Логика обработки платежа...  
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentSuccessCounter);  
        }  
        catch  
        {  
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentFailedCounter);  
        }  
    }  
} 

Код автоматически фиксирует успешные и неудачные платежи. Эти метрики интегрируются в Grafana для анализа бизнес-показателей.

📖 Нужны подробности? Читайте статью на хабре: «Эффективная стратегия мониторинга: ключевые метрики для успешного наблюдения»

Теги:
Рейтинг0
Комментарии0

Дайджест открытых мероприятий на май:

1️⃣ AI-агенты в облаке
🗓 13 мая, 18:00 по Мск, онлайн
Узнаем, как строятся AI-агенты, какие инфраструктуры стоят за их работой и какие возможности открывает стажировка в Cloud.ru.
🔗 Регистрация

2️⃣Вебинар от Московского инновационного кластера: «Защита и регистрация интеллектуальной собственности в России»
🗓 14 мая, 12:00 по Мск, онлайн
Практические советы о том, как защитить свои разработки и оформить права на них.
🔗 Регистрация

3️⃣MTS Startup Hub: как найти и реализовать идею для технологического проекта
🗓15 мая, 19:00 по Мск, онлайн
Как придумать идею для стартапа, пройти путь предпринимателя и найти ресурсы на развитие.
🔗 Регистрация

4️⃣ Т-Банк: образовательный кредит — как получить высшее образование с господдержкой
🗓 20 мая, 19:00 по Мск, онлайн
Разберем условия образовательного кредита, преимущества, оформление и действия в случае отказа.
🔗 Регистрация

5️⃣MTS Startup Hub: анализ единорогов как топливо для развития стартапов
🗓 22 мая, 19:00 по Мск, онлайн
Как изучение успешных стартапов помогает понять рынок, находить инновации и строить перспективные бизнес-модели.
🔗 Регистрация

6️⃣ Карьерный буст: как ускорить профессиональный рост
🗓 29 мая, 19:00 по Мск, онлайн
Поговорим о карьерных стратегиях, востребованных навыках и росте в новых реалиях.
🔗 Регистрация

7️⃣MTS Startup Hub: создание прототипов и MVP
🗓 29 мая, 19:00 по Мск, онлайн
Как быстро и эффективно протестировать идеи на практике.
🔗 Регистрация

8️⃣Экскурсия в Сбер
🗓 30 мая, 16:30 по Мск, онлайн
Смотрим, как работает один из самых технологичных банков страны изнутри.
🔗 Регистрация

Участие во всех мероприятиях - бесплатное. Регистрируйтесь по ссылкам выше, а также:

➡️ Скачайте брошюру о магистратуре «Науки о данных»
➡️ Проходите курс «Введение в машинное обучение»
➡️ Получите доступ к записи Дня открытых дверей онлайн-магистратуры «Науки о данных»

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

Теги:
Рейтинг0
Комментарии0

Кардинальное упрощение привязки GitHub, GitLab, Bitbucket в Amvera Cloud

Привязка репозиториев GitHub, GitLab, BitBucket вызывала у наших пользователей затруднения, и мы обещали упростить процесс.

Теперь для привязки репозитория достаточно указать токен и выбрать ветку и репозиторий.

Способ позволяет организовать максимально простой деплой и обновление приложений через git push. Для обновления приложения достаточно сделать коммит в привязанный репозиторий, и оно соберется и бесшовно запустится автоматически.

Заполняем три поля и CI/CD готов
Заполняем три поля и CI/CD готов

Подробная инструкция по подключению доступна по ссылке.

Amvera Cloud — это облако для простого деплоя приложений через git push (или интерфейс). Встроенный CI/CD, бэкапы и мониторинг позволяют развернуть проект тремя командами в IDE и не думать о настойке инфраструктуры. Amvera проще, чем использование VPS.

Теги:
Всего голосов 2: ↑1 и ↓1+1
Комментарии0

В феврале 2025 вышел релиз Docker Engine 28.0.0, устранивший проблемы безопасности:

Fix a security issue that was allowing remote hosts to connect directly to a container on its published ports. moby/moby#49325
Fix a security issue that was allowing neighbor hosts to connect to ports mapped on a loopback address. moby/moby#49325

В официальном блоге вышла статья с подробностями проблемы и возможными сценариями атак. Но, CVE заводить разработчики не захотели. Я не знаю какими принципами руководствовались разаботчики. По мне слова "Fix a security issue" тождественны созданию CVE. Я обратился в MITRE с описанием ситуации через эту форму (выбрал Request type - other). И получил такой ответ:

Thanks for the submission. We will treat this as a dispute/escalation request and reach out to Docker next. Hopefully that will spur them on to assign (it often does) but if not, we will take a look at assignment. 

Once we hear back we'll let you know if they changed their mind and decided to assign or what the next steps will be.

Надеюсь, CVE заведут. Мне и моим коллегам по цеху по безопасности гораздо удобнее оценивать безопасность архитектуры, имея единый источник проблем безопасности (база CVE). А не рыскать по всему интернету, пытаясь собрать воедино информацию о проблемах безопасности конктерных продуктов, придумывая какие-то запросы, вовзращающие релевантную информацию. Даже если описание в самом CVE сухое - всегда проще искать подробности по уникальному идентификатору CVE, чем выдумывать разные запросы для каждого конктерного продукта.

К сожалению, нежелание признавать CVE со стороны различных разработчиков случается периодически. В моей практике была ситуация, когда разработчик не просто не хотел заводить CVE, а ещё и желал, чтоб я сам отозвал CVE. После моего отказа пытался CVE оспорить (но, неудачно). Подробности - в статье "Как я зарегистрировал CVE и разозлил вендора"

Теги:
Всего голосов 6: ↑6 и ↓0+10
Комментарии0

Оплачиваемая стажировка Cloud.ru Camp — успей подать заявку до 12 мая 📢

Присоединяйся к Cloud.ru Camp — оплачиваемой стажерской программе, которая поможет студентам и начинающим специалистам прокачать скиллы и с головой погрузиться в IT-сферу. 

Ты можешь выбрать направления:

  • Продуктовая разработка: DevOps или Golang.

  • Кибербезопасность: мониторинг событий и автоматизация или сертификация программных продуктов.

  • Команда внедрения: QA.

  • Технические продажи: технический менеджер клиентов.

Что тебя ждет:

  • оплачиваемая стажировка,

  • работа в реальных проектах,

  • поддержка наставников и экспертов,

  • регулярная обратная связь.

А у лучших стажеров будет возможность попасть в штат Cloud․ru.

Прием заявок открыт до 16 мая включительно, а для прошедших все этапы отбора стажировка начнется 16 июня. Пройти стажировку можно очно в офисе Cloud.ru в Москве, а также удаленно из любой точки РФ. График гибкий — от 20 часов в неделю.

📬 Подать заявку на Cloud.ru Camp

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

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии0

Приглашаем на второй Cloud․ru Tech Lab: DevOps — митап для DevOps- и SRE-инженеров 🎙️

📅 Дата: 22 мая в 18:00
📍 Место: Москва, Goelro Loft, Большая Почтовая улица, 40с4

Мы продолжаем серию технических митапов Cloud․ru Tech Lab — в этот раз обсудим сложности DevOps-процессов и разберем DevOps-практики на реальных кейсах.

Темы докладов:

  • ClusterAPI как цель, Terraform как мост: управляем жизненным циклом платформы — Олег Одинцов, Старший инженер платформы App.Farm, РСХБ-Интех.

  • Автомасштабирование K8s в ноль: от базы до хардкора — Илья Смирнов, Архитектор решений, Cloud․ru.

  • Calico CNI: жизнь после запуска — Александр Качмашев, Инженер, Точка.

  • Как организовать сетевую связность Bare C kubernetes — Антон Паус, DevOps-инженер, Cloud․ru.

Также в программе afterparty c нетворкингом, легкими напитками и закусками.

Мы предусмотрели два формата участия:

  • офлайн — для тех, кто планирует лично посетить площадку,

  • онлайн — для тех, кто хочет посмотреть доклады в записи.

Зарегистрироваться на митап 👈

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Хочу представить свою утилиту muenvsubst для шаблонизации файлов, которая позволяет заменить всем известный envsubst, но при этом обладает гораздо более богатыми возможностями.

Основные фичи:

  • помимо шаблонизации файлов умеет шаблонизировать входной поток (stdin), используя переменные среды и результат выводить в выходной поток (stdout). Также как это делает envsubst

  • поддерживает синтаксис Jinja2 и его основные фичи, такие как условия, циклы, переменные, инклюды, различные вспомогательные функции (например, из шаблона можно звать shell-скрипты)

  • написана на C++ и собрана в статический бинарник x86 размером 350КБ без каких-либо дополнительных зависимостей, что позволяет её включать прямо в репозиторий и использовать в пайплайнах

Ранее я использовал в своих пайплайнах для шаблонизации mustache реализованные на bash и это было довольно удобно, но сам синтаксис и возможности mustache довольно ограниченные, а тащить что-то серьезное типа Jinja2 на питоне мне очень не хотелось, так как это тянуло за собой жирный рантайм, поэтому я и написал эту утилиту.

Надеюсь другим девопсам это зайдет так же как и мне. А также хотелось бы получить фидбек, может какие-то фичи ещё можно допилить?

Несколько примеров использования:

Простая подстановка переменной среды:

echo "Hello, {{ USER }}!" | muenvsubst

Шаблонизируем файл:

muenvsubst -i ./config.yml.j2 -o ./config.yml -d ./includes/

Использование переменных в шаблоне:

muenvsubst <<EOF
{%- set username = upper(USER) -%}
Hello, {{ username }}!
EOF

Использование флагов и условий:

USE_GREETER=yes muenvsubst << EOF
## if default(USE_GREETER, null) | toBool
Hello, {{ USER }}!
## else
Bye, {{ USER }}!
## endif
EOF

Использование циклов и разделение строки в список по символу:

USERS="John,Mark,Peter" muenvsubst << EOF
{%- for user in split(USERS,",") -%}
Hello, {{ user }}!
{%- endfor -%}
EOF

Использование инклюдов:

muenvsubst << EOF
## set USER="John"
## include "greeter.j2"
EOF

Файл инклюда greeter.j2:

Hello, {{ USER }}!
Теги:
Всего голосов 4: ↑4 и ↓0+6
Комментарии3

Начинаем вебинар по повышению производительности инфраструктуры

Привет, Хабр! В 12:00 по МСК проведем вебинар, где разберем, как эффективно использовать GPU в облаке для ML-проектов. Продакт-менеджер облачной платформы Selectel Антон Баранов расскажет, как оптимизировать производительность инфраструктуры и сократить расходы без потери качества. Присоединяйтесь!

Смотреть трансляцию:

на YouTube

в VK

Программа вебинара

  • Шесть способов сократить расходы на IT-инфраструктуру с GPU

  • Подбираем GPU под конкретную задачу. Разбор кейсов клиентов

  • Облако с GPU: обзор возможностей облачной платформы и доступных GPU-карт

  • Как выбрать подходящие карты в облаке и в MKS

  • Сокращаем сетевые задержки с помощью локальных SSD NVMe-дисков в облаке с GPU

  • Ответы на ваши вопросы

Кому будет полезно 

  • Техлидам и менеджерам ML-проектов: как выбрать оптимальную инфраструктуру.

  • Data-инженерам, MLOps-инженерам, DevOps-инженерам

  • Всем, кто работает с облачными ресурсами и хочет повысить ROI проектов.

Теги:
Всего голосов 3: ↑3 и ↓0+5
Комментарии0

Вебинар: как устроена совместная работа виртуальных машин и контейнеров в Deckhouse

Завтра, 23 апреля, мы проведём вебинар о виртуализации в экосистеме Deckhouse. Расскажем, почему разрабатываем своё решение, и покажем, как запускать виртуальные машины рядом с контейнерами, чтобы управлять ими в рамках одной платформы оркестрации. 

Будет полезно, если вы ищете альтернативу классической виртуализации или хотите начать использовать Kubernetes для оркестрации ВМ. Регистрируйтесь и подключайтесь с 12:00 по Москве. Ссылка для подключения придёт вам на почту. 

Вы узнаете:

  • Какие возможности по управлению ВМ уже есть в Deckhouse.

  • Что мы вкладываем в понятие Cloud Native-виртуализации.

  • Для чего может быть нужна совместная работа ВМ и контейнеров.

На демо покажем возможности Deckhouse Kubernetes Platform по администрированию и мониторингу ВМ и контейнеров, конфигурации балансировщиков и микросегментации на основе сетевых политик.

Спикеры вебинара:

  • Георгий Дауман, менеджер продукта Deckhouse Virtualization Platform

  • Кирилл Салеев, архитектор инфраструктурных решений Deckhouse

Теги:
Всего голосов 3: ↑3 и ↓0+3
Комментарии0

Как известно, основной глобальный инструмент для просмотра логов Certificate Transparency (CT-логов) через веб-интерфейс - это crt.sh. Однако сертификаты российских УЦ в глобальные логи пока не попадают (перечень принимаемых сертификатов и пресертификатов в CT-логе всегда ограничен некоторым набором корневых ключей). Для российских УЦ запущены российские CT-логи. Для просмотра российских CT-логов тоже есть сервисы с веб-интерфейсом:

  • ct.tlscc.ru - это выделенный экземпляр crt.sh, поддерживаемый ТЦИ и настроенный на российские логи; веб-сайт использует TLS-сертификат, выпущенный от корня ТЦИ, так что если корня в браузере нет, то будет выдаваться предупреждение; (пример запроса);

  • precert.ru - отдельный и весьма удобный сервис, имеющий целый ряд преимуществ: например, здесь другой интерфейс для поиска записей, подробная статистика по логам и УЦ; (пример запроса).

Сейчас в российские CT-логи добавляются сведения о сертификатах, выпускаемых НУЦ (все логи) и ТЦИ (логи "Яндекса" и VK). Основной объём логов составляют пресертификаты, которые добавляют сами УЦ, в процессе выпуска сертификата. Пресертификат отличается от сертификата наличием специального расширения (CT Poison), отсутствием SCT-меток и значением подписи. Обратите внимание, что сертификаты добавить в CT-лог может каждый. Например, можно добавить сертификат, найденный на каком-то веб-узле в Сети (если, конечно, сертификат выпущен подходящим УЦ). Но для добавления придётся уже воспользоваться HTTP-интерфейсом соответствующего лога напрямую, подготовив и отправив POST-запрос.

Зачем просматривать CT-логи? Во-первых, наличие сторон, изучающих записи в CT-логах, это основной декларируемый смысл Certificate Transparency. Во-вторых, просмотр логов позволяет пронаблюдать, что и для чего выпускается, и даже минимально контролировать выпуск сертификатов для тех доменов, которые вы администрируете; Certificate Transparency не гарантирует, что сведения о выпущенном сертификате будут в CT-логе, но такие сведения могут там быть, а сам по себе сертификат, благодаря наличию цифровой подписи, это какой-никакой, но документ, подтверждающий хотя бы свой собственный выпуск. В-третьих, в логах можно найти что-то неожиданное - для этого внимание нужно обращать на таймстемпы, на формат (пре)сертификатов, на состояние конкретных лог-сервисов.

Теги:
Рейтинг0
Комментарии0

Ближайшие события

Привет, долгожданные новости из мира кубернетиса. Иногда надо посмотреть за подиками, как они там живут поживают, все ли (ре)стартанули или кто завис. В kui для этого сделана кнопка RELOAD. Но постоянно жмякать кнопку это же дро...во какое-то правда? Хватит это терпеть! Добавил команду watch it, теперь можно залипнуть на какое-то время, глядя как подики ползают туда-сюда.

watch it
watch it

Оно будет с паузой в 3 секунды (+ время на обновление) постоянно показывать вывод kubectl get ...

NAME                      READY   STATUS    RESTARTS   AGE
chi-cluster-dev01-0-0-0   2/2     Running   0          23d
chi-cluster-dev01-0-1-0   2/2     Running   0          23d
chi-cluster-dev01-0-2-0   2/2     Running   0          23d

Press x to stop watching this...

Нажмите x когда надоест.

Творите, выдумывайте, пробуйте!)

Теги:
Рейтинг0
Комментарии0

Заполните опрос State of DevOps Russia 2025: помогите отследить тренды и развитие DevOps-практик

«Экспресс 42» запустил ежегодное исследование состояния DevOps в России. Ключевой темой исследования в 2025 году будет developer experience. На основании ваших ответов хотим изучить, что помогает компаниям формировать позитивный опыт для разработчиков и как на него влияют внутренние платформы, ML/AI-инструменты, облачные технологии и практики ИБ. 

В остальном, как и всегда, посмотрим, какие инструменты используют в индустрии, отследим технологические тренды и изучим факторы, влияющие на профиль эффективности компаний. Результатами поделимся осенью. Если у вас есть опыт в сфере DevOps — пройдите опрос. Это займёт около 20 минут. Чем больше респондентов, тем точнее результаты. 

Для кого опрос

Мы приглашаем заполнить анкету исследования всех специалистов, связанных с DevOps: инженеров и администраторов, разработчиков и тестировщиков, техлидов и тимлидов, CIO и CTO. В 2024 году в опросе приняли участие больше 4100 респондентов, и мы надеемся, что в этом году вас будет ещё больше. 

Если вы заполните анкету, то сможете поучаствовать в лотерее с розыгрышем классных призов от «Экспресс 42» и генеральных партнёров исследования. Более 80 победителей получат мерч, подписки на полезные и развлекательные сервисы, промокоды на незаменимые в работе продукты и билеты на такие профильные конференции, как Highload и DevOpsConf. 

Присоединяйтесь!

P. S.

Полные отчёты с 2020 по 2024 год можно скачать на лендинге State of DevOps Russia.

Теги:
Всего голосов 3: ↑3 и ↓0+3
Комментарии0

Пишут, что CA/B-форум согласовал дальнейшее сокращение интервала валидности TLS-сертификатов: теперь планируют к 2029 году уменьшить этот интервал до 47 дней. Ожидаемо. Я бы предположил, что ещё короче сделают (да и, фактически, раньше; например, Let's Encrypt уже готовит шестидневные сертификаты).

Тенденция коснётся и сертификатов, выпускаемых "собственными УЦ": если браузер принципиально не верит сертификатам только на основании длительности их интервала валидности, то не играет роли, был ли добавлен корневой ключ УЦ вручную или приехал в составе дистрибутива. (Технически, да, урезать действие ограничения для "домашних" сертификатов можно, но вряд ли имеет смысл на это рассчитывать.) Кроме того, строго автоматический выпуск сертификатов - требует наличия подходящего API на стороне УЦ, тоже немаловажный технологический фактор.

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

Теги:
Всего голосов 4: ↑4 и ↓0+6
Комментарии0

Привет, Хабр! Меня зовут Станислав Егоркин, я инженер юнита IaaS департамента разработки Infrastructure в AvitoTech.

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

За основу я взял наш дашборд Node Status, который показывал в предыдущей статье. Напомню, он служит для того, чтобы быстро понять, все ли в порядке с нодой в Kubernetes-кластере. В своей основе она содержит множество небольших панелек, которые единообразно подсвечиваются при возникновении аномалий: оранжевый значит «обрати внимание», красный - явно что-то не так. При необходимости по клику можно получить расширенную информацию по каждой метрике.

Я очистил наш внутренний вариант от специфики. Это позволяет использовать дашборд в любых окружениях, в которых развернуты нужные экспортеры:

  • node-exporter (лейбл «node» должен содержать имя Kubernetes-ноды);

  • kube-state-metrics;

  • node-problem-detector (опционально).

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

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

Если вы у вас возникнут сложности при использовании дашборда или предложения по его улучшению, пожалуйста, оставляйте свои комментарии! 

Теги:
Всего голосов 19: ↑19 и ↓0+20
Комментарии0

Внедряем ИИ с умом: разбор Gartner AI Opportunity Radar

Привет, Хабр!

ИИ обещает многое, но без чёткого плана легко спустить бюджет впустую. Gartner утверждает, что до 70% ИИ-проектов не окупаются из-за хаоса в подходе. Их ответ на это — "AI Opportunity Radar", инструмент, который должен помочь бизнесу и ИТ-командам понять, где ИИ даст результат, а где пока рано спешить. Разбираем, как он работает, с примерами из практики и техническими деталями.

Фактически это стратегическая диаграмма, которая делит возможности ИИ на четыре зоны по двум осям:

  • Внешнее (Customer-Facing) vs Внутреннее (Operations-Focused): для клиентов или внутренних процессов.

  • Повседневный ИИ (Everyday AI) vs Изменяющий правила игры (Game-Changing AI): постепенные улучшения или радикальные перемены.

Радар помогает выбрать приоритеты: быстрые улучшения или долгосрочные инвестиции.
Радар помогает выбрать приоритеты: быстрые улучшения или долгосрочные инвестиции.

Четыре зоны применения ИИ

1. Фронт-офис: улучшаем клиентский опыт

  • Суть: ИИ для взаимодействия с клиентами.

  • Пример: Чат-боты на базе LLM (например, Telegram-боты для поддержки).

  • Техстек: Используются NLP-фреймворки (Rasa, Hugging Face), интеграция с CRM через API, деплой на облаке (AWS, Azure). Нужны данные о клиентах.

  • Результат: Снижение нагрузки на саппорт, рост удовлетворённости (NPS).

2. Продукты и услуги: создаём новое

  • Суть: ИИ как часть продукта или бизнес-модели.

  • Пример: GitHub Copilot (трансформеры, обученные на миллионах репозиториев).

  • Техстек: Кастомные модели (PyTorch, TensorFlow), большие датасеты, GPU/TPU для тренировки, сложный пайплайн деплоя.

  • Результат: Уникальное предложение, выход на новые рынки.

3. Ключевые компетенции: усиливаем преимущества

  • Суть: ИИ для стратегического превосходства.

  • Пример: Антифрод в финтехе (Mastercard использует ансамбли LightGBM для анализа транзакций с latency < 50 мс).

  • Техстек: Исторические данные, feature engineering, потоковая обработка (Kafka, Spark).

  • Результат: Снижение рисков, лидерство в нише.

4. Бэк-офис: автоматизируем рутину

  • Суть: Оптимизация внутренних процессов.

  • Пример: Прогноз сбоев в CI/CD (GitLab экспериментирует с anomaly detection).

  • Техстек: Лёгкие модели (scikit-learn) или SaaS-решения (RPA, OCR), низкий порог входа.

  • Результат: Экономия ресурсов, меньше ошибок.

Как оценить возможности?

Gartner предлагает три фильтра:

  1. Техническая осуществимость:

    • Чат-бот: пара недель на API + настройку.

    • Кастомный ИИ: годы R&D, миллионы на инфраструктуру.

  2. Готовность компании:

    • Данные в DWH или хотя бы в нормальной базе?

    • Есть ML-инженеры или хотя бы аналитики?

  3. Рынок:

    • Клиенты примут бота, но скептичны к ИИ в критических сферах (медицина, финансы).

Каждая идея получает метку: "зелёный" (старт), "жёлтый" (дозреть), "красный" (ждать).

Практические кейсы

  • Фронт-офис: Бот для техподдержки (Rasa + PostgreSQL, деплой на Kubernetes).

  • Продукты: ИИ для анализа кода (Copilot: трансформеры + миллиарды строк кода).

  • Компетенции: Антифрод (LightGBM, данные транзакций, Spark Streaming).

  • Бэк-офис: Анализ логов (ELK Stack + ML для поиска аномалий).

Как внедрять: пошаговый план

  1. Определить цель: Руководство решает — рутина или трансформация.

  2. Карта идей: Нанести проекты на радар, оценить по трём критериям.

  3. Быстрые победы: Начать с бэк-офиса или фронт-офиса для первых результатов.

  4. Управление рисками:

    • Данные: шифрование, соответствие нормативке.

    • Модели: проверка на bias, мониторинг дрифта (MLflow, Prometheus).

  5. Итерации: Постоянно обновлять подход с учётом новых технологий.

Плюсы и минусы радара

  • Плюсы:

    • Структурирует хаос внедрения ИИ.

    • Подходит для любых масштабов.

  • Минусы:

    • Без данных и команды — пустая теория.

    • Требует адаптации под ваш домен, требования.

Вывод

"AI Opportunity Radar" — это фильтр, а не готовое решение. Он помогает отделить реальные задачи (боты, автоматизация) от фантазий (полный ИИ без данных).

Для старта — берите простое, стройте инфраструктуру, а потом уже замахивайтесь на крупное.

Теги:
Всего голосов 2: ↑2 и ↓0+4
Комментарии0

13 марта 16:00 CET (18:00 Мск) Андрей Квапил, более известный в инженерном сообществе как @kvaps будет травить байки о том, как правильно готовить LINSTOR и Talos Linux — на этот раз на комьюнити-мите LINBIT (создатели LINSTOR и DRBD). Основано на реальных событиях, приключившихся в Cozystack:)

Программа комьюнити-мита:

  • Andrei Kvapil: LINSTOR on Talos Linux: A robust base for Cozystack

  • Joel Colledge: DRBD resync without replication

  • Johannes Khoshnazar-Thoma: WinDRBD 1.2 news

Присоединяйтесь к трансляции:

Кроме того, будем транслировать встречу в телеграм-чате @drbd_ru.

Теги:
Рейтинг0
Комментарии0

Хабр, привет!

Приглашаем на митап о карьере в Linux🐧.

19 марта эксперты компании и приглашенный гость — блогер Константин Дипеж (DeusOps) — обсудят профессиональный путь Linux-специалиста.

— как безболезненно «вкатиться» в Linux

— с чем откликаться на вакансию

— какие вопросы задают на техническом интервью

— как расти профессионально после оффера

— как развиваться в DevOps и не только

Приглашаем Linux-специалистов, которые видят зоны роста и хотят выйти на новый уровень профессиональной экспертизы

Во время дискуссии можно будет задать вопросы спикерам. За лучшие – обещаем мерч;)

Встреча пройдет онлайн, 19 марта в 18:00 (мск). Подробности и регистрация на сайте.

Теги:
Всего голосов 1: ↑1 и ↓0+2
Комментарии0

Вклад авторов